4.  IKE Documents

4.1.  Base Documents

4.1.1.  IKEv1

   IKE is the preferred key management protocol for IPsec.  It is used
   for peer authentication; to negotiate, modify, and delete SAs; and to
   negotiate authenticated keying material for use within those SAs.
   The standard peer authentication methods used by IKEv1 (pre-shared
   secret keys and digital certificates) had several shortcomings
   related to use of IKEv1 to enable remote user authentication to a
   corporate VPN: it could not leverage the use of legacy authentication
   systems (e.g. RADIUS databases) to authenticate a remote user to a
   security gateway; and it could not be used to configure remote users
   with network addresses or other information needed in order to access
   the internal network.  Automatic key distribution is required for
   IPsec-v2, but alternatives to IKE may be used to satisfy that
   requirement.

   Several Internet Drafts were written to address these problems: two
   such documents include "Extended Authentication within IKE (XAUTH)"
   [IKE-XAUTH] (and its predecessor, "Extended Authentication within
   ISAKMP/Oakley (XAUTH)" [ISAKMP-XAUTH]) and "The ISAKMP Configuration
   Method" [IKE-MODE-CFG] (and its predecessor [ISAKMP-MODE-CFG]).
   These Internet Drafts did not progress to RFC status due to security
   flaws and other problems related to these solutions.  However, many
   current IKEv1 implementations incorporate aspects of these solutions
   to facilitate remote user access to corporate VPNs.  These solutions
   were not standardized, and different implementations implemented
   different versions.  Thus, there is no assurance that the
   implementations adhere fully to the suggested solutions or that one
   implementation can interoperate with others that claim to incorporate
   the same features.  Furthermore, these solutions have known security
   issues.  All of those problems and security issues have been solved
   in IKEv2; thus, use of these non-standardized IKEv1 solutions is not
   recommended.

4.1.1.1.  RFC 2409, The Internet Key Exchange (IKE) (S, November 1998)

   This document defines a key exchange protocol that can be used to
   negotiate authenticated keying material for SAs.  This document
   implements a subset of the Oakley protocol in conjunction with ISAKMP
   to obtain authenticated keying material for use with ISAKMP, and for

   other security associations such as AH and ESP for the IETF IPsec
   DOI.  While, historically, IKEv1 was created by combining two
   security protocols, ISAKMP and Oakley, in practice, the combination
   (along with the IPsec DOI) has commonly been viewed as one protocol,
   IKEv1.  The protocol's origins can be seen in the organization of the
   documents that define it.

4.1.1.2.  RFC 2408, Internet Security Association and Key Management
          Protocol (ISAKMP) (S, November 1998)

   This document defines procedures and packet formats to establish,
   negotiate, modify, and delete Security Associations (SAs).  It is
   intended to support the negotiation of SAs for security protocols at
   all layers of the network stack.  ISAKMP can work with many different
   key exchange protocols, each with different security properties.

4.1.1.3.  RFC 2407, The Internet IP Security Domain of Interpretation
          for ISAKMP (S, November 1998)

   Within ISAKMP, a Domain of Interpretation is used to group related
   protocols using ISAKMP to negotiate security associations.  Security
   protocols sharing a DOI choose security protocol and cryptographic
   transforms from a common namespace and share key exchange protocol
   identifiers.  This document defines the Internet IP Security DOI
   (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses
   ISAKMP to negotiate security associations.

4.1.1.4.  RFC 2412, The OAKLEY Key Determination Protocol
          (I, November 1998)

   [RFC2412] describes a key establishment protocol that two
   authenticated parties can use to agree on secure and secret keying
   material.  The Oakley protocol describes a series of key exchanges --
   called "modes" -- and details the services provided by each (e.g.,
   perfect forward secrecy for keys, identity protection, and
   authentication).  This document provides additional theory and
   background to explain some of the design decisions and security
   features of IKE and ISAKMP; it does not include details necessary for
   the implementation of IKEv1.

4.1.2.  IKEv2

4.1.2.1.  RFC 4306, Internet Key Exchange (IKEv2) Protocol
          (S, December 2005)

   This document contains the original description of version 2 of the
   Internet Key Exchange (IKE) protocol.  It covers what was previously
   covered by separate documents: ISAKMP, IKE, and DOI.  It also

   addresses NAT traversal, legacy authentication, and remote address
   acquisition.  IKEv2 is not interoperable with IKEv1.  Automatic key
   distribution is required for IPsec-v3, but alternatives to IKE may be
   used to satisfy that requirement.  This document has been superseded
   by [RFC5996].

4.1.2.2.  RFC 4718, IKEv2 Clarifications and Implementation Guidelines
          (I, October 2006)

   [RFC4718] clarifies many areas of the original IKEv2 specification
   [RFC4306] that were seen as potentially difficult to understand for
   developers who were not intimately familiar with the specification
   and its history.  It does not introduce any changes to the protocol,
   but rather provides descriptions that are less prone to ambiguous
   interpretations.  The goal of this document was to encourage the
   development of interoperable implementations.  The clarifications in
   this document have been included in the new version of the IKEv2
   specification [RFC5996].

4.1.2.3.  RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2)
          (S, September 2010)

   [RFC5996] combines the original IKEv2 RFC [RFC4306] with the
   Clarifications RFC [RFC4718], and resolves many implementation issues
   discovered by the community since the publication of these two
   documents.  This document was developed by the IPsecME (IPsec
   Maintenance and Extensions) Working Group, after the conclusion of
   the original IPsec Working Group.  Automatic key distribution is
   required for IPsec-v3, but alternatives to IKE may be used to satisfy
   that requirement.

4.2.  Additions and Extensions

4.2.1.  Peer Authentication Methods

4.2.1.1.  RFC 4478, Repeated Authentication in Internet Key Exchange
          (IKEv2) Protocol (E, April 2006)

   [RFC4478] addresses a problem unique to remote access scenarios.  How
   can the gateway (the IKE responder) force the remote user (the IKE
   initiator) to periodically reauthenticate, limiting the damage in the
   case where an unauthorized user gains physical access to the remote
   host? This document defines a new status notification, that a
   responder can send to an initiator, which notifies the initiator that
   the IPsec SA will be revoked unless the initiator reauthenticates
   within a specified period of time.  This optional extension applies
   only to IKEv2, not to IKEv1.

4.2.1.2.  RFC 4739, Multiple Authentication Exchanges in the Internet
          Key Exchange (IKEv2) Protocol (E, November 2006)

   IKEv2 supports several mechanisms for authenticating the parties but
   each endpoint uses only one of these mechanisms to authenticate
   itself.  [RFC4739] specifies an extension to IKEv2 that allows the
   use of multiple authentication exchanges, using either different
   mechanisms or the same mechanism.  This extension allows, for
   instance, performing certificate-based authentication of the client
   host followed by an EAP authentication of the user.  This also allows
   for authentication by multiple administrative domains, if needed.
   This optional extension applies only to IKEv2, not to IKEv1.

4.2.1.3.  RFC 4754, IKE and IKEv2 Authentication Using the Elliptic
          Curve Digital Signature Algorithm (ECDSA) (S, January 2007)

   [RFC4754] describes how the Elliptic Curve Digital Signature
   Algorithm (ECDSA) may be used as the authentication method within the
   IKEv1 and IKEv2 protocols.  ECDSA provides many benefits including
   computational efficiency, small signature sizes, and minimal
   bandwidth compared to other available digital signature methods like
   RSA and DSA.  This optional extension applies to both IKEv1 and
   IKEv2.

4.2.1.4.  RFC 5998, An Extension for EAP-Only Authentication in IKEv2
          (S, September 2010)

   IKEv2 allows an initiator to use EAP for peer authentication, but
   requires the responder to authenticate through the use of a digital
   signature.  [RFC5998] extends IKEv2 so that EAP methods that provide
   mutual authentication and key agreement can also be used to provide
   peer authentication for the responder.  This optional extension
   applies only to IKEv2, not to IKEv1.

4.2.2.  Certificate Contents and Management (PKI4IPsec)

   The format, contents, and interpretation of Public Key Certificates
   (PKCs) proved to be a source of interoperability problems within IKE
   and IPsec.  PKI4IPsec was an attempt to set in place some common
   procedures and interpretations to mitigate those problems.

4.2.2.1.  RFC 4809, Requirements for an IPsec Certificate Management
          Profile (I, February 2007)

   [RFC4809] enumerates requirements for Public Key Certificate (PKC)
   lifecycle transactions between different VPN System and PKI System
   products in order to better enable large scale, PKI-enabled IPsec

   deployments with a common set of transactions.  This document
   discusses requirements for both the IPsec and the PKI products.
   These optional requirements apply to both IKEv1 and IKEv2.

4.2.2.2.  RFC 4945, The Internet IP Security PKI Profile of
          IKEv1/ISAKMP, IKEv2, and PKIX (S, August 2007)

   [RFC4945] defines a profile of the IKE and Public Key Infrastructure
   using X.509 (PKIX) frameworks in order to provide an agreed-upon
   standard for using PKI technology in the context of IPsec.  It also
   documents the contents of the relevant IKE payloads and further
   specifies their semantics.  In addition, it summarizes the current
   state of implementations and deployment and provides advice to avoid
   common interoperability issues.  This optional extension applies to
   both IKEv1 and IKEv2.

4.2.2.3.  RFC 4806, Online Certificate Status Protocol (OCSP) Extensions
          to IKEv2 (S, February 2007)

   When certificates are used with IKEv2, the communicating peers need a
   mechanism to determine the revocation status of the peer's
   certificate.  OCSP is one such mechanism.  [RFC4806] defines the
   "OCSP Content" extension to IKEv2.  This document is applicable when
   OCSP is desired and security policy (e.g., firewall policy) prevents
   one of the IKEv2 peers from accessing the relevant OCSP responder
   directly.  This optional extension applies only to IKEv2, not to
   IKEv1.

4.2.3.  Dead Peer Detection

4.2.3.1.  RFC 3706, A Traffic-Based Method of Detecting Dead Internet
          Key Exchange (IKE) Peers (I, February 2004)

   When two peers communicate using IKE and IPsec, it is possible for
   the connectivity between the two peers to drop unexpectedly.  But the
   SAs can still remain until their lifetimes expire, resulting in the
   packets getting tunneled into a "black hole".  [RFC3706] describes an
   approach to detect peer liveliness without needing to send messages
   at regular intervals.  This RFC defines an optional extension to
   IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which
   refers to this feature as a "liveness check" or "liveness test".

4.2.4.  Remote Access

   The IKEv2 Mobility and Multihoming (MOBIKE) protocol enables two
   additional capabilities for IPsec VPN users: 1) moving from one
   address to another without re-establishing existing SAs and 2) using

   multiple interfaces simultaneously.  These solutions are limited to
   IPsec VPNs; they are not intended to provide more general mobility or
   multihoming capabilities.

   The IPsecME Working Group identified some missing components needed
   for more extensive IKEv2 and IPsec-v3 support for remote access
   clients.  These include efficient client resumption of a previously
   established session with a VPN gateway, efficient client redirection
   to an alternate VPN gateway, and support for IPv6 client
   configuration using IPsec configuration payloads.

4.2.4.1.  RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE)
          (S, June 2006)

   IKEv2 assumes that an IKE SA is created implicitly between the IP
   address pair that is used during the protocol execution when
   establishing the IKEv2 SA.  IPsec-related documents had no provision
   to change this pair after an IKE SA was created.  [RFC4555] defines
   extensions to IKEv2 that enable an efficient management of IKE and
   IPsec Security Associations when a host possesses multiple IP
   addresses and/or where IP addresses of an IPsec host change over
   time.

4.2.4.2.  RFC 4621, Design of the IKEv2 Mobility and Multihoming
          (MOBIKE) Protocol (I, August 2006)

   [RFC4621] discusses the involved network entities and the
   relationship between IKEv2 signaling and information provided by
   other protocols.  It also records design decisions for the MOBIKE
   protocol, background information, and records discussions within the
   working group.

4.2.4.3.  RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4
          and IKEv2 Mobility and Multihoming (MOBIKE) (B, June 2008)

   [RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility
   extensions to IKEv2 (MOBIKE) to provide secure connectivity and
   mobility to enterprise users when they roam into untrusted networks.

4.2.4.4.  RFC 5723, Internet Key Exchange Protocol Version 2 (IKEv2)
          Session Resumption (S, January 2010)

   [RFC5723] enables a remote client that has been disconnected from a
   gateway to re-establish SAs with the gateway in an expedited manner,
   without repeating the complete IKEv2 negotiation.  This capability
   requires changes to IKEv2.  This optional extension applies only to
   IKEv2, not to IKEv1.

4.2.4.5.  RFC 5685, Re-direct Mechanism for the Internet Key Exchange
          Protocol Version 2 (IKEv2) (S, November 2009)

   [RFC5685] enables a gateway to securely redirect VPN clients to
   another VPN gateway, either during or after the IKEv2 negotiation.
   Possible reasons include, but are not limited to, an overloaded
   gateway or a gateway that needs to shut down.  This requires changes
   to IKEv2.  This optional extension applies only to IKEv2, not to
   IKEv1.

4.2.4.6.  RFC 5739, IPv6 Configuration in Internet Key Exchange Protocol
          Version 2 (IKEv2) (E, February 2010)

   In IKEv2, a VPN gateway can assign an internal network address to a
   remote VPN client.  This is accomplished through the use of
   configuration payloads.  For an IPv6 client, the assignment of a
   single address is not sufficient to enable full-fledged IPv6
   communications.  [RFC5739] proposes several solutions that might
   remove this limitation.  This optional extension applies only to
   IKEv2, not to IKEv1.

5.  Cryptographic Algorithms and Suites

   Two basic requirements must be met for an algorithm to be used within
   IKE and/or IPsec: assignment of one or more IANA values and an RFC
   that describes how to use the algorithm within the relevant protocol,
   packet formats, special considerations, etc.  For each RFC that
   describes a cryptographic algorithm, this roadmap will classify its
   requirement level for each protocol, as either MUST, SHOULD, or MAY
   [RFC2119]; SHOULD+, SHOULD-, or MUST- [RFC4835]; optional; undefined;
   or N/A (not applicable).  A designation of "optional" means that the
   algorithm meets the two basic requirements, but its use is not
   specifically recommended for that protocol.  "Undefined" means that
   one of the basic requirements is not met: either there is no relevant
   IANA number for the algorithm or there is no RFC specifying how it
   should be used within that specific protocol.  "N/A" means that use
   of the algorithm is inappropriate in the context (e.g., NULL
   encryption for IKE, which always requires encryption; or combined
   mode algorithms, a new feature in IPsec-v3, for use with IPsec-v2).

   This document categorizes the requirement level of each algorithm for
   IKEv1, IKEv2, IPsec-v2, and IPsec-v3.  If an algorithm is recommended
   for use within IKEv1 or IKEv2, it is used either to protect the IKE
   SA's traffic (encryption and integrity-protection algorithms) or to
   generate keying material (Diffie-Hellman or DH groups, Pseudorandom
   Functions or PRFs).  If an algorithm is recommended for use within
   IPsec, it is used to protect the IPsec/child SA's traffic, and IKE is
   capable of negotiating its use for that purpose.  These requirements

   are summarized in Table 1 (Appendix A).  These levels are current as
   of February 2011; subsequent RFCs may result in altered requirement
   levels.  For algorithms, this could mean the introduction of new
   algorithms or upgrading or downgrading the requirement levels of
   current algorithms.

   The IANA registries for IKEv1 and IKEv2 include IANA values for
   various cryptographic algorithms.  IKE uses these values to negotiate
   IPsec SAs that will provide protection using those algorithms.  If a
   specific algorithm lacks a value for IKEv1 and/or IKEv2, that
   algorithm's use is classified as "undefined" (no IANA #) within
   IPsec-v2 and/or IPsec-v3.

5.1.  Algorithm Requirements

   Specifying a core set of mandatory algorithms for each protocol
   facilitates interoperability.  Defining those algorithms in an RFC
   separate from the base protocol RFC enhances algorithm agility.
   IPsec-v3 and IKEv2 each have an RFC that specifies their mandatory-
   to-implement (MUST), recommended (SHOULD), optional (MAY), and
   deprecated (SHOULD NOT) algorithms.  For IPsec-v2, this is included
   in the base protocol RFC.  That was originally the case for IKEv1,
   but IKEv1's algorithm requirements were updated in [RFC4109].

5.1.1.  RFC 4835, Cryptographic Algorithm Implementation Requirements
        for Encapsulating Security Payload (ESP) and Authentication
        Header (AH) (S, April 2007)

   [RFC4835] specifies the encryption and integrity-protection
   algorithms for IPsec (both versions).  Algorithms for IPsec-v2 were
   originally defined in [RFC2402] and [RFC2406].  [RFC4305] obsoleted
   those requirements, and was in turn obsoleted by [RFC4835].
   Therefore, [RFC4835] applies to IPsec-v2 as well as IPsec-v3.
   Combined mode algorithms are mentioned, but not assigned a
   requirement level.

5.1.2.  RFC 4307, Cryptographic Algorithms for Use in the Internet Key
        Exchange Version 2 (IKEv2) (S, December 2005)

   [RFC4307] specifies the encryption and integrity-protection
   algorithms used by IKEv2 to protect its own traffic, the Diffie-
   Hellman (DH) groups used within IKEv2, and the pseudorandom functions
   used by IKEv2 to generate keys, nonces, and other random values.
   [RFC4307] contains conflicting requirements for IKEv2 encryption and
   integrity-protection algorithms.  Where there are contradictory
   requirements, this document takes its requirement levels from Section

   3.1.1, "Encrypted Payload Algorithms", rather than from Section
   3.1.3, "IKEv2 Transform Type 1 Algorithms", or Section 3.1.4, "IKEv2
   Transform Type 2 Algorithms".

5.1.3.  RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1)
        (S, May 2005)

   [RFC4109] updates IKEv1's algorithm specifications, which were
   originally defined in [RFC2409].  It specifies the encryption and
   integrity-protection algorithms used by IKEv1 to protect its own
   traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash
   and pseudorandom functions used by IKEv1 to generate keys, nonces and
   other random values; and the authentication methods and algorithms
   used by IKEv1 for peer authentication.

