idnits 2.17.1 draft-williams-ipsec-channel-binding-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 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 (April 21, 2008) is 5848 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) == Outdated reference: A later version (-11) exists of draft-ietf-btns-connection-latching-06 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-btns-ipsec-apireq' ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) == Outdated reference: A later version (-07) exists of draft-ietf-btns-core-06 == Outdated reference: A later version (-07) exists of draft-ietf-btns-prob-and-applic-06 Summary: 4 errors (**), 0 flaws (~~), 4 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 Intended status: Standards Track April 21, 2008 5 Expires: October 23, 2008 7 End-Point Channel Bindings for IPsec Using IKEv2 and Public Keys 8 draft-williams-ipsec-channel-binding-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 23, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document specifies the end-point channel bindings for "IPsec 42 channels" where the peers used the Internet Key Exchange protocol 43 version 2 (IKEv2) and where they used public keys and/or certificates 44 to authenticate each other. Specifically, we use hashes of the end- 45 points' public keys. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Conventions used in this document . . . . . . . . . . . . . 3 51 2. IPsec Unique Channel Bindings . . . . . . . . . . . . . . . 4 52 2.1. API Requirements . . . . . . . . . . . . . . . . . . . . . . 4 53 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 5 54 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 55 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5.1. Normative References . . . . . . . . . . . . . . . . . . . . 7 57 5.2. Informative References . . . . . . . . . . . . . . . . . . . 7 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 59 Intellectual Property and Copyright Statements . . . . . . . 10 61 1. Introduction 63 Given the ability to construct IPsec channels 64 [I-D.ietf-btns-connection-latching] and the ability to bind 65 authentication at application layers to such secure channels 66 [RFC5056] the only missing components are: a definition of IPsec 67 channel bindings, and Application Programming Interfaces (APIs) by 68 which applications can obtain them. 70 Here we specify the "end-point channel bindings" [RFC5056] for IPsec 71 channels when peers use IKEv2 [RFC4306] and public keys and/or 72 certificates [RFC3280]. IPsec APIs [I-D.ietf-btns-ipsec-apireq] are 73 out of scope for this document, but some requirements for such APIs 74 are provided here. 76 IPsec channels where the peers were authenticated by methods other 77 than public key cryptography, such as EAP [RFC3748] or pre-shared 78 keys (PSK), or where IKEv2 was not used (e.g., manual keying), are 79 out of scope for this document. Channel bindings for such IPsec 80 channels should be specified elsewhere, if at all (see 81 [I-D.williams-ipsec-unique-channel-binding]). 83 The primary feature of IPsec end-point channel bindings as specified 84 here is this: there is no reference to the actual contents of any key 85 exchanges other than the public keys used therein. Algorithm 86 negotiations, nonces, session keys, and so on are of no consequence. 87 And no additional message exchanges of any kind are needed in order 88 to establish the end-point channel bindings for an IPsec channel. 90 1.1. Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. IPsec Unique Channel Bindings 98 The end-point channel bindings for IPsec channels established via 99 connection latching [I-D.ietf-btns-connection-latching] between peers 100 that use IKEv2 [RFC4306] and public keys (with or without PKIX 101 certificates [RFC3280]) SHALL be: 103 HASH(HASH(ID1) XOR HASH(ID2)) 105 Where HASH() is a cryptographic hash function selected by the 106 application requesting the end-point channel bindings. 107 Implementations MUST support the use of SHA-256 [RFC4634]. ID1 and 108 ID2 are the raw public keys of each peer. If a peer uses a 109 certificate, the value of the subjectPublicKey field (a BIT STRING) 110 of the certificate's subjectPublicKeyInfo field is to be used 111 verbatim. If a peer uses a Raw RSA CERT payload, then the 112 Certificate Data portion of that CERT payload will be used verbatim. 113 XOR is used here to avoid having to determine an order in which end- 114 point IDs should be used. 116 The rationale for using hashes of public keys is: to greatly reduce 117 the size of channel binding data that might need to be tracked in 118 kernel-mode implementations (as we'd otherwise use the raw public key 119 bit strings, which can be in excess of a kilobyte). 121 2.1. API Requirements 123 Because of the use of a hash function which must be selected by the 124 application, implementations of IPsec connection latching and end- 125 point channel bindings MUST provide a way, in the API for obtaining 126 channel bindings, for the application to select the hash function to 127 use. 129 Since hash agility here depends on the application and its ability to 130 negotiate hash functions for this purpose, implementations MUST 131 provide an API for listing the supported hash functions. 133 3. IANA Considerations 135 This document creates a type of channel binding, and so requires 136 registration in the IANA channel binding registry (set out by 137 [RFC5056]). 139 The registration procedure will be followed when this document enters 140 the RFC-Editor queue. The registration will be as follows: 142 o Channel binding unique prefix (name): IPsec-end-point-IKEv2- 143 pubkey-sha-256 145 o Channel binding type: end-point 147 o Channel type: IPsec 149 o Published specification: 151 o Channel binding is secret: no 153 o Description: see Section 2 155 o Intended usage: COMMON 157 o Contact: this document's author/editor 159 o Owner/Change controller: IETF 161 4. Security Considerations 163 The security considerations of [RFC5056], 164 [I-D.ietf-btns-connection-latching], and IPsec generally [RFC4301] 165 apply. The security of an application using channel binding to IPsec 166 channels depends critically on the overall security of each of these 167 components: IPsec [RFC4301], including the Internet Key Exchange 168 (IKEv2) protocol [RFC4306], ESP/AH [RFC4303] [RFC4302], IPsec 169 connection latching [I-D.ietf-btns-connection-latching], and the 170 application's authentication and channel binding mechanism 171 (potentially too many to reference here, but a common example is 172 likely to be the Kerberos V mechanism [RFC4121] for the Generic 173 Security Services API (GSS-API) [RFC2743]. A compromise of any one 174 of those components may compromise the application to varying 175 degrees. 177 This document describes end-point channel bindings for some IPsec 178 channels. End-point channel bindings do not uniquely identify a 179 connection in time, but a pair of peers. This is sufficient to 180 detect man-in-the-middle attacks via channel binding. There are no 181 additional security considerations, relating to the type of this 182 channel binding, beyond those described in [RFC5056]. 184 Use of non-pre-shared Raw RSA public keys or certificates that cannot 185 be validated to a given trust anchor is supported in the Better Than 186 Nothing (BTNS) [I-D.ietf-btns-prob-and-applic] [I-D.ietf-btns-core] 187 model. When combined with connection latching and channel binding 188 BTNS can provide all the security that an application requires but 189 without having to deploy an IPsec authentication infrastructure 190 (e.g., a PKI, manual pre-sharing of raw RSA public keys and/or self- 191 signed certificates). 193 The construction of IPsec end-point channel bindings described herein 194 depends on the strength of the public key algorithms used by the 195 IPsec peers to authenticate each other. Because we use hashes of 196 _public_ keys this construction does not require confidentiality 197 protection of the channel bindings. 199 We use a hash function in the construction of IPsec channel bindings. 200 Correspondingly, we provide for hash agility, but we push the 201 responsibility for hash agility to the application. Applications 202 cannot know what hash function their peers support without 203 negotiating a hash function. Supporting multiple hash functions 204 requires computing the end-point channel bindings for each supported 205 hash function, and it requires storing, in each IPsec channel, all 206 the those end-point channel bindings. Thus minimizing the number of 207 supported hash functions is important. 209 5. References 211 5.1. Normative References 213 [I-D.ietf-btns-connection-latching] 214 Williams, N., "IPsec Channels: Connection Latching", 215 draft-ietf-btns-connection-latching-06 (work in progress), 216 February 2008. 218 [I-D.ietf-btns-ipsec-apireq] 219 Richardson, M. and B. Sommerfeld, "Requirements for an 220 IPsec API", draft-ietf-btns-ipsec-apireq-00 (work in 221 progress), April 2006. 223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, March 1997. 226 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 227 X.509 Public Key Infrastructure Certificate and 228 Certificate Revocation List (CRL) Profile", RFC 3280, 229 April 2002. 231 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 232 Internet Protocol", RFC 4301, December 2005. 234 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 235 December 2005. 237 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 238 RFC 4303, December 2005. 240 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 241 RFC 4306, December 2005. 243 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 244 (SHA and HMAC-SHA)", RFC 4634, July 2006. 246 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 247 Channels", RFC 5056, November 2007. 249 5.2. Informative References 251 [I-D.ietf-btns-core] 252 Williams, N. and M. Richardson, "Better-Than-Nothing- 253 Security: An Unauthenticated Mode of IPsec", 254 draft-ietf-btns-core-06 (work in progress), January 2008. 256 [I-D.ietf-btns-prob-and-applic] 257 Touch, J., Black, D., and Y. Wang, "Problem and 258 Applicability Statement for Better Than Nothing Security 259 (BTNS)", draft-ietf-btns-prob-and-applic-06 (work in 260 progress), October 2007. 262 [I-D.williams-ipsec-unique-channel-binding] 263 Williams, N., "Unique Channel Bindings for IPsec Using 264 IKEv2", draft-williams-ipsec-unique-channel-binding-00 265 (work in progress), April 2008. 267 [RFC2743] Linn, J., "Generic Security Service Application Program 268 Interface Version 2, Update 1", RFC 2743, January 2000. 270 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 271 Levkowetz, "Extensible Authentication Protocol (EAP)", 272 RFC 3748, June 2004. 274 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 275 Version 5 Generic Security Service Application Program 276 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 277 July 2005. 279 Author's Address 281 Nicolas Williams 282 Sun Microsystems 283 5300 Riata Trace Ct 284 Austin, TX 78727 285 US 287 Email: Nicolas.Williams@sun.com 289 Full Copyright Statement 291 Copyright (C) The IETF Trust (2008). 293 This document is subject to the rights, licenses and restrictions 294 contained in BCP 78, and except as set forth therein, the authors 295 retain all their rights. 297 This document and the information contained herein are provided on an 298 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 299 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 300 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 301 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 302 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 303 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 305 Intellectual Property 307 The IETF takes no position regarding the validity or scope of any 308 Intellectual Property Rights or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; nor does it represent that it has 312 made any independent effort to identify any such rights. Information 313 on the procedures with respect to rights in RFC documents can be 314 found in BCP 78 and BCP 79. 316 Copies of IPR disclosures made to the IETF Secretariat and any 317 assurances of licenses to be made available, or the result of an 318 attempt made to obtain a general license or permission for the use of 319 such proprietary rights by implementers or users of this 320 specification can be obtained from the IETF on-line IPR repository at 321 http://www.ietf.org/ipr. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights that may cover technology that may be required to implement 326 this standard. Please address the information to the IETF at 327 ietf-ipr@ietf.org. 329 Acknowledgment 331 Funding for the RFC Editor function is provided by the IETF 332 Administrative Support Activity (IASA).