doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc3686.txt b/doc/rfc/rfc3686.txt
new file mode 100644
index 0000000..c9e444d
--- /dev/null
+++ b/doc/rfc/rfc3686.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                         R. Housley
+Request for Comments: 3686                                Vigil Security
+Category: Standards Track                                   January 2004
+
+
+         Using Advanced Encryption Standard (AES) Counter Mode
+            With IPsec Encapsulating Security Payload (ESP)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document describes the use of Advanced Encryption Standard (AES)
+   Counter Mode, with an explicit initialization vector, as an IPsec
+   Encapsulating Security Payload (ESP) confidentiality mechanism.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.1.  Conventions Used In This Document. . . . . . . . . . . .  2
+   2.  AES Block Cipher . . . . . . . . . . . . . . . . . . . . . . .  2
+       2.1.  Counter Mode . . . . . . . . . . . . . . . . . . . . . .  2
+       2.2.  Key Size and Rounds. . . . . . . . . . . . . . . . . . .  5
+       2.3.  Block Size . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  ESP Payload. . . . . . . . . . . . . . . . . . . . . . . . . .  5
+       3.1.  Initialization Vector. . . . . . . . . . . . . . . . . .  6
+       3.2.  Encrypted Payload. . . . . . . . . . . . . . . . . . . .  6
+       3.3.  Authentication Data. . . . . . . . . . . . . . . . . . .  6
+   4.  Counter Block Format . . . . . . . . . . . . . . . . . . . . .  7
+   5.  IKE Conventions. . . . . . . . . . . . . . . . . . . . . . . .  8
+       5.1.  Keying Material and Nonces . . . . . . . . . . . . . . .  8
+       5.2.  Phase 1 Identifier . . . . . . . . . . . . . . . . . . .  9
+       5.3.  Phase 2 Identifier . . . . . . . . . . . . . . . . . . .  9
+       5.4.  Key Length Attribute . . . . . . . . . . . . . . . . . .  9
+   6.  Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 12
+   8.  Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 14
+   9.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
+
+
+
+Housley                     Standards Track                     [Page 1]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   10. Intellectual Property Statement. . . . . . . . . . . . . . . . 16
+   11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+       12.1. Normative References . . . . . . . . . . . . . . . . . . 17
+       12.2. Informative References . . . . . . . . . . . . . . . . . 17
+   13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
+   14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19
+
+1.  Introduction
+
+   The National Institute of Standards and Technology (NIST) recently
+   selected the Advanced Encryption Standard (AES) [AES], also known as
+   Rijndael.  The AES is a block cipher, and it can be used in many
+   different modes.  This document describes the use of AES Counter Mode
+   (AES-CTR), with an explicit initialization vector (IV), as an IPsec
+   Encapsulating Security Payload (ESP) [ESP] confidentiality mechanism.
+
+   This document does not provide an overview of IPsec.  However,
+   information about how the various components of IPsec and the way in
+   which they collectively provide security services is available in
+   [ARCH] and [ROADMAP].
+
+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 [STDWORDS].
+
+2.  AES Block Cipher
+
+   This section contains a brief description of the relevant
+   characteristics of the AES block cipher.  Implementation requirements
+   are also discussed.
+
+2.1.  Counter Mode
+
+   NIST has defined five modes of operation for AES and other FIPS-
+   approved block ciphers [MODES].  Each of these modes has different
+   characteristics.  The five modes are: ECB (Electronic Code Book), CBC
+   (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output
+   FeedBack), and CTR (Counter).
+
+   Only AES Counter mode (AES-CTR) is discussed in this specification.
+   AES-CTR requires the encryptor to generate a unique per-packet value,
+   and communicate this value to the decryptor.  This specification
+   calls this per-packet value an initialization vector (IV).  The same
+   IV and key combination MUST NOT be used more than once.  The
+
+
+
+
+Housley                     Standards Track                     [Page 2]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   encryptor can generate the IV in any manner that ensures uniqueness.
+   Common approaches to IV generation include incrementing a counter for
+   each packet and linear feedback shift registers (LFSRs).
+
+   This specification calls for the use of a nonce for additional
+   protection against precomputation attacks.  The nonce value need not
+   be secret.  However, the nonce MUST be unpredictable prior to the
+   establishment of the IPsec security association that is making use of
+   AES-CTR.
+
+   AES-CTR has many properties that make it an attractive encryption
+   algorithm for in high-speed networking.  AES-CTR uses the AES block
+   cipher to create a stream cipher.  Data is encrypted and decrypted by
+   XORing with the key stream produced by AES encrypting sequential
+   counter block values.  AES-CTR is easy to implement, and AES-CTR can
+   be pipelined and parallelized.  AES-CTR also supports key stream
+   precomputation.
+
+   Pipelining is possible because AES has multiple rounds (see section
+   2.2).  A hardware implementation (and some software implementations)
+   can create a pipeline by unwinding the loop implied by this round
+   structure.  For example, after a 16-octet block has been input, one
+   round later another 16-octet block can be input, and so on.  In AES-
+   CTR, these inputs are the sequential counter block values used to
+   generate the key stream.
+
+   Multiple independent AES encrypt implementations can also be used to
+   improve performance.  For example, one could use two AES encrypt
+   implementations in parallel, to process a sequence of counter block
+   values, doubling the effective throughput.
+
+   The sender can precompute the key stream.  Since the key stream does
+   not depend on any data in the packet, the key stream can be
+   precomputed once the nonce and IV are assigned.  This precomputation
+   can reduce packet latency.  The receiver cannot perform similar
+   precomputation because the IV will not be known before the packet
+   arrives.
+
+   AES-CTR uses the only AES encrypt operation (for both encryption and
+   decryption), making AES-CTR implementations smaller than
+   implementations of many other AES modes.
+
+   When used correctly, AES-CTR provides a high level of
+   confidentiality.  Unfortunately, AES-CTR is easy to use incorrectly.
+   Being a stream cipher, any reuse of the per-packet value, called the
+   IV, with the same nonce and key is catastrophic.  An IV collision
+   immediately leaks information about the plaintext in both packets.
+   For this reason, it is inappropriate to use this mode of operation
+
+
+
+Housley                     Standards Track                     [Page 3]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   with static keys.  Extraordinary measures would be needed to prevent
+   reuse of an IV value with the static key across power cycles.  To be
+   safe, implementations MUST use fresh keys with AES-CTR.  The Internet
+   Key Exchange (IKE) [IKE] protocol can be used to establish fresh
+   keys.  IKE can also provide the nonce value.
+
+   With AES-CTR, it is trivial to use a valid ciphertext to forge other
+   (valid to the decryptor) ciphertexts.  Thus, it is equally
+   catastrophic to use AES-CTR without a companion authentication
+   function.  Implementations MUST use AES-CTR in conjunction with an
+   authentication function, such as HMAC-SHA-1-96 [HMAC-SHA].
+
+   To encrypt a payload with AES-CTR, the encryptor partitions the
+   plaintext, PT, into 128-bit blocks.  The final block need not be 128
+   bits; it can be less.
+
+      PT = PT[1] PT[2] ... PT[n]
+
+   Each PT block is XORed with a block of the key stream to generate the
+   ciphertext, CT.  The AES encryption of each counter block results in
+   128 bits of key stream.  The most significant 96 bits of the counter
+   block are set to the nonce value, which is 32 bits, followed by the
+   per-packet IV value, which is 64 bits.  The least significant 32 bits
+   of the counter block are initially set to one.  This counter value is
+   incremented by one to generate subsequent counter blocks, each
+   resulting in another 128 bits of key stream.  The encryption of n
+   plaintext blocks can be summarized as:
+
+      CTRBLK := NONCE || IV || ONE
+      FOR i := 1 to n-1 DO
+        CT[i] := PT[i] XOR AES(CTRBLK)
+        CTRBLK := CTRBLK + 1
+      END
+      CT[n] := PT[n] XOR TRUNC(AES(CTRBLK))
+
+   The AES() function performs AES encryption with the fresh key.
+
+   The TRUNC() function truncates the output of the AES encrypt
+   operation to the same length as the final plaintext block, returning
+   the most significant bits.
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 4]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   Decryption is similar.  The decryption of n ciphertext blocks can be
+   summarized as:
+
+      CTRBLK := NONCE || IV || ONE
+      FOR i := 1 to n-1 DO
+        PT[i] := CT[i] XOR AES(CTRBLK)
+        CTRBLK := CTRBLK + 1
+      END
+      PT[n] := CT[n] XOR TRUNC(AES(CTRBLK))
+
+2.2.  Key Size and Rounds
+
+   AES supports three key sizes: 128 bits, 192 bits, and 256 bits.  The
+   default key size is 128 bits, and all implementations MUST support
+   this key size.  Implementations MAY also support key sizes of 192
+   bits and 256 bits.
+
+   AES uses a different number of rounds for each of the defined key
+   sizes.  When a 128-bit key is used, implementations MUST use 10
+   rounds.  When a 192-bit key is used, implementations MUST use 12
+   rounds.  When a 256-bit key is used, implementations MUST use 14
+   rounds.
+
+2.3.  Block Size
+
+   The AES has a block size of 128 bits (16 octets).  As such, when
+   using AES-CTR, each AES encrypt operation generates 128 bits of key
+   stream.  AES-CTR encryption is the XOR of the key stream with the
+   plaintext.  AES-CTR decryption is the XOR of the key stream with the
+   ciphertext.  If the generated key stream is longer than the plaintext
+   or ciphertext, the extra key stream bits are simply discarded.  For
+   this reason, AES-CTR does not require the plaintext to be padded to a
+   multiple of the block size.  However, to provide limited traffic flow
+   confidentiality, padding MAY be included, as specified in [ESP].
+
+3.  ESP Payload
+
+   The ESP payload is comprised of the IV followed by the ciphertext.
+   The payload field, as defined in [ESP], is structured as shown in
+   Figure 1.
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 5]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Initialization Vector                     |
+   |                            (8 octets)                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                  Encrypted Payload (variable)                 ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   ~                 Authentication Data (variable)                ~
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 1.  ESP Payload Encrypted with AES-CTR
+
+3.1.  Initialization Vector
+
+   The AES-CTR IV field MUST be eight octets.  The IV MUST be chosen by
+   the encryptor in a manner that ensures that the same IV value is used
+   only once for a given key.  The encryptor can generate the IV in any
+   manner that ensures uniqueness.  Common approaches to IV generation
+   include incrementing a counter for each packet and linear feedback
+   shift registers (LFSRs).
+
+   Including the IV in each packet ensures that the decryptor can
+   generate the key stream needed for decryption, even when some packets
+   are lost or reordered.
+
+3.2.  Encrypted Payload
+
+   The encrypted payload contains the ciphertext.
+
+   AES-CTR mode does not require plaintext padding.  However, ESP does
+   require padding to 32-bit word-align the authentication data.  The
+   padding, Pad Length, and the Next Header MUST be concatenated with
+   the plaintext before performing encryption, as described in [ESP].
+
+3.3.  Authentication Data
+
+   Since it is trivial to construct a forgery AES-CTR ciphertext from a
+   valid AES-CTR ciphertext, AES-CTR implementations MUST employ a non-
+   NULL ESP authentication method.  HMAC-SHA-1-96 [HMAC-SHA] is a likely
+   choice.
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 6]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+4.  Counter Block Format
+
+   Each packet conveys the IV that is necessary to construct the
+   sequence of counter blocks used to generate the key stream necessary
+   to decrypt the payload.  The AES counter block cipher block is 128
+   bits.  Figure 2 shows the format of the counter block.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            Nonce                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Initialization Vector (IV)                   |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Block Counter                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 2.  Counter Block Format
+
+   The components of the counter block are as follows:
+
+   Nonce
+      The Nonce field is 32 bits.  As the name implies, the nonce is a
+      single use value.  That is, a fresh nonce value MUST be assigned
+      for each security association.  It MUST be assigned at the
+      beginning of the security association.  The nonce value need not
+      be secret, but it MUST be unpredictable prior to the beginning of
+      the security association.
+
+   Initialization Vector
+      The IV field is 64 bits.  As described in section 3.1, the IV MUST
+      be chosen by the encryptor in a manner that ensures that the same
+      IV value is used only once for a given key.
+
+   Block Counter
+      The block counter field is the least significant 32 bits of the
+      counter block.  The block counter begins with the value of one,
+      and it is incremented to generate subsequent portions of the key
+      stream.  The block counter is a 32-bit big-endian integer value.
+
+   Using the encryption process described in section 2.1, this
+   construction permits each packet to consist of up to:
+
+      (2^32)-1 blocks  =  4,294,967,295 blocks
+                       = 68,719,476,720 octets
+
+
+
+
+
+Housley                     Standards Track                     [Page 7]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   This construction can produce enough key stream for each packet
+   sufficient to handle any IPv6 jumbogram [JUMBO].
+
+5.  IKE Conventions
+
+   This section describes the conventions used to generate keying
+   material and nonces for use with AES-CTR using the Internet Key
+   Exchange (IKE) [IKE] protocol.  The identifiers and attributes needed
+   to negotiate a security association which uses AES-CTR are also
+   defined.
+
+5.1.  Keying Material and Nonces
+
+   As described in section 2.1, implementations MUST use fresh keys with
+   AES-CTR.  IKE can be used to establish fresh keys.  This section
+   describes the conventions for obtaining the unpredictable nonce value
+   from IKE.  Note that this convention provides a nonce value that is
+   secret as well as unpredictable.
+
+   IKE makes use of a pseudo-random function (PRF) to derive keying
+   material.  The PRF is used iteratively to derive keying material of
+   arbitrary size, called KEYMAT.  Keying material is extracted from the
+   output string without regard to boundaries.
+
+   The size of the requested KEYMAT MUST be four octets longer than is
+   needed for the associated AES key.  The keying material is used as
+   follows:
+
+   AES-CTR with a 128 bit key
+      The KEYMAT requested for each AES-CTR key is 20 octets.  The first
+      16 octets are the 128-bit AES key, and the remaining four octets
+      are used as the nonce value in the counter block.
+
+   AES-CTR with a 192 bit key
+      The KEYMAT requested for each AES-CTR key is 28 octets.  The first
+      24 octets are the 192-bit AES key, and the remaining four octets
+      are used as the nonce value in the counter block.
+
+   AES-CTR with a 256 bit key
+      The KEYMAT requested for each AES-CTR key is 36 octets.  The first
+      32 octets are the 256-bit AES key, and the remaining four octets
+      are used as the nonce value in the counter block.
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 8]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+5.2.  Phase 1 Identifier
+
+   This document does not specify the conventions for using AES-CTR for
+   IKE Phase 1 negotiations.  For AES-CTR to be used in this manner, a
+   separate specification is needed, and an Encryption Algorithm
+   Identifier needs to be assigned.
+
+5.3.  Phase 2 Identifier
+
+   For IKE Phase 2 negotiations, IANA has assigned an ESP Transform
+   Identifier of 13 for AES-CTR with an explicit IV.
+
+5.4.  Key Length Attribute
+
+   Since the AES supports three key lengths, the Key Length attribute
+   MUST be specified in the IKE Phase 2 exchange [DOI].  The Key Length
+   attribute MUST have a value of 128, 192, or 256.
+
+6.  Test Vectors
+
+   This section contains nine test vectors, which can be used to confirm
+   that an implementation has correctly implemented AES-CTR.  The first
+   three test vectors use AES with a 128 bit key; the next three test
+   vectors use AES with a 192 bit key; and the last three test vectors
+   use AES with a 256 bit key.
+
+   Test Vector #1: Encrypting 16 octets using AES-CTR with 128-bit key
+   AES Key          : AE 68 52 F8 12 10 67 CC 4B F7 A5 76 55 77 F3 9E
+   AES-CTR IV       : 00 00 00 00 00 00 00 00
+   Nonce            : 00 00 00 30
+   Plaintext String : 'Single block msg'
+   Plaintext        : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67
+   Counter Block (1): 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01
+   Key Stream    (1): B7 60 33 28 DB C2 93 1B 41 0E 16 C8 06 7E 62 DF
+   Ciphertext       : E4 09 5D 4F B7 A7 B3 79 2D 61 75 A3 26 13 11 B8
+
+   Test Vector #2: Encrypting 32 octets using AES-CTR with 128-bit key
+   AES Key          : 7E 24 06 78 17 FA E0 D7 43 D6 CE 1F 32 53 91 63
+   AES-CTR IV       : C0 54 3B 59 DA 48 D9 0B
+   Nonce            : 00 6C B6 DB
+   Plaintext        : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
+                    : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
+   Counter Block (1): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 01
+   Key Stream    (1): 51 05 A3 05 12 8F 74 DE 71 04 4B E5 82 D7 DD 87
+   Counter Block (2): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 02
+   Key Stream    (2): FB 3F 0C EF 52 CF 41 DF E4 FF 2A C4 8D 5C A0 37
+   Ciphertext       : 51 04 A1 06 16 8A 72 D9 79 0D 41 EE 8E DA D3 88
+                    : EB 2E 1E FC 46 DA 57 C8 FC E6 30 DF 91 41 BE 28
+
+
+
+Housley                     Standards Track                     [Page 9]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   Test Vector #3: Encrypting 36 octets using AES-CTR with 128-bit key
+   AES Key          : 76 91 BE 03 5E 50 20 A8 AC 6E 61 85 29 F9 A0 DC
+   AES-CTR IV       : 27 77 7F 3F  4A 17 86 F0
+   Nonce            : 00 E0 01 7B
+   Plaintext        : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
+                    : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
+                    : 20 21 22 23
+   Counter Block (1): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 01
+   Key Stream    (1): C1 CE 4A AB 9B 2A FB DE C7 4F 58 E2 E3 D6 7C D8
+   Counter Block (2): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 02
+   Key Stream    (2): 55 51 B6 38 CA 78 6E 21 CD 83 46 F1 B2 EE 0E 4C
+   Counter Block (3): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 03
+   Key Stream    (3): 05 93 25 0C 17 55 36 00 A6 3D FE CF 56 23 87 E9
+   Ciphertext       : C1 CF 48 A8 9F 2F FD D9 CF 46 52 E9 EF DB 72 D7
+                    : 45 40 A4 2B DE 6D 78 36 D5 9A 5C EA AE F3 10 53
+                    : 25 B2 07 2F
+
+   Test Vector #4: Encrypting 16 octets using AES-CTR with 192-bit key
+   AES Key          : 16 AF 5B 14 5F C9 F5 79 C1 75 F9 3E 3B FB 0E ED
+                    : 86 3D 06 CC FD B7 85 15
+   AES-CTR IV       : 36 73 3C 14 7D 6D 93 CB
+   Nonce            : 00 00 00 48
+   Plaintext String : 'Single block msg'
+   Plaintext        : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67
+   Counter Block (1): 00 00 00 48 36 73 3C 14 7D 6D 93 CB 00 00 00 01
+   Key Stream    (1): 18 3C 56 28 8E 3C E9 AA 22 16 56 CB 23 A6 9A 4F
+   Ciphertext       : 4B 55 38 4F E2 59 C9 C8 4E 79 35 A0 03 CB E9 28
+
+   Test Vector #5: Encrypting 32 octets using AES-CTR with 192-bit key
+   AES Key          : 7C 5C B2 40 1B 3D C3 3C 19 E7 34 08 19 E0 F6 9C
+                    : 67 8C 3D B8 E6 F6 A9 1A
+   AES-CTR IV       : 02 0C 6E AD C2 CB 50 0D
+   Nonce            : 00 96 B0 3B
+   Plaintext        : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
+                    : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
+   Counter Block (1): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 01
+   Key Stream    (1): 45 33 41 FF 64 9E 25 35 76 D6 A0 F1 7D 3C C3 90
+   Counter Block (2): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 02
+   Key Stream    (2): 94 81 62 0F 4E C1 B1 8B E4 06 FA E4 5E E9 E5 1F
+   Ciphertext       : 45 32 43 FC 60 9B 23 32 7E DF AA FA 71 31 CD 9F
+                    : 84 90 70 1C 5A D4 A7 9C FC 1F E0 FF 42 F4 FB 00
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 10]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   Test Vector #6: Encrypting 36 octets using AES-CTR with 192-bit key
+   AES Key          : 02 BF 39 1E E8 EC B1 59 B9 59 61 7B 09 65 27 9B
+                    : F5 9B 60 A7 86 D3 E0 FE
+   AES-CTR IV       : 5C BD 60 27 8D CC 09 12
+   Nonce            : 00 07 BD FD
+   Plaintext        : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
+                    : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
+                    : 20 21 22 23
+   Counter Block (1): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 01
+   Key Stream    (1): 96 88 3D C6 5A 59 74 28 5C 02 77 DA D1 FA E9 57
+   Counter Block (2): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 02
+   Key Stream    (2): C2 99 AE 86 D2 84 73 9F 5D 2F D2 0A 7A 32 3F 97
+   Counter Block (3): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 03
+   Key Stream    (3): 8B CF 2B 16 39 99 B2 26 15 B4 9C D4 FE 57 39 98
+   Ciphertext       : 96 89 3F C5 5E 5C 72 2F 54 0B 7D D1 DD F7 E7 58
+                    : D2 88 BC 95 C6 91 65 88 45 36 C8 11 66 2F 21 88
+                    : AB EE 09 35
+
+   Test Vector #7: Encrypting 16 octets using AES-CTR with 256-bit key
+   AES Key          : 77 6B EF F2 85 1D B0 6F 4C 8A 05 42 C8 69 6F 6C
+                    : 6A 81 AF 1E EC 96 B4 D3 7F C1 D6 89 E6 C1 C1 04
+   AES-CTR IV       : DB 56 72 C9 7A A8 F0 B2
+   Nonce            : 00 00 00 60
+   Plaintext String : 'Single block msg'
+   Plaintext        : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67
+   Counter Block (1): 00 00 00 60 DB 56 72 C9 7A A8 F0 B2 00 00 00 01
+   Key Stream    (1): 47 33 BE 7A D3 E7 6E A5 3A 67 00 B7 51 8E 93 A7
+   Ciphertext       : 14 5A D0 1D BF 82 4E C7 56 08 63 DC 71 E3 E0 C0
+
+   Test Vector #8: Encrypting 32 octets using AES-CTR with 256-bit key
+   AES Key          : F6 D6 6D 6B D5 2D 59 BB 07 96 36 58 79 EF F8 86
+                    : C6 6D D5 1A 5B 6A 99 74 4B 50 59 0C 87 A2 38 84
+   AES-CTR IV       : C1 58 5E F1 5A 43 D8 75
+   Nonce            : 00 FA AC 24
+   Plaintext        : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
+                    : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
+   Counter block (1): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 01
+   Key stream    (1): F0 5F 21 18 3C 91 67 2B 41 E7 0A 00 8C 43 BC A6
+   Counter block (2): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 02
+   Key stream    (2): A8 21 79 43 9B 96 8B 7D 4D 29 99 06 8F 59 B1 03
+   Ciphertext       : F0 5E 23 1B 38 94 61 2C 49 EE 00 0B 80 4E B2 A9
+                    : B8 30 6B 50 8F 83 9D 6A 55 30 83 1D 93 44 AF 1C
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 11]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   Test Vector #9: Encrypting 36 octets using AES-CTR with 256-bit key
+   AES Key          : FF 7A 61 7C E6 91 48 E4 F1 72 6E 2F 43 58 1D E2
+                    : AA 62 D9 F8 05 53 2E DF F1 EE D6 87 FB 54 15 3D
+   AES-CTR IV       : 51 A5 1D 70 A1 C1 11 48
+   Nonce            : 00 1C C5 B7
+   Plaintext        : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
+                    : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
+                    : 20 21 22 23
+   Counter block (1): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 01
+   Key stream    (1): EB 6D 50 81 19 0E BD F0 C6 7C 9E 4D 26 C7 41 A5
+   Counter block (2): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 02
+   Key stream    (2): A4 16 CD 95 71 7C EB 10 EC 95 DA AE 9F CB 19 00
+   Counter block (3): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 03
+   Key stream    (3): 3E E1 C4 9B C6 B9 CA 21 3F 6E E2 71 D0 A9 33 39
+   Ciphertext       : EB 6C 52 82 1D 0B BB F7 CE 75 94 46 2A CA 4F AA
+                    : B4 07 DF 86 65 69 FD 07 F4 8C C0 B5 83 D6 07 1F
+                    : 1E C0 E6 B8
+
+7.  Security Considerations
+
+   When used properly, AES-CTR mode provides strong confidentiality.
+   Bellare, Desai, Jokipii, Rogaway show in [BDJR] that the privacy
+   guarantees provided by counter mode are at least as strong as those
+   for CBC mode when using the same block cipher.
+
+   Unfortunately, it is very easy to misuse this counter mode.  If
+   counter block values are ever used for more that one packet with the
+   same key, then the same key stream will be used to encrypt both
+   packets, and the confidentiality guarantees are voided.
+
+   What happens if the encryptor XORs the same key stream with two
+   different plaintexts?  Suppose two plaintext byte sequences P1, P2,
+   P3 and Q1, Q2, Q3 are both encrypted with key stream K1, K2, K3.  The
+   two corresponding ciphertexts are:
+
+      (P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
+
+      (Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3)
+
+   If both of these two ciphertext streams are exposed to an attacker,
+   then a catastrophic failure of confidentiality results, since:
+
+      (P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1
+      (P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2
+      (P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 12]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   Once the attacker obtains the two plaintexts XORed together, it is
+   relatively straightforward to separate them.  Thus, using any stream
+   cipher, including AES-CTR, to encrypt two plaintexts under the same
+   key stream leaks the plaintext.
+
+   Therefore, stream ciphers, including AES-CTR, should not be used with
+   static keys.  It is inappropriate to use AES-CTR with static keys.
+   Extraordinary measures would be needed to prevent reuse of a counter
+   block value with the static key across power cycles.  To be safe, ESP
+   implementations MUST use fresh keys with AES-CTR.  The Internet Key
+   Exchange (IKE) protocol [IKE] can be used to establish fresh keys.
+   IKE can also be used to establish the nonce at the beginning of the
+   security association.
+
+   When IKE is used to establish fresh keys between two peer entities,
+   separate keys are established for the two traffic flows.  When a
+   mechanism other than IKE is used to establish fresh keys, and that
+   mechanism establishes only a single key to encrypt packets, then
+   there is a high probability that the peers will select the same IV
+   values for some packets.  Thus, to avoid counter block collisions,
+
+   ESP implementations that permit use of the same key for encrypting
+   outbound traffic and decrypting incoming traffic with the same peer
+   MUST ensure that the two peers assign different Nonce values to the
+   security association.
+
+   Data forgery is trivial with CTR mode.  The demonstration of this
+   attack is similar to the key stream reuse discussion above.  If a
+   known plaintext byte sequence P1, P2, P3 is encrypted with key stream
+   K1, K2, K3, then the attacker can replace the plaintext with one of
+   his own choosing.  The ciphertext is:
+
+      (P1 XOR K1), (P2 XOR K2), (P3 XOR K3)
+
+   The attacker simply XORs a selected sequence Q1, Q2, Q3 with the
+   ciphertext to obtain:
+
+      (Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3))
+
+   Which is the same as:
+
+      ((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3)
+
+   Decryption of the attacker-generated ciphertext will yield exactly
+   what the attacker intended:
+
+      (Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3)
+
+
+
+
+Housley                     Standards Track                    [Page 13]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   Accordingly, ESP implementations MUST use of AES-CTR in conjunction
+   with ESP authentication.
+
+   Additionally, since AES has a 128-bit block size, regardless of the
+   mode employed, the ciphertext generated by AES encryption becomes
+   distinguishable from random values after 2^64 blocks are encrypted
+   with a single key.  Since ESP with Enhanced Sequence Numbers allows
+   for up to 2^64 packets in a single security association, there is
+   real potential for more than 2^64 blocks to be encrypted with one
+   key.  Therefore, implementations SHOULD generate a fresh key before
+   2^64 blocks are encrypted with the same key.  Note that ESP with 32-
+   bit Sequence Numbers will not exceed 2^64 blocks even if all of the
+   packets are maximum-length IPv6 jumbograms [JUMBO].
+
+   There are fairly generic precomputation attacks against all block
+   cipher modes that allow a meet-in-the-middle attack against the key.
+   These attacks require the creation and searching of huge tables of
+   ciphertext associated with known plaintext and known keys.  Assuming
+   that the memory and processor resources are available for a
+   precomputation attack, then the theoretical strength of AES-CTR (and
+   any other block cipher mode) is limited to 2^(n/2) bits, where n is
+   the number of bits in the key.  The use of long keys is the best
+   countermeasure to precomputation attacks.  Therefore, implementations
+   that employ 128-bit AES keys should take precautions to make the
+   precomputation attacks more difficult.  The unpredictable nonce value
+   in the counter block significantly increases the size of the table
+   that the attacker must compute to mount a successful attack.
+
+8.  Design Rationale
+
+   In the development of this specification, the use of the ESP sequence
+   number field instead of an explicit IV field was considered.  This
+   selection is not a cryptographic security issue, as either approach
+   will prevent counter block collisions.
+
+   In a very conservative model of encryption security, at most 2^64
+   blocks ought to be encrypted with AES-CTR under a single key.  Under
+   this constraint, no more than 64 bits are needed to identify each
+   packet within a security association.  Since the ESP extended
+   sequence number is 64 bits, it is an obvious candidate for use as an
+   implicit IV.  This would dictate a single method for the assignment
+   of per-packet value in the counter block.  The use of an explicit IV
+   does not dictate such a method, which is desirable for several
+   reasons.
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 14]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   1. Only the encryptor can ensure that the value is not used for more
+      than one packet, so there is no advantage to selecting a mechanism
+      that allows the decryptor to determine whether counter block
+      values collide.  Damage from the collision is done, whether the
+      decryptor detects it or not.
+
+   2. Allows adders, LFSRs, and any other technique that meets the time
+      budget of the encryptor, so long as the technique results in a
+      unique value for each packet.  Adders are simple and
+      straightforward to implement, but due to carries, they do not
+      execute in constant time.  LFSRs offer an alternative that
+      executes in constant time.
+
+   3. Complexity is in control of the implementer.  Further, the
+      decision made by the implementer of the encryptor does not make
+      the decryptor more (or less) complex.
+
+   4. When the encryptor has more than one cryptographic hardware
+      device, an IV prefix can be assigned to each device, ensuring that
+      collisions will not occur.  Yet, since the decryptor does not need
+      to examine IV structure, the decryptor is unaffected by the IV
+      structure selected by the encryptor.  One cannot make use of the
+      same technique with the ESP sequence numbers, because the
+      semantics for them require sequential value generation.
+
+   5.  Assurance boundaries are very important to implementations that
+      will be evaluated against the FIPS Pub 140-1 or FIPS Pub 140-2
+      [SECRQMTS].  The assignment of the per-packet counter block value
+      needs to be inside the assurance boundary.  Some implementations
+      assign the sequence number inside the assurance boundary, but
+      others do not.  A sequence number collision does not have the dire
+      consequences, but, as described in section 6, a collision in
+      counter block values has disastrous consequences.
+
+   6. Coupling with the sequence number is possible in those
+      architectures where the sequence number assignment is performed
+      within the assurance boundary.  In this situation, the sequence
+      number and the IV field will contain the same value.
+
+   7. Decoupling from the sequence number is possible in those
+      architectures where the sequence number assignment is performed
+      outside the assurance boundary.
+
+   The use of an explicit IV field directly follows from the decoupling
+   of the sequence number and the per-packet counter block value.  The
+   overhead associated with 64 bits for the IV field is acceptable.
+   This overhead is significantly less than the overhead associated with
+   Cipher Block Chaining (CBC) mode.  As normally employed, CBC requires
+
+
+
+Housley                     Standards Track                    [Page 15]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   a full block for the IV and, on average, half of a block for padding.
+   AES-CTR with an explicit IV has about one-third of the overhead as
+   AES-CBC, and the overhead is constant for each packet.
+
+   The inclusion of the nonce provides a weak countermeasure against
+   precomputation attacks.  For this countermeasure to be effective, the
+   attacker must not be able to predict the value of the nonce well in
+   advance of security association establishment.  The use of long keys
+   provides a strong countermeasure to precomputation attacks, and AES
+   offers key sizes that thwart these attacks for many decades to come.
+
+   A 28-bit block counter value is sufficient for the generation of a
+   key stream to encrypt the largest possible IPv6 jumbogram [JUMBO];
+   however, a 32-bit field is used.  This size is convenient for both
+   hardware and software implementations.
+
+9.  IANA Considerations
+
+   IANA has assigned 13 as the ESP transform number for AES-CTR with an
+   explicit IV.
+
+10.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+11.  Acknowledgements
+
+   This document is the result of extensive discussions and compromises.
+   While not all of the participants are completely satisfied with the
+   outcome, the document is better for their contributions.
+
+
+
+Housley                     Standards Track                    [Page 16]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   The author thanks the members of the IPsec working group for their
+   contributions to the design, with special mention of the efforts of
+   (in alphabetical order) Steve Bellovin, David Black, Niels Ferguson,
+   Charlie Kaufman, Steve Kent, Tero Kivinen, Paul Koning, David McGrew,
+   Robert Moskowitz, Jesse Walker, and Doug Whiting.
+
+   The author thanks and Alireza Hodjat, John Viega, and Doug Whiting
+   for assistance with the test vectors.
+
+12.  References
+
+   This section provides normative and informative references.
+
+12.1.  Normative References
+
+   [AES]       NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)",
+               November 2001.
+
+   [DOI]       Piper, D., "The Internet IP Security Domain of
+               Interpretation for ISAKMP", RFC 2407, November 1998.
+
+   [ESP]       Kent, S. and R. Atkinson, "IP Encapsulating Security
+               Payload (ESP)", RFC 2406, November 1998.
+
+   [MODES]     Dworkin, M., "Recommendation for Block Cipher Modes of
+               Operation: Methods and Techniques", NIST Special
+               Publication 800-38A, December 2001.
+
+   [STDWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+12.2.  Informative References
+
+   [ARCH]      Kent, S. and R. Atkinson, "Security Architecture for the
+               Internet Protocol", RFC 2401, November 1998.
+
+   [BDJR]      Bellare, M, Desai, A., Jokipii, E. and P. Rogaway, "A
+               Concrete Security Treatment of Symmetric Encryption:
+               Analysis of the DES Modes of Operation", Proceedings 38th
+               Annual Symposium on Foundations of Computer Science,
+               1997.
+
+   [HMAC-SHA]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
+               ESP and AH", RFC 2404, November 1998.
+
+   [IKE]       Harkins, D. and D. Carrel, "The Internet Key Exchange
+               (IKE)", RFC 2409, November 1998.
+
+
+
+
+Housley                     Standards Track                    [Page 17]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+   [JUMBO]     Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms",
+               RFC 2675, August 1999.
+
+   [ROADMAP]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
+               Document Roadmap", RFC 2411, November 1998.
+
+   [SECRQMTS]  National Institute of Standards and Technology.  FIPS Pub
+               140-1: Security Requirements for Cryptographic Modules.
+               11 January 1994.
+
+               National Institute of Standards and Technology.  FIPS Pub
+               140-2: Security Requirements for Cryptographic Modules.
+               25 May 2001. [Supercedes FIPS Pub 140-1]
+
+13.  Author's Address
+
+   Russell Housley
+   Vigil Security, LLC
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+
+   EMail: housley@vigilsec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 18]
+
+RFC 3686         Using AES Counter Mode With IPsec ESP      January 2004
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 19]
+