1 / 18

IETF OAuth Proof-of-Possession

IETF OAuth Proof-of-Possession. Hannes Tschofenig. Status. Finished various specifications, including OAuth Core: RFC 6749 Bearer Tokens: RFC 6750 Security Threats: RFC 6819

pillan
Download Presentation

IETF OAuth Proof-of-Possession

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IETF OAuth Proof-of-Possession Hannes Tschofenig

  2. Status Finished various specifications, including OAuth Core: RFC 6749 Bearer Tokens: RFC 6750 Security Threats: RFC 6819 Discussion about an enhancement to Bearer Token security (now called “Proof-of-Possession”) since the early days of the working group. Design Team work late 2012/early 2013, which lead to requirements, use cases, and solution strawman proposals: Symmetric Key Solution: draft-ietf-oauth-v2-http-mac-05 Asymmetric Key Solution: draft-tschofenig-oauth-hotk-03 These two documents have now been replaced by others specs.

  3. JSON Web Token (JWT) • Standardized version of an access token (and ID Token). • Uses JSON-based encoding + JWE/JWS for encryption/signature + claims. • Described in https://ietf.org/doc/draft-ietf-oauth-json-web-token/ • WGLC finished • Proof-of-Possession Token extends JWT and embeds either a • Public key (or a fingerprint of it), or • Symmetric key (encrypted)

  4. PoP Token: Asymmetric Key Example [Header omitted.] { "iss":"xas.xboxlive.com", "aud":"http://auth.xboxlive.com", "exp":"1361398824", "nbf":"1360189224", "cnf":{ "jwk":{ "kty":"EC", "use":"sig", "crv":"P-256", "x":"18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", "y":"-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" } } } Binds a public key to the access token [Keyed message digest/digital signature omitted.]

  5. PoP Token: Symmetric Key Example { "alg":"RSA1_5", "enc":"A128CBC-HS256", "cty":"jwk+json" } { "iss": "https://server.example.com", "sub": "24400320", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "cnf":{ "jwk": "eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJB MTI4Q0JDLUhTMjU2IiwiY3R5IjoiandrK ... (remainder of JWE omitted for brevity)" } } Binds a symmetric key to the access token { "kty":"oct", "alg":"HS256", "k":"ZoRSOrFzN_FzUA5XKM YoVHyzff5oRJxl-IXRtztJ6uE" }

  6. I Architecture Client Authorization Server III II Resource Server Relevant document: http://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/

  7. I AS <-> Client Interaction Client • Variants: • Key Distribution at Access Token Issuance • Key Distribution at Client Registration Authorization Server III II Resource Server Relevant specifications:http://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/ http://datatracker.ietf.org/doc/draft-jones-oauth-proof-of-possession/

  8. AS <-> Client Interaction Example: Symmetric Key Client Authorization Server Request access token.I support PoP tokens Resource Server

  9. AS <-> Client Interaction Example: Symmetric Key Client AS creates PoP-enabled access token Authorization Server Resource Server

  10. AS <-> Client Interaction Example: Symmetric Key Client Authorization Server AS sends access token to Client & symmetric key Resource Server

  11. AS <-> Client Interaction • AS needs to bind a key to the access token. • Key can be an fresh and unique symmetric key, or • (ephemeral) public key • This requires two extensions: • New elements within the JWT to include the (encrypted symmetric key) or the public key. JWT is also integrity protected. • Mechanism for conveying ephemeral key from AS to client and for client to provide directives to AS. • Details: draft-bradley-oauth-pop-key-distribution-00 • Transport symmetric key from AS to client. • Transport (ephemeral) asymmetric key from AS to client. • Transport public key from client to AS. • Algorithm indication

  12. Dynamic Client Registration Attempt to simplify developer interaction with AS when they deploy client applications. Today, developers need to register various parameters (manually), such as Authentication mechanism & client authentication credentials Redirect URIs Grant types Meta data (client name, client logo, scopes, contact information, etc.) Also allows meta-data, including public keys, to be uploaded to AS. Two documents: draft-ietf-oauth-dyn-reg draft-ietf-oauth-dyn-reg-metadata WGLC in progress.

  13. I Client <-> RS Interaction Client • Building Blocks: • Proof of possession of PoP key • Message integrity (+ Channel Binding) • RS-to-client authentication Authorization Server III II Resource Server Relevant specification: http://datatracker.ietf.org/doc/draft-richer-oauth-signed-http-request/

  14. AS <-> Client Interaction Example: Symmetric Key Client Authenticator = Keyed Message Digest Computed Over Request. Authorization Server Resource Server AS sends access token to Client & Authenticator

  15. AS <-> Client Interaction Example: Symmetric Key Client Authorization Server RS “unwraps” access tokenand obtains symmetric key. RS verifies authenticator. SharedLong Term Key Resource Server

  16. Channel Binding • Channel bindings bind the application layer security to the underlying channel security mechanism. • Various approaches for providing channel bindings: • PoP public key use in TLS (as described in HOTK draft) • tls-unique: TLS Finish message • tls-server-end-point: hash of the TLS server's certificate: • Currently, no channel bindings described in <draft-richer-oauth-signed-http-request> • Be aware: Recently, new attacks have been identified with TLS-based channel bindings, see http://www.ietf.org/proceedings/89/slides/slides-89-tls-3.pdf

  17. I RS <-> AS Interaction [optional] Client • Variants: • a) Token introspection • b) Out-of-band Authorization Server III ` II Resource Server Relevant specification: http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/

  18. Next Steps • Good time to review through the PoP specification bundle is now • Provide feedback • Ask questions • Re-chartering to include documents in the milestone list. • Implementation activities to see what works and what doesn’t. • Various open issues to resolve. • Planning to schedule OAuth WG conference calls

More Related