Overview#
Channel Binding (RFC 5056) is a concept that allows applications to establish that the two end-points of a Secure connection at one Communication Layers are the same as at a higher Communication Layers by binding authentication at the higher Communication Layers to the channel at the Communication Layer.Channel Binding allows applications to delegate session protection to lower layers, which has various performance benefits.
The term "Channel Binding" was derived from the Generic Security Service Application Program Interface (GSSAPI) RFC 2743, which has a Channel Binding facility that was intended for binding GSSAPI authentication to Secure connections at lower network layers.
Channel Bindings for TLS (RFC 5929) defines three channel binding types for Transport Layer Security (TLS)
Microsoft Channel Binding#
Microsoft Channel Binding is a part of Microsoft's Extended Protection for Authentication and ADV190023Consider a scenario with three participants:
- a client
- a server - https://server
- attacker - https://attacker
without Channel Binding this can happen when a client application authenticates itself to the server using Kerberos, Digest SSP, or NTLM using HTTPS, a Transport Layer Security (TLS) channel is first established and authentication as the server has no method to detect that there is a Man-In-The-Middle (MiTM).
With Channel Binding, a property of the Transport Layer Security (TLS)-secured outer channel is used to create a "token" (Channel Binding Token or CBT) which is used in the authentication session the server.
A CBT aware server compares the CBT contained in the client authentication information, which MUST match the server's first communication between the Client-Server Exchange over Transport Layer Security (TLS).
Although referred to as LDAP Channel Binding is not LDAPv3 or an LDAP Specification, but tied to tokens generated and used ONLY by Microsoft Windows, over LDAP.
Channel Binding Token (CBT) is a property of the outer Secure connection (such as TLS) used to tie (bind) it to a conversation over an inner, client-authenticated channel. The Channel Binding Token MUST have the following properties (also defined by RFC 5056):
- When an outer channel exists, the value of the Channel Binding Token must be a property identifying either the outer Secure connection or the server endpoint, independently arrived at by both client and server sides of a Communication.
- Value of the Channel Binding Token sent by the client MUST NOT be something an attacker can influence.
- Confidentiality - No guarantees are made about Confidentiality of the Channel Binding Token value. This does not however mean that the value of the Channel Binding Token can always be examined by any other but the server performing authentication, as the protocol carrying the Channel Binding Token may be encrypting it.
- integrity The Channel Binding Token MUST be Cryptographic integrity protected in transit such that an attacker cannot insert, remove or modify its value.
Channel Binding is accomplished by the client transferring the ServicePrincipalName(SPN) and the Channel Binding Token to the server in a Cryptographic integrity protected fashion. The server validates the Channel Binding information in accordance with its policy and rejects authentication attempts for which it does not believe itself to have been the intended target. This way, the two channels become cryptographic bound together.
Microsoft Channel Binding affects Secure connection using Transport Layer Security (TLS) non-Windows Implementations and not patched Microsoft Windows when using Kerberos, Digest SSP, or NTLM using HTTPS.
The AV_PAIR structure defines an Attribute Value pair that ties the authentication data to a particular "channel" via a hash of things like IP Address and TCP/UDP port numbers.
The Sequences of AV_PAIR structures are defined in the NT LAN Manager Authentication Protocol and used in the CHALLENGE_MESSAGE (section 2.2.1.2) directly. They are also in the AUTHENTICATE_MESSAGE (section 2.2.1.3)
via the NTLMv2_CLIENT_CHALLENGE (section 2.2.2.7)
structure.
The AV_PAIR is also referred to in the MsvChannelBindings API.
Microsoft Channel Binding Enabling#
To preserve compatibility with existing clients and applications, a server may be configured to allow authentication attempts by clients that do not yet support Extended Protection for Authentication. The server can have the following levels of protection which are determined by the servers Windows registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<LDS instance name>\Parameters DWORD: LdapEnforceChannelBinding:- None - (DWORD value: 0) - No Channel Binding validation is performed. This is the behavior of all servers that have not been updated.
- Partial - (DWORD value: 1) - All clients that have been updated must provide Channel Binding information to the server. Clients that have not been updated do not have to do so. This is an intermediate option that allows for application compatibility.
- Full - (DWORD value: 2) - All clients must provide Channel Binding information. The server rejects authentication requests from clients that do not do so. (Which is the advice of ADV190023)
More Information#
There might be more information for this subject on one of the following:- ADV190023
- Channel Bindings for TLS
- Common Active Directory Bind Errors
- Extended Protection for Authentication
- RFC 5056
- Windows Authentication Package
- [#1] - Integrated Windows Authentication with Extended Protection
- based on information obtained 2020-01-17
- [#2] - Authentication failure from non-Windows NTLM or Kerberos servers
- based on information obtained 2020-01-17
- [#3] - Identifying Clear Text LDAP binds to your DC's
- based on information obtained 2020-01-18