idnits 2.17.1 draft-ietf-nfsv4-channel-bindings-04.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 431. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (June 29, 2006) is 6473 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 section? 'RFC2119' on line 364 looks like a reference -- Missing reference section? 'RFC2743' on line 370 looks like a reference -- Missing reference section? 'RFC2744' on line 373 looks like a reference -- Missing reference section? 'RFC3530' on line 376 looks like a reference -- Missing reference section? 'SECSH-GSSAPI' on line 237 looks like a reference -- Missing reference section? 'RFC2222' on line 367 looks like a reference -- Missing reference section? 'I-D.ietf-sasl-gs2' on line 359 looks like a reference -- Missing reference section? 'RFC4251' on line 380 looks like a reference -- Missing reference section? 'RFC4301' on line 383 looks like a reference -- Missing reference section? 'I-D.ietf-btns-connection-latching' on line 354 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 17 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: December 31, 2006 June 29, 2006 6 On the Use of Channel Bindings to Secure Channels 7 draft-ietf-nfsv4-channel-bindings-04.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 31, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document defines and formalizes the concept of channel bindings 41 to secure layers and defines the channel bindings for several types 42 of secure channels. 44 The concept of channel bindings allows applications to prove that the 45 end-points of two secure channels at different network layers are the 46 same by binding authentication at one channel to the session 47 protection at the other channel. The use of channel bindings allows 48 applications to delegate session protection to lower layers, which 49 may significantly improve performance for some applications. 51 Table of Contents 53 1. Conventions used in this document . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Authentication protocols and channel bindings . . . . . . . . 8 57 4.1. The GSS-API and channel bindings . . . . . . . . . . . . . 8 58 4.2. SASL and channel bindings . . . . . . . . . . . . . . . . 8 59 5. Channel bindings for various secure layers . . . . . . . . . . 10 60 5.1. Bindings to SSHv2 channels . . . . . . . . . . . . . . . . 10 61 5.2. Bindings to TLS channels . . . . . . . . . . . . . . . . . 10 62 5.3. Bindings to IPsec . . . . . . . . . . . . . . . . . . . . 10 63 5.4. Bindings to other types of channels . . . . . . . . . . . 11 64 6. Benefits of channel bindings to secure channels . . . . . . . 12 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 8. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 Intellectual Property and Copyright Statements . . . . . . . . . . 17 71 1. Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 Over the years several attempts have been made to delegate session 80 protection at one network layer to another, for performance and/or 81 scalability as well as for design elegance and also to avoid having 82 to reinvent the wheel (that is, cryptographic session protection) for 83 every new application or security layer. 85 The critical security problem to solve in order to achieve such 86 delegation of session protection is always the same: how to ensure 87 that there is no man-in-the-middle (MITM), from the point of view the 88 application, at the lower network layer to which session protection 89 is to be delegated. 91 An alternative statement of the problem: how does one ensure that the 92 end-points of two secure channels at different network layers are the 93 same? 95 And there may well be a MITM, particularly if the lower network layer 96 either provides no authentication or if there is no connection 97 between the authentication or principals used at the application and 98 those used at the lower network layer. 100 Such MITM attacks can be effected by, for example, spoofing IP 101 address lookups (which is possible, for example, when using DNS but 102 not DNSSEC) in a way that the application may not detect but which 103 directs the client application or network stack to connect to a 104 different host than had been intended (e.g., to the MITM's host). 106 Even if such MITM attacks seem particularly difficult to effect, the 107 attacks must be prevented for certain applications to be able to make 108 effective use of technologies such as IPsec. 110 A solution to this problem is highly desirable, particularly where 111 multi-user applications are run over secure network layers (e.g., NFS 112 over IPsec). For such applications the authentication model used at 113 the application layer (usually user<->server) is generally very 114 different from that used by secure, lower network layers, such as 115 IPsec (usually client<->server or single-user<->server), and may even 116 use different authentication infrastructures altogether (e.g., 117 Kerberos V for the application layer, x.509 certificates at the lower 118 layer). Such applications cannot, at present, generally leverage the 119 security provided by the lower network layers, which, if they could, 120 would allow them to offload session security to the secure lower 121 layer. 123 One solution involves ensuring the use of secure name services for 124 hostname to network address translation along with the use of secure 125 networks (e.g., IPsec). This approach can prevent the MITM attack 126 described above, but does not offer applications any guarantees that 127 there is no MITM in the lower layer. 129 This document describes another solution: the use of "channel 130 bindings" (a GSS-API concept [RFC2743] [RFC2744]) to bind 131 authentication at application layers to secure transports at lower 132 layers in the network stack. 134 "Channel bindings" are data which securely identify a secure channel 135 such that, when verified to match on both endpoints of end-to-end 136 application connections, leave no doubt that the endpoints of two 137 secure channels (the one identified by the bindings and the one used 138 to exchange/verify the bindings) are the same. 140 Because many applications exist which provide for authentication at 141 the application layer, because many such applications use generic 142 authentication frameworks, such as the GSS-API and SASL and are 143 already deployed along with a common authentication infrastructure 144 (e.g., Kerberos V, PKI, etc...), because such applications exist 145 which multiplex multiple users onto a single session (and so cannot 146 leverage network [e.g., IKE] authentication), the use of channel 147 bindings is an elegant solution even where secure name services and 148 networks are deployed. 150 A formal definition of the channel bindings concept is given below, 151 as well as the specific formulation of channel bindings for various 152 protocols that provide for session security. 154 Specific instructions for the use of channel bindings with GSS-API 155 instructions is given elsewhere. 157 3. Definitions 159 Definitions: 161 o Secure channel: a packet, datagram or octet stream connection 162 between two end-points that affords cryptographic integrity and, 163 optionally, confidentiality to data exchanged over it. 165 o Channel binding: ensuring that no man-in-the-middle exists between 166 two end-points authenticated at one network layer but using a 167 secure channel at a lower network layer. 169 o Channel bindings 171 Generally some data which names a channel or its end-points 172 such that if this data can be shown, at a higher network layer, 173 to be the same at both ends of a channel then there are no 174 MITMs between the two end-points at that higher network layer. 175 The security properties and channel bindings of the channel, 176 once established, MUST NOT change for the lifetime of the 177 channel. 179 More formally, there are two types of channel bindings: 181 + bindings that name a channel in a cryptographically secure 182 manner (e.g., the session ID in SSHv2; see below); 184 + bindings that name the authenticated end-points, or even a 185 single end-point, of a channel (e.g., as in IPsec; see 186 below) which are, in turn, securely bound to the channel. 188 Applications can exchange authenticated, integrity-protected 189 verifiers of channel bindings data to prove that the end-points 190 of some channel are the logically the same as the application 191 endpoints and thus, there can be no MITM at the lower layer. 193 o Channel bindings to network addresses 195 The GSS-API originally defined only channel bindings to network 196 addresses. 198 The network addresses of a channel's end-points typically say 199 nothing about the protection afforded by that channel, and 200 where the channel can be said to be secure the network 201 addresses may not be securely bound to the channel anyways. 203 In practice channel bindings to network addresses have mostly 204 just caused trouble with Network Address Translation (NAT). 206 4. Authentication protocols and channel bindings 208 Some authentication services provide for channel bindings, such as 209 the GSS-API and some GSS-API mechanisms, whereas others may not, such 210 as SASL (however, ongoing work may add channel binding support to 211 SASL). 213 Where suitable channel bindings facilities are not provided, 214 application protocol designers may include a separate, protected 215 (where the authentication service provides message protection 216 services) exchange of channel bindings material. 218 4.1. The GSS-API and channel bindings 220 The GSS-API provides for the use of channel bindings during 221 initialization of GSS-API security contexts, though GSS-API 222 mechanisms are not required to support this facility. 224 This channel bindings facility is described in detail in RFC2744. 226 GSS-API applications must agree a priori, through negotiation or 227 otherwise, on the use of channel bindings. This is because the GSS- 228 API does not have a way to indicate that a security context was 229 successfully established but that the channel bindings supplied could 230 not be verified to be the same for both peers. 232 Fortunately, it is possible to design GSS-API pseudo-mechanisms that 233 simply wrap around existing mechanisms for the purpose of allowing 234 applications to negotiate the use of channel bindings within their 235 existing methods for negotiating GSS-API mechanisms. For example, 236 NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as 237 does the SSHv2 protocol [SECSH-GSSAPI]. Such pseudo-mechanisms are 238 being proposed separately. [NOTE: Indirect reference to CCM...] 240 However, it does not, at this time, seem feasible to use SPNEGO with 241 such pseudo-mechanisms for negotiating the use of channel bindings. 243 4.2. SASL and channel bindings 245 SASL [RFC2222] does not yet provide for the use of channel bindings 246 during initialization of SASL contexts. 248 Work is ongoing [I-D.ietf-sasl-gs2] to specify how SASL, particularly 249 it's new bridge to the GSS-API, performs channel binding. SASL will 250 likely differ from the GSS-API in its handling of channel binding 251 failure (i.e., when there may be a MITM) in that channel binding 252 success/failure only affects the negotiation of SASL security layers. 253 I.e., when channel binding succeeds SASL should select no security 254 layers, leaving session cryptographic protection to the secure 255 channel that has been bound to. 257 5. Channel bindings for various secure layers 259 Not every secure session protocol or interface provides for secure 260 channels, and not every secure session protocol provides data 261 suitable for use as channel bindings. 263 5.1. Bindings to SSHv2 channels 265 SSHv2 [RFC4251] provides both, a secure channel and material (the 266 SSHv2 "session ID") that is suitable for use as channel bindings. 268 Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the 269 channel bindings for SSHv2. 271 5.2. Bindings to TLS channels 273 TLS provides both, a secure channel and material (the TLS "finished" 274 messages), that is suitable for use as channel bindings. 275 Alternatively the TLS PRF can be applied to a suitable constant octet 276 string to obtain value that is cryptographically bound to the given 277 TLS session. 279 The specification of channel bindings for TLS channels is still 280 ongoing. 282 Note that the TLS "session ID," in spite of being named similarly to 283 the SSHv2 session ID, is not suitable for use as channel bindings 284 because it is assigned by the server, so a MITM could assign the same 285 session ID on the client side as it gets from the server. 287 5.3. Bindings to IPsec 289 IPsec [RFC4301] does not provide for secure channels by itself, as it 290 protects individual packets. Further, the IPsec SAs used to protect 291 the packets for some channel (e.g., a TCP connection) over its 292 lifetime need not be related in any way that allows for construction 293 of channel bindings. 295 There is ongoing work to specify an IPsec secure channel construction 296 called "connection latching" [I-D.ietf-btns-connection-latching]. 298 Given connection latching the channel bindings for IPsec should 299 consist of the locally-observed ID types and values for the two end- 300 points of the IKE_SA that fathered the CHILD SA that triggered the 301 connection latch. A canonical encoding for these channel bindings 302 has not yet been agreed upon. 304 5.4. Bindings to other types of channels 306 Channel bindings for other secure session protocols are not specified 307 here. 309 6. Benefits of channel bindings to secure channels 311 The use of channel bindings to delegate session cryptographic 312 protection include: 314 o Performance improvements by avoiding double protection of 315 application data in cases where IPsec is in use and applications 316 provide their own secure channels. 318 o Performance improvements by leveraging hardware-accelerated IPsec. 320 o Performance improvements by allowing RDDP hardware offloading to 321 be integrated with IPsec hardware acceleration. 323 Where protocols layered above RDDP use privacy protection RDDP 324 offload cannot be done, thus by using channel bindings to IPsec 325 the privacy protection is moved to IPsec, which is layered 326 below RDDP, so RDDP can address application protocol data 327 that's in cleartext relative to the RDDP headers. 329 o Latency improvements for applications that multiplex multiple 330 users onto a single channel, such as NFS w/ RPCSEC_GSS. 332 7. Security Considerations 334 When delegating session protection from one layer to another, one 335 will almost certainly be making some session security trade-offs, 336 such as using weaker cipher modes in one layer than might be used in 337 the other. Implementors and administrators SHOULD understand these 338 trade-offs. 340 Channel bindings cannot and MUST NOT be used without mutual 341 authentication (of client/user/initiator and server/user/acceptor). 343 Anonymous secure channels SHOULD NOT be used without authentication 344 and corresponding use of their channel bindings at higher network 345 layers. 347 The security of channel bindings depends on the security of the 348 channels, the construction of the bindings and the security of the 349 authentication and integrity protection used to exchange channel 350 bindings. 352 8. Normative 354 [I-D.ietf-btns-connection-latching] 355 Williams, N., "IPsec Channels: Connection Latching", 356 draft-ietf-btns-connection-latching-00 (work in progress), 357 February 2006. 359 [I-D.ietf-sasl-gs2] 360 Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2 361 Mechanism Family", draft-ietf-sasl-gs2-00 (work in 362 progress), February 2006. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [RFC2222] Myers, J., "Simple Authentication and Security Layer 368 (SASL)", RFC 2222, October 1997. 370 [RFC2743] Linn, J., "Generic Security Service Application Program 371 Interface Version 2, Update 1", RFC 2743, January 2000. 373 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 374 C-bindings", RFC 2744, January 2000. 376 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 377 Beame, C., Eisler, M., and D. Noveck, "Network File System 378 (NFS) version 4 Protocol", RFC 3530, April 2003. 380 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 381 Protocol Architecture", RFC 4251, January 2006. 383 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 384 Internet Protocol", RFC 4301, December 2005. 386 Appendix A. Acknowledgments 388 The author would like to thank Mike Eisler for his work on the 389 Channel Conjunction Mechanism I-D and for bringing the problem to a 390 head, Sam Hartman for pointing out that channel bindings provide a 391 general solution to the channel binding problem, Jeff Altman for his 392 suggestion of using the TLS finished messages as the TLS channel 393 bindings, Bill Sommerfeld, for his help in developing channel 394 bindings for IPsec, and Radia Perlman for her most helpful comments, 395 Simon Josefsson for his work on the new SASL GSS-API bridge and his 396 suggestion that the TLS PRF be used to generate channel bindings to 397 TLS, and to many others. 399 Author's Address 401 Nicolas Williams 402 Sun Microsystems 403 5300 Riata Trace Ct 404 Austin, TX 78727 405 US 407 Email: Nicolas.Williams@sun.com 409 Intellectual Property Statement 411 The IETF takes no position regarding the validity or scope of any 412 Intellectual Property Rights or other rights that might be claimed to 413 pertain to the implementation or use of the technology described in 414 this document or the extent to which any license under such rights 415 might or might not be available; nor does it represent that it has 416 made any independent effort to identify any such rights. Information 417 on the procedures with respect to rights in RFC documents can be 418 found in BCP 78 and BCP 79. 420 Copies of IPR disclosures made to the IETF Secretariat and any 421 assurances of licenses to be made available, or the result of an 422 attempt made to obtain a general license or permission for the use of 423 such proprietary rights by implementers or users of this 424 specification can be obtained from the IETF on-line IPR repository at 425 http://www.ietf.org/ipr. 427 The IETF invites any interested party to bring to its attention any 428 copyrights, patents or patent applications, or other proprietary 429 rights that may cover technology that may be required to implement 430 this standard. Please address the information to the IETF at 431 ietf-ipr@ietf.org. 433 Disclaimer of Validity 435 This document and the information contained herein are provided on an 436 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 437 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 438 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 439 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 440 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 441 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 443 Copyright Statement 445 Copyright (C) The Internet Society (2006). This document is subject 446 to the rights, licenses and restrictions contained in BCP 78, and 447 except as set forth therein, the authors retain all their rights. 449 Acknowledgment 451 Funding for the RFC Editor function is currently provided by the 452 Internet Society.