[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 RFC 5282

Individual Submission                                          D. Black
Internet Draft                                                      EMC
Intended status: Proposed Standard                            D. McGrew
Expires: July 2008                                        Cisco Systems
Updates: 4306                                         February 15, 2008


   Using Authenticated Encryption Algorithms with the Encrypted Payload
          of the Internet Key Exchange version 2 (IKEv2) Protocol

               draft-black-ipsec-ikev2-aead-modes-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 July 30, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).





Abstract



Black & McGrew        Expires August 15, 2008                  [Page 1]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


   An authenticated encryption algorithm combines encryption and
   integrity into a single operation; such algorithms may also be
   referred to as combined modes of an encryption cipher or as combined
   mode algorithms.  This document describes the use of authenticated
   encryption algorithms with the Encrypted Payload of the Internet Key
   Exchange version 2 (IKEv2) protocol.

   The use of two specific authenticated encryption algorithms with the
   IKEv2 Encrypted Payload is also described; these two algorithms are
   the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES
   GCM) and AES in Counter with CBC-MAC Mode (AES CCM).  Additional
   documents may describe use of other authenticated encryption
   algorithms with the IKEv2 Encrypted Payload.

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].

   The symbols or variables that designate authenticated encryption and
   decryption operation inputs and outputs (K, N, P, A, and C) are the
   same as used in [RFC5116].

Table of Contents

   1. Introduction...................................................3
   2. Structure of this Document.....................................4
   3. IKEv2 Encrypted Payload Data...................................4
      3.1. AES GCM and AES CCM Initialization Vector (IV)............6
      3.2. AES GCM and AES CCM Ciphertext (C) Construction...........7
   4. AES GCM and AES CCM Nonce (N) Format...........................7
   5. Associated Data (A)............................................7
      5.1. Associated Data (A) Construction..........................8
      5.2. Data Integrity Coverage...................................8
   6. AES GCM and AES CCM Encrypted Payload Expansion................9
   7. IKEv2 Conventions for AES GCM and AES CCM......................9
      7.1. Keying Material and Salt Values...........................9
      7.2. IKEv2 Identifiers........................................10
      7.3. Key Length...............................................10
   8. Algorithm Selection...........................................10
   9. Test Vectors..................................................11
   10. Security Considerations......................................11
   11. IANA Considerations..........................................11
   12. Acknowledgments..............................................11
   13. References...................................................12
      13.1. Normative References....................................12


Black & McGrew         Expires August 15, 2008                 [Page 2]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


      13.2. Informative References..................................12
   Author's Addresses...............................................13
   Intellectual Property Statement..................................13
   Disclaimer of Validity...........................................13

