draft-ietf-ace-dtls-authorize-13.txt		draft-ietf-ace-dtls-authorize-14.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: March 12, 2021 Universitaet Bremen TZI		Expires: May 2, 2021 Universitaet Bremen TZI
	G. Selander		G. Selander
	Ericsson AB		Ericsson AB
	L. Seitz		L. Seitz
	Combitech		Combitech
	September 08, 2020		October 29, 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-13		draft-ietf-ace-dtls-authorize-14
	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 March 12, 2021.		This Internet-Draft will expire on May 2, 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 16, line 51 ¶		skipping to change at page 16, line 51 ¶
	or Section 3.3, respectively, the client is authorized to access		or Section 3.3, respectively, the client is authorized to access
	resources covered by the access token it has uploaded to the authz-		resources covered by the access token it has uploaded to the authz-
	info resource hosted by the resource server.		info resource hosted by the resource server.
	With the successful establishment of the DTLS channel, the client and		With the successful establishment of the DTLS channel, the client and
	the resource server have proven that they can use their respective		the resource server have proven that they can use their respective
	keying material. An access token that is bound to the client's		keying material. An access token that is bound to the client's
	keying material is associated with the channel. According to		keying material is associated with the channel. According to
	Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one		Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one
	access token for each client. New access tokens issued by the		access token for each client. New access tokens issued by the
	authorization server replace previously issued access tokens for the		authorization server SHOULD replace previously issued access tokens
	respective client. The resource server therefore must have a common		for the respective client. The resource server therefore needs a
	understanding with the authorization server how access tokens are		common understanding with the authorization server how access tokens
	ordered. The authorization server may, e.g., specify a "cti" claim		are ordered. The authorization server may, e.g., specify a "cti"
	for the access token (see Section 5.8.3 of		claim for the access token (see Section 5.8.3 of
	[I-D.ietf-ace-oauth-authz]) to employ a strict order.		[I-D.ietf-ace-oauth-authz]) to employ a strict order.
	Any request that the resource server receives on a DTLS channel that		Any request that the resource server receives on a DTLS channel that
	is tied to an access token via its keying material MUST be checked		is tied to an access token via its keying material MUST be checked
	against the authorization rules that can be determined with the		against the authorization rules that can be determined with the
	access token. The resource server MUST check for every request if		access token. The resource server MUST check for every request if
	the access token is still valid. If the token has expired, the		the access token is still valid. If the token has expired, the
	resource server MUST remove it. Incoming CoAP requests that are not		resource server MUST remove it. Incoming CoAP requests that are not
	authorized with respect to any access token that is associated with		authorized with respect to any access token that is associated with
	the client MUST be rejected by the resource server with 4.01		the client MUST be rejected by the resource server with 4.01
	skipping to change at page 24, line 7 ¶		skipping to change at page 24, line 7 ¶
	nodes.		nodes.
	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		Special thanks to Jim Schaad for his contributions and reviews of
	document. Special thanks to Ben Kaduk for his thorough reviews of		this document and to Ben Kaduk for his thorough reviews of this
	this document.		document. Thanks also to Paul Kyzivat for his review.
	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
	skipping to change at page 24, line 32 ¶		skipping to change at page 24, line 32 ¶
	Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35
	(work in progress), June 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]		[I-D.ietf-cbor-7049bis]
	Bormann, C. and P. Hoffman, "Concise Binary Object		Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", draft-ietf-cbor-7049bis-14 (work		Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work
	in progress), June 2020.		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>.
End of changes. 7 change blocks.
	14 lines changed or deleted		14 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/