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/rfc4304.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc4304.txt (limited to 'doc/rfc/rfc4304.txt') diff --git a/doc/rfc/rfc4304.txt b/doc/rfc/rfc4304.txt new file mode 100644 index 0000000..4908622 --- /dev/null +++ b/doc/rfc/rfc4304.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group S. Kent +Request for Comments: 4304 BBN Technologies +Category: Standards Track December 2005 + + + Extended Sequence Number (ESN) Addendum to + IPsec Domain of Interpretation (DOI) + for Internet Security Association + and Key Management Protocol (ISAKMP) + +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 + + The IP Security Authentication Header (AH) and Encapsulating Security + Payload (ESP) protocols use a sequence number to detect replay. This + document describes extensions to the Internet IP Security Domain of + Interpretation (DOI) for the Internet Security Association and Key + Management Protocol (ISAKMP). These extensions support negotiation + of the use of traditional 32-bit sequence numbers or extended (64- + bit) sequence numbers (ESNs) for a particular AH or ESP security + association. + + + + + + + + + + + + + + + + + + + +Kent Standards Track [Page 1] + +RFC 4304 ESN Addendum to ISAKMP DOI December 2005 + + +1. Introduction + + The specifications for the IP Authentication Header (AH) [AH] and the + IP Encapsulating Security Payload (ESP) [ESP] describe an option for + use of extended (64-bit) sequence numbers. This option permits + transmission of very large volumes of data at high speeds over an + IPsec Security Association, without rekeying to avoid sequence number + space exhaustion. This document describes the additions to the IPsec + DOI for ISAKMP [DOI] that are needed to support negotiation of the + extended sequence number (ESN) option. + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in RFC 2119 [Bra97]. + +2. IPsec Security Association Attribute + + The following SA attribute definition is used in Phase II of an + Internet Key Exchange Protocol (IKE) negotiation. The attribute type + is Basic (B). Encoding of this attribute is defined in the base + ISAKMP specification [ISAKMP]. Attributes described as basic MUST + NOT be encoded as variable. See [IKE] for further information on + attribute encoding in the IPsec DOI. All restrictions listed in + [IKE] also apply to the IPsec DOI and to this addendum. + + Attribute Type + + class value type + --------------------------------------------------------- + Extended (64-bit) Sequence Number 11 B + + Class Values + + This class specifies that the Security Association will be using + 64-bit sequence numbers. (See [AH] and [ESP] for a description + of extended (64-bit) sequence numbers.) + + RESERVED 0 + 64-bit Sequence Number 1 + + + + + + + + + + + + +Kent Standards Track [Page 2] + +RFC 4304 ESN Addendum to ISAKMP DOI December 2005 + + +3. Attribute Negotiation + + If an implementation receives a defined IPsec DOI attribute (or + attribute value) that it does not support, an ATTRIBUTES-NOT-SUPPORT + SHOULD be sent and the security association setup MUST be aborted. + + If an implementation receives any attribute value but the value for + 64-bit sequence numbers, the security association setup MUST be + aborted. + +4. Security Considerations + + This memo pertains to the Internet Key Exchange protocol [IKE], which + combines ISAKMP [ISAKMP] and Oakley [OAKLEY] to provide for the + derivation of cryptographic keying material in a secure and + authenticated manner. Specific discussion of the various security + protocols and transforms identified in this document can be found in + the associated base documents and in the cipher references. + + The addition of the ESN attribute does not change the underlying + security characteristics of IKE. In using ESNs with ESP, it is + important to employ an encryption mode that is secure when very large + volumes of data are encrypted under a single key. Thus, for example, + Data Encryption Standard (DES) in Cipher Block Chaining (CBC) mode + would NOT be suitable for use with the ESN, because no more than 2^32 + blocks should be encrypted under a single DES key in that mode. + Similarly, the integrity algorithm used with ESP or AH should be + secure relative to the number of packets being protected. To avoid + potential security problems imposed by algorithm limitations, the SA + lifetime may be set to limit the volume of data protected with a + single key, prior to reaching the 2^64 packet limit imposed by the + ESN. + +5. IANA Considerations + + This document contains a "magic" number to be maintained by the IANA. + No additional class values will be assigned for this attribute. The + IANA has allocated an IPsec Security Attribute value for "Attribute + Type". This value is listed under the heading "value" in the table + in Section 2. + +Acknowledgements + + The author would like to thank the members of the IPsec working + group. The author would also like to acknowledge the contributions + of Karen Seo for her help in the editing of this specification. + + + + + +Kent Standards Track [Page 3] + +RFC 4304 ESN Addendum to ISAKMP DOI December 2005 + + +Normative References + + [Bra97] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Level", BCP 14, RFC 2119, March 1997. + + [AH] Kent, S., "IP Authentication Header", RFC 4302, December + 2005. + + [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. + + [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, + "Internet Security Association and Key Management Protocol + (ISAKMP)", RFC 2408, November 1998. + +Informative References + + [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC + 2412, November 1998. + +Author's Address + + Stephen Kent + BBN Technologies + 10 Moulton Street + Cambridge, MA 02138 + USA + + Phone: +1 (617) 873-3988 + EMail: kent@bbn.com + + + + + + + + + + + + + + + +Kent Standards Track [Page 4] + +RFC 4304 ESN Addendum to ISAKMP DOI 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. + + + + + + + +Kent Standards Track [Page 5] + -- cgit v1.2.3