Difference between revisions of "Channel Binding"
From MgmtWiki
(→Problem) |
(→Problem) |
||
| Line 11: | Line 11: | ||
*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. | *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. | *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. This feature was dropped from Chrome as inadequate. The enterprise use case doesn't go away and now only Microsoft Browsers support the feature because they introduced it to solve a [[Kerberos]] problem anyway. | + | *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. This feature was dropped from Chrome as inadequate. The enterprise use case doesn't go away and now only Microsoft Browsers support the feature because they introduced it to solve a [[Kerberos]] problem anyway. |
==Solution== | ==Solution== | ||
Revision as of 15:08, 13 November 2018
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 [RFC 4301] [RFC 4303] [RFC 4302] can be accelerated in hardware to handle high link speeds, but IPsec key exchange protocols requires application support; then channel binding can bridge the gap.
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. This feature was dropped from Chrome as inadequate. The enterprise use case doesn't go away and now only Microsoft Browsers support the feature because they introduced it to solve a Kerberos problem anyway.
Solution
- Microsoft introduced Extended Protection for Authentication on (2009-12-09) as a mechanism to help safeguard authentication credentials on the Windows platform.
- Protection from the secure channel endpoint to a front end server
