draft-ietf-oauth-proof-of-possession-10.txt   draft-ietf-oauth-proof-of-possession-11.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: June 18, 2016 Ping Identity Expires: June 20, 2016 Ping Identity
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
December 16, 2015 December 18, 2015
Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
draft-ietf-oauth-proof-of-possession-10 draft-ietf-oauth-proof-of-possession-11
Abstract Abstract
This specification defines how to declare in a JSON Web Token (JWT) This specification defines how to declare in a JSON Web Token (JWT)
that the presenter of the JWT possesses a particular proof-of- that the presenter of the JWT possesses a particular proof-of-
possession key and that the recipient can cryptographically confirm possession key and that the recipient can cryptographically confirm
proof-of-possession of the key by the presenter. Being able to prove proof-of-possession of the key by the presenter. Being able to prove
possession of a key is also sometimes described as the presenter possession of a key is also sometimes described as the presenter
being a holder-of-key. being a holder-of-key.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 June 18, 2016. This Internet-Draft will expire on June 20, 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 3, line 9 skipping to change at page 3, line 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Appendix B. Document History . . . . . . . . . . . . . . . . . . 15 Appendix B. Document History . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This specification defines how a JSON Web Token [JWT] can declare This specification defines how a JSON Web Token [JWT] can declare
that the presenter of the JWT possesses a particular proof-of- that the presenter of the JWT possesses a particular proof-of-
possession key and that the recipient can cryptographically confirm possession (PoP) key and that the recipient can cryptographically
proof-of-possession of the key by the presenter. Proof-of-possession confirm proof-of-possession of the key by the presenter. Proof-of-
of a key is also sometimes described as the presenter being a holder- possession of a key is also sometimes described as the presenter
of-key. The [I-D.ietf-oauth-pop-architecture] specification being a holder-of-key. The [I-D.ietf-oauth-pop-architecture]
describes key confirmation, among other confirmation mechanisms. specification describes key confirmation, among other confirmation
This specification defines how to communicate key confirmation key mechanisms. This specification defines how to communicate key
information in JWTs. confirmation key information in JWTs.
Envision the following two use cases. The first use case employs a Envision the following two use cases. The first use case employs a
symmetric proof-of-possession key and the second use case employs an symmetric proof-of-possession key and the second use case employs an
asymmetric proof-of-possession key. asymmetric proof-of-possession key.
+--------------+ +--------------+
| | +--------------+ | | +--------------+
| |--(3) Presentation of -->| | | |--(3) Presentation of -->| |
| | JWT w/ Encrypted | | | | JWT w/ Encrypted | |
| Presenter | PoP Key | | | Presenter | PoP Key | |
skipping to change at page 4, line 20 skipping to change at page 4, line 20
demonstrate possession of the symmetric key; the presenter, for demonstrate possession of the symmetric key; the presenter, for
example, (4) uses the symmetric key in a challenge/response protocol example, (4) uses the symmetric key in a challenge/response protocol
with the recipient. The recipient is then able to verify that it is with the recipient. The recipient is then able to verify that it is
interacting with the genuine presenter by decrypting the key in the interacting with the genuine presenter by decrypting the key in the
confirmation claim of the JWT. By doing this, the recipient obtains confirmation claim of the JWT. By doing this, the recipient obtains
the symmetric key, which it then uses to verify cryptographically the symmetric key, which it then uses to verify cryptographically
protected messages exchanged with the presenter (4). This symmetric protected messages exchanged with the presenter (4). This symmetric
key mechanism described above is conceptually similar to the use of key mechanism described above is conceptually similar to the use of
Kerberos tickets. Kerberos tickets.
Note that for simplicity, the diagram above and associated text
describe the direct use of symmetric keys without the use of derived
keys. A more secure practice is to derive the symmetric keys
actually used from secrets exchanged, such as the key exchanged in
step (0), using a Key Derivation Function (KDF) and use the derived
keys, rather than directly using the secrets exchanged.
+--------------+ +--------------+
| | +--------------+ | | +--------------+
| |--(3) Presentation of -->| | | |--(3) Presentation of -->| |
| | JWT w/ Public | | | | JWT w/ Public | |
| Presenter | PoP Key | | | Presenter | PoP Key | |
| | | | | | | |
| |<-(4) Communication ---->| | | |<-(4) Communication ---->| |
| | Authenticated by | | | | Authenticated by | |
+--------------+ PoP Key | | +--------------+ PoP Key | |
| ^ | | | ^ | |
skipping to change at page 10, line 44 skipping to change at page 10, line 44
[I-D.ietf-oauth-pop-architecture]. [I-D.ietf-oauth-pop-architecture].
4. Security Considerations 4. Security Considerations
All of the security considerations that are discussed in [JWT] also All of the security considerations that are discussed in [JWT] also
apply here. In addition, proof-of-possession introduces its own apply here. In addition, proof-of-possession introduces its own
unique security issues. Possessing a key is only valuable if it is unique security issues. Possessing a key is only valuable if it is
kept secret. Appropriate means must be used to ensure that kept secret. Appropriate means must be used to ensure that
unintended parties do not learn private key or symmetric key values. unintended parties do not learn private key or symmetric key values.
Applications utilizing proof-of-possession should also utilize
audience restriction, as described in Section 4.1.3 of [JWT], as it
provides different protections. Proof-of-possession can be used by
recipients to reject messages from unauthorized senders. Audience
restriction can be used by recipients to reject messages intended for
different recipients.
A recipient might not understand the "cnf" claim. Applications that
require the proof-of-possession keys communicated with it to be
understood and processed must ensure that the parts of this
specification that they use are implemented.
Proof-of-possession via encrypted symmetric secrets is subject to Proof-of-possession via encrypted symmetric secrets is subject to
replay attacks. This attack can be avoided when a signed nonce or replay attacks. This attack can be avoided when a signed nonce or
challenge is used, since the recipient can use a distinct nonce or challenge is used, since the recipient can use a distinct nonce or
challenge for each interaction. challenge for each interaction. Replay can also be avoided if a sub-
key is derived from a shared secret that is specific to the instance
of the PoP demonstration.
Similarly to other information included in a JWT, it is necessary to Similarly to other information included in a JWT, it is necessary to
apply data origin authentication and integrity protection (via a apply data origin authentication and integrity protection (via a
keyed message digest or a digital signature). Data origin keyed message digest or a digital signature). Data origin
authentication ensures that the recipient of the JWT learns about the authentication ensures that the recipient of the JWT learns about the
entity that created the JWT, since this will be important for any entity that created the JWT, since this will be important for any
policy decisions. Integrity protection prevents an adversary from policy decisions. Integrity protection prevents an adversary from
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 might not understand the "cnf" claim. Applications that
require the proof-of-possession keys communicated with it to be
understood and processed must ensure that the parts of this
specification that they use are implemented.
Applications utilizing proof-of-possession should also utilize
audience restriction, as described in Section 4.1.3 of [JWT], as it
provides different protections. Proof-of-possession can be used by
recipients to reject messages from unauthorized senders. Audience
restriction can be used by recipients to reject messages intended for
different recipients.
5. Privacy Considerations 5. Privacy Considerations
A proof-of-possession key can be used as a correlation handle if the A proof-of-possession key can be used as a correlation handle if the
same key is used with multiple parties. Thus, for privacy reasons, same key is used with multiple parties. Thus, for privacy reasons,
it is recommended that different proof-of-possession keys be used it is recommended that different proof-of-possession keys be used
when interacting with different parties. when interacting with different parties.
6. IANA Considerations 6. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
skipping to change at page 12, line 10 skipping to change at page 12, line 12
Registration requests sent to the mailing list for review should use Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register JWT Confirmation an appropriate subject (e.g., "Request to register JWT Confirmation
Method: example"). Registration requests that are undetermined for a Method: example"). Registration requests that are undetermined for a
period longer than 21 days can be brought to the IESG's attention period longer than 21 days can be brought to the IESG's attention
(using the iesg@ietf.org mailing list) for resolution. (using the iesg@ietf.org mailing list) for resolution.
Criteria that should be applied by the Designated Experts include Criteria that should be applied by the Designated Experts include
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
functionality, determining whether it is likely to be of general functionality, determining whether it is likely to be of general
applicability or whether it is useful only for a single application, applicability or whether it is useful only for a single application,
and whether the registration makes sense. evaluating the security properties of the item being registered, and
whether the registration makes sense.
It is suggested that multiple Designated Experts be appointed who are It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using able to represent the perspectives of different applications using
this specification, in order to enable broadly-informed review of this specification, in order to enable broadly-informed review of
registration decisions. In cases where a registration decision could registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular be perceived as creating a conflict of interest for a particular
Expert, that Expert should defer to the judgment of the other Expert, that Expert should defer to the judgment of the other
Experts. Experts.
6.1. JSON Web Token Claims Registration 6.1. JSON Web Token Claims Registration
skipping to change at page 15, line 24 skipping to change at page 15, line 24
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.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", November 2014, C. Mortimore, "OpenID Connect Core 1.0", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors wish to thank Brian Campbell, Kepeng Li, James Manger, The authors wish to thank Brian Campbell, Stephen Farrell, Barry
Kathleen Moriarty, Justin Richer, and Nat Sakimura for their reviews Leiba, Kepeng Li, Chris Lonvick, James Manger, Kathleen Moriarty,
of the specification. Justin Richer, and Nat Sakimura for their reviews of the
specification.
Appendix B. Document History Appendix B. 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 ]]
-11
o Addressed Sec-Dir review comments by Chris Lonvick and ballot
comments by Stephen Farrell.
-10 -10
o Addressed review comments by Barry Leiba. o Addressed ballot comments by Barry Leiba.
-09 -09
o Removed erroneous quotation marks around numeric "exp" claim o Removed erroneous quotation marks around numeric "exp" claim
values in examples. values in examples.
-08 -08
o Added security consideration about also utilizing audience o Added security consideration about also utilizing audience
restriction. restriction.
-07 -07
o Addressed review comments by Hannes Tschofenig, Kathleen Moriarty, o Addressed review comments by Hannes Tschofenig, Kathleen Moriarty,
and Justin Richer. Changes were: and Justin Richer. Changes were:
o Clarified that symmetric proof-of-possession keys can be generated o Clarified that symmetric proof-of-possession keys can be generated
by either the presenter or the issuer. by either the presenter or the issuer.
 End of changes. 14 change blocks. 
30 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/