5.2.  Encryption Algorithms

   The encryption-algorithm RFCs describe how to use these algorithms to
   encrypt IKE and/or ESP traffic, providing confidentiality protection
   to the traffic.  They describe any special constraints, requirements,
   or changes to packet format appropriate for the specific algorithm.
   In general, they do not describe the detailed algorithmic
   computations; the reference section of each RFC includes pointers to
   documents that define the inner workings of the algorithm.  Some of
   the RFCs include sample test data, to enable implementors to compare
   their results with standardized output.

   When any encryption algorithm is used to provide confidentiality, the
   use of integrity protection is strongly recommended.  If the
   encryption algorithm is a stream cipher, omitting integrity
   protection seriously compromises the security properties of the
   algorithm.

   DES, as described in [RFC2405], was originally a required algorithm
   for IKEv1 and ESP-v2.  Since the use of DES is now deprecated, this
   roadmap does not include [RFC2405].

5.2.1.  RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec
        (S, November 1998)

   [RFC2410] is a tongue-in-cheek description of the no-op encryption
   algorithm (i.e., using ESP without encryption).  In order for IKE to
   negotiate the selection of the NULL encryption algorithm for use in
   an ESP SA, an identifying IANA number is needed.  This number (the
   value 11 for ESP_NULL) is found on the IANA registries for both IKEv1
   and IKEv2, but it is not mentioned in [RFC2410].

   Requirement levels for ESP-NULL:

     IKEv1 - N/A
     IKEv2 - N/A
     ESP-v2 - MUST [RFC4835]
     ESP-v3 - MUST [RFC4835]

   NOTE: RFC 4307 erroneously classifies ESP-NULL as MAY for IKEv2; this
   has been corrected in an errata submission for RFC 4307.

