< draft-ietf-ace-cwt-proof-of-possession-03.txt		draft-ietf-ace-cwt-proof-of-possession-04.txt >
	ACE M. Jones		ACE M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track L. Seitz		Intended status: Standards Track L. Seitz
	Expires: December 31, 2018 RISE SICS		Expires: May 10, 2019 RISE SICS
	G. Selander		G. Selander
	Ericsson AB		Ericsson AB
	S. Erdtman		S. Erdtman
	Spotify		Spotify
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	June 29, 2018		November 6, 2018
	Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)		Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
	draft-ietf-ace-cwt-proof-of-possession-03		draft-ietf-ace-cwt-proof-of-possession-04
	Abstract		Abstract
	This specification describes how to declare in a CBOR Web Token (CWT)		This specification describes how to declare in a CBOR Web Token (CWT)
	that the presenter of the CWT possesses a particular proof-of-		that the presenter of the CWT possesses a particular proof-of-
	possession key. Being able to prove possession of a key is also		possession key. Being able to prove possession of a key is also
	sometimes described as being the holder-of-key. This specification		sometimes described as being the holder-of-key. This specification
	provides equivalent functionality to "Proof-of-Possession Key		provides equivalent functionality to "Proof-of-Possession Key
	Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and		Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and
	CWTs rather than JSON and JWTs.		CWTs rather than JSON and JWTs.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 December 31, 2018.		This Internet-Draft will expire on May 10, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 13 ¶		skipping to change at page 6, line 13 ¶
	subsequently be encrypted for use in the "Encrypted_COSE_Key" member:		subsequently be encrypted for use in the "Encrypted_COSE_Key" member:
	{		{
	/kty/ 1 : /Symmetric/ 4,		/kty/ 1 : /Symmetric/ 4,
	/alg/ 3 : /HMAC256/ 5,		/alg/ 3 : /HMAC256/ 5,
	/k/ -1 : h'6684523ab17337f173500e5728c628547cb37df		/k/ -1 : h'6684523ab17337f173500e5728c628547cb37df
	e68449c65f885d1b73b49eae1A0B0C0D0E0F10'		e68449c65f885d1b73b49eae1A0B0C0D0E0F10'
	}		}
	The COSE_Key representation is used as the plaintext when encrypting		The COSE_Key representation is used as the plaintext when encrypting
	the key. The COSE_Key could, for instance, be encrypted using a		the key.
	COSE_Encrypt0 representation using the AES-CCM-16-64-128 algorithm.
	The following example CWT Claims Set of a CWT (using CBOR diagnostic		The following example CWT Claims Set of a CWT (using CBOR diagnostic
	notation, with linebreaks for readability) illustrates the use of an		notation, with linebreaks for readability) illustrates the use of an
	encrypted symmetric key as the "Encrypted_COSE_Key" member value:		encrypted symmetric key as the "Encrypted_COSE_Key" member value:
	{		{
	/iss/ 1 : "coaps://server.example.com",		/iss/ 1 : "coaps://server.example.com",
	/sub/ 2 : "24400320",		/sub/ 2 : "24400320",
	/aud/ 3: "s6BhdRkqt3",		/aud/ 3: "s6BhdRkqt3",
	/exp/ 4 : 1311281970,		/exp/ 4 : 1311281970,
	skipping to change at page 7, line 48 ¶		skipping to change at page 7, line 45 ¶
	4. Security Considerations		4. Security Considerations
	All of the security considerations that are discussed in [RFC8392]		All of the security considerations that are discussed in [RFC8392]
	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.
	Applications utilizing proof of possession SHOULD also utilize		Applications utilizing proof of possession SHOULD also utilize
	audience restriction, as described in Section 4.1.3 of [JWT], as it		audience restriction, as described in Section 4.1.3 of [JWT], as it
	provides additional protections. Proof of possession can be used by		provides additional protections. Audience restriction can be used by
	recipients to reject messages from unauthorized senders. Audience		recipients to reject messages intended for different recipients.
	restriction can be used by recipients to reject messages intended for
	different recipients.
	A recipient might not understand the "cnf" claim. Applications that		A recipient might not understand the "cnf" claim. Applications that
	require the proof-of-possession keys communicated with it to be		require the proof-of-possession keys communicated with it to be
	understood and processed MUST ensure that the parts of this		understood and processed MUST ensure that the parts of this
	specification that they use are implemented.		specification that they use are implemented.
	CBOR Web Tokens with proof-of-possession keys are used in context of		CBOR Web Tokens with proof-of-possession keys are used in context of
	an architecture, such as the ACE OAuth Framework		an architecture, such as the ACE OAuth Framework
	[I-D.ietf-ace-oauth-authz], in which protocols are used by a		[I-D.ietf-ace-oauth-authz], in which protocols are used by a
	presenter to request these tokens and to subsequently use them with		presenter to request these tokens and to subsequently use them with
	skipping to change at page 11, line 4 ¶		skipping to change at page 10, line 50 ¶
	make sense, the Designated Experts can choose to accept		make sense, the Designated Experts can choose to accept
	registrations for which the JWT Claim Name is listed as "N/A".		registrations for which the JWT Claim Name is listed as "N/A".
	Confirmation Key:		Confirmation Key:
	CBOR map key value for the confirmation method.		CBOR map key value for the confirmation method.
	Confirmation Value Type(s):		Confirmation Value Type(s):
	CBOR types that can be used for the confirmation method value.		CBOR types that can be used for the confirmation method value.
	Change Controller:		Change Controller:
	For Standards Track RFCs, list the "IESG". For others, give the		For Standards Track RFCs, list the "IESG". For others, give the
	name of the responsible party. Other details (e.g., postal		name of the responsible party. Other details (e.g., postal
	address, email address, home page URI) may also be included.		address, email address, home page URI) may also be included.
	Specification Document(s):		Specification Document(s):
	Reference to the document or documents that specify the parameter,		Reference to the document or documents that specify the parameter,
	preferably including URIs that can be used to retrieve copies of		preferably including URIs that can be used to retrieve copies of
	the documents. An indication of the relevant sections may also be		the documents. An indication of the relevant sections may also be
	included but is not required.		included but is not required.
	7.2.2. Initial Registry Contents		7.2.2. Initial Registry Contents
	o Confirmation Method Name: "COSE_Key"		o Confirmation Method Name: "COSE_Key"
	o Confirmation Method Description: COSE_Key Representing Public Key		o Confirmation Method Description: COSE_Key Representing Public Key
	o JWT Confirmation Method Name: "jwk"		o JWT Confirmation Method Name: "jwk"
	o Confirmation Key: 1		o Confirmation Key: 1
	o Confirmation Value Type(s): map		o Confirmation Value Type(s): COSE_Key structure
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.2 of [[ this document ]]		o Specification Document(s): Section 3.2 of [[ this document ]]
	o Confirmation Method Name: "Encrypted_COSE_Key"		o Confirmation Method Name: "Encrypted_COSE_Key"
	o Confirmation Method Description: Encrypted COSE_Key		o Confirmation Method Description: Encrypted COSE_Key
	o JWT Confirmation Method Name: "jwe"		o JWT Confirmation Method Name: "jwe"
	o Confirmation Key: 2		o Confirmation Key: 2
	o Confirmation Value Type(s): array (with an optional COSE_Encrypt		o Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0
	or COSE_Encrypt0 tag)		structure (with an optional corresponding COSE_Encrypt or
			COSE_Encrypt0 tag)
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.3 of [[ this document ]]		o Specification Document(s): Section 3.3 of [[ this document ]]
	o Confirmation Method Name: "kid"		o Confirmation Method Name: "kid"
	o Confirmation Method Description: Key Identifier		o Confirmation Method Description: Key Identifier
	o JWT Confirmation Method Name: "kid"		o JWT Confirmation Method Name: "kid"
	o Confirmation Key: 3		o Confirmation Key: 3
	o Confirmation Value Type(s): binary string		o Confirmation Value Type(s): binary string
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.4 of [[ this document ]]		o Specification Document(s): Section 3.4 of [[ this document ]]
	skipping to change at page 12, line 37 ¶		skipping to change at page 12, line 32 ¶
	[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,		[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,		"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
	May 2018, <https://www.rfc-editor.org/info/rfc8392>.		May 2018, <https://www.rfc-editor.org/info/rfc8392>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-ace-oauth-authz]		[I-D.ietf-ace-oauth-authz]
	Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and		Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
	H. Tschofenig, "Authentication and Authorization for		H. Tschofenig, "Authentication and Authorization for
	Constrained Environments (ACE) using the OAuth 2.0		Constrained Environments (ACE) using the OAuth 2.0
	Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-12		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16
	(work in progress), May 2018.		(work in progress), October 2018.
	[IANA.JWT.Claims]		[IANA.JWT.Claims]
	IANA, "JSON Web Token Claims",		IANA, "JSON Web Token Claims",
	<http://www.iana.org/assignments/jwt>.		<http://www.iana.org/assignments/jwt>.
	[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web		[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", RFC 7515, May 2015,		Signature (JWS)", RFC 7515, May 2015,
	<http://www.rfc-editor.org/info/rfc7515>.		<http://www.rfc-editor.org/info/rfc7515>.
	[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	skipping to change at page 13, line 33 ¶		skipping to change at page 13, line 26 ¶
	Thanks to the following people for their reviews of the		Thanks to the following people for their reviews of the
	specification: Roman Danyliw, Michael Richardson, and Jim Schaad.		specification: Roman Danyliw, Michael Richardson, and Jim Schaad.
	Ludwig Seitz and Goeran Selander worked on this document as part of		Ludwig Seitz and Goeran Selander worked on this document as part of
	the CelticPlus project CyberWI, with funding from Vinnova.		the CelticPlus project CyberWI, with funding from Vinnova.
	Document History		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 ]]
			-04
			o Addressed additional WGLC comments by Jim Schaad and Roman
			Danyliw.
	-03		-03
	o Addressed review comments by Jim Schaad, see https://www.ietf.org/		o Addressed review comments by Jim Schaad, see https://www.ietf.org/
	mail-archive/web/ace/current/msg02798.html		mail-archive/web/ace/current/msg02798.html
	o Removed unnecessary sentence in the introduction regarding the use		o Removed unnecessary sentence in the introduction regarding the use
	any strings that could be case-sensitive.		any strings that could be case-sensitive.
	o Clarified the terms Presenter and Recipient.		o Clarified the terms Presenter and Recipient.
End of changes. 11 change blocks.
	16 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/