doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc4309.txt b/doc/rfc/rfc4309.txt
new file mode 100644
index 0000000..d7c84db
--- /dev/null
+++ b/doc/rfc/rfc4309.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                         R. Housley
+Request for Comments: 4309                                Vigil Security
+Category: Standards Track                                  December 2005
+
+
+           Using Advanced Encryption Standard (AES) CCM 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 (2005).
+
+Abstract
+
+   This document describes the use of Advanced Encryption Standard (AES)
+   in Counter with CBC-MAC (CCM) Mode, with an explicit initialization
+   vector (IV), as an IPsec Encapsulating Security Payload (ESP)
+   mechanism to provide confidentiality, data origin authentication, and
+   connectionless integrity.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................2
+   2. AES CCM Mode ....................................................2
+   3. ESP Payload .....................................................4
+      3.1. Initialization Vector (IV) .................................4
+      3.2. Encrypted Payload ..........................................4
+      3.3. Authentication Data ........................................5
+   4. Nonce Format ....................................................5
+   5. AAD Construction ................................................6
+   6. Packet Expansion ................................................7
+   7. IKE Conventions .................................................7
+      7.1. Keying Material and Salt Values ............................7
+      7.2. Phase 1 Identifier .........................................8
+      7.3. Phase 2 Identifier .........................................8
+      7.4. Key Length Attribute .......................................8
+   8. Test Vectors ....................................................8
+   9. Security Considerations .........................................8
+   10. Design Rationale ...............................................9
+
+
+
+Housley                     Standards Track                     [Page 1]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+   11. IANA Considerations ...........................................11
+   12. Acknowledgements ..............................................11
+   13. References ....................................................11
+      13.1. Normative References .....................................11
+      13.2. Informative References ...................................12
+
+1.  Introduction
+
+   The Advanced Encryption Standard (AES) [AES] is a block cipher, and
+   it can be used in many different modes.  This document describes the
+   use of AES in CCM (Counter with CBC-MAC) mode (AES CCM), with an
+   explicit initialization vector (IV), as an IPsec Encapsulating
+   Security Payload (ESP) [ESP] mechanism to provide confidentiality,
+   data origin authentication, and connectionless integrity.
+
+   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 [ROAD].
+
+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 CCM Mode
+
+   CCM is a generic authenticate-and-encrypt block cipher mode [CCM].
+   In this specification, CCM is used with the AES [AES] block cipher.
+
+   AES CCM has two parameters:
+
+      M  M indicates the size of the integrity check value (ICV).  CCM
+         defines values of 4, 6, 8, 10, 12, 14, and 16 octets; However,
+         to maintain alignment and provide adequate security, only the
+         values that are a multiple of four and are at least eight are
+         permitted.  Implementations MUST support M values of 8 octets
+         and 16 octets, and implementations MAY support an M value of 12
+         octets.
+
+      L  L indicates the size of the length field in octets.  CCM
+         defines values of L between 2 octets and 8 octets.  This
+         specification only supports L = 4.  Implementations MUST
+         support an L value of 4 octets, which accommodates a full
+         Jumbogram [JUMBO]; however, the length includes all of the
+         encrypted data, which also includes the ESP Padding, Pad
+         Length, and Next Header fields.
+
+
+
+Housley                     Standards Track                     [Page 2]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+   There are four inputs to CCM originator processing:
+
+      key
+         A single key is used to calculate the ICV using CBC-MAC and to
+         perform payload encryption using counter mode.  AES supports
+         key sizes of 128 bits, 192 bits, and 256 bits.  The default key
+
+         size is 128 bits, and implementations MUST support this key
+         size.  Implementations MAY also support key sizes of 192 bits
+         and 256 bits.
+
+      nonce
+         The size of the nonce depends on the value selected for the
+         parameter L.  It is 15-L octets.  Implementations MUST support
+         a nonce of 11 octets.  The construction of the nonce is
+         described in Section 4.
+
+      payload
+         The payload of the ESP packet.  The payload MUST NOT be longer
+         than 4,294,967,295 octets, which is the maximum size of a
+         Jumbogram [JUMBO]; however, the ESP Padding, Pad Length, and
+         Next Header fields are also part of the payload.
+
+      AAD
+         CCM provides data integrity and data origin authentication for
+         some data outside the payload.  CCM does not allow additional
+         authenticated data (AAD) to be longer than
+         18,446,744,073,709,551,615 octets.  The ICV is computed from
+         the ESP header, Payload, and ESP trailer fields, which is
+         significantly smaller than the CCM-imposed limit.  The
+         construction of the AAD described in Section 5.
+
+   AES CCM requires the encryptor to generate a unique per-packet value
+   and to communicate this value to the decryptor.  This per-packet
+   value is one of the component parts of the nonce, and it is referred
+   to as the initialization vector (IV).  The same IV and key
+   combination MUST NOT be used more than once.  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).
+
+   AES CCM employs counter mode for encryption.  As with any stream
+   cipher, reuse of the same IV value with the same key is catastrophic.
+   An IV collision immediately leaks information about the plaintext in
+   both packets.  For this reason, it is inappropriate to use this CCM
+   with statically configured keys.  Extraordinary measures would be
+   needed to prevent reuse of an IV value with the static key across
+
+
+
+
+Housley                     Standards Track                     [Page 3]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+   power cycles.  To be safe, implementations MUST use fresh keys with
+   AES CCM.  The Internet Key Exchange (IKE) [IKE] protocol or IKEv2
+   [IKEv2] can be used to establish fresh keys.
+
+3.  ESP Payload
+
+   The ESP payload is composed of the IV followed by the ciphertext.
+   The payload field, as defined in [ESP], is structured as shown in
+   Figure 1.
+
+       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 CCM
+
+3.1.  Initialization Vector (IV)
+
+   The AES CCM 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
+   datagrams are lost or reordered.
+
+3.2.  Encrypted Payload
+
+    The encrypted payload contains the ciphertext.
+
+    AES CCM mode does not require plaintext padding.  However, ESP does
+    require padding to 32-bit word-align the authentication data.  The
+    Padding, Pad Length, and Next Header fields MUST be concatenated
+
+
+
+
+Housley                     Standards Track                     [Page 4]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+    with the plaintext before performing encryption, as described in
+    [ESP].  When padding is required, it MUST be generated and checked
+    in accordance with the conventions specified in [ESP].
+
+3.3.  Authentication Data
+
+   AES CCM provides an encrypted ICV.  The ICV provided by CCM is
+   carried in the Authentication Data fields without further encryption.
+   Implementations MUST support ICV sizes of 8 octets and 16 octets.
+   Implementations MAY also support ICV 12 octets.
+
+4.  Nonce Format
+
+   Each packet conveys the IV that is necessary to construct the
+   sequence of counter blocks used by counter mode to generate the key
+   stream.  The AES counter block is 16 octets.  One octet is used for
+   the CCM Flags, and 4 octets are used for the block counter, as
+   specified by the CCM L parameter.  The remaining octets are the
+   nonce.  These octets occupy the second through the twelfth octets in
+   the counter block.  Figure 2 shows the format of the nonce.
+
+       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
+                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      |                  Salt                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     Initialization Vector                     |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                           Figure 2.  Nonce Format
+
+   The components of the nonce are as follows:
+
+      Salt The salt field is 24 bits.  As the name implies, it contains
+         an unpredictable value.  It MUST be assigned at the beginning
+         of the security association.  The salt value need not be
+         secret, but it MUST NOT be predictable 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.
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 5]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+   This construction permits each packet to consist of up to:
+
+         2^32 blocks  =  4,294,967,296 blocks
+                      = 68,719,476,736 octets
+
+   This construction provides more key stream for each packet than is
+   needed to handle any IPv6 Jumbogram [JUMBO].
+
+5.  AAD Construction
+
+   The data integrity and data origin authentication for the Security
+   Parameters Index (SPI) and (Extended) Sequence Number fields is
+   provided without encrypting them.  Two formats are defined: one for
+   32-bit sequence numbers and one for 64-bit extended sequence numbers.
+   The format with 32-bit sequence numbers is shown in Figure 3, and the
+   format with 64-bit extended sequence numbers is shown in Figure 4.
+
+   Sequence Numbers are conveyed canonical network byte order.  Extended
+   Sequence Numbers are conveyed canonical network byte order, placing
+   the high-order 32 bits first and the low-order 32 bits second.
+   Canonical network byte order is fully described in RFC 791, Appendix
+   B.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               SPI                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     32-bit Sequence Number                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 3.  AAD Format with 32-bit Sequence Number
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               SPI                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 64-bit Extended Sequence Number               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 4.  AAD Format with 64-bit Extended Sequence Number
+
+
+
+
+
+
+
+
+Housley                     Standards Track                     [Page 6]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+6.  Packet Expansion
+
+   The initialization vector (IV) and the integrity check value (ICV)
+   are the only sources of packet expansion.  The IV always adds 8
+   octets to the front of the payload.  The ICV is added at the end of
+   the payload, and the CCM parameter M determines the size of the ICV.
+   Implementations MUST support M values of 8 octets and 16 octets, and
+   implementations MAY also support an M value of 12 octets.
+
+7.  IKE Conventions
+
+   This section describes the conventions used to generate keying
+   material and salt values for use with AES CCM using the Internet Key
+   Exchange (IKE) [IKE] protocol.  The identifiers and attributes needed
+   to negotiate a security association that uses AES CCM are also
+   defined.
+
+7.1.  Keying Material and Salt Values
+
+   As previously described, implementations MUST use fresh keys with AES
+   CCM.  IKE can be used to establish fresh keys.  This section
+   describes the conventions for obtaining the unpredictable salt value
+   for use in the nonce from IKE.  Note that this convention provides a
+   salt 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 KEYMAT MUST be three octets longer than is needed for the
+   associated AES key.  The keying material is used as follows:
+
+      AES CCM with a 128-bit key
+         The KEYMAT requested for each AES CCM key is 19 octets.  The
+         first 16 octets are the 128-bit AES key, and the remaining
+         three octets are used as the salt value in the counter block.
+
+      AES CCM with a 192-bit key
+         The KEYMAT requested for each AES CCM key is 27 octets.  The
+         first 24 octets are the 192-bit AES key, and the remaining
+         three octets are used as the salt value in the counter block.
+
+      AES CCM with a 256-bit key
+         The KEYMAT requested for each AES CCM key is 35 octets.  The
+         first 32 octets are the 256-bit AES key, and the remaining
+         three octets are used as the salt value in the counter block.
+
+
+
+
+Housley                     Standards Track                     [Page 7]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+7.2.  Phase 1 Identifier
+
+   This document does not specify the conventions for using AES CCM for
+   IKE Phase 1 negotiations.  For AES CCM to be used in this manner, a
+   separate specification is needed, and an Encryption Algorithm
+   Identifier needs to be assigned.
+
+7.3.  Phase 2 Identifier
+
+   For IKE Phase 2 negotiations, IANA has assigned three ESP Transform
+   Identifiers for AES CCM with an explicit IV:
+
+      14 for AES CCM with an 8-octet ICV;
+      15 for AES CCM with a 12-octet ICV; and
+      16 for AES CCM with a 16-octet ICV.
+
+7.4.  Key Length Attribute
+
+   Because 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.
+
+8.  Test Vectors
+
+   Section 8 of [CCM] provides test vectors that will assist
+   implementers with AES CCM mode.
+
+9.  Security Considerations
+
+   AES CCM employs counter (CTR) mode for confidentiality.  If a counter
+   value is 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 packet plaintexts?  Suppose two packets are defined by two
+   plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are
+   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, because:
+
+
+
+
+
+Housley                     Standards Track                     [Page 8]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+      (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
+
+   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, AES CCM should not be used with statically configured
+   keys.  Extraordinary measures would be needed to prevent the reuse of
+   a counter block value with the static key across power cycles.  To be
+   safe, implementations MUST use fresh keys with AES CCM.  The IKE
+   [IKE] protocol can be used to establish fresh keys.
+
+   When IKE is used to establish fresh keys between two peer entities,
+   separate keys are established for the two traffic flows.  If a
+   different mechanism is used to establish fresh keys, one that
+
+   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 and
+   decrypting packets with the same peer MUST ensure that the two peers
+   assign different salt values to the security association (SA).
+
+   Regardless of the mode used, AES with a 128-bit key is vulnerable to
+   the birthday attack after 2^64 blocks are encrypted with a single
+   key.  Since ESP with Extended Sequence Numbers allows for up to 2^64
+   packets in a single SA, there is real potential for more than 2^64
+   blocks to be encrypted with one key.  Implementations SHOULD generate
+   a fresh key before 2^64 blocks are encrypted with the same key, or
+   implementations SHOULD make use of the longer AES key sizes.  Note
+   that ESP with 32-bit Sequence Numbers will not exceed 2^64 blocks
+   even if all of the packets are maximum-length Jumbograms.
+
+10.  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
+   section documents the rationale for the selection of an explicit IV.
+   This selection is not a cryptographic security issue, as either
+   approach will prevent counter block collisions.
+
+   The use of the explicit IV does not dictate the manner that the
+   encryptor uses to assign the per-packet value in the counter block.
+   This is desirable for several reasons.
+
+
+
+
+Housley                     Standards Track                     [Page 9]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+      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.  The use of explicit IVs 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.  Furthermore, the
+      decision made by the implementer of the encryptor does not make
+      the decryptor more (or less) complex.
+
+      4.  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.
+
+      5.  Using the sequence number as the IV 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.
+
+      6.  By decoupling the IV and the sequence number, architectures
+      where the sequence number assignment is performed outside the
+      assurance boundary are accommodated.
+
+   The use of an explicit IV field directly follows from the decoupling
+   of the sequence number and the per-packet counter block value.  The
+   additional overhead (64 bits for the IV field) is acceptable.  This
+   overhead is significantly less overhead associated with Cipher Block
+   Chaining (CBC) mode.  As normally employed, CBC requires a full block
+   for the IV and, on average, half of a block for padding.  AES CCM
+   confidentiality processing with an explicit IV has about one-third of
+   the overhead as AES CBC, and the overhead is constant for each
+   packet.
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 10]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+11.  IANA Considerations
+
+   IANA has assigned three ESP transform numbers for use with AES CCM
+   with an explicit IV:
+
+      14 for AES CCM with an 8-octet ICV;
+      15 for AES CCM with a 12-octet ICV; and
+      16 for AES CCM with a 16-octet ICV.
+
+12.  Acknowledgements
+
+   Doug Whiting and Niels Ferguson worked with me to develop CCM mode.
+   We developed CCM mode as part of the IEEE 802.11i security effort.
+   One of the most attractive aspects of CCM mode is that it is
+   unencumbered by patents.  I acknowledge the companies that supported
+   the development of an unencumbered authenticated encryption mode (in
+   alphabetical order):
+
+      Hifn
+      Intersil
+      MacFergus
+      RSA Security
+
+   Also, I thank Tero Kivinen for his comprehensive review of this
+   document.
+
+13.  References
+
+   This section provides normative and informative references.
+
+13.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., "IP Encapsulating Security Payload (ESP)", RFC
+               4303, December 2005.
+
+   [CCM]       Whiting, D., Housley, R., and N. Ferguson, "Counter with
+               CBC-MAC (CCM)", RFC 3610, September 2003.
+
+   [STDWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Housley                     Standards Track                    [Page 11]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+13.2.  Informative References
+
+   [ARCH]      Kent, S. and K. Seo, "Security Architecture for the
+               Internet Protocol", RFC 4301, December 2005.
+
+   [IKE]       Harkins, D. and D. Carrel, "The Internet Key Exchange
+               (IKE)", RFC 2409, November 1998.
+
+   [IKEv2]     Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+               RFC 4306, December 2005.
+
+   [ROAD]      Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
+               Document Roadmap", RFC 2411, November 1998.
+
+   [JUMBO]     Borman, D., Deering, S., and R. Hinden, "IPv6
+               Jumbograms", RFC 2675, August 1999.
+
+Author's Address
+
+   Russell Housley
+   Vigil Security, LLC
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+
+   EMail: housley@vigilsec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 12]
+
+RFC 4309           Using AEC CCM Mode with IPsec ESP       December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Housley                     Standards Track                    [Page 13]
+