扩展的身份验证保护有助于防范中间人（MITM）攻击，攻击者在其中截获客户端凭据并将其转发到服务器。
假设有三个参与者：客户端、服务器和攻击者。 服务器具有 URL https://server，而攻击者具有 URL https://attacker。 攻击者会欺骗客户端访问攻击者，就好像是服务器一样。 然后，攻击者将请求发送到服务器。 如果攻击者尝试访问安全资源，服务器会使用 WWW-Authenticate 标头回复攻击者。 由于攻击者没有身份验证信息，因此它会将 WWW-Authenticate 标头发送给客户端。 客户端将授权标头发送到攻击者，攻击者将标头发送到服务器，并使用客户端的凭据访问安全资源。
目前，当客户端应用程序使用 HTTPS 通过 Kerberos、Digest 或 NTLM 向服务器进行身份验证时，首先会建立传输级别安全性（TLS）通道，并使用此通道进行身份验证。 但是，安全套接字层（SSL）生成的会话密钥与在身份验证期间生成的会话密钥之间没有绑定。 因此，在前面的方案中，如果通信通过 TLS（如 HTTPS 通道）发生，则创建了两个 SSL 通道：一个在客户端和攻击者之间，另一个是在攻击者和服务器之间创建的。 客户端的凭据首先通过客户端与攻击者之间的 SSL 通道发送到服务器，然后通过攻击者和服务器之间的通道发送。 客户端的凭据到达服务器后，服务器会验证凭据，而无需检测发送这些凭据的通道是否源自攻击者，而不是客户端。
解决方案是使用受 TLS 保护的外部通道和客户端经过身份验证的内部通道，并将通道绑定令牌（CBT）传递给服务器。 CBT 是受 TLS 保护的外部通道的属性，并且用于通过对客户端进行身份验证的内部通道将外部通道绑定到对话。
在前面的方案中，客户端攻击者 TLS 通道的 CBT 与发送到服务器的授权信息合并。 识别 CBT 的服务器将客户端身份验证信息中所含的 CBT（与客户端-攻击者通道相对应）与附加到攻击者-服务器通道的 CBT 进行比较。 CBT 是针对通道目的地特定的，因此客户端攻击者的 CBT 与攻击者服务器的 CBT 不匹配。 这允许服务器检测 MITM 攻击并拒绝身份验证请求。
客户端不需要任何配置设置。 在对客户端进行了更新以将 CBT 传递给服务器之后，它会始终执行此操作。 如果服务器也已更新，则可以将其配置为使用 CBT 或忽略它。 如果尚未更新，则忽略它。
服务器可以具有以下级别的保护：
没有。 不会执行通道绑定验证。 这是所有尚未更新的服务器的行为。
部分。 所有已更新的客户端都必须向服务器提供通道绑定信息。 尚未更新的客户端不必这样做。 这是允许应用程序兼容性的中间选项。
完全。 所有客户端都必须提供通道绑定信息。 服务器拒绝来自不这样做的客户端的身份验证请求。
有关详细信息，请参阅 Win7 CBT/扩展保护示例。