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.
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.Microsoft Channel Binding is a part of Microsoft's Extended Protection for Authentication and ADV190023
Consider 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).
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 Sequences of AV_PAIR structures are defined in the NT LAN Manager Authentication Protocol and used in the CHALLENGE_MESSAGE (section 188.8.131.52) directly. They are also in the AUTHENTICATE_MESSAGE (section 184.108.40.206) via the NTLMv2_CLIENT_CHALLENGE (section 220.127.116.11) structure.
The AV_PAIR is also referred to in the MsvChannelBindings API.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:
- Channel Bindings for TLS
- Common Active Directory Bind Errors
- Extended Protection for Authentication
- RFC 5056
- Web Blog_blogentry_170120_1
- 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