Network Working Group                                           D. Black
Request for Comments: 5282                                           EMC
Updates: 4306                                                  D. McGrew
Category: Standards Track                                    August 2008


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

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.



















Black & McGrew              Standards Track                     [Page 1]


RFC 5282           Authenticated Encryption and IKEv2        August 2008


Table of Contents

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












Black & McGrew              Standards Track                     [Page 2]


RFC 5282           Authenticated Encryption and IKEv2        August 2008


1.  Introduction

   An authenticated encryption algorithm combines encryption and
   integrity into a single operation on plaintext data to produce
   ciphertext that includes an integrity check [RFC5116].  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) [GCM] and AES in
   Counter with CBC-MAC Mode (AES CCM) [CCM].

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

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

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

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



Black & McGrew              Standards Track                     [Page 3]


RFC 5282           Authenticated Encryption and IKEv2        August 2008


   defined in [RFC5116].  The SK_* symbols or variables that designate
   specific IKEv2 keys are defined in [RFC4306].

2.  Structure of this Document

   This document is based on the RFCs that describe the usage of AES GCM
   [RFC4106] and AES CCM [RFC4309] with ESP; 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 [RFC5116].  An important
   departure from [RFC4106] and [RFC4309] is that these two RFCs
   describe separate ciphertext and integrity check outputs of the
   encryption operation, whereas [RFC5116] specifies a single ciphertext
   (C) output that includes an integrity check.  The latter more general
   approach encompasses authenticated encryption algorithms that produce
   a single, expanded ciphertext output into which the integrity check
   is incorporated, rather than producing separate ciphertext and
   integrity check outputs.

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

3.  IKEv2 Encrypted Payload Data

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

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