<pre>Network Working Group                                           D. Black
Request for Comments: 5282                                           EMC
Updates: <a href="./rfc4306">4306</a>                                                  D. McGrew
Category: Standards Track                                    August 2008


  <span class="h1">Using Authenticated Encryption Algorithms with the Encrypted Payload</span>
        <span class="h1">of the Internet Key Exchange version 2 (IKEv2) Protocol</span>

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   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 the use of other authenticated encryption
   algorithms with the IKEv2 Encrypted Payload.



















<span class="grey">Black &amp; McGrew              Standards Track                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
      <a href="#section-1.1">1.1</a>. Conventions Used in This Document ..........................<a href="#page-3">3</a>
   <a href="#section-2">2</a>. Structure of this Document ......................................<a href="#page-4">4</a>
   <a href="#section-3">3</a>. IKEv2 Encrypted Payload Data ....................................<a href="#page-4">4</a>
      <a href="#section-3.1">3.1</a>. AES GCM and AES CCM Initialization Vector (IV) .............<a href="#page-6">6</a>
      <a href="#section-3.2">3.2</a>. AES GCM and AES CCM Ciphertext (C) Construction ............<a href="#page-6">6</a>
   <a href="#section-4">4</a>. AES GCM and AES CCM Nonce (N) Format ............................<a href="#page-7">7</a>
   <a href="#section-5">5</a>. IKEv2 Associated Data (A) .......................................<a href="#page-8">8</a>
      <a href="#section-5.1">5.1</a>. Associated Data (A) Construction ...........................<a href="#page-8">8</a>
      <a href="#section-5.2">5.2</a>. Data Integrity Coverage ....................................<a href="#page-8">8</a>
   <a href="#section-6">6</a>. AES GCM and AES CCM Encrypted Payload Expansion .................<a href="#page-9">9</a>
   <a href="#section-7">7</a>. IKEv2 Conventions for AES GCM and AES CCM .......................<a href="#page-9">9</a>
      <a href="#section-7.1">7.1</a>. Keying Material and Salt Values ............................<a href="#page-9">9</a>
      <a href="#section-7.2">7.2</a>. IKEv2 Identifiers .........................................<a href="#page-10">10</a>
      <a href="#section-7.3">7.3</a>. Key Length ................................................<a href="#page-10">10</a>
   <a href="#section-8">8</a>. IKEv2 Algorithm Selection ......................................<a href="#page-11">11</a>
   <a href="#section-9">9</a>. Test Vectors ...................................................<a href="#page-11">11</a>
   <a href="#section-10">10</a>. <a href="./rfc5116">RFC 5116</a> AEAD_* Algorithms ....................................<a href="#page-11">11</a>
      <a href="#section-10.1">10.1</a>. AES GCM Algorithms with 8- and 12-octet ICVs .............<a href="#page-12">12</a>
           <a href="#section-10.1.1">10.1.1</a>. AEAD_AES_128_GCM_8 ................................<a href="#page-12">12</a>
           <a href="#section-10.1.2">10.1.2</a>. AEAD_AES_256_GCM_8 ................................<a href="#page-12">12</a>
           <a href="#section-10.1.3">10.1.3</a>. AEAD_AES_128_GCM_12 ...............................<a href="#page-12">12</a>
           <a href="#section-10.1.4">10.1.4</a>. AEAD_AES_256_GCM_12 ...............................<a href="#page-12">12</a>
      <a href="#section-10.2">10.2</a>. AES CCM Algorithms with an 11-octet Nonce ................<a href="#page-13">13</a>
           <a href="#section-10.2.1">10.2.1</a>. AEAD_AES_128_CCM_SHORT ............................<a href="#page-13">13</a>
           <a href="#section-10.2.2">10.2.2</a>. AEAD_AES_256_CCM_SHORT ............................<a href="#page-14">14</a>
           <a href="#section-10.2.3">10.2.3</a>. AEAD_AES_128_CCM_SHORT_8 ..........................<a href="#page-14">14</a>
           <a href="#section-10.2.4">10.2.4</a>. AEAD_AES_256_CCM_SHORT_8 ..........................<a href="#page-14">14</a>
           <a href="#section-10.2.5">10.2.5</a>. AEAD_AES_128_CCM_SHORT_12 .........................<a href="#page-14">14</a>
           <a href="#section-10.2.6">10.2.6</a>. AEAD_AES_256_CCM_SHORT_12 .........................<a href="#page-14">14</a>
      <a href="#section-10.3">10.3</a>. AEAD_* Algorithms and IKEv2 ..............................<a href="#page-15">15</a>
   <a href="#section-11">11</a>. Security Considerations .......................................<a href="#page-15">15</a>
   <a href="#section-12">12</a>. IANA Considerations ...........................................<a href="#page-16">16</a>
   <a href="#section-13">13</a>. Acknowledgments ...............................................<a href="#page-16">16</a>
   <a href="#section-14">14</a>. References ....................................................<a href="#page-17">17</a>
      <a href="#section-14.1">14.1</a>. Normative References .....................................<a href="#page-17">17</a>
      <a href="#section-14.2">14.2</a>. Informative References ...................................<a href="#page-17">17</a>












