!!! Overview
[{$pagename}] ([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].  

[{$pagename}] allows [applications] to delegate [session] protection to lower layers, which has various performance benefits.

The term "[{$pagename}]" was derived from the [Generic Security Service Application Program Interface] ([GSSAPI]) [RFC 2743], which has a [{$pagename}] 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] [{$pagename}]
[Microsoft] [{$pagename}] 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
The [attacker] tricks the [client] into accessing the [attacker]'s [URL] as if it were the server. The attacker then sends a request to the server. If the attacker is trying to access a secure resource, the server replies to the attacker with a [WWW-Authenticate] [Header]. The [attacker] does not have the [authentication] information, so it sends the [WWW-Authenticate] [header] on to the [client]. The client sends the [Authorization Header] to the [attacker], and the [attacker] sends the header on to the [server] and gets access to the secure [Protected Resource] using the client’s [credentials].

__without [{$pagename}]__ 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 [{$pagename}]__, 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] [{$pagename}] is not [LDAPv3] or an [LDAP] [Specification], but tied to [tokens] generated and used ONLY by [Microsoft Windows], over [LDAP].

[{$pagename}] [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 [{$pagename}] [Token] [MUST] have the following properties (also defined by [RFC 5056]):
* When an outer channel exists, the value of the [{$pagename}] [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 [{$pagename}] [Token] sent by the [client] [MUST NOT] be something an [attacker] can influence.
* [Confidentiality] - No guarantees are made about [Confidentiality] of the [{$pagename}] [Token] value. This does not however mean that the value of the [{$pagename}] [Token] can always be examined by any other but the server performing [authentication], as the [protocol] carrying the [{$pagename}] [Token] may be encrypting it.
* [integrity] The [{$pagename}] [Token] [MUST] be [Cryptographic] [integrity] protected in transit such that an [attacker] cannot insert, remove or modify its value.

[{$pagename}] is accomplished by the client transferring the [ServicePrincipalName]([SPN]) and the [{$pagename}] [Token] to the [server] in a [Cryptographic] [integrity] protected fashion. The [server] validates the [{$pagename}] 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] [{$pagename}] 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].

!! [Microsoft] [{$pagename}] 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 [{$pagename}] 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 [{$pagename}] 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 [{$pagename}] 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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Integrated Windows Authentication with Extended Protection|https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/dd639324(v=vs.90)?redirectedfrom=MSDN|target='_blank'] - based on information obtained 2020-01-17 
* [#2] - [Authentication failure from non-Windows NTLM or Kerberos servers|https://support.microsoft.com/en-us/help/976918/authentication-failure-from-non-windows-ntlm-or-kerberos-servers|target='_blank'] - based on information obtained 2020-01-17 
* [#3] - [Identifying Clear Text LDAP binds to your DC's|https://docs.microsoft.com/en-us/archive/blogs/russellt/identifying-clear-text-ldap-binds-to-your-dcs|target='_blank'] - based on information obtained 2020-01-18