1. Introduction

   An authenticated encryption algorithm [RFC5116] combines encryption
   and integrity into a single operation on plaintext data to produce
   ciphertext that includes an integrity check.  The integrity check may
   be an Integrity Check Value (ICV) that is logically distinct from the
   encrypted data or the integrity check may be incorporated into the
   encrypted data that is produced.  Authenticated encryption algorithms
   may also be referred to as combined modes of operation of a block
   cipher or as combined mode algorithms. An authenticated encryption
   with associated data (AEAD) algorithm also provides integrity
   protection for additional data that is associated with the plaintext,
   but which is left unencrypted.

   This document describes the use of authenticated encryption
   algorithms with the Encrypted Payload of the Internet Key Exchange
   version 2 (IKEv2) protocol.  The use of two specific authenticated
   encryption algorithms with the IKEv2 Encrypted Payload is also
   described; the two algorithms are the Advanced Encryption Standard
   (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-
   MAC Mode (AES CCM).

   Version 1 of the Internet Key Exchange protocol (IKEv1) [RFC2409] is
   based on the Internet Security Association and Key Management
   Protocol (ISAKMP) [RFC2408].  The E (Encryption) bit in the ISAKMP
   header specifies that all payloads following the header are
   encrypted, but any data integrity verification of those payloads is
   handled by a separate Hash Payload or Signature Payload (see sections
   3.1, 3.11 and 3.12 of [RFC2408]).  This separation of encryption from
   data integrity protection prevents use of authenticated encryption
   with IKEv1, thus limiting initial specifications of AES combined mode
   usage for IPsec to the Encapsulating Security Payload (ESP)
   [RFC2406].  The current version of ESP is version 2, ESPv2 [RFC4303].

   Version 2 of the Internet Key Exchange Protocol (IKEv2) [RFC4306]
   employs an Encrypted Payload that is based on the design of ESP.  The
   IKEv2 Encrypted Payload associates encryption and data integrity
   protection in a fashion that makes it possible to use authenticated
   encryption algorithms.





Black & McGrew         Expires August 15, 2008                 [Page 3]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


2. Structure of this Document

   This document is based on the RFCs that describe the usage of AES GCM
   [RFC4106] and AES CCM [RFC4309] with ESP, and hence the introductory
   material and specification of the modes in those documents are not
   repeated here.  The structure of this document follows the structure
   of those documents; each section of this document indicates which
   section of those two documents it corresponds to and calls out any
   significant changes of which implementers should be aware.
   Significant portions of the text of this document have been adapted
   from those two documents.

   This document is based on the authenticated encryption interfaces,
   notation and terminology described in [RFC5116].  An important
   departure from [RFC4106] and [RFC4309] is that these two RFCs
   describe separate ciphertext and integrity check outputs of the
   encryption operation, whereas [RFC5116] specifies a single Ciphertext
   (C) output that includes an integrity check.  The latter more general
   approach encompasses authenticated encryption algorithms that produce
   a single expanded ciphertext output into which the integrity check is
   incorporated, rather than producing separate ciphertext and integrity
   check outputs.

   For AES GCM and AES CCM, the [RFC5116] Ciphertext (C) output of
   encryption consists of the [RFC4106] or [RFC4309] ciphertext output
   concatenated with the [RFC4106] or [RFC4309] Integrity Check Value
   (ICV) output.  This document does not modify the AES GCM and AES CCM
   authenticated encryption algorithms.

3. IKEv2 Encrypted Payload Data

   This section is based on [RFC5116] and Section 3.14 of [RFC4306].

   For use of authenticated encryption algorithms with the IKEv2
   Encrypted Payload, this section updates [RFC4306] to replace Figure
   21 in Section 3.14 and the text that follows it through the end of
   that section with the contents of this section.  In addition Section
   3.14 of [RFC4306] is also updated to allow use of a single
   authenticated encryption algorithm instead of a block cipher and a
   separate integrity check algorithm.  In contrast, Sections 3.1 and
   3.2 of this document are specific to the AES GCM and AES CCM
   algorithms and hence do not update [RFC4306].

   The IKEv2 Encrypted Payload Data structure applies to all
   authenticated encryption algorithms, and it is the same structure
   that is used with ESP.  When an authenticated encryption algorithm is
   used, the IKEv2 Encrypted Payload is composed of the payload header


Black & McGrew         Expires August 15, 2008                 [Page 4]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


   fields, followed by an Initialization Vector (IV) field and
   Ciphertext (C) field that includes an integrity check as shown in
   Figure 1.


                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Next Payload  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                     Initialization Vector                     !
      !  (length is specified by authenticated encryption algorithm)  !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        Ciphertext                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Figure 1. IKEv2 Encrypted Payload Data for Authenticated Encryption

   The Next Payload field, C bit and Payload length fields are unchanged
   from [RFC4306].

   The contents of the Initialization Vector (IV) field are specified by
   the authenticated encryption algorithm; see Section 3.1 (below) for
   AES GCM and AES CCM. When decrypting an Encrypted Payload, a receiver
   constructs the nonce based on the IV from that data structure, using
   rules that are specific to the AEAD algorithm.

   The Ciphertext field is the output of an authenticated encryption
   operation (see Section 2.1 of [RFC5116]) on the following inputs:

   o  The secret key (K) is the cipher key obtained from the SK_ei or
      SK_er key, whichever is appropriate, see [RFC4306].  The
      authenticated encryption algorithm describes how to obtain the
      cipher key from SK_ei or SK_er; for AES GCM and AES CCM, see
      Section 7.1 (below).

   o  The nonce (N) is specified by the authenticated encryption
      algorithm; for AES GCM and AES CCM, see Section 4 (below).

   o  The plaintext (P) consists of the concatenation of the IKE
      Payloads to be encrypted with the Padding (if any) and the Pad
      Length, as shown in Figure 2 (below).

   o  The associated data (A) is described in Section 5 (below).




Black & McGrew         Expires August 15, 2008                 [Page 5]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


   Recall that the Ciphertext utput of AEAD algorithms, as defined by
   [RFC5116], incorporates data that allows for checks on the integrity
   and authenticity of the Ciphertext and associated data check data.
   Thus, there is no need for a separate Integrity Check Value (ICV)
   field in the IKEv2 Encrypted Payload Data structure.

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                 IKE Payloads to be Encrypted                  ~
      +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !               !             Padding (0-255 octets)            !
      +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
      !                                               !  Pad Length   !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


            Figure 2. IKEv2 Encrypted Payload Plaintext (P) for
                         Authenticated Encryption

   The IKE Payloads are as specified in [RFC4306].

   Padding MAY contain any value chosen by the sender.

   Pad Length is the number of octets in the Padding field.

   The length of the Padding field MUST be chosen so that the number of
   octets in the Encrypted Payload is a multiple of four, in order to
   satisfy IKEv2 data alignment needs.   The sender SHOULD set the Pad
   Length to the minimum value that makes the combination of the
   Payloads, the Padding, and the Pad Length fields a multiple of four
   octets in length, but the recipient MUST accept any length that
   results in proper alignment.

3.1. AES GCM and AES CCM Initialization Vector (IV)

   This section is based on Section 3.1 of [RFC4106] and Section 3.1 of
   [RFC4309].  The Initialization Vector requirements are common to AES
   GCM and AES CCM, and are the same as the requirements for ESP.

   The Initialization Vector (IV) MUST be eight octets, the AES block
   size.  The IV MUST be chosen by the encryptor in a manner that
   ensures that the same IV value is used only once for a given key.
   The encryptor can generate the IV in any manner that ensures
   uniqueness.  Common approaches to IV generation include incrementing
   a counter for each packet and linear feedback shift registers
   (LFSRs).


Black & McGrew         Expires August 15, 2008                 [Page 6]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


3.2. AES GCM and AES CCM Ciphertext (C) Construction

   This section is based on Section 6 of [RFC4106] and Section 3.1 of
   [RFC4309] with generalizations to match the interfaces specified in
   [RFC5116].  The constructions for AES GCM and AES CCM are different,
   but in each case, the construction is the same as used for ESP.

   For AES GCM and AES CCM, the Ciphertext field consists of the output
   of the AEAD encryption algorithm.  (Note that this field incorporates
   integrity-check data.)

   The AES GCM ICV consists solely of the AES GCM Authentication Tag.
   Implementations MUST support a full-length 16-octet ICV, MAY support
   8 or 12 octet ICVs, and MUST NOT support other ICV lengths.

   AES CCM provides an encrypted ICV.  Implementations MUST support ICV
   sizes of 8 octets and 16 octets. Implementations MAY also support 12
   octet ICVs and MUST NOT support other ICV lengths.

4. AES GCM and AES CCM Nonce (N) Format

   Specific AEAD algorithms MAY use different nonce formats, though they
   SHOULD use the following format, which is intended to be the default.
   With this format, the nonces are partially implicit, see Section
   3.2.1 of [RFC5116].  The implicit portion of the nonce is the salt;
   the salt is not included in the IKEv2 Encrypted Payload.  The
   explicit portion of the nonce is the IV that is included in the IKEv2
   Encrypted Payload.

   For use of AES GCM with the IKEv2 Encrypted Payload, the default
   nonce format MUST be used.  Note that this format matches the one
   specified in Section 4 of [RFC4106], which ensures compatibility
   between the use of AES GCM in IKEv2 and ESP.  All of the requirements
   of Section 4 of [RFC4106] apply to use of AES GCM with the IKEv2
   Encrypted Payload.

   For use of AES CCM with the IKEv2 Encrypted Payload, the nonce format
   MUST be the format specified in Section 4 of [RFC4309].  All of the
   requirements of Section 4 of [RFC4309] apply to use of AES CCM with
   the IKEv2 Encrypted Payload.

5. Associated Data (A)

   This section is based on Section 3.1 of [RFC4106] and Section 3.1 of
   [RFC4309], both of which refer to associated data as Additional
   Authenticated Data (AAD).  The associated data construction described
   in this section applies to all authenticated encryption algorithms,


Black & McGrew         Expires August 15, 2008                 [Page 7]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


   but differs from the construction used with ESP because IKEv2
   requires different data integrity coverage.

5.1. Associated Data (A) Construction

   The associated data (A) MUST consist of the partial contents of the
   IKEv2 message starting from the first octet of the Fixed IKE Header
   through the last octet of the Payload Header of the Encrypted Payload
   (i.e., the fourth octet of the Encrypted Payload), as shown in Figure
   3.  This includes any Payloads that are between the Fixed IKE Header
   and the Encrypted Payload.

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                         IKEv2 Header                          ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                   Unencrypted IKE Payloads                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Next Payload  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 3. IKEv2 Encrypted Payload Data for Combined Modes

   The Initialization Vector and Ciphertext fields shown in Figure 1
   (above) MUST NOT be included in the associated data.

5.2. Data Integrity Coverage

   The data integrity coverage of the IKEv2 Encrypted Payload
   encompasses the entire IKEv2 message that contains the Encrypted
   Payload.  When an authenticated encryption algorithm is used with the
   Encrypted Payload, this coverage is realized as follows:

   1. The associated data (A) covers the portion of the IKEv2 message
      starting from the first octet of the Fixed IKE Header through the
      last octet of the Payload Header of the Encrypted Payload (fourth
      octet of the Encrypted Payload).  This includes any Payloads
      between the Fixed IKE Header and the Encrypted Payload.  The
      Encrypted Payload is always the last payload in an IKEv2 message
      [RFC4306].

   2. The IV is an input to the authenticated encryption algorithm's
      integrity check.  A successful integrity check at the receiver
      verifies that the correct IV was used, providing data integrity
      coverage for the IV.



Black & McGrew         Expires August 15, 2008                 [Page 8]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


   3. The plaintext (IKE Payloads, Padding and Pad Length) is covered by
      the authenticated encryption algorithm's integrity check.

6. AES GCM and AES CCM Encrypted Payload Expansion

   The expansion described in Section 7 of [RFC4106] and Section 6 of
   [RFC4309] applies to use of the AES GCM and AES CCM combined modes
   with the IKEv2 Encrypted Payload.  See Section 7 of [RFC4106] and
   Section 6 of [RFC4309].

7. IKEv2 Conventions for AES GCM and AES CCM

   This section describes the conventions used to generate keying
   material and salt values for use with AES GCM and AES CCM using the
   IKEv2 [RFC4306] protocol.  The identifiers and attributes needed to
   use AES GCM and AES CCM with the IKEv2 Encrypted Payload are also
   specified.

7.1. Keying Material and Salt Values

   This section is based on Section 8.1 of [RFC4106] and Section 7.1 of
   [RFC4309].  The Keying Material and Salt Values for AES GCM and AES
   CCM are different, but have the same structure as the Keying Material
   and Salt Values used with ESP.

   IKEv2 makes use of a pseudo-random function (PRF) to derive keying
   material.  The PRF is used iteratively to derive keying material of
   arbitrary size, from which keying material for specific uses is
   extracted without regard to PRF output boundaries, see Section 2.14
   of [RFC4306].

   This subsection describes how the key derivation specified in Section
   2.14 of [RFC4306] is used to obtain keying material for AES GCM and
   AES CCM.  When AES GCM or AES CCM is used with the IKEv2 Encrypted
   Payload, the SK_ai and SK_ar integrity protection keys are not used;
   each key MUST be treated as having a size of zero (0) octets.  The
   size of each of the SK_ei and SK_er encryption keys includes
   additional salt bytes.  The size and format of each of the SK_ei and
   SK_er encryption keys MUST be:

   o  For AES GCM, each encryption key has the size and format of the
      "KEYMAT requested" material specified in Section 8.1 of [RFC4106]
      for the AES key size being used.  For example, if the AES key size
      is 128 bits, each encryption key is 20 octets, consisting of a 16
      octet AES cipher key followed by 4 octets of salt.




Black & McGrew         Expires August 15, 2008                 [Page 9]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


   o  For AES CCM, each key has the size and format of the "KEYMAT
      requested" material specified in Section 7.1 of [RFC4309] for the
      AES key size being used.  For example, if the AES key size is 128
      bits, each encryption key is 19 octets, consisting of a 16 octet
      AES cipher key followed by 3 octets of salt.

7.2. IKEv2 Identifiers

   This section is unique to IKEv2 Encrypted Payload usage of AES GCM
   and AES CCM.  It reuses the identifiers used to negotiate ESP usage
   of AES GCM and AES CCM.

   The following identifiers previously allocated by IANA are used to
   negotiate use of AES GCM and AES CCM as the Encryption (ENCR)
   Transform for IKEv2 (i.e., for use with the IKEv2 Encrypted Payload):


         16 for AES CCM with a 16-octet ICV; and
         20 for AES GCM with a 16 octet ICV.

   The identifiers 14, 15, 18, and 19 MUST NOT be used.  These
   identifiers are associated with transforms with shorter ICVs.

7.3. Key Length

   This section is based on Section 8.4 of [RFC4106] and Section 7.4 of
   [RFC4309].  The Key Length requirements are common to AES GCM and AES
   CCM and are identical to the key length requirements for ESP.

   Because the AES supports three key lengths, the Key Length attribute
   MUST be specified when any of the identifiers for AES GCM or AES CCM
   specified in Section 7.2 of this document is used.  The Key Length
   attribute MUST have a value of 128 or 256.

8. Algorithm Selection

   This section applies to the use of any authenticated encryption
   algorithm with the IKEv2 Encrypted Payload and is unique to that
   usage.

   IKEv2 (section 3.3.3 of [RFC4306]) specifies that both an encryption
   algorithm and an integrity checking algorithm are required for an IKE
   SA (Security Association). This document updates [RFC4306] by
   qualifying that statement to say that when an authenticated
   encryption algorithm is selected as the encryption algorithm for any
   SA (IKE or ESP), an integrity algorithm MUST NOT be selected for that
   SA.  This document further updates [RFC4306] to require that if all


Black & McGrew         Expires August 15, 2008                [Page 10]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


   of the encryption algorithms in any proposal are authenticated
   encryption algorithms, then the proposal MUST NOT propose any
   integrity transforms.

9. Test Vectors

   See Section 9 of [RFC4106] and Section 8 of [RFC4309] for references
   that provide AES GCM and AES CCM test vectors.

10. Security Considerations

   For authenticated encryption security considerations, see [RFC5116];
   there are important security considerations that are discussed
   outside the security considerations section of that document.

   The security considerations for use of AES GCM and AES CCM with ESP
   apply to use of these algorithms with the IKEv2 Encrypted Payload,
   see Section 10 of [RFC4106] and Section 9 of [RFC4309].  Use of AES
   GCM and AES CCM with IKEv2 does not create additional security
   considerations beyond those for use of AES GCM and AES CCM with ESP.

   For IKEv2 security considerations, see Section 5 of [RFC4306].

11. IANA Considerations

   This document has no actions for IANA.

   The Encryption Transform identifiers specified in Section 7.2 have
   been previously assigned by IANA for use with ESP.  This document
   extends their usage to IKEv2 for the Encrypted Payload.

12. Acknowledgments

   See Section 13 of [RFC4106] and Section 12 of [RFC4309] for AES GCM
   and AES CCM acknowledgments.

   Also, we thank Charlie Kaufman, Pasi Eronen, and Tero Kivinen for
   their comprehensive reviews of this document.

   This document was prepared using 2-Word-v2.0.template.dot, created by
   Joe Touch.








Black & McGrew         Expires August 15, 2008                [Page 11]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


13. References

13.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
             (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
             4106, June 2005.

   [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
             4303, December 2005.

   [RFC4306] Kaufman, C. (Editor), "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.

   [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
             Encryption", RFC 5116, to appear.

13.2. Informative References

   [RFC2406] Kent, S. and Atkinson, R., "IP Encapsulating Security
             Payload (ESP)", RFC 2406, November 1998.

   [RFC2408] Maughan, D., M. Schertler, M. Schneider and J. Turner, "
             Internet Security Association and Key Management Protocol
             (ISAKMP)", RFC 2408, November 1998.

   [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.














Black & McGrew         Expires August 15, 2008                [Page 12]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


Author's Addresses

   David L. Black
   EMC Corporation
   176 South Street
   Hopkinton, MA 10748

   Phone: +1 (508) 293-7953
   Email: black_david@emc.com

   David A. McGrew
   Cisco Systems, Inc.
   510 McCarthy Blvd.
   Milpitas, CA 95035


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, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF


Black & McGrew         Expires August 15, 2008                [Page 13]

Internet-Draft    Authenticated Encryption and IKEv2      February 2008


   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 IETF Trust (2008).

   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.


































Black & McGrew         Expires August 15, 2008                [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/