Extended Protection for Authentication Overview
Extended Protection for Authentication helps protect against man-in-the-middle (MITM) attacks, in which an attacker intercepts a client’s credentials and forwards them to a server.
Consider a scenario with three participants: a client, server, and attacker. The server has the URL https://server, whereas the attacker has the URL https://attacker. The attacker tricks the client into accessing the attacker 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 resources using the client’s credentials.
Currently, when a client application authenticates itself to the server using Kerberos, Digest, or NTLM using HTTPS, a Transport Level Security (TLS) channel is first established and authentication takes place using this channel. However, there is no binding between the session key generated by Secure Sockets Layer (SSL) and the session key that is generated during authentication. So, in the previous scenario, if the communication takes places over a TLS (such as an HTTPS channel), there are two SSL channels created: one between the client and the attacker, and another between the attacker and the server. The client’s credentials are sent from the client to the server first over the SSL channel between the client and the attacker and then over the channel between the attacker and the server. Once the client’s credentials reach the server, the server verifies the credentials without detecting that the channel over which those credentials were sent originated with the attacker and not the client.
The solution is to use a TLS-secured outer channel and a client-authenticated inner channel, and to pass a Channel Binding Token (CBT) to the server. The CBT is a property of the TLS-secured outer channel, and is used to bind the outer channel to a conversation over the client-authenticated inner channel.
In the previous scenario, the CBT of the client-attacker TLS channel is merged with the authorization information that is sent to the server. A CBT-aware server compares the CBT contained in the client authentication information, which corresponds to the client-attacker channel, to the CBT attached to the attacker-server channel. A CBT is specific to a channel’s destination, so the client-attacker CBT does not match the attacker-server CBT. This lets the server detect the MITM attack and refuse the authentication request.
The client side does not require any configuration setting. Once the platform on which the client is running has been updated to pass the CBT to the server, it always does so. If the server has also been updated, it can be configured to verify the CBT or ignore it. If it has not been updated, it always ignores it.
The server can have the following levels of protection:
Never. No channel binding validation is performed. This is the behavior of all servers that have not been updated.
When Supported. All clients that are running on a version of Windows that has been updated to support CBT must provide channel binding information to the server. Clients running on a version of Windows that has not been updated to support CBT do not have to do so. This is an intermediate option that allows for application compatibility.
Always. All clients must provide channel binding information. The server rejects authentication requests from clients that do not do so.
Note
There is no support for Extended Protection for Authentication in the WebHttpBinding at this time.
For more information, see the Win7 CBT/Extended Protection sample.