Network Working Group D. McGrew Internet-Draft J. Foley Intended status: Standards Track Cisco Systems Expires: April 18, 2014 October 15, 2013 Authenticated Encryption with Replay prOtection (AERO) draft-mcgrew-aero-00.txt Abstract This document describes Authenticated Encryption with Replay prOtection (AERO), a cryptographic technique that provides all of the essential security services needed for communication security. AERO offers several advantages over other methods: it has more compact messages, provides stronger misuse resistance, avoids the need to manage implicit state, and is simpler to use. This document defines a particular AERO algorithm as well as a registry for such algorithms. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 18, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must McGrew & Foley Expires April 18, 2014 [Page 1] Internet-Draft AERO October 2013 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3 1.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Data types and notation . . . . . . . . . . . . . . . . . 5 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Problems addressed by AERO . . . . . . . . . . . . . . . . 6 3. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Encryption Initialization . . . . . . . . . . . . . . . . 8 3.2. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Decryption Initialization . . . . . . . . . . . . . . . . 9 3.4. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Multiple senders and multiple receivers . . . . . . . . . 9 3.6. AEAD interface . . . . . . . . . . . . . . . . . . . . . . 10 4. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Contexts . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Encryption Initialization . . . . . . . . . . . . . . . . 12 4.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Decryption Initialization . . . . . . . . . . . . . . . . 13 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Stateless encryption algorithms . . . . . . . . . . . . . . . 16 5.1. Wide PRP (WPRP) . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. AERO-AES-XCB . . . . . . . . . . . . . . . . . . . . . 18 5.2. Other cryptographic techniques . . . . . . . . . . . . . . 18 6. Loss, reorder, and resynchronization . . . . . . . . . . . . . 20 7. Usage and applicability . . . . . . . . . . . . . . . . . . . 22 8. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. AERO_AES_128_XCB . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. Security considerations . . . . . . . . . . . . . . . . . . . 26 11.1. Authentication and confidentiality . . . . . . . . . . . . 26 11.1.1. Authentication strength . . . . . . . . . . . . . . . 28 11.2. Length hiding . . . . . . . . . . . . . . . . . . . . . . 29 11.3. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 29 11.4. Multiple senders . . . . . . . . . . . . . . . . . . . . . 30 11.5. Sequence number management failure . . . . . . . . . . . . 31 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 13.1. Normative references . . . . . . . . . . . . . . . . . . . 33 13.2. Informative references . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 McGrew & Foley Expires April 18, 2014 [Page 2] Internet-Draft AERO October 2013 1. Introduction This document describes Authenticated Encryption with Replay prOtection (AERO), a cryptographic technique that provides all of the essential security services needed for communication security. AERO can be considered a stateful and self-synchronizing authenticated encryption method that provides protection from replay attacks as a side benefit. Replay protection and authentication are provided through a single mechanism, in which a sequence number is encrypted along with a plaintext message. If the ciphertext message is not tampered with, then this sequence number will be recovered by the decrypter, and verified to be valid. If the ciphertext message is a replay of an earlier message, then the decrypter will detect this fact from the recovered sequence number. If the ciphertext message is tampered with, or is crafted as a forgery, this fact will be apparent to the decrypter because the value that should be a valid sequence is instead a pseudorandom value. AERO makes use of an underlying stateless encryption algorithm. This note defines a set of AERO algorithms that are based on the Advanced Encryption Standard (AES) [FIPS197] in the eXtended Code Book (XCB) mode of operation [MF07][1619.2]. AERO is not, by itself, a block cipher mode of operation. This note is structured as follows. Section 1 introduces the basic idea of AERO, describes the conventions and notations used in this note, and provides a glossary of acronyms and variables. Section 2 provides background on the problems that AERO solves. The interface and implementation are presented in Section 3 and Section 4, respectively. The underlying cryptographic primitives are described in Section 5. Section 6 describes synchronization between encrypters and decrypters, and Section 7 describes usage. A rationale for the design details is offered in Section 8, and test considerations and test cases are presented in Section 9. IANA considerations and security considerations follow in Section 10 and Section 11, respectively. 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]. 1.2. Glossary This section describes the symbols and acronyms used in this document. McGrew & Foley Expires April 18, 2014 [Page 3] Internet-Draft AERO October 2013 A - Associated Data. An unencrypted value whose integrity and authenticity is to be protected. AERO - Authenticated Encryption with Replay prOtection. A cryptographic technique that combines the three security services essential to communication security. C - Ciphertext. An encrypted value that corresponds to a plaintext. FAIL - a value returned by the AERO decryption operation to indicate that a ciphertext message is not valid; it could be either a replay or a forgery attempt. K - Key. A secret key that is shared between the sender(s) and receiver(s). M - bitmask. A bit vector used by the AERO decryption algorithm that holds information about the sequence numbers that have already been accepted. If a message with the sequence number X has been accepted and the current sequence number S > X, then M[S-X] = 1; otherwise M[S-X] = 0. P - Plaintext. An unencrypted value whose confidentiality, integrity and authenticity is to be protected. PMIN - minimum number of bytes of plaintext for a stateless encryption algorithm. PMIN is a parameter of the stateless encryption algorithm, which is used in the padding logic. R - the last rejected candidate sequence number that is greater than the current sequence number S. A T-bit unsigned integer maintained by the AERO decryption algorithm. S - the current sequence number. A T-bit unsigned integer maintained by the AERO encryption algorithm, where it represents the sequence number of the next message to be encrypted, and by the AERO decryption algorithm, where it represents the last candidate sequence number that was accepted. T - The number of bits in the sequence number that is internal to AERO encryption and decryption. W - Reorder tolerance parameter. A parameter used in AERO decryption (but not encryption) that determines the amount of message loss or reorder that the algorithm will tolerate. This value is 64 by default, but other values may be used as well. McGrew & Foley Expires April 18, 2014 [Page 4] Internet-Draft AERO October 2013 V - Resynchronization parameter. A parameter that determines the amount of message loss or reorder that the AERO decryption algorithm will tolerate during resynchronization. This value is 8 by default, but other values may be used as well. Z - the candidate sequence number. A value used in AERO decryption that may be a sequence number, or alternately may be data that resulted from the actions of an attacker. 1.3. Data types and notation An octet string is an ordered sequence of eight-bit values. Note that these strings are not character strings, and issues such as character representation are out of scope for this note. len(X) denotes the number of bits in the string X, expressed as an unsigned integer in network byte order. The concatenation of two octet strings A and B is denoted as A || B Conversion between unsigned integers and octet strings is done as follows. The Integer to String (I2S) algorithm takes as input an unsigned integer U, and converts it to network byte order (that is, a big-endian representation, in which the most significant octet is the initial one), and then returns the resulting octet string. The String to Integer (S2I) algorithm takes as input an octet string S, considers it as an integer in network byte order, and then converts it into the internal representation for unsigned integers used by the system. McGrew & Foley Expires April 18, 2014 [Page 5] Internet-Draft AERO October 2013 2. Background 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. AEAD is used in many communication security protocols, such as ESP, TLS, DTLS, IKE, and SRTP. These protocols also incorporate replay protection using an sequence number that is carried in the packet, which is authenticated because it is part of the associated data. This security service enables the receiver of a message to detect when a received message is a duplicate of a previously received message. In order to minimize the data overhead, some protocols (such as SRTP and ESP) have the most significant part of the sequence number (that is, the high order bits) be implicit state, which is not sent on the wire. The receiver constructs an estimate of the sequence number from the data on the wire and its current state. Authenticated Encryption with Replay prOtection (AERO) extends AEAD so that it provides a replay protection service. It also enables a receiver to correctly sequence all of the messages that it receives into the same order that they were sent. A replay protection service has a reorder tolerance parameter W; if a receiver processes a message that is more than W messages earlier than a previously processed message, then the service will reject the message even if it is not a replay. 2.1. Problems addressed by AERO Many communication security protocols are operated in environments where bandwidth is a scarce resource, and thus they seek to minimize the data overhead, that is, the number of additional bytes that must be communicated in order to add confidentiality, authenticity, and replay protection to each message. To authenticate a message, lengthening it is unavoidable. However, traditional encryption and replay protection techniques add avoidable overhead. Encryption methods methods such as AES-CBC encryption [SP800-38] have an average overhead of 24 bytes, and many uses of CTR, GCM [GCM], and CCM [CCM] have eight bytes of overhead because a nonce is carried in each message. In addition to that overhead, replay protection typically adds its own overhead; the use of a four-byte sequence number, for instance, adds that number of bytes. McGrew & Foley Expires April 18, 2014 [Page 6] Internet-Draft AERO October 2013 Some communication security protocol uses an implicit or partly implicit sequence number to reduce overhead. This practice complicates the use of that protocol whenever there are multiple receivers, since it is necessary to (securely) communicate the current value of the implicit part of the sequence number to a new receiver at the time that the receiver joins the session. For instance, [RFC4771] furnishes an example of the complications introduced by the need to manage implicit state. Several cryptographic algorithms require that a distinct nonce is input into each invocation of the encryption algorithm. This requirement is difficult to satisfy if there are multiple senders, or multiple encryption units, using the same secret key. Algorithms that require nonces introduce significant complexity into the systems that use them, as is revealed by the survey of usage of and issues with nonces in Internet protocols [IV-GEN]. Several cryptographic algorithms that require a distinct nonce as an input have a serious security degradation if there is nonce misuse (that is, if a system failure results in two or more identical nonces being used for the same key). CTR, CCM, and GCM all have a loss of confidentiality for each message that is associated with a misused nonce. GCM, GMAC [GCM], UMAC [RFC4418], and POLY1305 leak their authentication keys after nonce misuse. In scenarios in which it is not possible to provide high assurance that nonces will not be misused, these algorithms may not be appropriate. Both dedicated authenticated encryption algorithms, and the traditional method of combination of separate authentication and encryption algorithms, are often complex to use. Nonces and initialization vectors, especially, are often a source of confusion for implementers and application designers. AERO solves these problems by using a technique that combines message authentication with replay protection, thus eliminating the data overhead associated with replay protection and any need for using implicit state. AERO does not use a nonce as input, which addresses multiple issues: it reduces data overhead, it avoids all of the problems of coordinating nonces and the potential problems of nonce misuse, and it simplifies the jobs of the designers and implementers of applications and protocols. AERO can easily be used in multiple- sender scenarios, because no coordination of nonces is needed, and in multiple-receiver scenarios, because no coordination of implicit state is needed. McGrew & Foley Expires April 18, 2014 [Page 7] Internet-Draft AERO October 2013 3. Interface An AERO algorithm has four operations: encryption, decryption, encryption initialization, and decryption initialization. The inputs and outputs of these algorithms are defined below in terms of octet strings. An octet string is an ordered sequence of eight-bit values. The terms "AERO encryption" and "AERO decryption" refer to algorithms that provide authenticated encryption with replay protection. For brevity, these algorithms are simply called "encryption" and "decryption" when AERO is clear from the context. An implementation MAY accept additional inputs to these algorithms. For example, an optional input could be provided to allow the user to select between different implementation strategies. However, such extensions MUST NOT affect interoperability with other implementations. 3.1. Encryption Initialization The encryption initialization operation has one input: A secret key K, which MUST be generated in a way that is uniformly random or pseudorandom. This input is an octet string. The number of octets in K is fixed for each AERO algorithm, and is between 1 and 255. The operation has a single output, an AERO encryption context. 3.2. Encryption The AERO encryption operation has three inputs, each of which is an octet string: An AERO encryption context. A plaintext P, which contains the data to be encrypted and authenticated. The number of octets in P MAY be zero. The associated data A, which contains the data to be authenticated, but not encrypted. The number of octets in A MAY be zero. There is a single output: A ciphertext C, which is an octet string that is at least as long as the plaintext. McGrew & Foley Expires April 18, 2014 [Page 8] Internet-Draft AERO October 2013 A plaintext P and its associated data A is sometimes denoted together as (A, P), and that pair of elements is called a plaintext message. Similarly, a ciphertext C and its associated data A is denoted together as (A, C), and is called a ciphertext message. 3.3. Decryption Initialization The decryption initialization operation has one or two inputs: A secret key K, which MUST match the secret key used in the corresponding encryption initialization. This input is an octet string. The reorder tolerance parameter W, a non-negative integer which indicates the amount of reorder of messages that must be tolerated. This input is optional; when it is not provided as an input, the default value of 64 SHOULD be used. The operation has a single output, an AERO decryption context. 3.4. Decryption The AERO decryption operation has three inputs, each of which is an octet string: An AERO decryption context. An octet string C. The associated data A, which contains the data to be authenticated, but not encrypted. The length of A MAY be zero. The output is one of these two alternatives: An octet string P and an unsigned integer indicating the order in which P appeared in the sequence of plaintexts input to the send algorithm, or The symbol FAIL, which indicates that either the value C was not output by the send algorithm, or that (A, C) matches a previously accepted pair of values. 3.5. Multiple senders and multiple receivers A communications security protocol may have multiple senders (encrypters) as well as multiple receivers (decrypters). A single AERO key MAY be used by multiple senders, in which case each sender MUST use a distinct AERO encryption context. McGrew & Foley Expires April 18, 2014 [Page 9] Internet-Draft AERO October 2013 When multiple AERO encryption contexts are in use for a single key, a receiver must use a distinct AERO decryption context to process the messages encrypted with each distinct encryption context. That is, the receiver maintains a decryption context for each sender. This matches the conventional practice of communication security protocols, in which the receiver maintains a distinct security association for each sender. When processing a protected message, a receiver needs to select the appropriate AERO context to use in processing that message. Thus, each protected message must be associated with some indication of its sender. We call a field that contains this indication a Sender IDentifier (SID). When there are multiple senders, the values of the associated data input to the encryption algorithm for different senders SHOULD be distinct. This practice ensures that no two messages are identical, and that fact ensures that the AERO system provides strong confidentiality. An easy way to ensure the distinctness of Associated Data values is to include an SID in those values. For example, this requirement is met if the associated data includes a message header, and that header contains a field that identifies the sender of the message. Alternatively, the value of the plaintext can be distinct for each sender, for instance, if each plaintext includes an SID. If senders accidentally use the same SID value, the security of the session will degrade, but not catastrophically. See section Section 11.4 for more details. 3.6. AEAD interface AERO can be used through the IETF standard interface for authenticated encryption with associated data [RFC5116]. As AERO does not use a nonce or initialization vector, N_MAX = N_MIN = 0, and the application using the AEAD interface need not provide a nonce. Note that most of the usage guidance in RFC 5116 describes stipulations and cautions on the use of the nonces, so by eliminating the need for a nonce, AERO is simplifying the use of this standard. McGrew & Foley Expires April 18, 2014 [Page 10] Internet-Draft AERO October 2013 4. Implementation AERO makes use of a technique that combines message authentication with replay protection, in which the sender maintains a sequence number, and the encrypted value of this sequence number is communicated to the receiver. When the receiver decrypts a message, it parses out the data that would be equal to a sequence number if the message was sent by a legitimate sender, and verifies that this data is sensible. This data is called a candidate sequence number, and is denoted as Z; the verification process is detailed below. If the data is not sensible, then the decryption algorithm rejects the message. The technique provides authenticity because Z is a pseudorandom function of both the ciphertext and associated data, and in a forgery attempt, Z will be rejected with overwhelming probability. AERO is a stateful encryption method. It makes use of an underlying stateless encryption method; the interface to this method is defined below. This interface allows an AERO implementation to separate out the authentication and replay protection logic from the cryptographic algorithms that provide pseudorandomness. The interface also facilitates the use of different cryptographic techniques, thus allowing algorithm agility. The stateless encryption algorithm takes as input a secret key K, a plaintext P, a T-bit unsigned integer S, and an associated data A, and returns a ciphertext C. Here K, A, P, and C are all octet strings. The stateless decryption algorithm takes as input a secret key K, a ciphertext C, and an associated data A, and returns a plaintext P and a T-bit unsigned integer U. The stateless encryption algorithm may not be able to encrypt plaintexts that are shorter than a certain minimum value, so plaintexts are lengthend with the "pad" routine prior to encryption, and padding is removed after decryption with the "strip" routine. We denote as PMIN the minimum number of bytes in a plaintext that the stateful encryption algorithm can accept. Note that the stateless encryption provides only confidentiality, and not authenticity. 4.1. Contexts An encryption context includes a T-bit unsigned integer that holds the sequence number S. McGrew & Foley Expires April 18, 2014 [Page 11] Internet-Draft AERO October 2013 A decryption context includes a W-bit bitmask M and two T-bit unsigned integers S and R, which record the highest candidate sequence number that has been accepted, and the last candidate sequence number that has been rejected, respectively. 4.2. Encryption Initialization The encryption initialization operation does the following: 1. S is initialized to zero. 2. The value of the secret key K is stored in the context. 4.3. Encryption To encrypt a message (A, P), the following steps are performed: 1. The current sequence number S is read from the context. If S is greater than 2^T - 1, then the context cannot be used to encrypt any messages, so an indication of this error state is returned and the encryption processing halts. Otherwise, processing continues as follows. 2. U is set to the value of a S converted from an unsigned integer to an octet string using the Integer to String (I2S) routine described in Section 1.3. 3. If PMIN * 8 > T, then P is lengthened by appending a padding string PS to it, to ensure that L = len(P) + len(PS) + T is at least 128. The value of PS is as follows: PS = 00 if len(P) + T >= 120, PS = 0101 if len(P) + T = 112, PS = 020202 if len(P) + T = 104, PS = 03030303 if len(P) + T = 96, PS = 0404040404 if len(P) + T = 88, PS = 050505050505 if len(P) + T = 80, PS = 06060606060606 if len(P) + T = 72, PS = 0707070707070707 if len(P) + T = 64, PS = 080808080808080808 if len(P) + T = 56, PS = 09090909090909090909 if len(P) + T = 48, PS = 0A0A0A0A0A0A0A0A0A0A0A if len(P) + T = 40, PS = 0B0B0B0B0B0B0B0B0B0B0B0B if len(P) + T = 32, PS = 0C0C0C0C0C0C0C0C0C0C0C0C0C if len(P) + T = 24, PS = 0D0D0D0D0D0D0D0D0D0D0D0D0D0D if len(P) + T = 16, PS = 0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E if len(P) + T = 8. Note that padding MUST be appended to the plaintext if McGrew & Foley Expires April 18, 2014 [Page 12] Internet-Draft AERO October 2013 PMIN * 8 > T, and otherwise padding MUST NOT be used. As the parameter T is fixed for each particular key, either all of the messages processed by a particular key will use padding, or all will not. 4. The stateless encryption algorithm is applied to U, P, and A, using the secret key from the context. 5. The sequence number in the context is incremented by one. 6. The ciphertext C resulting from the stateless encryption algorithm is returned. A P +----|------|------------------+ | | | | | | | +------+ | | | | | | | | | | v +----+ | | | | S ->| +1 | | | | | | +----+ | | | v v | | | +-----+ +-----+ | AERO | | | pad | | I2S | | encryption | | +-----+ +-----+ | | | | | | | v v v | | +------------------+ | K ---->| stateless | | | | encryption | | | +------------------+ | | | | +-----------|------------------+ v C Figure 1: An illustration of the AERO encryption process. 4.4. Decryption Initialization During the decryption initialization process, 1. S is initialized to the reorder tolerance parameter W, 2. R is initialized to 2^T - 1, and McGrew & Foley Expires April 18, 2014 [Page 13] Internet-Draft AERO October 2013 3. the bitmask M is initialized to the all-zero value. 4.5. Decryption To decrypt an encrypted message (A, C), 1. The stateless decryption algorithm is applied to A and C, using the secret key K in the context, returning a candidate sequence number Z, which is a T-bit unsigned integer, and a plaintext Q, which is an octet string. 2. If PMIN * 8 > T, then padding is removed from Q as follows. B is set to the value of the last octet of Q, converted to an 8-bit unsigned integer. If B > (128 - T)/8, then the FAIL symbol is returned, and processing halts. Otherwise, the octet string P is set to all but the final B + 1 octets of Q. 3. Z is converted from an octet string to an unsigned integer using the S2I routine defined in Section 1.3. 4. Z is processed as follows; see Figure 3 for an illustration. 1. If Z is between 0 and S-W, inclusive, then Z is rejected. 2. If Z is between S-W+1 and S, inclusive, then the bitmask M is checked. If M[S-Z] = 0, then Z is accepted, M[S-Z] is set to 1, and P is returned as the plaintext. If M[S-Z] = 1, then Z is rejected. 3. If Z is between S+1 and S+W, inclusive, then Z is accepted, S is set to Z, and P is returned as the plaintext. The bitmask is shifted by Z-S (in the direction of higher indicies). 4. If Z is between S+W+1 and R, inclusive, then Z is rejected and R is set to Z. 5. If Z is between R+1 and R+V, inclusive, then Z is accepted, S is set to Z, the bitmask M is set to the all-zero value, and P is returned as the plaintext. 6. If Z is between R+V+1 and 2^T+1, inclusive, then Z is rejected and R is set to Z. 5. When Z is rejected, then AERO decryption MUST return the FAIL symbol, which indicates that either the message was a replay or a forgery attempt. McGrew & Foley Expires April 18, 2014 [Page 14] Internet-Draft AERO October 2013 A C +------|-------|--------------+ | v v | | +-------------+ | K ---->| stateless | | | | decryption | | | +-------------+ | | | | | | v v | | +-----+ +-----+ | | |strip| | S2I | | | +-----+ +-----+ | AERO | | | | decryption | v v | | P Z | | | | | v | | +-------------+ | | S-->| check |<--R | | ^ +-------------+ ^ | | | | | | | | +----------+ +----------+ | | | accept | | reject | | | +----------+ +----------+ | | | | | +--------|-----------|--------+ v v P (or) FAIL Figure 2: An illustration of the AERO decryption process. check reject reject bitmask and and | set R to Z set R to Z reject | accept | accept | | | | | | | v v v v v v +---------+----+----+----------------+---+----------------+-> Z | | | | | | | 0 S-W S S+W R R+V 2^T-1 Figure 3: An illustration of how the candidate sequence number Z is processed during AERO decryption. The possible values of Z are shown on a number line from 0 to 2^T-1. S and R are taken from the decryption context, the region into which Z falls determines how that value is processed. The acceptance region between R and R+V provides resynchronization as described in Section 6. McGrew & Foley Expires April 18, 2014 [Page 15] Internet-Draft AERO October 2013 5. Stateless encryption algorithms 5.1. Wide PRP (WPRP) An Pseudo-Random Permutation (PRP) is a keyed function that is both invertible and pseudorandom; that is, when the key is chosen at random, an attacker cannot distinguish it from an invertible function selected at random. For instance, a block cipher is a PRP with a fixed length (and narrow) input and output. An encryption algorithm that accepts plaintexts that have varying lengths can also be a PRP. This type of algorithm is called a Wide Pseudo-Random Permutation (WPRP), because the inputs can be wider than those of a typical block cipher. For our purposes, the WPRP must also accept an associated data input. For each distinct value of the associated data, the WPRP must realize a distinct pseudorandom function. Informally, for each distinct value of A, the WPRP "looks like" a distinct PRP. A WPRP is used as the underlying stateful encryption encryption method as follows. To encrypt an associated data A, a plaintext P, and a sequence number U with a secret key K, first U is appended to P, and the WPRP encryption is performed with the key K, the associated data A, and the plaintext Q = P || U resulting from the concatenation of P and U. The output of the WPRP encryption is returned as the ciphertext. This process is shown in Figure 4. A P U +------|-----|----|-----+ | | | | | | | v v | | | +--------+ | | | | append | | | | +--------+ | stateless | | | | encryption | | v | | | Q | | | | | | v v | | +-----------------+ | K ---->| WPRP encryption | | | +-----------------+ | | | | +-----------|-----------+ v C McGrew & Foley Expires April 18, 2014 [Page 16] Internet-Draft AERO October 2013 Figure 4: Using a WPRP as a stateless encryption method in AERO. To decrypt a ciphertext C with associated data A with a secret key K, first the WPRP decryption is applied to C, using the key K. Then the resulting output Q is split into two separate octet strings. The final T bits of the output is returned as U, and the initial len(Q) - T bits of Q are returned as P. This process is shown in Figure 5. A C +------|-------|--------+ | | | | | | | | | v v | | +-----------------+ | K ---->| WPRP decryption | | | +-----------------+ | | | | | v | | Q | stateless | | | decryption | v | | +-------+ | | | split | | | +-------+ | | | | | +-----------|-----|-----+ v v P U Figure 5: Using a WPRP as a stateless decryption method in AERO. A WPRP has the property that each bit of its output is a pseudorandom function of each bit of both of its inputs, for both encryption and decryption. A WPRP is very well suited for use in AERO. The fact that encryption is a WPRP, combined with the use of a sequence number, ensures strong confidentiality of the plaintext. The fact that the decryption algorithm is a WPRP ensures that an attacker cannot predict (much less control) the candidate sequence number, thus ensuring strong integrity, authenticity, and replay protection. WPRPs are used in disk-block encryption, because they provide the best security possible in scenarios where the ciphertext cannot be any longer than the plaintext. One such WPRP is the XCB mode of operation; below we define an AERO algorithm based on that standard Section 5.1.1. When a WPRP algorithm is used as the EAD algorithm in AERO, we call McGrew & Foley Expires April 18, 2014 [Page 17] Internet-Draft AERO October 2013 the resulting combination AERO-WPRP. An AERO-WPRP algorithm has very strong security properties, as described in Section 11. 5.1.1. AERO-AES-XCB The Advanced Encryption Standard (AES) eXtended Code Book (XCB) mode of operation, or AES-XCB [MF07], is a WPRP that was standardized in the IEEE [1619.2]. Below we define AERO-AES-128-XCB and AERO-AES- 256-XCB, which utilize that standard. Test cases are provided in Section 9. AES-XCB can encrypt only plaintexts that are at least PMIN = 16 bytes long, so padding MUST be used whenever the length T of the sequence number is less than 128 bits. AERO_AES_128_XCB uses AES with a 128 bit key in the XCB mode of operation as the underlying stateless encryption method in AERO. XCB is a WPRP, so the processing is performed as described in Section 5.1. AERO_AES_192_XCB uses AES with a 192 bit key in the XCB mode of operation as the underlying stateless encryption method, as described in Section 5.1. AERO_AES_256_XCB uses AES with a 256 bit key in the XCB mode of operation as the underlying stateless encryption method, as described in Section 5.1. 5.2. Other cryptographic techniques Using a Wide PRP in AERO provides very strong security. However, it is more computationally expensive than some other approaches. Thus, it may be useful to use other techniques that trade some well- understood reduction in security properties for lessened computational cost. We do not define any such techniques in this note, but we outline the tradeoffs that are possible. AEAD algorithms fit into two distinct categories: online and offline. With an online encryption algorithm, the ith ciphertext block can be output before the (i+1)st plaintext block has to be read (where a block is the size of the data blocks processed by a block cipher, typically) . These algorithms make a single pass over the data, and implementations need not buffer a significant amount of state. In contrast, with an offline encryption algorithm the entire plaintext must be read in before the first block of ciphertext can be output. Such algorithms must store state equal in length to the plaintext or ciphertext that they are processing. In a software environment, an offline algorithm is acceptable, as long it processes only plaintexts with lengths are short enough that they fit into high-speed random access memory. However, offline algorithms cannot be implemented in McGrew & Foley Expires April 18, 2014 [Page 18] Internet-Draft AERO October 2013 a hardware pipeline, such as those used in high-speed network encryption (for protocols such as 802.1AE). A WPRP is necessarily an offline algorithm. However, an online algorithm can implement a weakened variant of a WPRP: an Online Pseudo-Random Permutation (OPRP). An online permutation is a length- preserving permutation such that the ith block of output depends only on the first i blocks of input, for all values of i. An OPRP is an keyed online permutation that a computationally limited attacker cannot distinguish from an online permutation chosen uniformly at random from the set of all online permutations. With an OPRP, an attacker will be able to recognize when two messages with common plaintext prefixes are encrypted with the same key, since the ciphertext prefixes will be identical. There are OPRPs in the cryptographic literature that are suitable for use in AERO, such as the McOE-G [FFLW11] family of online authenticated encryption algorithms of Fleischmann, Forler, Lucks, and Wenzel. The design, selection, and standardization of such schemes would be valuable work, but it is beyond the scope of this note. There are offline ciphers that are more efficient that WPRPs, such as the Synthetic Initialization Vector (SIV) mode of operation of Rogaway and Shrimpton [RFC5297]. SIV encryption makes two passes over the plaintext, first to compute a Message Authentication Code (MAC) of that plaintext, the second to encrypt the plaintext using counter mode, using the MAC as the initialization vector for the encryption process. This two-pass encryption approach can be adapted for use in AERO, by having the IV computed by the tweakable encryption of the sequence number, using the MAC as the tweak. Such a mode of operation could be computationally less costly than a WPRP, but would also lack some of the misuse-resistance properties of a WPRP. McGrew & Foley Expires April 18, 2014 [Page 19] Internet-Draft AERO October 2013 6. Loss, reorder, and resynchronization AERO relies on the synchronization of the sequence number S between the sender (encryption algorithm) and the receiver (decryption algorithm). If those values differ by more than W, then we say that the sender and receiver are desynchronized; if this occurs, then it is likely that the decryption algorithm will discard at least one legitimate message that it receives. Desynchronization will occur whenever W+1 or more messages are lost by the communication channel between the sender and the receiver. When initializing an AERO decryption context, the reorder tolerance parameter W should be set to a value that is larger than the message reorder of the communication channel in use. However, values of W larger than 256 are discouraged for security reasons; see Section 11. The default value of W=64 is recommended when AERO ciphertext messages are carried over an unreliable transport protocol. When they are carried over a reliable transport protocol, W=1 is recommended. Resynchronization occurs automatically in AERO, because of the processing of candidate sequence numbers between R+1 and R+V. If a burst of exactly J messages that are lost, where J > W+1, then the receiver will reject the first message received immediately after the burst of lost messages, and will set R to the value of the current sequence number S of the sender. The candidate sequence number of the next message received will fall into the region between R+1 and R+V, since R=S and the candidate sequence number is S+1. Thus, after a burst of J > W lost packets, resynchronization is obtained after the spurious rejection of a single packet. Most applications can accept the induced loss of a single message in situations where J > W or more messages have been lost, since this corresponds to an increase in packet loss less than 2% when the recommended value of W=64 is used. However, an application MAY choose to cache a rejected message (A, C) and re-submit it to the AERO decryption algorithm if it appears to have been spuriously rejected during the resynchronization process, to eliminate the induced message loss. An application can do this without any need for special processing from an AERO implementation. When there are multiple receivers, it may be the case that one of the receivers is a "late joiner" that does not receive the initial messages sent in a session, because it joined that session some time after it began. The automatic resynchronization described above will enable a late joiner to synchronize with the sender after a single spurious rejection of a valid message. If an application protocol is designed to allow a late joiner in a session, it is likely that the McGrew & Foley Expires April 18, 2014 [Page 20] Internet-Draft AERO October 2013 application can tolerate this one spurious rejection as the cost of achieving synchronization without external coordination of state. The one free parameter in an AERO implementation is the number T of bits in the sequence number. This parameter determines the strength of the authentication provided, as well as the number of messages that can be encrypted by a particular sender using a particular key. Securty is the main consideration in the selection of this parameter; this topic is covered in Section 11.1.1. McGrew & Foley Expires April 18, 2014 [Page 21] Internet-Draft AERO October 2013 7. Usage and applicability AERO addresses several outstanding issues in cryptography as it is used for communication security. It is especially well suited for scenarios where there are bandwidth constrains or high costs associated with transmission and reception, as well as scenarios in which multiple senders or multiple receivers share an encryption key. It is also suitable for use when misuse resistance is desirable. AERO always detects replayed messages, as is expected of a replay protection service, but AERO may reject a message because it does not have all of the stored state that it needs in able to authoritatively determine that the message is not a replay. In this way, it matches the conventional practice of replay protection using sequence numbers. The sequence number output by the decryption algorithm can be used by the application calling AERO to put the decrypted plaintexts into their correct order. Some applications will not need this information, because they can rely on information in the associated data or plaintext to get information about the ordering of messages, or because they do not need to process the messages in order. When AERO ciphertext messages are carried above a reliable transport protocol such as TCP or SCCP, the reorder tolerance parameter W can be set to one and the resynchronization parameter V can be set to zero. This has the effect of improving the strength of the authentication that is provided. AERO-WPRP should be used, unless it is not possible to buffer the entire plaintext or ciphertext in memory during the encryption and decryption processes, in which case an AERO-OPRP would be more appropriate. Currently, there are no OPRP algorithms that can be implemented in an efficient pipeline, as is done with other AEAD algorithms such as AES-GCM, so this is an area of ongoing work. McGrew & Foley Expires April 18, 2014 [Page 22] Internet-Draft AERO October 2013 8. Rationale AES-XCB was chosen as it provides suitable security and performance, and it is a standard. In the future, stateless encryption algorithms with performance or security benefits over AES-XCB may be developed, but it is essential to specify a particular algorithm in this note, in order to gain experience in the implementation and use of AERO. It is unfortunate, but unavoidable, that the plaintext must be padded. It is unfortunate because of the slight additional overhead and implementation complexity. It is unavoidable because there is no efficient way to encrypt fewer than b bytes of plaintext using a block cipher with a b-byte block, in a way that meets the security needs of AERO. Also, there are not (yet) any dedicated encryption algorithms that are suitable. The padding and pad-stripping operations are included in the AERO encryption and decryption algorithms, respectively, because the pad- stripping operation also incorporates an authentication check. This arrangement simplifies the stateless encryption algorithm, and also ensures that more algorithms can be used as stateless encryption methods. Incorporating the sequence number generation inside of AERO has the advantage of putting that security-critical operation inside of the cryptographic module, which often benefits from higher assurance than other system components, including testing, as observed by Sections 5 and 6 of [IV-GEN]. McGrew & Foley Expires April 18, 2014 [Page 23] Internet-Draft AERO October 2013 9. Testing In the typical case in which the underlying stateless encryption algorithm is deterministic, both AERO encryption and AERO decryption are deterministic. This makes it possible to use test cases for all of the operations supported by an AERO algorithm. In this section we provide test cases for the AERO AES-XCB algorithm defined above. 9.1. AERO_AES_128_XCB Test Case 1 K: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f P: 01 02 03 04 05 06 A: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 U: 00 00 00 00 00 00 00 01 PS: 01 01 Q: 01 02 03 04 05 06 01 01 00 00 00 00 00 00 00 01 C: 23 e0 61 3f 18 07 d4 55 64 71 8d 72 9e fc 3d 46 Test Case 2 K: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f P: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 A: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 U: ff 00 00 00 0f 0e 0c 0b PS: 00 Q: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 00 ff 00 00 00 0f 0e 0c 0b C: e3 82 08 73 ff 55 20 6a 95 a5 83 2e a8 e4 c2 fd ee 96 ef b0 30 e1 fd cd 6f McGrew & Foley Expires April 18, 2014 [Page 24] Internet-Draft AERO October 2013 10. IANA Considerations The Internet Assigned Numbers Authority (IANA) has defined the AERO algorithm registry described below. An algorithm designer MAY register an algorithm in order to facilitate its use. Additions to the AERO algorithm registry require that a specification be documented in an Internet 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 "AERO_AES_128_XCB", that starts with the string "AERO", a positive number, and a reference to a specification that completely defines an AERO 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 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 will add the following entries to the AERO algorithm registry: +------------------+---------------+--------------------+ | Name | Reference | Numeric Identifier | +------------------+---------------+--------------------+ | AERO_AES_128_XCB | Section 5.1.1 | 1 | | | | | | AERO_AES_192_XCB | Section 5.1.1 | 2 | | | | | | AERO_AES_256_XCB | Section 5.1.1 | 3 | +------------------+---------------+--------------------+ An IANA registration of an AERO algorithm does not constitute an endorsement of that algorithm or its security. McGrew & Foley Expires April 18, 2014 [Page 25] Internet-Draft AERO October 2013 11. Security considerations There are three AERO security services: confidentiality, message authentication, and replay protection. We consider those services in that order. We use a simplistic but realistic model in which pseudorandom values are treated as random values. A more precise analysis would define the advantage that an adversary has in distinguishing the pseudorandom output of the stateless encryption algorithm from a truly random value, then quantify an attacker's advantage at forging AERO messages or distinguishing the output of the decryption algorithm from random, and then show that the attacker's advantage against AERO is negligibly small as long as the advantage against the stateless encryption algorithm is negligibly small. However, such a detailed analysis is beyond the scope of this note. AERO is secure in the following model, which captures the idea of a very strong adversary. The attacker is assumed to be able to adaptively choose plaintext messages (A, P) and ciphertext messages (A, C), and obtain the corresponding ciphertext and plaintext messages. The attacker is assumed to have limited computational resources. AERO is a stateful authenticated encryption method. Bellare, Kohno, and Namprempre have studied the security of stateful encrption and decryption in the context of the Secure Shell (SSH) protocol [BKN04]. 11.1. Authentication and confidentiality The confidentiality properties of AERO follow directly from that of the stateless encryption algorithm that it incorporates. When a WPRP is used, each WPRP plaintext will be distinct, because of the uniqueness of the sequence numbers. This fact ensures the indistinguishability of AERO encryption from a random function, and thus the strength of the confidentiality that it provides. AERO decryption can detect forgery attempts in two ways: the processing of the candidate sequence number, and the strip function that removes padding from the plaintext. The candidate sequence number is a pseudorandom function of both the AERO ciphertext and the AERO associated data, as is the post-decryption padding string PS. To an attacker that cannot distinguish the pseudorandom value from a random one, the probability p that a forgery attempt will not be detected by the candidate sequence number processing is McGrew & Foley Expires April 18, 2014 [Page 26] Internet-Draft AERO October 2013 (2*W + V) p = ------------. 2^T To an attacker that cannot distinguish the post-decryption value of PS from a random string, the probability ps that a forgery attempt will pass through the "strip" function undetected is (PMIN - T/8) ps = -------------. 256 Thus, the probability that a forgery attempt will go undetected is 1/2^T', where T' = T + 8 - lg((2*W + V) - lg(PMIN - T/8)) and lg(X) denotes the logarithm base two of X. As revealed by the equation above, AERO provides integrity and authentication protection that is essentially equivalent to an ideal message authentication code with a tag length of T' which is slightly less than T. The following table shows T' as a function of T, using the default values of W=64 and V=8 with PMIN=16, to three significant figures. The third column shows the number of bits in the data "on the wire" required by AERO. The final column shows the delta between the number of bits on the wire and the equivalent tag size T'. McGrew & Foley Expires April 18, 2014 [Page 27] Internet-Draft AERO October 2013 +-----+------+-----------+-------+ | T | T' | Data size | Delta | +-----+------+-----------+-------+ | 128 | 121 | 128 | 7.0 | | | | | | | 120 | 121 | 128 | 7.0 | | | | | | | 112 | 112 | 120 | 8.0 | | | | | | | 104 | 103 | 112 | 9.0 | | | | | | | 96 | 94.9 | 104 | 9.1 | | | | | | | 88 | 86.6 | 96 | 9.4 | | | | | | | 72 | 70.1 | 80 | 9.9 | | | | | | | 64 | 61.9 | 72 | 10.1 | | | | | | | 56 | 53.7 | 64 | 10.3 | | | | | | | 48 | 45.6 | 56 | 10.4 | | | | | | | 40 | 37.5 | 48 | 10.5 | | | | | | | 32 | 29.3 | 40 | 10.7 | | | | | | | 28 | 25.3 | 32 | 6.7 | +-----+------+-----------+-------+ The delta values can be considered to be the data overhead inherent in AERO, that is, the amount of additional data that must be included in a message in order to provide the replay protection, sequencing information, and self-synchronization capability. For higher authentication strengths, this overhead is roughly one byte; otherwise, it is slightly higher. When AERO is used over a reliable transport protocol, then the reorder tolerance parameter W SHOULD be set to one, and the resynchronization parameter V SHOULD be set to zero. When this is done, the delta values are about 7 bits smaller, and for a given amount of data overhead, the probability of a successful forgery is smaller by a factor of about 1/128. 11.1.1. Authentication strength As always, stronger authentication, and thus larger values of T', should be preferred over weaker authentication, and smaller values McGrew & Foley Expires April 18, 2014 [Page 28] Internet-Draft AERO October 2013 of T'. We recommend the use of T' = 121 (with 128 bits on the wire) whenever possible. When bandwidth is at a premium, it may be acceptable to use T' = 53.7 (64 bits on the wire). When the plaintext is audio or video data to be converted to an analog signal and played out of an audio speaker or video monitor, it may be acceptable to use even weaker authentication, whenever the consequences of a single forgery are limited to a localized "glitch" in the audio or video output. In such cases, an authentication strength of T' = 25.3 (32 bits on the wire) may be acceptable, but users are cautioned to verify these criteria before using such weak authentication. With these parameters, the likelihood of a successful forgery is one in 32 million. 11.2. Length hiding In some applications, it is desirable to hide the length of the plaintext from an attacker, in order to prevent the attacker from being able to make inferences about the plaintext based on those lengths. The plaintext padding scheme defined in this note is not suitable for this purpose and it MUST NOT be used as such. An application that seeks to hide plaintext lengths should instead process the plaintexts with a fragmentation and encoding scheme prior to encrypting them. Schemes of this sort are out of scope of this note. 11.3. Denial of Service (DoS) An attacker can potentially flood a communications channel with a set of bogus ciphertext messages in order to consume the computational resources of the receiver. In this section we review the vulnerability of AERO to this type of attack. AERO synchronization is robust even in the face of a DoS attack. An AERO sender and receiver will stay in synchronization unless either 1) the attacker succeeds in forging a message, or 2) a burst of at least B messages have been lost. The forgery likelihood is determined by the parameters T, V, and W, and it can be set high enough that the attacker's chance of success is negligible. A DoS attack may cause bursts of lost messages, by causing congestion on communication links. But AERO recovers quickly once that loss is over. AERO requires that all of the cryptographic processing be done during the decryption algorithm in order to detect a forgery attempt. This is in contrast to other authenticated encryption algorithms (e.g. GCM) that can avoid doing decryption processing, since the authentication check can be completed before the encryption starts. McGrew & Foley Expires April 18, 2014 [Page 29] Internet-Draft AERO October 2013 When AERO is in use on a communication environment where the data rate of the communications greatly exceeds that of AERO decryption, it may be beneficial to use additional mechanisms that allow the receiver to reject bogus messages. This could include having a fixed, unpredictable value in each message in order to foil off-path DoS attacks. To defend against on-path attackers, cryptographic techniques can be used. These techniques are beyond the scope of this document. 11.4. Multiple senders Section 3.5 describes the sender uniqueness requirement: a set of senders sharing the same key are recommended to ensure that their associated data inputs to the encryption algorithm will be distinct, for instance by including information in the associated data that uniquely identifies each sender. If the senders do not meet this requirement, then the security will degrade somewhat. The details of this degradation depend on the details of the underlying encryption method. When a WPRP is used in AERO and the sender uniqueness requirement is not met, an attacker can recognize when the same exact plaintext message (A, P) is encrypted by different senders with the same sequence number. Symbolically, if sender S1 and sender S2 both use the same associated data value A and plaintext value P in the ith message in sequence that they are each independently encrypting, then the resulting ciphertexts will be identical, and an attacker can infer that the plaintexts are matching. In many real-world scenarios, it is highly unlikely that distinct senders will each encrypt the same plaintext value for the same sequence number, and thus the security degradation will be tolerable. If, however, the plaintexts are either very short (such as eight or fewer octets) or very repetitive (there are only a million possible plaintexts, for instance), then the loss of confidentiality may be unacceptably high. When the sender uniqueness requirement is not met, the receiver will be processing messages from two or more senders, while believing it to be from a single sender. The decryption algorithm will synchronize with the highest sequence number of any sender, and reject the messages from other senders, if the highest sequence number is at least W greater than all other sequence numbers. If the sequence numbers of the senders are close, then the receiver will interleave messages from different senders. In the latter case, an attacker could potentially manipulate what the post-decryption plaintext looks like by selectively withholding messages from particular senders. Note that this property is not particular to AERO; it holds for any authenticated encryption scheme in which multiple entities are sharing the encryption key, and the receiver McGrew & Foley Expires April 18, 2014 [Page 30] Internet-Draft AERO October 2013 has no way of determining which entity encrypted a particular ciphertext message. These security properties compare very favorably with those of conventional authenticated encryption schemes. When the sender uniqueness requirement is not met with a nonce-based encryption scheme such as counter mode, CCM, GCM, Salsa or ChaCha, then essentially all of the confidentiality guarantees are lost. For nonce-based authentication schemes such as GCM, GMAC, and UMAC, all of the authentication guarantees are lost. 11.5. Sequence number management failure An AERO implementation might accidentally mismanage sequence numbers, due to faulty logic in the implementation, or due to external factors such as the cloning of the state of the virtual machine on which the implementation is running. If this happens, security will degrade. In order to ensure that the degradation is not catastrophic, the underlying stateless encryption algorithm should be robust against nonce misuse, in the sense of [RFC5297]. McGrew & Foley Expires April 18, 2014 [Page 31] Internet-Draft AERO October 2013 12. Acknowledgements The authors thank Dan Wing, Stefan Lucks, and Brian Weis for feedback and discussions, and Richard Barnes, Kenny Paterson, and Robert Moskowitz for suggestions and corrections. McGrew & Foley Expires April 18, 2014 [Page 32] Internet-Draft AERO October 2013 13. References 13.1. Normative references [1619.2] "IEEE 1619.2-2010: Standard for Wide-Block Encryption for Shared Storage Media", IEEE Computer Society https:// standards.ieee.org/findstds/standard/1619.2-2010.html, 2010. [FIPS197] "FIPS 197: Advanced Encryption Standard (AES)", Federal Information Processing Standard (FIPS) http://www.itl.nist.gov/fipspubs/fip197.htm. [MF07] McGrew, D. and S. Fluhrer, "The Security of the Extended Codebook (XCB) Mode of Operation", 14th Workshop on Selected Areas in Cryptography (SAC 2007) http://eprint.iacr.org/2007/298, August 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008. 13.2. Informative references [BKN04] Bellare, Kohno, and Namprempre, "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, 7(2), May 2004. http://homes.cs.washington.edu/~yoshi/papers/SSH/. [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 http:// www-cse.ucsd.edu/users/mihir/papers/oem.html. [CCM] Dworkin, "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/SP800-38C.pdf. [FFLW11] Fleischmann, Forler, Lucks, and Wenzel, "McOE: a family of McGrew & Foley Expires April 18, 2014 [Page 33] Internet-Draft AERO October 2013 almost foolproof on-line authenticated encryption schemes", Proceedings of the 19th international conference on Fast Software Encryption (FSE 2011) . [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. [IV-GEN] McGrew, D., "Generation of Deterministic Initialization Vectors (IVs) and Nonces", IETF Internet Draft http://www.ietf.org/id/draft-mcgrew-iv-gen-03.txt, October 2013. [R02] Rogaway, P., "Authenticated encryption with Associated- Data", Proceedings of the 2002 ACM Conference on Computer and Communication Security (CCS'02), pp. 98-107, ACM Press, 2002. http://www.cs.ucdavis.edu/~rogaway/papers/ad.pdf. [RFC4418] Krovetz, T., "UMAC: Message Authentication Code using Universal Hashing", RFC 4418, March 2006. [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity Transform Carrying Roll-Over Counter for the Secure Real- time Transport Protocol (SRTP)", RFC 4771, January 2007. [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)", RFC 5297, October 2008. [SP800-38] Dworkin, M., "NIST Special Publication 800-38: Recommendation for Block Cipher Modes of Operation", U.S. National Institue of Standards and Technology http:// csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. McGrew & Foley Expires April 18, 2014 [Page 34] Internet-Draft AERO October 2013 Authors' Addresses David McGrew Cisco Systems 13600 Dulles Technology Drive Herndon, VA 20171 US Email: mcgrew@cisco.com URI: http://www.mindspring.com/~dmcgrew/dam.htm John Foley Cisco Systems 7025-2 Kit Creek Road Research Triangle Park, NC 14987 US Email: foleyj@cisco.com McGrew & Foley Expires April 18, 2014 [Page 35]