idnits 2.16.02
/tmp/draft-mcgrew-auth-enc-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 949.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 960.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 967.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 973.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The exact meaning of the all-uppercase expression 'MAY NOT' is not
defined in RFC 2119. If it is intended as a requirements expression, it
should be rewritten using one of the combinations defined in RFC 2119;
otherwise it should not be all-uppercase.
== The expression 'MAY NOT', while looking like RFC 2119 requirements text,
is not defined in RFC 2119, and should not be used. Consider using 'MUST
NOT' instead (if that is what you mean).
Found 'MAY NOT' in this paragraph:
AEAD algorithms that rely on distinct nonces MAY NOT be appropriate
for some applications or for some scenarios. Application designers
should understand the requirements outlined in Section 3.1.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 2007) is 4363 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref. 'CCM'
-- Possible downref: Non-RFC (?) normative reference: ref. 'GCM'
-- Obsolete informational reference (is this intentional?): RFC 2434
(Obsoleted by RFC 5226)
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 11 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group D. McGrew
3 Internet-Draft Cisco Systems, Inc.
4 Intended status: Standards Track July 2007
5 Expires: January 2, 2008
7 An Interface and Algorithms for Authenticated Encryption
8 draft-mcgrew-auth-enc-05.txt
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on January 2, 2008.
35 Copyright Notice
37 Copyright (C) The IETF Trust (2007).
39 Abstract
41 This document defines algorithms for authenticated encryption with
42 associated data (AEAD), and defines a uniform interface and a
43 registry for such algorithms. The interface and registry can be used
44 as an application independent set of cryptoalgorithm suites. This
45 approach provides advantages in efficiency and security, and promotes
46 the reuse of crypto implementations.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
51 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
52 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
53 1.3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 4
54 1.4. Conventions Used In This Document . . . . . . . . . . . . 4
55 2. AEAD Interface . . . . . . . . . . . . . . . . . . . . . . . . 5
56 2.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 5
57 2.2. Authenticated Decryption . . . . . . . . . . . . . . . . . 7
58 2.3. Data Formatting . . . . . . . . . . . . . . . . . . . . . 7
59 3. Guidance on the use of AEAD algorithms . . . . . . . . . . . . 9
60 3.1. Requirements on Nonce Generation . . . . . . . . . . . . . 9
61 3.2. Recommended Nonce Formation . . . . . . . . . . . . . . . 10
62 3.2.1. Partially Implicit Nonces . . . . . . . . . . . . . . 11
63 3.3. Construction of AEAD Inputs . . . . . . . . . . . . . . . 11
64 3.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 12
65 4. Requirements on AEAD Algorithm Specifications . . . . . . . . 14
66 5. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 16
67 5.1. AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 16
68 5.1.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 16
69 5.2. AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . . . 17
70 5.3. AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 17
71 5.3.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 18
72 5.4. AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . . . 18
73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
74 7. Other Considerations . . . . . . . . . . . . . . . . . . . . . 21
75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
79 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
81 Intellectual Property and Copyright Statements . . . . . . . . . . 27
83 1. Introduction
85 Authenticated encryption [BN00] is a form of encryption that, in
86 addition to providing confidentiality for the plaintext that is
87 encrypted, provides a way to check its integrity and authenticity.
88 Authenticated encryption with Associated Data, or AEAD [R02], adds
89 the ability to check the integrity and authenticity of some
90 Associated Data (AD), also called "additional authenticated data",
91 that is not encrypted.
93 1.1. Background
95 Many cryptographic applications require both confidentiality and
96 message authentication. Confidentiality is a security service that
97 ensures that data is available only to those authorized to obtain it;
98 usually it is realized through encryption. Message authentication is
99 the service that ensures that data has not been altered or forged by
100 unauthorized entities; it can be achieved by using a Message
101 Authentication Code (MAC). This service is also called data
102 integrity. Many applications use an encryption method and a MAC
103 together to provide both of those security services, with each
104 algorithm using an independent key. More recently, the idea of
105 providing both security services using a single cryptoalgorithm has
106 become accepted. In this concept, the cipher and MAC are replaced by
107 an Authenticated Encryption with Associated Data (AEAD) algorithm.
109 Several crypto algorithms that implement AEAD algorithms have been
110 defined, including block cipher modes of operation and dedicated
111 algorithms. Some of these algorithms have been adopted and proven
112 useful in practice. Additionally, AEAD is close to an 'idealized'
113 view of encryption, such as those used in the automated analysis of
114 cryptographic protocols (see, for example, Section 2.5 of [BOYD]).
116 1.2. Scope
118 In this document we define an AEAD algorithm as an abstraction, by
119 specifying an interface to an AEAD and defining an IANA registry for
120 AEAD algorithms. We populate this registry with four AEAD algorithms
121 based on AES in Galois/Counter Mode [GCM] with 128 and 256 bit keys,
122 and AES in Counter and CBC MAC mode [CCM] with 128 and 256 bit keys.
124 In the following, we define the AEAD interface (Section 2), and then
125 provide guidance on the use of AEAD algorithms (Section 3), and
126 outline the requirements that each AEAD algorithm must meet
127 (Section 4). Then we define several AEAD algorithms (Section 5), and
128 establish an IANA registry for AEAD algorithms (Section 6). Lastly,
129 we discuss some other considerations (Section 7).
131 The AEAD interface specification does not address security protocol
132 issues such as anti-replay services or access control decisions that
133 are made on authenticated data. Instead, the specification aims to
134 abstract the cryptography away from those issues. The interface, and
135 the guidance about how to use it, are consistent with the
136 recommendations from [EEM04].
138 1.3. Benefits
140 The AEAD approach enables applications that need cryptographic
141 security services to more easily adopt those services. It benefits
142 the application designer by allowing them to focus on the important
143 issues such as security services, canonicalization, and data
144 marshaling, and relieving them of the need to design crypto
145 mechanisms that meet their security goals. Importantly, the security
146 of an AEAD algorithm can be analyzed independent from its use in a
147 particular application. This property frees the user of the AEAD of
148 the need to consider security aspects such as the relative order of
149 authentication and encryption and the security of the particular
150 combination of cipher and MAC, such as the potential loss of
151 confidentiality through the MAC. The application designer that uses
152 the AEAD interface need not select a particular AEAD algorithm during
153 the design stage. Additionally, the interface to the AEAD is
154 relatively simple, since it requires only a single key as input and
155 it requires only a single identifier to indicate the algorithm in use
156 in a particular case.
158 The AEAD approach benefits the implementer of the crypto algorithms
159 by making available optimizations that are otherwise not possible to
160 reduce the amount of computation, the implementation cost, and/or the
161 storage requirements. The simpler interface makes testing easier;
162 this is a considerable benefit for a crypto algorithm implementation.
163 By providing a uniform interface to access cryptographic services,
164 the AEAD approach allows a single crypto implementation to more
165 easily support multiple applications. For example, a hardware module
166 that supports the AEAD interface can easily provide crypto
167 acceleration to any application using that interface, even to
168 applications that had not been designed when the module was built.
170 1.4. Conventions Used In This Document
172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
174 document are to be interpreted as described in [RFC2119].
176 2. AEAD Interface
178 An AEAD algorithm has two operations, authenticated encryption and
179 authenticated decryption. The inputs and outputs of these algorithms
180 are defined in terms of octet strings.
182 An implementation MAY accept additional inputs. For example, an
183 input could be provided to allow the user to select between different
184 implementation strategies. However, such extensions MUST NOT affect
185 interoperability with other implementations.
187 2.1. Authenticated Encryption
189 The authenticated encryption operation has four inputs, each of which
190 is an octet string:
192 A secret key K, which MUST be generated in a way that is uniformly
193 random or pseudorandom.
195 A nonce N. Each nonce provided to distinct invocations of the
196 Authenticated Encryption operation MUST be distinct, for any
197 particular value of the key, unless each and every nonce is zero-
198 length. Applications that can generate distinct nonces SHOULD use
199 the nonce formation method defined in Section 3.2, and MAY use any
200 other method that meets the uniqueness requirement. Other
201 applications SHOULD use zero-length nonces.
203 A plaintext P, which contains the data to be encrypted and
204 authenticated,
206 The associated data A, which contains the data to be
207 authenticated, but not encrypted.
209 There is a single output:
211 A ciphertext C, which is as least as long as the plaintext, or
213 an indication that the requested encryption operation could not be
214 performed.
216 All of the inputs and outputs are variable-length octet strings,
217 whose lengths obey the following restrictions:
219 The number of octets in the key K is between one and 255. For
220 each AEAD algorithm, the length of K MUST be fixed.
222 For any particular value of the key, either 1) each nonce provided
223 to distinct invocations of the Authenticated Encryption operation
224 MUST be distinct, or 2) each and every nonce MUST be zero-length.
225 If zero-length nonces are used with a particular key, then each
226 and every nonce used with that key MUST have a length of zero.
227 Otherwise, the number of octets in the nonce SHOULD be twelve
228 (12). Nonces with different lengths MAY be used with a particular
229 key. Some algorithms cannot be used with zero-length nonces, but
230 others can; see Section 4. Applications that conform to the
231 recommended nonce length will avoid having to construct nonces
232 with different lengths, depending on the algorithm that is in use.
233 This guidance helps to keep algorithm-specific logic out of
234 applications.
236 The number of octets in the plaintext P MAY be zero.
238 The number of octets in the associated data A MAY be zero.
240 The number of octets in the ciphertext C MAY be zero.
242 This specification does not put a maximum length on the nonce, the
243 plaintext, the ciphertext, nor the additional authenticated data.
244 However, a particular AEAD algorithm MAY further restrict the lengths
245 of those inputs and outputs. A particular AEAD implementation MAY
246 further restrict the lengths of its inputs and outputs. If a
247 particular implementation of an AEAD algorithm is requested to
248 process an input that is outside the range of admissible lengths, or
249 an input that is outside the range of lengths supported by that
250 implementation, it MUST return an error code and it MUST NOT output
251 any other information. In particular, partially encrypted or
252 partially decrypted data MUST NOT be returned.
254 Both confidentiality and message authentication is provided on the
255 plaintext P. When the length of P is zero, the AEAD algorithm acts as
256 a Message Authentication Code on the input A.
258 The associated data A is used to protect information that needs to be
259 authenticated, but which does not need to be kept confidential. When
260 using an AEAD to secure a network protocol, for example, this input
261 could include addresses, ports, sequence numbers, protocol version
262 numbers, and other fields that indicate how the plaintext or
263 ciphertext should be handled, forwarded, or processed. In many
264 situations, it is desirable to authenticate these fields, though they
265 must be left in the clear to allow the network or system to function
266 properly. When this data is included in the input A, authentication
267 is provided without copying the data into the plaintext.
269 The secret key K MUST NOT be included in any of the other inputs (N,
270 P, and A). (This restriction does not mean that the values of those
271 inputs must be checked to ensure that they do not include substrings
272 that match the key; instead, it means that the key must not be
273 explicitly copied into those inputs.)
275 The nonce is authenticated internally to the algorithm, and it is not
276 necessary to include it in the AD input. The nonce MAY be included
277 in P or A if it is convenient to the application.
279 The nonce MAY be stored or transported with the ciphertext, or it MAY
280 be reconstructed immediately prior to the authenticated decryption
281 operation. It is sufficient to provide the decryption module with
282 enough information to allow it to construct the nonce. (For example,
283 a system could use a nonce consisting of a sequence number in a
284 particular format, in which case it could be inferred from the order
285 of the ciphertexts.) Because the authenticated decryption process
286 detects incorrect nonce values, no security failure will result if a
287 nonce is incorrectly reconstructed and fed into an authenticated
288 decryption operation. Any nonce reconstruction method will need to
289 take into account the possibility of loss or reorder of ciphertexts
290 between the encryption and decryption processes.
292 Applications MUST NOT assume any particular structure or formatting
293 of the ciphertext.
295 2.2. Authenticated Decryption
297 The authenticated decryption operation has four inputs: K, N , A and
298 C, as defined above. It has only a single output, either a plaintext
299 value P or a special symbol FAIL that indicates that the inputs are
300 not authentic. A ciphertext C, a nonce N, and associated data A are
301 authentic for key K when C is generated by the encrypt operation with
302 inputs K, N, P and A, for some values of N, P, and A. The
303 authenticated decrypt operation will, with high probability, return
304 FAIL whenever the inputs N, P, and A were crafted by a nonce-
305 respecting adversary that does not know the secret key (assuming that
306 the AEAD algorithm is secure).
308 2.3. Data Formatting
310 This document does not specify any particular encoding for the AEAD
311 inputs and outputs, since the encoding does not affect the security
312 services provided by an AEAD algorithm.
314 When choosing the format of application data, an application SHOULD
315 position the ciphertext C so that it appears after any other data
316 that is needed to construct the other inputs to the authenticated
317 decryption operation. For instance, if the nonce and ciphertext both
318 appear in a packet, the former value should precede the latter. This
319 rule facilitates efficient and simple hardware implementations of
320 AEAD algorithms.
322 3. Guidance on the use of AEAD algorithms
324 This section provides advice that must be followed in order to use an
325 AEAD algorithm securely.
327 If an application is unable to meet the uniqueness requirement on
328 nonce generation, then it MUST use a zero-length nonce. Randomized
329 or stateful algorithms, which are defined below, are suitable for use
330 with such applications. Otherwise, an application SHOULD use nonces
331 with a length of twelve octets. Since algorithms are encouraged to
332 support that length, applications should use that length to aid
333 interoperability.
335 3.1. Requirements on Nonce Generation
337 It is essential for security that the nonces be constructed in a
338 manner that respects the requirement that each nonce value be
339 distinct for each invocation of the authenticated encryption
340 operation, for any fixed value of the key. In this section we call
341 attention to some consequences of this requirement in different
342 scenarios.
344 When there are multiple devices performing encryption using a single
345 key, those devices must coordinate to ensure that the nonces are
346 unique. A simple way to do this is to use a nonce format that
347 contains a field that is distinct for each one of the devices, as
348 described in Section 3.2. Note that there is no need to coordinate
349 the details of the nonce format between the encrypter and the
350 decrypter, as long the entire nonce is sent or stored with the
351 ciphertext and is thus available to the decrypter. If the complete
352 nonce is not available to the decrypter, then the decrypter will need
353 to know how the nonce is structured so that it can reconstruct it.
354 Applications SHOULD provide encryption engines with some freedom in
355 choosing their nonces; for example, a nonce could contain both a
356 counter and a field that is set by the encrypter but is not processed
357 by the receiver. This freedom allows a set of encryption devices to
358 more readily coordinate to ensure the distinctness of their nonces.
360 If a secret key will be used for a long period of time, e.g. across
361 multiple reboots, then the nonce will need to be stored in non-
362 volatile memory. In such cases it is essential to use checkpointing
363 of the nonce, that is, the current nonce value should be stored to
364 provide the state information needed to resume encryption in case of
365 unexpected failure. One simple way to provide a high assurance that
366 a nonce value will not be used repeatedly is to wait until the
367 encryption process receives confirmation from the storage process
368 indicating that the succeeding nonce value has already been stored.
369 Because this method may add significant latency, it may be desirable
370 to store a nonce value that is several values ahead in the sequence.
371 As an example, the nonce 100 could be stored, after which the nonces
372 1 through 99 could be used for encryption. The nonce value 200 could
373 be stored at the same time that nonces 1 through 99 are being used,
374 and so on.
376 Many problems with nonce re-use can be avoided by changing a key in a
377 situation in which nonce coordination is difficult.
379 Each AEAD algorithm SHOULD describe what security degradation would
380 result from an inadvertent re-use of a nonce value.
382 3.2. Recommended Nonce Formation
384 The following method to construct nonces is RECOMMENDED. The nonce
385 is formatted as illustrated in Figure 1, with the initial octets
386 consisting of a Fixed field, and the final octets consisting of a
387 Counter field. For each fixed key, the length of each of these
388 fields, and thus the length of the nonce, is fixed. Implementations
389 SHOULD support 12-octet nonces in which the Counter field is four
390 octets long.
392 <----- variable ----> <----------- variable ----------->
393 +---------------------+----------------------------------+
394 | Fixed | Counter |
395 +---------------------+----------------------------------+
397 Figure 1: Recommended nonce format.
399 The Counter fields of successive nonces form a monotonically
400 increasing sequence, when those fields are regarded as unsigned
401 integers in network byte order. The length of the Counter field MUST
402 remain constant for all nonces that are generated for a given
403 encryption device. The Counter part SHOULD be equal to zero for the
404 first nonce, and increment by one for each successive nonce that is
405 generated. However, any particular Counter value MAY be skipped
406 over, and left out of the sequence of values that are used, if it is
407 convenient. For example, an application could choose to skip the
408 initial Counter=0 value, and set the Counter field of the initial
409 nonce to 1. Thus at most 2^(8*C) nonces can be generated when the
410 Counter field is C octets in length.
412 The Fixed field MUST remain constant for all nonces that are
413 generated for a given encryption device. If different devices are
414 performing encryption with a single key, then each distinct device
415 MUST use a distinct Fixed field, to ensure the uniqueness of the
416 nonces. Thus at most 2^(8*F) distinct encrypters can share a key
417 when the Fixed field is F octets in length.
419 3.2.1. Partially Implicit Nonces
421 In some cases it is desirable to not transmit or store an entire
422 nonce, but instead to reconstruct that value from contextual
423 information immediately prior to decryption. As an example,
424 ciphertexts could be stored in sequence on a disk, and the nonce for
425 a particular ciphertext could be inferred from its location, as long
426 as the rule for generating the nonces is known by the decrypter. We
427 call the portion of the nonce that is stored or sent with the
428 ciphertext the explicit part. We call the portion of the nonce that
429 is inferred the implicit part. When part of the nonce is implicit,
430 the following specialization of the above format is RECOMMENDED. The
431 Fixed field is divided into two sub-fields: a Fixed-Common field and
432 a Fixed-Distinct field. This format is shown in Figure 2. If
433 different devices are performing encryption with a single key, then
434 each distinct device MUST use a distinct Fixed-Distinct field. The
435 Fixed-Common field is common to all nonces. The Fixed-Distinct field
436 and the Counter field MUST be in the explicit part of the nonce. The
437 Fixed-Common field MAY be in the implicit part of the nonce. These
438 conventions ensure that the nonce is easy to reconstruct from the
439 explicit data.
441 +-------------------+--------------------+---------------+
442 | Fixed-Common | Fixed-Distinct | Counter |
443 +-------------------+--------------------+---------------+
444 <---- implicit ---> <------------ explicit ------------>
446 Figure 2: Partially implicit nonce format
448 The rationale for the partially implicit nonce format is as
449 follows. This method of nonce construction incorporates the best
450 known practice; it is used by both GCM ESP [RFC4106] and CCM ESP
451 [RFC4309], in which the Fixed field contains the Salt value and
452 the lowest eight octets of the nonce are explicitly carried in the
453 ESP packet. In GCM ESP, the Fixed field must be at least four
454 octets long, so that it can contain the Salt value. In CCM ESP,
455 the Fixed field must be at least three octets long for the same
456 reason. This nonce generation method is also used by several
457 counter mode variants including CTR ESP.
459 3.3. Construction of AEAD Inputs
461 If the AD input is constructed out of multiple data elements, then it
462 is essential that it be unambiguously parseable into its constituent
463 elements, without the use of any unauthenticated data in the parsing
464 process. This requirement ensures that an attacker cannot fool a
465 receiver into accepting a bogus set of data elements as authentic by
466 altering a set of data elements that were used to construct an AD
467 input in an authenticated encryption operation in such a way that the
468 data elements are different, but the AD input is unchanged. This
469 requirement is trivially met if the AD is composed of fixed-width
470 elements. If the AD contains a variable-length string, for example,
471 this requirement can be met by also including the length of the
472 string in the AD.
474 Similarly, if the plaintext is constructed out of multiple data
475 elements, then it is essential that it be unambiguously parseable
476 into its constituent elements, without using any unauthenticated data
477 in the parsing process. Note that data included in the AD may be
478 used when parsing the plaintext, though of course since the AD is not
479 encrypted there is a potential loss of confidentiality when
480 information about the plaintext is included in the AD.
482 3.4. Example Usage
484 To make use of an AEAD algorithm, an application must define how the
485 encryption algorithm's inputs are defined in terms of application
486 data, and how the ciphertext and nonce are conveyed. The clearest
487 way to do this is to express each input in terms of the data that
488 form it, then to express the application data in terms of the outputs
489 of the AEAD encryption operation.
491 For example, AES-GCM ESP [RFC4106] can be expressed as follows. The
492 AEAD inputs are
494 P = RestOfPayloadData || TFCpadding || Padding || PadLength ||
495 NextHeader
497 N = Salt || IV
499 A = SPI || SequenceNumber
501 where the symbol "||" denotes the concatenation operation, and the
502 fields RestOfPayloadData, TFCpadding, Padding, PadLength, NextHeader,
503 SPI, and SequenceNumber are as defined in [RFC4303] and the fields
504 Salt and IV are as defined in [RFC4106]. The field RestOfPayloadData
505 contains the plaintext data that is described by the NextHeader
506 field, and no other data. (Recall that the PayloadData field
507 contains both the IV and the RestOfPayloadData; see Figure 2 of
508 [RFC4303] for an illustration.)
510 The format of the ESP packet can be expressed as
512 ESP = SPI || SequenceNumber || IV || C
514 where C is the AEAD ciphertext (which in this case incorporates the
515 authentication tag). Please note that here we have not described the
516 use of the ESP Extended Sequence Number.
518 4. Requirements on AEAD Algorithm Specifications
520 Each AEAD algorithm MUST only accept keys with a fixed key length
521 K_LEN, and MUST NOT require any particular data format for the keys
522 provided as input. An algorithm that requires such structure (e.g.
523 one with subkeys in a particular parity-check format) will need to
524 provide it internally.
526 Each AEAD algorithm MUST accept any plaintext with a length between
527 zero and P_MAX octets, inclusive, where the value P_MAX is specific
528 to that algorithm. The value of P_MAX MUST be larger than zero, and
529 SHOULD be at least 65,536 (2^16) octets. This size is a typical
530 upper limit for network data packets. Other applications may use
531 even larger values of P_MAX, so it is desirable for general-purpose
532 algorithms to support higher values.
534 Each AEAD algorithm MUST accept any associated data with a length
535 between zero and A_MAX octets, inclusive, where the value A_MAX is
536 specific to that algorithm. The value of A_MAX MUST be larger than
537 zero, and SHOULD be at least 65,536 (2^16) octets. Other
538 applications may use even larger values of A_MAX, so it is desirable
539 for general-purpose algorithms to support higher values.
541 Each AEAD algorithm MUST accept any nonce with a length between N_MIN
542 and N_MAX octets, inclusive, where the values of N_MIN and N_MAX are
543 specific to that algorithm. The values of N_MAX and N_MIN MAY be
544 equal. Each algorithm SHOULD accept a nonce with a length of twelve
545 (12) octets. Randomized or stateful algorithms, which are described
546 below, MAY have an N_MAX value of zero.
548 An AEAD algorithm MAY structure its ciphertext output in any way; for
549 example, the ciphertext can incorporate an authentication tag. Each
550 algorithm SHOULD choose a structure that is amenable to efficient
551 processing.
553 An Authenticated Encryption algorithm MAY incorporate or make use of
554 a random source, e.g. for the generation of an internal
555 initialization vector that is incorporated into the ciphertext
556 output. An AEAD algorithm of this sort is called randomized; though
557 note that only encryption is random, and decryption is always
558 deterministic. A randomized algorithm MAY have a value of N_MAX that
559 is equal to zero.
561 An Authenticated Encryption algorithm MAY incorporate internal state
562 information that is maintained between invocations of the encrypt
563 operation, e.g. to allow for the construction of distinct values that
564 are used as internal nonces by the algorithm. An AEAD algorithm of
565 this sort is called stateful. This method could be used by an
566 algorithm to provide good security even when the application inputs
567 zero-length nonces. A stateful algorithm MAY have a value of N_MAX
568 that is equal to zero.
570 The specification of an AEAD algorithm MUST include the values of
571 K_LEN, P_MAX, A_MAX, N_MIN, and N_MAX defined above. Additionally,
572 it MUST specify the number of octets in the largest possible
573 ciphertext, which we denote C_MAX.
575 Each AEAD algorithm MUST provide a description relating the length of
576 the plaintext to that of the ciphertext. This relation MUST NOT
577 depend on external parameters, such as an authentication strength
578 parameter (e.g. authentication tag length). That sort of dependence
579 would complicate the use of the algorithm by creating a situation in
580 which the information from the AEAD registry was not sufficient to
581 ensure interoperability.
583 EACH AEAD algorithm specification SHOULD describe what security
584 degradation would result from an inadvertent re-use of a nonce value.
586 Each AEAD algorithm specification SHOULD provide a reference to a
587 detailed security analysis. This document does not specify a
588 particular security model, because several different models have been
589 used in the literature. The security analysis SHOULD define or
590 reference a security model.
592 An algorithm that is randomized or stateful, as defined above, SHOULD
593 describe itself using those terms.
595 5. AEAD Algorithms
597 This section defines four AEAD algorithms; two are based on AES GCM,
598 two are based on AES CCM. Each pair includes an algorithm with a key
599 size of 128 bits and one with a key size of 256 bits.
601 5.1. AEAD_AES_128_GCM
603 The AEAD_AES_128_GCM authenticated encryption algorithm works as
604 specified in [GCM], using AES-128 as the block cipher, by providing
605 the key, nonce, and plaintext, and associated data to that mode of
606 operation. An authentication tag with a length of 16 octets (128
607 bits) is used. The AEAD_AES_128_GCM ciphertext is formed by
608 appending the authentication tag provided as an output to the GCM
609 encryption operation to the ciphertext that is output by that
610 operation. Test cases are provided in the appendix of [GCM]. The
611 input and output lengths are as follows:
613 K_LEN is 16 octets,
615 P_MAX is 2^36 - 31 octets,
617 A_MAX is 2^61 - 1 octets,
619 N_MIN and N_MAX are both 12 octets, and
621 C_MAX is 2^36 - 15 octets.
623 An AEAD_AES_128_GCM ciphertext is exactly 16 octets longer than its
624 corresponding plaintext.
626 A security analysis of GCM is available in [MV04].
628 5.1.1. Nonce Reuse
630 Inadvertent reuse of the same nonce by two invocations of the GCM
631 encryption operation, with the same key, undermines the security of
632 all of the subsequent uses of that key. For this reason, GCM should
633 only be used whenever nonce uniqueness can be provided with
634 assurance. The design feature that GCM uses to achieve minimal
635 latency causes the vulnerabilities on the subsequent uses of the key.
636 Note that it is acceptable to input the same nonce value multiple
637 times to the decryption operation.
639 The security consequences are quite serious if an attacker observes
640 two ciphertexts that were created using the same nonce and key
641 values, unless the plaintext and AD values in both invocations of the
642 encrypt operation were identical. First, a loss of confidentiality
643 ensues because he will be able to reconstruct the bitwise
644 exclusive-or of the two plaintext values. Second, a loss of
645 integrity ensues because the attacker will be able to recover the
646 internal hash key used to provide data integrity. Knowledge of this
647 key makes subsequent forgeries trivial.
649 5.2. AEAD_AES_256_GCM
651 This algorithm is identical to AEAD_AES_128_GCM, but with the
652 following differences:
654 K_LEN is 32 octets, instead of 16 octets, and
656 AES-256 GCM is used instead of AES-128 GCM.
658 5.3. AEAD_AES_128_CCM
660 The AEAD_AES_128_CCM authenticated encryption algorithm works as
661 specified in [CCM], using AES-128 as the block cipher, by providing
662 the key, nonce, associated data, and plaintext to that mode of
663 operation. The formatting and counter generation function are as
664 specified in Appendix A of that reference, and the values of the
665 parameters identified in that appendix are as follows:
667 the nonce length n is 12,
669 the tag length t is 16, and
671 the value of q is 3.
673 An authentication tag with a length of 16 octets (128 bits) is used.
674 The AEAD_AES_128_CCM ciphertext is formed by appending the
675 authentication tag provided as an output to the CCM encryption
676 operation to the ciphertext that is output by that operation. Test
677 cases are provided in [CCM]. The input and output lengths are as
678 follows:
680 K_LEN is 16 octets,
682 P_MAX is 2^24 - 1 octets,
684 A_MAX is 2^64 - 1 octets,
686 N_MIN and N_MAX are both 12 octets, and
688 C_MAX is 2^24 + 15 octets.
690 An AEAD_AES_128_CCM ciphertext is exactly 16 octets longer than its
691 corresponding plaintext.
693 A security analysis of AES CCM is available in [J02].
695 5.3.1. Nonce Reuse
697 Inadvertent reuse of the same nonce by two invocations of the CCM
698 encryption operation, with the same key, undermines the security for
699 the messages processed with those invocations. A loss of
700 confidentiality ensues because an adversary will be able to
701 reconstruct the bitwise exclusive-or of the two plaintext values.
703 5.4. AEAD_AES_256_CCM
705 This algorithm is identical to AEAD_AES_128_CCM, but with the
706 following differences:
708 K_LEN is 32 octets, instead of 16, and
710 AES-256 CCM is used instead of AES-128 CCM.
712 6. IANA Considerations
714 The Internet Assigned Numbers Authority (IANA) will define the "AEAD
715 Registry" described below. An algorithm designer MAY register an
716 algorithm in order to facilitate its use. Additions to the AEAD
717 Registry require that a specification be documented in an Internet
718 RFC or another permanent and readily available reference, in
719 sufficient detail that interoperability between independent
720 implementations is possible. Each entry in the registry contains the
721 following elements:
723 a short name, such as "AEAD_AES_128_GCM", that starts with the
724 string "AEAD",
726 a positive number, and
728 a reference to a specification that completely defines an AEAD
729 algorithm and provides test cases that can be used to verify the
730 correctness of an implementation.
732 Requests to add an entry to the registry MUST include the name and
733 the reference. The number is assigned by IANA. These number
734 assignments SHOULD use the smallest available positive number.
735 Submitters SHOULD have their requests reviewed by the IRTF Crypto
736 Forum Research Group (CFRG) at cfrg@ietf.org. Interested applicants
737 that are unfamiliar with IANA processes should visit
738 http://www.iana.org.
740 The numbers between 32,768 (binary 1000000000000000) and 65,535
741 (binary 1111111111111111) inclusive, will not be assigned by IANA,
742 and are reserved for private use; no attempt will be made to prevent
743 multiple sites from using the same value in different (and
744 incompatible) ways [RFC2434].
746 IANA will add the following entries to the AEAD Registry:
748 +------------------+-------------+--------------------+
749 | Name | Reference | Numeric Identifier |
750 +------------------+-------------+--------------------+
751 | AEAD_AES_128_GCM | Section 5.1 | 1 |
752 | | | |
753 | AEAD_AES_256_GCM | Section 5.2 | 2 |
754 | | | |
755 | AEAD_AES_128_CCM | Section 5.3 | 3 |
756 | | | |
757 | AEAD_AES_256_CCM | Section 5.4 | 4 |
758 +------------------+-------------+--------------------+
760 An IANA registration of an AEAD does not constitute an endorsement of
761 that algorithm or its security.
763 7. Other Considerations
765 Directly testing a randomized AEAD encryption algorithm using test
766 cases with fixed inputs and outputs is not possible, since the
767 encryption process is non-deterministic. However, it is possible to
768 test a randomized AEAD algorithm using the following technique. The
769 authenticated decryption algorithm is deterministic, and it can be
770 directly tested. The authenticated encryption algorithm can be
771 tested by encrypting a plaintext, decrypting the resulting
772 ciphertext, and comparing the original plaintext to the post-
773 decryption plaintext. Combining both of these tests covers both the
774 encryption and decryption algorithms.
776 The AEAD algorithms selected reflect those that have been already
777 adopted by standards. It is an open question as to what other AEAD
778 algorithms should be added. Many variations on basic algorithms are
779 possible, each with its own advantages. While it is desirable to
780 admit any algorithms that are found to be useful in practice, it is
781 also desirable to limit the total number of registered algorithms.
782 The current specification requires that a registered algorithm
783 provide a complete specification and a set of validation data; it is
784 hoped that these prerequisites set the admission criteria
785 appropriately.
787 It may be desirable to define an AEAD algorithm that uses the generic
788 composition with the encrypt-then-MAC method [BN00], combining a
789 common encryption algorithm, such as CBC [MODES], with a common
790 message authentication code, such as HMAC-SHA1 [RFC2104] or AES CMAC
791 [CMAC]. An AEAD algorithm of this sort would reflect the best
792 current practice, and might be more easily supported by crypto
793 modules that lack support for other AEAD algorithms.
795 8. Security Considerations
797 This document describes authenticated encryption algorithms, and
798 provides guidance on their use. While these algorithms make it
799 easier, in some ways, to design a cryptographic application, it
800 should be borne in mind that strong cryptographic security is
801 difficult to achieve. While AEAD algorithms are quite useful, they
802 do nothing to address the issues of key generation [RFC4086] and key
803 management [RFC4107].
805 AEAD algorithms that rely on distinct nonces MAY NOT be appropriate
806 for some applications or for some scenarios. Application designers
807 should understand the requirements outlined in Section 3.1.
809 A software implementation of the AEAD encryption operation in a
810 Virtual Machine (VM) environment could inadvertently re-use a nonce
811 due to a "rollback" of the VM to an earlier state [GR05].
812 Applications are encouraged to document potential issues to help the
813 user of the application and the VM avoid unintentional mistakes of
814 this sort. The possibility exists that an attacker can cause a VM
815 rollback; threats and mitigations in that scenario are an area of
816 active research. For perspective, we note that an attacker who can
817 trigger such a rollback may have already succeeded in subverting the
818 security of the system, e.g. by causing an accounting error.
820 An IANA registration of an AEAD algorithm MUST NOT be regarded as an
821 endorsement of its security. Furthermore, the perceived security
822 level of an algorithm can degrade over time, due to cryptanalytic
823 advances or to "Moore's Law", that is, the diminishing cost of
824 computational resources over time.
826 9. Acknowledgments
828 Many reviewers provided valuable comments on earlier drafts of this
829 document. Some fruitful discussions took place on the email list of
830 the Crypto Forum Research Group in 2006.
832 10. References
834 10.1. Normative References
836 [CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM
837 Mode for Authentication and Confidentiality", U.S.
838 National Institute of Standards and Technology http://
839 csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf.
841 [GCM] Dworkin, M., "NIST Special Publication 800-38D:
842 Recommendation for Block Cipher Modes of Operation:
843 Galois/Counter Mode (GCM) and GMAC.", U.S. National
844 Institute of Standards and Technology http://
845 csrc.nist.gov/publications/nistpubs/800-38D/SP800-38D.pdf.
847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
848 Requirement Levels", BCP 14, RFC 2119, March 1997.
850 10.2. Informative References
852 [BN00] Bellare, M. and C. Namprempre, "Authenticated encryption:
853 Relations among notions and analysis of the generic
854 composition paradigm", Proceedings of ASIACRYPT 2000,
855 Springer-Verlag, LNCS 1976, pp. 531-545 http://
856 www-cse.ucsd.edu/users/mihir/papers/oem.html.
858 [BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication
859 and Key Establishment", Springer, 2003 .
861 [CMAC] "NIST Special Publication 800-38B", http://csrc.nist.gov/
862 CryptoToolkit/modes/800-38_Series_Publications/
863 SP800-38B.pdf.
865 [EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and
866 provably repairing the SSH authenticated encryption
867 scheme: A case study of the Encode-then-Encrypt-and-MAC
868 paradigm", ACM Transactions on Information and System Secu
869 rity, http://www-cse.ucsd.edu/users/tkohno/papers/
870 TISSEC04/.
872 [GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder
873 than Real: Security Challenges in Virtual Machine Based
874 Computing Environments", Proceedings of the 10th Workshop
875 on Hot Topics in Operating Systems http://
876 www.stanford.edu/~talg/papers/HOTOS05/
877 virtual-harder-hotos05.pdf.
879 [J02] Jonsson, J., "On the Security of CTR + CBC-MAC",
880 Proceedings of the 9th Annual Workshop on Selected Areas
881 on Cryptography, http://csrc.nist.gov/CryptoToolkit/modes/
882 proposedmodes/ccm/ccm-ad1.pdf, 2002.
884 [MODES] Dworkin, M., "NIST Special Publication 800-38:
885 Recommendation for Block Cipher Modes of Operation", U.S.
886 National Institute of Standards and Technology http://
887 csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.
889 [MV04] McGrew, D. and J. Viega, "The Security and Performance of
890 the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT
891 '04, http://eprint.iacr.org/2004/193, December 2004.
893 [R02] Rogaway, P., "Authenticated encryption with Associated-
894 Data", ACM Conference on Computer and Communication
895 Security (CCS'02), pp. 98-107, ACM Press,
896 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.html.
898 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
899 Hashing for Message Authentication", RFC 2104,
900 February 1997.
902 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
903 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
904 October 1998.
906 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
907 Requirements for Security", BCP 106, RFC 4086, June 2005.
909 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
910 (GCM) in IPsec Encapsulating Security Payload (ESP)",
911 RFC 4106, June 2005.
913 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
914 Key Management", BCP 107, RFC 4107, June 2005.
916 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
917 RFC 4303, December 2005.
919 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
920 Mode with IPsec Encapsulating Security Payload (ESP)",
921 RFC 4309, December 2005.
923 Author's Address
925 David A. McGrew
926 Cisco Systems, Inc.
927 510 McCarthy Blvd.
928 Milpitas, CA 95035
929 US
931 Phone: (408) 525 8651
932 Email: mcgrew@cisco.com
933 URI: http://www.mindspring.com/~dmcgrew/dam.htm
935 Full Copyright Statement
937 Copyright (C) The IETF Trust (2007).
939 This document is subject to the rights, licenses and restrictions
940 contained in BCP 78, and except as set forth therein, the authors
941 retain all their rights.
943 This document and the information contained herein are provided on an
944 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
945 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
946 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
947 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
948 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
949 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
951 Intellectual Property
953 The IETF takes no position regarding the validity or scope of any
954 Intellectual Property Rights or other rights that might be claimed to
955 pertain to the implementation or use of the technology described in
956 this document or the extent to which any license under such rights
957 might or might not be available; nor does it represent that it has
958 made any independent effort to identify any such rights. Information
959 on the procedures with respect to rights in RFC documents can be
960 found in BCP 78 and BCP 79.
962 Copies of IPR disclosures made to the IETF Secretariat and any
963 assurances of licenses to be made available, or the result of an
964 attempt made to obtain a general license or permission for the use of
965 such proprietary rights by implementers or users of this
966 specification can be obtained from the IETF on-line IPR repository at
967 http://www.ietf.org/ipr.
969 The IETF invites any interested party to bring to its attention any
970 copyrights, patents or patent applications, or other proprietary
971 rights that may cover technology that may be required to implement
972 this standard. Please address the information to the IETF at
973 ietf-ipr@ietf.org.
975 Acknowledgment
977 Funding for the RFC Editor function is provided by the IETF
978 Administrative Support Activity (IASA).