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

Versions: 00 01 02 03 04 05 RFC 5116

Network Working Group                                          D. McGrew
Internet-Draft                                       Cisco Systems, Inc.
Expires: April 26, 2007                                 October 23, 2006


        An Interface and Algorithms for Authenticated Encryption
                      draft-mcgrew-auth-enc-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This draft defines algorithms for authenticated encryption with
   additional authenticated data (AEAD), and defines a uniform interface
   and a registry for such algorithms.  The interface and registry can
   be used as an application independent set of cryptoalgorithm suites.
   This approach provides advantages in efficiency and security, and
   promotes the reuse of crypto implementations.






McGrew                   Expires April 26, 2007                 [Page 1]


Internet-Draft          Authenticated Encryption            October 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Background . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2   Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3   Benefits . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.4   Conventions Used In This Document  . . . . . . . . . . . .  4
   2.  AEAD Interface . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1   Authenticated Encryption . . . . . . . . . . . . . . . . .  5
     2.2   Authenticated Decryption . . . . . . . . . . . . . . . . .  7
     2.3   Data Formatting  . . . . . . . . . . . . . . . . . . . . .  7
   3.  Recommended Nonce Formation  . . . . . . . . . . . . . . . . .  8
   4.  Requirements on the use of AEAD algorithms . . . . . . . . . . 10
   5.  Requirements on AEAD algorithms  . . . . . . . . . . . . . . . 11
   6.  AEAD Algorithms  . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1   AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 12
       6.1.1   AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . 12
     6.2   AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 12
       6.2.1   AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . 13
     6.3   AEAD_AES_128_HMAC_SHA1 . . . . . . . . . . . . . . . . . . 13
       6.3.1   Test Cases . . . . . . . . . . . . . . . . . . . . . . 15
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 20
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 21
     11.1  Normative References . . . . . . . . . . . . . . . . . . . 21
     11.2  Informative References . . . . . . . . . . . . . . . . . . 21
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22
       Intellectual Property and Copyright Statements . . . . . . . . 23





















McGrew                   Expires April 26, 2007                 [Page 2]


Internet-Draft          Authenticated Encryption            October 2006


1.  Introduction

   Authenticated encryption is a form of encryption that, in addition to
   providing confidentiality for the plaintext that is encrypted,
   provides a way to check its integrity and authenticity.
   Authenticated encryption with Associated Data, or AEAD, adds the
   ability to check the integrity and authenticity of some additional
   "associated data" that is not encrypted.

1.1  Background

   Many cryptographic applications require both confidentiality and
   message authentication.  Often an encryption method and a message
   authentication code (MAC) are used to provide those security
   services, with each algorithm using an independent key.  More
   recently, the idea of providing both security services using a single
   cryptoalgorithm has become accepted.  In this concept, the cipher and
   MAC are replaced by an Authenticated Encryption with Associated Data
   (AEAD) algorithm.  Several crypto algorithms that implement AEAD
   algorithms have been defined, including block cipher modes of
   operation and dedicated algorithms.  Some of these algorithms have
   been adopted and proven useful in practice.  Additionally, AEAD is
   close to an 'idealized' view of encryption, such as those used in the
   automated analysis of cryptographic protocols.

1.2  Scope

   In this document we define an AEAD algorithm as an abstraction, by
   specifying an interface to an AEAD and defining an IANA registry for
   AEAD algorithms.  We populate this registry with five AEAD
   algorithms: AES in Galois/Counter Mode [GCM] with 128 and 256 bit
   keys, AES in Counter and CBC MAC mode [CCM] with 128 and 256 bit
   keys, and an algorithm that composes AES-128 CBC and HMAC-SHA1.  This
   approach enables applications that need cryptographic security
   services to more easily adopt those services.

   In the following, we define the AEAD interface (Section 2), and then
   outline the requirements that each AEAD algorithm must meet
   (Section 5) and provide guidance on the use of AEAD algorithms
   (Section 4).  Then we define five AEAD algorithms (Section 6), and
   establish an IANA registry for AEAD algorithms (Section 7).  Lastly,
   we discuss some open questions (Section 8).

   The AEAD interface specification does not address security protocol
   issues such as anti-replay services or access control decisions that
   are made on authenticated data.  Instead, the specification aims to
   abstract the cryptography away from those issues.  The interface, and
   the guidance about how to use it, are consistent with the



