draft-ietf-oauth-proof-of-possession-00.txt   draft-ietf-oauth-proof-of-possession-01.txt 
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: January 22, 2015 Ping Identity Expires: August 1, 2015 Ping Identity
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
July 21, 2014 January 28, 2015
Proof-Of-Possession Semantics for JSON Web Tokens (JWTs) Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
draft-ietf-oauth-proof-of-possession-00.txt draft-ietf-oauth-proof-of-possession-01
Abstract Abstract
This specification defines how to express a declaration in a JSON Web This specification defines how to express a declaration in a JSON Web
Token (JWT) that the presenter of the JWT possesses a particular key Token (JWT) that the presenter of the JWT possesses a particular key
and that the recipient can cryptographically confirm proof-of- and that the recipient can cryptographically confirm proof-of-
possession of the key by the presenter. This property is also possession of the key by the presenter. This property is also
sometimes described as the presenter being a holder-of-key. sometimes described as the presenter being a holder-of-key.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 22, 2015. This Internet-Draft will expire on August 1, 2015.
Copyright Notice 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. 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Proof-Of-Possession Representation . . . . . . . . . . . . . 3 3. Proof-Of-Possession Representation . . . . . . . . . . . . . . 4
3.1. Proof-of-Possession of an Asymmetric Key . . . . . . . . 4 3.1. Proof-of-Possession of an Asymmetric Key . . . . . . . . . 4
3.2. Proof-of-Possession of a Symmetric Key . . . . . . . . . 4 3.2. Proof-of-Possession of a Symmetric Key . . . . . . . . . . 5
3.3. Confirmation . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Specifics Intentionally Not Specified . . . . . . . . . . 6 3.4. Specifics Intentionally Not Specified . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. JSON Web Token Claims Registration . . . . . . . . . . . 8 5.1. JSON Web Token Claims Registration . . . . . . . . . . . . 8
5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 8 5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 8
5.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 8 5.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 8
5.2.1. Registration Template . . . . . . . . . . . . . . . . 8 5.2.1. Registration Template . . . . . . . . . . . . . . . . 9
5.2.2. Initial Registry Contents . . . . . . . . . . . . . . 9 5.2.2. Initial Registry Contents . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Appendix C. Document History . . . . . . . . . . . . . . . . . . 10 Appendix C. Document History . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This specification defines how to express a declaration in a JSON Web This specification defines how to express a declaration in a JSON Web
Token (JWT) [JWT] that the presenter of the JWT possesses a Token (JWT) [JWT] that the presenter of the JWT possesses a
particular key and that the recipient can cryptographically confirm particular key and that the recipient can cryptographically confirm
proof-of-possession of the key by the presenter. This property is proof-of-possession of the key by the presenter. This property is
also sometimes described as the presenter being a holder-of-key. also sometimes described as the presenter being a holder-of-key.
[[ Editorial Note: This paragraph needs to be updated to provide more [[ Editorial Note: This paragraph needs to be updated to provide more
context and possibly also to describe the use of asymmetric keys context and possibly also to describe the use of asymmetric keys
instead. It's not clear that the symmetric case is as useful or instead. It's not clear that the symmetric case is as useful or
valuable, and it is certainly more complicated.]] Envision the valuable, and it is certainly more complicated.]] Envision the
following use case: An OAuth 2.0 authorization server generates a JWT following use case: An OAuth 2.0 authorization server generates a JWT
and places an encrypted symmetric key inside the newly introduced and places an encrypted symmetric key inside the newly introduced
confirmation claim. This symmetric key is encrypted with a key known confirmation claim. This symmetric key is encrypted with a key known
only to the authorization server and the recipient. The JWT is then only to the authorization server and the recipient. The JWT is then
sent to the presenter. Since the presenter is unable to obtain the sent to the presenter. Since the presenter is unable to obtain the
encrypted symmetric key, the authorization server conveys that encrypted symmetric key, the authorization server conveys that
symmetric key separately to the presenter. Now, the presenter is in symmetric key separately to the presenter. Now, the presenter is in
possession of the symmetric key as well as the JWT (which includes possession of the symmetric key as well as the JWT (which includes
the confirmation claim member). When the presenter needs to utilize the confirmation claim member). When the presenter needs to utilize
the JWT to at recipient, it also needs to demonstrate possession of the JWT to at recipient, it also needs to demonstrate possession of
skipping to change at page 6, line 26 skipping to change at page 6, line 46
are intentionally not described in this specification, as different are intentionally not described in this specification, as different
protocols will communicate this information in different ways. protocols will communicate this information in different ways.
Likewise, the means of communicating the signed nonce is also not Likewise, the means of communicating the signed nonce is also not
specified, as this is also protocol-specific. specified, as this is also protocol-specific.
Note that another means of proving possession of the key when it is a Note that another means of proving possession of the key when it is a
symmetric key is to encrypt the key to the recipient. The means of symmetric key is to encrypt the key to the recipient. The means of
obtaining a key for the recipient is likewise protocol-specific. obtaining a key for the recipient is likewise protocol-specific.
For an example specification that uses the mechanisms defined in this For an example specification that uses the mechanisms defined in this
document, see [I-D.hunt-oauth-pop-architecture]. document, see [I-D.ietf-oauth-pop-architecture].
4. Security Considerations 4. Security Considerations
All of the normal security issues, especially in relationship to All of the normal security issues, especially in relationship to
comparing URIs and dealing with unrecognized values, that are comparing URIs and dealing with unrecognized values, that are
discussed in JWT [JWT] also apply here. discussed in JWT [JWT] also apply here.
In addition, proof-of-possession introduces its own unique security In addition, proof-of-possession introduces its own unique security
issues. Possessing the key is only valuable if it is kept secret. issues. Possessing the key is only valuable if it is kept secret.
Appropriate means must be used to ensure that unintended parties do Appropriate means must be used to ensure that unintended parties do
skipping to change at page 7, line 12 skipping to change at page 7, line 32
changing any elements conveyed within the JWT payload. Special care changing any elements conveyed within the JWT payload. Special care
has to be applied when carrying symmetric keys inside the JWT, since has to be applied when carrying symmetric keys inside the JWT, since
those not only require integrity protection, but also confidentiality those not only require integrity protection, but also confidentiality
protection. protection.
A recipient may not understand the newly introduced "cnf" claim and A recipient may not understand the newly introduced "cnf" claim and
may consequently treat it as a bearer token. While this is a may consequently treat it as a bearer token. While this is a
legitimate concern, it is outside the scope of this specification, legitimate concern, it is outside the scope of this specification,
since demonstration the possession of the key associated with the since demonstration the possession of the key associated with the
"cnf" claim is not covered by this specification. For more details, "cnf" claim is not covered by this specification. For more details,
please consult [I-D.hunt-oauth-pop-architecture]. please consult [I-D.ietf-oauth-pop-architecture].
5. IANA Considerations 5. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
established by this specification. established by this specification.
Values are registered with a Specification Required [RFC5226] after a Values are registered with a Specification Required [RFC5226] after a
two-week review period on the [TBD]@ietf.org mailing list, on the two-week review period on the [TBD]@ietf.org mailing list, on the
advice of one or more Designated Experts. However, to allow for the advice of one or more Designated Experts. However, to allow for the
allocation of values prior to publication, the Designated Expert(s) allocation of values prior to publication, the Designated Expert(s)
may approve registration once they are satisfied that such a may approve registration once they are satisfied that such a
specification will be published. specification will be published.
Registration requests must be sent to the [TBD]@ietf.org mailing list Registration requests must be sent to the [TBD]@ietf.org mailing list
for review and comment, with an appropriate subject (e.g., "Request for review and comment, with an appropriate subject (e.g., "Request
for access token type: example"). [[ Note to the RFC Editor: The for access token type: example"). [[ Note to the RFC Editor: The name
name of the mailing list should be determined in consultation with of the mailing list should be determined in consultation with the
the IESG and IANA. Suggested name: jwt-reg-review. ]] IESG and IANA. Suggested name: jwt-reg-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. Registration requests that are undetermined for a period successful. Registration requests that are undetermined for a period
longer than 21 days can be brought to the IESG's attention (using the longer than 21 days can be brought to the IESG's attention (using the
iesg@iesg.org mailing list) for resolution. iesg@iesg.org mailing list) for resolution.
Criteria that should be applied by the Designated Expert(s) includes Criteria that should be applied by the Designated Expert(s) includes
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
skipping to change at page 9, line 24 skipping to change at page 9, line 46
Web Key Web Key
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3 of [[ this document ]] o Specification Document(s): Section 3 of [[ this document ]]
6. References 6. References
6.1. Normative References 6.1. Normative References
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption (work in progress), draft-ietf-jose-json-web-encryption (work in progress),
July 2014. January 2015.
[JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web- [JWK] Jones, M., "JSON Web Key (JWK)",
key (work in progress), July 2014. draft-ietf-jose-json-web-key (work in progress),
January 2015.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token (work in (JWT)", draft-ietf-oauth-json-web-token (work in
progress), July 2014. progress), December 2014.
[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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
6.2. Informative References 6.2. Informative References
[I-D.hunt-oauth-pop-architecture] [I-D.ietf-oauth-pop-architecture]
Hunt, P., Richer, J., Mills, W., Mishra, P., and H. Hunt, P., Richer, J., Mills, W., Mishra, P., and H.
Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security
Architecture", draft-hunt-oauth-pop-architecture-02 (work Architecture", draft-ietf-oauth-pop-architecture-00 (work
in progress), June 2014. in progress), July 2014.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005. 2.0-os, March 2005.
Appendix A. Open Issues Appendix A. Open Issues
In some conversations, we have said that it is the issuer of the JWT In some conversations, we have said that it is the issuer of the JWT
skipping to change at page 10, line 27 skipping to change at page 10, line 49
Appendix B. Acknowledgements Appendix B. Acknowledgements
The authors wish to thank James Manger for his review of the The authors wish to thank James Manger for his review of the
specification. specification.
Appendix C. Document History Appendix C. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-02
o Used the same section structuring conventions as the JWT
specification.
o Reverted some changes introduced in -01 without adequate prior
review.
o Applied some editorial corrections.
-01 -01
o Updated references.
o Updated affiliation.
o Various editorial changes.
o Updates to the security considerations section based on review
feedback by James Manager.
o Included the kid element in the examples (as requested by James
Manger).
o Expanded the introduction section.
o Moved the terminology/RFC2119 boilerplate text from the
introduction to a separate terminology section.
-00 -00
o Wrote the first draft. o Created the initial working group draft from
draft-jones-oauth-proof-of-possession-02.
Authors' Addresses Authors' Addresses
Michael B. Jones Michael B. Jones
Microsoft Microsoft
Email: mbj@microsoft.com Email: mbj@microsoft.com
URI: http://self-issued.info/ URI: http://self-issued.info/
John Bradley John Bradley
 End of changes. 19 change blocks. 
61 lines changed or deleted 45 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/