TLS 1.2 Cipher Suites With AES-GCM – What data (if any) is passed to the AES-GCM cipher as the Additional Authentication Data?

Question

TLS 1.2 defines a number of cipher suites that employ AES-GCM, e.g.:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384  
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256    
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384    

Being that AES-GCM is an AEAD cipher, it handles both encryption and integrity verification. Also, it can optionally accept additional authentication data as one of its inputs (in addition to the plaintext, the key, and the iv). The additional authentication data is not encrypted, but it is included in the integrity verification process.

I’ve read RFC 5289, RFC 5288, RFC 5246, etc., but I’ve not found any mention of what data, if any, is passed to the AES-GCM cipher as the additional authentication data in a TLS 1.2 implementation such as one of the above.

My question is: In a TLS 1.2 implementation that employs AES-GCM – what data (if any) is passed to the AES-GCM cipher as the additional authentication data?

Answer 1

Actually section 6.2.3.3 of RFC 5246 talks about the associated data:

The additional authenticated data, which we denote as
additional_data, is defined as follows:

additional_data = seq_num + TLSCompressed.type +
                    TLSCompressed.version + TLSCompressed.length;

where "+" denotes concatenation.

So the sequence number, the packet version, the packet type and the packet length are passed as associated data to the cipher.

---

So why is exactly this data authenticated?

• The sequence number: Authenticating this helps prevent re-ordering and replay attacks and binds the sequence number to the data packet.
• The protocol version: Authenticating this ensures that if you can't downgrade the protocol version (eg to SSLv3) to exploit weaknesses and learn something about the content of the current packet.
• The packet type: I suppose this blocks you from re-using a handshake packet for an application traffic packet (which may have independent sequence number streams)
• The packet length: This blocks you from silently chopping some data off somewhere, but is mostly here because it's public data and authenticating it doesn't really hurt.