idnits 2.17.1 draft-williams-ipsec-channel-binding-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 282. 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 (March 21, 2008) is 5852 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-core' is defined on line 219, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-btns-prob-and-applic' is defined on line 224, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-btns-connection-latching-04 -- 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) == 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: 3 errors (**), 0 flaws (~~), 6 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 March 21, 2008 5 Expires: September 22, 2008 7 Channel Bindings for IPsec Using IKEv2 and Public Keys 8 draft-williams-ipsec-channel-binding-00.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 September 22, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document specifies the channel bindings for "IPsec channels" 42 where the peers used the Internet Key Exchange protocol version 2 43 (IKEv2) and where they used public keys and/or certificates to 44 authenticate each other 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Conventions used in this document . . . . . . . . . . . . . 3 50 2. IPsec Channel Bindings . . . . . . . . . . . . . . . . . . . 4 51 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 5 52 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 53 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 5.1. Normative References . . . . . . . . . . . . . . . . . . . . 7 55 5.2. Informative References . . . . . . . . . . . . . . . . . . . 7 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 57 Intellectual Property and Copyright Statements . . . . . . . 10 59 1. Introduction 61 Given the ability to construct IPsec channels 62 [I-D.ietf-btns-connection-latching] and the ability to bind 63 authentication at application layers to such secure channels 64 [RFC5056] the only missing components are: a definition of IPsec 65 channel bindings, and Application Programming Interfaces (APIs) by 66 which applications can obtain them. 68 Here we specify the "end-point channel bindings" [RFC5056] for IPsec 69 channels when peers use IKev2 [RFC4306] and public keys and/or 70 certificates. IPsec APIs [I-D.ietf-btns-ipsec-apireq] are out of 71 scope for this document. 73 IPsec channels where the peers were authenticated by methods other 74 than public key cryptography, such as EAP [RFC3748] or pre-shared 75 keys (PSK), or where IKEv2 was not used (e.g., manual keying), are 76 out of scope for this document. Channel bindings for such IPsec 77 channels should be specified elsewhere, if at all. 79 1.1. Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. IPsec Channel Bindings 87 The channel bindings for IPsec channels established via connection 88 latching [I-D.ietf-btns-connection-latching] between peers that use 89 IKEv2 [RFC4306] and public keys (with or without PKIX certificates 90 [RFC3280]) SHALL be: 92 the octet-string that results from the concatenation of the two 93 peers' raw public keys as they appear in the subjectPublicKey 94 field of their corresponding certificates' subjectPublicKeyInfo, 95 or as they appear in their IKEv2 CERT payload when the "Raw RSA 96 Key" CERT payload type has been used (see section 3.6 of 97 [RFC4306]. The order of concatenation SHALL be the binary 98 collation order of the two public keys, in increasing order. 100 The "binary collation order" is the "i;octet" collation registered in 101 the "Collation Registry for Internet Application Protocols" 102 [RFC4790]. 104 Because public keys in certificates are bit strings but the i;octet 105 collation operates on octet strings, public keys appearing in 106 certificates MUST be padded with zero bits to a number of bits that 107 is divisible by eight. 109 We provide end-point channel bindings (the peers' public keys) as the 110 IPsec channel binding because the construction of IPsec channels by 111 connection latching [I-D.ietf-btns-connection-latching] does not 112 unambiguously identify a single IKE_SA or CHILD SA pair from which 113 "unique channel bindings" could be derived. 115 We use a binary collation to determine the order of concatenation 116 because connection latching does not unambiguously identify the 117 initiator of the channel (besides, even TCP supports a notion of 118 simultaneous connections, in which case both peers are the 119 initiators). By using a collation to pick which key follows the 120 other we obtain an encoding of the end-point channel bindings that 121 both peers can agree on without negotiation. 123 3. IANA Considerations 125 This document creates a type of channel binding, and so requires 126 registration in the IANA channel binding registry (set out by 127 [RFC5056]). 129 The registration procedure will be followed when this document enters 130 the RFC-Editor queue. The registration will be as follows: 132 o Channel binding unique prefix (name): IPsec-end-point-IKEv2-pubkey 134 o Channel binding type: end-point 136 o Channel type: IPsec 138 o Published specification: 140 o Channel binding is secret: no 142 o Description: see Section 2 144 o Intended usage: COMMON 146 o Contact: this document's author/editor 148 o Owner/Change controller: IETF 150 4. Security Considerations 152 The security considerations of [RFC5056], 153 [I-D.ietf-btns-connection-latching], and IPsec generally [RFC4301] 154 apply. The security of an application using channel binding to IPsec 155 channels depends critically on the overall security of each of these 156 components: IPsec [RFC4301], including the IPsec key exchange 157 protocol [RFC4306], ESP/AH [RFC4303] [RFC4302], IPsec connection 158 latching, and the application's authentication and channel binding 159 mechanism. A compromise of any one of those components may 160 compromise the application to varying degrees. 162 This document describes end-point channel bindings for some IPsec 163 channels. End-point channel bindings do not uniquely identify a 164 connection, but, in this case, a pair of peers. There are no 165 additional security considerations, relating to the type of this 166 channel binding, beyond those described in [RFC5056]. 168 The construction of IPsec end-point channel bindings described herein 169 depends on the strength of the public keys and public key algorithms 170 used by the IPsec peers to authenticate each other, as well as on 171 IKEv2. As such is adds no weakness beyond any weaknesses in the 172 those cryptosystems. And because these are _public_ keys this 173 construction does not require confidentiality protection of the 174 channel bindings. 176 5. References 178 5.1. Normative References 180 [I-D.ietf-btns-connection-latching] 181 Williams, N., "IPsec Channels: Connection Latching", 182 draft-ietf-btns-connection-latching-04 (work in progress), 183 December 2007. 185 [I-D.ietf-btns-ipsec-apireq] 186 Richardson, M. and B. Sommerfeld, "Requirements for an 187 IPsec API", draft-ietf-btns-ipsec-apireq-00 (work in 188 progress), April 2006. 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, March 1997. 193 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 194 X.509 Public Key Infrastructure Certificate and 195 Certificate Revocation List (CRL) Profile", RFC 3280, 196 April 2002. 198 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 199 Internet Protocol", RFC 4301, December 2005. 201 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 202 December 2005. 204 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 205 RFC 4303, December 2005. 207 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 208 RFC 4306, December 2005. 210 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 211 Application Protocol Collation Registry", RFC 4790, 212 March 2007. 214 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 215 Channels", RFC 5056, November 2007. 217 5.2. Informative References 219 [I-D.ietf-btns-core] 220 Williams, N. and M. Richardson, "Better-Than-Nothing- 221 Security: An Unauthenticated Mode of IPsec", 222 draft-ietf-btns-core-06 (work in progress), January 2008. 224 [I-D.ietf-btns-prob-and-applic] 225 Touch, J., Black, D., and Y. Wang, "Problem and 226 Applicability Statement for Better Than Nothing Security 227 (BTNS)", draft-ietf-btns-prob-and-applic-06 (work in 228 progress), October 2007. 230 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 231 Levkowetz, "Extensible Authentication Protocol (EAP)", 232 RFC 3748, June 2004. 234 Author's Address 236 Nicolas Williams 237 Sun Microsystems 238 5300 Riata Trace Ct 239 Austin, TX 78727 240 US 242 Email: Nicolas.Williams@sun.com 244 Full Copyright Statement 246 Copyright (C) The IETF Trust (2008). 248 This document is subject to the rights, licenses and restrictions 249 contained in BCP 78, and except as set forth therein, the authors 250 retain all their rights. 252 This document and the information contained herein are provided on an 253 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 254 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 255 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 256 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 257 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 258 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 260 Intellectual Property 262 The IETF takes no position regarding the validity or scope of any 263 Intellectual Property Rights or other rights that might be claimed to 264 pertain to the implementation or use of the technology described in 265 this document or the extent to which any license under such rights 266 might or might not be available; nor does it represent that it has 267 made any independent effort to identify any such rights. Information 268 on the procedures with respect to rights in RFC documents can be 269 found in BCP 78 and BCP 79. 271 Copies of IPR disclosures made to the IETF Secretariat and any 272 assurances of licenses to be made available, or the result of an 273 attempt made to obtain a general license or permission for the use of 274 such proprietary rights by implementers or users of this 275 specification can be obtained from the IETF on-line IPR repository at 276 http://www.ietf.org/ipr. 278 The IETF invites any interested party to bring to its attention any 279 copyrights, patents or patent applications, or other proprietary 280 rights that may cover technology that may be required to implement 281 this standard. Please address the information to the IETF at 282 ietf-ipr@ietf.org. 284 Acknowledgment 286 Funding for the RFC Editor function is provided by the IETF 287 Administrative Support Activity (IASA).