draft-ietf-oauth-proof-of-possession-07.txt   draft-ietf-oauth-proof-of-possession-08.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: May 27, 2016 Ping Identity Expires: June 2, 2016 Ping Identity
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
November 24, 2015 November 30, 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-07 draft-ietf-oauth-proof-of-possession-08
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. Being able to prove 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 May 27, 2016. This Internet-Draft will expire on June 2, 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 31 skipping to change at page 2, line 31
3.5. Representation of a URL for a Proof-of-Possession Key . . 9 3.5. Representation of a URL for a Proof-of-Possession Key . . 9
3.6. Specifics Intentionally Not Specified . . . . . . . . . . 10 3.6. Specifics Intentionally Not Specified . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. JSON Web Token Claims Registration . . . . . . . . . . . . 12 6.1. JSON Web Token Claims Registration . . . . . . . . . . . . 12
6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 12 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 12
6.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 12 6.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 12
6.2.1. Registration Template . . . . . . . . . . . . . . . . 12 6.2.1. Registration Template . . . . . . . . . . . . . . . . 12
6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 13 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
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) [JWT] can This specification defines how a JSON Web Token (JWT) [JWT] can
declare that the presenter of the JWT possesses a key and that the declare that the presenter of the JWT possesses a key and that the
recipient can cryptographically confirm that the presenter possesses recipient can cryptographically confirm that the presenter possesses
that key. Proof-of-possession of a key is also sometimes described that key. Proof-of-possession of a key is also sometimes described
skipping to change at page 10, line 47 skipping to change at page 10, line 47
All of the security considerations that are discussed in JWT [JWT] All of the security considerations that are discussed in JWT [JWT]
also apply here. In addition, proof-of-possession introduces its own also 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.
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
challenged for each interaction. challenge for each interaction.
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, in which case it A recipient might not understand the "cnf" claim. Applications that
will typically be ignored. Unless this is acceptable behavior, require the proof-of-possession keys communicated with it to be
applications that need the proof-of-possession keys communicated with understood and processed must ensure that the parts of this
it to be understood and processed must require that the parts of this specification that they use are implemented.
specification that they use be implemented.
Applications utilizing proof-of-possession should also utilize
audience restriction, as they provide 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
skipping to change at page 15, line 33 skipping to change at page 15, line 41
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors wish to thank Brian Campbell, Kepeng Li, James Manger, The authors wish to thank Brian Campbell, Kepeng Li, James Manger,
Kathleen Moriarty, Justin Richer, and Nat Sakimura for their reviews Kathleen Moriarty, Justin Richer, and Nat Sakimura for their reviews
of the specification. 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 ]]
-08
o Added security consideration about also utilizing audience
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.
o Clarified that confirmation members that are not understood must o Clarified that confirmation members that are not understood must
be ignored unless otherwise specified by the application. be ignored unless otherwise specified by the application.
 End of changes. 8 change blocks. 
13 lines changed or deleted 23 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/