--- 1/draft-ietf-oauth-pop-architecture-00.txt 2015-03-03 07:14:36.858805933 -0800 +++ 2/draft-ietf-oauth-pop-architecture-01.txt 2015-03-03 07:14:36.902807019 -0800 @@ -1,25 +1,25 @@ OAuth P. Hunt, Ed. Internet-Draft Oracle Corporation Intended status: Informational J. Richer -Expires: January 22, 2015 The MITRE Corporation +Expires: September 4, 2015 W. Mills P. Mishra Oracle Corporation H. Tschofenig ARM Limited - July 21, 2014 + March 3, 2015 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture - draft-ietf-oauth-pop-architecture-00.txt + draft-ietf-oauth-pop-architecture-01.txt Abstract The OAuth 2.0 bearer token specification, as defined in RFC 6750, allows any party in possession of a bearer token (a "bearer") to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens must to be protected from disclosure in transit and at rest. Some scenarios demand additional security protection whereby a client @@ -35,25 +35,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 22, 2015. + This Internet-Draft will expire on September 4, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -69,21 +69,21 @@ 3.3. Access to a Non-TLS Protected Resource . . . . . . . . . 4 3.4. Offering Application Layer End-to-End Security . . . . . 5 4. Security and Privacy Threats . . . . . . . . . . . . . . . . 5 5. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Confidentiality Protection . . . . . . . . . . . . . . . 7 5.2. Sender Constraint . . . . . . . . . . . . . . . . . . . . 7 5.3. Key Confirmation . . . . . . . . . . . . . . . . . . . . 8 5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction At the time of writing the OAuth 2.0 protocol family ([RFC6749], @@ -198,27 +198,28 @@ should work in such a scenario. Furthermore, it may not be necessary to provide authentication of the resource server towards the client. 3.4. Offering Application Layer End-to-End Security In Web deployments resource servers are often placed behind load balancers, which are deployed by the same organization that operates the resource servers. These load balancers may terminate the TLS connection setup and HTTP traffic is transmitted in the clear from the load balancer to the resource server. With application layer - security independent of the underlying TLS security it is possible to + security in addition to the underlying TLS security it is possible to allow application servers to perform cryptographic verification on an end-to-end basis. The key aspect in this use case is therefore to offer end-to-end security in the presence of load balancers via application layer - security. + security. Enterprise networks also deploy proxies that inspect + traffic and thereby break TLS. 4. Security and Privacy Threats The following list presents several common threats against protocols utilizing some form of tokens. This list of threats is based on NIST Special Publication 800-63 [NIST800-63]. We exclude a discussion of threats related to any form of identity proofing and authentication of the resource owner to the authorization server since these procedures are not part of the OAuth 2.0 protocol specification itself. @@ -442,26 +443,34 @@ the possession of the secret to the resource server when accessing the resource. The resource server, when receiving an access token, needs to verify that the key used by the client matches the one included in the access token. There are slight differences between the use of symmetric keys and asymmetric keys when they are bound to the access token and the subsequent interaction between the client and the authorization server when demonstrating possession of these keys. Figure 1 shows the symmetric key procedure and Figure 2 illustrates how asymmetric - keys are used. + keys are used. While symmetric cryptography provides better + performance properties the use of asymmetric cryptography allows the + client to keep the private key locally and never expose it to any + other party. - With the JSON Web Token (JWT) a standardized format for access tokens - is available. The necessary elements to bind symmetric or asymmetric - keys to the JWT are described in - [I-D.jones-oauth-proof-of-possession]. + With the JSON Web Token (JWT) [I-D.ietf-oauth-json-web-token] a + standardized format for access tokens is available. The necessary + elements to bind symmetric or asymmetric keys to a JWT are described + in [I-D.ietf-oauth-proof-of-possession]. + + Note: The negotiation of cryptographic algorithms between the client + and the authorization server is not shown in the examples below and + assumed to be present in a protocol solution to meet the requirements + for crypto-agility. +---------------+ ^| | // | Authorization | / | Server | // | | / | | (I) // /+---------------+ Access / // Token / / @@ -496,21 +505,21 @@ key transport mechanism from the authorization server to the client has been explained in the previous paragraph there are three ways for communicating this session key from the authorization server to the resource server, namely Embedding the symmetric key inside the access token itself. This requires that the symmetric key is confidentiality protected. The resource server queries the authorization server for the symmetric key. This is an approach envisioned by the token - introspection endpoint [I-D.richer-oauth-introspection]. + introspection endpoint [I-D.ietf-oauth-introspection]. The authorization server and the resource server both have access to the same back-end database. Smaller, tightly coupled systems might prefer such a deployment strategy. +---------------+ ^| | Access Token Req. // | Authorization | +Parameters / | Server | +[Fingerprint] // | | @@ -537,97 +546,99 @@ the server could be involved in the generation of the ephemeral key pair. This exchange is shown in Figure 1. If the client generates the key pair it either includes a fingerprint of the public key or the public key in the request to the authorization server. The authorization server would include this fingerprint or public key in the confirmation claim inside the access token and thereby bind the asymmetric key pair to the token. If the client did not provide a fingerprint or a public key in the request then the authorization server is asked to create an ephemeral asymmetric key pair, binds the fingerprint of the public key to the access token, and returns the - asymmetric key pair (public and private key) to the client. + asymmetric key pair (public and private key) to the client. Note + that there is a strong preference for generating the private/public + key pair locally at the client rather than at the server. The specification describing the interaction between the client and the authorization server, as shown in Figure 1 and in Figure 2, can - be found in [I-D.bradley-oauth-pop-key-distribution]. + be found in [I-D.ietf-oauth-pop-key-distribution]. Once the client has obtained the necessary access token and keying material it can start to interact with the resource server. To demonstrate possession of the key bound to the access token it needs to apply this key to the request by computing a keyed message digest (i.e., a symmetric key-based cryptographic primitive) or a digital - signature (i.e., an asymmetric cryptographic primitive). When the + signature (i.e., an asymmetric cryptographic computation). When the resource server receives the request it verifies it and decides whether access to the protected resource can be granted. This exchange is shown in Figure 3. +---------------+ | | | Authorization | | Server | | | | | +---------------+ Request +-----------+ + Signature/MAC (a) +------------+ | |---------------------->| | | | [+Access Token] | Resource | | Client | | Server | | | Response (b) | | | |<----------------------| | - +-----------+ +------------+ + +-----------+ [+ Signature/MAC] +------------+ ^ ^ | | | | Symmetric Key Symmetric Key or or Asymmetric Key Pair Public Key (Client) + + Parameters Parameters Figure 3: Client demonstrates PoP. The specification describing the ability to sign the HTTP request from the client to the resource server can be found in - [I-D.richer-oauth-signed-http-request]. + [I-D.ietf-oauth-signed-http-request]. So far the examples talked about access tokens that are passed by value and allow the resource server to make authorization decisions immediately after verifying the request from the client. In some deployments a real-time interaction between the authorization server and the resource server is envisioned that lowers the need to pass self-contained access tokens around. In that case the access token merely serves as a handle or a reference to state stored at the authorization server. As a consequence, the resource server cannot autonomously make an authorization decision when receiving a request from a client but has to consult the authorization server. This can, for example, be done using the token introspection endpoint (see - [I-D.richer-oauth-introspection]). Figure 4 shows the protocol + [I-D.ietf-oauth-introspection]). Figure 4 shows the protocol interaction graphically. Despite the additional token exchange previous descriptions about associating symmetric and asymmetric keys to the access token are still applicable to this scenario. +---------------+ Access ^| | - Token Req. // | Authorization |\ + Token Req. // | Authorization |^ (I) / | Server | \ (IV) Token - // | | \ Introspection + // | | \ Introspection Req. / | | \ +Access // /+---------------+ \ Token / // (II) \ \\ / / Access \ \ // // Token \ (V) \ / / \Resp.\ // // \ \ - / v \ \ + / v V \ +-----------+ Request +Signature/MAC+------------+ | | (III) +Access Token | | | |---------------------->| Resource | | Client | (VI) Success or | Server | | | Failure | | | |<----------------------| | +-----------+ +------------+ Figure 4: Token Introspection and Access Token Handles. @@ -775,38 +786,39 @@ pseudonymous identity of the resource owner, since the authorization server is the only entity involved in verifying the resource owner's identity. Collusion: Resource servers that collude can be prevented from using information related to the resource owner to track the individual. That is, two different resource servers can be prevented from determining that the same resource owner has authenticated to both - of them. This requires that each authorization server obtains - different keying material as well as different access tokens with - content that does not allow identification of the resource owner. + of them. Authorization servers MUST bind different keying + material to access tokens used for resource servers from different + origins (or similar concepts in the app world). AS-to-RS Relationship Anonymity: - This MAC Token security does not provide AS-to-RS relationship - anonymity since the client has to inform the resource server about - the resource server it wants to talk to. The authorization server - needs to know how to encrypt the session key the client and the - resource server will be using. + For solutions using asymmetric key cryptography the client MAY + conceal information about the resource server it wants to interact + with. The authorization server MAY reject such an attempt since + it may not be able to enforce access control decisions. - As an additional requirement a solution MUST enable support for - channel bindings. The concept of channel binding, as defined in - [RFC5056], allows applications to establish that the two end-points - of a secure channel at one network layer are the same as at a higher - layer by binding authentication at the higher layer to the channel at - the lower layer. + Channel Binding: + + A solution MUST enable support for channel bindings. The concept + of channel binding, as defined in [RFC5056], allows applications + to establish that the two end-points of a secure channel at one + network layer are the same as at a higher layer by binding + authentication at the higher layer to the channel at the lower + layer. There are performance concerns with the use of asymmetric cryptography. Although symmetric key cryptography offers better performance asymmetric cryptography offers additional security properties. A solution MUST therefore offer the capability to support both symmetric as well as asymmetric keys. There are threats that relate to the experience of the software developer as well as operational practices. Verifying the servers identity in TLS is discussed at length in [RFC6125]. @@ -834,64 +846,62 @@ chairs, Hannes Tschofenig, and Derek Atkins) provided their input during these calls: Bill Mills, Justin Richer, Phil Hunt, Prateek Mishra, Mike Jones, George Fletcher, Leif Johansson, Lucy Lynch, John Bradley, Tony Nadalin, Klaas Wierenga, Thomas Hardjono, Brian Campbell In the appendix of this document we re-use content from [RFC4962] and the authors would like thank Russ Housely and Bernard Aboba for their work on RFC 4962. + We would like to thank Reddy Tirumaleswar for his review. + 11. References 11.1. Normative References - [I-D.bradley-oauth-pop-key-distribution] - Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, - "OAuth 2.0 Proof-of-Possession: Authorization Server to - Client Key Distribution", draft-bradley-oauth-pop-key- - distribution-01 (work in progress), June 2014. - [I-D.ietf-httpbis-p1-messaging] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", draft-ietf- httpbis-p1-messaging-26 (work in progress), February 2014. [I-D.ietf-jose-json-web-encryption] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", - draft-ietf-jose-json-web-encryption-31 (work in progress), - July 2014. + draft-ietf-jose-json-web-encryption-40 (work in progress), + January 2015. + + [I-D.ietf-oauth-introspection] + ietf@justin.richer.org, i., "OAuth 2.0 Token + Introspection", draft-ietf-oauth-introspection-05 (work in + progress), February 2015. [I-D.ietf-oauth-json-web-token] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token - (JWT)", draft-ietf-oauth-json-web-token-25 (work in - progress), July 2014. + (JWT)", draft-ietf-oauth-json-web-token-32 (work in + progress), December 2014. - [I-D.jones-oauth-proof-of-possession] + [I-D.ietf-oauth-pop-key-distribution] + Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, + "OAuth 2.0 Proof-of-Possession: Authorization Server to + Client Key Distribution", draft-ietf-oauth-pop-key- + distribution-00 (work in progress), July 2014. + + [I-D.ietf-oauth-proof-of-possession] Jones, M., Bradley, J., and H. Tschofenig, "Proof-Of- Possession Semantics for JSON Web Tokens (JWTs)", draft- - jones-oauth-proof-of-possession-02 (work in progress), - July 2014. - - [I-D.richer-oauth-introspection] - Richer, J., "OAuth Token Introspection", draft-richer- - oauth-introspection-06 (work in progress), July 2014. + ietf-oauth-proof-of-possession-01 (work in progress), + January 2015. - [I-D.richer-oauth-signed-http-request] + [I-D.ietf-oauth-signed-http-request] Richer, J., Bradley, J., and H. Tschofenig, "A Method for - Signing an HTTP Requests for OAuth", draft-richer-oauth- - signed-http-request-01 (work in progress), April 2014. - - [I-D.tschofenig-oauth-audience] - Tschofenig, H., "OAuth 2.0: Audience Information", draft- - tschofenig-oauth-audience-00 (work in progress), February - 2013. + Signing an HTTP Requests for OAuth", draft-ietf-oauth- + signed-http-request-00 (work in progress), July 2014. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -984,28 +994,28 @@ January 2013. Authors' Addresses Phil Hunt (editor) Oracle Corporation Email: phil.hunt@yahoo.com Justin Richer - The MITRE Corporation - Email: jricher@mitre.org + Email: ietf@justin.richer.org William Mills Email: wmills@yahoo-inc.com Prateek Mishra Oracle Corporation Email: prateek.mishra@oracle.com Hannes Tschofenig ARM Limited + Hall in Tirol 6060 Austria Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at