Network Working Group D. McGrew
Internet-Draft Cisco Systems, Inc.
Expires: January 2, 2007 July 2006
Authenticated Encryption
draft-mcgrew-auth-enc-00.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 January 2, 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 January 2, 2007 [Page 1]
Internet-Draft Authenticated Encryption July 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 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. Requirements on AEAD algorithms . . . . . . . . . . . . . . . 8
3.1 Example IV Formation . . . . . . . . . . . . . . . . . . . 8
4. Requirements on the use of AEAD algorithms . . . . . . . . . . 9
5. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 10
5.1.1 AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . 10
5.2 AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 10
5.2.1 AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . 10
5.3 AEAD_AES_128_HMAC_SHA1 . . . . . . . . . . . . . . . . . . 11
5.3.1 Test Cases . . . . . . . . . . . . . . . . . . . . . . 12
5.3.2 AEAD_AES_256_HMAC_SHA1 . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 15
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 January 2, 2007 [Page 2]
Internet-Draft Authenticated Encryption July 2006
1. Introduction
Many cryptographic protocols provide 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. Many crypto algorithms that implement AEAD
algorithms have been defined, including block cipher modes of
operation and dedicated algorithms. Several of these algorithms have
been adopted and proven useful in practice. 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 six AEAD algorithms: AES
in Galois/Counter Mode [GCM], AES in Counter and CBC MAC mode [CCM],
and an algorithm that composes AES CBC and HMAC-SHA1, with key sizes
of 128 and 256. This approach enables applications that need
cryptographic security services to more easily adopt those services.
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.
McGrew Expires January 2, 2007 [Page 3]
Internet-Draft Authenticated Encryption July 2006
The AEAD 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].
In the following, we define the AEAD interface (Section 2), and then
outline the requirements that each AEAD algorithm must meet
(Section 3) and provide guidance on the use of AEAD algorithms
(Section 4). Then we define six AEAD algorithms (Section 5), and
establish an IANA registry for AEAD algorithms (Section 6). Lastly,
we describe an example usage of the interface (Section 7) and discuss
some open questions (Section 8).
1.1 Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
McGrew Expires January 2, 2007 [Page 4]
Internet-Draft Authenticated Encryption July 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 bit strings. However, an implementation MAY
choose to accept only inputs whose bit-lengths are multiples of 8;
that is, it may accept only octet strings.
Each AEAD algorithm uses an Initialization Vector, or IV, to
initialize the algorithm for processing a particular message. The IV
is generated by the authenticated encryption algorithm, and it is
provided as an input to the authenticated decryption algorithm. The
IV is an output of the AEAD algorithm, rather than an input to it, so
that it is under the control of the crypto module implementing that
algorithm.
Rationale. Proper IV generation is a crucial for security, and
the requirements on how IVs are generated are different for
different algorithms. Giving the AEAD algorithm the
responsibility of generating its own IV hides that dependency from
the user, better reflects the interface between a crypto module
and an application, and promotes the testability of
implementations.
Each AEAD algorithm MUST specify the way in which its IVs are
generated, to allow for external testing of the IV generation
component of the encryption algorithm.
An AEAD algorithm is called deterministic if the outputs of the
encryption algorithm are a deterministic function of its inputs.
Otherwise, the AEAD algorithm is called random.
An AEAD algorithm MAY be stateful, that is, it may require that state
is maintained between each invocation of the authenticated encryption
operation, and/or between each invocation of the authenticated
decryption operation.
2.1 Authenticated Encryption
The authenticated encryption operation has three inputs, each of
which is a bit string:
a secret key K,
a plaintext P, which is to be encrypted,
additional authenticated data (AAD), which is denoted as A. This
data is authenticated, but not encrypted.
McGrew Expires January 2, 2007 [Page 5]
Internet-Draft Authenticated Encryption July 2006
A deterministic AEAD encryption algorithm MUST accept an additional
input, and that value MUST be included verbatim in the IV. This
input is called the IV contribution.
There are three outputs:
an initialization vector IV,
a ciphertext C,
an authentication tag T.
For each AEAD algorithm, the length of the key is fixed. The lengths
of the other inputs and outputs may vary, and may include zero. The
length of the ciphertext is equal to, or greater than, the length of
the plaintext. The length of the tag is denoted as t.
Both confidentiality and message authentication is provided on the
plaintext. The strength of the authentication of P, IV and A is
attenuated by the length t of the authentication tag. 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 must be left unencrypted.
When using an AEAD to secure a network protocol, this input could
include addresses, ports, sequence numbers, protocol version numbers,
and other fields that indicate how the plaintext 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 AAD, authentication is provided without copying the
data into the ciphertext.
The IV is authenticated internally to the algorithm, and it is not
necessary to include it in the AAD input. The IV MAY be included in
the AAD if it convenient to the application.
The IV 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 IV to be reconstructed. Because
the authenticated decryption process detects incorrect IV values, no
security failure results when a receiver incorrectly reconstructs an
IV.
McGrew Expires January 2, 2007 [Page 6]
Internet-Draft Authenticated Encryption July 2006
2.2 Authenticated Decryption
The authenticated decryption operation has five inputs: K, IV , C ,
A, and T, as defined above. It has only a single output, either the
plaintext value P or a special symbol FAIL that indicates that the
inputs are not authentic. A ciphertext C , initialization vector IV
, additional authenticated data A and tag T are authentic for key K
when IV, C, and T are generated by the encrypt operation with inputs
K, A and P, for some plaintext P. 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.
An application using an AEAD SHOULD use the following rules for
ordering the AEAD outputs (e.g. within a packet) , in order to
facilitate efficient and simple implementations of AEAD algorithms:
The Authentication Tag SHOULD follow all other fields.
The Ciphertext SHOULD follow all fields other than the
Authentication Tag.
McGrew Expires January 2, 2007 [Page 7]
Internet-Draft Authenticated Encryption July 2006
3. Requirements on AEAD algorithms
As described above, a deterministic AEAD algorithm MUST accept an IV
contribution input to its encryption operation. This input MUST be
included, verbatim, in the IV that is generated by that operation. A
deterministic algorithm MAY use the IV formation method defined in
Section 3.1, or any other method that meets this requirement.
3.1 Example IV Formation
One method to construct IVs that include a contribution, and which
conforms to many different methods of IV construction, is as follows.
The leftmost bits of the IV consist of the contribution. For any
fixed key, the length of the IV contribution is fixed. The rightmost
bits of the IV consist of an unsigned integer in network byte order.
The length of the integer part is chosen so that the total length of
the IV is the desired value. The integer part of the IV is equal to
one for the first IV, and increments by one for each successive IV
that is generated. The integer part is never equal to the all-zero
value.
Rationale. This method is used by both GCM ESP [RFC4106] and CCM
ESP [RFC4309], in which the IV contribution contains the Salt
value and the lowest eight octets of the IV are explicitly carried
in the ESP packet. In GCM ESP, the IV contribution must be at
least four octets long, so that it can contain the Salt value. In
CCM ESP, the IV contribution must be at least three octets long
for the same reason. This IV generation method is also used by
several counter mode variants including CTR ESP.
McGrew Expires January 2, 2007 [Page 8]
Internet-Draft Authenticated Encryption July 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 January 2, 2007 [Page 9]
Internet-Draft Authenticated Encryption July 2006
5. AEAD Algorithms
This section defines six AEAD algorithms; two are based on AES GCM,
two are based on AES CCM, and two are 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.
5.1 AEAD_AES_128_GCM
This algorithm is deterministic and stateful. An IV contribution
with a length of between zero and eight octets is accepted, and the
IV is constructed as described in Section 3.1. The IV is 12 octets
in length, and the secret key is 128 bits long.
The AEAD_AES_128_GCM authenticated encryption algorithm works as
specified in [GCM], by providing the key, IV, and plaintext to that
mode of operation. Test cases are provided in that reference.
5.1.1 AEAD_AES_256_GCM
This algorithm is identical to AEAD_AES_128_GCM, but with the
following differences:
the secret key is 256 bits long, instead of 128 bits in length,
and
AES-256 GCM is used instead of AES-128 GCM.
5.2 AEAD_AES_128_CCM
This algorithm is deterministic and stateful. An IV contribution
with a length of between zero and seven octets is accepted, and the
IV is constructed as described in Section 3.1. The IV is eleven
octets long, and the secret key is 128 bits in length.
The AEAD_AES_128_CCM authenticated encryption algorithm works as
specified in [CCM], by providing the key, IV, and plaintext to that
mode of operation. Test cases are provided in that reference.
5.2.1 AEAD_AES_256_CCM
This algorithm is identical to AEAD_AES_128_CCM, but with the
following differences:
the secret key is 256 bits long, instead of 128 bits in length,
and
McGrew Expires January 2, 2007 [Page 10]
Internet-Draft Authenticated Encryption July 2006
AES-256 CCM is used instead of AES-128 CCM.
5.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 IV is 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.)
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 IV, and the ciphertext, using the MAC_KEY.
McGrew Expires January 2, 2007 [Page 11]
Internet-Draft Authenticated Encryption July 2006
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");
ENC_KEY = leftmost(HMAC_SHA1(K, "ENC"), 128);
2. Compute the MAC value by applying HMAC_SHA1 to the clear data,
the IV, and the ciphertext, 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.
5.3.1 Test Cases
A future version of this document will include test cases for
AEAD_AES_128_HMAC_SHA1.
5.3.2 AEAD_AES_256_HMAC_SHA1
This algorithm is identical to AEAD_AES_128_HMAC_SHA1, but with the
following differences:
McGrew Expires January 2, 2007 [Page 12]
Internet-Draft Authenticated Encryption July 2006
the secret key is 256 bits long, instead of 128 bits in length,
AES-256 CBC is used instead of AES-128 CBC, and
if a pseudorandom process is used to generate the IVs, that
process must have a cryptographic strength equivalent to that of
AES-256.
McGrew Expires January 2, 2007 [Page 13]
Internet-Draft Authenticated Encryption July 2006
6. 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 six entries to the AEAD Registry:
+----------------------------+---------------+--------------------+
| Name | Reference | Numeric Identifier |
+----------------------------+---------------+--------------------+
| AEAD_AES_128_GCM | Section 5.1 | 1 |
| | | |
| AEAD_AES_256_GCM | Section 5.1.1 | 2 |
| | | |
| AEAD_AES_128_CCM | Section 5.2 | 3 |
| | | |
| AEAD_AES_256_CCM | Section 5.2.1 | 4 |
| | | |
| AEAD_AES_128_CBC_HMAC_SHA1 | Section 5.3 | 5 |
| | | |
| AEAD_AES_256_CBC_HMAC_SHA1 | Section 5.3.2 | 6 |
+----------------------------+---------------+--------------------+
McGrew Expires January 2, 2007 [Page 14]
Internet-Draft Authenticated Encryption July 2006
7. Example Usage
ESP support is easy to achieve, and can interoperate with existing
ESP implementations of ESP GCM [RFC4106] and ESP CCM [RFC4309]. The
ESP sender-side processing is illustrated in Figure 1, which shows
how the fields of an ESP packet correspond to the authenticated
encryption inputs and outputs. Note that the only the rightmost
eight octets of the IV are explicitly carried in the packet. ESP
receiver-side processing is shown in Figure 2.
The conventional algorithms used in "generic composition" within ESP
include HMAC-SHA1 and AES in CBC mode. Unfortunately, the CBC
padding method used in ESP is not suitable for generic use, since it
interposes the padding and the pad length inside of the plaintext.
Thus the AES_128_CBC_HMAC_SHA1 AEAD algorithm is very close to, but
slightly different from, the equivalent generic composition method
for ESP.
K IV Contribution
| |
+-----------------------+ -+ v v
| SPI | | +-------+
+-----------------------+ +--> AAD ->| |
| Sequence Number | | | a |
+-----------------------+ -+ | u e |
| IV | <---- IV ---| t n a |
| | | h c l |
+-----------------------+ -+ | e r g |
| | | | n y o |
~ ESP Payload ~ | | t p r |
| | +--> P --->| i t i |
+-----------+-----+-----+ | | c i t |
| Padding | PL | NH | | | a o m |
+-----------+-----+-----+ -+ | t n |
| Integrity | | e |
~ Check ~ <---- T ----| d |
| Value | +-------+
+-----------------------+
Figure 1: ESP AEAD encryption processing.
McGrew Expires January 2, 2007 [Page 15]
Internet-Draft Authenticated Encryption July 2006
K
|
+-----------------------+ -+ V
| SPI | | +-------+
+-----------------------+ +--> AAD ->| |
| Sequence Number | | | a |
+-----------------------+ -+ | u d |
| IV | ----- IV -->| t e a |
| | | h c l |
+-----------------------+ | e r g |
| | <-+ | n y o |
~ ESP Payload ~ | | t p r |
| | +-- P ----| i t i |
+-----------+-----+-----+ | | c i t |
| Padding | PL | NH | <-+ | a o m |
+-----------+-----+-----+ | t n |
| Integrity | | e |
~ Check ~ ----- T --->| d |
| Value | +-------+
+-----------------------+
Figure 2: ESP AEAD decryption processing.
McGrew Expires January 2, 2007 [Page 16]
Internet-Draft Authenticated Encryption July 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. Both random and deterministic algorithms have
been provided. 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.
McGrew Expires January 2, 2007 [Page 17]
Internet-Draft Authenticated Encryption July 2006
Directly testing a randomized AEAD encryption algorithm using a test
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.
This specification is incomplete regarding the subject of
authentication tag lengths. A future version will need to provide
clarification. One alternative is to have each AEAD algorithm use a
fixed tag length, though if the specification is inflexible, we are
faced with the need to choose that length carefully. If backwards
compatibility is desirable, a length of 12 octets would be best; if
security is considered paramount, then the longest is the best. One
way to add flexibility would be to have each AEAD return a fixed-
length authentication tag, but then to define a standard mechanism by
which that tag can be truncated when it is desirable to do so.
The authentication tag could be included in the ciphertext, which
would simplify the interface slightly, but would remove some
flexibility. Most existing security protocols include a separate
integrity check field to carry a message authentication code, so a
separate output for that tag was included in the AEAD interface.
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 January 2, 2007 [Page 18]
Internet-Draft Authenticated Encryption July 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 January 2, 2007 [Page 19]
Internet-Draft Authenticated Encryption July 2006
10. Acknowledgments
Eric Rescorla and Yoshi Kohno provided valuable comments on early
versions of this document.
McGrew Expires January 2, 2007 [Page 20]
Internet-Draft Authenticated Encryption July 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 January 2, 2007 [Page 21]
Internet-Draft Authenticated Encryption July 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 January 2, 2007 [Page 22]
Internet-Draft Authenticated Encryption July 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 January 2, 2007 [Page 23]
