IETF OAuth Proof-of-Possession

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