OAuth Security – Proof of Possession

Session Topic: OAuth Security: Proof of Possession

Wednesday 1B

Convener: Hannes

Notes-takers): Roshni

Tags for the session - technology discussed/ideas considered: OAuth2, PoP

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Presentation here: http://www.tschofenig.priv.at/oauth/IETF-OAuth-PoP.pptx

Presented status of various specs for provided security better than bearer token security.

JWT

• uses JSON based encoding to describe claims
• “security token” but may also be used as an access token

Two cases:
	1. Asymmetric Key
	2. Symmetric Key (JWK encrypted in JWE)

		    Authzn Server
	I	   /	       \ 	III
	          /    II	 \
	Client----------Resource Servier

Motivation:

• 1. Desire to have E2E security at the application level.
• 2. To disallow a resource server from reusing an access token in other services. (single use tokens)

Q. PoP almost a factor of client authentication

Discussed methods of binding the secret:

• 1. secret bound to token
• 2. secret bound to client
• 3. secret bound to client instance

I. Client - Authzn server interaction

Reference:

Key distribution at client registration (draft-jones)

Key distribution at access token issuance (draft-bradley)

Followed up with an example of the symmetric key case:

• (i) The client sends a request for an access token along with some indication that says “I support PoP tokens”.
• (ii) AS then creates a PoP enabled access token
• (iii) AS sends access token to client along with the key. The key is also included in the token.

Discussion:

The symmetric key is produced by the AS.

For the asymmetric key case, the client generates public private key pairs.

What is the motivation for letting the client ask for PoP enabled tokens?

“I can handle PoP” is different from explicitly asking for a PoP enabled token. The server must have some way of knowing that the client can handle these tokens. Should therefore not be a runtime request (some ambiguity about runtime requests spec’d in the reference draft) -- reason for question: limit giving more options to potential attackers.

Does this work if the access token is not in a JWT?

Yes, but this example made 4 assumptions:

• i. symmetric key
• ii. JWT
• iii. No token introspection between AS and RS
• iv. Long term key shared between AS and RS.

Repeat:

PoP key should not be tied to JWT.

ACK. Need to follow up.

For asymmetric keys, the draft currently supports both key creation at the client and by the AS.

II. Client-RS interaction

• i) Proof of possession of PoP key
• ii) Message integrity + channel binding
• iii) RS to client authentication

The authenticator is a keyed message type computed over the request (contains access token and channel binding). Client generates JOSE object (JWS) - covers access token + some secret component --> access token identifier, and then submits the whole structure with the HTTP message, does the above (i), (ii), (iii).

There are problems with not signing everything. There was some discussion about mobility of headers and ordering. If the ordering of the headers matters for the API, then the app needs to be aware of that.

Suggestion: use existing RFCs for canonicalization of requests affected by mutability under HTTP and proxies.

Or -- use channel binding (more to follow in the next talk).

The RS then uses the shared long term key (with the AS) to unwrap / decrypt the access token and verify the authenticator.

Channel Bindings:

Ways to get the application layer security into the transport layer security

Options include using a public key in the TLS or use tls-unique and tls-server-end-point.

Warning: new attacks identified with the TLS based channel binding.

III. RS-AS interaction

Token introspection -- get claims and keying material from the AS to verify the authenticator, but the RS needs to identify itself first.

Next steps:

slides to be shared on the OAuth mailing list.