RFC 5056
On the Use of Channel Bindings to Secure Channels
RFC 5056: On the Use of Channel Bindings to Secure Channels 🎀
Title block tea ☕: this is RFC 5056 💅, written by N. Williams from Sun. It's a Standards Track doc, which means it's an actual Internet standards-track protocol thing 👑. It's dated November 2007 🍓. The title block doesn't list anything it obsoletes or updates, so it's its own little lane 🦋.
Status of This Memo ✨
Okay so this doc is an Internet standards track protocol for the whole Internet community 🌐, and it's literally asking you to chat about it and send suggestions for making it better 💬. For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. And distribution of this memo is unlimited 🫶.
Abstract 🦋
So the big idea is channel binding 💖. It lets apps prove that the two end-points of a secure channel at one network layer are the same two end-points they authenticated at a higher layer. You do that by tying the higher-layer authentication to the lower-layer channel 🔗. The payoff? Apps can hand session protection off to the lower layers, and that comes with a bunch of performance benefits 🔥.
This document digs into channel binding for secure channels and formalizes the whole concept 🧠.
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 .......................................221. Introduction 💫
Bestie, there are tons of situations where an app wants to do its own authentication up at the application layer 🙋♀️, but also wants to use session or transport security from a lower network layer 🔐. Take IPsec [RFC4301] [RFC4303] [RFC4302]. It's super accelerable in hardware for really high link speeds ⚡, but IPsec key exchange protocols and the IPsec architecture aren't that easy to use as a security mechanism inside applications 🙃. That's especially true when the apps have users as clients 👩💻. So combining security at both layers is honestly kind of attractive 😍.
But here's the catch 🙈: to do that securely, you have to "bind" the mechanisms together. That's how you avoid man-in-the-middle vulnerabilities and get everything integrated in a seamless way 🧵. This is the whole goal of "Channel Bindings" 🎯.
The term "channel binding" in this document comes from the Generic Security Service Application Program Interface (GSS-API) [RFC2743] 🧩. GSS-API has a channel binding facility that was meant for binding GSS-API authentication to secure channels at lower network layers. Tea spill: the purpose and benefits of that facility weren't really discussed in depth, and some details were left unspecified 🤷♀️. But now we see this concept can be super useful, so we start with a generalization and formalization of "channel binding" that doesn't depend on GSS-API 🦋.
Even though it's inspired by and derived from GSS-API, the channel binding idea here is NOT limited to GSS-API apps 🙅♀️. We picture apps using channel binding with other security frameworks too, like Simple Authentication and Security Layer (SASL) [RFC4422] 🎀. We also picture it working with protocols that bring their own authentication mechanisms, like the Key Distribution Center (KDC) exchanges of Kerberos V [RFC4120] 🗝️. And we see the notion of channel binding being useful when analyzing security protocols too 🔬.
The main goal of channel binding is to delegate cryptographic session protection to network layers below the application 🏗️. The hope is that you can better leverage hardware implementations of cryptographic protocols ⚙️. Section 5 describes some intended uses of channel binding 📖. Also, some apps may benefit from having less active cryptographic state 🧹. That means less overhead when accessing that state, and so less impact of security on latency 🏎️.
The critical security problem to solve for this kind of delegation is making sure there's no man-in-the-middle (MITM), from the point of view of the application, at the lower network layer where session protection is being delegated 🚨. That's the boss-level problem, no cap 👑.
There may well be an MITM 👀. This is especially likely if the lower network layer provides no authentication, or if there's no strong connection between the authentication or principals used at the application and the ones used at the lower network layer 😬.
Even if MITM attacks seem really hard to pull off 🥷, they still have to be prevented for certain apps to make effective use of things like IPsec [RFC2401] [RFC4301] or HTTP with TLS [RFC4346] in certain contexts 🔒. Examples are when there's no authentication to speak of, or when one node's set of trust anchors is too weak to believe it can authenticate its peers 🫠. Also, secure channels that are open to MITM attacks because they give no useful end-point authentication are still useful when they're combined with application-layer authentication 🤝. Otherwise they're only kinda "better than nothing" 🙃. See Better Than Nothing Security (BTNS) [BTNS-AS] for the tea on that 🍵.
For example, Internet Small Computer Systems Interface (iSCSI) [RFC3720] 💾 provides application-layer authentication (say, using Kerberos V), but it relies on IPsec for transport protection 😤. iSCSI doesn't provide a binding between the two. So iSCSI initiators have to be careful to make sure the name of the server authenticated at the application layer and the name of the peer at the IPsec layer match. That's basically an informal form of channel binding 🫣.
This document describes a solution ✨: use "channel binding" to bind authentication at application layers to secure sessions at lower layers in the network stack 🎀💖.
1.1. Conventions Used in This Document 📝
Here's the fine print 🤓. 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] 📜.
2. Definitions 📚
Okay, now the vocab list 💅. Pay attention, because these terms get used a lot.
- Secure channel: a packet, datagram, octet stream connection, or sequence of connections between two end-points that affords cryptographic integrity and, optionally, confidentiality to data exchanged over it 🔐. We assume the channel is secure. If an attacker can successfully cryptanalyze a channel's session keys, for example, then the channel is not secure 💀.
- Channel binding: the process of establishing that no man-in-the-middle exists between two end-points that have been authenticated at one network layer but are using a secure channel at a lower network layer 🔗. This term is used as a noun ✍️.
- Channel bindings: [See historical note below.] 🕰️
Generally, some data that "names" a channel or one or both of 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 🏷️. This term is used as a noun ✍️.
More formally, there are two types of channel bindings 🧐:
- unique channel bindings: channel bindings that name a channel in a cryptographically secure manner and uniquely in time 🦄.
- end-point channel bindings: channel bindings that name the authenticated end-points, or even a single end-point, of a channel. Those are, in turn, securely bound to the channel, but they do not identify a channel uniquely in time ⏳.
- Cryptographic binding: (e.g., "cryptographically bound") a cryptographic operation that causes an object, such as a private encryption or signing key, or an established secure channel, to "speak for" [Lampson91] some principal, such as a user, a computer, etcetera 🪪. For example, a Public Key Infrastructure for X.509 Certificates (PKIX) certificate binds a private key to the name of a principal in the trust domain of the certificate's issuer. That way, a possessor of said private key can act on behalf of the user (or other entity) named by the certificate 🔑.
Cryptographic bindings are generally asymmetric in nature (not to be confused with symmetric or asymmetric key cryptography). An object is rendered capable of standing for another, but the reverse usually isn't the case. We don't say that a user speaks for their private keys, but we do say that the user's private keys speak for the user 🫵.
Note that there may be many instances of "cryptographic binding" in an application of channel binding 🔁. The credentials that authenticate principals at the application layer bind private or secret keys to the identities of those principals, so the keys speak for them 🗣️. A secure channel typically consists of symmetric session keys used to provide confidentiality and integrity protection to data sent over the channel. Each end-point's session keys speak for that end-point of the channel 🤙. Finally, each end-point of a channel bound to authentication at the application layer speaks for the principal authenticated at the application layer on the same side of the channel 🫶.
The terms defined above have been in use for many years, and they've been taken to mean, at least in some contexts, what's stated below. Unfortunately, this means "channel binding" can refer to the channel binding operation and, sometimes, to the name of a channel. Meanwhile "channel bindings" (a difference of only one letter 😭) generally refers to the name of a channel 🙃.
Note that the Extensible Authentication Protocol (EAP) [RFC3748] uses "channel binding" to refer to a facility that may look similar to the one described here, but it's actually quite different 🙅♀️. See Section 2.2 for more details 📖.
2.1. Properties of Channel Binding ✨
okay so, applications, authentication frameworks (like the GSS-API and SASL), security mechanisms (like the Kerberos V GSS-API mechanism [RFC1964]), and secure channels all need to hit the requirements and should follow the recommendations below 💅
Requirements:
- In order to use channel binding, applications MUST verify that the same channel bindings are observed at either side of the channel. To do this, the application MUST use an authentication protocol at the application layer to authenticate one, the other, or both application peers (one at each end of the channel). 🔥
- If the authentication protocol used by the application supports channel binding, the application SHOULD use it. 💖
- An authentication protocol that supports channel binding MUST provide an input slot in its API for a "handle" to the channel, or its channel bindings. 🎀
- If the authentication protocol does not support a channel binding operation, but provides a "security layer" with at least integrity protection, then the application MUST use the authentication protocol's integrity protection facilities to exchange channel bindings, or cryptographic hashes thereof. 🦋
- The name of the type of channel binding MUST be used by the application and/or authentication protocol to avoid ambiguity about which of several possible types of channels is being bound. If nested instances of the same type of channel are available, then the innermost channel MUST be used. 👑
- Specifications of channel bindings for any secure channels MUST provide for a single, canonical octet string encoding of the channel bindings. Under this framework, channel bindings MUST start with the channel binding unique prefix followed by a colon (ASCII
0x3A). 🌸 - The channel bindings for a given type of secure channel MUST be constructed in such a way that an MITM could not easily force the channel bindings of a given channel to match those of another. 🙈
- Unique channel bindings MUST bind not only the key exchange for the secure channel, but also any negotiations and authentication that may have taken place to establish the channel. ✨
- End-point channel bindings MUST be bound into the secure channel and all its negotiations. For example, a public key as an end-point channel binding should be used to verify a signature of such negotiations (or to encrypt them), including the initial key exchange and negotiation messages for that channel -- such a key would then be bound into the channel. A certificate name as end-point channel binding could also be bound into the channel in a similar way, though in the case of a certificate name, the binding also depends on the strength of the authentication of that name (that is, the validation of the certificate, the trust anchors, the algorithms used in the certificate path construction and validation, etcetera). 🧚
- End-point channel bindings MAY be identifiers (e.g., certificate names) that must be authenticated through some infrastructure, such as a public key infrastructure (PKI). In such cases, applications MUST ensure that the channel provides adequate authentication of such identifiers (e.g., that the certificate validation policy and trust anchors used by the channel satisfy the application's requirements). To avoid implementation difficulties in addressing this requirement, applications SHOULD use cryptographic quantities as end-point channel bindings, such as certificate-subject public keys. 🫶
- Applications that desire confidentiality protection MUST use application-layer session protection services for confidentiality protection when the bound channel does not provide confidentiality protection. 🔒
- The integrity of a secure channel MUST NOT be weakened should their channel bindings be revealed to an attacker. That is, the construction of the channel bindings for any type of secure channel MUST NOT leak secret information about the channel. End-point channel bindings, however, MAY leak information about the end-points of the channel (e.g., their names). 😭
- The channel binding operation MUST be at least integrity protected in the security mechanism used at the application layer. 💅
- Authentication frameworks and mechanisms that support channel binding MUST communicate channel binding failure to applications. 🚨
- Applications MUST NOT send sensitive information, requiring confidentiality protection, over the underlying channel prior to completing the channel binding operation. 🙅♀️
Recommendations:
- End-point channel bindings where the end-points are meaningful names SHOULD NOT be used when the channel does not provide confidentiality protection and privacy protection is desired. Alternatively, channels that export such channel bindings SHOULD provide for the use of a digest and SHOULD NOT introduce new digest/hash agility problems as a result. 🌈
Options:
- Authentication frameworks and mechanisms that support channel binding MAY fail to establish authentication if channel binding fails. 🍓
- Applications MAY send information over the underlying channel and without integrity protection from the application-layer authentication protocol prior to completing the channel binding operation if such information requires only integrity protection. This could be useful for optimistic negotiations. 🦋
- A security mechanism MAY exchange integrity-protected channel bindings. 💜
- A security mechanism MAY exchange integrity-protected digests of channel bindings. Such mechanisms SHOULD provide for hash/digest agility. ⭐
- A security mechanism MAY use channel bindings in key exchange, authentication, or key derivation, prior to the exchange of "authenticator" messages. 🎀
2.2. EAP Channel Binding ✨
This section is informative. This document does not update EAP [RFC3748], it neither normatively describes, nor does it impose requirements on any aspect of EAP or EAP methods. 🌸
EAP [RFC3748] includes a concept of channel binding described as follows:
The communication within an EAP method of integrity-protected channel properties such as endpoint identifiers which can be compared to values communicated via out of band mechanisms (such as via a AAA or lower layer protocol).
Section 7.15 of [RFC3748] describes the problem as one where a Network Access Server (NAS) (a.k.a. "authenticator") may lie to the peer (client) and cause the peer to make incorrect authorization decisions (e.g., as to what traffic may transit through the NAS). This is not quite like the purpose of generic channel binding (MITM detection). 🙈
Section 7.15 of [RFC3748] calls for "a protected exchange of channel properties such as endpoint identifiers" such that "it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method". 💀
This has sometimes been taken to be very similar to the generic notion of channel binding provided here. However, there is a very subtle difference between the two concepts of channel binding that makes it much too difficult to put forth requirements and recommendations that apply to both. The difference is about the lower-layer channel: 🧐
- In the generic channel binding case, the identities of either end of this channel are irrelevant to anything other than the construction of a name for that channel, in which case the identities of the channel's end-points must be established a priori.
- Whereas in the EAP case, the identity of the NAS end of the channel, and even security properties of the channel itself, may be established during or after authentication of the EAP peer to the EAP server.
In other words: there is a fundamental difference in mechanics (timing of lower-layer channel establishment) and in purpose (authentication of lower-layer channel properties for authorization purposes vs. MITM detection). 🦋
After some discussion we have concluded that there is no simple way to obtain requirements and recommendations that apply to both generic and EAP channel binding. Therefore, EAP is out of the scope of this document. 🚫
3. Authentication and Channel Binding Semantics 👑
Some authentication frameworks and/or mechanisms provide for channel binding, such as the GSS-API and some GSS-API mechanisms, whereas others may not, such as SASL (however, ongoing work is adding channel binding support to SASL). Semantics may vary with respect to negotiation, how the binding occurs, and handling of channel binding failure (see below). 🌈
Where suitable channel binding facilities are not provided, application protocols MAY include a separate, protected exchange of channel bindings. In order to do this, the application-layer authentication service must provide message protection services (at least integrity protection). 🎀
3.1. The GSS-API and Channel Binding 🧚
The GSS-API [RFC2743] provides for the use of channel binding during initialization of GSS-API security contexts, though GSS-API mechanisms are not required to support this facility. 💅
This channel binding facility is described in [RFC2743] and [RFC2744]. 📖
GSS-API mechanisms must fail security context establishment when channel binding fails, and the GSS-API provides no mechanism for the negotiation of channel binding. As a result GSS-API applications must agree a priori, through negotiation or otherwise, on the use of channel binding. 😬
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 binding 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 [RFC4462]. Such pseudo-mechanisms are being proposed separately, see [STACKABLE]. 🫶
3.2. SASL and Channel Binding 🍓
SASL [RFC4422] does not yet provide for the use of channel binding during initialization of SASL contexts. 🥺
Work is ongoing [SASL-GS2] to specify how SASL, particularly its 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 an MITM) in that channel binding success/failure will only affect the negotiation of SASL security layers. That is, when channel binding succeeds, SASL should select no security layers, leaving session cryptographic protection to the secure channel that SASL authentication has been bound to. ✨
4. Channel Bindings Specifications 🎀
okay so the channel binding specs for different secure channels aren't actually written up in this doc 🙈 bestie, you'll find the good stuff in these places:
+--------------------+----------------------------------------------+
| Secure Channel | Reference |
| Type | |
+--------------------+----------------------------------------------+
| SSHv2 | [SSH-CB] |
| | |
| TLS | [TLS-CB] |
| | |
| IPsec | There is no specification for IPsec channel |
| | bindings yet, but the IETF Better Than |
| | Nothing Security (BTNS) WG is working to |
| | specify IPsec channels, and possibly IPsec |
| | channel bindings. |
+--------------------+----------------------------------------------+IPsec is still a work in progress, so don't expect a finished spec there yet 🦋
4.1. Examples of Unique Channel Bindings
this part is not normative 🌸 it's just here to show how you might build channel bindings for different secure channels.
For SSHv2 [RFC4251], the SSHv2 session ID should suffice 💖 it's a cryptographic binding of all the relevant SSHv2 connection parameters: key exchange and negotiation.
The TLS [RFC4346] session ID is just assigned by the server 😭 so it doesn't have the properties you need to be useful as a channel binding. Any MITM posing as the server can simply hand the victim client the same session ID that the server assigned to the MITM. Instead, the initial, unencrypted TLS finished messages (the client's, the server's, or both) are sufficient. They're the output of the TLS pseudo-random function, keyed with the session key, applied to all the handshake material ✨
4.2. Examples of End-Point Channel Bindings
same energy here: this part is not normative 🧚 it just shows how you might build channel bindings.
For SSHv2 [RFC4251], the SSHv2 host public key, when it's present, should suffice 🔥 it's used to sign the algorithm suite negotiation and the Diffie-Hellman key exchange. As long as the client observes the host public key that corresponds to the private host key the server used, then there cannot be an MITM in the SSHv2 connection. Note that not all SSHv2 key exchanges use host public keys, so this construction is not as useful as the one in Section 4.1 🙈
For TLS [RFC4346]the server certificate should suffice for the same reasons as above 🌈 again, not all TLS cipher suites involve server certificates, so this construction is only really useful in scenarios where server certificates are commonly used.
5. Uses of Channel Binding 👑
okay, here are the uses for channel binding identified so far 💅
- Delegating session cryptographic protection to layers where hardware can reasonably be expected to support the relevant cryptographic protocols:
- NFSv4 [RFC3530] with Remote Direct Data Placement (RDDP) [NFS-DDP] for zero-copy reception, where network interface controllers (NICs) support RDDP. Cryptographic session protection would be delegated to Encapsulating Security Payload (ESP) [RFC4303] / Authentication Headers (AHs) [RFC4302].
- iSCSI [RFC3720] with Remote Direct Memory Access (RDMA) [RFC5046]. Cryptographic session protection would be delegated to ESP/AH.
- HTTP with TLS [RFC2817] [RFC2818]. In situations involving proxies, users may want to bind authentication to a TLS channel between the last client-side proxy and the first server-side proxy ("concentrator"). There is ongoing work to expand the set of choices for end-to-end authentication at the HTTP layer, which, coupled with channel binding to TLS, would allow for proxies while not forgoing protection over public internets 🦋
- Reducing the number of live cryptographic contexts that an application must maintain:
- NFSv4 [RFC3530] multiplexes multiple users onto individual connections. Each user is authenticated separately, and users' remote procedure calls (RPCs) are protected with per-user GSS-API security contexts. This means large timesharing clients must often maintain many cryptographic contexts per NFSv4 connection. With channel binding to IPsec, they could maintain a much smaller number of cryptographic contexts per NFSv4 connection, which means less memory pressure and fewer interactions with cryptographic hardware ✨
For example, applications that want to use RDDP to get zero-copy semantics on reception may use a network layer that NICs understand, to offload delivery of application data into pre-arranged memory buffers. Note that to get zero-copy reception semantics, either the application data has to be in cleartext relative to this RDDP layer, or the RDDP implementation must know how to implement the cryptographic session protection protocols used at the application layer 🫶
There are a multitude of application-layer cryptographic session protection protocols available 🌸 it's not reasonable to expect NICs to support many of them. Also, some application protocols may maintain many cryptographic session contexts per connection (NFSv4 does, for example). It's thought to be simpler to push the cryptographic session protection down the network stack (to IPsec) and still be able to produce NICs that offload other operations (i.e., TCP/IP, ESP/AH, and DDP), than to add support in the NIC for the many session cryptographic protection protocols in use in common applications at the application layer 💜
The following figure shows how the various network layers are related:
+---------------------+
| Application layer |<---+
| |<-+ | In cleartext, relative
+---------------------+ | | to each other.
| RDDP |<---+
+---------------------+ |
| TCP/SCTP |<-+
+---------------------+ | Channel binding of app-layer
| ESP/AH |<-+ authentication to IPsec
+---------------------+
| IP |
+---------------------+
| ... |
+---------------------+6. Benefits of Channel Binding to Secure Channels 🍓
so the benefits of using channel binding to delegate session cryptographic protection are:
- Performance improvements by avoiding double protection of application data in cases where IPsec is in use and applications provide their own secure channels.
- Performance improvements by leveraging hardware-accelerated IPsec.
- 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. So, by using channel binding to IPsec, the privacy protection is moved to IPsec, which is layered below RDDP. That means RDDP can address application protocol data that's in cleartext relative to the RDDP headers 🧚
- Latency improvements for applications that multiplex multiple users onto a single channel, such as NFS with RPCSEC_GSS [RFC2203].
Delegating session cryptographic protection to IPsec requires features that aren't specified yet 😭 there's ongoing work to specify:
- IPsec channels [CONN-LATCH];
- Application programming interfaces (APIs) related to IPsec channels [BTNS-IPSEC];
- Channel bindings for IPsec channels;
- Low infrastructure IPsec authentication [BTNS-CORE].
7. IANA Considerations 💖
IANA has created a new registry for channel bindings specifications for various types of channels 🦋
The purpose of this registry is not only to make sure the values used to name channel bindings are unique, but also to give a definitive reference to technical specifications that detail each channel binding available for use on the Internet ✨
There is no naming convention for channel bindings: any string made up of US-ASCII alphanumeric characters, period ('.'), and dash ('-') will do 🌈
The procedure in Section 7.1 is to be used for registering a value that names a specific individual mechanism.
7.1. Registration Procedure
registering a new channel binding requires expert review as defined in BCP 26 [RFC2434] 👑
To request registration of a channel binding, fill in the following template 💅
- Subject: Registration of channel binding X
- Channel binding unique prefix (name):
- Channel binding type: (One of "unique" or "end-point")
- Channel type: (e.g., TLS, IPsec, SSH, etc.)
- Published specification (recommended, optional):
- Channel binding is secret (requires confidentiality protection): yes/no
- Description (optional if a specification is given; required if no published specification is specified):
- Intended usage: (one of COMMON, LIMITED USE, or OBSOLETE)
- Person and email address to contact for further information:
- Owner/Change controller name and email address:
- Expert reviewer name and contact information: (leave blank)
- Note: (Any other information that the author deems relevant may be added here.)
then send it by electronic mail to <channel-binding@ietf.org> (a public mailing list) and carbon copy IANA at <iana@iana.org> 📬 after allowing two weeks for community input on the mailing list, an expert will determine whether the registration request is appropriate, and will either approve or disapprove it with notice to the requestor, the mailing list, and IANA 🫶
If the expert approves the registration, they add their name to the submitted registration.
The expert has the main responsibility of making sure that channel bindings for IETF specifications go through the IETF consensus process and that prefixes are unique 🔥
The review should focus on the appropriateness of the requested channel binding for the proposed use, the appropriateness of the proposed prefix, and the correctness of the channel binding type in the registration. The review may consider relevant aspects of any provided technical specification, such as its IANA Considerations section. However, this review is narrowly focused on whether the requested registration is appropriate, not on the overall soundness of any provided technical specification 🙈
Authors are encouraged to pursue community review by posting the technical specification as an Internet-Draft and soliciting comment by posting to appropriate IETF mailing lists 🌸
7.2. Comments on Channel Bindings Registrations
comments on registered channel bindings should first be sent to the "owner" of the channel binding and to the channel binding mailing list 💜
Submitters of comments may, after a reasonable attempt to contact the owner, ask IANA to attach their comment to the channel binding type registration itself, by sending mail to <iana@iana.org>. At IANA's sole discretion, IANA may attach the comment to the channel bindings registration 🧚
7.3. Change Control ✨
okay so once IANA publishes a channel bindings registration, the author can ask for a change to its definition 📝 The change request follows the same procedure as the original registration request 💅
the owner of a channel bindings can pass responsibility to another person or agency just by telling IANA 🫶 no discussion or review needed, which is lowkey so convenient
the IESG may reassign responsibility for a channel bindings registration 👑 the most common reason is when the registration's author has died, has moved out of contact, or is otherwise unable to make changes that matter to the community 😭 that's when someone else steps in so the mechanism can still get the updates it needs
channel bindings registrations may not be deleted 🙅♀️ instead, a mechanism that's no longer believed appropriate for use can be declared OBSOLETE by changing its "intended usage" field 🪦 those channel bindings get clearly marked in the lists IANA publishes, so everyone can see what's retired 👀
and finally, the IESG is considered to be the owner of all channel bindings that are on the IETF standards track 🎀
8. Security Considerations 🔥
okay this section is seriously important bestie 💀 security considerations show up all throughout this document, but the big one to look at is Section 2.1 🙈
when you delegate session protection from one layer to another, you're almost guaranteed to be making some session security trade-offs 😬 like maybe using weaker cipher modes in one layer than you'd use in the other. figuring out how strong each option is compared to the others is hard, might not be easy to automate, and is way out of scope for this document 🫠 implementors and administrators should really understand these trade-offs 💜 interfaces to secure channels and application-layer authentication frameworks and mechanisms could offer some kind of security profile, so applications can avoid handing session protection off to channels that are too weak to meet a required security profile ✨
channel binding is what makes "anonymous" channels (where neither end-point is strongly authenticated to the other) actually useful 🦋 implementors should avoid making it easy to use those channels without channel binding 🙅♀️
the security of channel binding depends on the security of the channels 🔐, how their channel bindings are constructed 🧱, and the security of the authentication mechanism the application uses along with its channel binding method 🫶
channel bindings should be built so that revealing a channel's channel bindings to third parties doesn't weaken the security of the channel 🌸 however, with end-point channel bindings, disclosing them may reveal the identities of the peers 😭 so watch out for that one!!
8.1. Non-Unique Channel Bindings and Channel Binding Re-Establishment 💅
application developers might be tempted to use non-unique channel bindings for fast re-authentication after a channel is re-established 🏃♀️ but you have to be careful to avoid attacks on multi-user systems 🚨
picture a user multiplexing protocol like NFSv4 that uses channel binding to IPsec on a multi-user client 🧚 if another user can connect directly to port 2049 (NFS) on some server using IPsec and simply asserts RPCSEC_GSS credential handles, that user can impersonate any user authenticated by the client to the server 💀 why? because the new connection has the same channel bindings as the NFS client's!! iconic behavior, not in a good way 🙈
to prevent this, the server must require that at least a host-based client principal, and maybe all of the client's user principals, re-authenticate and perform channel binding before the server will let the clients assert RPCSEC_GSS context handles 🔒 another option is for the protocol to require a) that secure channels provide confidentiality protection and b) that fast re-authentication cookies be difficult to guess (for example, large numbers selected randomly) 🎲
in other contexts there may not be these problems 🌈 for example, with application protocols that don't multiplex users over a single channel, and where confidentiality protection is always used in the secure channel 🫶
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
- [BTNS-AS] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Work in Progress, October 2007.
- [BTNS-CORE] Richardson, M. and N. Williams, "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", Work in Progress, September 2007.
- [BTNS-IPSEC] Richardson, M. and B. Sommerfeld, "Requirements for an IPsec API", Work in Progress, April 2006.
- [CONN-LATCH] Williams, N., "IPsec Channels: Connection Latching", Work in Progress, September 2007.
- [Lampson91] Lampson, B., Abadi, M., Burrows, M., and E. Wobber, "Authentication in Distributed Systems: Theory and Practive", October 1991.
- [NFS-DDP] Callaghan, B. and T. Talpey, "NFS Direct Data Placement", Work in Progress, July 2007.
- [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
- [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [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.
- [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
- [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 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.
- [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
- [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.
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
- [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
- [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006.
- [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007.
- [SASL-GS2] Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Work in Progress, October 2007.
- [SSH-CB] Williams, N., "Channel Binding Identifiers for Secure Shell Channels", Work in Progress, November 2007.
- [STACKABLE] Williams, N., "Stackable Generic Security Service Pseudo-Mechanisms", Work in Progress, June 2006.
- [TLS-CB] Altman, J. and N. Williams, "Unique Channel Bindings for TLS", Work in Progress, November 2007.
Appendix A. Acknowledgments 🌷
huge thank yous to Mike Eisler for his work on the Channel Conjunction Mechanism document and for bringing the problem to a head 👏 Sam Hartman for pointing out that channel binding provides a general solution to the channel binding problem 💜 and Jeff Altman for suggesting the use of the TLS finished messages as the TLS channel bindings ✨ also thanks to Bill Sommerfeld, Radia Perlman, Simon Josefsson, Joe Salowey, Eric Rescorla, Michael Richardson, Bernard Aboba, Tom Petch, Mark Brown, and many others 🫶
Author's Address 📮
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct.
Austin, TX 78727
US
EMail: Nicolas.Williams@sun.comFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property 🦋
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. 💖
📦 where this page comes from
- ietf: rfc5056 2007-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms