Channel Binding - Revision history

Tom: /* Reference */

2022-09-04T21:39:35Z

‎Reference

Tom: /* Context */

2022-05-31T17:02:23Z

‎Context

Tom: /* Problem */

2018-11-13T22:08:58Z

‎Problem

Tom: /* Problem */

2018-11-13T22:07:48Z

‎Problem

Tom: /* Solution */

2018-11-09T00:13:52Z

‎Solution

Tom: /* Solution */

2018-11-09T00:12:34Z

‎Solution

Tom: /* Solution */

2018-11-09T00:11:29Z

‎Solution

Tom: /* Context */

2018-08-26T02:51:19Z

‎Context

Tom: /* Context */

2018-08-26T02:48:13Z

‎Context

Tom: /* Context */

2018-08-26T02:44:49Z

‎Context

@@ Line 19: / Line 19: @@
 ==Reference==
-[[Category:Glossary]]
+[[Category: Glossary]]
-[[Category:Authentication]]
+[[Category: Networking]]

@@ Line 6: / Line 6: @@
 <blockquote> 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.</blockquote>
-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.
+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 require application support; then channel binding can bridge the gap.
 ==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.
 *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==

@@ 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.
 *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.
+*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 [https://blogs.technet.microsoft.com/srd/2009/12/08/extended-protection-for-authentication/ Extended Protection for Authentication] on (2009-12-09) as a mechanism to help safeguard authentication credentials on the Windows platform.

@@ Line 16: / Line 16: @@
 ----
 ==Solution==
-*Microsoft introduced [https://blogs.technet.microsoft.com/srd/2009/12/08/extended-protection-for-authentication/ Extended Protection for Authentication] on (2009-12-09).
+*Microsoft introduced [https://blogs.technet.microsoft.com/srd/2009/12/08/extended-protection-for-authentication/ 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

@@ Line 3: / Line 3: @@
 ==Context==
-RFC 5056 "On the Use of Channel Bindings to Secure Channels" Abstract <blockquote> 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.</blockquote>
+RFC 5056 "On the Use of Channel Bindings to Secure Channels" Abstract
 ==Problem==