idnits 2.17.1 draft-ietf-nfsv4-channel-bindings-02.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 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 449. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 465), 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 == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 12) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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 (July 15, 2004) is 7222 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 323, but not defined == Unused Reference: 'RFC2744' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'RFC0854' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC2025' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'RFC2203' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC2478' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC2623' is defined on line 399, 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 (~~), 13 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: January 13, 2005 July 15, 2004 5 On the Use of Channel Bindings to Secure Channels 6 draft-ietf-nfsv4-channel-bindings-02.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 January 13, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). 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 . . . . . . . . . . 8 59 5.1 Bindings to SSHv2 channels . . . . . . . . . . . . . . . . 8 60 5.2 Bindings to TLS channels . . . . . . . . . . . . . . . . . 8 61 5.3 Bindings to IPsec . . . . . . . . . . . . . . . . . . . . 8 62 5.3.1 Interfaces for creating IPsec channels . . . . . . . . 9 63 5.4 Bindings to other types of channels . . . . . . . . . . . 9 64 6. Benefits of channel bindings to secure channels . . . . . . . 10 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 12 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 70 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 Intellectual Property and Copyright Statements . . . . . . . . 14 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 integrity- 241 protected channel bindings using established SASL integrity layers. 243 Alternatively, SASL applications MAY use the GSS-* SASL mechanisms 244 (which correspond to GSS-API mechanisms) to ensure the use of channel 245 bindings through the GSS-API's facilities; this approach may require 246 more study and specification elsewhere. 248 5. Channel bindings for various secure layers 250 Not every secure session protocol or interface provides for secure 251 channels, and not every secure session protocol provides data 252 suitable for use as channel bindings. 254 5.1 Bindings to SSHv2 channels 256 SSHv2 provides both, a secure channel and material (the SSHv2 257 "session ID") that is suitable for use as channel bindings. 259 Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the 260 channel bindings for SSHv2. 262 5.2 Bindings to TLS channels 264 TLS provides both, a secure channel and material (the TLS "finished" 265 messages), that is suitable for use as channel bindings. 267 Thus it is RECOMMENDED that the concatenation of the client's and 268 server's "finished" messages, in that order, be used as the channel 269 bindings for TLS. 271 Note that the TLS "session ID," in spite of being named similarly to 272 the SSHv2 session ID, is not suitable for use as channel bindings 273 because it is assigned by the server, so a MITM could assign the same 274 session ID on the client side as it gets from the server. 276 5.3 Bindings to IPsec 278 IPsec does not provide for secure channels by itself, as it protects 279 individual packets. Further, the IPsec SAs used to protect the 280 packets for some channel (e.g., a TCP connection) need not be related 281 in any way that allows for construction of channel bindings. 283 There is a set of IPsec parameters that may be kept constant for all 284 IP packets for a given channel (e.g., a TCP connection): 286 o the peers' authenticated IPsec IDs 287 o the SA types (e.g., transport mode ESP) 288 o the privacy and integrity protection algorithms used 290 [QUESTION: Should IPsec traffic selectors, that is, the protocol 291 (TCP, UDP, SCTP) and port numbers used for the channel be 292 included?] 294 Provided interfaces for binding a channel to these IPsec parameters 295 it is possible to construct a channel secured by IPsec. 297 The channel bindings for such a channel, then, are the values of 298 those IPsec parameters to which the channel is bound. 300 Requirements for such interfaces to IPsec are specified in 301 [IPSP-APIREQ]. 303 5.3.1 Interfaces for creating IPsec channels 305 In order to build an IPsec channel some additional application 306 programming interfaces are needed to: 308 o indicate that an as yet unconnected channel is to be bound to 309 IPsec IDs and 310 o explicitly specify one, the other or both of those IDs 311 o implicitly specify one, the other or both of those IDs (e.g., the 312 ID corresponding to the current application program instance) 313 o indirectly specify one, the other or both of those IDs (e.g., 314 through IP addresses or hostnames) 316 and/or 318 o discover the IPsec IDs to which a channel is bound 320 For connection-less datagram transports the IDs to be used need to be 321 specified/discovered on a per-datagram basis. 323 See [IPSP-APIREQ]. 325 5.4 Bindings to other types of channels 327 Channel bindings for other secure session protocols are not specified 328 here. 330 6. Benefits of channel bindings to secure channels 332 The use of channel bindings to delegate session cryptographic 333 protection include: 335 o Performance improvements by avoiding double protection of 336 application data in cases where IPsec is in use and applications 337 provide their own secure channels. 338 o Performance improvements by leveraging hardware-accelerated IPsec. 339 o Performance improvements by allowing RDDP hardware offloading to 340 be integrated with IPsec hardware acceleration. 341 Where protocols layered above RDDP use privacy protection RDDP 342 offload cannot be done, thus by using channel bindings to IPsec 343 the privacy protection is moved to IPsec, which is layered 344 below RDDP, so RDDP can address application protocol data 345 that's in cleartext relative to the RDDP headers. 346 o Latency improvements for applications that multiplex multiple 347 users onto a single channel, such as NFS w/ RPCSEC_GSS. 349 7. Security Considerations 351 When delegating session protection from one layer to another, one 352 will almost certainly be making some session security trade-offs, 353 such as using weaker cipher modes in one layer than might be used in 354 the other. Implementors and administrators SHOULD understand these 355 trade-offs. 357 Channel bindings cannot and MUST NOT be used without mutual 358 authentication (of client/user/initiator and server/user/acceptor). 360 Anonymous secure channels SHOULD NOT be used without authentication 361 and corresponding use of their channel bindings at higher network 362 layers. 364 The security of channel bindings depends on the security of the 365 channels, the construction of the bindings and the security of the 366 authentication and integrity protection used to exchange channel 367 bindings. 369 8. References 371 8.1 Normative 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997. 376 [RFC2743] Linn, J., "Generic Security Service Application Program 377 Interface Version 2, Update 1", RFC 2743, January 2000. 379 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 380 C-bindings", RFC 2744, January 2000. 382 8.2 Informative 384 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 385 Specification", STD 8, RFC 854, May 1983. 387 [RFC1035] Mockapetris, P., "Domain names - implementation and 388 specification", STD 13, RFC 1035, November 1987. 390 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 391 (SPKM)", RFC 2025, October 1996. 393 [RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol 394 Specification", RFC 2203, September 1997. 396 [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 397 Negotiation Mechanism", RFC 2478, December 1998. 399 [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues 400 and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", 401 RFC 2623, June 1999. 403 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 404 Beame, C., Eisler, M. and D. Noveck, "Network File System 405 (NFS) version 4 Protocol", RFC 3530, April 2003. 407 Author's Address 409 Nicolas Williams 410 Sun Microsystems 411 5300 Riata Trace Ct 412 Austin, TX 78727 413 US 415 EMail: Nicolas.Williams@sun.com 417 Appendix A. Acknowledgments 419 The author would like to thank Mike Eisler for his work on the 420 Channel Conjunction Mechanism I-D and for bringing the problem to a 421 head, Sam Hartman for pointing out that channel bindings provide a 422 general solution to the channel binding problem, Jeff Altman for his 423 suggestion of using the TLS finished messages as the TLS channel 424 bindings, Bill Sommerfeld, for his help in developing channel 425 bindings for IPsec, and Radia Perlman for her most helpful comments. 427 Intellectual Property Statement 429 The IETF takes no position regarding the validity or scope of any 430 Intellectual Property Rights or other rights that might be claimed to 431 pertain to the implementation or use of the technology described in 432 this document or the extent to which any license under such rights 433 might or might not be available; nor does it represent that it has 434 made any independent effort to identify any such rights. Information 435 on the procedures with respect to rights in RFC documents can be 436 found in BCP 78 and BCP 79. 438 Copies of IPR disclosures made to the IETF Secretariat and any 439 assurances of licenses to be made available, or the result of an 440 attempt made to obtain a general license or permission for the use of 441 such proprietary rights by implementers or users of this 442 specification can be obtained from the IETF on-line IPR repository at 443 http://www.ietf.org/ipr. 445 The IETF invites any interested party to bring to its attention any 446 copyrights, patents or patent applications, or other proprietary 447 rights that may cover technology that may be required to implement 448 this standard. Please address the information to the IETF at 449 ietf-ipr@ietf.org. 451 Disclaimer of Validity 453 This document and the information contained herein are provided on an 454 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 455 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 456 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 457 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 458 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 Copyright Statement 463 Copyright (C) The Internet Society (2004). This document is subject 464 to the rights, licenses and restrictions contained in BCP 78, and 465 except as set forth therein, the authors retain all their rights. 467 Acknowledgment 469 Funding for the RFC Editor function is currently provided by the 470 Internet Society.