draft-ietf-ace-dtls-authorize-14.txt		draft-ietf-ace-dtls-authorize-15.txt
	ACE Working Group S. Gerdes		ACE Working Group S. Gerdes
	Internet-Draft O. Bergmann		Internet-Draft O. Bergmann
	Intended status: Standards Track C. Bormann		Intended status: Standards Track C. Bormann
	Expires: May 2, 2021 Universitaet Bremen TZI		Expires: 24 July 2021 Universität Bremen TZI
	G. Selander		G. Selander
	Ericsson AB		Ericsson AB
	L. Seitz		L. Seitz
	Combitech		Combitech
	October 29, 2020		20 January 2021
	Datagram Transport Layer Security (DTLS) Profile for Authentication and		Datagram Transport Layer Security (DTLS) Profile for Authentication and
	Authorization for Constrained Environments (ACE)		Authorization for Constrained Environments (ACE)
	draft-ietf-ace-dtls-authorize-14		draft-ietf-ace-dtls-authorize-15
	Abstract		Abstract
	This specification defines a profile of the ACE framework that allows		This specification defines a profile of the ACE framework that allows
	constrained servers to delegate client authentication and		constrained servers to delegate client authentication and
	authorization. The protocol relies on DTLS version 1.2 for		authorization. The protocol relies on DTLS version 1.2 for
	communication security between entities in a constrained network		communication security between entities in a constrained network
	using either raw public keys or pre-shared keys. A resource-		using either raw public keys or pre-shared keys. A resource-
	constrained server can use this protocol to delegate management of		constrained server can use this protocol to delegate management of
	authorization information to a trusted host with less severe		authorization information to a trusted host with less severe
	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 2, 2021.		This Internet-Draft will expire on 24 July 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4		2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
	3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Communication Between the Client and the Authorization		3.1. Communication Between the Client and the Authorization
	Server . . . . . . . . . . . . . . . . . . . . . . . . . 6		Server . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 7		3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 7
	3.2.1. Access Token Retrieval from the Authorization Server 7		3.2.1. Access Token Retrieval from the Authorization
	3.2.2. DTLS Channel Setup Between Client and Resource Server 9		Server . . . . . . . . . . . . . . . . . . . . . . . 7
			3.2.2. DTLS Channel Setup Between Client and Resource
			Server . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 10		3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 10
	3.3.1. Access Token Retrieval from the Authorization Server 10		3.3.1. Access Token Retrieval from the Authorization
	3.3.2. DTLS Channel Setup Between Client and Resource Server 14		Server . . . . . . . . . . . . . . . . . . . . . . . 10
			3.3.2. DTLS Channel Setup Between Client and Resource
			Server . . . . . . . . . . . . . . . . . . . . . . . 14
	3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 16		3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 16
	4. Dynamic Update of Authorization Information . . . . . . . . . 18		4. Dynamic Update of Authorization Information . . . . . . . . . 18
	5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 19		5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 19
	6. Secure Communication with an Authorization Server . . . . . . 19		6. Secure Communication with an Authorization Server . . . . . . 20
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 21		7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 21
	7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 22		7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 22
	7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 22		7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 22
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	11.1. Normative References . . . . . . . . . . . . . . . . . . 24		11.1. Normative References . . . . . . . . . . . . . . . . . . 24
	11.2. Informative References . . . . . . . . . . . . . . . . . 25		11.2. Informative References . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	This specification defines a profile of the ACE framework		This specification defines 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] over DTLS version 1.2 [RFC6347] to		server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to
	communicate. The client obtains an access token, bound to a key (the		communicate. The client obtains an access token, bound to a key (the
	proof-of-possession key), from an authorization server to prove its		proof-of-possession key), from an authorization server to prove its
	authorization to access protected resources hosted by the resource		authorization to access protected resources hosted by the resource
	server. Also, the client and the resource server are provided by the		server. Also, the client and the resource server are provided by the
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 52 ¶
	C RS AS		C RS AS
	| [---- Resource Request ------>]| |		| [---- Resource Request ------>]| |
	| | |		| | |
	| [<-AS Request Creation Hints-] | |		| [<-AS Request Creation Hints-] | |
	| | |		| | |
	| ------- Token Request ----------------------------> |		| ------- Token Request ----------------------------> |
	| | |		| | |
	| <---------------------------- Access Token --------- |		| <---------------------------- Access Token --------- |
	| + Access Information |		| + Access Information |
	Figure 1: Retrieving an Access Token		Figure 1: Retrieving an Access Token
	To determine the authorization server in charge of a resource hosted		To determine the authorization server in charge of a resource hosted
	at the resource server, the client can send an initial Unauthorized		at the resource server, the client can send an initial Unauthorized
	Resource Request message to the resource server. The resource server		Resource Request message to the resource server. The resource server
	then denies the request and sends an AS Request Creation Hints		then denies the request and sends an AS Request Creation Hints
	message containing the address of its authorization server back to		message containing the address of its authorization server back to
	the client as specified in Section 5.1.2 of		the client as specified in Section 5.1.2 of
	[I-D.ietf-ace-oauth-authz].		[I-D.ietf-ace-oauth-authz].
	Once the client knows the authorization server's address, it can send		Once the client knows the authorization server's address, it can send
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 35 ¶
	To retrieve an access token for the resource that the client wants to		To retrieve an access token for the resource that the client wants to
	access, the client requests an access token from the authorization		access, the client requests an access token from the authorization
	server. Before the client can request the access token, the client		server. Before the client can request the access token, the client
	and the authorization server MUST establish a secure communication		and the authorization server MUST establish a secure communication
	channel. This profile assumes that the keying material to secure		channel. This profile assumes that the keying material to secure
	this communication channel has securely been obtained either by		this communication channel has securely been obtained either by
	manual configuration or in an automated provisioning process. The		manual configuration or in an automated provisioning process. The
	following requirements in alignment with Section 6.5 of		following requirements in alignment with Section 6.5 of
	[I-D.ietf-ace-oauth-authz] therefore must be met:		[I-D.ietf-ace-oauth-authz] therefore must be met:
	o The client MUST securely have obtained keying material to		* The client MUST securely have obtained keying material to
	communicate with the authorization server.		communicate with the authorization server.
	o Furthermore, the client MUST verify that the authorization server		* Furthermore, the client MUST verify that the authorization server
	is authorized to provide access tokens (including authorization		is authorized to provide access tokens (including authorization
	information) about the resource server to the client, and that		information) about the resource server to the client, and that
	this authorization information about the authorization server is		this authorization information about the authorization server is
	still valid.		still valid.
	o Also, the authorization server MUST securely have obtained keying		* Also, the authorization server MUST securely have obtained keying
	material for the client, and obtained authorization rules approved		material for the client, and obtained authorization rules approved
	by the resource owner (RO) concerning the client and the resource		by the resource owner (RO) concerning the client and the resource
	server that relate to this keying material.		server that relate to this keying material.
	The client and the authorization server MUST use their respective		The client and the authorization server MUST use their respective
	keying material for all exchanged messages. How the security		keying material for all exchanged messages. How the security
	association between the client and the authorization server is		association between the client and the authorization server is
	bootstrapped is not part of this document. The client and the		bootstrapped is not part of this document. The client and the
	authorization server must ensure the confidentiality, integrity and		authorization server must ensure the confidentiality, integrity and
	authenticity of all exchanged messages within the ACE protocol.		authenticity of all exchanged messages within the ACE protocol.
	skipping to change at page 9, line 24 ¶		skipping to change at page 9, line 24 ¶
	rs_cnf : {		rs_cnf : {
	COSE_Key : {		COSE_Key : {
	kty : EC2,		kty : EC2,
	crv : P-256,		crv : P-256,
	x : h'd7cc072de2205bdc1537...',		x : h'd7cc072de2205bdc1537...',
	y : h'f95e1d4b851a2cc80fff...'		y : h'f95e1d4b851a2cc80fff...'
	}		}
	}		}
	}		}
	Figure 4: Access Token Response Example for RPK Mode		Figure 4: Access Token Response Example for RPK Mode
	3.2.2. DTLS Channel Setup Between Client and Resource Server		3.2.2. DTLS Channel Setup Between Client and Resource Server
	Before the client initiates the DTLS handshake with the resource		Before the client initiates the DTLS handshake with the resource
	server, the client MUST send a "POST" request containing the obtained		server, the client MUST send a "POST" request containing the obtained
	access token to the authz-info resource hosted by the resource		access token to the authz-info resource hosted by the resource
	server. After the client receives a confirmation that the resource		server. After the client receives a confirmation that the resource
	server has accepted the access token, it SHOULD proceed to establish		server has accepted the access token, it SHOULD proceed to establish
	a new DTLS channel with the resource server. The client MUST use its		a new DTLS channel with the resource server. The client MUST use its
	correct public key in the DTLS handshake. If the authorization		correct public key in the DTLS handshake. If the authorization
	skipping to change at page 11, line 41 ¶		skipping to change at page 11, line 41 ¶
	An example access token request for an access token with a symmetric		An example access token request for an access token with a symmetric
	proof-of-possession key is illustrated in Figure 5.		proof-of-possession key is illustrated in Figure 5.
	POST coaps://as.example.com/token		POST coaps://as.example.com/token
	Content-Format: application/ace+cbor		Content-Format: application/ace+cbor
	Payload:		Payload:
	{		{
	audience : "smokeSensor1807",		audience : "smokeSensor1807",
	}		}
	Figure 5: Example Access Token Request, (implicit) symmetric PoP-key		Figure 5: Example Access Token Request, (implicit) symmetric PoP-key
	A corresponding example access token response is illustrated in		A corresponding example access token response is illustrated in
	Figure 6. In this example, the authorization server returns a 2.01		Figure 6. In this example, the authorization server returns a 2.01
	response containing a new access token (truncated to improve		response containing a new access token (truncated to improve
	readability) and information for the client, including the symmetric		readability) and information for the client, including the symmetric
	key in the cnf claim. The information is transferred as a CBOR data		key in the cnf claim. The information is transferred as a CBOR data
	structure as specified in [I-D.ietf-ace-oauth-authz].		structure as specified in [I-D.ietf-ace-oauth-authz].
	2.01 Created		2.01 Created
	Content-Format: application/ace+cbor		Content-Format: application/ace+cbor
	skipping to change at page 12, line 24 ¶		skipping to change at page 12, line 24 ¶
	profile : coap_dtls,		profile : coap_dtls,
	cnf : {		cnf : {
	COSE_Key : {		COSE_Key : {
	kty : symmetric,		kty : symmetric,
	kid : h'3d027833fc6267ce',		kid : h'3d027833fc6267ce',
	k : h'73657373696f6e6b6579'		k : h'73657373696f6e6b6579'
	}		}
	}		}
	}		}
	Figure 6: Example Access Token Response, symmetric PoP-key		Figure 6: Example Access Token Response, symmetric PoP-key
	The access token also comprises a "cnf" claim. This claim usually		The access token also comprises a "cnf" claim. This claim usually
	contains a "COSE_Key" object that carries either the symmetric key		contains a "COSE_Key" object that carries either the symmetric key
	itself or a key identifier that can be used by the resource server to		itself or a key identifier that can be used by the resource server to
	determine the secret key it shares with the client. If the access		determine the secret key it shares with the client. If the access
	token carries a symmetric key, the access token MUST be encrypted		token carries a symmetric key, the access token MUST be encrypted
	using a "COSE_Encrypt0" structure. The authorization server MUST use		using a "COSE_Encrypt0" structure. The authorization server MUST use
	the keying material shared with the resource server to encrypt the		the keying material shared with the resource server to encrypt the
	token.		token.
	The "cnf" structure in the access token is provided in Figure 7.		The "cnf" structure in the access token is provided in Figure 7.
	cnf : {		cnf : {
	COSE_Key : {		COSE_Key : {
	kty : symmetric,		kty : symmetric,
	kid : h'3d027833fc6267ce'		kid : h'3d027833fc6267ce'
	}		}
	}		}
	Figure 7: Access Token without Keying Material		Figure 7: Access Token without Keying Material
	A response that declines any operation on the requested resource is		A response that declines any operation on the requested resource is
	constructed according to Section 5.2 of [RFC6749], (cf.		constructed according to Section 5.2 of [RFC6749], (cf.
	Section 5.6.3. of [I-D.ietf-ace-oauth-authz]). Figure 8 shows an		Section 5.6.3. of [I-D.ietf-ace-oauth-authz]). Figure 8 shows an
	example for a request that has been rejected due to invalid request		example for a request that has been rejected due to invalid request
	parameters.		parameters.
	4.00 Bad Request		4.00 Bad Request
	Content-Format: application/ace+cbor		Content-Format: application/ace+cbor
	Payload:		Payload:
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 5 ¶
	unique symmetric key is required.		unique symmetric key is required.
	In this example, HKDF consists of the composition of the HKDF-Extract		In this example, HKDF consists of the composition of the HKDF-Extract
	and HKDF-Expand steps [RFC5869]. The symmetric key is derived from		and HKDF-Expand steps [RFC5869]. The symmetric key is derived from
	the key identifier, the key derivation key and other data:		the key identifier, the key derivation key and other data:
	OKM = HKDF(salt, IKM, info, L),		OKM = HKDF(salt, IKM, info, L),
	where:		where:
	o OKM, the output keying material, is the derived symmetric key		* OKM, the output keying material, is the derived symmetric key
	o salt is the empty byte string		* salt is the empty byte string
	o IKM, the input keying material, is the key derivation key as		* IKM, the input keying material, is the key derivation key as
	defined above		defined above
	o info is the serialization of a CBOR array consisting of		* info is the serialization of a CBOR array consisting of
	([RFC8610]):		([RFC8610]):
	info = [		info = [
	type : tstr,		type : tstr,
	L : uint,		L : uint,
	access_token: bytes		access_token: bytes
	]		]
	where:		where:
	o type is set to the constant text string "ACE-CoAP-DTLS-key-		* type is set to the constant text string "ACE-CoAP-DTLS-key-
	derivation",		derivation",
	o L is the size of the symmetric key in bytes,		* L is the size of the symmetric key in bytes,
	o access_token is the content of the "access_token" field as		* access_token is the content of the "access_token" field as
	transferred from the authorization server to the resource server.		transferred from the authorization server to the resource server.
	All CBOR data types are encoded in CBOR using preferred serialization		All CBOR data types are encoded in CBOR using preferred serialization
	and deterministic encoding as specified in Section 4 of		and deterministic encoding as specified in Section 4 of [RFC8949].
	[I-D.ietf-cbor-7049bis]. This implies in particular that the "type"		This implies in particular that the "type" and "L" components use the
	and "L" components use the minimum length encoding. The content of		minimum length encoding. The content of the "access_token" field is
	the "access_token" field is treated as opaque data for the purpose of		treated as opaque data for the purpose of key derivation.
	key derivation.
	Use of a unique (per resource server) "kid" and the use of a key		Use of a unique (per resource server) "kid" and the use of a key
	derivation IKM that MUST be unique per authorization server/resource		derivation IKM that MUST be unique per authorization server/resource
	server pair as specified above will ensure that the derived key is		server pair as specified above will ensure that the derived key is
	not shared across multiple clients. However, to additionally provide		not shared across multiple clients. However, to additionally provide
	variation in the derived key across different tokens used by the same		variation in the derived key across different tokens used by the same
	client, it is additionally RECOMMENDED to include the "iat" claim and		client, it is additionally RECOMMENDED to include the "iat" claim and
	either the "exp" or "exi" claims in the access token.		either the "exp" or "exi" claims in the access token.
	3.3.2. DTLS Channel Setup Between Client and Resource Server		3.3.2. DTLS Channel Setup Between Client and Resource Server
	skipping to change at page 15, line 38 ¶		skipping to change at page 15, line 38 ¶
	that is used as value for "psk_identity" as shown in Figure 9.		that is used as value for "psk_identity" as shown in Figure 9.
	{ cnf : {		{ cnf : {
	COSE_Key : {		COSE_Key : {
	kty: symmetric,		kty: symmetric,
	kid : h'3d027833fc6267ce'		kid : h'3d027833fc6267ce'
	}		}
	}		}
	}		}
	Figure 9: Access token containing a single kid parameter		Figure 9: Access token containing a single kid parameter
	As an alternative to the access token upload, the client can provide		As an alternative to the access token upload, the client can provide
	the most recent access token in the "psk_identity" field of the		the most recent access token in the "psk_identity" field of the
	ClientKeyExchange message. To do so, the client MUST treat the		ClientKeyExchange message. To do so, the client MUST treat the
	contents of the "access_token" field from the AS-to-Client response		contents of the "access_token" field from the AS-to-Client response
	as opaque data as specified in Section 4.2 of [RFC7925] and not		as opaque data as specified in Section 4.2 of [RFC7925] and not
	perform any re-coding. This allows the resource server to retrieve		perform any re-coding. This allows the resource server to retrieve
	the shared secret directly from the "cnf" claim of the access token.		the shared secret directly from the "cnf" claim of the access token.
	If a resource server receives a ClientKeyExchange message that		If a resource server receives a ClientKeyExchange message that
	contains a "psk_identity" with a length greater than zero, it MUST		contains a "psk_identity" with a length greater than zero, it MUST
	parse the contents of the "psk_identity" field as CBOR data structure		parse the contents of the "psk_identity" field as CBOR data structure
	and process the contents as following:		and process the contents as following:
	o If the data contains a "cnf" field with a "COSE_Key" structure		* If the data contains a "cnf" field with a "COSE_Key" structure
	with a "kid", the resource server continues the DTLS handshake		with a "kid", the resource server continues the DTLS handshake
	with the associated key that corresponds to this kid.		with the associated key that corresponds to this kid.
	o If the data comprises additional CWT information, this information		* If the data comprises additional CWT information, this information
	must be stored as an access token for this DTLS association before		must be stored as an access token for this DTLS association before
	continuing with the DTLS handshake.		continuing with the DTLS handshake.
	If the contents of the "psk_identity" do not yield sufficient		If the contents of the "psk_identity" do not yield sufficient
	information to select a valid access token for the requesting client,		information to select a valid access token for the requesting client,
	the resource server aborts the DTLS handshake with an		the resource server aborts the DTLS handshake with an
	"illegal_parameter" alert.		"illegal_parameter" alert.
	When the resource server receives an access token, it MUST check if		When the resource server receives an access token, it MUST check if
	the access token is still valid, if the resource server is the		the access token is still valid, if the resource server is the
	skipping to change at page 20, line 5 ¶		skipping to change at page 20, line 11 ¶
	resource server MUST notify the client with an error response with		resource server MUST notify the client with an error response with
	code 4.01 (Unauthorized) for any long running request before		code 4.01 (Unauthorized) for any long running request before
	terminating the association.		terminating the association.
	6. Secure Communication with an Authorization Server		6. Secure Communication with an Authorization Server
	As specified in the ACE framework (Sections 5.6 and 5.7 of		As specified in the ACE framework (Sections 5.6 and 5.7 of
	[I-D.ietf-ace-oauth-authz]), the requesting entity (the resource		[I-D.ietf-ace-oauth-authz]), the requesting entity (the resource
	server and/or the client) and the authorization server communicate		server and/or the client) and the authorization server communicate
	via the token endpoint or introspection endpoint. The use of CoAP		via the token endpoint or introspection endpoint. The use of CoAP
	and DTLS for this communication is RECOMMENDED in this profile, other		and DTLS for this communication is REQUIRED in this profile. Other
	protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be		protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) will
	used instead.		require specification of additional profile(s).
	How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the		How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the
	authorization server are established is out of scope for this		authorization server are established is out of scope for this
	profile.		profile.
	If other means of securing the communication with the authorization		If other means of securing the communication with the authorization
	server are used, the communication security requirements from		server are used, the communication security requirements from
	Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable.		Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable.
	7. Security Considerations		7. Security Considerations
	skipping to change at page 24, line 22 ¶		skipping to change at page 24, line 25 ¶
	projects CyberWI, and CRITISEC with funding from Vinnova.		projects CyberWI, and CRITISEC with funding from Vinnova.
	11. References		11. References
	11.1. Normative References		11.1. Normative 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-35		Framework (ACE-OAuth)", Work in Progress, Internet-Draft,
	(work in progress), June 2020.		draft-ietf-ace-oauth-authz-36, 16 November 2020,
			<http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-
			authz-36.txt>.
	[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)", Work in Progress,
	params-13 (work in progress), April 2020.		Internet-Draft, draft-ietf-ace-oauth-params-13, 28 April
			2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
	[I-D.ietf-cbor-7049bis]		oauth-params-13.txt>.
	Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work
	in progress), September 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>.
	[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key		[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
	Ciphersuites for Transport Layer Security (TLS)",		Ciphersuites for Transport Layer Security (TLS)",
	RFC 4279, DOI 10.17487/RFC4279, December 2005,		RFC 4279, DOI 10.17487/RFC4279, December 2005,
	<https://www.rfc-editor.org/info/rfc4279>.		<https://www.rfc-editor.org/info/rfc4279>.
	skipping to change at page 25, line 46 ¶		skipping to change at page 26, line 5 ¶
	Curve Cryptography (ECC) Cipher Suites for Transport Layer		Curve Cryptography (ECC) Cipher Suites for Transport Layer
	Security (TLS) Versions 1.2 and Earlier", RFC 8422,		Security (TLS) Versions 1.2 and Earlier", RFC 8422,
	DOI 10.17487/RFC8422, August 2018,		DOI 10.17487/RFC8422, August 2018,
	<https://www.rfc-editor.org/info/rfc8422>.		<https://www.rfc-editor.org/info/rfc8422>.
	[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.		[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
	Tschofenig, "Proof-of-Possession Key Semantics for CBOR		Tschofenig, "Proof-of-Possession Key Semantics for CBOR
	Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March		Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
	2020, <https://www.rfc-editor.org/info/rfc8747>.		2020, <https://www.rfc-editor.org/info/rfc8747>.
			[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
			Representation (CBOR)", STD 94, RFC 8949,
			DOI 10.17487/RFC8949, December 2020,
			<https://www.rfc-editor.org/info/rfc8949>.
	11.2. Informative References		11.2. Informative References
	[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,		[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
	"Transport Layer Security (TLS) Session Resumption without		"Transport Layer Security (TLS) Session Resumption without
	Server-Side State", RFC 5077, DOI 10.17487/RFC5077,		Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
	January 2008, <https://www.rfc-editor.org/info/rfc5077>.		January 2008, <https://www.rfc-editor.org/info/rfc5077>.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand		[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,		Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,		DOI 10.17487/RFC5869, May 2010,
	skipping to change at page 26, line 46 ¶		skipping to change at page 27, line 13 ¶
	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>.
	Authors' Addresses		Authors' Addresses
	Stefanie Gerdes		Stefanie Gerdes
	Universitaet Bremen TZI		Universität Bremen TZI
	Postfach 330440		Postfach 330440
	Bremen D-28359		D-28359 Bremen
	Germany		Germany
	Phone: +49-421-218-63906		Phone: +49-421-218-63906
	Email: gerdes@tzi.org		Email: gerdes@tzi.org
	Olaf Bergmann		Olaf Bergmann
	Universitaet Bremen TZI		Universität Bremen TZI
	Postfach 330440		Postfach 330440
	Bremen D-28359		D-28359 Bremen
	Germany		Germany
	Phone: +49-421-218-63904		Phone: +49-421-218-63904
	Email: bergmann@tzi.org		Email: bergmann@tzi.org
	Carsten Bormann		Carsten Bormann
	Universitaet Bremen TZI		Universität Bremen TZI
	Postfach 330440		Postfach 330440
	Bremen D-28359		D-28359 Bremen
	Germany		Germany
	Phone: +49-421-218-63921		Phone: +49-421-218-63921
	Email: cabo@tzi.org		Email: cabo@tzi.org
	Goeran Selander		Göran Selander
	Ericsson AB		Ericsson AB
	Email: goran.selander@ericsson.com		Email: goran.selander@ericsson.com
	Ludwig Seitz		Ludwig Seitz
	Combitech		Combitech
	Djaeknegatan 31		Djäknegatan 31
	Malmoe 211 35		SE-211 35 Malmö
	Sweden		Sweden
	Email: ludwig.seitz@combitech.se		Email: ludwig.seitz@combitech.se
End of changes. 45 change blocks.
	68 lines changed or deleted		74 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/