RFC 5116 – An Interface and Algorithms for Authenticated Encryption

Network Working Group                                          D. McGrew
Request for Comments: 5116                           Cisco Systems, Inc.
Category: Standards Track                                   January 2008


         An Interface and Algorithms for Authenticated Encryption

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

   This document defines algorithms for Authenticated Encryption with
   Associated 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 Standards Track [ Page 1 ]
RFC 5116 Authenticated Encryption January 20081. IntroductionBN00] 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 [R02], adds
   the ability to check the integrity and authenticity of some
   Associated Data (AD), also called "additional authenticated data",
   that is not encrypted.

1.1. BackgroundBOYD]).

   The benefits of AEAD algorithms, and this interface, are outlined in
   Section 1.3.

1.2. ScopeGCM] with 128- and 256-bit keys, and AES in Counter and CBC MAC
   Mode [CCM] with 128- and 256-bit keys.

   In the following, we define the AEAD interface (Section 2), and then
   provide guidance on the use of AEAD algorithms (Section 3), and
   outline the requirements that each AEAD algorithm must meet



 McGrew Standards Track [ Page 3 ] 
RFC 5116 Authenticated Encryption January 2008Section 4).  Then we define several AEAD algorithms (Section 5), and
   establish an IANA registry for AEAD algorithms (Section 6).  Lastly,
   we discuss some other considerations (Section 7).

   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
   recommendations from [EEM04].

1.3. Benefits1.4. Conventions Used in This DocumentRFC2119].



 McGrew Standards Track [ Page 4 ]
RFC 5116 Authenticated Encryption January 20082. AEAD Interface2.1. Authenticated EncryptionSection 3.2, and MAY use any
      other method that meets the uniqueness requirement.  Other
      applications SHOULD use zero-length nonces.

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

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

   There is a single output:

      A ciphertext C, which is at 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 1 and 255.  For each
      AEAD algorithm, the length of K MUST be fixed.






 McGrew Standards Track [ Page 5 ]
RFC 5116 Authenticated Encryption January 2008Section 4.  Applications that conform to the
      recommended nonce length will avoid having to construct nonces
      with different lengths, depending on the algorithm that is in use.
      This guidance helps to keep algorithm-specific logic out of
      applications.

      The number of octets in the plaintext P MAY be zero.

      The number of octets in the associated data A MAY be zero.

      The number of octets in the ciphertext C MAY be zero.

   This specification does not put a maximum length on the nonce, the
   plaintext, the ciphertext, or the additional authenticated data.
   However, a particular AEAD algorithm MAY further restrict the lengths
   of those 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 are 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 associated data A is used to protect information that needs to be
   authenticated, but 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 plaintext.





 McGrew Standards Track [ Page 6 ]
RFC 5116 Authenticated Encryption January 20082.2. Authenticated Decryption2.3. Data Formatting McGrew Standards Track [ Page 7 ]
RFC 5116 Authenticated Encryption January 20083. Guidance on the Use of AEAD Algorithms3.1. Requirements on Nonce GenerationSection 3.2.  Note that there is no need to coordinate
   the details of the nonce format between the encrypter and the
   decrypter, as long the entire nonce is sent or stored with the
   ciphertext and is thus available to the decrypter.  If the complete
   nonce is not available to the decrypter, then the decrypter will need
   to know how the nonce is structured so that it can reconstruct it.
   Applications SHOULD provide encryption engines with some freedom in
   choosing their nonces; for example, a nonce could contain both a
   counter and a field that is set by the encrypter but is not processed
   by the receiver.  This freedom allows a set of encryption devices to
   more readily coordinate to ensure the distinctness of their nonces.

   If a secret key will be used for a long period of time, e.g., across
   multiple reboots, then the nonce will need to be stored in non-
   volatile memory.  In such cases, it is essential to use checkpointing
   of the nonce; that is, the current nonce value should be stored to
   provide the state information needed to resume encryption in case of



 McGrew Standards Track [ Page 8 ]
RFC 5116 Authenticated Encryption January 20083.2. Recommended Nonce Formation McGrew Standards Track [ Page 9 ]
RFC 5116 Authenticated Encryption January 20083.2.1. Partially Implicit NoncesRFC4106] 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 Standards Track [ Page 10 ]
 
RFC 5116 Authenticated Encryption January 20083.3. Construction of AEAD Inputs3.4. Example UsageRFC4106] can be expressed as follows.  The
   AEAD inputs are

      P = RestOfPayloadData || TFCpadding || Padding || PadLength ||
      NextHeader

      N = Salt || IV

      A = SPI || SequenceNumber

   where the symbol "||" denotes the concatenation operation, and the
   fields RestOfPayloadData, TFCpadding, Padding, PadLength, NextHeader,
   SPI, and SequenceNumber are as defined in [RFC4303], and the fields
   Salt and IV are as defined in [RFC4106].  The field RestOfPayloadData
   contains the plaintext data that is described by the NextHeader



 McGrew Standards Track [ Page 11 ]