McGrew                   Expires April 26, 2007                 [Page 3]


Internet-Draft          Authenticated Encryption            October 2006


   recommendations from [EEM04].


1.3  Benefits

   The approach benefits the application designer by allowing them to
   focus on the important issues of security services, canonicalization,
   and data marshaling, and relieving them of the need to design crypto
   mechanisms that meet their security goals.  Importantly, the security
   of an AEAD algorithm can be analyzed independent from its use in a
   particular application.  This property frees the user of the AEAD of
   the need to consider security aspects such as the relative order of
   authentication and encryption and the security of the particular
   combination of cipher and MAC, such as the potential loss of
   confidentiality through the MAC.  The application designer that uses
   the AEAD interface need not select a particular AEAD algorithm during
   the design stage.  Additionally, the interface to the AEAD is
   relatively simple, since it requires only a single key as input and
   it requires only a single identifier to indicate the algorithm in use
   in a particular case.

   The AEAD approach benefits the implementer of the crypto algorithms
   by making available optimizations that are otherwise not possible to
   reduce the amount of computation, the implementation cost, and/or the
   storage requirements.  The simpler interface makes testing easier;
   this is a considerable benefit for a crypto algorithm implementation.
   By providing a uniform interface to access cryptographic services,
   the AEAD approach allows a single crypto implementation to easily
   support multiple applications.  For example, a hardware module that
   supports the AEAD interface can easily provide crypto acceleration to
   any application using that interface, even to applications that had
   not been designed when the module was built.

1.4  Conventions Used In This Document

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













McGrew                   Expires April 26, 2007                 [Page 4]


Internet-Draft          Authenticated Encryption            October 2006


2.  AEAD Interface

   An AEAD algorithm has two operations, authenticated encryption and
   authenticated decryption.  The inputs and outputs of these algorithms
   are defined in terms of octet strings.

   An implementation MAY accept additional inputs.  For example, an
   input could be provided to allow the user to select between different
   implementation strategies.  However, such extensions MUST NOT affect
   interoperability.

2.1  Authenticated Encryption

   The authenticated encryption operation has four inputs, each of which
   is an octet string:

      A secret key K, which MUST be generated in a way that is uniformly
      random or pseudorandom.

      An nonce N. Each nonce provided to distinct invocations of the
      Authenticated Encryption operation MUST be distinct, for any
      particular value of the key; applications SHOULD use the nonce
      formation method defined in Section 3, and MAY use any other
      method that meets this requirement.

      A plaintext P, which contains the data to be encrypted and
      authenticated,

      The additional authenticated data A, which contains the data to be
      authenticated, but not encrypted.

   There is a single output:

      A ciphertext C, which is as least as long as the plaintext, or

      an indication that the requested encryption operation could not be
      performed.

   All of the inputs and outputs are variable-length octet strings,
   whose lengths obey the following restrictions:

      The number of octets in the key K is between one and 256.  For
      each AEAD algorithm, the length of K MUST be fixed.

      The number of octets in the nonce is between one and 2^64 - 1,
      inclusive.  However, the length SHOULD be twelve (12) octets.





McGrew                   Expires April 26, 2007                 [Page 5]


Internet-Draft          Authenticated Encryption            October 2006


      The number of octets in the plaintext P is between zero and 2^64 -
      1, inclusive.

      The number of octets in the additional authenticated data AAD is
      between zero and 2^64 - 1, inclusive.

      The number of octets in the ciphertext C is between zero and 2^64
      + 255.

   An AEAD algorithm MAY further restrict the lengths of its inputs and
   outputs.  A particular AEAD implementation MAY further restrict the
   lengths of its inputs and outputs.  If a particular implementation of
   an AEAD algorithm is requested to process an input that is outside
   the range of admissible lengths, or an input that is outside the
   range of lengths supported by that implementation, it MUST return an
   error code and it MUST NOT output any other information.  In
   particular, partially encrypted or partially decrypted data MUST NOT
   be returned.

   Both confidentiality and message authentication is provided on the
   plaintext P. When the length of P is zero, the AEAD algorithm acts as
   a Message Authentication Code on the input A.

   The additional authenticated data A is used to protect information
   that needs to be authenticated, but which does not need to be kept
   confidential.  When using an AEAD to secure a network protocol, for
   example, this input could include addresses, ports, sequence numbers,
   protocol version numbers, and other fields that indicate how the
   plaintext or ciphertext should be handled, forwarded, or processed.
   In many situations, it is desirable to authenticate these fields,
   though they must be left in the clear to allow the network or system
   to function properly.  When this data is included in the input A,
   authentication is provided without copying the data into the
   ciphertext.

   The nonce is authenticated internally to the algorithm, and it is not
   necessary to include it in the AAD input.  The nonce MAY be included
   in P or A if it convenient to the application.

   The nonce MAY be transported along with the plaintext.  The entire IV
   need not be transmitted; it is sufficient to provide the receiver
   with enough information to allow the nonce to be reconstructed.
   Because the authenticated decryption process detects incorrect nonce
   values, no security failure results when a receiver incorrectly
   reconstructs an IV.  Any such reconstruction method will need to take
   into account the possible loss or reorder of ciphertexts between the
   encryption and decryption processes.




McGrew                   Expires April 26, 2007                 [Page 6]


Internet-Draft          Authenticated Encryption            October 2006


   Applications MUST NOT assume any particular structure or formatting
   of the ciphertext.

2.2  Authenticated Decryption

   The authenticated decryption operation has four inputs: K, IV , A and
   C, as defined above.  It has only a single output, either a plaintext
   value P or a special symbol FAIL that indicates that the inputs are
   not authentic.  A ciphertext C , nonce N , and additional
   authenticated data A are authentic for key K when IV, and C is
   generated by the encrypt operation with inputs K, IV, P and A, for
   some values of IV, P, and A. The authenticated decrypt operation
   will, with high probability, return FAIL whenever its inputs were not
   created by the encrypt operation with the identical key (assuming
   that the AEAD algorithm is secure).

2.3  Data Formatting

   This document does not specify any particular encoding for the AEAD
   inputs and outputs, since the encoding does not affect the security
   services provided by an AEAD algorithm.

   When formatting a ciphertext, an application SHOULD position the
   ciphertext C so that it appears after any other data that is needed
   to construct the other inputs to the Authenticated Decryption
   operation.  For example, if the nonce and ciphertext both appear in a
   packet, the former value should precede the latter.  This rule
   facilitates efficient and simple implementations of AEAD algorithms.























McGrew                   Expires April 26, 2007                 [Page 7]


Internet-Draft          Authenticated Encryption            October 2006


