Network Working Group D. McGrew
Internet-Draft Cisco Systems, Inc.
Expires: September 2, 2005 J. Viega
Secure Software, Inc.
March 2005
The Use of Galois Message Authentication Code (GMAC) in IPsec ESP
draft-mcgrew-aes-gmac-esp-00.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 September 2, 2005.
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 an IPsec Encapsulating
Security Payload (ESP) mechanism to provide data origin
authentication, but not confidentiality. 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 Expires September 2, 2005 [Page 1]
Internet-Draft GMAC ESP March 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions Used In This Document . . . . . . . . . . . . 3
2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ESP Payload Data . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Initialization Vector (IV) . . . . . . . . . . . . . . . . 5
4. Nonce Format . . . . . . . . . . . . . . . . . . . . . . . . 6
5. AAD Construction . . . . . . . . . . . . . . . . . . . . . . 7
6. Integrity Check Value (ICV) . . . . . . . . . . . . . . . . 8
7. Differences with AES-GCM-ESP . . . . . . . . . . . . . . . . 9
8. Packet Expansion . . . . . . . . . . . . . . . . . . . . . . 10
9. IKE Conventions . . . . . . . . . . . . . . . . . . . . . . 11
9.1 Keying Material and Salt Values . . . . . . . . . . . . . 11
9.2 Phase 1 Identifier . . . . . . . . . . . . . . . . . . . . 11
9.3 Phase 2 Identifier . . . . . . . . . . . . . . . . . . . . 11
9.4 Key Length Attribute . . . . . . . . . . . . . . . . . . . 12
10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . 14
12. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 15
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
15.1 Normative References . . . . . . . . . . . . . . . . . . 18
15.2 Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20
McGrew & Viega Expires September 2, 2005 [Page 2]
Internet-Draft GMAC ESP March 2005
1. Introduction
This document describes the use of AES GMAC mode (AES-GMAC) as an
IPSec ESP mechanism for data origin authentication. We refer to this
method as AES-GMAC-ESP. It 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 is designed so that the incremental cost of implementing
it, 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 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 September 2, 2005 [Page 3]
Internet-Draft GMAC ESP March 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 fields,
and how the ESP packet is formed from the plaintext and
authentication tag.
ESP also defines an IV. For clarity, we refer to the AES-GMAC IV as
a nonce in the context of AES-GMAC-ESP. 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 mode, it can be difficult to use this mode
securely when using statically configured keys. For safety's sake,
implementations MUST use an automated key mangement system, such as
the Internet Key Exchange (IKE) [RFC2409], to ensure that this
requirement is met.
McGrew & Viega Expires September 2, 2005 [Page 4]
Internet-Draft GMAC ESP March 2005
3. ESP Payload Data
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
preceeds the encryption IV.
3.1 Initialization Vector (IV)
The AES-GMAC-ESP 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.
McGrew & Viega Expires September 2, 2005 [Page 5]
Internet-Draft GMAC ESP March 2005
4. Nonce Format
The nonce passed to the AES-GMAC authentiation 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 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 9.1.
Initialization Vector
The IV field is described in section Section 3.1.
McGrew & Viega Expires September 2, 2005 [Page 6]
Internet-Draft GMAC ESP March 2005
5. 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.
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
McGrew & Viega Expires September 2, 2005 [Page 7]
Internet-Draft GMAC ESP March 2005
6. 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.
McGrew & Viega Expires September 2, 2005 [Page 8]
Internet-Draft GMAC ESP March 2005
7. Differences with AES-GCM-ESP
In this section we highlight the differences between this
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.
+-> +-----------------------+ <-+
AES-GCM-ESP | | SPI | |
AAD -------+ +-----------------------+ |
| | Sequence Number | | AES-GMAC-ESP
+->+-> +-----------------------+ +---- AAD
AES-GCM-ESP | | | |
Plaintext -+ ~ ESP Payload ~ |
| | | |
| +-----------+-----+-----+ |
| | Padding | PL | NH | |
+----> +-----------+-----+-----+ <-+
Figure 5: Differences between AES-GMAC-ESP and AES-GCM-ESP.
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.
McGrew & Viega Expires September 2, 2005 [Page 9]
Internet-Draft GMAC ESP March 2005
8. 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 September 2, 2005 [Page 10]
Internet-Draft GMAC ESP March 2005
9. IKE Conventions
This section describes the conventions used to generate keying
material and salt values for use with AES-GMAC-ESP using the Internet
Key Exchange (IKE) [RFC2409] protocol. The identifiers and
attributes needed to negotiate a security association using AES-GMAC-
ESP are also defined.
9.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 MUST be four octets
longer than is needed for the associated AES key. The keying
material is used as follows:
AES-GMAC-ESP 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 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 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.
9.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 is
RECOMMENDED.
9.3 Phase 2 Identifier
For IKE Phase 2 negotiations, IANA has assigned <TBD> as the ESP
McGrew & Viega Expires September 2, 2005 [Page 11]
Internet-Draft GMAC ESP March 2005
Transform Identifier for AES-GMAC with an eight-byte explicit IV.
9.4 Key Length Attribute
Since the AES supports three key lengths, the Key Length attribute
MUST be specified in the IKE Phase 2 exchange [RFC2407]. The Key
Length attribute MUST have a value of 128, 192 or 256.
McGrew & Viega Expires September 2, 2005 [Page 12]
Internet-Draft GMAC ESP March 2005
10. Test Vectors
Appendix B of [GCM] provides test vectors that will assist
implementers with AES-GMAC.
McGrew & Viega Expires September 2, 2005 [Page 13]
Internet-Draft GMAC ESP March 2005
11. Security Considerations
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
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 September 2, 2005 [Page 14]
Internet-Draft GMAC ESP March 2005
12. Design Rationale
This specification was designed to be as similar to the AES-GCM ESP
[GCM-ESP] as possible. We re-use the design and implementation
experience from that specification.
McGrew & Viega Expires September 2, 2005 [Page 15]
Internet-Draft GMAC ESP March 2005
13. IANA Considerations
IANA has assigned three ESP transform numbers for use with AES GMAC:
"TBD1" for AES-128 GMAC, "TBD2" for AES-192 GMAC, "TBD3" for AES-256
GMAC.
McGrew & Viega Expires September 2, 2005 [Page 16]
Internet-Draft GMAC ESP March 2005
14. Acknowledgements
Our discussions with Fabio Maino and David Black significantly
improved this specification. 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 Konoho paricipated; this work provided the
first unencumbered block cipher mode capable of supporting high-speed
authenticated encryption. We express our thanks to Fabio, David,
Russ, Doug, and Yoshi.
McGrew & Viega Expires September 2, 2005 [Page 17]
Internet-Draft GMAC ESP March 2005
15. References
15.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.
[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.
15.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
Its Use With IPsec", RFC 2410, November 1998.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
McGrew & Viega Expires September 2, 2005 [Page 18]
Internet-Draft GMAC ESP March 2005
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 September 2, 2005 [Page 19]
Internet-Draft GMAC ESP March 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 September 2, 2005 [Page 20]
