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?
Actually section 22.214.171.124 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?
External links referenced by this document: