On the Use of Channel Bindings to Secure Channels
RFC 5056
Document | Type |
RFC - Proposed Standard
(November 2007; Errata)
Was draft-williams-on-channel-binding (individual in sec area)
|
|
---|---|---|---|
Last updated | 2018-12-20 | ||
Replaces | draft-ietf-nfsv4-channel-bindings | ||
Stream | IETF | ||
Formats | plain text pdf html bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5056 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Sam Hartman | ||
Send notices to | (None) |
Network Working Group N. Williams Request for Comments: 5056 Sun Category: Standards Track November 2007 On the Use of Channel Bindings to Secure Channels Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits. This document discusses and formalizes the concept of channel binding to secure channels. Williams Standards Track [Page 1] RFC 5056 On Channel Bindings November 2007 Table of Contents 1. Introduction ....................................................3 1.1. Conventions Used in This Document ..........................4 2. Definitions .....................................................4 2.1. Properties of Channel Binding ..............................6 2.2. EAP Channel Binding ........................................9 3. Authentication and Channel Binding Semantics ...................10 3.1. The GSS-API and Channel Binding ...........................10 3.2. SASL and Channel Binding ..................................11 4. Channel Bindings Specifications ................................11 4.1. Examples of Unique Channel Bindings .......................11 4.2. Examples of End-Point Channel Bindings ....................12 5. Uses of Channel Binding ........................................12 6. Benefits of Channel Binding to Secure Channels .................14 7. IANA Considerations ............................................15 7.1. Registration Procedure ....................................15 7.2. Comments on Channel Bindings Registrations ................16 7.3. Change Control ............................................17 8. Security Considerations ........................................17 8.1. Non-Unique Channel Bindings and Channel Binding Re-Establishment ..........................................18 9. References .....................................................19 9.1. Normative References ......................................19 9.2. Informative References ....................................19 Appendix A. Acknowledgments .......................................22 Williams Standards Track [Page 2] RFC 5056 On Channel Bindings November 2007 1. Introduction In a number of situations, it is useful for an application to be able to handle authentication within the application layer, while simultaneously being able to utilize session or transport security at a lower network layer. For example, IPsec [RFC4301] [RFC4303] [RFC4302] is amenable to being accelerated in hardware to handle very high link speeds, but IPsec key exchange protocols and the IPsec architecture are not as amenable to use as a security mechanism within applications, particularly applications that have users as clients. A method of combining security at both layers is therefore attractive. To enable this to be done securely, it is necessary to "bind" the mechanisms together -- so as to avoid man-in-the-middle vulnerabilities and enable the mechanisms to be integrated in a seamless way. This is the objective of "Channel Bindings". The term "channel binding", as used in this document, derives from the Generic Security Service Application Program Interface (GSS-API) [RFC2743], which has a channel binding facility that was intended for binding GSS-API authentication to secure channels at lower network layers. The purpose and benefits of the GSS-API channel binding facility were not discussed at length, and some details were left unspecified. Now we find that this concept can be very useful, therefore we begin with a generalization and formalization of "channel binding" independent of the GSS-API. Although inspired by and derived from the GSS-API, the notion of channel binding described herein is not at all limited to use by GSS- API applications. We envision use of channel binding by applications that utilize other security frameworks, such as Simple AuthenticationShow full document text