Adding TLS 1.2 Support to Your TLS Library - Implementing SSL/TLS Using Cryptography and PKI - page 496

However, CBC-MAC fails to provide all of the requirements for a secure MAC.
It satisfi es the fi rst and second requirements. You cannot discover the
key from the output, and somebody without the key cannot generate a
valid MAC.
It fails to satisfy the last two requirements; it is possible to deliberately
engineer collisions this way.
Therefore, CBC-MAC must be used with an encryption algorithm; the MAC
itself must be protected by a cipher.
Combining CTR and CBC-MAC into AES-CCM
AES-CCM uses AES in CTR mode to achieve encryption and the same algorithm
in CBC-MAC mode to achieve authentication (CCM just stands for Counter with
CBC-MAC). AES-CCM is specifi ed by the U.S. government's NIST at http://csrc
.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf . Both encryption
and MAC are used with the same key to provide a simultaneously encrypted
and authenticated block. The length of the output is the same as that of the
input, plus the chosen length of the MAC.
The length of the MAC is variable; as noted previously, you can make it any
length you want, up to the length of an AES block. However, both sides must agree,
before exchanging any data, what this length is; although the MAC length affects
the output, it's not recoverable from the ciphertext. Therefore, the length must gen-
erally be fi xed at implementation time, or exchanged out of band. To keep things
relatively simple, you fi x it at eight bytes.
Conceptually, AES-CCM is simple — CTR mode and CBC-MAC are both
fairly easy to understand. However, as they say, “the devil is in the details.”
Actually implementing AES-CCM according to the standard is fairly complex,
because everything has to be just-so to achieve proper interoperability. Most of
the complexity in CCM surrounds the MAC. Remember from Chapter 4 that a
good MAC function must include the length of the input somehow; MD5 and
SHA both append a padding block terminated with the length of the input, in
bits. This ensures that a single 0 bit MAC's to something different than, say, two
0 bits. CCM uses CBC-MAC with such a length, but the length is prepended
rather than appended.
In fact, the fi rst input block to the MAC function is an entire 16-byte block
of header information. This header information is never encrypted, but is just
used to initialize the MAC. The fi rst byte of this header information declares
both the length of the MAC and the number of bytes that encode the length of
the input. In other words, if the length of the input is encoded in a four-byte
integer, then the fi rst byte of the header block declares “4”. (This also means that
the length of the input must be known before encryption begins. AES-CCM
does not lend itself to “running” computations.)