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/