draft-ietf-ace-cwt-proof-of-possession-05.txt		draft-ietf-ace-cwt-proof-of-possession-06.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: May 13, 2019 RISE SICS		Expires: August 25, 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.
	November 9, 2018		February 21, 2019
	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-05		draft-ietf-ace-cwt-proof-of-possession-06
	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 May 13, 2019.		This Internet-Draft will expire on August 25, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	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
	skipping to change at page 2, line 50 ¶		skipping to change at page 2, line 50 ¶
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	This specification describes how a CBOR Web Token (CWT) [RFC8392] can		This specification describes how a CBOR Web Token (CWT) [RFC8392] can
	declare that the presenter of the CWT possesses a particular proof-		declare that the presenter of the CWT possesses a particular proof-
	of-possession (PoP) key. Proof of possession of a key is also		of-possession (PoP) key. Proof of 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)" [RFC7800], but using CBOR		Semantics for JSON Web Tokens (JWTs)" [RFC7800], but using CBOR
	[RFC7049] and CWTs [RFC8392] rather than JSON [RFC7159] and JWTs		[RFC7049] and CWTs [RFC8392] rather than JSON [RFC8259] and JWTs
	[JWT].		[JWT].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 9 ¶
	recipient using COSE_Encrypt or COSE_Encrypt0.		recipient using COSE_Encrypt or COSE_Encrypt0.
	The following example (using CBOR diagnostic notation, with		The following example (using CBOR diagnostic notation, with
	linebreaks for readability) illustrates a symmetric key that could		linebreaks for readability) illustrates a symmetric key that could
	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'		e68449c65f885d1b73b49eae1'
	}		}
	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 key.
	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,
	/iat/ 5 : 1311280970,		/iat/ 5 : 1311280970,
	/cnf/ 8 : {		/cnf/ 8 : {
	/COSE_Encrypt0/ 2 : [		/COSE_Encrypt0/ 2 : [
	/protected header / h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,		/protected header/ h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,
	/unprotected header/ { / iv / 5: h'636898994FF0EC7BFCF6D3F95B'},		/unprotected header/ { / iv / 5: h'636898994FF0EC7BFCF6D3F95B'},
	/ciphertext/ h'0573318A3573EB983E55A7C2F06CADD0796C9E584F1D0E3E		/ciphertext/ h'0573318A3573EB983E55A7C2F06CADD0796C9E584F1D0E3E
	A8C5B052592A8B2694BE9654F0431F38D5BBC8049FA7F13F'		A8C5B052592A8B2694BE9654F0431F38D5BBC8049FA7F13F'
	]		]
	}		}
	}		}
	The example above was generated with the key:		The example above was generated with the key:
	h'6162630405060708090a0b0c0d0e0f10'		h'6162630405060708090a0b0c0d0e0f10'
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 33 ¶
	are identified by Key IDs, care must be taken to keep the keys for		are identified by Key IDs, care must be taken to keep the keys for
	the different kinds of CWTs segregated so that an attacker cannot		the different kinds of CWTs segregated so that an attacker cannot
	cause the wrong PoP key to be used by using a valid Key ID for the		cause the wrong PoP key to be used by using a valid Key ID for the
	wrong kind of CWT.		wrong kind of CWT.
	7. IANA Considerations		7. 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 on a Specification Required [RFC5226] basis		Values are registered on a Specification Required [RFC8126] basis
	after a three-week review period on the cwt-reg-review@ietf.org		after a three-week review period on the cwt-reg-review@ietf.org
	mailing list, on the advice of one or more Designated Experts.		mailing list, on the advice of one or more Designated Experts.
	However, to allow for the allocation of values prior to publication,		However, to allow for the allocation of values prior to publication,
	the Designated Experts may approve registration once they are		the Designated Experts may approve registration once they are
	satisfied that such a specification will be published. [[ Note to		satisfied that such a specification will be published. [[ Note to
	the RFC Editor: The name of the mailing list should be determined in		the RFC Editor: The name of the mailing list should be determined in
	consultation with the IESG and IANA. Suggested name: cwt-reg-		consultation with the IESG and IANA. Suggested name: cwt-reg-
	review@ietf.org. ]]		review@ietf.org. ]]
	Registration requests sent to the mailing list for review should use		Registration requests sent to the mailing list for review should use
	skipping to change at page 13, line 18 ¶		skipping to change at page 13, line 18 ¶
	[IANA.CWT.Claims]		[IANA.CWT.Claims]
	IANA, "CBOR Web Token Claims",		IANA, "CBOR Web Token Claims",
	<http://www.iana.org/assignments/cwt>.		<http://www.iana.org/assignments/cwt>.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,
	<https://www.rfc-editor.org/info/rfc5226>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
			[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
			Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",		[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,		RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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-16		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-21
	(work in progress), October 2018.		(work in progress), February 2019.
	[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
	(JWT)", RFC 7519, DOI 10.17487/RFC7159, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<http://www.rfc-editor.org/info/rfc7519>.		<http://www.rfc-editor.org/info/rfc7519>.
	[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,
	<http://docs.oasis-open.org/security/saml/v2.0/>.		<http://docs.oasis-open.org/security/saml/v2.0/>.
	[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
	2014, <https://www.rfc-editor.org/info/rfc7159>.
	[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-		[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
	Possession Key Semantics for JSON Web Tokens (JWTs)",		Possession Key Semantics for JSON Web Tokens (JWTs)",
	RFC 7800, DOI 10.17487/RFC7800, April 2016,		RFC 7800, DOI 10.17487/RFC7800, April 2016,
	<https://www.rfc-editor.org/info/rfc7800>.		<https://www.rfc-editor.org/info/rfc7800>.
			[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
			Interchange Format", STD 90, RFC 8259,
			DOI 10.17487/RFC8259, December 2017,
			<https://www.rfc-editor.org/info/rfc8259>.
	Acknowledgements		Acknowledgements
	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 ]]
			-06
			o Corrected nits identified by Roman Danyliw.
	-05		-05
	o Added text suggested by Jim Schaad describing considerations when		o Added text suggested by Jim Schaad describing considerations when
	using the Key ID confirmation method.		using the Key ID confirmation method.
	-04		-04
	o Addressed additional WGLC comments by Jim Schaad and Roman		o Addressed additional WGLC comments by Jim Schaad and Roman
	Danyliw.		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.
	o Clarified text about the confirmation claim.		o Clarified text about the confirmation claim.
End of changes. 18 change blocks.
	22 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/