Difference between revisions of "Token Binding"
From MgmtWiki
(→Context) |
(→Problem) |
||
| (12 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
==Context== | ==Context== | ||
| − | *Secure web connections | + | *Secure web connections are dependent on HTTPS for security. |
| − | *See the page on [[Channel Binding]] about RFC 5056 for details on the | + | *See the page on [[Channel Binding]] about RFC 5056 for details on the use of low level security protocols to provide application level security. |
==Problem== | ==Problem== | ||
| − | + | *Attempts to make a trusted connection from a user to [[Web Site]] have included [[EV Cert]]s and other attempt to over come the failings inherent in trusting any connection based on the [[URL]] have all failed. See the page [[Bearer Tokens Considered Harmful]] for details. | |
| − | *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. The feature has been dropped by the Google Chrome browser as inadequate to solve the problem. So a different solution is required. | + | *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 a transparent mechanism to close this gap. RFC 8471 ''The Token Binding Protocol Version 1.0'' was approved in (2018-10) by the IETF. The [[Token Binding]] feature has been dropped by the Google Chrome browser as inadequate to solve the problem at about the same time as the RFC was approved. So a different solution is required. |
| + | *HTTPS and the identity in the [[X.509]] Certificate is adequate given the uncertain nature of the [[URL]] as an [[Identifier]]. | ||
| + | * Token binding requires that the key used in TLS be used at the application layer. That would require that the internet facing server have access to the signing key, or at least that the signing key be distributed to multiple servers. This is poor security practice and should be banned outright. | ||
| + | * See the page on [[Wild Card Certificates]] for details on the ALPACA attack which shows an example of where the mixing of security between the transport layer and application layer can create problems. | ||
==Solution== | ==Solution== | ||
| − | Look to other solutions like [[Bound Token]]s. | + | Look to other solutions like: |
| + | # [[Bound Token]]s do not need to be based on the underlying HTTPS connection, which was never designed to create trust in the identity of the [[Web Site]]. | ||
| + | # Create a [[Trusted Identifier]] as a URN for web sites and then bind the token to that URN. | ||
==Reference== | ==Reference== | ||
Latest revision as of 17:05, 5 November 2021
Full Title or Meme
The process of binding an OpenID Connect or OAuth 2.0 interchange to a HTTPS channel that has been established between a user agent and a Web Site.
Context
- Secure web connections are dependent on HTTPS for security.
- See the page on Channel Binding about RFC 5056 for details on the use of low level security protocols to provide application level security.
Problem
- Attempts to make a trusted connection from a user to Web Site have included EV Certs and other attempt to over come the failings inherent in trusting any connection based on the URL have all failed. See the page Bearer Tokens Considered Harmful for details.
- 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 a transparent mechanism to close this gap. RFC 8471 The Token Binding Protocol Version 1.0 was approved in (2018-10) by the IETF. The Token Binding feature has been dropped by the Google Chrome browser as inadequate to solve the problem at about the same time as the RFC was approved. So a different solution is required.
- HTTPS and the identity in the X.509 Certificate is adequate given the uncertain nature of the URL as an Identifier.
- Token binding requires that the key used in TLS be used at the application layer. That would require that the internet facing server have access to the signing key, or at least that the signing key be distributed to multiple servers. This is poor security practice and should be banned outright.
- See the page on Wild Card Certificates for details on the ALPACA attack which shows an example of where the mixing of security between the transport layer and application layer can create problems.
Solution
Look to other solutions like:
- Bound Tokens do not need to be based on the underlying HTTPS connection, which was never designed to create trust in the identity of the Web Site.
- Create a Trusted Identifier as a URN for web sites and then bind the token to that URN.
