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

OAuth 2.0 Security

  • Upload
    harvey

  • View
    95

  • Download
    0

Embed Size (px)

DESCRIPTION

OAuth 2.0 Security. OAuth Design Team Conference Call, 4 th 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. - PowerPoint PPT Presentation

Citation preview

Page 1: OAuth 2.0 Security

OAuth 2.0 Security

OAuth Design Team Conference Call, 4th Feb. 2013

Page 2: OAuth 2.0 Security

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

Page 3: OAuth 2.0 Security

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.

Page 4: OAuth 2.0 Security

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.

Page 5: OAuth 2.0 Security

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

Page 6: OAuth 2.0 Security

Backup

Page 7: OAuth 2.0 Security

Scoping Proposal

• For the start we focus on a symmetric key variant.

• Later we can add an asymmetric key version.

• OK?

Page 8: OAuth 2.0 Security

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

User Agent &

Resource Owner

Client (C)

Authorization Server (AS)

Resource Server (RS)

Access Token

Keys & Meta Data

AS-C

AS-RS

Access Token

AS-RS

Keyed Message

Digest

C-RS

TLS

Page 9: OAuth 2.0 Security

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

Keyed Message

Digest

User Agent &

Resource Owner

Client (C)

Authorization Server (AS)

Resource Server (RS)

Access Token

Keys & Meta Data

AS-C

AS-RS

Access Token

AS-RS

C-RS

TLS

Key Request

Page 10: OAuth 2.0 Security

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

Keyed Message

Digest

User Agent &

Resource Owner

Client (C)

Authorization Server (AS)

Resource Server (RS)

Access Token

Keys & Meta Data

AS-C

AS-RS

Access Token

AS-RS

C-RS

TLS

Key Request

Page 11: OAuth 2.0 Security

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.

Page 12: OAuth 2.0 Security

Confirm Cryptographic Algorithm Selection

• Client supported list of algorithms cannot be modified since it is sent over a TLS protected channel.

Page 13: OAuth 2.0 Security

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

Page 14: OAuth 2.0 Security

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.

Page 15: OAuth 2.0 Security

Replay Detection Mechanism

• Based on timestamp with optional seq-number

Page 16: OAuth 2.0 Security

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?

Page 17: OAuth 2.0 Security

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

Page 18: OAuth 2.0 Security

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)

Page 19: OAuth 2.0 Security

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?

Page 20: OAuth 2.0 Security

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.

Page 21: OAuth 2.0 Security

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)

Page 22: OAuth 2.0 Security

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.

Page 23: OAuth 2.0 Security

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

Page 24: OAuth 2.0 Security

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?