NETWORK WORKING GROUP N. Williams Internet-Draft Sun Expires: December 31, 2006 June 29, 2006 On the Use of Channel Bindings to Secure Channels draft-ietf-nfsv4-channel-bindings-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines and formalizes the concept of channel bindings to secure layers and defines the channel bindings for several types of secure channels. The concept of channel bindings allows applications to prove that the end-points of two secure channels at different network layers are the same by binding authentication at one channel to the session protection at the other channel. The use of channel bindings allows applications to delegate session protection to lower layers, which Williams Expires December 31, 2006 [Page 1] Internet-Draft On Channel Bindings June 2006 may significantly improve performance for some applications. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Authentication protocols and channel bindings . . . . . . . . 8 4.1. The GSS-API and channel bindings . . . . . . . . . . . . . 8 4.2. SASL and channel bindings . . . . . . . . . . . . . . . . 8 5. Channel bindings for various secure layers . . . . . . . . . . 10 5.1. Bindings to SSHv2 channels . . . . . . . . . . . . . . . . 10 5.2. Bindings to TLS channels . . . . . . . . . . . . . . . . . 10 5.3. Bindings to IPsec . . . . . . . . . . . . . . . . . . . . 10 5.4. Bindings to other types of channels . . . . . . . . . . . 11 6. Benefits of channel bindings to secure channels . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Williams Expires December 31, 2006 [Page 2] Internet-Draft On Channel Bindings June 2006 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Williams Expires December 31, 2006 [Page 3] Internet-Draft On Channel Bindings June 2006 2. Introduction Over the years several attempts have been made to delegate session protection at one network layer to another, for performance and/or scalability as well as for design elegance and also to avoid having to reinvent the wheel (that is, cryptographic session protection) for every new application or security layer. The critical security problem to solve in order to achieve such delegation of session protection is always the same: how to ensure that there is no man-in-the-middle (MITM), from the point of view the application, at the lower network layer to which session protection is to be delegated. An alternative statement of the problem: how does one ensure that the end-points of two secure channels at different network layers are the same? And there may well be a MITM, particularly if the lower network layer either provides no authentication or if there is no connection between the authentication or principals used at the application and those used at the lower network layer. Such MITM attacks can be effected by, for example, spoofing IP address lookups (which is possible, for example, when using DNS but not DNSSEC) in a way that the application may not detect but which directs the client application or network stack to connect to a different host than had been intended (e.g., to the MITM's host). Even if such MITM attacks seem particularly difficult to effect, the attacks must be prevented for certain applications to be able to make effective use of technologies such as IPsec. A solution to this problem is highly desirable, particularly where multi-user applications are run over secure network layers (e.g., NFS over IPsec). For such applications the authentication model used at the application layer (usually user<->server) is generally very different from that used by secure, lower network layers, such as IPsec (usually client<->server or single-user<->server), and may even use different authentication infrastructures altogether (e.g., Kerberos V for the application layer, x.509 certificates at the lower layer). Such applications cannot, at present, generally leverage the security provided by the lower network layers, which, if they could, would allow them to offload session security to the secure lower layer. One solution involves ensuring the use of secure name services for hostname to network address translation along with the use of secure Williams Expires December 31, 2006 [Page 4] Internet-Draft On Channel Bindings June 2006 networks (e.g., IPsec). This approach can prevent the MITM attack described above, but does not offer applications any guarantees that there is no MITM in the lower layer. This document describes another solution: the use of "channel bindings" (a GSS-API concept [RFC2743] [RFC2744]) to bind authentication at application layers to secure transports at lower layers in the network stack. "Channel bindings" are data which securely identify a secure channel such that, when verified to match on both endpoints of end-to-end application connections, leave no doubt that the endpoints of two secure channels (the one identified by the bindings and the one used to exchange/verify the bindings) are the same. Because many applications exist which provide for authentication at the application layer, because many such applications use generic authentication frameworks, such as the GSS-API and SASL and are already deployed along with a common authentication infrastructure (e.g., Kerberos V, PKI, etc...), because such applications exist which multiplex multiple users onto a single session (and so cannot leverage network [e.g., IKE] authentication), the use of channel bindings is an elegant solution even where secure name services and networks are deployed. A formal definition of the channel bindings concept is given below, as well as the specific formulation of channel bindings for various protocols that provide for session security. Specific instructions for the use of channel bindings with GSS-API instructions is given elsewhere. Williams Expires December 31, 2006 [Page 5] Internet-Draft On Channel Bindings June 2006 3. Definitions Definitions: o Secure channel: a packet, datagram or octet stream connection between two end-points that affords cryptographic integrity and, optionally, confidentiality to data exchanged over it. o Channel binding: ensuring that no man-in-the-middle exists between two end-points authenticated at one network layer but using a secure channel at a lower network layer. o Channel bindings Generally some data which names a channel or its end-points such that if this data can be shown, at a higher network layer, to be the same at both ends of a channel then there are no MITMs between the two end-points at that higher network layer. The security properties and channel bindings of the channel, once established, MUST NOT change for the lifetime of the channel. More formally, there are two types of channel bindings: + bindings that name a channel in a cryptographically secure manner (e.g., the session ID in SSHv2; see below); + bindings that name the authenticated end-points, or even a single end-point, of a channel (e.g., as in IPsec; see below) which are, in turn, securely bound to the channel. Applications can exchange authenticated, integrity-protected verifiers of channel bindings data to prove that the end-points of some channel are the logically the same as the application endpoints and thus, there can be no MITM at the lower layer. o Channel bindings to network addresses The GSS-API originally defined only channel bindings to network addresses. Williams Expires December 31, 2006 [Page 6] Internet-Draft On Channel Bindings June 2006 The network addresses of a channel's end-points typically say nothing about the protection afforded by that channel, and where the channel can be said to be secure the network addresses may not be securely bound to the channel anyways. In practice channel bindings to network addresses have mostly just caused trouble with Network Address Translation (NAT). Williams Expires December 31, 2006 [Page 7] Internet-Draft On Channel Bindings June 2006 4. Authentication protocols and channel bindings Some authentication services provide for channel bindings, such as the GSS-API and some GSS-API mechanisms, whereas others may not, such as SASL (however, ongoing work may add channel binding support to SASL). Where suitable channel bindings facilities are not provided, application protocol designers may include a separate, protected (where the authentication service provides message protection services) exchange of channel bindings material. 4.1. The GSS-API and channel bindings The GSS-API provides for the use of channel bindings during initialization of GSS-API security contexts, though GSS-API mechanisms are not required to support this facility. This channel bindings facility is described in detail in RFC2744. GSS-API applications must agree a priori, through negotiation or otherwise, on the use of channel bindings. This is because the GSS- API does not have a way to indicate that a security context was successfully established but that the channel bindings supplied could not be verified to be the same for both peers. Fortunately, it is possible to design GSS-API pseudo-mechanisms that simply wrap around existing mechanisms for the purpose of allowing applications to negotiate the use of channel bindings within their existing methods for negotiating GSS-API mechanisms. For example, NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as does the SSHv2 protocol [SECSH-GSSAPI]. Such pseudo-mechanisms are being proposed separately. [NOTE: Indirect reference to CCM...] However, it does not, at this time, seem feasible to use SPNEGO with such pseudo-mechanisms for negotiating the use of channel bindings. 4.2. SASL and channel bindings SASL [RFC2222] does not yet provide for the use of channel bindings during initialization of SASL contexts. Work is ongoing [I-D.ietf-sasl-gs2] to specify how SASL, particularly it's new bridge to the GSS-API, performs channel binding. SASL will likely differ from the GSS-API in its handling of channel binding failure (i.e., when there may be a MITM) in that channel binding success/failure only affects the negotiation of SASL security layers. I.e., when channel binding succeeds SASL should select no security Williams Expires December 31, 2006 [Page 8] Internet-Draft On Channel Bindings June 2006 layers, leaving session cryptographic protection to the secure channel that has been bound to. Williams Expires December 31, 2006 [Page 9] Internet-Draft On Channel Bindings June 2006 5. Channel bindings for various secure layers Not every secure session protocol or interface provides for secure channels, and not every secure session protocol provides data suitable for use as channel bindings. 5.1. Bindings to SSHv2 channels SSHv2 [RFC4251] provides both, a secure channel and material (the SSHv2 "session ID") that is suitable for use as channel bindings. Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the channel bindings for SSHv2. 5.2. Bindings to TLS channels TLS provides both, a secure channel and material (the TLS "finished" messages), that is suitable for use as channel bindings. Alternatively the TLS PRF can be applied to a suitable constant octet string to obtain value that is cryptographically bound to the given TLS session. The specification of channel bindings for TLS channels is still ongoing. Note that the TLS "session ID," in spite of being named similarly to the SSHv2 session ID, is not suitable for use as channel bindings because it is assigned by the server, so a MITM could assign the same session ID on the client side as it gets from the server. 5.3. Bindings to IPsec IPsec [RFC4301] does not provide for secure channels by itself, as it protects individual packets. Further, the IPsec SAs used to protect the packets for some channel (e.g., a TCP connection) over its lifetime need not be related in any way that allows for construction of channel bindings. There is ongoing work to specify an IPsec secure channel construction called "connection latching" [I-D.ietf-btns-connection-latching]. Given connection latching the channel bindings for IPsec should consist of the locally-observed ID types and values for the two end- points of the IKE_SA that fathered the CHILD SA that triggered the connection latch. A canonical encoding for these channel bindings has not yet been agreed upon. Williams Expires December 31, 2006 [Page 10] Internet-Draft On Channel Bindings June 2006 5.4. Bindings to other types of channels Channel bindings for other secure session protocols are not specified here. Williams Expires December 31, 2006 [Page 11] Internet-Draft On Channel Bindings June 2006 6. Benefits of channel bindings to secure channels The use of channel bindings to delegate session cryptographic protection include: o Performance improvements by avoiding double protection of application data in cases where IPsec is in use and applications provide their own secure channels. o Performance improvements by leveraging hardware-accelerated IPsec. o Performance improvements by allowing RDDP hardware offloading to be integrated with IPsec hardware acceleration. Where protocols layered above RDDP use privacy protection RDDP offload cannot be done, thus by using channel bindings to IPsec the privacy protection is moved to IPsec, which is layered below RDDP, so RDDP can address application protocol data that's in cleartext relative to the RDDP headers. o Latency improvements for applications that multiplex multiple users onto a single channel, such as NFS w/ RPCSEC_GSS. Williams Expires December 31, 2006 [Page 12] Internet-Draft On Channel Bindings June 2006 7. Security Considerations When delegating session protection from one layer to another, one will almost certainly be making some session security trade-offs, such as using weaker cipher modes in one layer than might be used in the other. Implementors and administrators SHOULD understand these trade-offs. Channel bindings cannot and MUST NOT be used without mutual authentication (of client/user/initiator and server/user/acceptor). Anonymous secure channels SHOULD NOT be used without authentication and corresponding use of their channel bindings at higher network layers. The security of channel bindings depends on the security of the channels, the construction of the bindings and the security of the authentication and integrity protection used to exchange channel bindings. 8. Normative [I-D.ietf-btns-connection-latching] Williams, N., "IPsec Channels: Connection Latching", draft-ietf-btns-connection-latching-00 (work in progress), February 2006. [I-D.ietf-sasl-gs2] Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-00 (work in progress), February 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000. [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003. Williams Expires December 31, 2006 [Page 13] Internet-Draft On Channel Bindings June 2006 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. Williams Expires December 31, 2006 [Page 14] Internet-Draft On Channel Bindings June 2006 Appendix A. Acknowledgments The author would like to thank Mike Eisler for his work on the Channel Conjunction Mechanism I-D and for bringing the problem to a head, Sam Hartman for pointing out that channel bindings provide a general solution to the channel binding problem, Jeff Altman for his suggestion of using the TLS finished messages as the TLS channel bindings, Bill Sommerfeld, for his help in developing channel bindings for IPsec, and Radia Perlman for her most helpful comments, Simon Josefsson for his work on the new SASL GSS-API bridge and his suggestion that the TLS PRF be used to generate channel bindings to TLS, and to many others. Williams Expires December 31, 2006 [Page 15] Internet-Draft On Channel Bindings June 2006 Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US Email: Nicolas.Williams@sun.com Williams Expires December 31, 2006 [Page 16] Internet-Draft On Channel Bindings June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Williams Expires December 31, 2006 [Page 17]