[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 4304

IPsec Working Group                                         Stephen Kent
Internet Draft                                          BBN Technologies
Expires August 2004                                        February 2004





       Extended Sequence Number Addendum to IPsec DOI for ISAKMP

                  draft-ietf-ipsec-esn-addendum-03.txt






Status of This Memo

   This document is an Internet Draft and is subject to all provisions
   of Section 10 of RFC2026. Internet Drafts are working documents of
   the Internet Engineering Task Force (IETF), its areas, and its
   working groups.  Note that other groups may also distribute working
   documents as Internet Drafts

   Internet Drafts are draft documents valid for a maximum of 6 months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as a "work in progress".

   The list of current Internet Drafts can be accessed at
   http://www.ietf.org/lid-abstracts.html

   The list of Internet Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


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 for a particular AH or ESP security association.








Kent                                                            [Page 1]

Internet Draft         ESN Addendum to ISAKMP DOI          February 2003


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 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 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    TBD             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                                                            [Page 2]

Internet Draft         ESN Addendum to ISAKMP DOI          February 2003


3. Attribute Negotiation

   If an implementation receives a defined IPsec DOI attribute (or
   attribute value) which 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 extended sequence numbers
   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, DES in 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.  Upon
   approval of this draft for publication as an RFC, IANA is to allocate
   an IPsec Security Attribute value for "Attribute Type".  This value
   is to replace the TBD under the heading "value" in the table in
   Section 2.


Acknowledgments

   The author would like to thank the members of the IPsec working
   group. The author would also like to acknowledge the contributions of


Kent                                                            [Page 3]

Internet Draft         ESN Addendum to ISAKMP DOI          February 2003


   Karen Seo for her help in the editing of this specification.


References

   [AH]       Kent, S., "IP Authentication Header", RFC ???, ??? 2003.

   [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
              ???, ??? 2003.

   [IKE]      Harkins, D., and D. Carrel, D., "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.

   [OAKLEY]   Orman, H., "The OAKLEY Key Determination Protocol", RFC
              2412, November 1998.


Author Information

   Stephen Kent
   BBN Technologies
   10 Moulton Street
   Cambridge, MA  02138
   USA

   Phone: +1 (617) 873-3988
   EMail: kent@bbn.com
















Kent                                                            [Page 4]

Internet Draft         ESN Addendum to ISAKMP DOI          February 2003



Notices


   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."

   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 assigns.

   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


Kent                                                            [Page 5]

Internet Draft         ESN Addendum to ISAKMP DOI          February 2003


   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires August 2004















































Kent                                                            [Page 6]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/