Adding support for AES GMAC (RFC4543).

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/standards/rfc4543.txt b/doc/standards/rfc4543.txt
new file mode 100644
index 000000000..5e9668eb8
--- /dev/null
+++ b/doc/standards/rfc4543.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                          D. McGrew
+Request for Comments: 4543                           Cisco Systems, Inc.
+Category: Standards Track                                       J. Viega
+                                                            McAfee, Inc.
+                                                                May 2006
+
+
+        The Use of Galois Message Authentication Code (GMAC) in
+                            IPsec ESP and AH
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This memo describes the use of the Advanced Encryption Standard (AES)
+   Galois Message Authentication Code (GMAC) as a mechanism to provide
+   data origin authentication, but not confidentiality, within the IPsec
+   Encapsulating Security Payload (ESP) and Authentication Header (AH).
+   GMAC is based on the Galois/Counter Mode (GCM) of operation, and can
+   be efficiently implemented in hardware for speeds of 10 gigabits per
+   second and above, and is also well-suited to software
+   implementations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 1]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................3
+   2. AES-GMAC ........................................................3
+   3. The Use of AES-GMAC in ESP ......................................3
+      3.1. Initialization Vector ......................................4
+      3.2. Nonce Format ...............................................4
+      3.3. AAD Construction ...........................................5
+      3.4. Integrity Check Value (ICV) ................................6
+      3.5. Differences with AES-GCM-ESP ...............................6
+      3.6. Packet Expansion ...........................................7
+   4. The Use of AES-GMAC in AH .......................................7
+   5. IKE Conventions .................................................8
+      5.1. Phase 1 Identifier .........................................8
+      5.2. Phase 2 Identifier .........................................8
+      5.3. Key Length Attribute .......................................9
+      5.4. Keying Material and Salt Values ............................9
+   6. Test Vectors ....................................................9
+   7. Security Considerations ........................................10
+   8. Design Rationale ...............................................11
+   9. IANA Considerations ............................................11
+   10. Acknowledgements ..............................................11
+   11. References ....................................................12
+      11.1. Normative References .....................................12
+      11.2. Informative References ...................................12
+1.  Introduction
+
+   This document describes the use of AES-GMAC mode (AES-GMAC) as a
+   mechanism for data origin authentication in ESP [RFC4303] and AH
+   [RFC4302].  We refer to these methods as ENCR_NULL_AUTH_AES_GMAC and
+   AUTH_AES_GMAC, respectively.  ENCR_NULL_AUTH_AES_GMAC is a companion
+   to the AES Galois/Counter Mode ESP [RFC4106], which provides
+   authentication as well as confidentiality.  ENCR_NULL_AUTH_AES_GMAC
+   is intended for cases in which confidentiality is not desired.  Like
+   GCM, GMAC is efficient and secure, and is amenable to high-speed
+   implementations in hardware.  ENCR_NULL_AUTH_AES_GMAC and
+   AUTH_AES_GMAC are designed so that the incremental cost of
+   implementation, given an implementation is AES-GCM-ESP, is small.
+
+   This document does not cover implementation details of GCM or GMAC.
+   Those details can be found in [GCM], along with test vectors.
+
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 2]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+1.1.  Conventions Used in This Document
+
+   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 [RFC2119].
+
+2.  AES-GMAC
+
+   GMAC is a block cipher mode of operation providing data origin
+   authentication.  It is defined in terms of the GCM authenticated
+   encryption operation as follows.  The GCM authenticated encryption
+   operation has four inputs: a secret key, an initialization vector
+   (IV), a plaintext, and an input for additional authenticated data
+   (AAD).  It has two outputs, a ciphertext whose length is identical to
+   the plaintext and an authentication tag.  GMAC is the special case of
+   GCM in which the plaintext has a length of zero.  The (zero-length)
+   ciphertext output is ignored, of course, so that the only output of
+   the function is the Authentication Tag.  In the following, we
+   describe how the GMAC IV and AAD are formed from the ESP and AH
+   fields, and how the ESP and AH packets are formed from the
+   Authentication Tag.
+
+   Below we refer to the AES-GMAC IV input as a nonce, in order to
+   distinguish it from the IV fields in the packets.  The same nonce and
+   key combination MUST NOT be used more than once, since reusing a
+   nonce/key combination destroys the security guarantees of AES-GMAC.
+
+   Because of this restriction, it can be difficult to use this mode
+   securely when using statically configured keys.  For the sake of good
+   security, implementations MUST use an automated key management
+   system, such as the Internet Key Exchange (IKE) (either version two
+   [RFC4306] or version one [RFC2409]), to ensure that this requirement
+   is met.
+
+3.  The Use of AES-GMAC in ESP
+
+   The AES-GMAC algorithm for ESP is defined as an ESP "combined mode"
+   algorithm (see Section 3.2.3 of [RFC4303]), rather than an ESP
+   integrity algorithm.  It is called ENCR_NULL_AUTH_AES_GMAC to
+   highlight the fact that it performs no encryption and provides no
+   confidentiality.
+
+      Rationale: ESP makes no provision for integrity transforms to
+      place an initialization vector within the Payload field; only
+      encryption transforms are expected to use IVs.  Defining GMAC as
+      an encryption transform avoids this issue, and allows GMAC to
+      benefit from the same pipelining as does GCM.
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 3]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+   Like all ESP combined modes, it is registered in IKEv2 as an
+   encryption transform, or "Type 1" transform.  It MUST NOT be used in
+   conjunction with any other ESP encryption transform (within a
+   particular ESP encapsulation).  If confidentiality is desired, then
+   GCM ESP [RFC4106] SHOULD be used instead.
+
+3.1.  Initialization Vector
+
+   With ENCR_NULL_AUTH_AES_GMAC, an explicit Initialization Vector (IV)
+   is included in the ESP Payload, at the outset of that field.  The IV
+   MUST be eight octets long.  For a given key, the IV MUST NOT repeat.
+   The most natural way to meet this requirement is to set the IV using
+   a counter, but implementations are free to set the IV field in any
+   way that guarantees uniqueness, such as a linear feedback shift
+   register (LFSR).  Note that the sender can use any IV generation
+   method that meets the uniqueness requirement without coordinating
+   with the receiver.
+
+3.2.  Nonce Format
+
+   The nonce passed to the AES-GMAC authentication algorithm has the
+   following layout:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Salt                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Initialization Vector                     |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 1: Nonce Format
+
+   The components of the nonce are as follows:
+
+   Salt
+      The salt field is a four-octet value that is assigned at the
+      beginning of the security association, and then remains constant
+      for the life of the security association.  The salt SHOULD be
+      unpredictable (i.e., chosen at random) before it is selected, but
+      need not be secret.  We describe how to set the salt for a
+      Security Association established via the Internet Key Exchange in
+      Section 5.4.
+
+   Initialization Vector
+      The IV field is described in Section 3.1.
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 4]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+3.3.  AAD Construction
+
+   Data integrity and data origin authentication are provided for the
+   SPI, (Extended) Sequence Number, Authenticated Payload, Padding, Pad
+   Length, and Next Header fields.  This is done by including those
+   fields in the AES-GMAC Additional Authenticated Data (AAD) field.
+   Two formats of the AAD are defined: one for 32-bit sequence numbers,
+   and one for 64-bit extended sequence numbers.  The format with 32-bit
+   sequence numbers is shown in Figure 2, and the format with 64-bit
+   extended sequence numbers is shown in Figure 3.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               SPI                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     32-bit Sequence Number                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                Authenticated Payload (variable)               ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Padding (0-255 bytes)                      |
+   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               |  Pad Length   | Next Header   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+            Figure 2: AAD Format with 32-bit Sequence Number
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               SPI                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 64-bit Extended Sequence Number               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                Authenticated Payload (variable)               ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Padding (0-255 bytes)                      |
+   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               |  Pad Length   | Next Header   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Figure 3: AAD Format with 64-bit Extended Sequence Number
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 5]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+   The use of 32-bit sequence numbers vs. 64-bit extended sequence
+   numbers is determined by the security association (SA) management
+   protocol that is used to create the SA.  For IKEv2 [RFC4306] this is
+   negotiated via Transform Type 5, and the default for ESP is to use
+   64-bit extended sequence numbers in the absence of negotiation (e.g.,
+   see Section 2.2.1 of [RFC4303]).
+
+3.4.  Integrity Check Value (ICV)
+
+   The ICV consists solely of the AES-GMAC Authentication Tag.  The
+   Authentication Tag MUST NOT be truncated, so the length of the ICV is
+   16 octets.
+
+3.5.  Differences with AES-GCM-ESP
+
+   In this section, we highlight the differences between this
+   specification and AES-GCM-ESP [RFC4106].  The essential difference is
+   that in this document, the AAD consists of the SPI, Sequence Number,
+   and ESP Payload, and the AES-GCM plaintext is zero-length, while in
+   AES-GCM-ESP, the AAD consists only of the SPI and Sequence Number,
+   and the AES-GCM plaintext consists of the ESP Payload.  These
+   differences are illustrated in Figure 4.  This figure shows the case
+   in which the Extended Sequence Number option is not used.  When that
+   option is exercised, the Sequence Number field in the figure would be
+   replaced with the Extended Sequence Number.
+
+   Importantly, ENCR_NULL_AUTH_AES_GMAC is *not* equivalent to AES-GCM-
+   ESP with encryption "turned off".  However, the ICV computations
+   performed in both cases are similar because of the structure of the
+   GHASH function [GCM].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 6]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+                     +-> +-----------------------+ <-+
+      AES-GCM-ESP    |   |          SPI          |   |
+          AAD -------+   +-----------------------+   |
+                     |   |    Sequence Number    |   |
+                     +-> +-----------------------+   |
+                         |    Authentication     |   |
+                         |          IV           |   |
+                  +->+-> +-----------------------+   +
+      AES-GCM-ESP |      |                       |   |
+       Plaintext -+      ~       ESP Payload     ~   |
+                  |      |                       |   |
+                  |      +-----------+-----+-----+   |
+                  |      | Padding   |  PL | NH  |   |
+                  +----> +-----------+-----+-----+ <-+
+                                                     |
+                       ENCR_NULL_AUTH_AES_GMAC AAD --+
+
+   Figure 4: Differences between ENCR_NULL_AUTH_AES_GMAC and AES-GCM-ESP
+
+3.6.  Packet Expansion
+
+   The IV adds an additional eight octets to the packet and the ICV adds
+   an additional 16 octets.  These are the only sources of packet
+   expansion, other than the 10-13 bytes taken up by the ESP SPI,
+   Sequence Number, Padding, Pad Length, and Next Header fields (if the
+   minimal amount of padding is used).
+
+4.  The Use of AES-GMAC in AH
+
+   In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
+   and the Authentication Tag, as shown in Figure 5.  Unlike the usual
+   AH case, the Authentication Data field contains both an input to the
+   authentication algorithm (the IV) and the output of the
+   authentication algorithm (the tag).  No padding is required in the
+   Authentication Data field, because its length is a multiple of 64
+   bits.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 7]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Initialization Vector (IV)                 |
+   |                            (8 octets)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |             Integrity Check Value (ICV) (16 octets)           |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 5: The AUTH_AES_GMAC Authentication Data Format
+
+   The IV is as described in Section 3.1.  The Integrity Check Value
+   (ICV) is as described in Section 3.4.
+
+   The GMAC Nonce input is formed as described in Section 3.2.  The GMAC
+   AAD input consists of the authenticated data as defined in Section
+   3.1 of [RFC4302].  These values are provided as to that algorithm,
+   along with the secret key, and the resulting authentication tag given
+   as output is used to form the ICV.
+
+5.  IKE Conventions
+
+   This section describes the conventions used to generate keying
+   material and salt values for use with ENCR_NULL_AUTH_AES_GMAC and
+   AUTH_AES_GMAC using the Internet Key Exchange (IKE) versions one
+   [RFC2409] and two [RFC4306].
+
+5.1.  Phase 1 Identifier
+
+   This document does not specify the conventions for using AES-GMAC for
+   IKE Phase 1 negotiations.  For AES-GMAC to be used in this manner, a
+   separate specification would be needed, and an Encryption Algorithm
+   Identifier would need to be assigned.  Implementations SHOULD use an
+   IKE Phase 1 cipher that is at least as strong as AES-GMAC.  The use
+   of AES-CBC [RFC3602] with the same AES key size as used by
+   ENCR_NULL_AUTH_AES_GMAC or AUTH_AES_GMAC is RECOMMENDED.
+
+5.2.  Phase 2 Identifier
+
+   For IKE Phase 2 negotiations, IANA has assigned identifiers as
+   described in Section 9.
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 8]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+5.3.  Key Length Attribute
+
+   AES-GMAC can be used with any of the three AES key lengths.  The way
+   that the key length is indicated is different for AH and ESP.
+
+   For AH, each key length has its own separate integrity transform
+   identifier and algorithm name (Section 9).  The IKE Key Length
+   attribute MUST NOT be used with these identifiers.  This transform
+   MUST NOT be used with ESP.
+
+   For ESP, there is a single encryption transform identifier (which
+   represents the combined transform) (Section 9).  The IKE Key Length
+   attribute MUST be used with each use of this identifier to indicate
+   the key length.  The Key Length attribute MUST have a value of 128,
+   192, or 256.
+
+5.4.  Keying Material and Salt Values
+
+   IKE makes use of a pseudo-random function (PRF) to derive keying
+   material.  The PRF is used iteratively to derive keying material of
+   arbitrary size, called KEYMAT.  Keying material is extracted from the
+   output string without regard to boundaries.
+
+   The size of the KEYMAT for the ENCR_NULL_AUTH_AES_GMAC and
+   AUTH_AES_GMAC MUST be four octets longer than is needed for the
+   associated AES key.  The keying material is used as follows:
+
+   ENCR_NULL_AUTH_AES_GMAC with a 128-bit key and AUTH_AES_128_GMAC
+      The KEYMAT requested for each AES-GMAC key is 20 octets.  The
+      first 16 octets are the 128-bit AES key, and the remaining four
+      octets are used as the salt value in the nonce.
+
+   ENCR_NULL_AUTH_AES_GMAC with a 192-bit key and AUTH_AES_192_GMAC
+      The KEYMAT requested for each AES-GMAC key is 28 octets.  The
+      first 24 octets are the 192-bit AES key, and the remaining four
+      octets are used as the salt value in the nonce.
+
+   ENCR_NULL_AUTH_AES_GMAC with a 256-bit key and AUTH_AES_256_GMAC
+      The KEYMAT requested for each AES-GMAC key is 36 octets.  The
+      first 32 octets are the 256-bit AES key, and the remaining four
+      octets are used as the salt value in the nonce.
+
+6.  Test Vectors
+
+   Appendix B of [GCM] provides test vectors that will assist
+   implementers with AES-GMAC.
+
+
+
+
+
+McGrew & Viega              Standards Track                     [Page 9]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+7.  Security Considerations
+
+   Since the authentication coverage is different between AES-GCM-ESP
+   and this specification (see Figure 4), it is worth pointing out that
+   both specifications are secure.  In ENCR_NULL_AUTH_AES_GMAC, the IV
+   is not included in either the plaintext or the additional
+   authenticated data.  This does not adversely affect security, because
+   the IV field only provides an input to the GMAC IV, which is not
+   required to be authenticated (see [GCM]).  In AUTH_AES_GMAC, the IV
+   is included in the additional authenticated data.  This fact has no
+   adverse effect on security; it follows from the property that GMAC is
+   secure even against attacks in which the adversary can manipulate
+   both the IV and the message.  Even an adversary with these powerful
+   capabilities cannot forge an authentication tag for any message
+   (other than one that was submitted to the chosen-message oracle).
+   Since such an adversary could easily choose messages that contain the
+   IVs with which they correspond, there are no security problems with
+   the inclusion of the IV in the AAD.
+
+   GMAC is provably secure against adversaries that can adaptively
+   choose plaintexts, ICVs and the AAD field, under standard
+   cryptographic assumptions (roughly, that the output of the underlying
+   cipher under a randomly chosen key is indistinguishable from a
+   randomly selected output).  Essentially, this means that, if used
+   within its intended parameters, a break of GMAC implies a break of
+   the underlying block cipher.  The proof of security is available in
+   [GCMP].
+
+   The most important security consideration is that the IV never
+   repeats for a given key.  In part, this is handled by disallowing the
+   use of AES-GMAC when using statically configured keys, as discussed
+   in Section 2.
+
+   When IKE is used to establish fresh keys between two peer entities,
+   separate keys are established for the two traffic flows.  If a
+   different mechanism is used to establish fresh keys, one that
+   establishes only a single key to protect packets, then there is a
+   high probability that the peers will select the same IV values for
+   some packets.  Thus, to avoid counter block collisions, ESP or AH
+   implementations that permit use of the same key for protecting
+   packets with the same peer MUST ensure that the two peers assign
+   different salt values to the security association (SA).
+
+   The other consideration is that, as with any block cipher mode of
+   operation, the security of all data protected under a given security
+   association decreases slightly with each message.
+
+
+
+
+
+McGrew & Viega              Standards Track                    [Page 10]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+   To protect against this problem, implementations MUST generate a
+   fresh key before processing 2^64 blocks of data with a given key.
+   Note that it is impossible to reach this limit when using 32-bit
+   Sequence Numbers.
+
+   Note that, for each message, GMAC calls the block cipher only once.
+
+8.  Design Rationale
+
+   This specification was designed to be as similar to AES-GCM-ESP
+   [RFC4106] as possible.  We re-use the design and implementation
+   experience from that specification.  We include all three AES key
+   sizes since AES-GCM-ESP supports all of those sizes, and the larger
+   key sizes provide future users with more high-security options.
+
+9.  IANA Considerations
+
+   IANA has assigned the following IKEv2 parameters.  For the use of AES
+   GMAC in AH, the following integrity (type 3) transform identifiers
+   have been assigned:
+
+       "9" for AUTH_AES_128_GMAC
+
+      "10" for AUTH_AES_192_GMAC
+
+      "11" for AUTH_AES_256_GMAC
+
+   For the use of AES-GMAC in ESP, the following encryption (type 1)
+   transform identifier has been assigned:
+
+      "21" for ENCR_NULL_AUTH_AES_GMAC
+
+10.  Acknowledgements
+
+   Our discussions with Fabio Maino and David Black significantly
+   improved this specification, and Tero Kivinen provided us with useful
+   comments.  Steve Kent provided guidance on ESP interactions.  This
+   work is closely modeled after AES-GCM, which itself is closely
+   modeled after Russ Housley's AES-CCM transform [RFC4309].
+   Additionally, the GCM mode of operation was originally conceived as
+   an improvement to the CWC mode [CWC] in which Doug Whiting and Yoshi
+   Kohno participated.  We express our thanks to Fabio, David, Tero,
+   Steve, Russ, Doug, and Yoshi.
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                    [Page 11]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+11.  References
+
+11.1.  Normative References
+
+   [GCM]      McGrew, D. and J. Viega, "The Galois/Counter Mode of
+              Operation (GCM)", Submission to NIST. http://
+              csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/
+              gcm-spec.pdf, January 2004.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3602]  Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
+              Algorithm and Its Use with IPsec", RFC 3602, September
+              2003.
+
+11.2.  Informative References
+
+   [CWC]      Kohno, T., Viega, J., and D. Whiting, "CWC: A high-
+              performance conventional authenticated encryption mode",
+              Fast Software Encryption.
+              http://eprint.iacr.org/2003/106.pdf, February 2004.
+
+   [GCMP]     McGrew, D. and J. Viega, "The Security and Performance of
+              the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT
+              '04, http://eprint.iacr.org/2004/193, December 2004.
+
+   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
+              (IKE)", RFC 2409, November 1998.
+
+   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
+              (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
+              4106, June 2005.
+
+   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
+              2005.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+              4303, December 2005.
+
+   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
+              4306, December 2005.
+
+   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM
+              Mode with IPsec Encapsulating Security Payload (ESP)", RFC
+              4309, December 2005.
+
+
+
+
+
+McGrew & Viega              Standards Track                    [Page 12]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+Authors' Addresses
+
+   David A. McGrew
+   Cisco Systems, Inc.
+   510 McCarthy Blvd.
+   Milpitas, CA  95035
+   US
+
+   Phone: (408) 525 8651
+   EMail: mcgrew@cisco.com
+   URI:   http://www.mindspring.com/~dmcgrew/dam.htm
+
+
+   John Viega
+   McAfee, Inc.
+   1145 Herndon Parkway, Suite 500
+   Herndon, VA 20170
+
+   EMail: viega@list.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                    [Page 13]
+
+RFC 4543                GMAC in IPsec ESP and AH                May 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+McGrew & Viega              Standards Track                    [Page 14]
+