Network Working Group D. McGrew
Internet-Draft Cisco Systems, Inc.
Expires: April 24, 2006 J. Viega
Secure Software, Inc.
October 21, 2005
The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
draft-mcgrew-aes-gmac-esp-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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
McGrew & Viega Expires April 24, 2006 [Page 1]
Internet-Draft GMAC ESP October 2005
implementations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 History . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Conventions Used In This Document . . . . . . . . . . . . 3
2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. AES GMAC-ESP . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Authentication Initialization Vector . . . . . . . . . . . 5
3.2 Nonce Format . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 AAD Construction . . . . . . . . . . . . . . . . . . . . . 6
3.4 Integrity Check Value (ICV) . . . . . . . . . . . . . . . 7
3.5 Differences with AES-GCM-ESP . . . . . . . . . . . . . . . 7
3.6 Packet Expansion . . . . . . . . . . . . . . . . . . . . . 8
4. AES-GMAC AH . . . . . . . . . . . . . . . . . . . . . . . . 9
5. IKE Conventions . . . . . . . . . . . . . . . . . . . . . . 10
5.1 Keying Material and Salt Values . . . . . . . . . . . . . 10
5.2 Phase 1 Identifier . . . . . . . . . . . . . . . . . . . . 10
5.3 Phase 2 Identifier . . . . . . . . . . . . . . . . . . . . 10
5.4 Key Length Attribute . . . . . . . . . . . . . . . . . . . 11
6. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . 13
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1 Normative References . . . . . . . . . . . . . . . . . . 17
11.2 Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . 19
McGrew & Viega Expires April 24, 2006 [Page 2]
Internet-Draft GMAC ESP October 2005
1. Introduction
This document describes the use of AES GMAC mode (AES-GMAC) as an
mechanism for data origin authentication in IPSec ESP [RFC2406] and
AH [RFC2402]. We refer to these methods as AES-GMAC-ESP and AES-
GMAC-AH, respectively. AES-GMAC-ESP is a companion to the AES
Galois/Counter Mode ESP [GCM-ESP], which provides authentication as
well as confidentiality. AES-GMAC-ESP 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.
AES-GMAC-ESP and AES-GMAC-AH 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.
1.1 History
The original version of this document only described AES-GMAC-ESP,
and not AES-GMAC-AH. This version adds support for AH, without
making any changes to the normative ESP text (other than editorial
ones), except for a clarification about transform identifiers and the
IKE Key Length attribute.
1.2 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].
McGrew & Viega Expires April 24, 2006 [Page 3]
Internet-Draft GMAC ESP October 2005
2. AES-GCM
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 an
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 safety's sake,
implementations MUST use an automated key management system, such as
the Internet Key Exchange (IKE) [RFC2409], to ensure that this
requirement is met.
McGrew & Viega Expires April 24, 2006 [Page 4]
Internet-Draft GMAC ESP October 2005
3. AES GMAC-ESP
The ESP Payload Data is comprised of an eight-octet Authentication
Initialization Vector (IV) followed by the Authenticated Payload.
The payload field, as defined in [RFC2406], is structured as shown in
Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Initialization Vector |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticated Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The AES-GMAC ESP Payload, when no encryption is used.
The Authenticated Payload field consists of the ESP Payload field as
defined by the encryption transform. When AES-GMAC-ESP is used in
the absence of encryption, that is, with NULL encryption [RFC2410],
then the Authenticated Payload contains the data described by the ESP
Next Header field. When AES-GMAC-ESP is used in the presence of an
ESP encryption transform that uses an IV, the encryption IV appears
within the Authenticated Payload.
Rationale: In ESP encryption takes place before authentication on
the sender side, and authentication takes place first on the
receiver side. Because of this ordering, the Authentication IV
precedes the encryption IV.
3.1 Authentication Initialization Vector
The Authentication IV field MUST be eight octets. 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:
McGrew & Viega Expires April 24, 2006 [Page 5]
Internet-Draft GMAC ESP October 2005
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 2: 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.1.
Initialization Vector
The IV field is described in Section Section 3.1.
3.3 AAD Construction
Data integrity and data origin authentication is 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 3, and the format with 64-bit
extended sequence numbers is shown in Figure 4.
McGrew & Viega Expires April 24, 2006 [Page 6]
Internet-Draft GMAC ESP October 2005
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 3: 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 4: AAD Format with 64-bit Extended Sequence Number
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
McGrew & Viega Expires April 24, 2006 [Page 7]
Internet-Draft GMAC ESP October 2005
specification and AES-GCM-ESP. The essential difference is that in
this draft, 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 5. 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, AES-GMAC-ESP is *not* equivalent to AES-GCM-ESP with
encryption "turned off". However, the computations performed in both
cases are very nearly identical, because of the structure of the
GHASH function [GCM] that is used to compute the ICVs. The only
place where these computations differ is in the final GF(2^128)
multiplication, where the lengths of the Plaintext and AAD inputs are
taken into account.
+-> +-----------------------+ <-+
AES-GCM-ESP | | SPI | |
AAD -------+ +-----------------------+ |
| | Sequence Number | | AES-GMAC-ESP
+-> +-----------------------+ |
| Authentication | |
| IV | |
+->+-> +-----------------------+ +---- AAD
AES-GCM-ESP | | | |
Plaintext -+ ~ ESP Payload ~ |
| | | |
| +-----------+-----+-----+ |
| | Padding | PL | NH | |
+----> +-----------+-----+-----+ <-+
Figure 5: Differences between AES-GMAC-ESP 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), and any expansion due to the ESP
encryption transform.
McGrew & Viega Expires April 24, 2006 [Page 8]
Internet-Draft GMAC ESP October 2005
4. AES-GMAC AH
In AES-GMAC-AH, the AH Authentication Data field consists of the
Authentication IV and and the Authentication Tag, as shown in
Figure 6. 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Initialization Vector |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Check Value (ICV) (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The AES-GMAC-AH Authentication Data format.
Authentication IV is as described in Section Section 3.1. The
Integrity Check Value (ICV) is as described in Section 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 [RFC2402]. 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.
McGrew & Viega Expires April 24, 2006 [Page 9]
Internet-Draft GMAC ESP October 2005
5. IKE Conventions
This section describes the conventions used to generate keying
material and salt values for use with AES-GMAC-ESP and AES-GMAC-AH
using the Internet Key Exchange (IKE) [RFC2409].
5.1 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 AES-GMAC-ESP and AES-GMAC-AH MUST be
four octets longer than is needed for the associated AES key. The
keying material is used as follows:
AES-GMAC-ESP and AES-GMAC-AH with a 128 bit key
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.
AES-GMAC-ESP and AES-GMAC-AH with a 192 bit key
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.
AES-GMAC-ESP and AES-GMAC-AH with a 256 bit key
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.
5.2 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 is needed, and an Encryption Algorithm
Identifier needs to be assigned. Implementations SHOULD use an IKE
Phase 1 cipher which is at least as strong as AES-GMAC. The use of
AES CBC [RFC3602] with the same key size as used by AES-GMAC-ESP or
AES-GMAC-AH is RECOMMENDED.
5.3 Phase 2 Identifier
For IKE Phase 2 negotiations, IANA has assigned identifiers as
described in Section 9.
McGrew & Viega Expires April 24, 2006 [Page 10]
Internet-Draft GMAC ESP October 2005
5.4 Key Length Attribute
AES-GMAC can be used with any of the three AES key lengths. Each key
length has its own separate transform identifier and authentication
algorithm value (Section 9). The IKE Key Length attribute MUST NOT
be used to indicate AES-GMAC key lengths.
Rationale: the AES-GMAC key length is indicated by the transform
identifier, so the use of the Key Length attribute is redundant.
Omitting that attribute avoids potential confusion, since an IKE
peer might mistakenly assume that the key attribute applied to an
encryption transform.
McGrew & Viega Expires April 24, 2006 [Page 11]
Internet-Draft GMAC ESP October 2005
6. Test Vectors
Appendix B of [GCM] provides test vectors that will assist
implementers with AES-GMAC.
McGrew & Viega Expires April 24, 2006 [Page 12]
Internet-Draft GMAC ESP October 2005
7. Security Considerations
In AES-GMAC-ESP, the Authentication IV is not included in either the
plaintext nor the additional authenticated data. This does not
affect security, because the IV field only provides an input to the
GMAC IV, which is not required to be authenticated (see [GCM]). In
AES-GMAC-AH, the Authentication IV is included in the additional
authenticated data; this fact has no effect on security.
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 repeat
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.
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.
McGrew & Viega Expires April 24, 2006 [Page 13]
Internet-Draft GMAC ESP October 2005
8. Design Rationale
This specification was designed to be as similar to AES-GCM-ESP [GCM-
ESP] 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.
McGrew & Viega Expires April 24, 2006 [Page 14]
Internet-Draft GMAC ESP October 2005
9. IANA Considerations
IANA has assigned the following AH Transform Identifiers to
AES-GMAC-AH:
"TBD1" for AES-128 GMAC
"TBD2" for AES-192 GMAC
"TBD3" for AES-256 GMAC
IANA has assigned the following AH/ESP Authentication Algorithm
Values for AES-GMAC-AH/AES-GMAC-ESP:
"TBD1" for AES-128 GMAC
"TBD2" for AES-192 GMAC
"TBD3" for AES-256 GMAC
McGrew & Viega Expires April 24, 2006 [Page 15]
Internet-Draft GMAC ESP October 2005
10. Acknowledgements
Our discussions with Fabio Maino and David Black significantly
improved this specification, and Tero Kivinen provided us with useful
comments. This work is closely modeled after AES-GCM, which itself
is closely modeled after Russ Housley's AES-CCM transform [CCM-ESP].
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, Ted,
Russ, Doug, and Yoshi.
McGrew & Viega Expires April 24, 2006 [Page 16]
Internet-Draft GMAC ESP October 2005
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.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[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
[CCM-ESP] Housley, R., "Using AES CCM Mode With IPsec ESP", Work In
Progress. <draft-ietf-ipsec-ciph-aes-ccm-05.txt>.
[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.
[GCM-ESP] Viega, J. and D. McGrew, "The Use of AES GCM in IPsec
ESP", Work In
Progress. <draft-ietf-ipsec-ciph-aes-gcm-01.txt>.
[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.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
McGrew & Viega Expires April 24, 2006 [Page 17]
Internet-Draft GMAC ESP October 2005
Its Use With IPsec", RFC 2410, November 1998.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
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
Secure Software, Inc.
4100 Lafayette Center Dr., Suite 100
Chantilly, VA 20151
US
Phone: (703) 814 4402
Email: viega@securesoftware.com
McGrew & Viega Expires April 24, 2006 [Page 18]
Internet-Draft GMAC ESP October 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
McGrew & Viega Expires April 24, 2006 [Page 19]
