Channel Binding

From MgmtWiki
Revision as of 19:44, 25 August 2018 by Tom (talk | contribs) (Context)

Jump to: navigation, search

Full Title or Meme

The process of binding an Authentication process to a secure channel that has been established between two communicating end-points.

Context

RFC 5056 "On the Use of Channel Bindings to Secure Channels" Abstract

The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.

In applications that need user interaction to complete authentication while simultaneously being able to utilize session or transport security at a lower network layer. For example, IPsec [RFC4301] [RFC4303] [RFC4302] is amenable to being accelerated in hardware to handle very high link speeds, but IPsec key exchange protocols and the IPsec architecture are not as amenable to use as a security mechanism within applications, particularly applications that have users as clients

Problem

  • Original Problem: Channel Rely is an attack against an Authentication process in certain scenarios. If an attacker manages to elicit a client to connect to him, that attacker could take advantage of the authentication mechanism and use it to authenticate against a third party server on which the client has an account with identical credentials. In addition, the attacker could even authenticate against a service running on the client itself. Evan so, the attacker could never learn the user’s password.
  • Using channel binding between endpoints on protects the token between the endpoints. With the rise of off-loading secure support for IPSec and TLS (HTTPS) results in a gap in protection as the packet travels beyond the secure end point to the server that supports the business logic.
  • Token reuse: OAuth 2.0 or OpenID Connect use of bearer tokens raises the risk of token theft. For years architects have been waiting for Token Binding to get ratified so there would be transparent mechanism to close this gap. If this feature gets dropped from Chrome, this enterprise use case doesn't go away and only Microsoft Browsers support the feature.

Solution

  • Microsoft introduced EAP
  • Protection from the secure channel endpoint to a front end server

Reference