On the Use of Channel Bindings to Secure Channels
Extracted elements (26)
EAP channel binding (RFC 3748 Section 7.15) is fundamentally different from the generic channel binding defined here. EAP addresses NAS authentication and authorization correctness, while generic channel binding addresses MITM detection; moreover, in EAP the identity of the lower-layer channel end-point may be established during or after authentication, whereas generic channel binding requires the lower-layer channel to be established a priori.
For SSHv2 end-point channel bindings, the host public key suffices because it is used to sign algorithm suite negotiation and the Diffie-Hellman key exchange; however, not all SSHv2 key exchanges use host public keys, limiting this construction's applicability. The SSHv2 session ID is preferable as a unique channel binding because it is a cryptographic binding of all relevant connection parameters.
The main goal of channel binding is to delegate cryptographic session protection to lower network layers (e.g., IPsec with hardware acceleration), reducing double-protection overhead, enabling zero-copy RDDP offloading, and reducing the number of live per-user cryptographic contexts that applications such as NFSv4 must maintain.
The TLS session ID is assigned by the server and is therefore not suitable as a unique channel binding, because an MITM posing as the server can assign the same session ID to a victim client. Instead, the initial unencrypted TLS finished messages (client's, server's, or both) are appropriate, as they are the output of the TLS pseudo-random function keyed with the session key applied to all handshake material.
SASL (as of RFC 4422) did not yet support channel binding during context initialization. Ongoing work (SASL-GS2) was expected to differ from GSS-API in that channel binding failure would only affect negotiation of SASL security layers: when channel binding succeeds, SASL should select no security layers and delegate session protection to the bound channel.
The GSS-API provides a channel binding facility during security context initialization, but GSS-API mechanisms are not required to support it. GSS-API mechanisms must fail security context establishment when channel binding fails, and the GSS-API provides no negotiation mechanism for channel binding; applications must agree a priori on its use.
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 protocol does not support channel binding but provides at least integrity protection, the application MUST use that integrity protection to exchange channel bindings or cryptographic hashes thereof.
Applications MUST NOT send sensitive information requiring confidentiality protection over the underlying channel prior to completing the channel binding operation.
Applications MUST verify that the same channel bindings are observed at either side of the channel, using an application-layer authentication protocol to authenticate one or both peers. If the authentication protocol supports channel binding, the application SHOULD use it.
Applications that desire confidentiality protection MUST use application-layer session protection services for confidentiality when the bound channel does not provide it. The integrity of a secure channel MUST NOT be weakened should its channel bindings be revealed to an attacker; i.e., the construction MUST NOT leak secret information about the channel.
End-point channel bindings MUST be bound into the secure channel and all its negotiations, including the initial key exchange and negotiation messages. When end-point channel bindings are identifiers requiring infrastructure authentication (e.g., PKI), applications MUST ensure the channel provides adequate authentication of such identifiers. Applications SHOULD prefer cryptographic quantities (e.g., certificate-subject public keys) as end-point channel bindings.
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. Channels that export such channel bindings SHOULD provide for the use of a digest and SHOULD NOT introduce new digest/hash agility problems.
Specifications of channel bindings for any secure channel 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 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.
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.
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 channel types is being bound. If nested instances of the same type of channel are available, then the innermost channel MUST be used.
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.
A channel binding registration template requires: channel binding unique prefix (name), type (unique or end-point), channel type (e.g., TLS, IPsec, SSH), published specification (recommended), whether the binding is secret, description, intended usage (COMMON/LIMITED USE/OBSOLETE), contact information, and owner/change controller. Registrations may not be deleted but may be marked OBSOLETE.
A 'secure channel' is defined as 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. The channel is assumed to be secure; if an attacker can successfully cryptanalyze its session keys, then the channel is not secure.
A security mechanism MAY exchange integrity-protected channel bindings or integrity-protected digests of channel bindings; digest-based 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.
'Channel binding' (noun) is 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. 'Channel bindings' (noun) is data that names a channel or its end-points such that showing it to be the same at both ends proves no MITM exists.
Unique channel bindings name a channel in a cryptographically secure manner and uniquely in time. End-point channel bindings name the authenticated end-points of a channel which are securely bound to the channel, but do not identify the channel uniquely in time.
IANA created a new registry for channel bindings specifications. The registry ensures uniqueness of channel binding name prefixes and provides a definitive reference to technical specifications. Names may be any string of US-ASCII alphanumeric characters, period ('.'), and dash ('-'). Registration requires expert review per BCP 26.
Channel binding makes anonymous channels (where neither end-point is strongly authenticated) useful, but implementors should avoid making it easy to use such channels without channel binding, as doing so would reintroduce the MITM vulnerability that channel binding is designed to prevent.
The security of channel binding depends on the security of the channels, the construction of their channel bindings, and the security of the authentication mechanism and its channel binding method. Delegating session protection involves cryptographic trade-offs (e.g., weaker cipher modes); implementors and administrators should understand these trade-offs and interfaces SHOULD expose a security profile concept.
Using non-unique (end-point) channel bindings for fast re-authentication after channel re-establishment can enable impersonation attacks on multi-user systems. In a scenario like NFSv4 over IPsec on a multi-user client, a second user connecting to the same server port would share the same channel bindings and could assert credential handles belonging to other users; the server must require re-authentication before accepting asserted context handles.