3.  Recommended Nonce Formation

   It is essential for security that the nonces be constructed in a
   manner that respects the requirements that each nonce value be
   distinct for each invocation of the Authenticated Encryption
   operation, for any fixed value of the key.  Special attention must be
   paid to the case in which there are multiple encryption devices using
   a single key.

   The following method to construct nonces is RECOMMENDED.  The nonce
   is formatted as illustrated in Figure 1, with the initial octets
   consisting of a Fixed field, and the final octets consisting of a
   Counter field.  Both fields have variable lengths.
    <----- variable ----> <----------- variable ----------->
   +---------------------+----------------------------------+
   |        Fixed        |              Counter             |
   +---------------------+----------------------------------+

                    Figure 1: Recommended nonce format.

   The Counter field is regarded as an unsigned integer in network byte
   order.  The Counter part is equal to one for the first nonce, and it
   increments by one for each successive nonce that is generated.  The
   integer part is never equal to the all-zero value.  Thus at most
   2^(8*C) - 1 nonces can be generated when the Counter field is C
   octets in length.

   The Fixed field MUST remain constant for all nonces that are
   generated for a given encryption device.  However, if different
   devices are performing encryption with a single key, then each
   distinct device MUST use a distinct Fixed field, to ensure the
   uniqueness of the nonces.  Thus at most 2^(8*F) distinct senders can
   share a key when the Fixed field is F octets in length.  When the
   number of encrypters is less than this value, the initial octets of
   the Fixed fields MUST be chosen so that they are common across all
   encrypters.  The final octets of the Fixed field will need to be
   distinct across all encrypters.  This substructure is shown in
   Figure 2.

   In some cases it is desirable to not transmit or store an entire
   nonce, but instead to reconstruct that value immediately prior to
   decryption.  In these cases, it is RECOMMENDED that the distinct
   final octets of the Fixed field, and the Counter field, be explicitly
   transmitted or stored, while the common initial octets of the Fixed
   field be stored with the key.  The explicit information is shown in
   Figure 2.  However, applications MAY use any method of reconstructing
   nonces that is convenient.




McGrew                   Expires April 26, 2007                 [Page 8]


Internet-Draft          Authenticated Encryption            October 2006


    <------------- Fixed field ------------>
   +-------------------+--------------------+---------------+
   |   Fixed (common)  :  Fixed (distinct)  |    Counter    |
   +-------------------+--------------------+---------------+
                        <------------ explicit ------------->

               Figure 2: Nonce structure and reconstruction

      Rationale.  This method of nonce construction incorporates the
      best known practice, and facilitates the reconstruction of nonces
      from partial explicit information.  It is used by both GCM ESP
      [RFC4106] and CCM ESP [RFC4309], in which the Fixed field contains
      the Salt value and the lowest eight octets of the nonce are
      explicitly carried in the ESP packet.  In GCM ESP, the Fixed field
      must be at least four octets long, so that it can contain the Salt
      value.  In CCM ESP, the Fixed field must be at least three octets
      long for the same reason.  This nonce generation method is also
      used by several counter mode variants including CTR ESP.

































McGrew                   Expires April 26, 2007                 [Page 9]


Internet-Draft          Authenticated Encryption            October 2006


4.  Requirements on the use of AEAD algorithms

   This section provides advice that must be followed in order to use an
   AEAD algorithm securely.

   If the AAD input is constructed out of multiple data elements, then
   it is essential that it be unambiguously parseable into its
   constituent elements, without the use of any unauthenticated data in
   the parsing process.  This requirement ensures that an attacker
   cannot fool a receiver into accepting a bogus set of data elements as
   authentic by altering a set of data elements that were used to
   construct an AAD input in an authenticated encryption operation in
   such a way that the data elements are different, but the AAD input is
   unchanged.  This requirement is trivially met if the AAD is composed
   of fixed-width elements.  If the AAD contains a variable-length
   string, for example, this requirement can be met by also including
   the length of the string in the AAD.

   Similarly, if the plaintext is constructed out of multiple data
   elements, then it is essential that it be unambiguously parseable
   into its constituent elements, without using any unauthenticated data
   in the parsing process.  Note that data that included in the AAD may
   be used when parsing the plaintext, though of course since the AAD is
   not encrypted there is a potential loss of confidentiality when
   information about the plaintext is included in the AAD.


























McGrew                   Expires April 26, 2007                [Page 10]


Internet-Draft          Authenticated Encryption            October 2006


