draft-ietf-oauth-pop-architecture-06.txt   draft-ietf-oauth-pop-architecture-07.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: May 27, 2016 Expires: June 3, 2016
W. Mills W. Mills
P. Mishra P. Mishra
Oracle Corporation Oracle Corporation
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
November 24, 2015 December 1, 2015
OAuth 2.0 Proof-of-Possession (PoP) Security Architecture OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
draft-ietf-oauth-pop-architecture-06.txt draft-ietf-oauth-pop-architecture-07.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 be of a cryptographic key). To prevent misuse, bearer tokens must 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 May 27, 2016. This Internet-Draft will expire on June 3, 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 6, line 48 skipping to change at page 6, line 48
access token. access token.
Token repudiation: Token repudiation:
Token repudiation refers to a property whereby a resource server Token repudiation refers to a property whereby a resource server
is given an assurance that the authorization server cannot deny to is given an assurance that the authorization server cannot deny to
have created a token for the client. have created a token for the client.
5. Requirements 5. Requirements
In contrast to bearer tokens [RFC6750] which call for tokens that are
opaque to OAuth 2.0 clients, this specification defines the
requirements for proof-of-possession ("PoP") tokens that may be
parsed and verified by OAuth 2.0 clients and relying parties. In
general, a "PoP" token enables an OAuth 2.0 client to demonstrate a
proof-of-possession confirming the client's right to wield the token.
RFC 4962 [RFC4962] gives useful guidelines for designers of RFC 4962 [RFC4962] gives useful guidelines for designers of
authentication and key management protocols. While RFC 4962 was authentication and key management protocols. While RFC 4962 was
written with the AAA framework used for network access authentication written with the AAA framework used for network access authentication
in mind the offered suggestions are useful for the design of other in mind the offered suggestions are useful for the design of other
key management systems as well. The following requirements list key management systems as well. The following requirements list
applies OAuth 2.0 terminology to the requirements outlined in RFC applies OAuth 2.0 terminology to the requirements outlined in RFC
4962. 4962.
These requirements include These requirements include
skipping to change at page 10, line 51 skipping to change at page 10, line 44
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, for example, in the access token content and a standardized solution, for example, in the
form of a JSON-based format, is available with the JWT [RFC7519]. form of a JSON-based format, is available with the JWT [RFC7519].
6. Threat Mitigation 6. Threat Mitigation
A large range of threats can be mitigated by protecting the content A large range of threats can be mitigated by protecting the content
of the token, for example using a digital signature or a keyed of the token, for example using a digital signature or a keyed
message digest. Alternatively, the content of the token could be message digest. Alternatively, the content of the token could be
passed by reference rather than by value (requiring a separate passed by reference rather than by value (requiring a separate
message exchange to resolve the reference to the token content). To message exchange to resolve the reference to the token content).
simplify the subsequent description we assume in the PoP architecture
that the token itself is digitally signed by the authorization server To simplify discussion in the following example we assume that the
and therefore cannot be modified. token itself cannot be modified by the client, either due to
cryptographic protection (such as signature or encryption) or use of
a reference value with sufficient entropy and associated secure
lookup. The token remains opaque to the client. These are
characteristics shared with bearer tokens and more information on
best practices can be found in [RFC6819] and in the security
considerations section of [RFC6750].
To deal with token redirect it is important for the authorization To deal with token redirect it is important for the authorization
server to include the identifier of the intended recipient - the server to include the identifier of the intended recipient - the
resource server. A resource server must not be allowed to accept resource server. A resource server must not be allowed to accept
access tokens that are not meant for its consumption. access tokens that are not meant for its consumption.
To provide protection against token disclosure two approaches are To provide protection against token disclosure two approaches are
possible, namely (a) not to include sensitive information inside the possible, namely (a) not to include sensitive information inside the
token or (b) to ensure confidentiality protection. The latter token or (b) to ensure confidentiality protection. The latter
approach requires at least the communication interaction between the approach requires at least the communication interaction between the
skipping to change at page 20, line 26 skipping to change at page 20, line 26
[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-02 (work in progress), October 2015. distribution-02 (work in progress), October 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 Key Semantics for JSON Web Tokens (JWTs)", Possession Key Semantics for JSON Web Tokens (JWTs)",
draft-ietf-oauth-proof-of-possession-06 (work in draft-ietf-oauth-proof-of-possession-08 (work in
progress), November 2015. progress), November 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-01 (work in progress), March 2015. signed-http-request-01 (work in progress), March 2015.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
 End of changes. 7 change blocks. 
16 lines changed or deleted 15 lines changed or added

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