AES-CCM Cipher Suites for Transport Layer Security (TLS)
Extracted elements (20)
AES-CCM uses only the AES encrypt operation (decryption is not needed), making it amenable to compact implementations and therefore suitable for constrained environments such as embedded servers and 802.15.4 wireless sensor nodes. Adoption in standard TLS is also needed to enable interoperability between web clients and embedded devices.
The _8 cipher suite variants (8-octet authentication tags) are introduced specifically because they produce shorter ciphertexts and are more suitable for bandwidth-constrained networks with small message sizes, at the cost of a shorter authentication tag compared to the full 16-octet tag.
The HMAC truncation option negotiated via the 'truncated_hmac' TLS extension (RFC 6066 Section 7) has no effect on these AES-CCM cipher suites because they do not use HMAC for record authentication.
These cipher suites cannot be used with DTLS versions earlier than 1.2, since the ability to use AEAD ciphers was introduced in DTLS 1.2 (RFC 6347).
Clients MUST check the TLS version and generate a fatal 'illegal_parameter' alert if they detect an incorrect version, guarding against non-compliant servers that might negotiate TLS 1.1 or earlier while selecting these suites.
Clients MUST NOT offer these cipher suites if they do not offer TLS 1.2 or later.
Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security.
Servers that select an earlier version of TLS MUST NOT select one of these cipher suites.
The nonce SHALL be 12 bytes long and is constructed as the 4-byte salt concatenated with the 8-byte nonce_explicit, following the 'partially explicit' nonce pattern of RFC 5116 Section 3.2.1.
These cipher suites MUST NOT be negotiated in TLS versions earlier than 1.2, since AEAD support was introduced in TLS 1.2 and the TLSCiphertext structure lacked the 'aead' option before that version.
AEAD_AES_128_CCM_8 (algorithm identifier 18) is identical to AEAD_AES_128_CCM except it uses an 8-octet authentication tag instead of 16 octets. The ciphertext is exactly 8 octets longer than the corresponding plaintext.
AEAD_AES_256_CCM_8 (algorithm identifier 19) is identical to AEAD_AES_256_CCM except it uses an 8-octet authentication tag instead of 16 octets. The ciphertext is exactly 8 octets longer than the corresponding plaintext.
Eight PSK-based AES-CCM cipher suites are defined: TLS_PSK_WITH_AES_128_CCM (0xC0,0xA4), TLS_PSK_WITH_AES_256_CCM (0xC0,0xA5), TLS_DHE_PSK_WITH_AES_128_CCM (0xC0,0xA6), TLS_DHE_PSK_WITH_AES_256_CCM (0xC0,0xA7), and _8 tag variants (0xC0,0xA8–0xC0,0xAB). PSK and DHE_PSK key exchange follows RFC 4279/5487.
Eight RSA-based AES-CCM cipher suites are defined: TLS_RSA_WITH_AES_128_CCM (0xC0,0x9C), TLS_RSA_WITH_AES_256_CCM (0xC0,0x9D), TLS_DHE_RSA_WITH_AES_128_CCM (0xC0,0x9E), TLS_DHE_RSA_WITH_AES_256_CCM (0xC0,0x9F), and their _8 variants with 8-octet authentication tags (0xC0,0xA0–0xC0,0xA3). Non-_8 suites use 16-octet authentication tags; all use the TLS 1.2 PRF with HMAC-SHA-256.
IANA assigned algorithm identifiers 18 (AEAD_AES_128_CCM_8) and 19 (AEAD_AES_256_CCM_8) from the 'AEAD Algorithms' registry.
IANA assigned values for the 16 cipher suites defined in Sections 3 and 4 from the 'TLS Cipher Suite' registry (0xC09C–0xC0AB).
AES-CCM security requires that the counter is never reused. The IV construction (4-byte implicit salt plus 8-byte explicit per-record nonce) is specifically designed to prevent counter reuse across records.
Only the ephemeral Diffie-Hellman-based cipher suites (DHE_RSA and DHE_PSK variants) are capable of providing perfect forward secrecy; RSA and PSK static key exchange variants do not provide PFS.
The CCMNonce is exactly 12 bytes: a 4-byte implicit salt (client_write_IV or server_write_IV, not transmitted on the wire) concatenated with an 8-byte explicit nonce (nonce_explicit) carried in each TLS record's GenericAEADCipher.nonce_explicit field. SecurityParameters.fixed_iv_length is 4; SecurityParameters.record_iv_length is 8.
When nonce_explicit equals the sequence number, the CCMClientNonce is struct { uint32 client_write_IV; uint64 seq_num; } and CCMServerNonce is struct { uint32 server_write_IV; uint64 seq_num; }. In DTLS the 64-bit seq_num is the 16-bit epoch concatenated with the 48-bit sequence number.