Cryptography
aes tls gcm integrity aes-gcm
Updated Sun, 19 Jun 2022 02:11:06 GMT

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


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.

Ive read RFC 5289, RFC 5288, RFC 5246, etc., but Ive 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?

Solution

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.

Comments (2)

  • +0 – Thank you for referencing this @SEJPM. What threat does this aim to prevent, and how does the use of this information as the additional authenticated data mitigate that threat? — May 31, 2018 at 20:22  
  • +0 – Note this is exactly the same pseudoheader added to the plaintext when computing HMAC for non-AEAD ciphersuites in 6.2.3.1, and its length 8+1+2+2=13 is the source of the RHUL group's 'Lucky 13' attack. — Jun 01, 2018 at 01:26  

External Links

External links referenced by this document:

References