<span class="grey">Black &amp; McGrew              Standards Track                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   An authenticated encryption algorithm combines encryption and
   integrity into a single operation on plaintext data to produce
   ciphertext that includes an integrity check [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>].  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 AEAD algorithms with the Encrypted
   Payload of the Internet Key Exchange version 2 (IKEv2) protocol.  The
   use of two specific AEAD algorithms with the IKEv2 Encrypted Payload
   is also described; the two algorithms are the Advanced Encryption
   Standard (AES) in Galois/Counter Mode (AES GCM) [<a href="#ref-GCM" title="&quot;NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.&quot;">GCM</a>] and AES in
   Counter with CBC-MAC Mode (AES CCM) [<a href="#ref-CCM" title="&quot;NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality&quot;">CCM</a>].

   Version 1 of the Internet Key Exchange protocol (IKEv1) [<a href="./rfc2409" title="&quot;The Internet Key Exchange (IKE)&quot;">RFC2409</a>] is
   based on the Internet Security Association and Key Management
   Protocol (ISAKMP) [<a href="./rfc2408" title="&quot;Internet Security Association and Key Management Protocol (ISAKMP)&quot;">RFC2408</a>].  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 [<a href="./rfc2408" title="&quot;Internet Security Association and Key Management Protocol (ISAKMP)&quot;">RFC2408</a>]).  This separation of encryption
   from data integrity protection prevents the use of authenticated
   encryption with IKEv1, thus limiting initial specifications of AES
   combined mode usage for IPsec to the Encapsulating Security Payload
   (ESP) [<a href="./rfc2406" title="&quot;IP Encapsulating Security Payload (ESP)&quot;">RFC2406</a>].  The current version of ESP is version 3, ESPv3
   [<a href="./rfc4303" title="&quot;IP Encapsulating Security Payload (ESP)&quot;">RFC4303</a>].

   Version 2 of the Internet Key Exchange Protocol (IKEv2) [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>]
   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 AEAD
   algorithms.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Conventions Used in This Document</span>

   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 [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

   The symbols or variables that designate authenticated encryption and
   decryption operation inputs and outputs (K, N, P, A, and C) are



<span class="grey">Black &amp; McGrew              Standards Track                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


   defined in [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>].  The SK_* symbols or variables that designate
   specific IKEv2 keys are defined in [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Structure of this Document</span>

   This document is based on the RFCs that describe the usage of AES GCM
   [<a href="./rfc4106" title="&quot;The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)&quot;">RFC4106</a>] and AES CCM [<a href="./rfc4309" title="&quot;Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)&quot;">RFC4309</a>] with ESP; 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; many sections of this document indicate which
   sections of those two documents correspond, and call out any
   significant differences that implementers should be aware of.
   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 [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>].  An important
   departure from [<a href="./rfc4106" title="&quot;The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)&quot;">RFC4106</a>] and [<a href="./rfc4309" title="&quot;Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)&quot;">RFC4309</a>] is that these two RFCs
   describe separate ciphertext and integrity check outputs of the
   encryption operation, whereas [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>] 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 [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>] ciphertext (C) output of
   authenticated encryption consists of the [<a href="./rfc4106" title="&quot;The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)&quot;">RFC4106</a>] or [<a href="./rfc4309" title="&quot;Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)&quot;">RFC4309</a>]
   ciphertext output concatenated with the [<a href="./rfc4106" title="&quot;The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)&quot;">RFC4106</a>] or [<a href="./rfc4309" title="&quot;Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)&quot;">RFC4309</a>]
   Integrity Check Value (ICV) output.  This document does not modify
   the AES GCM or AES CCM authenticated encryption algorithms specified
   in [<a href="./rfc4106" title="&quot;The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)&quot;">RFC4106</a>] and [<a href="./rfc4309" title="&quot;Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)&quot;">RFC4309</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  IKEv2 Encrypted Payload Data</span>

   This section is based on [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>] and <a href="./rfc4306#section-3.14">Section&nbsp;3.14 of [RFC4306]</a>.

   For the use of authenticated encryption algorithms with the IKEv2
   Encrypted Payload, this section updates <a href="./rfc4306#section-3.14">Section&nbsp;3.14 of [RFC4306]</a> by
   replacing Figure 21 and the text that follows it (through the end of
   that section) with the contents of this section.  In addition,
   <a href="./rfc4306#section-3.14">Section&nbsp;3.14 of [RFC4306]</a> is also updated to allow the use of a
   single authenticated encryption algorithm instead of a block cipher
   and a separate integrity check algorithm.  In contrast, Sections <a href="#section-3.1">3.1</a>
   and 3.2 of this document are specific to the AES GCM and AES CCM
   algorithms and hence do not update [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>].  The updates to
   [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>] made by this document have no effect when authenticated
   encryption algorithms are neither proposed nor used.



<span class="grey">Black &amp; McGrew              Standards Track                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


   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
   fields, followed by an Initialization Vector (IV) field and a
   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, C bit, and Payload Length fields are unchanged from
   [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>].

   The contents of the Initialization Vector (IV) field are specified by
   the authenticated encryption algorithm; see Sections <a href="#section-3.1">3.1</a> and <a href="#section-4">4</a>
   (below) for AES GCM and AES CCM.

   The Ciphertext field is the output of an authenticated encryption
   operation (see <a href="./rfc5116#section-2.1">Section&nbsp;2.1 of [RFC5116]</a>) 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 [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>].  The
      authenticated encryption algorithm describes how to obtain the
      cipher key from SK_ei or SK_er; for AES GCM and AES CCM, see
      <a href="#section-7.1">Section 7.1</a> (below).

   o  The nonce (N) is specified by the authenticated encryption
      algorithm; for AES GCM and AES CCM, see <a href="#section-4">Section 4</a> (below).  When
      decrypting an Encrypted Payload, a receiver constructs the nonce
      based on the IV in the Encrypted Payload, using rules that are
      specific to the authenticated encryption algorithm; see Sections
      3.1 and 4 (below) for AES GCM and AES CCM.

   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).  The plaintext structure in
      Figure 2 applies to all encryption algorithms used with the IKEv2
      Encrypted Payload, and is unchanged from [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>].



<span class="grey">Black &amp; McGrew              Standards Track                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


   o  The associated data (A) is described in <a href="#section-5">Section 5</a> (below).

                           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)

   The IKE Payloads are as specified in [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>].

   Padding MAY contain any value chosen by the sender.

   Pad Length is the number of octets in the Padding field.  There are
   no alignment requirements on the length of the Padding field; the
   recipient MUST accept any amount of Padding up to 255 octets.

   The ciphertext output of authenticated encryption algorithms, as
   defined by [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>], incorporates data that allows checks on the
   integrity and authenticity of the ciphertext and associated data.
   Thus, there is no need for a separate Integrity Check Value (ICV)
   field in the IKEv2 Encrypted Payload Data structure.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  AES GCM and AES CCM Initialization Vector (IV)</span>

   This section is based on <a href="./rfc4106#section-3.1">Section&nbsp;3.1 of [RFC4106]</a> and <a href="./rfc4309#section-3.1">Section&nbsp;3.1 of
   [RFC4309]</a>.  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 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 MAY 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).

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  AES GCM and AES CCM Ciphertext (C) Construction</span>

   This section is based on <a href="./rfc4106#section-6">Section&nbsp;6 of [RFC4106]</a> and <a href="./rfc4309#section-3.1">Section&nbsp;3.1 of
   [RFC4309]</a> with generalizations to match the interfaces specified in
   [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>].  The constructions for AES GCM and AES CCM are different,
   but in each case, the construction is the same as for ESP.




