idnits 2.17.1 draft-richardson-btns-ikeextensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 259. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2007) is 6280 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) == Unused Reference: 'I-D.ietf-btns-connection-latching' is defined on line 158, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-kitten-gssapi-channel-bindings' is defined on line 169, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nfsv4-channel-bindings' is defined on line 175, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 180, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 187, but no explicit reference was found in the text == Unused Reference: 'RFC2743' is defined on line 190, but no explicit reference was found in the text == Unused Reference: 'RFC4251' is defined on line 193, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 196, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-btns-connection-latching-00 == Outdated reference: A later version (-07) exists of draft-ietf-btns-prob-and-applic-03 ** Downref: Normative reference to an Informational draft: draft-ietf-btns-prob-and-applic (ref. 'I-D.ietf-btns-prob-and-applic') == Outdated reference: A later version (-07) exists of draft-ietf-kitten-gssapi-channel-bindings-01 == Outdated reference: A later version (-04) exists of draft-ietf-nfsv4-channel-bindings-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-nfsv4-channel-bindings' ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 5 errors (**), 0 flaws (~~), 15 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Expires: August 5, 2007 M. Richardson 5 SSW 6 February 2007 8 Extensions to IKEv1 and IKEv2 to indicate use of Better-Than-Nothing- 9 Security 10 draft-richardson-btns-ikeextensions-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 5, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies how to use the Internet Key Exchange (IKE) 44 protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" 45 security associations (SAs) for use with the IPsec Encapsulating 46 Security Payload (ESP) and the IPsec Authentication Header (AH). 47 This is part of the Better-Than-Nothing-Security (BTNS) work. Two 48 optional IKE extensions are documented here, and the format for one 49 certificate payload type is fully specified. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. IKE Notify . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Exchange of public keys . . . . . . . . . . . . . . . . . . . 5 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 60 Intellectual Property and Copyright Statements . . . . . . . . 10 62 1. Introduction 64 When two nodes decide to use BTNS, they may wish to communicate this 65 intention to the remote party. 67 There are no protocol reasons to require this intention to be 68 communicated, however, it is useful for diagnostic purposes to be 69 able to indicate this fact in the IKE negotiation. 71 As part of the BTNS IKE negotiation, it will be necessary for the 72 parties to exchange authentication keying material, and one option is 73 to use the certificate payload. The use of Raw RSA Key type (11) is 74 clarified with some examples. 76 2. IKE Notify 78 A new notify message is defined for both IKEv1 [RFC2408] and IKEv2 79 [RFC4306]. The name of the new notify is BTNS_AUTHENTICATED, and the 80 notify number is TBD1. 82 This notify message MAY appear in any exchange of phase 1 (IKEv1), 83 and in any exchange of the PARENT_SA (IKEv2). It SHOULD be sent in 84 after the phase 1 SA has become private, since there is little reason 85 to advise a third party of what kind of authentication is being done. 87 This means it SHOULD be sent during the third exchange of MAIN MODE 88 (IKEv1), in the second exchange of Aggressive Mode (IKEv1), and 89 during the second exchange of IKEv2. 91 Note: Aggressive mode is SHOULD NOT be used for BTNS. 93 3. Exchange of public keys 95 A BTNS negotiation MUST include a public key for each end-point. 96 This key will be carried in a Certificate Payload (section 3.6 of 97 [RFC4306] and section 3.9 of [RFC2408]). There are several options 98 as to how to carry the key. 100 The public KEY MUST be sent in a Certificate Type 11: Raw RSA Key. 101 This code point is hereby defined for IKEv1 identically to IKEv2. 103 An implementation MAY also include the same public KEY in a 104 Certificate Payload of type 1 (PKCS #7 wrapped X.509), and it may be 105 self-signed or relative to some CA. 107 An IKEv2 implementation MAY also include the same public KEY as a 108 Hash and URL of X.509 certificate bundle (type 13), or certificate 109 (type 12). (In general, an implementation should not send both type 110 1 and types 12 or 13, as it would be redundant.) 112 An implementation MAY also send additional Certificate Payload types 113 which it believes may be useful, provided that they all lead to the 114 same RSA key. An implementation SHOULD avoid using so many 115 Certificate Payload types that it causes the IKE messages to be 116 fragmented. 118 An implementation receiving more than one Certificate Payload SHOULD 119 use the following sources to arrive at a public key to use to 120 authenticate the peer, in the following order: 122 a preconfigure RSA key contained in a local trusted store. 124 an in-band X.509 certificate that can be verified against a 125 locally trusted root CA 127 a certificate or certificate bundle retrieved from the indicated 128 URL, that matches the hash, and can be verified 130 the key contained in the raw RSA Key payload 132 All Certificate Payload types other than type 11 are optional, and 133 type 11 is mandatory, so there will always be a public key available 134 to confirm the signature on in the IKE AUTH payload. 136 The additional payloads are present to deal with the situations where 137 the trust relationship may in fact be asymetrical, such as for the 138 Asymetrical SAB (A-SAB), and for the Asymetrical IKE CBB (AI-CBB). 139 (see [I-D.ietf-btns-prob-and-applic]) 141 4. IANA Considerations 143 Please assign NOTIFY Type TBD1. from the Notify-Types in the ipsec- 144 registry of IKEv1. 146 Please assign NOTIFY Type TBD1. from the IKEv2 Notify Message Types 147 table of the ikev2-parameters registry. 149 5. Security Considerations 151 This document does not introduce any new mechanisms or modes to IKEv1 152 or IKEv2. It details the order in which to look for authentication 153 data for a protocol which does not in itself require any 154 authentication data. 156 6. Normative References 158 [I-D.ietf-btns-connection-latching] 159 Williams, N., "IPsec Channels: Connection Latching", 160 draft-ietf-btns-connection-latching-00 (work in progress), 161 February 2006. 163 [I-D.ietf-btns-prob-and-applic] 164 Touch, J., "Problem and Applicability Statement for Better 165 Than Nothing Security (BTNS)", 166 draft-ietf-btns-prob-and-applic-03 (work in progress), 167 June 2006. 169 [I-D.ietf-kitten-gssapi-channel-bindings] 170 Williams, N., "Clarifications and Extensions to the GSS- 171 API for the Use of Channel Bindings", 172 draft-ietf-kitten-gssapi-channel-bindings-01 (work in 173 progress), October 2005. 175 [I-D.ietf-nfsv4-channel-bindings] 176 Williams, N., "On the Use of Channel Bindings to Secure 177 Channels", draft-ietf-nfsv4-channel-bindings-03 (work in 178 progress), February 2005. 180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, March 1997. 183 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 184 Security Association and Key Management Protocol 185 (ISAKMP)", RFC 2408, November 1998. 187 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 188 (IKE)", RFC 2409, November 1998. 190 [RFC2743] Linn, J., "Generic Security Service Application Program 191 Interface Version 2, Update 1", RFC 2743, January 2000. 193 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 194 Protocol Architecture", RFC 4251, January 2006. 196 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 197 Internet Protocol", RFC 4301, December 2005. 199 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 200 RFC 4306, December 2005. 202 Authors' Addresses 204 Nicolas Williams 205 Sun Microsystems 206 5300 Riata Trace Ct 207 Austin, TX 78727 208 US 210 Email: Nicolas.Williams@sun.com 212 Michael C. Richardson 213 Sandelman Software Works 214 470 Dawson Avenue 215 Ottawa, ON K1Z 5V7 216 CA 218 Email: mcr@sandelman.ottawa.on.ca 219 URI: http://www.sandelman.ottawa.on.ca/ 221 Full Copyright Statement 223 Copyright (C) The IETF Trust (2007). 225 This document is subject to the rights, licenses and restrictions 226 contained in BCP 78, and except as set forth therein, the authors 227 retain all their rights. 229 This document and the information contained herein are provided on an 230 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 231 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 232 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 233 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 234 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 235 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 237 Intellectual Property 239 The IETF takes no position regarding the validity or scope of any 240 Intellectual Property Rights or other rights that might be claimed to 241 pertain to the implementation or use of the technology described in 242 this document or the extent to which any license under such rights 243 might or might not be available; nor does it represent that it has 244 made any independent effort to identify any such rights. Information 245 on the procedures with respect to rights in RFC documents can be 246 found in BCP 78 and BCP 79. 248 Copies of IPR disclosures made to the IETF Secretariat and any 249 assurances of licenses to be made available, or the result of an 250 attempt made to obtain a general license or permission for the use of 251 such proprietary rights by implementers or users of this 252 specification can be obtained from the IETF on-line IPR repository at 253 http://www.ietf.org/ipr. 255 The IETF invites any interested party to bring to its attention any 256 copyrights, patents or patent applications, or other proprietary 257 rights that may cover technology that may be required to implement 258 this standard. Please address the information to the IETF at 259 ietf-ipr@ietf.org. 261 Acknowledgment 263 Funding for the RFC Editor function is provided by the IETF 264 Administrative Support Activity (IASA).