--- 1/draft-ietf-oauth-pop-architecture-01.txt 2015-07-06 08:15:04.793837567 -0700 +++ 2/draft-ietf-oauth-pop-architecture-02.txt 2015-07-06 08:15:04.873839502 -0700 @@ -1,25 +1,25 @@ OAuth P. Hunt, Ed. Internet-Draft Oracle Corporation Intended status: Informational J. Richer -Expires: September 4, 2015 +Expires: January 7, 2016 W. Mills P. Mishra Oracle Corporation H. Tschofenig ARM Limited - March 3, 2015 + July 6, 2015 OAuth 2.0 Proof-of-Possession (PoP) Security Architecture - draft-ietf-oauth-pop-architecture-01.txt + draft-ietf-oauth-pop-architecture-02.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,21 +35,21 @@ 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 September 4, 2015. + This Internet-Draft will expire on January 7, 2016. Copyright Notice 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 @@ -69,27 +69,27 @@ 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 . . . . . . . . . . . . . . . . . . . 19 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 11.2. Informative References . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 11.2. Informative References . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction At the time of writing the OAuth 2.0 protocol family ([RFC6749], [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely the bearer token. RFC 6750 [RFC6750] specifies the bearer token mechanism and defines it as follows: "A security token with the property that any party in possession @@ -227,22 +227,24 @@ Token manufacture/modification: An attacker may generate a bogus tokens or modify the token content (such as authentication or attribute statements) of an existing token, causing resource server to grant inappropriate access to the client. For example, an attacker may modify the token to extend the validity period. A client may modify the token to have access to information that they should not be able to view. - Token disclosure: Tokens may contain personal data, such as real - name, age or birthday, payment information, etc. + Token disclosure: + + Tokens may contain personal data, such as real name, age or + birthday, payment information, etc. Token redirect: An attacker uses the token generated for consumption by the resource server to obtain access to another resource server. Token reuse: An attacker attempts to use a token that has already been used once with a resource server. The attacker may be an eavesdropper @@ -448,24 +450,24 @@ 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. 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) [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]. + With the JSON Web Token (JWT) [RFC7519] 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 | @@ -818,22 +820,21 @@ 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]. A number of the threats listed in Section 4 demand protection of the access token content and a standardized solution, in form of a JSON- - based format, is available with the JWT - [I-D.ietf-oauth-json-web-token]. + based format, is available with the JWT [RFC7519]. 8. Security Considerations The purpose of this document is to provide use cases, requirements, and motivation for developing an OAuth security solution extending Bearer Tokens. As such, this document is only about security. 9. IANA Considerations This document does not require actions by IANA. @@ -852,141 +853,83 @@ 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.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-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-32 (work in - progress), December 2014. + Richer, J., "OAuth 2.0 Token Introspection", draft-ietf- + oauth-introspection-11 (work in progress), July 2015. [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. + distribution-01 (work in progress), March 2015. [I-D.ietf-oauth-proof-of-possession] Jones, M., Bradley, J., and H. Tschofenig, "Proof-Of- Possession Semantics for JSON Web Tokens (JWTs)", draft- - ietf-oauth-proof-of-possession-01 (work in progress), - January 2015. + ietf-oauth-proof-of-possession-02 (work in progress), + March 2015. [I-D.ietf-oauth-signed-http-request] Richer, J., Bradley, J., and H. Tschofenig, "A Method for 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. + signed-http-request-01 (work in progress), March 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext - Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. - - [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., - Leach, P., Luotonen, A., and L. Stewart, "HTTP - Authentication: Basic and Digest Access Authentication", - RFC 2617, June 1999. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, RFC - 3986, January 2005. - - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 5226, - May 2008. - [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. - [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, - April 2011. - [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. - [W3C.REC-html401-19991224] - Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 - Specification", World Wide Web Consortium Recommendation - REC-html401-19991224, December 1999, - . + [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token + (JWT)", RFC 7519, May 2015. 11.2. Informative References [I-D.hardjono-oauth-kerberos] Hardjono, T., "OAuth 2.0 support for the Kerberos V5 Authentication Protocol", draft-hardjono-oauth-kerberos-01 (work in progress), December 2010. - [NIST-FIPS-180-3] - National Institute of Standards and Technology, "Secure - Hash Standard (SHS). FIPS PUB 180-3, October 2008", - October 2008. - [NIST800-63] Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., and E. Nabbus, "NIST Special Publication 800-63-1, INFORMATION SECURITY", December 2008. - [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness - Requirements for Security", BCP 106, RFC 4086, June 2005. - [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010. - [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings - for TLS", RFC 5929, July 2010. - [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011. [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012. [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0