idnits 2.17.1 draft-ietf-ipsec-esn-addendum-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 51: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 52: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 60: '...scribed as basic MUST NOT be encoded a...' RFC 2119 keyword, line 84: '... SHOULD be sent and the security ass...' RFC 2119 keyword, line 87: '...the security association setup MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7370 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Bra97' is mentioned on line 54, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AH' ** Obsolete normative reference: RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP' ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. 'OAKLEY') Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPsec Working Group Stephen Kent 2 Internet Draft BBN Technologies 3 Expires August 2004 February 2004 5 Extended Sequence Number Addendum to IPsec DOI for ISAKMP 7 draft-ietf-ipsec-esn-addendum-03.txt 9 Status of This Memo 11 This document is an Internet Draft and is subject to all provisions 12 of Section 10 of RFC2026. Internet Drafts are working documents of 13 the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet Drafts 17 Internet Drafts are draft documents valid for a maximum of 6 months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet Drafts as reference 20 material or to cite them other than as a "work in progress". 22 The list of current Internet Drafts can be accessed at 23 http://www.ietf.org/lid-abstracts.html 25 The list of Internet Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Copyright (C) The Internet Society (2004). All Rights Reserved. 30 Abstract 32 The IP Security Authentication Header (AH) and Encapsulating Security 33 Payload (ESP) protocols use a sequence number to detect replay. This 34 document describes extensions to the Internet IP Security Domain of 35 Interpretation (DOI) for the Internet Security Association and Key 36 Management Protocol(ISAKMP). These extensions support negotiation of 37 the use of traditional 32-bit sequence numbers or extended 64-bit 38 sequence numbers for a particular AH or ESP security association. 40 1. Introduction 42 The specifications for the IP Authentication Header (AH) [AH] and the 43 IP Encapsulating Security Payload (ESP) [ESP] describe an option for 44 use of Extended (64-bit) Sequence Numbers. This option permits 45 transmission of very large volumes of data at high-speeds over an 46 IPsec Security Association, without rekeying to avoid sequence number 47 space exhaustion. This document describes the additions to the IPsec 48 DOI for ISAKMP [DOI] that are needed to support negotiation of the 49 Extended Sequence Number option. 51 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 52 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 53 document, are to be interpreted as described in RFC 2119 [Bra97]. 55 2. IPsec Security Association Attribute 57 The following SA attribute definition is used in Phase II of an IKE 58 negotiation. The attribute type is Basic (B). Encoding of this 59 attribute is defined in the base ISAKMP specification [ISAKMP]. 60 Attributes described as basic MUST NOT be encoded as variable. See 61 [IKE] for further information on attribute encoding in the IPsec DOI. 62 All restrictions listed in [IKE] also apply to the IPsec DOI and to 63 this addendum. 65 Attribute Type 67 class value type 68 --------------------------------------------------------- 69 Extended (64-bit) Sequence Number TBD B 71 Class Values 73 This class specifies that the Security Association will be using 74 64-bit Sequence Numbers. (See [AH] and [ESP] for a description 75 of Extended (64-bit) Sequence Numbers.) 77 RESERVED 0 78 64-bit Sequence Number 1 80 3. Attribute Negotiation 82 If an implementation receives a defined IPsec DOI attribute (or 83 attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT 84 SHOULD be sent and the security association setup MUST be aborted. 86 If an implementation receives any attribute value but the value for 87 64-bit Sequence Numbers, the security association setup MUST be 88 aborted. 90 4. Security Considerations 92 This memo pertains to the Internet Key Exchange protocol ([IKE]), 93 which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to provide for 94 the derivation of cryptographic keying material in a secure and 95 authenticated manner. Specific discussion of the various security 96 protocols and transforms identified in this document can be found in 97 the associated base documents and in the cipher references. 99 The addition of the ESN attribute does not change the underlying 100 security characteristics of IKE. In using extended sequence numbers 101 with ESP, it is important to employ an encryption mode that is secure 102 when very large volumes of data are encrypted under a single key. 103 Thus, for example, DES in CBC mode would NOT be suitable for use with 104 the ESN, because no more than 2^32 blocks should be encrypted under a 105 single DES key in that mode. Similarly, the integrity algorithm used 106 with ESP or AH should be secure relative to the number of packets 107 being protected. To avoid potential security problems imposed by 108 algorithm limitations, the SA lifetime may be set to limit the volume 109 of data protected with a single key, prior to reaching the 2^64 110 packet limit imposed by the ESN. 112 5. IANA Considerations 114 This document contains a "magic" number to be maintained by the IANA. 115 No additional class values will be assigned for this attribute. Upon 116 approval of this draft for publication as an RFC, IANA is to allocate 117 an IPsec Security Attribute value for "Attribute Type". This value 118 is to replace the TBD under the heading "value" in the table in 119 Section 2. 121 Acknowledgments 123 The author would like to thank the members of the IPsec working 124 group. The author would also like to acknowledge the contributions of 125 Karen Seo for her help in the editing of this specification. 127 References 129 [AH] Kent, S., "IP Authentication Header", RFC ???, ??? 2003. 131 [DOI] Piper, D., "The Internet IP Security Domain of 132 Interpretation for ISAKMP", RFC 2407, November 1998. 134 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 135 ???, ??? 2003. 137 [IKE] Harkins, D., and D. Carrel, D., "The Internet Key Exchange 138 (IKE)", RFC 2409, November 1998. 140 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 141 "Internet Security Association and Key Management Protocol 142 (ISAKMP)", RFC 2408, November 1998. 144 [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 145 2412, November 1998. 147 Author Information 149 Stephen Kent 150 BBN Technologies 151 10 Moulton Street 152 Cambridge, MA 02138 153 USA 155 Phone: +1 (617) 873-3988 156 EMail: kent@bbn.com 158 Notices 160 The IETF takes no position regarding the validity or scope of any 161 intellectual property or other rights that might be claimed to 162 pertain to the implementation or use of the technology described in 163 this document or the extent to which any license under such rights 164 might or might not be available; neither does it represent that it 165 has made any effort to identify any such rights. Information on the 166 IETF's procedures with respect to rights in standards-track and 167 standards- related documentation can be found in BCP-11. Copies of 168 claims of rights made available for publication and any assurances of 169 licenses to be made available, or the result of an attempt made to 170 obtain a general license or permission for the use of such 171 proprietary rights by implementors or users of this specification can 172 be obtained from the IETF Secretariat." 174 The IETF invites any interested party to bring to its attention any 175 copyrights, patents or patent applications, or other proprietary 176 rights which may cover technology that may be required to practice 177 this standard. Please address the information to the IETF Executive 178 Director." 180 Copyright (C) The Internet Society (2004). All Rights Reserved. 182 This document and translations of it may be copied and furnished to 183 others, and derivative works that comment on or otherwise explain it 184 or assist in its implementation may be prepared, copied, published 185 and distributed, in whole or in part, without restriction of any 186 kind, provided that the above copyright notice and this paragraph are 187 included on all such copies and derivative works. However, this 188 document itself may not be modified in any way, such as by removing 189 the copyright notice or references to the Internet Society or other 190 Internet organizations, except as needed for the purpose of 191 developing Internet standards in which case the procedures for 192 copyrights defined in the Internet Standards process must be 193 followed, or as required to translate it into languages other than 194 English. 196 The limited permissions granted above are perpetual and will not be 197 revoked by the Internet Society or its successors or assigns. 199 This document and the information contained herein is provided on an 200 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 201 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 202 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 203 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 204 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 206 Expires August 2004