Movatterモバイル変換

Network Working Group                                            S. KentRequest for Comments: 4304                              BBN TechnologiesCategory: Standards Track                                  December 2005Extended Sequence Number (ESN) Addendum toIPsec 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 20051.  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 inRFC 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  1Kent                        Standards Track                     [Page 2]

RFC 4304               ESN Addendum to ISAKMP DOI          December 20053.  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   inSection 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 2005Normative 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)",RFC4303, 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",RFC2412, November 1998.Author's Address   Stephen Kent   BBN Technologies   10 Moulton Street   Cambridge, MA  02138   USA   Phone: +1 (617) 873-3988   EMail: kent@bbn.comKent                        Standards Track                     [Page 4]

RFC 4304               ESN Addendum to ISAKMP DOI          December 2005Full Copyright Statement   Copyright (C) The Internet Society (2005).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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]