Transcript AS Client Interaction

IETF OAuth
Proof-of-Possession
Hannes Tschofenig
1
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.
2
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)
3
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"
}
}
}
[Keyed message digest/digital signature omitted.]
4
Binds a public key
to the access token
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,
Binds a symmetric key
to the access token
"cnf":{
"jwk":
"eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJB
MTI4Q0JDLUhTMjU2IiwiY3R5IjoiandrK
... (remainder of JWE omitted for brevity)"
}
}
5
{
"kty":"oct",
"alg":"HS256",
"k":"ZoRSOrFzN_FzUA5XKM
YoVHyzff5oRJxl-IXRtztJ6uE"
}
Architecture
Authorization
Server
I
III
Client
II
Resource
Server
Relevant document:
http://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/
6
AS <-> Client Interaction
Variants:
• Key Distribution at Access Token Issuance
• Key Distribution at Client Registration
I
Client
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/
7
AS <-> Client Interaction
Example: Symmetric Key
Authorization
Server
Request access token.
I support PoP tokens
Client
8
Resource
Server
AS <-> Client Interaction
Example: Symmetric Key
AS creates PoP-enabled
access token
Client
9
Authorization
Server
Resource
Server
AS <-> Client Interaction
Example: Symmetric Key
AS sends access token
to Client & symmetric key
Client
10
Authorization
Server
Resource
Server
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




11
Transport symmetric key from AS to client.
Transport (ephemeral) asymmetric key from AS to client.
Transport public key from client to AS.
Algorithm indication
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.
12
Client <-> RS Interaction
Building Blocks:
a)
Proof of possession of PoP key
b)
Message integrity (+ Channel Binding)
c)
RS-to-client authentication
Authorization
Server
I
III
Client
II
Resource
Server
Relevant specification : http://datatracker.ietf.org/doc/draft-richer-oauth-signed-http-request/
13
AS <-> Client Interaction
Example: Symmetric Key
Authorization
Server
Client
14
AS sends access token to
Client & Authenticator
Authenticator
= Keyed Message
Digest Computed
Over Request.
Resource
Server
AS <-> Client Interaction
Example: Symmetric Key
Authorization
Server
Shared
Long
Term
Key
Client
15
RS “unwraps” access token
and obtains symmetric key.
RS verifies authenticator.
Resource
Server
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-richeroauth-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
16
RS <-> AS Interaction [optional]
Variants:
a) Token introspection
b) Out-of-band
Authorization
Server
I
III
`
Client
II
Resource
Server
Relevant specification: http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
17
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
18