Security

1. Security HannesTschofenig

2. Goal for this Meeting • Use the next 2 hours to determine what the security consideration section of the OAuthdraft(s) should contain. • Currently, the security consideration section of draft-ietf-oauth-v2-10 is empty. • Note: No time to actually write text today. • The next couple of slides are an introduction to get the discussion started. • Approaches the topic based on NIST SP 800-63

3. Abstract View on OAuth ,-. (* *) `+' User ' :------------ ---|--- ~~~~~~~~~~: : Service / \ : Management : Interaction / \ : of Resources : : Consent : : : : : : : : +---:-+ Carol : : 1. |Carol| as : : Obtain .'>| | Asserting : : Access .' +-----+ Party : : Token.' : : .' : : .' : : v' : +-:---+ +--:--+ Bob |Alice|<------------------------->|Bob | as | | 2. Authenticated | | Relying +-----+ Request + +-----+ Party Access Token

4. Status: draft-ietf-oauth-v2-10(with relevance for security) • Token: • Token Format not specified • Token Content not specified • Protection of token unspecified. • HTTP Basic Authentication used for interaction with the authorization server, see (1) • No HTTP-level authentication for authenticated request (2) specified. • TLS not mandatory to use for (2) either.

5. Example Instantiation: Web Server Flow

7. Security Threats (based on NIST SP 800-63) • Token manufacture/modificationAn attacker may generate a bogus token or modify the token content of an existing token, causing Bob to grant inappropriate access to the Alice. • Token disclosureTokens may contain authentication and attribute statements that include sensitive information. • Token redirectAn attacker uses the token generated for consumption by Bob to obtain access to a second Relying Party. • Token reuseAn attacker attempts to use a token that has already been used once with Bob.

8. Threat Mitigation(based on NIST SP 800-63) • Token modification: • Protect the content, or use a reference instead! • Token redirect: • Carol must include the identity of the token consumer, Bob. • Token disclosure: • Variant (a): Do not include sensitive information • Variant (b): Offer confidentiality protection

9. Dealing with Token Reuse • Approach #1: Confidentiality Protection & extra condition* *: Alice has to make sure it does not distribute the token to entities other than Bob Carol TLS Bob Alice TLS

10. Dealing with Token Reuse (2) • Approach #2: Sender Constraint • Token contains information about the legitimate presenter (Alice). • Bob has to authenticate Alice first to verify whether the token constraint matches the authenticated identity

11. Dealing with Token Reuse (3) • Approach #3: Key Confirmation Carol Req Token,SK, {SK}Bob TLS Bob Alice Token, {Request}SK, {SK}Bob

12. Mandatory to implement? • Challenge: draft-ietf-oauth-v2-10 does not provide a completely interoperable solution since many aspects are left for bi-lateral agreements between Alice & Bob. • So, what should be mandatory to implement? • Key Confirmation Approach • Experience in deployment available from Kerberos. • Other approaches suffer from operational considerations • Ensuring that Alice only provides token to Bob • Establishing authentication infrastructure • Putting proper constraints in the token. • MUST implement and use TLS between Alice and Carol (exchange #1)

13. Additional Security Considerations • This slide set focuses on the token exchange. Security for the exchange between Alice and Carol isn’t described in great detail. • Main document can only provide requirements for token protection • Will have to be postponed to documents covering the details. Example: • Additional security considerations based on properties of individual flows. • Relate to properties provided by operating systems, libraries/application frameworks, and browsers.