draft-ietf-ace-oscore-profile-10.txt		draft-ietf-ace-oscore-profile-11.txt
	ACE Working Group F. Palombini		ACE Working Group F. Palombini
	Internet-Draft Ericsson AB		Internet-Draft Ericsson AB
	Intended status: Standards Track L. Seitz		Intended status: Standards Track L. Seitz
	Expires: September 10, 2020 Combitech		Expires: December 20, 2020 Combitech
	G. Selander		G. Selander
	Ericsson AB		Ericsson AB
	M. Gunnarsson		M. Gunnarsson
	RISE		RISE
	March 9, 2020		June 18, 2020
	OSCORE profile of the Authentication and Authorization for Constrained		OSCORE profile of the Authentication and Authorization for Constrained
	Environments Framework		Environments Framework
	draft-ietf-ace-oscore-profile-10		draft-ietf-ace-oscore-profile-11
	Abstract		Abstract
	This memo specifies a profile for the Authentication and		This memo specifies a profile for the Authentication and
	Authorization for Constrained Environments (ACE) framework. It		Authorization for Constrained Environments (ACE) framework. It
	utilizes Object Security for Constrained RESTful Environments		utilizes Object Security for Constrained RESTful Environments
	(OSCORE) to provide communication security, server authentication,		(OSCORE) to provide communication security, server authentication,
	and proof-of-possession for a key owned by the client and bound to an		and proof-of-possession for a key owned by the client and bound to an
	OAuth 2.0 access token.		OAuth 2.0 access token.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 September 10, 2020.		This Internet-Draft will expire on December 20, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4		2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
	3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 6		3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 6
	3.1. C-to-AS: POST to token endpoint . . . . . . . . . . . . . 6		3.1. C-to-AS: POST to token endpoint . . . . . . . . . . . . . 6
	3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 8		3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 8
	3.2.1. OSCORE_Security_Context Object . . . . . . . . . . . 13		3.2.1. OSCORE_Security_Context Object . . . . . . . . . . . 13
	4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 16		4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 17
	4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 17		4.1. C-to-RS: POST to authz-info endpoint . . . . . . . . . . 18
	4.1.1. The Nonce 1 Parameter . . . . . . . . . . . . . . . . 18		4.1.1. The Nonce 1 Parameter . . . . . . . . . . . . . . . . 19
	4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 18		4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 19
	4.2.1. The Nonce 2 Parameter . . . . . . . . . . . . . . . . 19		4.2.1. The Nonce 2 Parameter . . . . . . . . . . . . . . . . 21
	4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 19		4.3. OSCORE Setup . . . . . . . . . . . . . . . . . . . . . . 21
	4.4. Access rights verification . . . . . . . . . . . . . . . 21		4.4. Access rights verification . . . . . . . . . . . . . . . 22
	5. Secure Communication with AS . . . . . . . . . . . . . . . . 21		5. Secure Communication with AS . . . . . . . . . . . . . . . . 22
	6. Discarding the Security Context . . . . . . . . . . . . . . . 21		6. Discarding the Security Context . . . . . . . . . . . . . . . 23
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 22		7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 24		9.1. ACE OAuth Profile Registry . . . . . . . . . . . . . . . 25
	9.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 24		9.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 26
	9.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 24		9.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 26
	9.4. OSCORE Security Context Parameters Registry . . . . . . . 25		9.4. OSCORE Security Context Parameters Registry . . . . . . . 26
	9.5. CWT Confirmation Methods Registry . . . . . . . . . . . . 25		9.5. CWT Confirmation Methods Registry . . . . . . . . . . . . 27
	9.6. JWT Confirmation Methods Registry . . . . . . . . . . . . 26		9.6. JWT Confirmation Methods Registry . . . . . . . . . . . . 28
	9.7. Expert Review Instructions . . . . . . . . . . . . . . . 26		9.7. Expert Review Instructions . . . . . . . . . . . . . . . 28
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.1. Normative References . . . . . . . . . . . . . . . . . . 27		10.1. Normative References . . . . . . . . . . . . . . . . . . 29
	10.2. Informative References . . . . . . . . . . . . . . . . . 28		10.2. Informative References . . . . . . . . . . . . . . . . . 30
	Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 28		Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 30
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	This memo specifies a profile of the ACE framework		This memo specifies a profile of the ACE framework
	[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource		[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource
	server use CoAP [RFC7252] to communicate. The client uses an access		server use CoAP [RFC7252] to communicate. The client uses an access
	token, bound to a key (the proof-of-possession key) to authorize its		token, bound to a key (the proof-of-possession key) to authorize its
	access to the resource server. Note that this profile uses a		access to the resource server. Note that this profile uses a
	symmetric-crypto-based scheme, where the symmetric secret is used as		symmetric-crypto-based scheme, where the symmetric secret is used as
	input material for keying material derivation. In order to provide		input material for keying material derivation. In order to provide
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 30 ¶
	"scope" : "read"		"scope" : "read"
	}		}
	Figure 2: Example C-to-AS POST /token request for an access token		Figure 2: Example C-to-AS POST /token request for an access token
	bound to a symmetric key.		bound to a symmetric key.
	If the client wants to update its access rights without changing an		If the client wants to update its access rights without changing an
	existing OSCORE Security Context, it MUST include in its POST request		existing OSCORE Security Context, it MUST include in its POST request
	to the token endpoint a req_cnf object. The req_cnf MUST include a		to the token endpoint a req_cnf object. The req_cnf MUST include a
	kid field carrying a bstr-wrapped CBOR array object containing the		kid field carrying a bstr-wrapped CBOR array object containing the
	client's identifier (assigned as discussed in Section 3.2) and		client's identifier (assigned as discussed in Section 3.2) and the
	optionally the context identifier (if assigned as discussed in		context identifier (if assigned as discussed in Section 3.2). The
	Section 3.2). The CBOR array is defined in Figure 3, and follows the		CBOR array is defined in Figure 3, and follows the notation of
	notation of [RFC8610]. These identifiers, together with other		[RFC8610]. These identifiers, together with other information such
	information such as audience, can be used by the AS to determine the		as audience, can be used by the AS to determine the shared secret
	shared secret bound to the proof-of-possession token and therefore		bound to the proof-of-possession token and therefore MUST identify a
	MUST identify a symmetric key that was previously generated by the AS		symmetric key that was previously generated by the AS as a shared
	as a shared secret for the communication between the client and the		secret for the communication between the client and the RS. The AS
	RS. The AS MUST verify that the received value identifies a proof-		MUST verify that the received value identifies a proof-of-possession
	of-possession key that has previously been issued to the requesting		key that has previously been issued to the requesting client. If
	client. If that is not the case, the Client-to-AS request MUST be		that is not the case, the Client-to-AS request MUST be declined with
	declined with the error code 'invalid_request' as defined in		the error code 'invalid_request' as defined in Section 5.6.3 of
	Section 5.6.3 of [I-D.ietf-ace-oauth-authz].		[I-D.ietf-ace-oauth-authz].
	kid_arr = [		kid_arr = [
	clientId,		clientId,
	?IdContext		?IdContext
	]		]
	kid = bstr .cbor kid_arr		kid = bstr .cbor kid_arr
	Figure 3: CDDL Notation of kid for Update of Access Rights		Figure 3: CDDL Notation of kid for Update of Access Rights
	skipping to change at page 9, line 29 ¶		skipping to change at page 9, line 29 ¶
	o an HKDF algorithm		o an HKDF algorithm
	o a salt		o a salt
	o the OSCORE version number		o the OSCORE version number
	The OSCORE_Security_Context is a CBOR map object, defined in		The OSCORE_Security_Context is a CBOR map object, defined in
	Section 3.2.1. This object is transported in the 'cnf' parameter of		Section 3.2.1. This object is transported in the 'cnf' parameter of
	the access token response as defined in Section 3.2 of		the access token response as defined in Section 3.2 of
	[I-D.ietf-ace-oauth-params], as value of a field named 'osc'		[I-D.ietf-ace-oauth-params], as the value of a field named 'osc',
	registered in Section 9.5 and Section 9.6. The master secret MUST be		registered in Section 9.5 and Section 9.6. The master secret MUST be
	communicated as the 'ms' field in the 'osc' field in the 'cnf'		communicated as the 'ms' field in the 'osc' field in the 'cnf'
	parameter of the access token response as defined in Section 3.2 of		parameter of the access token response as defined in Section 3.2 of
	[I-D.ietf-ace-oauth-params]. The AEAD algorithm may be included as		[I-D.ietf-ace-oauth-params]. The AEAD algorithm may be included as
	the 'alg' parameter in the OSCORE_Security_Context; the HKDF		the 'alg' parameter in the OSCORE_Security_Context; the HKDF
	algorithm may be included as the 'hkdf' parameter of the		algorithm may be included as the 'hkdf' parameter of the
	OSCORE_Security_Context, a salt may be included as the 'salt'		OSCORE_Security_Context, a salt may be included as the 'salt'
	parameter of the OSCORE_Security_Context, and the OSCORE version		parameter of the OSCORE_Security_Context, and the OSCORE version
	number may be included as the 'version' parameter of the		number may be included as the 'version' parameter of the
	OSCORE_Security_Context.		OSCORE_Security_Context.
	skipping to change at page 10, line 22 ¶		skipping to change at page 10, line 22 ¶
	We assume in this document that a resource is associated to one		We assume in this document that a resource is associated to one
	single AS, which makes it possible for the AS to enforce uniqueness		single AS, which makes it possible for the AS to enforce uniqueness
	of identifiers for each client requesting a particular resource to a		of identifiers for each client requesting a particular resource to a
	RS. If this is not the case, collisions of identifiers may occur at		RS. If this is not the case, collisions of identifiers may occur at
	the RS, in which case the RS needs to have a mechanism in place to		the RS, in which case the RS needs to have a mechanism in place to
	disambiguate identifiers or mitigate the effect of the collisions.		disambiguate identifiers or mitigate the effect of the collisions.
	Moreover, implementers of this specification need to be aware that if		Moreover, implementers of this specification need to be aware that if
	other authentication mechanisms are used to set up OSCORE between the		other authentication mechanisms are used to set up OSCORE between the
	same client and RS, that do not rely on AS assigning identifiers,		same client and RS, that do not rely on AS assigning identifiers,
	collisions may happen and need to be mitigated.		collisions may happen and need to be mitigated. A mitigation example
			would be to use distinct namespaces of identifiers for different
			authentication mechanisms.
	Note that in Section 4.3 C sets the Sender ID of its Security Context		Note that in Section 4.3 C sets the Sender ID of its Security Context
	to the clientId value received and the Recipient ID to the serverId		to the clientId value received and the Recipient ID to the serverId
	value, and RS does the opposite.		value, and RS does the opposite.
	Figure 5 shows an example of an AS response, with payload in CBOR		Figure 5 shows an example of an AS response, with payload in CBOR
	diagnostic notation without the tag and value abbreviations. The		diagnostic notation without the tag and value abbreviations. The
	access token has been truncated for readability.		access token has been truncated for readability.
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	skipping to change at page 11, line 26 ¶		skipping to change at page 11, line 46 ¶
	"alg" : "AES-CCM-16-64-128",		"alg" : "AES-CCM-16-64-128",
	"clientId" : h'00',		"clientId" : h'00',
	"serverId" : h'01',		"serverId" : h'01',
	"ms" : h'f9af838368e353e78888e1426bd94e6f'		"ms" : h'f9af838368e353e78888e1426bd94e6f'
	}		}
	}		}
	Figure 6: Example CWT with OSCORE parameters.		Figure 6: Example CWT with OSCORE parameters.
	The same CWT token as in Figure 6, using the value abbreviations		The same CWT token as in Figure 6, using the value abbreviations
	defined in [I-D.ietf-ace-oauth-authz] and		defined in [I-D.ietf-ace-oauth-authz] and [RFC8747] and encoded in
	[I-D.ietf-ace-cwt-proof-of-possession] and encoded in CBOR is shown		CBOR is shown in Figure 7.
	in Figure 7.
	NOTE TO THE RFC EDITOR: before publishing, it should be checked (and		NOTE TO THE RFC EDITOR: before publishing, it should be checked (and
	in case fixed) that the values used below (which are not yet		in case fixed) that the values used below (which are not yet
	registered) are the final values registered in IANA.		registered) are the final values registered in IANA.
	A5 # map(5)		A5 # map(5)
	03 # unsigned(3)		03 # unsigned(3)
	76 # text(22)		76 # text(22)
	74656D7053656E736F72496E4C6976696E67526F6F6D		74656D7053656E736F72496E4C6976696E67526F6F6D
	# "tempSensorInLivingRoom"		# "tempSensorInLivingRoom"
	skipping to change at page 12, line 45 ¶		skipping to change at page 12, line 49 ¶
	Figure 7: Example CWT with OSCORE parameters.		Figure 7: Example CWT with OSCORE parameters.
	If the client has requested an update to its access rights using the		If the client has requested an update to its access rights using the
	same OSCORE Security Context, which is valid and authorized, the AS		same OSCORE Security Context, which is valid and authorized, the AS
	MUST omit the 'cnf' parameter in the response, and MUST carry the		MUST omit the 'cnf' parameter in the response, and MUST carry the
	client identifier and the context identifier (if it was set and		client identifier and the context identifier (if it was set and
	included in the initial access token response by the AS) in the 'kid'		included in the initial access token response by the AS) in the 'kid'
	field in the 'cnf' parameter of the token, with the same structure		field in the 'cnf' parameter of the token, with the same structure
	defined in Figure 3. These identifiers need to be included in the		defined in Figure 3. These identifiers need to be included in the
	response, in order for the RS to identify the previously generated		token in order for the RS to identify the previously generated
	Security Context.		Security Context.
	Figure 8 shows an example of such an AS response, with payload in		Figure 8 shows an example of such an AS response, with payload in
	CBOR diagnostic notation without the tag and value abbreviations.		CBOR diagnostic notation without the tag and value abbreviations.
	The access token has been truncated for readability.		The access token has been truncated for readability.
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	Content-Type: "application/ace+cbor"		Content-Type: "application/ace+cbor"
	Payload:		Payload:
	{		{
	skipping to change at page 13, line 43 ¶		skipping to change at page 13, line 47 ¶
	rights.		rights.
	3.2.1. OSCORE_Security_Context Object		3.2.1. OSCORE_Security_Context Object
	An OSCORE_Security_Context is an object that represents part or all		An OSCORE_Security_Context is an object that represents part or all
	of an OSCORE Security Context, i.e., the local set of information		of an OSCORE Security Context, i.e., the local set of information
	elements necessary to carry out the cryptographic operations in		elements necessary to carry out the cryptographic operations in
	OSCORE (Section 3.1 of [RFC8613]). In particular, the		OSCORE (Section 3.1 of [RFC8613]). In particular, the
	OSCORE_Security_Context object is defined to be serialized and		OSCORE_Security_Context object is defined to be serialized and
	transported between nodes, as specified by this document, but can		transported between nodes, as specified by this document, but can
	also be used in this way by other specifications if needed. The		also be used by other specifications if needed. The
	OSCORE_Security_Context object can either be encoded as a JSON object		OSCORE_Security_Context object can either be encoded as a JSON object
	or as a CBOR map. The set of common parameters that can appear in an		or as a CBOR map. The set of common parameters that can appear in an
	OSCORE_Security_Context object can be found in the IANA "OSCORE		OSCORE_Security_Context object can be found in the IANA "OSCORE
	Security Context Parameters" registry (Section 9.4), defined for		Security Context Parameters" registry (Section 9.4), defined for
	extensibility, and is specified below. All parameters are optional.		extensibility, and is specified below. All parameters are optional.
	Table 1 provides a summary of the OSCORE_Security_Context parameters		Table 1 provides a summary of the OSCORE_Security_Context parameters
	defined in this section.		defined in this section.
	+-----------+-------+----------------+--------------+---------------+		+-----------+-------+----------------+--------------+---------------+
	| name | CBOR | CBOR type | registry | description |		| name | CBOR | CBOR type | registry | description |
	skipping to change at page 16, line 43 ¶		skipping to change at page 17, line 43 ¶
	? 7 => bstr, ; contextId		? 7 => bstr, ; contextId
	* int / tstr => any		* int / tstr => any
	}		}
	4. Client-RS Communication		4. Client-RS Communication
	The following subsections describe the details of the POST request		The following subsections describe the details of the POST request
	and response to the authz-info endpoint between client and RS. The		and response to the authz-info endpoint between client and RS. The
	client generates a nonce N1, and posts it together with the token		client generates a nonce N1, and posts it together with the token
	that includes the materials (e.g., OSCORE parameters) received from		that includes the materials (e.g., OSCORE parameters) received from
	the AS to the RS. The RS then generates a nonce N2, and use		the AS to the RS. The RS then generates a nonce N2, and uses
	Section 3.2 of [RFC8613] to derive a security context based on a		Section 3.2 of [RFC8613] to derive a security context based on a
	shared master secret and the two nonces, established between client		shared master secret and the two nonces, established between client
	and server. The nonces are encoded as CBOR bstr if CBOR is used, and		and server. The nonces are encoded as CBOR bstr if CBOR is used, and
	as Base64 string if JSON is used. This security context is used to		as Base64 string if JSON is used. This security context is used to
	protect all future communication between client and RS using OSCORE,		protect all future communication between client and RS using OSCORE,
	as long as the access token is valid.		as long as the access token is valid.
	Note that the RS and client authenticates themselves by generating		Note that the RS and client authenticates themselves by generating
	the shared OSCORE Security Context using the pop-key as master		the shared OSCORE Security Context using the pop-key as master
	secret. An attacker posting a valid token to the RS will not be able		secret. An attacker posting a valid token to the RS will not be able
	skipping to change at page 17, line 28 ¶		skipping to change at page 18, line 28 ¶
	client MUST use CoAP and the Authorization Information resource as		client MUST use CoAP and the Authorization Information resource as
	described in section 5.8.1 of [I-D.ietf-ace-oauth-authz] to transport		described in section 5.8.1 of [I-D.ietf-ace-oauth-authz] to transport
	the token and N1 to the RS.		the token and N1 to the RS.
	Note that the use of the payload and the Content-Format is different		Note that the use of the payload and the Content-Format is different
	from what described in section 5.8.1 of [I-D.ietf-ace-oauth-authz],		from what described in section 5.8.1 of [I-D.ietf-ace-oauth-authz],
	which only transports the token without any CBOR wrapping. In this		which only transports the token without any CBOR wrapping. In this
	profile, the client MUST wrap the token and N1 in a CBOR map. The		profile, the client MUST wrap the token and N1 in a CBOR map. The
	client MUST use the Content-Format "application/ace+cbor" defined in		client MUST use the Content-Format "application/ace+cbor" defined in
	section 8.14 of [I-D.ietf-ace-oauth-authz]. The client MUST include		section 8.14 of [I-D.ietf-ace-oauth-authz]. The client MUST include
	the access token using the correct CBOR label (e.g., "cwt" for CWT,		the access token using the "access_token" parameter and N1 using the
	"jwt" for JWT) and N1 using the 'nonce1' parameter defined in		'nonce1' parameter defined in Section 4.1.1.
	Section 4.1.1.
	The authz-info endpoint is not protected, nor are the responses from		The authz-info endpoint is not protected, nor are the responses from
	this resource.		this resource.
	The access token MUST be encrypted, since it is transferred from the		The access token MUST be encrypted, since it is transferred from the
	client to the RS over an unprotected channel.		client to the RS over an unprotected channel.
	Note that a client may be required to re-POST the access token in		Note that a client may be required to re-POST the access token in
	order to complete a request, since an RS may delete a stored access		order to complete a request, since an RS may delete a stored access
	token at any time, for example due to all storage space being		token (and associated Security Context) at any time, for example due
	consumed. This situation is detected by the client when it receives		to all storage space being consumed. This situation is detected by
	an AS Request Creation Hints response.		the client when it receives an AS Request Creation Hints response.
			Reposting the same access token will result in deriving a new OSCORE
			Security Context to be used with the RS, as different nonces will be
			used.
	Figure 11 shows an example of the request sent from the client to the		Figure 11 shows an example of the request sent from the client to the
	RS, with payload in CBOR diagnostic notation without the tag and		RS, with payload in CBOR diagnostic notation without the tag and
	value abbreviations. The access token has been truncated for		value abbreviations. The access token has been truncated for
	readability.		readability.
	Header: POST (Code=0.02)		Header: POST (Code=0.02)
	Uri-Host: "rs.example.com"		Uri-Host: "rs.example.com"
	Uri-Path: "authz-info"		Uri-Path: "authz-info"
	Content-Format: "application/ace+cbor"		Content-Format: "application/ace+cbor"
	Payload:		Payload:
	{		{
	"access_token": h'a5037674656d7053656e73 ...		"access_token": h'a5037674656d7053656e73 ...
	(remainder of access token (CWT) omitted for brevity)',		(remainder of access token (CWT) omitted for brevity)',
	"nonce1": h'018a278f7faab55a'		"nonce1": h'018a278f7faab55a'
	}		}
	Figure 11: Example C-to-RS POST /authz-info request using CWT		Figure 11: Example C-to-RS POST /authz-info request using CWT
			If the client has already posted a valid token, has already
			established a security association with the RS, and wants to update
			its access rights, the client can do so by posting the new token
			(retrieved from the AS and containing the update of access rights) to
			the /authz-info endpoint. The client MUST protect the request using
			the OSCORE Security Context established during the first token
			exchange. The client MUST only send the access token in the payload,
			no nonce is sent. After proper verification (see Section 4.2), the
			RS will replace the old token with the new one, maintaining the same
			Security Context.
	4.1.1. The Nonce 1 Parameter		4.1.1. The Nonce 1 Parameter
	This parameter MUST be sent from the client to the RS, together with		This parameter MUST be sent from the client to the RS, together with
	the access token, if the ace profile used is coap_oscore. The		the access token, if the ace profile used is coap_oscore. The
	parameter is encoded as a byte string for CBOR-based interactions,		parameter is encoded as a byte string for CBOR-based interactions,
	and as a string (Base64 encoded binary) for JSON-based interactions.		and as a string (Base64 encoded binary) for JSON-based interactions.
	This parameter is registered in Section 9.2.		This parameter is registered in Section 9.2.
	4.2. RS-to-C: 2.01 (Created)		4.2. RS-to-C: 2.01 (Created)
	skipping to change at page 19, line 18 ¶		skipping to change at page 20, line 27 ¶
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	Content-Format: "application/ace+cbor"		Content-Format: "application/ace+cbor"
	Payload:		Payload:
	{		{
	"nonce2": h'25a8991cd700ac01'		"nonce2": h'25a8991cd700ac01'
	}		}
	Figure 12: Example RS-to-C 2.01 (Created) response		Figure 12: Example RS-to-C 2.01 (Created) response
			As specified in section 5.8.3 of [I-D.ietf-ace-oauth-authz], the RS
			must notify the client with an error response with code 4.01
			(Unauthorized) for any long running request before terminating the
			session, when the access token expires.
			If the RS receives the token in a OSCORE protected message, it means
			that the client is requesting an update of access rights. The RS
			MUST discard any nonce in the request, if any was sent. The RS MUST
			check that the "kid" of the "cnf" parameter of the new access token
			matches the OSCORE Security Context used to protect the message. If
			that's the case, the RS MUST discard the old token and associate the
			new token to the Security Context identified by "kid". The RS MUST
			respond with a 2.01 (Created) response protected with the same
			Security Context, with no payload. If any verification fails, the RS
			MUST respond with a 4.01 (Unauthorized) error response.
	As specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz], when		As specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz], when
	receiving an updated access token with updated authorization		receiving an updated access token with updated authorization
	information from the client (see Section 3.1), it is recommended that		information from the client (see Section 3.1), it is recommended that
	the RS overwrites the previous token, that is only the latest		the RS overwrites the previous token, that is only the latest
	authorization information in the token received by the RS is valid.		authorization information in the token received by the RS is valid.
	This simplifies for the RS to keep track of authorization information		This simplifies for the RS to keep track of authorization information
	for a given client.		for a given client.
	As specified in section 5.8.3 of [I-D.ietf-ace-oauth-authz], the RS
	must notify the client with an error response with code 4.01
	(Unauthorized) for any long running request before terminating the
	session, when the access token expires.
	4.2.1. The Nonce 2 Parameter		4.2.1. The Nonce 2 Parameter
	This parameter MUST be sent from the RS to the Client if the ace		This parameter MUST be sent from the RS to the Client if the ace
	profile used is coap_oscore. The parameter is encoded as a byte		profile used is coap_oscore. The parameter is encoded as a byte
	string for CBOR-based interactions, and as a string (Base64 encoded		string for CBOR-based interactions, and as a string (Base64 encoded
	binary) for JSON-based interactions. This parameter is registered in		binary) for JSON-based interactions. This parameter is registered in
	Section 9.2		Section 9.2
	4.3. OSCORE Setup		4.3. OSCORE Setup
	skipping to change at page 20, line 50 ¶		skipping to change at page 22, line 23 ¶
	The RS then uses this Security Context to verify requests and send		The RS then uses this Security Context to verify requests and send
	responses to C using OSCORE. If OSCORE verification fails, error		responses to C using OSCORE. If OSCORE verification fails, error
	responses are used, as specified in section 8 of [RFC8613].		responses are used, as specified in section 8 of [RFC8613].
	Additionally, if OSCORE verification succeeds, the verification of		Additionally, if OSCORE verification succeeds, the verification of
	access rights is performed as described in section Section 4.4. The		access rights is performed as described in section Section 4.4. The
	RS MUST NOT use the Security Context after the related token has		RS MUST NOT use the Security Context after the related token has
	expired, and MUST respond with a unprotected 4.01 (Unauthorized)		expired, and MUST respond with a unprotected 4.01 (Unauthorized)
	error message to requests received that correspond to a Security		error message to requests received that correspond to a Security
	Context with an expired token.		Context with an expired token.
	If the exchange was an update of access rights, i.e., a new Security
	Context was derived from a client that already had a Security Context
	in place, the RS is RECOMMENDED to delete the old Security Context
	after OSCORE verification and verification of access rights succeed.
	The RS MUST delete the Security Context if it deletes the access
	token associated to it.
	4.4. Access rights verification		4.4. Access rights verification
	The RS MUST follow the procedures defined in section 5.8.2 of		The RS MUST follow the procedures defined in section 5.8.2 of
	[I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected		[I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected
	request from a client, then the RS processes it according to		request from a client, then the RS processes it according to
	[RFC8613]. If OSCORE verification succeeds, and the target resource		[RFC8613]. If OSCORE verification succeeds, and the target resource
	requires authorization, the RS retrieves the authorization		requires authorization, the RS retrieves the authorization
	information using the access token associated to the Security		information using the access token associated to the Security
	Context. The RS then must verify that the authorization information		Context. The RS then must verify that the authorization information
	covers the resource and the action requested.		covers the resource and the action requested.
	skipping to change at page 21, line 48 ¶		skipping to change at page 23, line 15 ¶
	Furthermore the requesting entity and the AS communicate through the		Furthermore the requesting entity and the AS communicate through the
	introspection endpoint as specified in section 5.7 of		introspection endpoint as specified in section 5.7 of
	[I-D.ietf-ace-oauth-authz] and through the token endpoint as		[I-D.ietf-ace-oauth-authz] and through the token endpoint as
	specified in section 5.6 of [I-D.ietf-ace-oauth-authz].		specified in section 5.6 of [I-D.ietf-ace-oauth-authz].
	6. Discarding the Security Context		6. Discarding the Security Context
	There are a number of scenarios where a client or RS needs to discard		There are a number of scenarios where a client or RS needs to discard
	the OSCORE security context, and acquire a new one.		the OSCORE security context, and acquire a new one.
	The client MUST discard the current security context associated with		The client MUST discard the current Security Context associated with
	an RS when:		an RS when:
	o the Sequence Number space ends.		o the Sequence Number space ends.
	o the access token associated with the context expires.		o the access token associated with the context expires.
	o the client receives a number of 4.01 Unauthorized responses to		o the client receives a number of 4.01 Unauthorized responses to
	OSCORE requests using the same security context. The exact number		OSCORE requests using the same Security Context. The exact number
	needs to be specified by the application.		needs to be specified by the application.
	o the client receives a new nonce in the 2.01 (Created) response		o the client receives a new nonce in the 2.01 (Created) response
	(see Section 4.2) to a POST request to the authz-info endpoint,		(see Section 4.2) to a POST request to the authz-info endpoint,
	when re-posting a (non-expired) token associated to the existing		when re-posting a (non-expired) token associated to the existing
	context.		context.
	The RS MUST discard the current security context associated with a		The RS MUST discard the current Security Context associated with a
	client when:		client when:
	o the Sequence Number space ends.		o the Sequence Number space ends.
	o the access token associated with the context expires.		o the access token associated with the context expires.
			o the client has successfully replaced the current security context
			with a newer one by posting an access token to the unprotected
			/authz-info endpoint at the RS, e.g., by re-posting the same
			token, as specified in Section 4.1.
			Whenever one more access token is successfully posted to the RS, and
			a new Security Context is derived between the client and RS, messages
			in transit that were protected with the previous Security Context
			might not pass verification, as the old context is discarded. That
			means that messages sent shortly before the client posts one more
			access token to the RS might not successfully reach the destination.
			Analogously, implementations may want to cancel CoAP observations at
			the RS registered before the Security Context is replaced, or
			conversely they will need to implement a mechanism to ensure that
			those observation are to be protected with the newly derived Security
			Context.
	7. Security Considerations		7. Security Considerations
	This document specifies a profile for the Authentication and		This document specifies a profile for the Authentication and
	Authorization for Constrained Environments (ACE) framework		Authorization for Constrained Environments (ACE) framework
	[I-D.ietf-ace-oauth-authz]. Thus the general security considerations		[I-D.ietf-ace-oauth-authz]. Thus the general security considerations
	from the framework also apply to this profile.		from the framework also apply to this profile.
	Furthermore the general security considerations of OSCORE [RFC8613]		Furthermore the general security considerations of OSCORE [RFC8613]
	also apply to this specific use of the OSCORE protocol.		also apply to this specific use of the OSCORE protocol.
	skipping to change at page 25, line 50 ¶		skipping to change at page 27, line 38 ¶
	for the field if one exists		for the field if one exists
	This registry will be initially populated by the values in Table 1.		This registry will be initially populated by the values in Table 1.
	The specification column for all of these entries will be this		The specification column for all of these entries will be this
	document and [RFC8613].		document and [RFC8613].
	9.5. CWT Confirmation Methods Registry		9.5. CWT Confirmation Methods Registry
	The following registration is done for the CWT Confirmation Methods		The following registration is done for the CWT Confirmation Methods
	Registry following the procedure specified in section 7.2.1 of		Registry following the procedure specified in section 7.2.1 of
	[I-D.ietf-ace-cwt-proof-of-possession]:		[RFC8747]:
	o Confirmation Method Name: "osc"		o Confirmation Method Name: "osc"
	o Confirmation Method Description: OSCORE_Security_Context carrying		o Confirmation Method Description: OSCORE_Security_Context carrying
	the parameters for using OSCORE per-message security with implicit		the parameters for using OSCORE per-message security with implicit
	key confirmation		key confirmation
	o Confirmation Key: TBD (value between 4 and 255)		o Confirmation Key: TBD (value between 4 and 255)
	o Confirmation Value Type(s): map		o Confirmation Value Type(s): map
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.2.1 of [[this specification]]		o Specification Document(s): Section 3.2.1 of [[this specification]]
	skipping to change at page 27, line 28 ¶		skipping to change at page 29, line 19 ¶
	[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-33		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33
	(work in progress), February 2020.		(work in progress), February 2020.
	[I-D.ietf-ace-oauth-params]		[I-D.ietf-ace-oauth-params]
	Seitz, L., "Additional OAuth Parameters for Authorization		Seitz, L., "Additional OAuth Parameters for Authorization
	in Constrained Environments (ACE)", draft-ietf-ace-oauth-		in Constrained Environments (ACE)", draft-ietf-ace-oauth-
	params-12 (work in progress), February 2020.		params-13 (work in progress), April 2020.
	[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>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	skipping to change at page 28, line 18 ¶		skipping to change at page 30, line 7 ¶
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,		(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
	<https://www.rfc-editor.org/info/rfc8613>.		<https://www.rfc-editor.org/info/rfc8613>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-ace-cwt-proof-of-possession]
	Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
	Tschofenig, "Proof-of-Possession Key Semantics for CBOR
	Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
	possession-11 (work in progress), October 2019.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,		FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
	<https://www.rfc-editor.org/info/rfc4949>.		<https://www.rfc-editor.org/info/rfc4949>.
	[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",		[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
	RFC 6749, DOI 10.17487/RFC6749, October 2012,		RFC 6749, DOI 10.17487/RFC6749, October 2012,
	<https://www.rfc-editor.org/info/rfc6749>.		<https://www.rfc-editor.org/info/rfc6749>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,		DOI 10.17487/RFC7231, June 2014,
	<https://www.rfc-editor.org/info/rfc7231>.		<https://www.rfc-editor.org/info/rfc7231>.
	[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>.
			[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
			Tschofenig, "Proof-of-Possession Key Semantics for CBOR
			Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
			2020, <https://www.rfc-editor.org/info/rfc8747>.
	Appendix A. Profile Requirements		Appendix A. Profile Requirements
	This section lists the specifications on this profile based on the		This section lists the specifications on this profile based on the
	requirements on the framework, as requested in Appendix C of		requirements on the framework, as requested in Appendix C of
	[I-D.ietf-ace-oauth-authz].		[I-D.ietf-ace-oauth-authz].
	o Optionally define new methods for the client to discover the		o Optionally define new methods for the client to discover the
	necessary permissions and AS for accessing a resource, different		necessary permissions and AS for accessing a resource, different
	from the one proposed in: Not specified		from the one proposed in: Not specified
	o Optionally specify new grant types: Not specified		o Optionally specify new grant types: Not specified
	skipping to change at page 29, line 30 ¶		skipping to change at page 31, line 18 ¶
	o Specify the communication and security protocol for interactions		o Specify the communication and security protocol for interactions
	between client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE)		between client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE)
	o Specify how/if the authz-info endpoint is protected, including how		o Specify how/if the authz-info endpoint is protected, including how
	error responses are protected: Not protected.		error responses are protected: Not protected.
	o Optionally define other methods of token transport than the authz-		o Optionally define other methods of token transport than the authz-
	info endpoint: Not defined		info endpoint: Not defined
	Acknowledgments		Acknowledgments
	The authors wish to thank Jim Schaad and Marco Tiloca for the input		The authors wish to thank Jim Schaad and Marco Tiloca for the input
	on this memo. Special thanks to the responsible area director Ben		on this memo. Special thanks to the responsible area director
	Kaduk for his extensive review and contributed text.		Benjamin Kaduk for his extensive review and contributed text. Ludwig
			Seitz worked on this document as part of the CelticNext projects
			CyberWI, and CRITISEC with funding from Vinnova.
	Authors' Addresses		Authors' Addresses
	Francesca Palombini		Francesca Palombini
	Ericsson AB		Ericsson AB
	Email: francesca.palombini@ericsson.com		Email: francesca.palombini@ericsson.com
	Ludwig Seitz		Ludwig Seitz
	Combitech		Combitech
End of changes. 27 change blocks.
	81 lines changed or deleted		117 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/