5.  Requirements on AEAD algorithms

   Each AEAD algorithm MUST only accept keys with a fixed key length
   K_LEN, and MUST NOT require any particular data format for the keys
   provided as input.  An algorithm that requires such structure
   internally (e.g. one with subkeys in a particular parity-check
   format) will need to provide it internally.

   Each AEAD algorithm MUST accept any plaintext with a length between
   zero and P_MAX octets, where the value P_MAX is specific to that
   algorithm.

   Each AEAD algorithm MUST accept any additional authenticated data
   with a length between zero and A_MAX octets, where the value A_MAX is
   specific to that algorithm.

   Each AEAD algorithm MUST accept any IV with a length between N_MIN
   and N_MAX octets, where the values of N_MIN and N_MAX are specific to
   that algorithm.  Each algorithm SHOULD accept an IV with a length of
   twelve (12) octets.

   An AEAD algorithm MAY structure its ciphertext output in any way; for
   example, the ciphertext can incorporate an authentication tag.  Each
   algorithm SHOULD choose a structure that is amenable to efficient
   processing.

   An Authenticated Encryption algorithm MAY incorporate a random
   source, e.g. for the generation of an internal initialization vector
   that is incorporated into the ciphertext output.  An algorithm that
   uses an internal random initialization vector in this manner MAY have
   a value of N_MAX that is equal to zero.

   The specification of an AEAD algorithm MUST include the values of
   K_LEN, P_MAX, A_MAX, N_MIN, and N_MAX defined above.  Additionally,
   it MUST specify the number of octets in the largeset possible
   ciphertext, which we denote C_MAX.

   Each AEAD algorithm MUST provide a description relating the length of
   the plaintext to that of the ciphertext.












McGrew                   Expires April 26, 2007                [Page 11]


Internet-Draft          Authenticated Encryption            October 2006


6.  AEAD Algorithms

   This section defines five AEAD algorithms; two are based on AES GCM,
   two are based on AES CCM, and one is based on a composition of AES
   CBC and HMAC SHA1.  Each pair includes an algorithm with a key size
   of 128 bits and one with a key size of 256 bits.

6.1  AEAD_AES_128_GCM

   The AEAD_AES_128_GCM authenticated encryption algorithm works as
   specified in [GCM], by providing the key, nonce, and plaintext, and
   additional authenticated data to that mode of operation.  An
   authentication tag with a length of 16 octets (128 bits) is used.
   The AEAD_AES_128_GCM ciphertext is formed by appending the
   authentication tag provided as an output to the GCM encryption
   operation to the ciphertext that is output by that operation.  Test
   cases are provided in the appendix of [GCM].  The input and output
   lengths are as follows:

      K_LEN is 16 octets,

      P_MAX is 2^36 - 31 octets,

      A_MAX is 2^61 - 1 octets,

      N_MIN is 1 (one) octet and N_MAX is 2^61 -1 octets; applications
      SHOULD use an nonce length of 12 octets, since GCM is optimized
      for that length,

      C_MAX is 2^36 - 15 octets.


6.1.1  AEAD_AES_256_GCM

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

      K_LEN is 32 octets, instead of 16 octets, and

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


6.2  AEAD_AES_128_CCM

   The AEAD_AES_128_CCM authenticated encryption algorithm works as
   specified in [CCM], by providing the key, nonce, additional
   authenticated data, and plaintext to that mode of operation.  The
   formatting and counter generation function are as specified in



McGrew                   Expires April 26, 2007                [Page 12]


Internet-Draft          Authenticated Encryption            October 2006


   Appendix A of that reference, and the values of the parameters
   identified in that appendix are as follows:

      the nonce length n is 12,

      the tag length t is 16, and

      the value q is 3.

   An authentication tag with a length of 16 octets (128 bits) is used.
   The AEAD_AES_128_CCM ciphertext is formed by appending the
   authentication tag provided as an output to the CCM encryption
   operation to the ciphertext that is output by that operation.  Test
   cases are provided in [CCM].  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 12 octets, and

      C_MAX is 2^24 + 15 octets.


