< draft-ietf-ace-oauth-authz-42.txt		draft-ietf-ace-oauth-authz-43.txt >
	ACE Working Group L. Seitz		ACE Working Group L. Seitz
	Internet-Draft Combitech		Internet-Draft Combitech
	Intended status: Standards Track G. Selander		Intended status: Standards Track G. Selander
	Expires: December 10, 2021 Ericsson		Expires: January 11, 2022 Ericsson
	E. Wahlstroem		E. Wahlstroem
	S. Erdtman		S. Erdtman
	Spotify AB		Spotify AB
	H. Tschofenig		H. Tschofenig
	Arm Ltd.		Arm Ltd.
	June 8, 2021		July 10, 2021
	Authentication and Authorization for Constrained Environments (ACE)		Authentication and Authorization for Constrained Environments (ACE)
	using the OAuth 2.0 Framework (ACE-OAuth)		using the OAuth 2.0 Framework (ACE-OAuth)
	draft-ietf-ace-oauth-authz-42		draft-ietf-ace-oauth-authz-43
	Abstract		Abstract
	This specification defines a framework for authentication and		This specification defines a framework for authentication and
	authorization in Internet of Things (IoT) environments called ACE-		authorization in Internet of Things (IoT) environments called ACE-
	OAuth. The framework is based on a set of building blocks including		OAuth. The framework is based on a set of building blocks including
	OAuth 2.0 and the Constrained Application Protocol (CoAP), thus		OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
	transforming a well-known and widely used authorization solution into		transforming a well-known and widely used authorization solution into
	a form suitable for IoT devices. Existing specifications are used		a form suitable for IoT devices. Existing specifications are used
	where possible, but extensions are added and profiles are defined to		where possible, but extensions are added and profiles are defined to
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 10, 2021.		This Internet-Draft will expire on January 11, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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/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 3, line 21 ¶		skipping to change at page 3, line 21 ¶
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 42		6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 43		6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 43
	6.2. Communication Security . . . . . . . . . . . . . . . . . 44		6.2. Communication Security . . . . . . . . . . . . . . . . . 44
	6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44		6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44
	6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 45		6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 45
	6.5. Minimal Security Requirements for Communication . 45		6.5. Minimal Security Requirements for Communication . 45
	6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46		6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46
	6.7. Combining Profiles . . . . . . . . . . . . . . . . . . . 47		6.7. Combining Profiles . . . . . . . . . . . . . . . . . . . 47
	6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47		6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47
	6.9. Identifying Audiences . . . . . . . . . . . . . . . . . . 48		6.9. Identifying Audiences . . . . . . . . . . . . . . . . . . 48
	6.10. Denial of Service Against or with Introspection . . 48		6.10. Denial of Service Against or with Introspection . . 49
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
	8.1. ACE Authorization Server Request Creation Hints . . . . . 50		8.1. ACE Authorization Server Request Creation Hints . . . . . 50
	8.2. CoRE Resource Type Registry . . . . . . . . . . . . . . . 51		8.2. CoRE Resource Type Registry . . . . . . . . . . . . . . . 51
	8.3. OAuth Extensions Error Registration . . . . . . . . . . . 51		8.3. OAuth Extensions Error Registration . . . . . . . . . . . 51
	8.4. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51		8.4. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51
	8.5. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 52		8.5. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 52
	8.6. OAuth Access Token Types . . . . . . . . . . . . . . . . 52		8.6. OAuth Access Token Types . . . . . . . . . . . . . . . . 52
	8.7. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52		8.7. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 53
	8.7.1. Initial Registry Contents . . . . . . . . . . . . . . 53		8.7.1. Initial Registry Contents . . . . . . . . . . . . . . 53
	8.8. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53		8.8. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53
	8.9. OAuth Parameter Registration . . . . . . . . . . . . . . 54		8.9. OAuth Parameter Registration . . . . . . . . . . . . . . 54
	8.10. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 54		8.10. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 54
	8.11. OAuth Introspection Response Parameter Registration . . . 54		8.11. OAuth Introspection Response Parameter Registration . . . 55
	8.12. OAuth Token Introspection Response CBOR Mappings Registry 55		8.12. OAuth Token Introspection Response CBOR Mappings Registry 55
	8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55		8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 56
	8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56		8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56
	8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57		8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57
	8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 58		8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 58
	8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58		8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
	10.1. Normative References . . . . . . . . . . . . . . . . . . 59		10.1. Normative References . . . . . . . . . . . . . . . . . . 60
	10.2. Informative References . . . . . . . . . . . . . . . . . 62		10.2. Informative References . . . . . . . . . . . . . . . . . 62
	Appendix A. Design Justification . . . . . . . . . . . . . . . . 65		Appendix A. Design Justification . . . . . . . . . . . . . . . . 65
	Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68		Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 69
	Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71		Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71
	Appendix D. Assumptions on AS Knowledge about C and RS . . . . . 72		Appendix D. Assumptions on AS Knowledge about C and RS . . . . . 72
	Appendix E. Differences to OAuth 2.0 . . . . . . . . . . . . . . 72		Appendix E. Differences to OAuth 2.0 . . . . . . . . . . . . . . 73
	Appendix F. Deployment Examples . . . . . . . . . . . . . . . . 73		Appendix F. Deployment Examples . . . . . . . . . . . . . . . . 73
	F.1. Local Token Validation . . . . . . . . . . . . . . . . . 73		F.1. Local Token Validation . . . . . . . . . . . . . . . . . 74
	F.2. Introspection Aided Token Validation . . . . . . . . . . 77		F.2. Introspection Aided Token Validation . . . . . . . . . . 78
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
	1. Introduction		1. Introduction
	Authorization is the process for granting approval to an entity to		Authorization is the process for granting approval to an entity to
	access a generic resource [RFC4949]. The authorization task itself		access a generic resource [RFC4949]. The authorization task itself
	can best be described as granting access to a requesting client, for		can best be described as granting access to a requesting client, for
	a resource hosted on a device, the resource server (RS). This		a resource hosted on a device, the resource server (RS). This
	exchange is mediated by one or multiple authorization servers (AS).		exchange is mediated by one or multiple authorization servers (AS).
	Managing authorization for a large number of devices and users can be		Managing authorization for a large number of devices and users can be
	a complex task.		a complex task.
	skipping to change at page 6, line 34 ¶		skipping to change at page 6, line 34 ¶
	[I-D.ietf-quic-transport]. Note that this document specifies		[I-D.ietf-quic-transport]. Note that this document specifies
	protocol exchanges in terms of RESTful verbs such as GET and POST.		protocol exchanges in terms of RESTful verbs such as GET and POST.
	Future profiles using protocols that do not support these verbs MUST		Future profiles using protocols that do not support these verbs MUST
	specify how the corresponding protocol messages are transmitted		specify how the corresponding protocol messages are transmitted
	instead.		instead.
	A third building block is the Concise Binary Object Representation		A third building block is the Concise Binary Object Representation
	(CBOR) [RFC8949], for encodings where JSON [RFC8259] is not		(CBOR) [RFC8949], for encodings where JSON [RFC8259] is not
	sufficiently compact. CBOR is a binary encoding designed for small		sufficiently compact. CBOR is a binary encoding designed for small
	code and message size. Self-contained tokens and protocol message		code and message size. Self-contained tokens and protocol message
	payloads are encoded in CBOR when CoAP is used.		payloads are encoded in CBOR when CoAP is used. When CoAP is not
			used, the use of CBOR remains RECOMMENDED.
	A fourth building block is CBOR Object Signing and Encryption (COSE)		A fourth building block is CBOR Object Signing and Encryption (COSE)
	[RFC8152], which enables object-level layer security as an		[RFC8152], which enables object-level layer security as an
	alternative or complement to transport layer security (DTLS [RFC6347]		alternative or complement to transport layer security (DTLS [RFC6347]
	or TLS [RFC8446]). COSE is used to secure self-contained tokens such		or TLS [RFC8446]). COSE is used to secure self-contained tokens such
	as proof-of-possession (PoP) tokens, which are an extension to the		as proof-of-possession (PoP) tokens, which are an extension to the
	OAuth bearer tokens. The default token format is defined in CBOR Web		OAuth bearer tokens. The default token format is defined in CBOR Web
	Token (CWT) [RFC8392]. Application-layer security for CoAP using		Token (CWT) [RFC8392]. Application-layer security for CoAP using
	COSE can be provided with OSCORE [RFC8613].		COSE can be provided with OSCORE [RFC8613].
	skipping to change at page 47, line 7 ¶		skipping to change at page 47, line 7 ¶
	lose the current values of counters tracking the "exi" claims of		lose the current values of counters tracking the "exi" claims of
	tokens it is storing.		tokens it is storing.
	The first drawback is inherent to the deployment scenario and the		The first drawback is inherent to the deployment scenario and the
	"exi" solution. It can therefore not be mitigated without requiring		"exi" solution. It can therefore not be mitigated without requiring
	the RS be online at times. The second drawback can be mitigated by		the RS be online at times. The second drawback can be mitigated by
	regularly storing the value of "exi" counters to persistent memory.		regularly storing the value of "exi" counters to persistent memory.
	6.7. Combining Profiles		6.7. Combining Profiles
	There may be use cases were different profiles of this framework are		There may be use cases where different transport and security
	combined. For example, an MQTT-TLS profile is used between the		protocols are allowed for the different interactions, and, if that is
	client and the RS in combination with a CoAP-DTLS profile for		not explicitly covered by an existing profile, it corresponds to
	interactions between the client and the AS. The security of a		combining profiles into a new one. For example, a new profile could
	profile MUST NOT depend on the assumption that the profile is used		specify that a previously-defined MQTT-TLS profile is used between
	for all the different types of interactions in this framework.		the client and the RS in combination with a previously-defined CoAP-
			DTLS profile for interactions between the client and the AS. The new
			profile that combines existing profiles MUST specify how the existing
			profiles' security properties are achieved. Any profile therefore
			MUST clearly specify its security requirements and MUST document if
			its security depends on the combination of various protocol
			interactions.
	6.8. Unprotected Information		6.8. Unprotected Information
	Communication with the authz-info endpoint, as well as the various		Communication with the authz-info endpoint, as well as the various
	error responses defined in this framework, all potentially include		error responses defined in this framework, all potentially include
	sending information over an unprotected channel. These messages may		sending information over an unprotected channel. These messages may
	leak information to an adversary, or may be manipulated by active		leak information to an adversary, or may be manipulated by active
	attackers to induce incorrect behavior. For example error responses		attackers to induce incorrect behavior. For example error responses
	for requests to the Authorization Information endpoint can reveal		for requests to the Authorization Information endpoint can reveal
	information about an otherwise opaque access token to an adversary		information about an otherwise opaque access token to an adversary
	skipping to change at page 73, line 4 ¶		skipping to change at page 73, line 27 ¶
	o Cardinality of "grant_type" parameter -- In client-to-AS requests		o Cardinality of "grant_type" parameter -- In client-to-AS requests
	using OAuth 2.0, the "grant_type" parameter is required (per		using OAuth 2.0, the "grant_type" parameter is required (per
	[RFC6749]). In this framework, this parameter is optional. See		[RFC6749]). In this framework, this parameter is optional. See
	Section 5.8.1.		Section 5.8.1.
	o Encoding of "scope" parameter -- In client-to-AS requests using		o Encoding of "scope" parameter -- In client-to-AS requests using
	OAuth 2.0, the "scope" parameter is string encoded (per		OAuth 2.0, the "scope" parameter is string encoded (per
	[RFC6749]). In this framework, this parameter may also be encoded		[RFC6749]). In this framework, this parameter may also be encoded
	as a byte string. See Section 5.8.1.		as a byte string. See Section 5.8.1.
	o Cardinality of "token_type" parameter -- in AS-to-client responses		o Cardinality of "token_type" parameter -- in AS-to-client responses
	using OAuth 2.0, the token_type parameter is required (per		using OAuth 2.0, the token_type parameter is required (per
	[RFC6749]). In this framework, this parameter is optional. See		[RFC6749]). In this framework, this parameter is optional. See
	Section 5.8.2.		Section 5.8.2.
	o Access token retention -- in OAuth 2.0, the access token is sent		o Access token retention -- in OAuth 2.0, the access token may be
	with each request to the RS. In this framework, the RS must be		sent with every request to the RS. The exact use of access tokens
			depends on the semantics of the application and the session
			management concept it uses. In this framework, the RS must be
	able to store these tokens for later use. See Section 5.10.1.		able to store these tokens for later use. See Section 5.10.1.
	Appendix F. Deployment Examples		Appendix F. Deployment Examples
	There is a large variety of IoT deployments, as is indicated in		There is a large variety of IoT deployments, as is indicated in
	Appendix A, and this section highlights a few common variants. This		Appendix A, and this section highlights a few common variants. This
	section is not normative but illustrates how the framework can be		section is not normative but illustrates how the framework can be
	applied.		applied.
	For each of the deployment variants, there are a number of possible		For each of the deployment variants, there are a number of possible
End of changes. 16 change blocks.
	25 lines changed or deleted		33 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/