idnits 2.17.00 (12 Aug 2021) /tmp/idnits8836/draft-ietf-nfsv4-channel-bindings-03.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 464), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (February 22, 2005) is 6296 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: 'SECSH-GSSAPI' is mentioned on line 229, but not defined == Missing Reference: 'IPSP-APIREQ' is mentioned on line 322, but not defined == Unused Reference: 'RFC2744' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'RFC0854' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC2025' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'RFC2203' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC2478' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC2623' is defined on line 398, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2478 (Obsoleted by RFC 4178) -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETWORK WORKING GROUP N. Williams 2 Internet-Draft Sun 3 Expires: August 23, 2005 February 22, 2005 5 On the Use of Channel Bindings to Secure Channels 6 draft-ietf-nfsv4-channel-bindings-03.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 23, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document defines and formalizes the concept of channel bindings 40 to secure layers and defines the channel bindings for several types 41 of secure channels. 43 The concept of channel bindings allows applications to prove that the 44 end-points of two secure channels at different network layers are the 45 same by binding authentication at one channel to the session 46 protection at the other channel. The use of channel bindings allows 47 applications to delegate session protection to lower layers, which 48 may significantly improve performance for some applications. 50 Table of Contents 52 1. Conventions used in this document . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4. Authentication protocols and channel bindings . . . . . . . . 7 56 4.1 The GSS-API and channel bindings . . . . . . . . . . . . . 7 57 4.2 SASL and channel bindings . . . . . . . . . . . . . . . . 7 58 5. Channel bindings for various secure layers . . . . . . . . . . 9 59 5.1 Bindings to SSHv2 channels . . . . . . . . . . . . . . . . 9 60 5.2 Bindings to TLS channels . . . . . . . . . . . . . . . . . 9 61 5.3 Bindings to IPsec . . . . . . . . . . . . . . . . . . . . 9 62 5.3.1 Interfaces for creating IPsec channels . . . . . . . . 10 63 5.4 Bindings to other types of channels . . . . . . . . . . . 10 64 6. Benefits of channel bindings to secure channels . . . . . . . 11 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 8.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 70 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 71 Intellectual Property and Copyright Statements . . . . . . . . 15 73 1. Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 Over the years several attempts have been made to delegate session 82 protection at one network layer to another, for performance and/or 83 scalability as well as for design elegance and also to avoid having 84 to reinvent the wheel (that is, cryptographic session protection) for 85 every new application or security layer. 87 The critical security problem to solve in order to achieve such 88 delegation of session protection is always the same: how to ensure 89 that there is no man-in-the-middle (MITM), from the point of view the 90 application, at the lower network layer to which session protection 91 is to be delegated. 93 An alternative statement of the problem: how does one ensure that the 94 end-points of two secure channels at different network layers are the 95 same? 97 And there may well be a MITM, particularly if the lower network layer 98 either provides no authentication or if there is no connection 99 between the authentication or principals used at the application and 100 those used at the lower network layer. 102 Such MITM attacks can be effected by, for example, spoofing IP 103 address lookups (which is possible, for example, when using DNS but 104 not DNSSEC) in a way that the application may not detect but which 105 directs the client application or network stack to connect to a 106 different host than had been intended (e.g., to the MITM's host). 108 Even if such MITM attacks seem particularly difficult to effect, the 109 attacks must be prevented for certain applications to be able to make 110 effective use of technologies such as IPsec. 112 A solution to this problem is highly desirable, particularly where 113 multi-user applications are run over secure network layers (e.g., NFS 114 over IPsec). For such applications the authentication model used at 115 the application layer (usually user<->server) is generally very 116 different from that used by secure, lower network layers, such as 117 IPsec (usually client<->server or single-user<->server), and may even 118 use different authentication infrastructures altogether (e.g., 119 Kerberos V for the application layer, x.509 certificates at the lower 120 layer). Such applications cannot, at present, generally leverage the 121 security provided by the lower network layers, which, if they could, 122 would allow them to offload session security to the secure lower 123 layer. 125 One solution involves ensuring the use of secure name services for 126 hostname to network address translation along with the use of secure 127 networks (e.g., IPsec). This approach can prevent the MITM attack 128 described above, but does not offer applications any guarantees that 129 there is no MITM in the lower layer. 131 This document describes another solution: the use of "channel 132 bindings" (a GSS-API concept [RFC2743]) to bind authentication at 133 application layers to secure transports at lower layers in the 134 network stack. 136 "Channel bindings" are data which securely identify a secure channel 137 such that, when verified to match on both endpoints of end-to-end 138 application connections, leave no doubt that the endpoints of two 139 secure channels (the one identified by the bindings and the one used 140 to exchange/verify the bindings) are the same. 142 Because many applications exist which provide for authentication at 143 the application layer, because many such applications use generic 144 authentication frameworks, such as the GSS-API and SASL and are 145 already deployed along with a common authentication infrastructure 146 (e.g., Kerberos V, PKI, etc...), because such applications exist 147 which multiplex multiple users onto a single session (and so cannot 148 leverage network [e.g., IKE] authentication), the use of channel 149 bindings is an elegant solution even where secure name services and 150 networks are deployed. 152 A formal definition of the channel bindings concept is given below, 153 as well as the specific formulation of channel bindings for various 154 protocols that provide for session security. 156 Specific instructions for the use of channel bindings with GSS-API 157 instructions is given elsewhere. 159 3. Definitions 161 The GSS-API [RFC2743] is a generic interface to GSS-API security 162 mechanisms which provides for authentication and session 163 cryptographic protection. One facility provided by the GSS-API is a 164 concept of "channel bindings" which consists of some data which must 165 be provided, if at all, by both, initiators and acceptors, and which 166 the GSS-API security mechanisms ensure are the same for both, the 167 initiator and acceptor of any given GSS-API security context - if the 168 channel bindings provided by them do not match then the mechanism 169 fails to establish the security context. 171 o Channel bindings 172 Generally some data which names a channel or its end-points. 173 The security properties and channel bindings of the channel, 174 once established, MUST NOT change for the lifetime of the 175 channel. 177 More formally, there are two types of channel bindings: 179 + bindings that name a channel in a cryptographically secure 180 manner (e.g., the session ID in SSHv2; see below); 181 + bindings that name the authenticated end-points of a channel 182 (e.g., as in IPsec; see below) which are, in turn, securely 183 bound to the channel. 185 Applications can exchange authenticated, integrity-protected 186 verifiers of channel bindings data to prove that the end-points 187 of some channel are the logically the same as the application 188 endpoints and thus, there can be no MITM at the lower layer. 189 o Channel bindings to network addresses 190 The GSS-API originally defined only channel bindings to network 191 addresses. 192 The network addresses of a channel's end-points typically say 193 nothing about the protection afforded by that channel, and 194 where the channel can be said to be secure the network 195 addresses may not be securely bound to the channel anyways. 196 In practice channel bindings to network addresses have mostly 197 just caused trouble with Network Address Translation (NAT). 199 4. Authentication protocols and channel bindings 201 Some authentication services provide for channel bindings, such as 202 the GSS-API and some GSS-API mechanisms, whereas others may not, such 203 as SASL. 205 Where suitable channel bindings facilities are not provided 206 application protocol designers may include a separate, protected 207 (where the authentication service provides message protection 208 services) exchange of channel bindings material. 210 4.1 The GSS-API and channel bindings 212 The GSS-API provides for the use of channel bindings during 213 initialization of GSS-API security contexts, though GSS-API 214 mechanisms are not required to support this facility. 216 This channel bindings facility is described in detail in RFC2744. 218 GSS-API applications must agree a priori, through negotiation or 219 otherwise, on the use of channel bindings. This is because the 220 GSS-API does not have a way to indicate that a security context was 221 successfully established but that the channel bindings supplied could 222 not be verified to be the same for both peers. 224 Fortunately, it is possible to design GSS-API pseudo-mechanisms that 225 simply wrap around existing mechanisms for the purpose of allowing 226 applications to negotiate the use of channel bindings within their 227 existing methods for negotiating GSS-API mechanisms. For example, 228 NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as 229 does the SSHv2 protocol [SECSH-GSSAPI]. Such pseudo-mechanisms are 230 being proposed separately. [NOTE: Indirect reference to CCM...] 232 However, it does not, at this time, seem feasible to use SPNEGO with 233 such pseudo-mechanisms for negotiating the use of channel bindings. 235 4.2 SASL and channel bindings 237 SASL does not provide for the use of channel bindings during 238 initialization of SASL contexts. 240 SASL applications MAY define their own exchange of 241 integrity-protected channel bindings using established SASL integrity 242 layers. 244 Alternatively, SASL applications MAY use the GSS-* SASL mechanisms 245 (which correspond to GSS-API mechanisms) to ensure the use of channel 246 bindings through the GSS-API's facilities; this approach may require 247 more study and specification elsewhere. 249 5. Channel bindings for various secure layers 251 Not every secure session protocol or interface provides for secure 252 channels, and not every secure session protocol provides data 253 suitable for use as channel bindings. 255 5.1 Bindings to SSHv2 channels 257 SSHv2 provides both, a secure channel and material (the SSHv2 258 "session ID") that is suitable for use as channel bindings. 260 Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the 261 channel bindings for SSHv2. 263 5.2 Bindings to TLS channels 265 TLS provides both, a secure channel and material (the TLS "finished" 266 messages), that is suitable for use as channel bindings. 268 Thus it is RECOMMENDED that the concatenation of the client's and 269 server's "finished" messages, in that order, be used as the channel 270 bindings for TLS. 272 Note that the TLS "session ID," in spite of being named similarly to 273 the SSHv2 session ID, is not suitable for use as channel bindings 274 because it is assigned by the server, so a MITM could assign the same 275 session ID on the client side as it gets from the server. 277 5.3 Bindings to IPsec 279 IPsec does not provide for secure channels by itself, as it protects 280 individual packets. Further, the IPsec SAs used to protect the 281 packets for some channel (e.g., a TCP connection) over its lifetime 282 need not be related in any way that allows for construction of 283 channel bindings. 285 There is a set of IPsec parameters that may be kept constant for all 286 IP packets for a given channel (e.g., a TCP connection): 288 o the peers' authenticated IPsec IDs 289 o the SA types (e.g., transport mode ESP) 290 o the privacy and integrity protection algorithms used 292 Provided interfaces for binding a channel to these IPsec parameters 293 it is possible to construct a channel secured by IPsec. 295 The channel bindings for such a channel, then, are the values of 296 those IPsec parameters to which the channel is bound. 298 Requirements for such interfaces to IPsec are specified in 299 [IPSP-APIREQ]. 301 5.3.1 Interfaces for creating IPsec channels 303 In order to build an IPsec channel some additional application 304 programming interfaces are needed to: 306 o indicate that an as yet unconnected channel is to be bound to 307 IPsec IDs and 308 o explicitly specify one, the other or both of those IDs 309 o implicitly specify one, the other or both of those IDs (e.g., the 310 ID corresponding to the current application program instance) 311 o indirectly specify one, the other or both of those IDs (e.g., 312 through IP addresses or hostnames) 313 o explicitly specify ESP and/or AH and associated algorithms 315 and/or 317 o discover the IPsec parameters to which a channel is bound 319 For connection-less datagram transports the IDs to be used need to be 320 specified/discovered on a per-datagram basis. 322 See [IPSP-APIREQ]. 324 5.4 Bindings to other types of channels 326 Channel bindings for other secure session protocols are not specified 327 here. 329 6. Benefits of channel bindings to secure channels 331 The use of channel bindings to delegate session cryptographic 332 protection include: 334 o Performance improvements by avoiding double protection of 335 application data in cases where IPsec is in use and applications 336 provide their own secure channels. 337 o Performance improvements by leveraging hardware-accelerated IPsec. 338 o Performance improvements by allowing RDDP hardware offloading to 339 be integrated with IPsec hardware acceleration. 340 Where protocols layered above RDDP use privacy protection RDDP 341 offload cannot be done, thus by using channel bindings to IPsec 342 the privacy protection is moved to IPsec, which is layered 343 below RDDP, so RDDP can address application protocol data 344 that's in cleartext relative to the RDDP headers. 345 o Latency improvements for applications that multiplex multiple 346 users onto a single channel, such as NFS w/ RPCSEC_GSS. 348 7. Security Considerations 350 When delegating session protection from one layer to another, one 351 will almost certainly be making some session security trade-offs, 352 such as using weaker cipher modes in one layer than might be used in 353 the other. Implementors and administrators SHOULD understand these 354 trade-offs. 356 Channel bindings cannot and MUST NOT be used without mutual 357 authentication (of client/user/initiator and server/user/acceptor). 359 Anonymous secure channels SHOULD NOT be used without authentication 360 and corresponding use of their channel bindings at higher network 361 layers. 363 The security of channel bindings depends on the security of the 364 channels, the construction of the bindings and the security of the 365 authentication and integrity protection used to exchange channel 366 bindings. 368 8. References 370 8.1 Normative 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [RFC2743] Linn, J., "Generic Security Service Application Program 376 Interface Version 2, Update 1", RFC 2743, January 2000. 378 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 379 C-bindings", RFC 2744, January 2000. 381 8.2 Informative 383 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 384 Specification", STD 8, RFC 854, May 1983. 386 [RFC1035] Mockapetris, P., "Domain names - implementation and 387 specification", STD 13, RFC 1035, November 1987. 389 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 390 (SPKM)", RFC 2025, October 1996. 392 [RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol 393 Specification", RFC 2203, September 1997. 395 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 396 Negotiation Mechanism", RFC 2478, December 1998. 398 [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues 399 and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", 400 RFC 2623, June 1999. 402 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 403 Beame, C., Eisler, M. and D. Noveck, "Network File System 404 (NFS) version 4 Protocol", RFC 3530, April 2003. 406 Author's Address 408 Nicolas Williams 409 Sun Microsystems 410 5300 Riata Trace Ct 411 Austin, TX 78727 412 US 414 EMail: Nicolas.Williams@sun.com 416 Appendix A. Acknowledgments 418 The author would like to thank Mike Eisler for his work on the 419 Channel Conjunction Mechanism I-D and for bringing the problem to a 420 head, Sam Hartman for pointing out that channel bindings provide a 421 general solution to the channel binding problem, Jeff Altman for his 422 suggestion of using the TLS finished messages as the TLS channel 423 bindings, Bill Sommerfeld, for his help in developing channel 424 bindings for IPsec, and Radia Perlman for her most helpful comments. 426 Intellectual Property Statement 428 The IETF takes no position regarding the validity or scope of any 429 Intellectual Property Rights or other rights that might be claimed to 430 pertain to the implementation or use of the technology described in 431 this document or the extent to which any license under such rights 432 might or might not be available; nor does it represent that it has 433 made any independent effort to identify any such rights. Information 434 on the procedures with respect to rights in RFC documents can be 435 found in BCP 78 and BCP 79. 437 Copies of IPR disclosures made to the IETF Secretariat and any 438 assurances of licenses to be made available, or the result of an 439 attempt made to obtain a general license or permission for the use of 440 such proprietary rights by implementers or users of this 441 specification can be obtained from the IETF on-line IPR repository at 442 http://www.ietf.org/ipr. 444 The IETF invites any interested party to bring to its attention any 445 copyrights, patents or patent applications, or other proprietary 446 rights that may cover technology that may be required to implement 447 this standard. Please address the information to the IETF at 448 ietf-ipr@ietf.org. 450 Disclaimer of Validity 452 This document and the information contained herein are provided on an 453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 455 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 456 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 457 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 458 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 460 Copyright Statement 462 Copyright (C) The Internet Society (2005). This document is subject 463 to the rights, licenses and restrictions contained in BCP 78, and 464 except as set forth therein, the authors retain all their rights. 466 Acknowledgment 468 Funding for the RFC Editor function is currently provided by the 469 Internet Society.