6.2.1  AEAD_AES_256_CCM

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

      K_LEN is 32 octets, instead of 16, and

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


6.3  AEAD_AES_128_HMAC_SHA1

   This algorithm random and stateless.  It is based on the "generic
   composition" of CBC encryption with HMAC authentication, with the the
   encrypt-then-MAC method [AE].  It uses the HMAC message
   authentication code [RFC2104] with the SHA-1 hash function [SHA1] to
   provide message authentication.  Test cases for HMAC_SHA1 are
   provided in [RFC2202].  For encryption, it uses AES-128 in the cipher
   block chaining (CBC) mode of operation as defined in Section 6.2 of
   [MODES], with the padding method defined by Appendix A of the same
   reference.  The input key is 128 bits long, and the CBC IV is



McGrew                   Expires April 26, 2007                [Page 13]


Internet-Draft          Authenticated Encryption            October 2006


   generated uniformly at random, and is also 128 bits long.

   The authenticated encryption algorithm is as follows, or uses an
   equivalent set of steps:

   1.  Generate the secondary keys MAC_KEY and ENC_KEY from the input
       key K as follows:

          MAC_KEY = HMAC_SHA1(K, "MAC");

          ENC_KEY = leftmost(HMAC_SHA1(K, "ENC"), 128);

       where the function leftmost(X, m) accepts a bitstring X and a
       non-negative integer m and returns the bitstring containing the
       leftmost m bits of X. MAC_KEY is 160 bits long, and ENC_KEY is
       128 bits long.

   2.  Generate a 128-bit IV uniformly at random.  (A pseudorandom
       process MAY be used if its strength is equivalent to AES-128.)
       Note that this IV is distinct from the nonce provided as an input
       to the authenticated encryption operation.

   3.  Pad the plaintext by appending a single '1' bit to that data and
       then appending to the resulting string as few '0' bits as are
       necessary to make the number of bits in the plaintext into a
       multiple of 128.  Note that padding MUST be added to the data; if
       the number of octets in the payload data is a multiple of 16,
       then 16 octets of padding will be added.

   4.  Encrypt the payload using AES-128 in CBC mode, using the ENC_KEY
       and the random IV.  Form the ciphertext by prepending the IV to
       the CBC ciphertext outputs.

   5.  Compute the authentication tag by applying HMAC_SHA1 to the AAD,
       the length of the AAD expressed as a 64-bit unsigned integer in
       network byte order, the IV, and the ciphertext, in that order,
       using the MAC_KEY.

   6.  Return the ciphertext and the authentication tag.

   The authenticated decryption algorithm is as follows, or uses an
   equivalent set of steps:

   1.  Generate the secondary keys MAC_KEY and ENC_KEY from the input
       key K as follows:

          MAC_KEY = HMAC_SHA1(K, "MAC");




McGrew                   Expires April 26, 2007                [Page 14]


Internet-Draft          Authenticated Encryption            October 2006


          ENC_KEY = leftmost(HMAC_SHA1(K, "ENC"), 128);

   2.  Compute the MAC value by applying HMAC_SHA1 to the AAD, he length
       of the AAD expressed as a 64-bit unsigned integer in network byte
       order, the IV, and the ciphertext, in that order, using the
       MAC_KEY.  Compare this value to the authentication tag.  If they
       match, then continue with the processing.  Otherwise, discard the
       data and return FAIL.

   3.  Decrypt the payload using AES-128 in CBC mode, with the ENC_KEY,
       using the first 128 bits of the ciphertext as the random IV.

   4.  Remove padding by deleting the final '1' bit and all of the
       following '0' bits.  The remaining data forms the payload data.

   5.  Return the plaintext.

   The length of the ciphertext can be inferred from that of the
   plaintext.  The number L of octets in the ciphertext is given by

      L = 16 * ( floor(M / 16) + 2)

   where M denotes the number of octets in the payload, and the function
   floor() rounds its argument down to the nearest integer.  This fact
   is needed by the encoding function, since the length of the
   ciphertext, rather than the length of the payload, must be
   authenticated.

   The lengths of the inputs are restricted as follows:

      K_LEN is 16 octets,

      P_MAX is 2^32 - 1 octets,

      A_MAX is 2^64 - 1 octets,

      N_MIN and N_MAX are both zero octets, and

      C_MAX is 2^32 + 19 octets.


