Bound Token

From MgmtWiki
Revision as of 21:45, 22 October 2018 by Tom (talk | contribs) (Identifier)

Jump to: navigation, search

Full Title or Meme

A data structure that passes strongly purpose bound Authorization grants to a Resource server.

Context

RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer Token Usage" defines the Bearer Token.

Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.

The Bound Token is specifically designed to overcome several of the problems of a Bearer Token.

Problem


  • Any party in possession of a Bearer Token can use it to get access to the associated Resources. To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.
  • Bearer Tokens are valid only for as short time as possible. These tokens work like passwords, and if intercepted can be used immediately by an attacker. Therefore the OAuth2 (with bearer token) specification requires that all communication takes place over SSL - since no cryptography is built into the specification. Typically access tokens have a short validity, which can be refreshed with a "refresh token" which has longer validity but is only transferred when the initial bearer token is received by the consumer, and when a bearer token is refreshed.
  • Microsoft reported the replay attack against Kerberos tokens[1] and addressed the attack with Channel Binding.[2]
  • 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

  • This wiki page creates a new type of structure to address the problems noted above. It is currently just a draft proposal to get the conversation about the complete solution started.

Identifier

All trusted entities need to be identified. In the current federation document it is proposed that the the SID, IIS, etc. be a URL rather than a URI, since we know what a URL is, but a URI seems to be too unbounded for practical use. As a tentative solution we propose a new schema, the trusted ID or tid://.

Note that the most important attribute of a TID that offers up metadata is a URL pointing to the authority. But in the case of a native app, the URL might need to be somewhere else to be useful.

Reference

  • Microsoft Security Advisory 974926, Credential Relaying Attacks on Integrated Windows Authentication (2009-12-08) https://docs.microsoft.com/en-us/security-updates/securityadvisories/2009/974926
  • Microsoft Directroy Services Team, Control Extended Protection for Authentication using Security Policy. https://blogs.technet.microsoft.com/askds/2009/12/10/control-extended-protection-for-authentication-using-security-policy/