7Network Working Group N. Williams
8Request for Comments: 5056 Sun
9Category: Standards Track November 2007
12 On the Use of Channel Bindings to Secure Channels
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
24 The concept of channel binding allows applications to establish that
25 the two end-points of a secure channel at one network layer are the
26 same as at a higher layer by binding authentication at the higher
27 layer to the channel at the lower layer. This allows applications to
28 delegate session protection to lower layers, which has various
31 This document discusses and formalizes the concept of channel binding
58Williams Standards Track [Page 1]
60RFC 5056 On Channel Bindings November 2007
65 1. Introduction ....................................................3
66 1.1. Conventions Used in This Document ..........................4
67 2. Definitions .....................................................4
68 2.1. Properties of Channel Binding ..............................6
69 2.2. EAP Channel Binding ........................................9
70 3. Authentication and Channel Binding Semantics ...................10
71 3.1. The GSS-API and Channel Binding ...........................10
72 3.2. SASL and Channel Binding ..................................11
73 4. Channel Bindings Specifications ................................11
74 4.1. Examples of Unique Channel Bindings .......................11
75 4.2. Examples of End-Point Channel Bindings ....................12
76 5. Uses of Channel Binding ........................................12
77 6. Benefits of Channel Binding to Secure Channels .................14
78 7. IANA Considerations ............................................15
79 7.1. Registration Procedure ....................................15
80 7.2. Comments on Channel Bindings Registrations ................16
81 7.3. Change Control ............................................17
82 8. Security Considerations ........................................17
83 8.1. Non-Unique Channel Bindings and Channel Binding
84 Re-Establishment ..........................................18
85 9. References .....................................................19
86 9.1. Normative References ......................................19
87 9.2. Informative References ....................................19
88 Appendix A. Acknowledgments .......................................22
114Williams Standards Track [Page 2]
116RFC 5056 On Channel Bindings November 2007
121 In a number of situations, it is useful for an application to be able
122 to handle authentication within the application layer, while
123 simultaneously being able to utilize session or transport security at
124 a lower network layer. For example, IPsec [RFC4301] [RFC4303]
125 [RFC4302] is amenable to being accelerated in hardware to handle very
126 high link speeds, but IPsec key exchange protocols and the IPsec
127 architecture are not as amenable to use as a security mechanism
128 within applications, particularly applications that have users as
129 clients. A method of combining security at both layers is therefore
130 attractive. To enable this to be done securely, it is necessary to
131 "bind" the mechanisms together -- so as to avoid man-in-the-middle
132 vulnerabilities and enable the mechanisms to be integrated in a
133 seamless way. This is the objective of "Channel Bindings".
135 The term "channel binding", as used in this document, derives from
136 the Generic Security Service Application Program Interface (GSS-API)
137 [RFC2743], which has a channel binding facility that was intended for
138 binding GSS-API authentication to secure channels at lower network
139 layers. The purpose and benefits of the GSS-API channel binding
140 facility were not discussed at length, and some details were left
141 unspecified. Now we find that this concept can be very useful,
142 therefore we begin with a generalization and formalization of
143 "channel binding" independent of the GSS-API.
145 Although inspired by and derived from the GSS-API, the notion of
146 channel binding described herein is not at all limited to use by GSS-
147 API applications. We envision use of channel binding by applications
148 that utilize other security frameworks, such as Simple Authentication
149 and Security Layer (SASL) [RFC4422] and even protocols that provide
150 their own authentication mechanisms (e.g., the Key Distribution
151 Center (KDC) exchanges of Kerberos V [RFC4120]). We also envision
152 use of the notion of channel binding in the analysis of security
155 The main goal of channel binding is to be able to delegate
156 cryptographic session protection to network layers below the
157 application in hopes of being able to better leverage hardware
158 implementations of cryptographic protocols. Section 5 describes some
159 intended uses of channel binding. Also, some applications may
160 benefit by reducing the amount of active cryptographic state, thus
161 reducing overhead in accessing such state and, therefore, the impact
162 of security on latency.
170Williams Standards Track [Page 3]
172RFC 5056 On Channel Bindings November 2007
175 The critical security problem to solve in order to achieve such
176 delegation of session protection is ensuring that there is no man-
177 in-the-middle (MITM), from the point of view the application, at the
178 lower network layer to which session protection is to be delegated.
180 There may well be an MITM, particularly if either the lower network
181 layer provides no authentication or there is no strong connection
182 between the authentication or principals used at the application and
183 those used at the lower network layer.
185 Even if such MITM attacks seem particularly difficult to effect, the
186 attacks must be prevented for certain applications to be able to make
187 effective use of technologies such as IPsec [RFC2401] [RFC4301] or
188 HTTP with TLS [RFC4346] in certain contexts (e.g., when there is no
189 authentication to speak of, or when one node's set of trust anchors
190 is too weak to believe that it can authenticate its peers).
191 Additionally, secure channels that are susceptible to MITM attacks
192 because they provide no useful end-point authentication are useful
193 when combined with application-layer authentication (otherwise they
194 are only somewhat "better than nothing" -- see Better Than Nothing
195 Security (BTNS) [BTNS-AS]).
197 For example, Internet Small Computer Systems Interface (iSCSI)
198 [RFC3720] provides for application-layer authentication (e.g., using
199 Kerberos V), but relies on IPsec for transport protection; iSCSI does
200 not provide a binding between the two. iSCSI initiators have to be
201 careful to make sure that the name of the server authenticated at the
202 application layer and the name of the peer at the IPsec layer match
203 -- an informal form of channel binding.
205 This document describes a solution: the use of "channel binding" to
206 bind authentication at application layers to secure sessions at lower
207 layers in the network stack.
2091.1. Conventions Used in This Document
211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
213 document are to be interpreted as described in [RFC2119].
217 o Secure channel: a packet, datagram, octet stream connection, or
218 sequence of connections between two end-points that affords
219 cryptographic integrity and, optionally, confidentiality to data
220 exchanged over it. We assume that the channel is secure -- if an
221 attacker can successfully cryptanalyze a channel's session keys,
222 for example, then the channel is not secure.
226Williams Standards Track [Page 4]
228RFC 5056 On Channel Bindings November 2007
231 o Channel binding: the process of establishing that no man-in-the-
232 middle exists between two end-points that have been authenticated
233 at one network layer but are using a secure channel at a lower
234 network layer. This term is used as a noun.
236 o Channel bindings: [See historical note below.]
238 Generally, some data that "names" a channel or one or both of
239 its end-points such that if this data can be shown, at a higher
240 network layer, to be the same at both ends of a channel, then
241 there are no MITMs between the two end-points at that higher
242 network layer. This term is used as a noun.
244 More formally, there are two types of channel bindings:
246 + unique channel bindings:
248 channel bindings that name a channel in a cryptographically
249 secure manner and uniquely in time;
251 + end-point channel bindings:
253 channel bindings that name the authenticated end-points, or
254 even a single end-point, of a channel which are, in turn,
255 securely bound to the channel, but which do not identify a
256 channel uniquely in time.
258 o Cryptographic binding: (e.g., "cryptographically bound") a
259 cryptographic operation that causes an object, such as a private
260 encryption or signing key, or an established secure channel, to
261 "speak for" [Lampson91] some principal, such as a user, a
262 computer, etcetera. For example, a Public Key Infrastructure for
263 X.509 Certificates (PKIX) certificate binds a private key to the
264 name of a principal in the trust domain of the certificate's
265 issuer such that a possessor of said private key can act on behalf
266 of the user (or other entity) named by the certificate.
268 Cryptographic bindings are generally asymmetric in nature (not to
269 be confused with symmetric or asymmetric key cryptography) in that
270 an object is rendered capable of standing for another, but the
271 reverse is not usually the case (we don't say that a user speaks
272 for their private keys, but we do say that the user's private keys
275 Note that there may be many instances of "cryptographic binding" in
276 an application of channel binding. The credentials that authenticate
277 principals at the application layer bind private or secret keys to
278 the identities of those principals, such that said keys speak for
282Williams Standards Track [Page 5]
284RFC 5056 On Channel Bindings November 2007
287 them. A secure channel typically consists of symmetric session keys
288 used to provide confidentiality and integrity protection to data sent
289 over the channel; each end-point's session keys speak for that end-
290 point of the channel. Finally, each end-point of a channel bound to
291 authentication at the application layer speaks for the principal
292 authenticated at the application layer on the same side of the
295 The terms defined above have been in use for many years and have been
296 taken to mean, at least in some contexts, what is stated below.
297 Unfortunately this means that "channel binding" can refer to the
298 channel binding operation and, sometimes to the name of a channel,
299 and "channel bindings" -- a difference of only one letter --
300 generally refers to the name of a channel.
302 Note that the Extensible Authentication Protocol (EAP) [RFC3748] uses
303 "channel binding" to refer to a facility that may appear to be
304 similar to the one decribed here, but it is, in fact, quite
305 different. See Section 2.2 for mode details.
3072.1. Properties of Channel Binding
309 Applications, authentication frameworks (e.g., the GSS-API, SASL),
310 security mechanisms (e.g., the Kerberos V GSS-API mechanism
311 [RFC1964]), and secure channels must meet the requirements and should
312 follow the recommendations that are listed below.
316 o In order to use channel binding, applications MUST verify that the
317 same channel bindings are observed at either side of the channel.
318 To do this, the application MUST use an authentication protocol at
319 the application layer to authenticate one, the other, or both
320 application peers (one at each end of the channel).
322 * If the authentication protocol used by the application supports
323 channel binding, the application SHOULD use it.
325 * An authentication protocol that supports channel binding MUST
326 provide an input slot in its API for a "handle" to the channel,
327 or its channel bindings.
329 * If the authentication protocol does not support a channel
330 binding operation, but provides a "security layer" with at
331 least integrity protection, then the application MUST use the
332 authentication protocol's integrity protection facilities to
333 exchange channel bindings, or cryptographic hashes thereof.
338Williams Standards Track [Page 6]
340RFC 5056 On Channel Bindings November 2007
343 * The name of the type of channel binding MUST be used by the
344 application and/or authentication protocol to avoid ambiguity
345 about which of several possible types of channels is being
346 bound. If nested instances of the same type of channel are
347 available, then the innermost channel MUST be used.
349 o Specifications of channel bindings for any secure channels MUST
350 provide for a single, canonical octet string encoding of the
351 channel bindings. Under this framework, channel bindings MUST
352 start with the channel binding unique prefix followed by a colon
355 o The channel bindings for a given type of secure channel MUST be
356 constructed in such a way that an MITM could not easily force the
357 channel bindings of a given channel to match those of another.
359 o Unique channel bindings MUST bind not only the key exchange for
360 the secure channel, but also any negotiations and authentication
361 that may have taken place to establish the channel.
363 o End-point channel bindings MUST be bound into the secure channel
364 and all its negotiations. For example, a public key as an end-
365 point channel binding should be used to verify a signature of such
366 negotiations (or to encrypt them), including the initial key
367 exchange and negotiation messages for that channel -- such a key
368 would then be bound into the channel. A certificate name as end-
369 point channel binding could also be bound into the channel in a
370 similar way, though in the case of a certificate name, the binding
371 also depends on the strength of the authentication of that name
372 (that is, the validation of the certificate, the trust anchors,
373 the algorithms used in the certificate path construction and
374 validation, etcetera).
376 o End-point channel bindings MAY be identifiers (e.g., certificate
377 names) that must be authenticated through some infrastructure,
378 such as a public key infrastructure (PKI). In such cases,
379 applications MUST ensure that the channel provides adequate
380 authentication of such identifiers (e.g., that the certificate
381 validation policy and trust anchors used by the channel satisfy
382 the application's requirements). To avoid implementation
383 difficulties in addressing this requirement, applications SHOULD
384 use cryptographic quantities as end-point channel bindings, such
385 as certificate-subject public keys.
387 o Applications that desire confidentiality protection MUST use
388 application-layer session protection services for confidentiality
389 protection when the bound channel does not provide confidentiality
394Williams Standards Track [Page 7]
396RFC 5056 On Channel Bindings November 2007
399 o The integrity of a secure channel MUST NOT be weakened should
400 their channel bindings be revealed to an attacker. That is, the
401 construction of the channel bindings for any type of secure
402 channel MUST NOT leak secret information about the channel. End-
403 point channel bindings, however, MAY leak information about the
404 end-points of the channel (e.g., their names).
406 o The channel binding operation MUST be at least integrity protected
407 in the security mechanism used at the application layer.
409 o Authentication frameworks and mechanisms that support channel
410 binding MUST communicate channel binding failure to applications.
412 o Applications MUST NOT send sensitive information, requiring
413 confidentiality protection, over the underlying channel prior to
414 completing the channel binding operation.
418 o End-point channel bindings where the end-points are meaningful
419 names SHOULD NOT be used when the channel does not provide
420 confidentiality protection and privacy protection is desired.
421 Alternatively, channels that export such channel bindings SHOULD
422 provide for the use of a digest and SHOULD NOT introduce new
423 digest/hash agility problems as a result.
427 o Authentication frameworks and mechanisms that support channel
428 binding MAY fail to establish authentication if channel binding
431 o Applications MAY send information over the underlying channel and
432 without integrity protection from the application-layer
433 authentication protocol prior to completing the channel binding
434 operation if such information requires only integrity protection.
435 This could be useful for optimistic negotiations.
437 o A security mechanism MAY exchange integrity-protected channel
440 o A security mechanism MAY exchange integrity-protected digests of
441 channel bindings. Such mechanisms SHOULD provide for hash/digest
444 o A security mechanism MAY use channel bindings in key exchange,
445 authentication, or key derivation, prior to the exchange of
446 "authenticator" messages.
450Williams Standards Track [Page 8]
452RFC 5056 On Channel Bindings November 2007
4552.2. EAP Channel Binding
457 This section is informative. This document does not update EAP
458 [RFC3748], it neither normatively describes, nor does it impose
459 requirements on any aspect of EAP or EAP methods.
461 EAP [RFC3748] includes a concept of channel binding described as
464 The communication within an EAP method of integrity-protected
465 channel properties such as endpoint identifiers which can be
466 compared to values communicated via out of band mechanisms (such
467 as via a AAA or lower layer protocol).
469 Section 7.15 of [RFC3748] describes the problem as one where a
470 Network Access Server (NAS) (a.k.a. "authenticator") may lie to the
471 peer (client) and cause the peer to make incorrect authorization
472 decisions (e.g., as to what traffic may transit through the NAS).
473 This is not quite like the purpose of generic channel binding (MITM
476 Section 7.15 of [RFC3748] calls for "a protected exchange of channel
477 properties such as endpoint identifiers" such that "it is possible to
478 match the channel properties provided by the authenticator via out-
479 of-band mechanisms against those exchanged within the EAP method".
481 This has sometimes been taken to be very similar to the generic
482 notion of channel binding provided here. However, there is a very
483 subtle difference between the two concepts of channel binding that
484 makes it much too difficult to put forth requirements and
485 recommendations that apply to both. The difference is about the
488 o In the generic channel binding case, the identities of either end
489 of this channel are irrelevant to anything other than the
490 construction of a name for that channel, in which case the
491 identities of the channel's end-points must be established a
494 o Whereas in the EAP case, the identity of the NAS end of the
495 channel, and even security properties of the channel itself, may
496 be established during or after authentication of the EAP peer to
499 In other words: there is a fundamental difference in mechanics
500 (timing of lower-layer channel establishment) and in purpose
501 (authentication of lower-layer channel properties for authorization
502 purposes vs. MITM detection).
506Williams Standards Track [Page 9]
508RFC 5056 On Channel Bindings November 2007
511 After some discussion we have concluded that there is no simple way
512 to obtain requirements and recommendations that apply to both generic
513 and EAP channel binding. Therefore, EAP is out of the scope of this
5163. Authentication and Channel Binding Semantics
518 Some authentication frameworks and/or mechanisms provide for channel
519 binding, such as the GSS-API and some GSS-API mechanisms, whereas
520 others may not, such as SASL (however, ongoing work is adding channel
521 binding support to SASL). Semantics may vary with respect to
522 negotiation, how the binding occurs, and handling of channel binding
525 Where suitable channel binding facilities are not provided,
526 application protocols MAY include a separate, protected exchange of
527 channel bindings. In order to do this, the application-layer
528 authentication service must provide message protection services (at
529 least integrity protection).
5313.1. The GSS-API and Channel Binding
533 The GSS-API [RFC2743] provides for the use of channel binding during
534 initialization of GSS-API security contexts, though GSS-API
535 mechanisms are not required to support this facility.
537 This channel binding facility is described in [RFC2743] and
540 GSS-API mechanisms must fail security context establishment when
541 channel binding fails, and the GSS-API provides no mechanism for the
542 negotiation of channel binding. As a result GSS-API applications
543 must agree a priori, through negotiation or otherwise, on the use of
546 Fortunately, it is possible to design GSS-API pseudo-mechanisms that
547 simply wrap around existing mechanisms for the purpose of allowing
548 applications to negotiate the use of channel binding within their
549 existing methods for negotiating GSS-API mechanisms. For example,
550 NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as
551 does the SSHv2 protocol [RFC4462]. Such pseudo-mechanisms are being
552 proposed separately, see [STACKABLE].
562Williams Standards Track [Page 10]
564RFC 5056 On Channel Bindings November 2007
5673.2. SASL and Channel Binding
569 SASL [RFC4422] does not yet provide for the use of channel binding
570 during initialization of SASL contexts.
572 Work is ongoing [SASL-GS2] to specify how SASL, particularly its new
573 bridge to the GSS-API, performs channel binding. SASL will likely
574 differ from the GSS-API in its handling of channel binding failure
575 (i.e., when there may be an MITM) in that channel binding
576 success/failure will only affect the negotiation of SASL security
577 layers. That is, when channel binding succeeds, SASL should select
578 no security layers, leaving session cryptographic protection to the
579 secure channel that SASL authentication has been bound to.
5814. Channel Bindings Specifications
583 Channel bindings for various types of secure channels are not
584 described herein. Some channel bindings specifications can be found
587 +--------------------+----------------------------------------------+
588 | Secure Channel | Reference |
590 +--------------------+----------------------------------------------+
595 | IPsec | There is no specification for IPsec channel |
596 | | bindings yet, but the IETF Better Than |
597 | | Nothing Security (BTNS) WG is working to |
598 | | specify IPsec channels, and possibly IPsec |
599 | | channel bindings. |
600 +--------------------+----------------------------------------------+
6024.1. Examples of Unique Channel Bindings
604 The following text is not normative, but is here to show how one
605 might construct channel bindings for various types of secure
608 For SSHv2 [RFC4251] the SSHv2 session ID should suffice as it is a
609 cryptographic binding of all relevant SSHv2 connection parameters:
610 key exchange and negotiation.
612 The TLS [RFC4346] session ID is simply assigned by the server. As
613 such, the TLS session ID does not have the required properties to be
614 useful as a channel binding because any MITM, posing as the server,
618Williams Standards Track [Page 11]
620RFC 5056 On Channel Bindings November 2007
623 can simply assign the same session ID to the victim client as the
624 server assigned to the MITM. Instead, the initial, unencrypted TLS
625 finished messages (the client's, the server's, or both) are
626 sufficient as they are the output of the TLS pseudo-random function,
627 keyed with the session key, applied to all handshake material.
6294.2. Examples of End-Point Channel Bindings
631 The following text is not normative, but is here to show how one
632 might construct channel bindings for various types of secure
635 For SSHv2 [RFC4251] the SSHv2 host public key, when present, should
636 suffice as it is used to sign the algorithm suite negotiation and
637 Diffie-Hellman key exchange; as long the client observes the host
638 public key that corresponds to the private host key that the server
639 used, then there cannot be an MITM in the SSHv2 connection. Note
640 that not all SSHv2 key exchanges use host public keys; therefore,
641 this channel bindings construction is not as useful as the one given
644 For TLS [RFC4346]the server certificate should suffice for the same
645 reasons as above. Again, not all TLS cipher suites involve server
646 certificates; therefore, the utility of this construction of channel
647 bindings is limited to scenarios where server certificates are
6505. Uses of Channel Binding
652 Uses for channel binding identified so far:
654 o Delegating session cryptographic protection to layers where
655 hardware can reasonably be expected to support relevant
656 cryptographic protocols:
658 * NFSv4 [RFC3530] with Remote Direct Data Placement (RDDP)
659 [NFS-DDP] for zero-copy reception where network interface
660 controllers (NICs) support RDDP. Cryptographic session
661 protection would be delegated to Encapsulating Security Payload
662 (ESP) [RFC4303] / Authentication Headers (AHs) [RFC4302].
664 * iSCSI [RFC3720] with Remote Direct Memory Access (RDMA)
665 [RFC5046]. Cryptographic session protection would be delegated
668 * HTTP with TLS [RFC2817] [RFC2818]. In situations involving
669 proxies, users may want to bind authentication to a TLS channel
670 between the last client-side proxy and the first server-side
674Williams Standards Track [Page 12]
676RFC 5056 On Channel Bindings November 2007
679 proxy ("concentrator"). There is ongoing work to expand the
680 set of choices for end-to-end authentication at the HTTP layer,
681 that, coupled with channel binding to TLS, would allow for
682 proxies while not forgoing protection over public internets.
684 o Reducing the number of live cryptographic contexts that an
685 application must maintain:
687 * NFSv4 [RFC3530] multiplexes multiple users onto individual
688 connections. Each user is authenticated separately, and users'
689 remote procedure calls (RPCs) are protected with per-user GSS-
690 API security contexts. This means that large timesharing
691 clients must often maintain many cryptographic contexts per-
692 NFSv4 connection. With channel binding to IPsec, they could
693 maintain a much smaller number of cryptographic contexts per-
694 NFSv4 connection, thus reducing memory pressure and
695 interactions with cryptographic hardware.
697 For example, applications that wish to use RDDP to achieve zero-copy
698 semantics on reception may use a network layer understood by NICs to
699 offload delivery of application data into pre-arranged memory
700 buffers. Note that in order to obtain zero-copy reception semantics
701 either application data has to be in cleartext relative to this RDDP
702 layer, or the RDDP implementation must know how to implement
703 cryptographic session protection protocols used at the application
706 There are a multitude of application-layer cryptographic session
707 protection protocols available. It is not reasonable to expect that
708 NICs should support many such protocols. Further, some application
709 protocols may maintain many cryptographic session contexts per-
710 connection (for example, NFSv4 does). It is thought to be simpler to
711 push the cryptographic session protection down the network stack (to
712 IPsec), and yet be able to produce NICs that offload other operations
713 (i.e., TCP/IP, ESP/AH, and DDP), than it would be to add support in
714 the NIC for the many session cryptographic protection protocols in
715 use in common applications at the application layer.
730Williams Standards Track [Page 13]
732RFC 5056 On Channel Bindings November 2007
735 The following figure shows how the various network layers are
738 +---------------------+
739 | Application layer |<---+
740 | |<-+ | In cleartext, relative
741 +---------------------+ | | to each other.
743 +---------------------+ |
745 +---------------------+ | Channel binding of app-layer
746 | ESP/AH |<-+ authentication to IPsec
747 +---------------------+
749 +---------------------+
751 +---------------------+
7536. Benefits of Channel Binding to Secure Channels
755 The use of channel binding to delegate session cryptographic
758 o Performance improvements by avoiding double protection of
759 application data in cases where IPsec is in use and applications
760 provide their own secure channels.
762 o Performance improvements by leveraging hardware-accelerated IPsec.
764 o Performance improvements by allowing RDDP hardware offloading to
765 be integrated with IPsec hardware acceleration.
767 Where protocols layered above RDDP use privacy protection, RDDP
768 offload cannot be done. Thus, by using channel binding to
769 IPsec, the privacy protection is moved to IPsec, which is
770 layered below RDDP. So, RDDP can address application protocol
771 data that's in cleartext relative to the RDDP headers.
773 o Latency improvements for applications that multiplex multiple
774 users onto a single channel, such as NFS with RPCSEC_GSS
777 Delegation of session cryptographic protection to IPsec requires
778 features not yet specified. There is ongoing work to specify:
780 o IPsec channels [CONN-LATCH];
786Williams Standards Track [Page 14]
788RFC 5056 On Channel Bindings November 2007
791 o Application programming interfaces (APIs) related to IPsec
792 channels [BTNS-IPSEC];
794 o Channel bindings for IPsec channels;
796 o Low infrastructure IPsec authentication [BTNS-CORE].
7987. IANA Considerations
800 IANA has created a new registry for channel bindings specifications
801 for various types of channels.
803 The purpose of this registry is not only to ensure uniqueness of
804 values used to name channel bindings, but also to provide a
805 definitive reference to technical specifications detailing each
806 channel binding available for use on the Internet.
808 There is no naming convention for channel bindings: any string
809 composed of US-ASCII alphanumeric characters, period ('.'), and dash
812 The procedure detailed in Section 7.1 is to be used for registration
813 of a value naming a specific individual mechanism.
8157.1. Registration Procedure
817 Registration of a new channel binding requires expert review as
818 defined in BCP 26 [RFC2434].
820 Registration of a channel binding is requested by filling in the
823 o Subject: Registration of channel binding X
825 o Channel binding unique prefix (name):
827 o Channel binding type: (One of "unique" or "end-point")
829 o Channel type: (e.g., TLS, IPsec, SSH, etc.)
831 o Published specification (recommended, optional):
833 o Channel binding is secret (requires confidentiality protection):
836 o Description (optional if a specification is given; required if no
837 published specification is specified):
842Williams Standards Track [Page 15]
844RFC 5056 On Channel Bindings November 2007
847 o Intended usage: (one of COMMON, LIMITED USE, or OBSOLETE)
849 o Person and email address to contact for further information:
851 o Owner/Change controller name and email address:
853 o Expert reviewer name and contact information: (leave blank)
855 o Note: (Any other information that the author deems relevant may be
858 and sending it via electronic mail to <channel-binding@ietf.org> (a
859 public mailing list) and carbon copying IANA at <iana@iana.org>.
860 After allowing two weeks for community input on the mailing list to
861 be determined, an expert will determine the appropriateness of the
862 registration request and either approve or disapprove the request
863 with notice to the requestor, the mailing list, and IANA.
865 If the expert approves registration, it adds her/his name to the
866 submitted registration.
868 The expert has the primary responsibility of making sure that channel
869 bindings for IETF specifications go through the IETF consensus
870 process and that prefixes are unique.
872 The review should focus on the appropriateness of the requested
873 channel binding for the proposed use, the appropriateness of the
874 proposed prefix, and correctness of the channel binding type in the
875 registration. The scope of this request review may entail
876 consideration of relevant aspects of any provided technical
877 specification, such as their IANA Considerations section. However,
878 this review is narrowly focused on the appropriateness of the
879 requested registration and not on the overall soundness of any
880 provided technical specification.
882 Authors are encouraged to pursue community review by posting the
883 technical specification as an Internet-Draft and soliciting comment
884 by posting to appropriate IETF mailing lists.
8867.2. Comments on Channel Bindings Registrations
888 Comments on registered channel bindings should first be sent to the
889 "owner" of the channel bindings and to the channel binding mailing
892 Submitters of comments may, after a reasonable attempt to contact the
893 owner, request IANA to attach their comment to the channel binding
894 type registration itself by sending mail to <iana@iana.org>. At
898Williams Standards Track [Page 16]
900RFC 5056 On Channel Bindings November 2007
903 IANA's sole discretion, IANA may attach the comment to the channel
904 bindings registration.
908 Once a channel bindings registration has been published by IANA, the
909 author may request a change to its definition. The change request
910 follows the same procedure as the registration request.
912 The owner of a channel bindings may pass responsibility for the
913 channel bindings to another person or agency by informing IANA; this
914 can be done without discussion or review.
916 The IESG may reassign responsibility for a channel bindings
917 registration. The most common case of this will be to enable changes
918 to be made to mechanisms where the author of the registration has
919 died, has moved out of contact, or is otherwise unable to make
920 changes that are important to the community.
922 Channel bindings registrations may not be deleted; mechanisms that
923 are no longer believed appropriate for use can be declared OBSOLETE
924 by a change to their "intended usage" field. Such channel bindings
925 will be clearly marked in the lists published by IANA.
927 The IESG is considered to be the owner of all channel bindings that
928 are on the IETF standards track.
9308. Security Considerations
932 Security considerations appear throughout this document. In
933 particular see Section 2.1.
935 When delegating session protection from one layer to another, one
936 will almost certainly be making some session security trade-offs,
937 such as using weaker cipher modes in one layer than might be used in
938 the other. Evaluation and comparison of the relative cryptographic
939 strengths of these is difficult, may not be easily automated, and is
940 far out of scope for this document. Implementors and administrators
941 should understand these trade-offs. Interfaces to secure channels
942 and application-layer authentication frameworks and mechanisms could
943 provide some notion of security profile so that applications may
944 avoid delegation of session protection to channels that are too weak
945 to match a required security profile.
947 Channel binding makes "anonymous" channels (where neither end-point
948 is strongly authenticated to the other) useful. Implementors should
949 avoid making it easy to use such channels without channel binding.
954Williams Standards Track [Page 17]
956RFC 5056 On Channel Bindings November 2007
959 The security of channel binding depends on the security of the
960 channels, the construction of their channel bindings, and the
961 security of the authentication mechanism used by the application and
962 its channel binding method.
964 Channel bindings should be constructed in such a way that revealing
965 the channel bindings of a channel to third parties does not weaken
966 the security of the channel. However, for end-point channel bindings
967 disclosure of the channel bindings may disclose the identities of the
9708.1. Non-Unique Channel Bindings and Channel Binding Re-Establishment
972 Application developers may be tempted to use non-unique channel
973 bindings for fast re-authentication following channel re-
974 establishment. Care must be taken to avoid the possibility of
975 attacks on multi-user systems.
977 Consider a user multiplexing protocol like NFSv4 using channel
978 binding to IPsec on a multi-user client. If another user can connect
979 directly to port 2049 (NFS) on some server using IPsec and merely
980 assert RPCSEC_GSS credential handles, then this user will be able to
981 impersonate any user authenticated by the client to the server. This
982 is because the new connection will have the same channel bindings as
983 the NFS client's! To prevent this, the server must require that at
984 least a host-based client principal, and perhaps all the client's
985 user principals, re-authenticate and perform channel binding before
986 the server will allow the clients to assert RPCSEC_GSS context
987 handles. Alternatively, the protocol could require a) that secure
988 channels provide confidentiality protection and b) that fast re-
989 authentication cookies be difficult to guess (e.g., large numbers
992 In other contexts there may not be such problems, for example, in the
993 case of application protocols that don't multiplex users over a
994 single channel and where confidentiality protection is always used in
1010Williams Standards Track [Page 18]
1012RFC 5056 On Channel Bindings November 2007
10179.1. Normative References
1019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1020 Requirement Levels", BCP 14, RFC 2119, March 1997.
10229.2. Informative References
1024 [BTNS-AS] Touch, J., Black, D., and Y. Wang, "Problem and
1025 Applicability Statement for Better Than Nothing Security
1026 (BTNS)", Work in Progress, October 2007.
1028 [BTNS-CORE] Richardson, M. and N. Williams, "Better-Than-Nothing-
1029 Security: An Unauthenticated Mode of IPsec", Work in
1030 Progress, September 2007.
1032 [BTNS-IPSEC] Richardson, M. and B. Sommerfeld, "Requirements for an
1033 IPsec API", Work in Progress, April 2006.
1035 [CONN-LATCH] Williams, N., "IPsec Channels: Connection Latching",
1036 Work in Progress, September 2007.
1038 [Lampson91] Lampson, B., Abadi, M., Burrows, M., and E. Wobber,
1039 "Authentication in Distributed Systems: Theory and
1040 Practive", October 1991.
1042 [NFS-DDP] Callaghan, B. and T. Talpey, "NFS Direct Data
1043 Placement", Work in Progress, July 2007.
1045 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
1046 RFC 1964, June 1996.
1048 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
1049 Specification", RFC 2203, September 1997.
1051 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
1052 Internet Protocol", RFC 2401, November 1998.
1054 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1055 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
1058 [RFC2743] Linn, J., "Generic Security Service Application Program
1059 Interface Version 2, Update 1", RFC 2743, January 2000.
1061 [RFC2744] Wray, J., "Generic Security Service API Version 2 :
1062 C-bindings", RFC 2744, January 2000.
1066Williams Standards Track [Page 19]
1068RFC 5056 On Channel Bindings November 2007
1071 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
1072 HTTP/1.1", RFC 2817, May 2000.
1074 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1076 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
1077 Beame, C., Eisler, M., and D. Noveck, "Network File
1078 System (NFS) version 4 Protocol", RFC 3530, April 2003.
1080 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
1081 and E. Zeidner, "Internet Small Computer Systems
1082 Interface (iSCSI)", RFC 3720, April 2004.
1084 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
1085 H. Levkowetz, "Extensible Authentication Protocol
1086 (EAP)", RFC 3748, June 2004.
1088 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
1089 Kerberos Network Authentication Service (V5)", RFC 4120,
1092 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
1093 Protocol Architecture", RFC 4251, January 2006.
1095 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
1096 Internet Protocol", RFC 4301, December 2005.
1098 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
1101 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
1102 4303, December 2005.
1104 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
1105 Security (TLS) Protocol Version 1.1", RFC 4346, April
1108 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
1109 Security Layer (SASL)", RFC 4422, June 2006.
1111 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
1112 "Generic Security Service Application Program Interface
1113 (GSS-API) Authentication and Key Exchange for the Secure
1114 Shell (SSH) Protocol", RFC 4462, May 2006.
1122Williams Standards Track [Page 20]
1124RFC 5056 On Channel Bindings November 2007
1127 [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah,
1128 H., and P. Thaler, "Internet Small Computer System
1129 Interface (iSCSI) Extensions for Remote Direct Memory
1130 Access (RDMA)", RFC 5046, October 2007.
1132 [SASL-GS2] Josefsson, S., "Using GSS-API Mechanisms in SASL: The
1133 GS2 Mechanism Family", Work in Progress, October 2007.
1135 [SSH-CB] Williams, N., "Channel Binding Identifiers for Secure
1136 Shell Channels", Work in Progress, November 2007.
1138 [STACKABLE] Williams, N., "Stackable Generic Security Service
1139 Pseudo-Mechanisms", Work in Progress, June 2006.
1141 [TLS-CB] Altman, J. and N. Williams, "Unique Channel Bindings for
1142 TLS", Work in Progress, November 2007.
1178Williams Standards Track [Page 21]
1180RFC 5056 On Channel Bindings November 2007
1183Appendix A. Acknowledgments
1185 Thanks to Mike Eisler for his work on the Channel Conjunction
1186 Mechanism document and for bringing the problem to a head, Sam
1187 Hartman for pointing out that channel binding provides a general
1188 solution to the channel binding problem, and Jeff Altman for his
1189 suggestion of using the TLS finished messages as the TLS channel
1190 bindings. Also, thanks to Bill Sommerfeld, Radia Perlman, Simon
1191 Josefsson, Joe Salowey, Eric Rescorla, Michael Richardson, Bernard
1192 Aboba, Tom Petch, Mark Brown, and many others.
1198 5300 Riata Trace Ct.
1202 EMail: Nicolas.Williams@sun.com
1234Williams Standards Track [Page 22]
1236RFC 5056 On Channel Bindings November 2007
1239Full Copyright Statement
1241 Copyright (C) The IETF Trust (2007).
1243 This document is subject to the rights, licenses and restrictions
1244 contained in BCP 78, and except as set forth therein, the authors
1245 retain all their rights.
1247 This document and the information contained herein are provided on an
1248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1250 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1251 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1252 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1255Intellectual Property
1257 The IETF takes no position regarding the validity or scope of any
1258 Intellectual Property Rights or other rights that might be claimed to
1259 pertain to the implementation or use of the technology described in
1260 this document or the extent to which any license under such rights
1261 might or might not be available; nor does it represent that it has
1262 made any independent effort to identify any such rights. Information
1263 on the procedures with respect to rights in RFC documents can be
1264 found in BCP 78 and BCP 79.
1266 Copies of IPR disclosures made to the IETF Secretariat and any
1267 assurances of licenses to be made available, or the result of an
1268 attempt made to obtain a general license or permission for the use of
1269 such proprietary rights by implementers or users of this
1270 specification can be obtained from the IETF on-line IPR repository at
1271 http://www.ietf.org/ipr.
1273 The IETF invites any interested party to bring to its attention any
1274 copyrights, patents or patent applications, or other proprietary
1275 rights that may cover technology that may be required to implement
1276 this standard. Please address the information to the IETF at
1290Williams Standards Track [Page 23]