1. 1 IETF OAuth Proof-of-Possession Hannes Tschofenig

2. 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. 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. 4 PoP Token: Asymmetric Key Example { "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.] [Header omitted.]

5. 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)" } { "kty":"oct", "alg":"HS256", "k":"ZoRSOrFzN_FzUA5XKM YoVHyzff5oRJxl-IXRtztJ6uE" } Binds a symmetric key to the access token

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

7. 7 I Client Authorization Server Resource Server II III Variants: Key Distribution at Access Token Issuance Key Distribution at Client Registration AS Client Interaction 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. 8 Client Authorization Server Resource Server AS Client Interaction Example: Symmetric Key Request access token. I support PoP tokens

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

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

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

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

15. 15 Client Authorization Server Resource Server AS Client Interaction Example: Symmetric Key RS “unwraps” access token and obtains symmetric key. RS verifies authenticator. Shared Long Term Key

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

18. 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