draft-ietf-ace-dtls-authorize-11.txt		draft-ietf-ace-dtls-authorize-12.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: December 20, 2020 Universitaet Bremen TZI		Expires: January 7, 2021 Universitaet Bremen TZI
	G. Selander		G. Selander
	Ericsson AB		Ericsson AB
	L. Seitz		L. Seitz
	Combitech		Combitech
	June 18, 2020		July 06, 2020
	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-11		draft-ietf-ace-dtls-authorize-12
	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 December 20, 2020.		This Internet-Draft will expire on January 7, 2021.
	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 29 ¶		skipping to change at page 2, line 29 ¶
	2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4		2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
	3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . . . . . 6		3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 6
	3.2.1. DTLS Channel Setup Between Client and Resource Server 9		3.2.1. DTLS Channel Setup Between Client and Resource Server 9
	3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 10		3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 10
	3.3.1. DTLS Channel Setup Between Client and Resource Server 14		3.3.1. 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 . . . . . . . . . 17		4. Dynamic Update of Authorization Information . . . . . . . . . 17
	5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 18		5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 19
	6. Secure Communication with an Authorization Server . . . . . . 19		6. Secure Communication with an Authorization Server . . . . . . 19
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 19		7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 20		7.1. Reuse of Existing Sessions . . . . . . . . . . . . . . . 21
	7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 21		7.2. Multiple Access Tokens . . . . . . . . . . . . . . . . . 21
	7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 21		7.3. Out-of-Band Configuration . . . . . . . . . . . . . . . . 22
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	11.1. Normative References . . . . . . . . . . . . . . . . . . 23		11.1. Normative References . . . . . . . . . . . . . . . . . . 23
	11.2. Informative References . . . . . . . . . . . . . . . . . 25		11.2. Informative References . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	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
	skipping to change at page 8, line 20 ¶		skipping to change at page 8, line 20 ¶
	server MUST protect the integrity of the access token such that the		server MUST protect the integrity of the access token such that the
	resource server can detect unauthorized changes. If the access token		resource server can detect unauthorized changes. If the access token
	contains confidential data, the authorization server MUST also		contains confidential data, the authorization server MUST also
	protect the confidentiality of the access token.		protect the confidentiality of the access token.
	The client MUST ascertain that the access token response belongs to a		The client MUST ascertain that the access token response belongs to a
	certain previously sent access token request, as the request may		certain previously sent access token request, as the request may
	specify the resource server with which the client wants to		specify the resource server with which the client wants to
	communicate.		communicate.
	An example access token response from the authorization to the client		An example access token response from the authorization server to the
	is depicted in Figure 4. Here, the contents of the "access_token"		client is depicted in Figure 4. Here, the contents of the
	claim have been truncated to improve readability. Caching proxies		"access_token" claim have been truncated to improve readability.
	process the Max-Age option in the CoAP response which has a default		Caching proxies process the Max-Age option in the CoAP response which
	value of 60 seconds (Section 5.6.1 of [RFC7252]). The authorization		has a default value of 60 seconds (Section 5.6.1 of [RFC7252]). The
	server SHOULD adjust the Max-Age option such that it does not exceed		authorization server SHOULD adjust the Max-Age option such that it
	the "expires_in" parameter to avoid stale responses.		does not exceed the "expires_in" parameter to avoid stale responses.
	2.01 Created		2.01 Created
	Content-Format: application/ace+cbor		Content-Format: application/ace+cbor
	Max-Age: 3560		Max-Age: 3560
	Payload:		Payload:
	{		{
	access_token : b64'SlAV32hkKG...		access_token : b64'SlAV32hkKG...
	(remainder of CWT omitted for brevity;		(remainder of CWT omitted for brevity;
	CWT contains the client's RPK in the cnf claim)',		CWT contains the client's RPK in the cnf claim)',
	expires_in : 3600,		expires_in : 3600,
	skipping to change at page 13, line 33 ¶		skipping to change at page 13, line 33 ¶
	o IKM, the input keying material, is the key derivation key as		o 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		o info is the serialization of a CBOR array consisting of
	([RFC8610]):		([RFC8610]):
	info = [		info = [
	type : tstr,		type : tstr,
	L : uint,		L : uint,
	access_token: map		access_token: bytes
	]		]
	where:		where:
	o type is set to the constant text string "ACE-CoAP-DTLS-key-		o 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,		o L is the size of the symmetric key in bytes,
	o access_token is the decrypted access_token as transferred from the		o access_token is the content of the "access_token" field as
	authorization server to the resource server. The decrypted access		transferred from the authorization server to the resource server.
	token usually denotes a CWT claim set represented as CBOR map.
			All CBOR data types are encoded in CBOR using preferred serialization
			and deterministic encoding as specified in Section 4 of
			[I-D.ietf-cbor-7049bis]. This implies in particular that the "type"
			and "L" components use the minimum length encoding. The content of
			the "access_token" field is treated as opaque data for the purpose of
			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 is unique per authorization server/resource		derivation IKM that is 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.1. DTLS Channel Setup Between Client and Resource Server		3.3.1. DTLS Channel Setup Between Client and Resource Server
	skipping to change at page 15, line 17 ¶		skipping to change at page 15, line 30 ¶
	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		o 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 stored key associated with this kid.		with the associated key that corresponds to this kid.
	o If the data comprises additional CWT information, this information		o If the data comprises additional CWT information, this information
	must be stored as 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
	intended destination (i.e., the audience of the token), and if the		intended destination (i.e., the audience of the token), and if the
	skipping to change at page 20, line 43 ¶		skipping to change at page 20, line 51 ¶
	exchange and interject forged messages with a valid cookie to		exchange and interject forged messages with a valid cookie to
	continue with the handshake. A similar issue exists with the		continue with the handshake. A similar issue exists with the
	unprotected authorization information endpoint where the resource		unprotected authorization information endpoint where the resource
	server needs to keep valid access tokens until their expiry.		server needs to keep valid access tokens until their expiry.
	Adversaries can fill up the constrained resource server's internal		Adversaries can fill up the constrained resource server's internal
	storage for a very long time with interjected or otherwise retrieved		storage for a very long time with interjected or otherwise retrieved
	valid access tokens. The protection of access tokens that are stored		valid access tokens. The protection of access tokens that are stored
	in the authorization information endpoint depends on the keying		in the authorization information endpoint depends on the keying
	material that is used between the authorization server and the		material that is used between the authorization server and the
	resource server: The resource server must ensure that it processes		resource server: The resource server must ensure that it processes
	only access tokens that are encrypted and integrity-protected by an		only access tokens that are (encrypted and) integrity-protected by an
	authorization server that is authorized to provide access tokens for		authorization server that is authorized to provide access tokens for
	the resource server.		the resource server.
	7.1. Reuse of Existing Sessions		7.1. Reuse of Existing Sessions
	To avoid the overhead of a repeated DTLS handshake, [RFC7925]		To avoid the overhead of a repeated DTLS handshake, [RFC7925]
	recommends session resumption [RFC5077] to reuse session state from		recommends session resumption [RFC5077] to reuse session state from
	an earlier DTLS association and thus requires client side		an earlier DTLS association and thus requires client side
	implementation. In this specification, the DTLS session is subject		implementation. In this specification, the DTLS session is subject
	to the authorization rules denoted by the access token that was used		to the authorization rules denoted by the access token that was used
	for the initial setup of the DTLS association. Enabling session		for the initial setup of the DTLS association. Enabling session
	resumption would require the server to transfer the authorization		resumption would require the server to transfer the authorization
	information with the session state in an encrypted SessionTicket to		information with the session state in an encrypted SessionTicket to
	the client. Assuming that the server uses long-lived keying		the client. Assuming that the server uses long-lived keying
	material, this could open up attacks due to the lack of forward		material, this could open up attacks due to the lack of forward
	secrecy. Moreover, using this mechanism, a client can resume a DTLS		secrecy. Moreover, using this mechanism, a client can resume a DTLS
	session without proving the possession of the PoP key again.		session without proving the possession of the PoP key again.
	Therefore, the use of session resumption is NOT RECOMMENDED for		Therefore, the use of session resumption is NOT RECOMMENDED for
	resource servers.		resource servers.
	Since renogiation of DTLS associations is prone to attacks as well,		Since renegotiation of DTLS associations is prone to attacks as well,
	[RFC7925] requires clients to decline any renogiation attempt. A		[RFC7925] requires clients to decline any renogiation attempt. A
	server that wants to initiate re-keying therefore SHOULD periodically		server that wants to initiate re-keying therefore SHOULD periodically
	force a full handshake.		force a full handshake.
	7.2. Multiple Access Tokens		7.2. Multiple Access Tokens
	The use of multiple access tokens for a single client increases the		The use of multiple access tokens for a single client increases the
	strain on the resource server as it must consider every access token		strain on the resource server as it must consider every access token
	and calculate the actual permissions of the client. Also, tokens may		and calculate the actual permissions of the client. Also, tokens may
	contradict each other which may lead the server to enforce wrong		contradict each other which may lead the server to enforce wrong
	skipping to change at page 23, line 18 ¶		skipping to change at page 23, line 30 ¶
	Profile ID: TBD (suggested: 1)		Profile ID: TBD (suggested: 1)
	Change Controller: IESG		Change Controller: IESG
	Reference: [RFC-XXXX]		Reference: [RFC-XXXX]
	10. Acknowledgments		10. Acknowledgments
	Thanks to Jim Schaad for his contributions and reviews of this		Thanks to Jim Schaad for his contributions and reviews of this
	document. Special thanks to Ben Kaduk for his thorough review of		document. Special thanks to Ben Kaduk for his thorough reviews of
	this document.		this document.
	Ludwig Seitz worked on this document as part of the CelticNext		Ludwig Seitz worked on this document as part of the CelticNext
	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-33		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35
	(work in progress), February 2020.		(work in progress), June 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-13 (work in progress), April 2020.		params-13 (work in progress), April 2020.
			[I-D.ietf-cbor-7049bis]
			Bormann, C. and P. Hoffman, "Concise Binary Object
			Representation (CBOR)", draft-ietf-cbor-7049bis-14 (work
			in progress), June 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>.
End of changes. 18 change blocks.
	26 lines changed or deleted		37 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/