< draft-ietf-oauth-pop-architecture-01.txt   draft-ietf-oauth-pop-architecture-02.txt >
OAuth P. Hunt, Ed. OAuth P. Hunt, Ed.
Internet-Draft Oracle Corporation Internet-Draft Oracle Corporation
Intended status: Informational J. Richer Intended status: Informational J. Richer
Expires: September 4, 2015 Expires: January 7, 2016
W. Mills W. Mills
P. Mishra P. Mishra
Oracle Corporation Oracle Corporation
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
March 3, 2015 July 6, 2015
OAuth 2.0 Proof-of-Possession (PoP) Security Architecture OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
draft-ietf-oauth-pop-architecture-01.txt draft-ietf-oauth-pop-architecture-02.txt
Abstract Abstract
The OAuth 2.0 bearer token specification, as defined in RFC 6750, 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 allows any party in possession of a bearer token (a "bearer") to get
access to the associated resources (without demonstrating possession access to the associated resources (without demonstrating possession
of a cryptographic key). To prevent misuse, bearer tokens must to be of a cryptographic key). To prevent misuse, bearer tokens must to be
protected from disclosure in transit and at rest. protected from disclosure in transit and at rest.
Some scenarios demand additional security protection whereby a client Some scenarios demand additional security protection whereby a client
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.3. Access to a Non-TLS Protected Resource . . . . . . . . . 4 3.3. Access to a Non-TLS Protected Resource . . . . . . . . . 4
3.4. Offering Application Layer End-to-End Security . . . . . 5 3.4. Offering Application Layer End-to-End Security . . . . . 5
4. Security and Privacy Threats . . . . . . . . . . . . . . . . 5 4. Security and Privacy Threats . . . . . . . . . . . . . . . . 5
5. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 6 5. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Confidentiality Protection . . . . . . . . . . . . . . . 7 5.1. Confidentiality Protection . . . . . . . . . . . . . . . 7
5.2. Sender Constraint . . . . . . . . . . . . . . . . . . . . 7 5.2. Sender Constraint . . . . . . . . . . . . . . . . . . . . 7
5.3. Key Confirmation . . . . . . . . . . . . . . . . . . . . 8 5.3. Key Confirmation . . . . . . . . . . . . . . . . . . . . 8
5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
At the time of writing the OAuth 2.0 protocol family ([RFC6749], At the time of writing the OAuth 2.0 protocol family ([RFC6749],
[RFC6750], and [RFC6819]) offer a single standardized security [RFC6750], and [RFC6819]) offer a single standardized security
mechanism to access protected resources, namely the bearer token. mechanism to access protected resources, namely the bearer token.
RFC 6750 [RFC6750] specifies the bearer token mechanism and defines RFC 6750 [RFC6750] specifies the bearer token mechanism and defines
it as follows: it as follows:
"A security token with the property that any party in possession "A security token with the property that any party in possession
skipping to change at page 5, line 50 skipping to change at page 5, line 50
Token manufacture/modification: Token manufacture/modification:
An attacker may generate a bogus tokens or modify the token An attacker may generate a bogus tokens or modify the token
content (such as authentication or attribute statements) of an content (such as authentication or attribute statements) of an
existing token, causing resource server to grant inappropriate existing token, causing resource server to grant inappropriate
access to the client. For example, an attacker may modify the access to the client. For example, an attacker may modify the
token to extend the validity period. A client 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 token to have access to information that they should not be able
to view. to view.
Token disclosure: Tokens may contain personal data, such as real Token disclosure:
name, age or birthday, payment information, etc.
Tokens may contain personal data, such as real name, age or
birthday, payment information, etc.
Token redirect: Token redirect:
An attacker uses the token generated for consumption by the An attacker uses the token generated for consumption by the
resource server to obtain access to another resource server. resource server to obtain access to another resource server.
Token reuse: Token reuse:
An attacker attempts to use a token that has already been used An attacker attempts to use a token that has already been used
once with a resource server. The attacker may be an eavesdropper once with a resource server. The attacker may be an eavesdropper
skipping to change at page 10, line 32 skipping to change at page 10, line 34
There are slight differences between the use of symmetric keys and There are slight differences between the use of symmetric keys and
asymmetric keys when they are bound to the access token and the asymmetric keys when they are bound to the access token and the
subsequent interaction between the client and the authorization subsequent interaction between the client and the authorization
server when demonstrating possession of these keys. Figure 1 shows server when demonstrating possession of these keys. Figure 1 shows
the symmetric key procedure and Figure 2 illustrates how asymmetric the symmetric key procedure and Figure 2 illustrates how asymmetric
keys are used. While symmetric cryptography provides better keys are used. While symmetric cryptography provides better
performance properties the use of asymmetric cryptography allows the performance properties the use of asymmetric cryptography allows the
client to keep the private key locally and never expose it to any client to keep the private key locally and never expose it to any
other party. other party.
With the JSON Web Token (JWT) [I-D.ietf-oauth-json-web-token] a With the JSON Web Token (JWT) [RFC7519] a standardized format for
standardized format for access tokens is available. The necessary access tokens is available. The necessary elements to bind symmetric
elements to bind symmetric or asymmetric keys to a JWT are described or asymmetric keys to a JWT are described in
in [I-D.ietf-oauth-proof-of-possession]. [I-D.ietf-oauth-proof-of-possession].
Note: The negotiation of cryptographic algorithms between the client Note: The negotiation of cryptographic algorithms between the client
and the authorization server is not shown in the examples below and and the authorization server is not shown in the examples below and
assumed to be present in a protocol solution to meet the requirements assumed to be present in a protocol solution to meet the requirements
for crypto-agility. for crypto-agility.
+---------------+ +---------------+
^| | ^| |
// | Authorization | // | Authorization |
/ | Server | / | Server |
skipping to change at page 18, line 45 skipping to change at page 18, line 45
performance asymmetric cryptography offers additional security performance asymmetric cryptography offers additional security
properties. A solution MUST therefore offer the capability to properties. A solution MUST therefore offer the capability to
support both symmetric as well as asymmetric keys. support both symmetric as well as asymmetric keys.
There are threats that relate to the experience of the software There are threats that relate to the experience of the software
developer as well as operational practices. Verifying the servers developer as well as operational practices. Verifying the servers
identity in TLS is discussed at length in [RFC6125]. identity in TLS is discussed at length in [RFC6125].
A number of the threats listed in Section 4 demand protection of the 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- access token content and a standardized solution, in form of a JSON-
based format, is available with the JWT based format, is available with the JWT [RFC7519].
[I-D.ietf-oauth-json-web-token].
8. Security Considerations 8. Security Considerations
The purpose of this document is to provide use cases, requirements, The purpose of this document is to provide use cases, requirements,
and motivation for developing an OAuth security solution extending and motivation for developing an OAuth security solution extending
Bearer Tokens. As such, this document is only about security. Bearer Tokens. As such, this document is only about security.
9. IANA Considerations 9. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
skipping to change at page 19, line 36 skipping to change at page 19, line 30
In the appendix of this document we re-use content from [RFC4962] and 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 the authors would like thank Russ Housely and Bernard Aboba for their
work on RFC 4962. work on RFC 4962.
We would like to thank Reddy Tirumaleswar for his review. We would like to thank Reddy Tirumaleswar for his review.
11. References 11. References
11.1. Normative 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] [I-D.ietf-oauth-introspection]
ietf@justin.richer.org, i., "OAuth 2.0 Token Richer, J., "OAuth 2.0 Token Introspection", draft-ietf-
Introspection", draft-ietf-oauth-introspection-05 (work in oauth-introspection-11 (work in progress), July 2015.
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.
[I-D.ietf-oauth-pop-key-distribution] [I-D.ietf-oauth-pop-key-distribution]
Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, Bradley, J., Hunt, P., Jones, M., and H. Tschofenig,
"OAuth 2.0 Proof-of-Possession: Authorization Server to "OAuth 2.0 Proof-of-Possession: Authorization Server to
Client Key Distribution", draft-ietf-oauth-pop-key- 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] [I-D.ietf-oauth-proof-of-possession]
Jones, M., Bradley, J., and H. Tschofenig, "Proof-Of- Jones, M., Bradley, J., and H. Tschofenig, "Proof-Of-
Possession Semantics for JSON Web Tokens (JWTs)", draft- Possession Semantics for JSON Web Tokens (JWTs)", draft-
ietf-oauth-proof-of-possession-01 (work in progress), ietf-oauth-proof-of-possession-02 (work in progress),
January 2015. March 2015.
[I-D.ietf-oauth-signed-http-request] [I-D.ietf-oauth-signed-http-request]
Richer, J., Bradley, J., and H. Tschofenig, "A Method for Richer, J., Bradley, J., and H. Tschofenig, "A Method for
Signing an HTTP Requests for OAuth", draft-ietf-oauth- Signing an HTTP Requests for OAuth", draft-ietf-oauth-
signed-http-request-00 (work in progress), July 2014. signed-http-request-01 (work in progress), March 2015.
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (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 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012. 6749, October 2012.
[W3C.REC-html401-19991224] [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 (JWT)", RFC 7519, May 2015.
Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>.
11.2. Informative References 11.2. Informative References
[I-D.hardjono-oauth-kerberos] [I-D.hardjono-oauth-kerberos]
Hardjono, T., "OAuth 2.0 support for the Kerberos V5 Hardjono, T., "OAuth 2.0 support for the Kerberos V5
Authentication Protocol", draft-hardjono-oauth-kerberos-01 Authentication Protocol", draft-hardjono-oauth-kerberos-01
(work in progress), December 2010. (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] [NIST800-63]
Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S.,
and E. Nabbus, "NIST Special Publication 800-63-1, and E. Nabbus, "NIST Special Publication 800-63-1,
INFORMATION SECURITY", December 2008. 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 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, December for Transport Layer Security (TLS)", RFC 4279, December
2005. 2005.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", BCP Authorization, and Accounting (AAA) Key Management", BCP
132, RFC 4962, July 2007. 132, RFC 4962, July 2007.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, November 2007.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010. 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 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012. Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
 End of changes. 20 change blocks. 
81 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/