5.2.2.  RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, November 1998)

   [RFC2451] describes how to use encryption algorithms in cipher-block-
   chaining (CBC) mode to encrypt IKE and ESP traffic.  It specifically
   mentions Blowfish, CAST-128, Triple DES (3DES), International Data
   Encryption Algorithm (IDEA), and RC5, but it is applicable to any
   block-cipher algorithm used in CBC mode.  The algorithms mentioned in
   the RFC all have a 64-bit blocksize and a 64-bit random
   Initialization Vector (IV) that is sent in the packet along with the
   encrypted data.

   Requirement levels for 3DES-CBC:

     IKEv1 - MUST [RFC4109]
     IKEv2 - MUST- [RFC4307]
     ESP-v2 - MUST [RFC4835]
     ESP-v3 - MUST- [RFC4835]

   Requirement levels for other CBC algorithms (Blowfish, CAST, IDEA,
   RC5):

     IKEv1 - optional
     IKEv2 - optional
     ESP-v2 - optional
     ESP-v3 - optional

5.2.3.  RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec
        (S, September. 2003)

   [RFC3602] describes how to use AES in cipher block chaining (CBC)
   mode to encrypt IKE and ESP traffic.  AES is the successor to DES.
   AES-CBC is a block-mode cipher with a 128-bit blocksize, a random IV
   that is sent in the packet along with the encrypted data, and
   keysizes of 128, 192 and 256 bits.  If AES-CBC is implemented,
   128-bit keys are MUST; the other sizes are MAY.  [RFC3602] includes
   IANA values for use in IKEv1 and ESP-v2.  A single IANA value is
   defined for AES-CBC, so IKE negotiations need to specify the keysize.

   Requirement levels for AES-CBC with 128-bit keys:

     IKEv1 - SHOULD [RFC4109]
     IKEv2 - SHOULD+ [RFC4307]
     ESP-v2 - MUST [RFC4835]
     ESP-v3 - MUST [RFC4835]

   Requirement levels for AES-CBC with 192- or 256-bit keys:

     IKEv1 - optional
     IKEv2 - optional
     ESP-v2 - optional
     ESP-v3 - optional