6.3.1  Test Cases

   A future version of this document will include test cases for
   AEAD_AES_128_HMAC_SHA1.






McGrew                   Expires April 26, 2007                [Page 15]


Internet-Draft          Authenticated Encryption            October 2006


7.  IANA Considerations

   IANA will define the "AEAD Registry" described below.  Additions and
   changes to the AEAD Registry are by expert review.  Each entry in the
   registry contains the following elements:

      a short name, such as "AEAD_AES_128_GCM", that starts with the
      string "AEAD",

      a positive number, and

      a reference to a specification that completely defines an AEAD
      algorithm and provides test cases that can be used to verify the
      correctness of an implementation.

   Requests to add an entry to the registry MUST include the name and
   the reference.  The number is assigned by IANA.  These number
   assignments SHOULD use the smallest available positive number.

   IANA will add the following five entries to the AEAD Registry:

  +----------------------------+---------------+--------------------+
  | Name                       |   Reference   | Numeric Identifier |
  +----------------------------+---------------+--------------------+
  | AEAD_AES_128_GCM           |  Section 6.1  |          1         |
  |                            |               |                    |
  | AEAD_AES_256_GCM           | Section 6.1.1 |          2         |
  |                            |               |                    |
  | AEAD_AES_128_CCM           |  Section 6.2  |          3         |
  |                            |               |                    |
  | AEAD_AES_256_CCM           | Section 6.2.1 |          4         |
  |                            |               |                    |
  | AEAD_AES_128_CBC_HMAC_SHA1 |  Section 6.3  |          5         |
  +----------------------------+---------------+--------------------+

















McGrew                   Expires April 26, 2007                [Page 16]


Internet-Draft          Authenticated Encryption            October 2006


8.  Open Questions

   The additional authenticated data input is well suited to
   authenticating headers.  Some cryptographic protocols have trailers
   that should be authenticated.  For example, in the Secure RTP
   protocol the authenticated data consists of the RTP header, the
   ciphertext containing the encrypted payload, and some additional
   data, in that order.  It is impossible for an AEAD to accommodate
   both the authenticated header and authenticated trailer without
   adding an additional input for the trailer.  Because none of the
   specified AEAD algorithms can handle both a trailer and a footer,
   this specification does not include a trailer in its interface.  We
   expect that protocols like SRTP will need to define different
   processing rules that include all of the authenticated-only data into
   a single AAD input in order to make use of this specification.
   However, new rules would need to be defined in order to use either
   GCM or CCM or any other AEAD transforms, so this need is not
   especially onerous.

   The TLS protocol as currently defined assumes that authentication
   will precede encryption.  Thus, in order to accommodate this
   specification, new processing rules would need to be written that
   make no assumptions about the relative ordering of the cryptographic
   services.  However, as above, these new rules would need to be
   defined anyway in order to use any AEAD algorithm.

   The AEAD algorithms selected reflect those that have been already
   adopted by standards.  It is an open question as to what other AEAD
   algorithms should be added.  Many variations on basic algorithms are
   possible, each with its own advantages.  While it is desirable to
   admit any algorithms that are found to be useful in practice, it is
   also desirable to limit the total number of registered algorithms.
   The current specification requires that a registered algorithm
   provide a complete specification and a set of validation data; it is
   hoped that these prerequisites set the admission criteria
   appropriately.

   Some users may view an IANA assignment as a recommendation or an
   endorsement of a particular AEAD algorithm.  Other users may desire
   to register an AEAD algorithm in order to allow for experimental or
   specialized use.  Because of these conflicting perspectives, it may
   be desirable to allocate a second IANA registry for experimental use.

   It may be desirable to replace HMAC-SHA1 with AES CMAC [CMAC] in the
   generic composition algorithm, or to introduce an additional
   algorithm that does so.

   Directly testing a randomized AEAD encryption algorithm using a test



