From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4309.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc4309.txt (limited to 'doc/rfc/rfc4309.txt') 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] + -- cgit v1.2.3