<span class="grey">Black &amp; McGrew              Standards Track                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


   For AES GCM and AES CCM, the Ciphertext field consists of the output
   of the authenticated 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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  AES GCM and AES CCM Nonce (N) Format</span>

   Specific authenticated encryption algorithms MAY use different nonce
   formats, but they SHOULD use the default nonce format specified in
   this section.

   The default nonce format uses partially implicit nonces (see <a href="./rfc5116#section-3.2.1">Section</a>
   <a href="./rfc5116#section-3.2.1">3.2.1 of [RFC5116]</a>) as follows:

   o  The implicit portion of the nonce is the salt that is part of the
      IKEv2 Keying Material shared by the encryptor and decryptor (see
      <a href="#section-7.1">Section 7.1</a>); the salt is not included in the IKEv2 Encrypted
      Payload.

   o  The explicit portion of the nonce is the IV that is included in
      the IKEv2 Encrypted Payload.

   When this default nonce format is used, both the encryptor and
   decryptor construct the nonce by concatenating the salt with the IV,
   in that order.

   For the use of AES GCM with the IKEv2 Encrypted Payload, this default
   nonce format MUST be used and a 12 octet nonce MUST be used.  Note
   that this format matches the one specified in <a href="./rfc4106#section-4">Section&nbsp;4 of [RFC4106]</a>,
   providing compatibility between the use of AES GCM in IKEv2 and ESP.
   All of the requirements of <a href="./rfc4106#section-4">Section&nbsp;4 of [RFC4106]</a> apply to the use of
   AES GCM with the IKEv2 Encrypted Payload.

   For the use of AES CCM with the IKEv2 Encrypted Payload, this default
   nonce format MUST be used and an 11 octet nonce MUST be used.  Note
   that this format matches the one specified in <a href="./rfc4309#section-4">Section&nbsp;4 of [RFC4309]</a>,
   providing compatibility between the use of AES CCM in IKEv2 and ESP.
   All of the requirements of <a href="./rfc4309#section-4">Section&nbsp;4 of [RFC4309]</a> apply to the use of
   AES CCM with the IKEv2 Encrypted Payload.





