OAuth WG Conference Call, 11th Jan. 2013 OAuth 2.0 Security OAuth WG Conference Call, 11th Jan. 2013

Crypto-Agility [C->RS: Discovery] C->AS: [algorithm list]**, id(RS), id(client), scope C<-AS: algorithm*, key, access token C->RS: algorithm, HMAC/signature, access token*** C<-RS: OK. *Assumption: AS knows what algorithms are supported by the RS. AS selects appropriate algorithm from the client-provided list. **: Algorithm list & token types could be conveyed implicitly via the client id. Client registers the data during the registration phase. ***: Alternatively an error message is returned if no common algorithms are supported.

Confirm Cryptographic Algorithm Selection Client supported list of algorithms cannot be modified since it is sent over a TLS protected channel.

Uniquely Named Keys Key used for client authentication is named via Client_id Key used to protect the access token is named kid (if the JOSE work is used). Session key used for client<->RS interaction could be named via id (as in MAC draft). Should a session key also be used for a subsequent exchange of data between the client and the resource server?

Authorization Restriction Information needed by client: Lifetime of the session key + Key identifier Authorization Scope Resource Server the access token can be used (Any information related to delegation, or post-dated access tokens.)

Bind Key to its Context Session key to be used for client-to-RS interaction Lifetime of session key. Symmetric key: lifetime of access token Asymmetric key: longer lifetime Who has access to the session key? Depends on the type: Symmetric: AS, client instance, RS Asymmetric: privacy key known to the client instance only

Prevent the Domino Effect What happens when a client gets compromised? Rouge client must not get access to resources of resource owners who have been interacted with that client. What happens when a resource server gets compromised? Rouge RS must not be able to impersonate clients to other RSs

Strong, fresh session keys Randomly generated with sufficient entropy Client id: client id is not visible to RS Joint key control (client & AS) for symmetric keys? Scope Should a different session key be used when the scope changes? Lifetime of C<->RS session key : For symmetric keys: lifetime of the session key is bound to the access token lifetime.

Replay Detection Mechanism Based on timestamp with optional seq-number

Authenticate All Parties AS authenticated by the client Client authentication to the AS (mandatory?) Client authentication to the RS via keyed message digest/signature RS authentication to the client?

Authorization Resource Owner is authorized by the AS. Client is authorized by the AS via client authentication (mandatory?) RS authorizes client based on access token in combination with proof of possession of key. AS authorizes RS via the encrypted session key.

Keying Material Confidentiality and Integrity Client obtains session key via TLS protected channel. If refresh token leaks then it can be used to obtain access token + new session key. The refresh token behaves like a bearer token. A problem? Without channel binding the TLS tunnel may terminate before the AS RS obtains session key via encrypted access token (in case of symmetric keys) (optionally: RS obtains session key from AS)

Client Identity Confidentiality A Client has identity confidentiality when any party other than the Resource Server and the Authorization Server cannot sufficiently identify the Client within the anonymity set. Client to AS exchange is confidentiality protected. Client id is not exposed to RS.

Resource Owner Identity Confidentiality Only the Authorization Server gets to know the identity of the resource owner Unless a JWT carries a "sub" (Subject) Claim

Collusion The Authorization Server can be prevented from knowing which Resource Servers a Resource Owner interacts with. Consequence: The AS is unable to populate the audience field in a JWT. The AS cannot encrypt a session key for usage with a specific RS. Best supported with asymmetric cryptography Is this a desirable feature for an initial version?