4304
PROPOSED STANDARD
Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
Authors: S. Kent
Date: December 2005
Area: sec
Working Group: ipsec
Stream: IETF
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. [STANDARDS-TRACK]
RFC 4304
PROPOSED STANDARD
Network Working Group S. Kent
Request for Comments: 4304 BBN Technologies
Category: Standards Track December 2005
<span class="h1">Extended Sequence Number (ESN) Addendum to</span>
<span class="h1">IPsec Domain of Interpretation (DOI)</span>
<span class="h1">for Internet Security Association</span>
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.
<span class="grey">Kent Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4304">RFC 4304</a> ESN Addendum to ISAKMP DOI December 2005</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The specifications for the IP Authentication Header (AH) [<a href="#ref-AH" title=""IP Authentication Header"">AH</a>] and the
IP Encapsulating Security Payload (ESP) [<a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>] 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 [<a href="#ref-DOI" title=""The Internet IP Security Domain of Interpretation for ISAKMP"">DOI</a>] 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 <a href="./rfc2119">RFC 2119</a> [<a href="#ref-Bra97" title=""Key words for use in RFCs to Indicate Requirement Level"">Bra97</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. IPsec Security Association Attribute</span>
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 [<a href="#ref-ISAKMP" title=""Internet Security Association and Key Management Protocol (ISAKMP)"">ISAKMP</a>]. Attributes described as basic MUST
NOT be encoded as variable. See [<a href="#ref-IKE" title=""The Internet Key Exchange (IKE)"">IKE</a>] for further information on
attribute encoding in the IPsec DOI. All restrictions listed in
[<a href="#ref-IKE" title=""The Internet Key Exchange (IKE)"">IKE</a>] 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 [<a href="#ref-AH" title=""IP Authentication Header"">AH</a>] and [<a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>] for a description
of extended (64-bit) sequence numbers.)
RESERVED 0
64-bit Sequence Number 1
<span class="grey">Kent Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4304">RFC 4304</a> ESN Addendum to ISAKMP DOI December 2005</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Attribute Negotiation</span>
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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This memo pertains to the Internet Key Exchange protocol [<a href="#ref-IKE" title=""The Internet Key Exchange (IKE)"">IKE</a>], which
combines ISAKMP [<a href="#ref-ISAKMP" title=""Internet Security Association and Key Management Protocol (ISAKMP)"">ISAKMP</a>] and Oakley [<a href="#ref-OAKLEY" title=""The OAKLEY Key Determination Protocol"">OAKLEY</a>] 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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
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 <a href="#section-2">Section 2</a>.
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.
<span class="grey">Kent Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4304">RFC 4304</a> ESN Addendum to ISAKMP DOI December 2005</span>
Normative References
[<a id="ref-Bra97">Bra97</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-AH">AH</a>] Kent, S., "IP Authentication Header", <a href="./rfc4302">RFC 4302</a>, December
2005.
[<a id="ref-DOI">DOI</a>] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", <a href="./rfc2407">RFC 2407</a>, November 1998.
[<a id="ref-ESP">ESP</a>] Kent, S., "IP Encapsulating Security Payload (ESP)", <a href="./rfc4303">RFC</a>
<a href="./rfc4303">4303</a>, December 2005.
[<a id="ref-IKE">IKE</a>] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", <a href="./rfc2409">RFC 2409</a>, November 1998.
[<a id="ref-ISAKMP">ISAKMP</a>] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", <a href="./rfc2408">RFC 2408</a>, November 1998.
Informative References
[<a id="ref-OAKLEY">OAKLEY</a>] Orman, H., "The OAKLEY Key Determination Protocol", <a href="./rfc2412">RFC</a>
<a href="./rfc2412">2412</a>, November 1998.
Author's Address
Stephen Kent
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3988
EMail: [email protected]
<span class="grey">Kent Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4304">RFC 4304</a> ESN Addendum to ISAKMP DOI December 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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-
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kent Standards Track [Page 5]
Annotations
Select text to annotate