5.2.4.  RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode
        With IPsec Encapsulating Security Payload (ESP)
        (S, January 2004)

   [RFC3686] describes how to use AES in counter (CTR) mode to encrypt
   ESP traffic.  AES-CTR is a stream cipher with a 32-bit random nonce
   (1/SA) and a 64-bit IV.  If AES-CTR is implemented, 128-bit keys are
   MUST; 192- and 256-byte keys are MAY.  Reuse of the IV with the same
   key and nonce compromises the data's security; thus, AES-CTR should
   not be used with manual keying.  AES-CTR can be pipelined and
   parallelized; it uses only the AES encryption operations for both
   encryption and decryption.

   Requirement levels for AES-CTR:

     IKEv1 - undefined (no IANA #)
     IKEv2 - optional [RFC5930]
     ESP-v2 - SHOULD [RFC4835]
     ESP-v3 - SHOULD [RFC4835]

5.2.5.  RFC 5930, Using Advanced Encryption Standard Counter Mode (AES-
        CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol
        (I, July 210).

   [RFC5930] extends [RFC3686] to enable the use of AES-CTR to provide
   encryption and integrity protection for IKEv2 messages.

5.2.6.  RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec
        (S, December 2005)

   [RFC4312] describes how to use Camellia in cipher block chaining
   (CBC) mode to encrypt IKE and ESP traffic.  Camellia-CBC is a block-
   mode cipher with a 128-bit blocksize, a random IV that is sent in the
   packet along with the encrypted data, and keysizes of 128, 192, and

   256 bits.  If Camellia-CBC is implemented, 128-bit keys are MUST; the
   other sizes are MAY.  [RFC4312] includes IANA values for use in IKEv1
   and IPsec-v2.  A single IANA value is defined for Camellia-CBC, so
   IKEv1 negotiations need to specify the keysize.

5.2.7.  RFC 5529, Modes of Operation for Camellia for Use with IPsec
        (S, April 2009)

   [RFC5529] describes the use of the Camellia block-cipher algorithm in
   conjunction with several different modes of operation.  It describes
   the use of Camellia in cipher block chaining (CBC) mode and counter
   (CTR) mode as an encryption algorithm within ESP.  It also describes
   the use of Camellia in Counter with CBC-MAC (CCM) mode as a combined
   mode algorithm in ESP.  This document defines how to use IKEv2 to
   generate keying material for a Camellia ESP SA; it does not define
   how to use Camellia within IKEv2 to protect an IKEv2 SA's traffic.
   However, this RFC, in conjunction with IKEv2's generalized
   description of block-mode encryption, provide enough detail to allow
   the use of Camellia-CBC algorithms within IKEv2.  All three modes can
   use keys of length 128 bits, 192 bits, or 256 bits. [RFC5529]
   includes IANA values for use in IKEv2 and IPsec-v3.  A single IANA
   value is defined for each Camellia mode, so IKEv2 negotiations need
   to specify the keysize.

   Requirement levels for Camellia-CBC:

     IKEv1 - optional
     IKEv2 - optional
     ESP-v2 - optional
     ESP-v3 - optional

   Requirement levels for Camellia-CTR:

     IKEv1 - undefined (no IANA #)
     IKEv2 - undefined (no RFC)
     ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKE)
     ESP-v3 - optional

   Requirement levels for Camellia-CCM:

     IKEv1 - N/A
     IKEv2 - undefined (no RFC)
     ESP-v2 - N/A
     ESP-v3 - optional

5.2.8.  RFC 4196, The SEED Cipher Algorithm and Its Use with IPsec
        (S, October 2005)

   [RFC4196] describes how to use SEED in cipher block chaining (CBC)
   mode to encrypt ESP traffic.  It describes how to use IKEv1 to
   negotiate a SEED-ESP SA, but does not define the use of SEED to
   protect IKEv1 traffic.  SEED-CBC is a block-mode cipher with a
   128-bit blocksize, a random IV that is sent in the packet along with
   the encrypted data, and a keysize of 128 bits.  [RFC4196] includes
   IANA values for use in IKEv1 and IPsec-v2.  [RFC4196] includes test
   data.

   Requirement levels for SEED-CBC:

     IKEv1 - undefined (no IANA #)
     IKEv2 - undefined (no IANA #)
     ESP-v2 - optional
     ESP-v3 - optional (but no IANA #, so cannot be negotiated by IKE)

5.3.  Integrity-Protection (Authentication) Algorithms

   The integrity-protection algorithm RFCs describe how to use these
   algorithms to authenticate IKE and/or IPsec traffic, providing
   integrity protection to the traffic.  This protection is provided by
   computing an Integrity Check Value (ICV), which is sent in the
   packet.  The RFCs describe any special constraints, requirements, or
   changes to packet format appropriate for the specific algorithm.  In
   general, they do not describe the detailed algorithmic computations;
   the reference section of each RFC includes pointers to documents that
   define the inner workings of the algorithm.  Some of the RFCs include
   sample test data, to enable implementors to compare their results
   with standardized output.

   Some of these algorithms generate a fixed-length ICV, which is
   truncated when it is included in an IPsec-protected packet.  For
   example, standard HMAC-SHA-1 (Hashed Message Authentication Code)
   generates a 160-bit ICV, which is truncated to 96 bits when it is
   used to provide integrity protection to an ESP or AH packet.  The
   individual RFC descriptions mention those algorithms that are
   truncated.  When these algorithms are used to protect IKEv2 SAs, they
   are also truncated.  For IKEv1, HMAC-SHA-1 and HMAC-MD5 are
   negotiated by requesting the hash algorithms SHA-1 and MD5,
   respectively; these algorithms are not truncated when used to protect
   an IKEv1 SA.  For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry
   contains values for both the truncated version and the standard non-
   truncated version; thus, IKEv2 has the capability to negotiate either
   version of the algorithm.  However, only the truncated version is
   used for IKEv2 SAs and for IPsec SAs.  The non-truncated version is

   reserved for use by the Fibre Channel protocol [RFC4595].  For the
   other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC-
   RIPEMD), only the truncated version can be used for both IKEv2 and
   IPsec-v3 SAs.

   One other algorithm, AES-GMAC [RFC4543], can also provide integrity
   protection.  It has two versions: an integrity-protection algorithm
   for use within AH-v3, and a combined mode algorithm with null
   encryption for use within ESP-v3.  [RFC4543] is described in Section
   5.4, "Combined Mode Algorithms".

5.3.1.  RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH
        (S, November 1998)

   [RFC2404] describes HMAC-SHA-1, an integrity-protection algorithm
   with a 512-bit blocksize, and a 160-bit key and Integrity Check Value
   (ICV).  For use within IPsec, the ICV is truncated to 96 bits.  This
   is currently the most commonly used integrity-protection algorithm.

   Requirement levels for HMAC-SHA-1:

     IKEv1 - MUST [RFC4109]
     IKEv2 - MUST [RFC4307]
     IPsec-v2 - MUST [RFC4835]
     IPsec-v3 - MUST [RFC4835]

5.3.2.  RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
        (S, September 2003)

   [RFC3566] describes AES-XCBC-MAC, a variant of CBC-MAC, which is
   secure for messages of varying lengths (unlike classic CBC-MAC).  It
   is an integrity-protection algorithm with a 128-bit blocksize and a
   128-bit key and ICV.  For use within IPsec, the ICV is truncated to
   96 bits.  [RFC3566] includes test data.

   Requirement levels for AES-XCBC-MAC:

     IKEv1 - undefined (no RFC)
     IKEv2 - optional
     IPsec-v2 - SHOULD+ [RFC4835]
     IPsec-v3 - SHOULD+ [RFC4835]

5.3.3.  RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
        with IPsec (S, May 2007)

   [RFC4868] describes a family of algorithms, successors to HMAC-SHA-1.
   HMAC-SHA-256 has a 512-bit blocksize and a 256-bit key and ICV.
   HMAC-SHA-384 has a 1024-bit blocksize and a 384-bit key and ICV.

   HMAC-SHA-512 has a 1024-bit blocksize and a 512-bit key and ICV.  For
   use within IKE and IPsec, the ICV is truncated to half its original
   size (128 bits, 192 bits, or 256 bits).  Each of the three algorithms
   has its own IANA value, so IKE does not have to negotiate the
   keysize.

   Requirement levels for HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512:

     IKEv1 - optional
     IKEv2 - optional
     IPsec-v2 - optional
     IPsec-v3 - optional

5.3.4.  RFC 2403, The Use of HMAC-MD5-96 within ESP and AH
        (S, November 1998)

   [RFC2403] describes HMAC-MD5, an integrity-protection algorithm with
   a 512-bit blocksize and a 128-bit key and Integrity Check Value
   (ICV).  For use within IPsec, the ICV is truncated to 96 bits.  It
   was a required algorithm for IKEv1 and IPsec-v2.  The use of plain
   MD5 is now deprecated, but [RFC4835] states: "Weaknesses have become
   apparent in MD5; however, these should not affect the use of MD5 with
   HMAC".

   Requirement levels for HMAC-MD5:

     IKEv1 - MAY [RFC4109]
     IKEv2 - optional [RFC4307]
     IPsec-v2 - MAY [RFC4835]
     IPsec-v3 - MAY [RFC4835]

5.3.5.  RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec
        (S, June 2006)

   [RFC4494] describes AES-CMAC, another variant of CBC-MAC, which is
   secure for messages of varying lengths.  It is an integrity-
   protection algorithm with a 128-bit blocksize and 128-bit key and
   ICV.  For use within IPsec, the ICV is truncated to 96 bits.
   [RFC4494] includes test data.

   Requirement levels for AES-CMAC:

     IKEv1 - undefined (no IANA #)
     IKEv2 - optional
     IPsec-v2 - optional (but no IANA #, so cannot be negotiated by IKE)
     IPsec-v3 - optional

5.3.6.  RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH
        (S, June 2000)

   [RFC2857] describes HMAC-RIPEMD, an integrity-protection algorithm
   with a 512-bit blocksize and a 160-bit key and ICV.  For use within
   IPsec, the ICV is truncated to 96 bits.

   Requirement levels for HMAC-RIPEMD:

     IKEv1 - undefined (no IANA #)
     IKEv2 - undefined (no IANA #)
     IPsec-v2 - optional
     IPsec-v3 - optional (but no IANA #, so cannot be negotiated by IKE)

5.3.7.  RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE)
        and IPsec (I, May 2007)

   In light of recent attacks on MD5 and SHA-1, [RFC4894] examines
   whether it is necessary to replace the hash functions currently used
   by IKE and IPsec for key generation, integrity protection, digital
   signatures, or PKIX certificates.  It concludes that the algorithms
   recommended for IKEv2 [RFC4307] and IPsec-v3 [RFC4305] are not
   currently susceptible to any known attacks.  Nonetheless, it suggests
   that implementors add support for AES-XCBC-MAC-96 [RFC3566], AES-
   XCBC-PRF-128 [RFC4434], and HMAC-SHA-256, -384, and -512 [RFC4868]
   for future use.  It also suggests that IKEv2 implementors add support
   for PKIX certificates signed with SHA-256, -384, and -512.

5.4.  Combined Mode Algorithms

   IKEv1 and ESP-v2 use separate algorithms to provide encryption and
   integrity protection, and IKEv1 can negotiate different combinations
   of algorithms for different SAs.  In ESP-v3, a new class of
   algorithms was introduced, in which a single algorithm can provide
   both encryption and integrity protection.  [RFC5996] describes how
   IKEv2 can negotiate combined mode algorithms to be used in ESP-v3
   SAs.  [RFC5282] adds that capability to IKEv2, enabling IKEv2 to
   negotiate and use combined mode algorithms for its own traffic.  When
   properly designed, these algorithms can provide increased efficiency
   in both implementation and execution.

   Although ESP-v2 did not originally include combined mode algorithms,
   some IKEv1 implementations have added the capability to negotiate
   combined mode algorithms for use in IPsec SAs; these implementations
   do not include the capability to use combined mode algorithms to
   protect IKE SAs.  IANA numbers for combined mode algorithms have been
   added to the IKEv1 registry.

5.4.1.  RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with
        IPsec Encapsulating Security Payload (ESP) (S, December 2005)

   [RFC4309] describes how to use AES in counter with CBC-MAC (CCM)
   mode, a combined algorithm, to encrypt and integrity protect ESP
   traffic.  AES-CCM is a block-mode cipher with a 128-bit blocksize; a
   random IV that is sent in the packet along with the encrypted data; a
   24-bit salt value (1/SA); keysizes of 128, 192, and 256 bits and ICV
   sizes of 64, 96 and 128 bits.  If AES-CCM is implemented, 128-bit
   keys are MUST; the other sizes are MAY.  ICV sizes of 64 and 128 bits
   are MUST; 96 bits is MAY.  The salt value is generated by IKE during
   the key-generation process.  Reuse of the IV with the same key
   compromises the data's security; thus, AES-CCM should not be used
   with manual keying.  [RFC4309] includes IANA values that IKE can use
   to negotiate ESP-v3 SAs.  Each of the three ICV lengths has its own
   IANA value, but IKE negotiations need to specify the keysize.
   [RFC4309] includes test data.  [RFC4309] describes how IKE can
   negotiate the use of AES-CCM to use in an ESP SA.  [RFC5282] extends
   this to the use of AES-CCM to protect an IKEv2 SA.

   Requirement levels for AES-CCM:

     IKEv1 - N/A
     IKEv2 - optional
     ESP-v2 - N/A
     ESP-v3 - optional [RFC4835]

   NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but
   combined mode algorithms are not a feature of IPsec-v2.  Although
   some IKEv1/IPsec-v2 implementations include this capability (see
   Section 5.4), it is not part of the protocol.

5.4.2.  RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec
        Encapsulating Security Payload (ESP) (S, June 2005)

   [RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a
   combined algorithm, to encrypt and integrity protect ESP traffic.
   AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV
   that is sent in the packet along with the encrypted data; a 32-bit
   salt value (1/SA); keysizes of 128, 192, and 256 bits; and ICV sizes
   of 64, 96, and 128 bits.  If AES-GCM is implemented, 128-bit keys are
   MUST; the other sizes are MAY.  An ICV size of 128 bits is a MUST; 64
   and 96 bits are MAY.  The salt value is generated by IKE during the
   key-generation process.  Reuse of the IV with the same key
   compromises the data's security; thus, AES-GCM should not be used
   with manual keying.  [RFC4106] includes IANA values that IKE can use
   to negotiate ESP-v3 SAs.  Each of the three ICV lengths has its own
   IANA value, but IKE negotiations need to specify the keysize.

   [RFC4106] includes test data.  [RFC4106] describes how IKE can
   negotiate the use of AES-GCM to use in an ESP SA.  [RFC5282] extends
   this to the use of AES-GCM to protect an IKEv2 SA.

   Requirement levels for AES-GCM:

     IKEv1 - N/A
     IKEv2 - optional
     ESP-v2 - N/A
     ESP-v3 - optional [RFC4835]

   NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but
   combined mode algorithms are not a feature of IPsec-v2.  Although
   some IKEv1/IPsec-v2 implementations include this capability (see
   Section 5.4), it is not part of the protocol.

5.4.3.  RFC 4543, The Use of Galois Message Authentication Code (GMAC)
        in IPsec ESP and AH (S, May 2006)

   [RFC4543] is the variant of AES-GCM [RFC4106] that provides integrity
   protection without encryption.  It has two versions: an integrity-
   protection algorithm for use within AH, and a combined mode algorithm
   with null encryption for use within ESP.  It can use a key of 128-,
   192-, or 256-bits; the ICV is always 128 bits, and is not truncated.
   AES-GMAC uses a nonce, consisting of a 64-bit IV and a 32-bit salt
   (1/SA).  The salt value is generated by IKE during the key generation
   process.  Reuse of the salt value with the same key compromises the
   data's security; thus, AES-GMAC should not be used with manual
   keying.  For use within AH, each keysize has its own IANA value, so
   IKE does not have to negotiate the keysize.  For use within ESP,
   there is only one IANA value, so IKE negotiations must specify the
   keysize.  AES-GMAC cannot be used by IKE to protect its own SAs,
   since IKE traffic requires encryption.

   Requirement levels for AES-GMAC:

     IKEv1 - N/A
     IKEv2 - N/A
     IPsec-v2 - N/A
     IPsec-v3 - optional

   NOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, but
   combined mode algorithms are not a feature of IPsec-v2.  Although
   some IKEv1/IPsec-v2 implementations include this capability (see
   Section 5.4), it is not part of the protocol.

5.4.4.  RFC 5282, Using Authenticated Encryption Algorithms with the
        Encrypted Payload of the Internet Key Exchange version 2 (IKEv2)
        Protocol (S, August 2008)

   [RFC5282] extends [RFC4309] and [RFC4106] to enable the use of AES-
   CCM and AES-GCM to provide encryption and integrity protection for
   IKEv2 messages.

5.5.  Pseudo-Random Functions (PRFs)

   IKE uses pseudorandom functions (PRFs) to generate the secret keys
   that are used in IKE SAs and IPsec SAs.  These PRFs are generally the
   same algorithms used for integrity protection, but their output is
   not truncated, since all of the generated bits are generally needed
   for the keys.  If the PRF's output is not long enough to supply the
   required number of bits of keying material, the PRF is applied
   iteratively until the requisite amount of keying material is
   generated.

   For each IKEv2 SA, the peers negotiate both a PRF algorithm and an
   integrity-protection algorithm; the former is used to generate keying
   material and other values, and the latter is used to provide
   protection to the IKE SA's traffic.

   IKEv1's approach is more complicated.  IKEv1 [RFC2409] does not
   specify any PRF algorithms.  For each IKEv1 SA, the peers agree on an
   unkeyed hash function (e.g., SHA-1).  IKEv1 uses the HMAC version of
   this function to generate keying material and to provide integrity
   protection for the IKE SA.  Therefore, PRFs that are not HMACs cannot
   currently be used in IKEv1.

   Requirement levels for PRF-HMAC-SHA1:

     IKEv1 - MUST [RFC4109]
     IKEv2 - MUST [RFC4307]

   Requirement levels for PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-
   HMAC-SHA-512:

     IKEv1 - optional [RFC4868]
     IKEv2 - optional [RFC4868]

5.5.1.  RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key
        Exchange Protocol (IKE) (S, February 2006)

   [RFC3566] defines AES-XCBC-MAC-96, which is used for integrity
   protection within IKE and IPsec.  [RFC4434] enables the use of AES-
   XCBC-MAC as a PRF within IKE.  The PRF differs from the integrity-

   protection algorithm in two ways: its 128-bit output is not truncated
   to 96 bits, and it accepts a variable-length key, which is modified
   (lengthened via padding or shortened through application of AES-XCBC)
   to a 128-bit key.  [RFC4434] includes test data.

   Requirement levels for AES-XCBC-PRF:

     IKEv1 - undefined (no RFC)
     IKEv2 - SHOULD+ [RFC4307]

   NOTE: RFC 4109 erroneously classifies AES-XCBC-PRF as SHOULD for
   IKEv1; this has been corrected in an errata submission for RFC 4109.

5.5.2.  RFC 4615, The Advanced Encryption Standard-Cipher-based Message
        Authentication Code-Pseudorandom Function-128 (AES-CMAC-PRF-128)
        Algorithm for the Internet Key Exchange Protocol (IKE)
        (S, August 2006)

   [RFC4615] extends [RFC4494] to enable the use of AES-CMAC as a PRF
   within IKEv2, in a manner analogous to that used by [RFC4434] for
   AES-XCBC.

   Requirement levels for AES-CMAC-PRF:

     IKEv1 - undefined (no IANA #)
     IKEv2 - optional

5.6.  Cryptographic Suites

5.6.1.  RFC 4308, Cryptographic Suites for IPsec (S, December 2005)

   An IKE negotiation consists of multiple cryptographic attributes,
   both for the IKE SA and for the IPsec SA.  The number of possible
   combinations can pose a challenge to peers trying to find a common
   policy.  To enhance interoperability, [RFC4308] defines two pre-
   defined suites, consisting of combinations of algorithms that
   comprise typical security policies.  IKE/ESP suite "VPN-A" includes
   use of 3DES, HMAC-SHA-1, and 1024-bit modular exponentiation group
   (MODP) Diffie-Hellman (DH); IKE/ESP suite "VPN-B" includes AES-CBC,
   AES-XCBC-MAC, and 2048-bit MODP DH.  These suites are intended to be
   named "single-button" choices in the administrative interface, but do
   not prevent the use of alternative combinations.

5.6.2.  RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007)

   [RFC4869] adds four pre-defined suites, based upon the United States
   National Security Agency's "Suite B" specifications, to those
   specified in [RFC4308].  IKE/ESP suites "Suite-B-GCM-128" and "Suite-

   B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256, or HMAC-
   SHA-384, and 256-bit or 384-bit elliptic-curve (EC) DH groups.
   IKE/AH suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include use
   of AES-CBC, AES-GMAC, HMAC-SHA-256, or HMAC-SHA-384, and 256-bit or
   384-bit EC DH groups.  While [RFC4308] does not specify a peer-
   authentication method, [RFC4869] mandates pre-shared key
   authentication for IKEv1; public key authentication using ECDSA is
   recommended for IKEv1 and required for IKEv2.

5.7.  Diffie-Hellman Algorithms

   IKE negotiations include a Diffie-Hellman exchange, which establishes
   a shared secret to which both parties contributed.  This value is
   used to generate keying material to protect both the IKE SA and the
   IPsec SA.

   IKEv1 [RFC2409] contains definitions of two DH MODP groups and two
   elliptic curve (EC) groups; IKEv2 [RFC5996] only references the MODP
   groups.  The requirements levels of these groups are:

   Requirement levels for DH MODP group 1:

     IKEv1 - MAY [RFC4109]
     IKEv2 - optional

   Requirement levels for DH MODP group 2:

     IKEv1 - MUST [RFC4109]
     IKEv2 - MUST- [RFC4307]

   Requirement levels for EC groups 3-4:

     IKEv1 - MAY [RFC4109]
     IKEv2 - undefined (no IANA #)

5.7.1.  RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups
        for Internet Key Exchange (IKE) (S, May 2003)

   [RFC2409] and [RFC5996] define two MODP DH groups (groups 1 and 2)
   for use within IKE.  [RFC3526] adds six more groups (groups 5 and
   14-18).  Group 14 is a 2048-bit group that is strongly recommended
   for use in IKE.

   Requirement levels for DH MODP group 14:

     IKEv1 - SHOULD [RFC4109]
     IKEv2 - SHOULD+ [RFC4307]

   Requirement levels for DH MODP groups 5, 15-18:

     IKEv1 - optional [RFC4109]
     IKEv2 - optional

5.7.2.  RFC 4753, ECP Groups For IKE and IKEv2 (I, January 2007)

   [RFC4753] defines three EC DH groups (groups 19-21) for use within
   IKE.

   The document includes test data.

   Requirement levels for DH EC groups  19-21:

     IKEv1 - optional [RFC4109]
     IKEv2 - optional

5.7.3.  RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for
        IKE and IKEv2 (I, June 2010)

   [RFC5903] obsoletes [RFC4753], fixing an inconsistency in the DH
   shared secret value.

5.7.4.  RFC 5114, Additional Diffie-Hellman Groups for Use with IETF
        Standards (I, January 2008)

   [RFC5114] defines five additional DH groups (MODP groups 22-24 and EC
   groups 25-26) for use in IKE.  It also includes three EC DH groups
   (groups 19-21) that were originally defined in [RFC4753]; however,
   the current specification for these groups is [RFC5903].  The IANA
   group numbers are specific to IKE, but the DH groups are intended for
   use in multiple IETF protocols, including Transport Layer
   Security/Secure Socket Layer (TLS/SSL), Secure/Multipurpose Internet
   Mail Extensions (S/MIME), and X.509 Certificates.

   Requirement levels for DH MODP groups 22-24, EC groups 25-26:

     IKEv1 - optional
     IKEv2 - optional