RFC 5116 Authenticated Encryption January 2008RFC4303] for an illustration.)

   The format of the ESP packet can be expressed as

      ESP = SPI || SequenceNumber || IV || C

   where C is the AEAD ciphertext (which in this case incorporates the
   authentication tag).  Please note that here we have not described the
   use of the ESP Extended Sequence Number.

4. Requirements on AEAD Algorithm Specifications McGrew Standards Track [ Page 12 ]
RFC 5116 Authenticated Encryption January 2008 McGrew Standards Track [ Page 13 ]
RFC 5116 Authenticated Encryption January 20085. AEAD Algorithms5.1. AEAD_AES_128_GCMGCM], using AES-128 as the block cipher, by providing
   the key, nonce, and plaintext, and associated 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 and N_MAX are both 12 octets, and

      C_MAX is 2^36 - 15 octets.

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

   A security analysis of GCM is available in [MV04].

5.1.1. Nonce Reuse McGrew Standards Track [ Page 14 ]
RFC 5116 Authenticated Encryption January 20085.2. AEAD_AES_256_GCM5.3. AEAD_AES_128_CCMCCM], using 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 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 of 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.



 McGrew Standards Track [ Page 15 ]
RFC 5116 Authenticated Encryption January 2008http://www.iana.org.

   The numbers between 32,768 (binary 1000000000000000) and 65,535
   (binary 1111111111111111) inclusive, will not be assigned by IANA,
   and are reserved for private use; no attempt will be made to prevent
   multiple sites from using the same value in different (and
   incompatible) ways [RFC2434].

   IANA has added the following entries to the AEAD Registry:

          +------------------+-------------+--------------------+
          | Name             |  Reference  | Numeric Identifier |
          +------------------+-------------+--------------------+
          | AEAD_AES_128_GCM | Section 5.1 |          1         |
          | AEAD_AES_256_GCM | Section 5.2 |          2         |
          | AEAD_AES_128_CCM | Section 5.3 |          3         |
          | AEAD_AES_256_CCM | Section 5.4 |          4         |
          +------------------+-------------+--------------------+

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

7. Other Considerations McGrew Standards Track [ Page 17 ]
RFC 5116 Authenticated Encryption January 2008BN00], combining a
   common encryption algorithm, such as CBC [MODES], with a common
   message authentication code, such as HMAC-SHA1 [RFC2104] or AES CMAC
   [CMAC].  An AEAD algorithm of this sort would reflect the best
   current practice, and might be more easily supported by crypto
   modules that lack support for other AEAD algorithms.

8. Security ConsiderationsRFC4086] and key
   management [RFC4107].

   AEAD algorithms that rely on distinct nonces may be inappropriate for
   some applications or for some scenarios.  Application designers
   should understand the requirements outlined in Section 3.1.

   A software implementation of the AEAD encryption operation in a
   Virtual Machine (VM) environment could inadvertently reuse a nonce
   due to a "rollback" of the VM to an earlier state [GR05].
   Applications are encouraged to document potential issues to help the
   user of the application and the VM avoid unintentional mistakes of
   this sort.  The possibility exists that an attacker can cause a VM
   rollback; threats and mitigations in that scenario are an area of
   active research.  For perspective, we note that an attacker who can
   trigger such a rollback may have already succeeded in subverting the
   security of the system, e.g., by causing an accounting error.

   An IANA registration of an AEAD algorithm MUST NOT be regarded as an
   endorsement of its security.  Furthermore, the perceived security
   level of an algorithm can degrade over time, due to cryptanalytic
   advances or to "Moore's Law", that is, the diminishing cost of
   computational resources over time.

9. Acknowledgments McGrew Standards Track [ Page 18 ]
RFC 5116 Authenticated Encryption January 200810. References10.1. Normative ReferencesCCM]      Dworkin, M., "NIST Special Publication 800-38C: The CCM
              Mode for Authentication and Confidentiality", U.S.
              National Institute of Standards and Technology,
              .

   [GCM]      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,
              .

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

10.2. Informative ReferencesBN00]     Bellare, M. and C. Namprempre, "Authenticated encryption:
              Relations among notions and analysis of the generic
              composition paradigm", Proceedings of ASIACRYPT 2000,
              Springer-Verlag, LNCS 1976, pp. 531-545, 2002.

   [BOYD]     Boyd, C. and A. Mathuria, "Protocols for Authentication
              and Key Establishment", Springer 2003.

   [CMAC]     "NIST Special Publication 800-38B", .

   [EEM04]    Bellare, M., Namprempre, C., and T. Kohno, "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,
              .

   [GR05]     Garfinkel, T. and M. Rosenblum, "When Virtual is Harder
              than Real: Security Challenges in Virtual Machine Based
              Computing Environments", Proceedings of the 10th Workshop
              on Hot Topics in Operating Systems,
              .





 McGrew Standards Track [ Page 19 ] 
RFC 5116 Authenticated Encryption January 2008http://www.mindspring.com/~dmcgrew/dam.htm








































 McGrew Standards Track [ Page 21 ]
RFC 5116 Authenticated Encryption January 2008BCP 78, 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 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.












McGrew                      Standards Track                    [Page 22]
generator : https://coinselected.com
category : crypto topics

Leave a Reply

Your email address will not be published.