<span class="grey">Black &amp; McGrew              Standards Track                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  IKEv2 Associated Data (A)</span>

   This section is based on <a href="./rfc4106#section-5">Section&nbsp;5 of [RFC4106]</a> and <a href="./rfc4309#section-5">Section&nbsp;5 of
   [RFC4309]</a>, 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,
   but differs from the construction used with ESP because IKEv2
   requires different data integrity coverage.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Associated Data (A) Construction</span>

   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 Associated Data (A) for
                         Authenticated Encryption

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

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Data Integrity Coverage</span>

   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
      [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>].



<span class="grey">Black &amp; McGrew              Standards Track                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


   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.

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

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  AES GCM and AES CCM Encrypted Payload Expansion</span>

   The expansion described in <a href="./rfc4106#section-7">Section&nbsp;7 of [RFC4106]</a> and <a href="./rfc4309#section-6">Section&nbsp;6 of
   [RFC4309]</a> applies to the use of the AES GCM and AES CCM combined
   modes with the IKEv2 Encrypted Payload.  See <a href="./rfc4106#section-7">Section&nbsp;7 of [RFC4106]</a>
   and <a href="./rfc4309#section-6">Section&nbsp;6 of [RFC4309]</a>.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  IKEv2 Conventions for AES GCM and AES CCM</span>

   This section describes the conventions used to generate keying
   material and salt values for use with AES GCM and AES CCM using the
   IKEv2 [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>] protocol.  The identifiers and attributes needed to
   use AES GCM and AES CCM with the IKEv2 Encrypted Payload are also
   specified.

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Keying Material and Salt Values</span>

   This section is based on <a href="./rfc4106#section-8.1">Section&nbsp;8.1 of [RFC4106]</a> and <a href="./rfc4309#section-7.1">Section&nbsp;7.1 of
   [RFC4309]</a>.  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 <a href="./rfc4306#section-2.14">Section&nbsp;2.14
   of [RFC4306]</a>.

   This subsection describes how the key derivation specified in <a href="./rfc4306#section-2.14">Section</a>
   <a href="./rfc4306#section-2.14">2.14 of [RFC4306]</a> 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 <a href="./rfc4106#section-8.1">Section&nbsp;8.1 of [RFC4106]</a>
      for the AES key size being used.  For example, if the AES key size



<span class="grey">Black &amp; McGrew              Standards Track                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


      is 128 bits, each encryption key is 20 octets, consisting of a
      16-octet AES cipher key followed by 4 octets of salt.

   o  For AES CCM, each key has the size and format of the "KEYMAT
      requested" material specified in <a href="./rfc4309#section-7.1">Section&nbsp;7.1 of [RFC4309]</a> 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.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  IKEv2 Identifiers</span>

   This section is unique to the 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 the use of AES GCM and AES CCM as the Encryption (ENCR)
   Transform for IKEv2 (i.e., for use with the IKEv2 Encrypted Payload):

         14 for AES CCM with an 8-octet ICV;
         15 for AES CCM with a 12-octet ICV;
         16 for AES CCM with a 16-octet ICV;

         18 for AES GCM with an 8-octet ICV;
         19 for AES GCM with a 12-octet ICV; and
         20 for AES GCM with a 16-octet ICV.

   A 16-octet ICV size SHOULD be used with IKEv2, as the higher level of
   security that it provides by comparison to smaller ICV sizes is
   appropriate to IKEv2's key exchange and related functionality.

   In general, the use of 12-octet ICVs (values 15 and 19) is NOT
   RECOMMENDED in order to reduce the number of options for ICV size.
   If an ICV size larger than 8 octets is appropriate, 16-octet ICVs
   SHOULD be used.

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  Key Length</span>

   This section is based on <a href="./rfc4106#section-8.4">Section&nbsp;8.4 of [RFC4106]</a> and <a href="./rfc4309#section-7.4">Section&nbsp;7.4 of
   [RFC4309]</a>.  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 <a href="#section-7.2">Section 7.2</a> of this document, is used.  The Key Length
   attribute MUST have a value of 128, 192, or 256.  The use of the
   value 192 is NOT RECOMMENDED.  If an AES key larger than 128 bits is




