]> Cisco Systems, Inc.

510 McCarthy Blvd. Milpitas CA 95035 US (408) 525 8651 mcgrew@cisco.com http://www.mindspring.com/~dmcgrew/dam.htm

General ESP This note provides test cases for the use of AES GCM and GMAC in ESP, as defined in RFC4106 and RFC4543, and clarifies some points in the latter specification.

This document reviews the use of the Galois/Counter Mode (GCM) and Galois Message Authentication Code (GMAC) modes of operation for the Advanced Encryption Standard as they are used in the Encapsulating Security Payload (ESP) .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

We briefly review the AES-GCM-ESP and AES-GMAC-ESP definitions and establish the notation used in the test cases. The GCM encryption operation takes as input a key, a nonce, a plaintext, and an additional authenticated data (AAD) value. It outputs a ciphertext and an authentication tag, or "tag" for short. Here we follow and refer to the GCM initialization vector (IV) as a nonce in order to differentiate it from the IV that is carried in the ESP packet. The eight-byte ESP IV forms part of the 12-byte GCM nonce. In , "The Use of Galois/Counter Mode (GCM) in IPsec ESP", the GCM inputs and ESP fields are as follows:

Here the fields RestOfPayloadData, TFCpadding, Padding, PadLength, NextHeader, SPI, SequenceNumber, and ICV are as defined in and the fields Salt and IV are as defined in . The field RestOfPayloadData contains the plaintext data that is described by the NextHeader field, and no other data. (Recall that the PayloadData field contains both the IV and the RestOfPayloadData; see for an illustration.) defines the tag as the ICV, instead of defining it as the final part of the Payload Data. However, the two definitions are functionally equivalent. +-----------+-----+-----+ <-+ | ENCR_NULL_AUTH_AES_GMAC AAD --+ ]]> -->

In RFC 4543, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", the GMAC inputs and ESP fields are as follows:

Here the symbol {} refers to the zero-length octet string. The "Payload Data" is called the "Authenticated Payload" in one part of RFC 4543. It consists of the eight-octet IV, followed by the data encapsulated by ESP, that is, the data referred to by the Next Header field. RFC 4543, Section 7 (Security Considerations), second sentence, should read "In AES-GCM-ESP, the IV is not included in either the plaintext or the additional authenticated data." It currently contains a typographical error, and reads "In ENCR_NULL_AUTH_AES_GMAC, the IV is not included in either the plaintext or the additional authenticated data."

Here are the test cases. The algorithm used in the test case. The secret key used by AES-GCM or AES-GMAC. The ESP SPI field. The ESP Sequence Number field, if the length is four octets, or the ESP Extended Sequence Number, if the length is eight octets. The AES-GCM or AES-GMAC nonce; it is an input to the algorithm. The AES-GCM plaintext, which is an input to that algorithm. The AES-GCM or AES-GMAC additional authenticated data; it is an input to that algorithm. The AES-GCM ciphertext and authentication tag, or the AES-GMAC authentication tag; this is an output from the algorithm. The complete ESP packet.

An improperly implemented crypto algorithm may be insecure.

This document has no actions for IANA.

Thanks to Arpan Srivastava and Aravindhan P. for generating and validating test cases.

&rfc2119; &rfc4106; &rfc4303;