McGrew                   Expires April 26, 2007                [Page 17]


Internet-Draft          Authenticated Encryption            October 2006


   cases with fixed inputs and outputs is not possible, since the
   encryption process is non-deterministic.  However, it is easy to test
   a randomized AEAD algorithm against fixed test cases.  The
   authenticated decryption algorithm is deterministic, and it can be
   directly tested.  The authenticated encryption algorithm can be
   tested by encrypting a plaintext, decrypting the resulting
   ciphertext, and comparing the original plaintext to the post-
   decryption plaintext.

   Some of the terminology in this specification is unwieldy, and could
   perhaps be improved.  For example, "AEAD algorithm" could be replaced
   with "crypto transform", which would be meaningful to a broader
   community, but is less precise.






































McGrew                   Expires April 26, 2007                [Page 18]


Internet-Draft          Authenticated Encryption            October 2006


9.  Security Considerations

   A future version of this document will define the security services
   that must be provided by an AEAD algorithm.















































McGrew                   Expires April 26, 2007                [Page 19]


Internet-Draft          Authenticated Encryption            October 2006


10.  Acknowledgments

   Many reviewers provided valuable comments on earlier drafts of this
   document.















































McGrew                   Expires April 26, 2007                [Page 20]


Internet-Draft          Authenticated Encryption            October 2006


11.  References

11.1  Normative References

   [CCM]      "NIST Special Publication 800-38C: The CCM Mode for
              Authentication and Confidentiality",
               http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.

   [GCM]      McGrew, D. and J. Viega, "The Galois/Counter Mode of
              Operation (GCM)", Submission to NIST. http://
              csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/
              gcm-spec.pdf, January 2004.

   [MODES]    "NIST Special Publication 800-38", Reccomendation for
              Block Cipher Modes of Operation http://csrc.nist.gov/
              publications/nistpubs/800-38a/sp800-38a.pdf.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

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

   [RFC2202]  Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
              SHA-1", RFC 2202, September 1997.

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

   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM
              Mode with IPsec Encapsulating Security Payload (ESP)",
              RFC 4309, December 2005.

   [SHA1]     "FIPS 180-1: Secure Hash Standard,", Federal Information
              Processing Standard
              (FIPS) http://www.itl.nist.gov/fipspubs/fip180-1.htm.

11.2  Informative References

   [AE]     "Authenticated encryption: Relations among notions and
            analysis of the generic composition paradigm", Proceedings
            of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp.
            531-545 http://www.

   [CMAC]   "NIST Special Publication 800-38B",  http://csrc.nist.gov/
            CryptoToolkit/modes/800-38_Series_Publications/



McGrew                   Expires April 26, 2007                [Page 21]


Internet-Draft          Authenticated Encryption            October 2006


            SP800-38B.pdf.

   [EEM04]  "Breaking and provably repairing the SSH authenticated
            encryption scheme: A case study of the Encode-then-Encrypt-
            and-MAC paradigm", ACM Transactions on Information and
            System Security, http://www-cse.ucsd.edu/users/tkohno/
            papers/TISSEC04/.


Author's Address

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

   Phone: (408) 525 8651
   Email: mcgrew@cisco.com
   URI:   http://www.mindspring.com/~dmcgrew/dam.htm































McGrew                   Expires April 26, 2007                [Page 22]


Internet-Draft          Authenticated Encryption            October 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




McGrew                   Expires April 26, 2007                [Page 23]


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