<span class="grey">Black &amp; McGrew              Standards Track                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


   appropriate, a 256-bit AES key SHOULD be used.  This reduces the
   number of options for AES key length.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  IKEv2 Algorithm Selection</span>

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

   IKEv2 (<a href="./rfc4306#section-3.3.3">Section&nbsp;3.3.3 of [RFC4306]</a>) specifies that both an encryption
   algorithm and an integrity checking algorithm are required for an IKE
   SA (Security Association).  This document updates [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>] to
   require 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 [<a href="./rfc4306" title="&quot;Internet Key Exchange (IKEv2) Protocol&quot;">RFC4306</a>] to require that if all of the encryption algorithms
   in any proposal are authenticated encryption algorithms, then the
   proposal MUST NOT propose any integrity transforms.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Test Vectors</span>

   See <a href="./rfc4106#section-9">Section&nbsp;9 of [RFC4106]</a> and <a href="./rfc4309#section-8">Section&nbsp;8 of [RFC4309]</a> for references
   that provide AES GCM and AES CCM test vectors.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  <a href="./rfc5116">RFC 5116</a> AEAD_* Algorithms</span>

   This section adds new algorithms to the AEAD_* algorithm framework
   defined in [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>] to encompass the usage of AES GCM and AES CCM
   with IKEv2.  An AEAD_* algorithm does not have any attributes or
   parameters; each AEAD_* algorithm identifier defined in this document
   completely specifies the AES key size and the ICV size to be used
   (e.g., AEAD_AES_128_GCM uses a 128-bit AES key and a 16-octet ICV).

   AEAD_* algorithm coverage of the AES GCM and AES CCM authenticated
   encryption algorithms used with IKEv2 requires specification of eight
   additional AEAD_* algorithms beyond the four algorithms specified in
   [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>]:

   o  Four AEAD_* algorithms are specified to allow 8- and 12-octet ICVs
      to be used with the AES GCM and AEAD_* algorithms specified in
      [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>].

   o  The version of AES CCM used with IPsec (see [<a href="./rfc4309" title="&quot;Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)&quot;">RFC4309</a>]) uses an
      11-octet nonce instead of the 12-octet nonce used by the version
      of AES CCM specified in [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>].  Six AEAD_* algorithms are
      specified for this short nonce version of AES CCM.





<span class="grey">Black &amp; McGrew              Standards Track                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


   This document recommends against the use of 192-bit AES keys, and
   therefore does not specify AEAD_* algorithms for 192-bit AES keys.

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  AES GCM Algorithms with 8- and 12-octet ICVs</span>

   The following four AEAD_* algorithms are identical to the AEAD_*
   algorithms specified in [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>], except that an 8-octet ICV is used
   instead of a 16-octet ICV.

<span class="h4"><a class="selflink" id="section-10.1.1" href="#section-10.1.1">10.1.1</a>.  AEAD_AES_128_GCM_8</span>

   This algorithm is identical to AEAD_AES_128_GCM (see <a href="./rfc5116#section-5.1">Section&nbsp;5.1 of
   [RFC5116]</a>), except that the tag length, t, is 8, and an
   authentication tag with a length of 8 octets (64 bits) is used.

   An AEAD_AES_128_GCM_8 ciphertext is exactly 8 octets longer than its
   corresponding plaintext.

<span class="h4"><a class="selflink" id="section-10.1.2" href="#section-10.1.2">10.1.2</a>.  AEAD_AES_256_GCM_8</span>

   This algorithm is identical to AEAD_AES_256_GCM (see <a href="./rfc5116#section-5.2">Section&nbsp;5.2 of
   [RFC5116]</a>), except that the tag length, t, is 8, and an
   authentication tag with a length of 8 octets (64 bits) is used.

   An AEAD_AES_256_GCM_8 ciphertext is exactly 8 octets longer than its
   corresponding plaintext.

