OAuth 2.0 Security

OAuth 2.0 Security OAuth Design Team Conference Call, 4th Feb. 2013

Agenda • IETF submission deadline showing up soon. • We need to make decisions about the core design aspects. • Summary slides about: • What we know • What we don’t know. • Not discussed

What we know • We have a write-up of the requirements and the main use cases • We want to focus on symmetric keys for the moment. • Lifetime of session key to be bound to the lifetime of the access token (for symmetric keys) • Replay protection support has to be included.

What we don’t know • Crypto-Agility: • We have not come to a conclusion regarding algorithm indication. When? By whom? How? • Key distribution: • Three mechanisms presented. Which one should focus on? • Solution Design: • HTTP level or JSON level? • Use Cases: • Is there interest in the support for “Signed URLs”? • No conclusion regarding client indicating RS-id • Key naming: • Keys need to have a name. Previous discussion indicated that the key name could be the access token or some other identifier.

Not discussed • Degree of the keyed message digest protection • Selected header fields only • Body of the message: is there any hope? • Who generates the session key? AS, client, or joint key control • Do we want to provide a channel binding solution? • Should subsequent messages exchanged between the client and the RS be integrity protected as well? • Assumption: Scope is included in the token and changing the scope requires a new access token to be obtained. OK? • Collusion: Not sure whether it is a desirable property

Backup

Scoping Proposal • For the start we focus on a symmetric key variant. • Later we can add an asymmetric key version. • OK?

How RS obtains the Session Key?Option#1: Key Transport

How RS obtains the Session Key?Option#2: “Key Retrieval” Key Request

How RS obtains the Session Key?Option#3: Key Agreement Key Request

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.

Prevent the Domino Effect • What happens when a client gets compromised? • Rogue 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? • Rogue 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

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). • Question: • 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 with • (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)

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?

OAuth 2.0 Security