summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5116.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5116.txt')
-rw-r--r--doc/rfc/rfc5116.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc5116.txt b/doc/rfc/rfc5116.txt
new file mode 100644
index 0000000..a776c6c
--- /dev/null
+++ b/doc/rfc/rfc5116.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+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 2008
+
+
+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. Guidance on the Use of AEAD Algorithms . . . . . . . . . . . . 8
+ 3.1. Requirements on Nonce Generation . . . . . . . . . . . . . 8
+ 3.2. Recommended Nonce Formation . . . . . . . . . . . . . . . 9
+ 3.2.1. Partially Implicit Nonces . . . . . . . . . . . . . . 10
+ 3.3. Construction of AEAD Inputs . . . . . . . . . . . . . . . 11
+ 3.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11
+ 4. Requirements on AEAD Algorithm Specifications . . . . . . . . 12
+ 5. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.1. AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 14
+ 5.1.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 14
+ 5.2. AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . . . 15
+ 5.3. AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 15
+ 5.3.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 16
+ 5.4. AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . . . 16
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
+ 7. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McGrew Standards Track [Page 2]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+1. Introduction
+
+ Authenticated encryption [BN00] 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. Background
+
+ Many cryptographic applications require both confidentiality and
+ message authentication. Confidentiality is a security service that
+ ensures that data is available only to those authorized to obtain it;
+ usually it is realized through encryption. Message authentication is
+ the service that ensures that data has not been altered or forged by
+ unauthorized entities; it can be achieved by using a Message
+ Authentication Code (MAC). This service is also called data
+ integrity. Many applications use an encryption method and a MAC
+ together to provide both of 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 (see, for example, Section 2.5 of [BOYD]).
+
+ The benefits of AEAD algorithms, and this interface, are outlined in
+ Section 1.3.
+
+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 four AEAD algorithms
+ based on the Advanced Encryption Standard (AES) in Galois/Counter
+ Mode [GCM] 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 2008
+
+
+ (Section 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. Benefits
+
+ The AEAD approach enables applications that need cryptographic
+ security services to more easily adopt those services. It benefits
+ the application designer by allowing them to focus on important
+ issues such as 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
+ 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 more
+ 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 Standards Track [Page 4]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+2. AEAD Interface
+
+ An AEAD algorithm has two operations, authenticated encryption and
+ authenticated decryption. The inputs and outputs of these algorithms
+ are defined below 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 with other implementations.
+
+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.
+
+ A nonce N. Each nonce provided to distinct invocations of the
+ Authenticated Encryption operation MUST be distinct, for any
+ particular value of the key, unless each and every nonce is zero-
+ length. Applications that can generate distinct nonces SHOULD use
+ the nonce formation method defined in Section 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 2008
+
+
+ For any particular value of the key, either 1) each nonce provided
+ to distinct invocations of the Authenticated Encryption operation
+ MUST be distinct, or 2) each and every nonce MUST be zero-length.
+ If zero-length nonces are used with a particular key, then each
+ and every nonce used with that key MUST have a length of zero.
+ Otherwise, the number of octets in the nonce SHOULD be twelve
+ (12). Nonces with different lengths MAY be used with a particular
+ key. Some algorithms cannot be used with zero-length nonces, but
+ others can; see Section 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 2008
+
+
+ The secret key K MUST NOT be included in any of the other inputs (N,
+ P, and A). (This restriction does not mean that the values of those
+ inputs must be checked to ensure that they do not include substrings
+ that match the key; instead, it means that the key must not be
+ explicitly copied into those inputs.)
+
+ The nonce is authenticated internally to the algorithm, and it is not
+ necessary to include it in the AD input. The nonce MAY be included
+ in P or A if it is convenient to the application.
+
+ The nonce MAY be stored or transported with the ciphertext, or it MAY
+ be reconstructed immediately prior to the authenticated decryption
+ operation. It is sufficient to provide the decryption module with
+ enough information to allow it to construct the nonce. (For example,
+ a system could use a nonce consisting of a sequence number in a
+ particular format, in which case it could be inferred from the order
+ of the ciphertexts.) Because the authenticated decryption process
+ detects incorrect nonce values, no security failure will result if a
+ nonce is incorrectly reconstructed and fed into an authenticated
+ decryption operation. Any nonce reconstruction method will need to
+ take into account the possibility of loss or reorder of ciphertexts
+ between the encryption and decryption processes.
+
+ Applications MUST NOT assume any particular structure or formatting
+ of the ciphertext.
+
+2.2. Authenticated Decryption
+
+ The authenticated decryption operation has four inputs: K, N, 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, a nonce N, and associated data A are
+ authentic for key K when C is generated by the encrypt operation with
+ inputs K, N, P, and A, for some values of N, P, and A. The
+ authenticated decrypt operation will, with high probability, return
+ FAIL whenever the inputs N, P, and A were crafted by a nonce-
+ respecting adversary that does not know the secret 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 choosing the format of application data, 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
+
+
+
+McGrew Standards Track [Page 7]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+ decryption operation. For instance, if the nonce and ciphertext both
+ appear in a packet, the former value should precede the latter. This
+ rule facilitates efficient and simple hardware implementations of
+ AEAD algorithms.
+
+3. Guidance on the Use of AEAD Algorithms
+
+ This section provides advice that must be followed in order to use an
+ AEAD algorithm securely.
+
+ If an application is unable to meet the uniqueness requirement on
+ nonce generation, then it MUST use a zero-length nonce. Randomized
+ or stateful algorithms, which are defined below, are suitable for use
+ with such applications. Otherwise, an application SHOULD use nonces
+ with a length of twelve octets. Since algorithms are encouraged to
+ support that length, applications should use that length to aid
+ interoperability.
+
+3.1. Requirements on Nonce Generation
+
+ It is essential for security that the nonces be constructed in a
+ manner that respects the requirement that each nonce value be
+ distinct for each invocation of the authenticated encryption
+ operation, for any fixed value of the key. In this section, we call
+ attention to some consequences of this requirement in different
+ scenarios.
+
+ When there are multiple devices performing encryption using a single
+ key, those devices must coordinate to ensure that the nonces are
+ unique. A simple way to do this is to use a nonce format that
+ contains a field that is distinct for each one of the devices, as
+ described in Section 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 2008
+
+
+ unexpected failure. One simple way to provide a high assurance that
+ a nonce value will not be used repeatedly is to wait until the
+ encryption process receives confirmation from the storage process
+ indicating that the succeeding nonce value has already been stored.
+ Because this method may add significant latency, it may be desirable
+ to store a nonce value that is several values ahead in the sequence.
+ As an example, the nonce 100 could be stored, after which the nonces
+ 1 through 99 could be used for encryption. The nonce value 200 could
+ be stored at the same time that nonces 1 through 99 are being used,
+ and so on.
+
+ Many problems with nonce reuse can be avoided by changing a key in a
+ situation in which nonce coordination is difficult.
+
+ Each AEAD algorithm SHOULD describe what security degradation would
+ result from an inadvertent reuse of a nonce value.
+
+3.2. Recommended Nonce Formation
+
+ 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. For each fixed key, the length of each of these
+ fields, and thus the length of the nonce, is fixed. Implementations
+ SHOULD support 12-octet nonces in which the Counter field is four
+ octets long.
+
+ <----- variable ----> <----------- variable ----------->
+ +---------------------+----------------------------------+
+ | Fixed | Counter |
+ +---------------------+----------------------------------+
+
+ Figure 1: Recommended nonce format
+
+ The Counter fields of successive nonces form a monotonically
+ increasing sequence, when those fields are regarded as unsigned
+ integers in network byte order. The length of the Counter field MUST
+ remain constant for all nonces that are generated for a given
+ encryption device. The Counter part SHOULD be equal to zero for the
+ first nonce, and increment by one for each successive nonce that is
+ generated. However, any particular Counter value MAY be skipped
+ over, and left out of the sequence of values that are used, if it is
+ convenient. For example, an application could choose to skip the
+ initial Counter=0 value, and set the Counter field of the initial
+ nonce to 1. Thus, at most 2^(8*C) nonces can be generated when the
+ Counter field is C octets in length.
+
+
+
+
+
+McGrew Standards Track [Page 9]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+ The Fixed field MUST remain constant for all nonces that are
+ generated for a given encryption device. 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 encrypters can share a key
+ when the Fixed field is F octets in length.
+
+3.2.1. Partially Implicit Nonces
+
+ In some cases, it is desirable to not transmit or store an entire
+ nonce, but instead to reconstruct that value from contextual
+ information immediately prior to decryption. As an example,
+ ciphertexts could be stored in sequence on a disk, and the nonce for
+ a particular ciphertext could be inferred from its location, as long
+ as the rule for generating the nonces is known by the decrypter. We
+ call the portion of the nonce that is stored or sent with the
+ ciphertext the explicit part. We call the portion of the nonce that
+ is inferred the implicit part. When part of the nonce is implicit,
+ the following specialization of the above format is RECOMMENDED. The
+ Fixed field is divided into two sub-fields: a Fixed-Common field and
+ a Fixed-Distinct field. This format is shown in Figure 2. If
+ different devices are performing encryption with a single key, then
+ each distinct device MUST use a distinct Fixed-Distinct field. The
+ Fixed-Common field is common to all nonces. The Fixed-Distinct field
+ and the Counter field MUST be in the explicit part of the nonce. The
+ Fixed-Common field MAY be in the implicit part of the nonce. These
+ conventions ensure that the nonce is easy to reconstruct from the
+ explicit data.
+
+ +-------------------+--------------------+---------------+
+ | Fixed-Common | Fixed-Distinct | Counter |
+ +-------------------+--------------------+---------------+
+ <---- implicit ---> <------------ explicit ------------>
+
+ Figure 2: Partially implicit nonce format
+
+ The rationale for the partially implicit nonce format is as
+ follows. This method of nonce construction incorporates the best
+ known practice; it is used by both GCM Encapuslating Security
+ Payload (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 Standards Track [Page 10]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+3.3. Construction of AEAD Inputs
+
+ If the AD 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. (In mathematical terms, the AD input must be an injective
+ function of the data elements.) If an application constructs its AD
+ input in such a way that there are two distinct sets of data elements
+ that result in the same AD value, then an attacker could cause a
+ receiver to accept a bogus set by substituting one set for the other.
+ The requirement that the AD be uniquely parseable ensures that this
+ attack is not possible. This requirement is trivially met if the AD
+ is composed of fixed-width elements. If the AD contains a variable-
+ length string, for example, this requirement can be met by also
+ including the length of the string in the AD.
+
+ 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 included in the AD may be
+ used when parsing the plaintext, though of course since the AD is not
+ encrypted there is a potential loss of confidentiality when
+ information about the plaintext is included in the AD.
+
+3.4. Example Usage
+
+ To make use of an AEAD algorithm, an application must define how the
+ encryption algorithm's inputs are defined in terms of application
+ data, and how the ciphertext and nonce are conveyed. The clearest
+ way to do this is to express each input in terms of the data that
+ form it, then to express the application data in terms of the outputs
+ of the AEAD encryption operation.
+
+ For example, AES-GCM ESP [RFC4106] 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 2008
+
+
+ field, and no other data. (Recall that the PayloadData field
+ contains both the IV and the RestOfPayloadData; see Figure 2 of
+ [RFC4303] 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
+
+ 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 (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, inclusive, where the value P_MAX is specific
+ to that algorithm. The value of P_MAX MUST be larger than zero, and
+ SHOULD be at least 65,536 (2^16) octets. This size is a typical
+ upper limit for network data packets. Other applications may use
+ even larger values of P_MAX, so it is desirable for general-purpose
+ algorithms to support higher values.
+
+ Each AEAD algorithm MUST accept any associated data with a length
+ between zero and A_MAX octets, inclusive, where the value A_MAX is
+ specific to that algorithm. The value of A_MAX MUST be larger than
+ zero, and SHOULD be at least 65,536 (2^16) octets. Other
+ applications may use even larger values of A_MAX, so it is desirable
+ for general-purpose algorithms to support higher values.
+
+ Each AEAD algorithm MUST accept any nonce with a length between N_MIN
+ and N_MAX octets, inclusive, where the values of N_MIN and N_MAX are
+ specific to that algorithm. The values of N_MAX and N_MIN MAY be
+ equal. Each algorithm SHOULD accept a nonce with a length of twelve
+ (12) octets. Randomized or stateful algorithms, which are described
+ below, MAY have an N_MAX value of zero.
+
+ 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.
+
+
+
+
+
+McGrew Standards Track [Page 12]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+ An Authenticated Encryption algorithm MAY incorporate or make use of
+ a random source, e.g., for the generation of an internal
+ initialization vector that is incorporated into the ciphertext
+ output. An AEAD algorithm of this sort is called randomized; though
+ note that only encryption is random, and decryption is always
+ deterministic. A randomized algorithm MAY have a value of N_MAX that
+ is equal to zero.
+
+ An Authenticated Encryption algorithm MAY incorporate internal state
+ information that is maintained between invocations of the encrypt
+ operation, e.g., to allow for the construction of distinct values
+ that are used as internal nonces by the algorithm. An AEAD algorithm
+ of this sort is called stateful. This method could be used by an
+ algorithm to provide good security even when the application inputs
+ zero-length nonces. A stateful algorithm 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 largest 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. This relation MUST NOT
+ depend on external parameters, such as an authentication strength
+ parameter (e.g., authentication tag length). That sort of dependence
+ would complicate the use of the algorithm by creating a situation in
+ which the information from the AEAD registry was not sufficient to
+ ensure interoperability.
+
+ EACH AEAD algorithm specification SHOULD describe what security
+ degradation would result from an inadvertent reuse of a nonce value.
+
+ Each AEAD algorithm specification SHOULD provide a reference to a
+ detailed security analysis. This document does not specify a
+ particular security model, because several different models have been
+ used in the literature. The security analysis SHOULD define or
+ reference a security model.
+
+ An algorithm that is randomized or stateful, as defined above, SHOULD
+ describe itself using those terms.
+
+
+
+
+
+
+
+
+
+
+McGrew Standards Track [Page 13]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+5. AEAD Algorithms
+
+ This section defines four AEAD algorithms; two are based on AES GCM,
+ two are based on AES CCM. Each pair includes an algorithm with a key
+ size of 128 bits and one with a key size of 256 bits.
+
+5.1. AEAD_AES_128_GCM
+
+ The AEAD_AES_128_GCM authenticated encryption algorithm works as
+ specified in [GCM], 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
+
+ The inadvertent reuse of the same nonce by two invocations of the GCM
+ encryption operation, with the same key, but with distinct plaintext
+ values, undermines the confidentiality of the plaintexts protected in
+ those two invocations, and undermines all of the authenticity and
+ integrity protection provided by that key. For this reason, GCM
+ should only be used whenever nonce uniqueness can be provided with
+ assurance. The design feature that GCM uses to achieve minimal
+ latency causes the vulnerabilities on the subsequent uses of the key.
+ Note that it is acceptable to input the same nonce value multiple
+ times to the decryption operation.
+
+ The security consequences are quite serious if an attacker observes
+ two ciphertexts that were created using the same nonce and key
+
+
+
+McGrew Standards Track [Page 14]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+ values, unless the plaintext and AD values in both invocations of the
+ encrypt operation were identical. First, a loss of confidentiality
+ ensues because he will be able to reconstruct the bitwise
+ exclusive-or of the two plaintext values. Second, a loss of
+ integrity ensues because the attacker will be able to recover the
+ internal hash key used to provide data integrity. Knowledge of this
+ key makes subsequent forgeries trivial.
+
+5.2. 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.
+
+5.3. AEAD_AES_128_CCM
+
+ The AEAD_AES_128_CCM authenticated encryption algorithm works as
+ specified in [CCM], 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 2008
+
+
+ An AEAD_AES_128_CCM ciphertext is exactly 16 octets longer than its
+ corresponding plaintext.
+
+ A security analysis of AES CCM is available in [J02].
+
+5.3.1. Nonce Reuse
+
+ Inadvertent reuse of the same nonce by two invocations of the CCM
+ encryption operation, with the same key, undermines the security for
+ the messages processed with those invocations. A loss of
+ confidentiality ensues because an adversary will be able to
+ reconstruct the bitwise exclusive-or of the two plaintext values.
+
+5.4. 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. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has defined the "AEAD
+ Registry" described below. An algorithm designer MAY register an
+ algorithm in order to facilitate its use. Additions to the AEAD
+ Registry require that a specification be documented in an RFC or
+ another permanent and readily available reference, in sufficient
+ detail that interoperability between independent implementations is
+ possible. 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.
+ Submitters SHOULD have their requests reviewed by the IRTF Crypto
+
+
+
+
+
+McGrew Standards Track [Page 16]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+ Forum Research Group (CFRG) at cfrg@ietf.org. Interested applicants
+ that are unfamiliar with IANA processes should visit
+ http://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
+
+ Directly testing a randomized AEAD encryption algorithm using test
+ cases with fixed inputs and outputs is not possible, since the
+ encryption process is non-deterministic. However, it is possible to
+ test a randomized AEAD algorithm using the following technique. 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. Combining both of these tests covers both the
+ encryption and decryption algorithms.
+
+ 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.
+
+
+
+
+McGrew Standards Track [Page 17]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+ It may be desirable to define an AEAD algorithm that uses the generic
+ composition with the encrypt-then-MAC method [BN00], 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 Considerations
+
+ This document describes authenticated encryption algorithms, and
+ provides guidance on their use. While these algorithms make it
+ easier, in some ways, to design a cryptographic application, it
+ should be borne in mind that strong cryptographic security is
+ difficult to achieve. While AEAD algorithms are quite useful, they
+ do nothing to address the issues of key generation [RFC4086] 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
+
+ Many reviewers provided valuable comments on earlier drafts of this
+ document. Some fruitful discussions took place on the email list of
+ the Crypto Forum Research Group in 2006.
+
+
+
+
+
+
+
+McGrew Standards Track [Page 18]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+10. References
+
+10.1. Normative References
+
+ [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM
+ Mode for Authentication and Confidentiality", U.S.
+ National Institute of Standards and Technology,
+ <http://csrc.nist.gov/publications/nistpubs/800-38C/
+ SP800-38C.pdf>.
+
+ [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,
+ <http://csrc.nist.gov/publications/nistpubs/800-38D/
+ SP-800-38D.pdf>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+10.2. Informative References
+
+ [BN00] 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", <http://csrc.nist.gov/
+ publications/nistpubs/800-38B/SP_800-38B.pdf>.
+
+ [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,
+ <http://www-cse.ucsd.edu/users/tkohno/papers/TISSEC04/>.
+
+ [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,
+ <http://www.stanford.edu/~talg/papers/HOTOS05/
+ virtual-harder-hotos05.pdf>.
+
+
+
+
+
+McGrew Standards Track [Page 19]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+ [J02] Jonsson, J., "On the Security of CTR + CBC-MAC",
+ Proceedings of the 9th Annual Workshop on Selected Areas
+ on Cryptography, 2002, <http://csrc.nist.gov/groups/ST/
+ toolkit/BCM/documents/proposedmodes/ccm/ccm-ad1.pdf>.
+
+ [MODES] Dworkin, M., "NIST Special Publication 800-38:
+ Recommendation for Block Cipher Modes of Operation", U.S.
+ National Institute of Standards and Technology,
+ <http://csrc.nist.gov/publications/nistpubs/800-38a/
+ sp800-38a.pdf>.
+
+ [MV04] McGrew, D. and J. Viega, "The Security and Performance of
+ the Galois/Counter Mode (GCM)", Proceedings of
+ INDOCRYPT '04, December 2004,
+ <http://eprint.iacr.org/2004/193>.
+
+ [R02] Rogaway, P., "Authenticated encryption with Associated-
+ Data", ACM Conference on Computer and Communication
+ Security (CCS'02), pp. 98-107, ACM Press, 2002,
+ <http://www.cs.ucdavis.edu/~rogaway/papers/ad.html>.
+
+ [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104,
+ February 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+ [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
+ (GCM) in IPsec Encapsulating Security Payload (ESP)",
+ RFC 4106, June 2005.
+
+ [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
+ Key Management", BCP 107, RFC 4107, June 2005.
+
+ [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
+ RFC 4303, December 2005.
+
+ [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
+ Mode with IPsec Encapsulating Security Payload (ESP)",
+ RFC 4309, December 2005.
+
+
+
+
+
+
+McGrew Standards Track [Page 20]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+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 Standards Track [Page 21]
+
+RFC 5116 Authenticated Encryption January 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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.
+
+ 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]
+