<span class="h4"><a class="selflink" id="section-10.1.3" href="#section-10.1.3">10.1.3</a>.  AEAD_AES_128_GCM_12</span>

   This algorithm is identical to AEAD_AES_128_GCM (see <a href="./rfc5116#section-5.1">Section&nbsp;5.1 of
   [RFC5116]</a>), except that the tag length, t, is 12, and an
   authentication tag with a length of 12 octets (64 bits) is used.

   An AEAD_AES_128_GCM_12 ciphertext is exactly 12 octets longer than
   its corresponding plaintext.

<span class="h4"><a class="selflink" id="section-10.1.4" href="#section-10.1.4">10.1.4</a>.  AEAD_AES_256_GCM_12</span>

   This algorithm is identical to AEAD_AES_256_GCM (see <a href="./rfc5116#section-5.2">Section&nbsp;5.2 of
   [RFC5116]</a>, except that the tag length, t, is 12 and an authentication
   tag with a length of 12 octets (64 bits) is used.

   An AEAD_AES_256_GCM_12 ciphertext is exactly 12 octets longer than
   its corresponding plaintext.







<span class="grey">Black &amp; McGrew              Standards Track                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  AES CCM Algorithms with an 11-octet Nonce</span>

   The following four AEAD algorithms employ the AES CCM algorithms with
   an 11 octet nonce as specified in [<a href="./rfc4309" title="&quot;Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)&quot;">RFC4309</a>].

<span class="h4"><a class="selflink" id="section-10.2.1" href="#section-10.2.1">10.2.1</a>.  AEAD_AES_128_CCM_SHORT</span>

   The AEAD_AES_128_CCM_SHORT authenticated encryption algorithm is
   identical to the AEAD_AES_128_CCM algorithm (see <a href="./rfc5116#section-5.3">Section&nbsp;5.3 of
   [RFC5116]</a>), except that it uses a nonce that is one octet shorter.
   AEAD_AES_128_CCM_SHORT works as specified in [<a href="#ref-CCM" title="&quot;NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality&quot;">CCM</a>].  It uses AES-128
   as the block cipher by providing the key, nonce, associated data, and
   plaintext to that mode of operation.  The formatting and counter
   generation function are as specified in <a href="#appendix-A">Appendix A</a> of [<a href="#ref-CCM" title="&quot;NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality&quot;">CCM</a>], and the
   values of the parameters identified in that appendix are as follows:

         the nonce length n is 11,

         the tag length t is 16, and

         the value of q is 3.

   An authentication tag with a length of 16 octets (128 bits) is used.
   The AEAD_AES_128_CCM_SHORT ciphertext consists of the ciphertext
   output of the CCM encryption operation concatenated with the
   authentication tag output of the CCM encryption operation.  Test
   cases are provided in [<a href="#ref-CCM" title="&quot;NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality&quot;">CCM</a>].  The input and output lengths are as
   follows:

         K_LEN is 16 octets,

         P_MAX is 2^24 - 1 octets,

         A_MAX is 2^64 - 1 octets,

         N_MIN and N_MAX are both 11 octets, and

         C_MAX is 2^24 + 15 octets.

   An AEAD_AES_128_CCM_SHORT ciphertext is exactly 16 octets longer than
   its corresponding plaintext.










<span class="grey">Black &amp; McGrew              Standards Track                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


<span class="h4"><a class="selflink" id="section-10.2.2" href="#section-10.2.2">10.2.2</a>.  AEAD_AES_256_CCM_SHORT</span>

   This algorithm is identical to AEAD_AES_128_CCM_SHORT, but with the
   following differences:

         K_LEN is 32 octets, instead of 16, and

         AES-256 CCM is used instead of AES-128 CCM.

   An AEAD_AES_256_CCM_SHORT ciphertext is exactly 16 octets longer than
   its corresponding plaintext.

<span class="h4"><a class="selflink" id="section-10.2.3" href="#section-10.2.3">10.2.3</a>.  AEAD_AES_128_CCM_SHORT_8</span>

   This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that
   the tag length, t, is 8, and an authentication tag with a length of 8
   octets (64 bits) is used.

   An AEAD_AES_128_CCM_SHORT_8 ciphertext is exactly 8 octets longer
   than its corresponding plaintext.

<span class="h4"><a class="selflink" id="section-10.2.4" href="#section-10.2.4">10.2.4</a>.  AEAD_AES_256_CCM_SHORT_8</span>

   This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that
   the tag length, t, is 8, and an authentication tag with a length of 8
   octets (64 bits) is used.

   An AEAD_AES_256_CCM_SHORT_8 ciphertext is exactly 8 octets longer
   than its corresponding plaintext.

<span class="h4"><a class="selflink" id="section-10.2.5" href="#section-10.2.5">10.2.5</a>.  AEAD_AES_128_CCM_SHORT_12</span>

   This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that
   the tag length, t, is 12, and an authentication tag with a length of
   12 octets (64 bits) is used.

   An AEAD_AES_128_CCM_SHORT_12 ciphertext is exactly 12 octets longer
   than its corresponding plaintext.

<span class="h4"><a class="selflink" id="section-10.2.6" href="#section-10.2.6">10.2.6</a>.  AEAD_AES_256_CCM_SHORT_12</span>

   This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that
   the tag length, t, is 12, and an authentication tag with a length of
   8 octets (64 bits) is used.

   An AEAD_AES_256_CCM_SHORT_12 ciphertext is exactly 12 octets longer
   than its corresponding plaintext.




<span class="grey">Black &amp; McGrew              Standards Track                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


<span class="h3"><a class="selflink" id="section-10.3" href="#section-10.3">10.3</a>.  AEAD_* Algorithms and IKEv2</span>

   The following table lists the AES CCM and AES GCM AEAD_* algorithms
   that can be negotiated by IKEv2 and provides the IKEv2 Encryption
   (ENCR) Transform Identifier and Key Length Attribute combination that
   is used to negotiate each algorithm.

      +--------------------------+------------------+-------------+
      | AEAD algorithm           | ENCR Identifier  | Key Length  |
      +--------------------------+------------------+-------------+
      | AEAD_AES_128_GCM         |        20        |     128     |
      | AEAD_AES_256_GCM         |        20        |     256     |
      | AEAD_AES_128_GCM_8       |        18        |     128     |
      | AEAD_AES_256_GCM_8       |        18        |     256     |
      | AEAD_AES_128_GCM_12      |        19        |     128     |
      | AEAD_AES_256_GCM_12      |        19        |     256     |
      | AEAD_AES_128_CCM_SHORT   |        16        |     128     |
      | AEAD_AES_256_CCM_SHORT   |        16        |     256     |
      | AEAD_AES_128_CCM_SHORT_8 |        14        |     128     |
      | AEAD_AES_256_CCM_SHORT_8 |        14        |     256     |
      | AEAD_AES_128_CCM_SHORT_12|        15        |     128     |
      | AEAD_AES_256_CCM_SHORT_12|        15        |     256     |
      +--------------------------+------------------+-------------+

   Each of the above AEAD_* algorithms is identical to the algorithm
   designated by the combination of the IKEv2 ENCR Identifier and Key
   Length Attribute shown on the same line of the table.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Security Considerations</span>

   For authenticated encryption security considerations, see the
   entirety of [<a href="./rfc5116" title="&quot;An Interface and Algorithms for Authenticated Encryption&quot;">RFC5116</a>], not just its security considerations section;
   there are important security considerations that are discussed
   outside the security considerations section of that document.

   The security considerations for the use of AES GCM and AES CCM with
   ESP apply to the use of these algorithms with the IKEv2 Encrypted
   Payload, see <a href="./rfc4106#section-10">Section&nbsp;10 of [RFC4106]</a> and <a href="./rfc4309#section-9">Section&nbsp;9 of [RFC4309]</a>.  Use
   of AES GCM and AES CCM with IKEv2 does not create additional security
   considerations beyond those for the use of AES GCM and AES CCM with
   ESP.

   For IKEv2 security considerations, see <a href="./rfc4306#section-5">Section&nbsp;5 of [RFC4306]</a>.








<span class="grey">Black &amp; McGrew              Standards Track                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  IANA Considerations</span>

   The Encryption Transform identifiers specified in <a href="#section-7.2">Section 7.2</a> have
   been previously assigned by IANA for use with ESP.  This document
   extends their usage to IKEv2 for the Encrypted Payload.  No IANA
   actions are required for this usage extension.

   IANA has added the following entries to the Authenticated Encryption
   with Associated Data (AEAD) Parameters Registry:

   +--------------------------+----------------+--------------------+
   | Name                     |  Reference     | Numeric Identifier |
   +--------------------------+----------------+--------------------+
   | AEAD_AES_128_GCM_8       | <a href="#section-10.1.1">Section 10.1.1</a> |          5         |
   | AEAD_AES_256_GCM_8       | <a href="#section-10.1.2">Section 10.1.2</a> |          6         |
   | AEAD_AES_128_GCM_12      | <a href="#section-10.1.3">Section 10.1.3</a> |          7         |
   | AEAD_AES_256_GCM_12      | <a href="#section-10.1.4">Section 10.1.4</a> |          8         |
   | AEAD_AES_128_CCM_SHORT   | <a href="#section-10.2.1">Section 10.2.1</a> |          9         |
   | AEAD_AES_256_CCM_SHORT   | <a href="#section-10.2.2">Section 10.2.2</a> |         10         |
   | AEAD_AES_128_CCM_SHORT_8 | <a href="#section-10.2.3">Section 10.2.3</a> |         11         |
   | AEAD_AES_256_CCM_SHORT_8 | <a href="#section-10.2.4">Section 10.2.4</a> |         12         |
   | AEAD_AES_128_CCM_SHORT_12| <a href="#section-10.2.5">Section 10.2.5</a> |         13         |
   | AEAD_AES_256_CCM_SHORT_12| <a href="#section-10.2.6">Section 10.2.6</a> |         14         |
   +--------------------------+----------------+--------------------+

   An IANA registration of an AEAD algorithm does not constitute an
   endorsement of that algorithm or its security.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  Acknowledgments</span>

   See <a href="./rfc4106#section-13">Section&nbsp;13 of [RFC4106]</a> and <a href="./rfc4309#section-12">Section&nbsp;12 of [RFC4309]</a> for AES GCM
   and AES CCM acknowledgments.

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

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












<span class="grey">Black &amp; McGrew              Standards Track                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>.  References</span>

<span class="h3"><a class="selflink" id="section-14.1" href="#section-14.1">14.1</a>.  Normative References</span>

   [<a id="ref-CCM">CCM</a>]     Dworkin, M., "NIST Special Publication 800-38C: The CCM
             Mode for Authentication and Confidentiality", U.S. National
             Institute of Standards and Technology,
             &lt;<a href="http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf">http://csrc.nist.gov/publications/nistpubs/800-38C/</a>
             <a href="http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf">SP800-38C.pdf</a>&gt;, updated July 2007.

   [<a id="ref-GCM">GCM</a>]     Dworkin, M., "NIST Special Publication 800-38D:
             Recommendation for Block Cipher Modes of Operation:
             Galois/Counter Mode (GCM) and GMAC.", U.S. National
             Institute of Standards and Technology, November 2007,
             &lt;<a href="http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf">http://csrc.nist.gov/publications/nistpubs/800-38D/</a>
             <a href="http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf">SP-800-38D.pdf</a>&gt;, November 2007.

   [<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC4106">RFC4106</a>] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
             (GCM) in IPsec Encapsulating Security Payload (ESP)", <a href="./rfc4106">RFC</a>
             <a href="./rfc4106">4106</a>, June 2005.

   [<a id="ref-RFC4303">RFC4303</a>] Kent, S., "IP Encapsulating Security Payload (ESP)", <a href="./rfc4303">RFC</a>
             <a href="./rfc4303">4303</a>, December 2005.

   [<a id="ref-RFC4306">RFC4306</a>] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
             <a href="./rfc4306">RFC 4306</a>, December 2005.

   [<a id="ref-RFC4309">RFC4309</a>] Housley, R., "Using Advanced Encryption Standard (AES) CCM
             Mode with IPsec Encapsulating Security Payload (ESP)", <a href="./rfc4309">RFC</a>
             <a href="./rfc4309">4309</a>, December 2005.

   [<a id="ref-RFC5116">RFC5116</a>] McGrew, D., "An Interface and Algorithms for Authenticated
             Encryption", <a href="./rfc5116">RFC 5116</a>, January 2008.

<span class="h3"><a class="selflink" id="section-14.2" href="#section-14.2">14.2</a>.  Informative References</span>

   [<a id="ref-RFC2406">RFC2406</a>] Kent, S. and R. Atkinson, "IP Encapsulating Security
             Payload (ESP)", <a href="./rfc2406">RFC 2406</a>, November 1998.

   [<a id="ref-RFC2408">RFC2408</a>] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
             "Internet Security Association and Key Management Protocol
             (ISAKMP)", <a href="./rfc2408">RFC 2408</a>, November 1998.

   [<a id="ref-RFC2409">RFC2409</a>] Harkins, D. and D. Carrel, "The Internet Key Exchange
             (IKE)", <a href="./rfc2409">RFC 2409</a>, November 1998.



<span class="grey">Black &amp; McGrew              Standards Track                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


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

   Phone: +1 (408) 525-8651
   EMail: mcgrew@cisco.com

































<span class="grey">Black &amp; McGrew              Standards Track                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5282">RFC 5282</a>           Authenticated Encryption and IKEv2        August 2008</span>


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   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
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   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.












Black &amp; McGrew              Standards Track                    [Page 19]
</pre>