Diff: rfc9200v6.txt - rfc9200.txt

	rfc9200v6.txt	rfc9200.txt

	skipping to change at line 12 ¶	skipping to change at line 12 ¶
	Internet Engineering Task Force (IETF) L. Seitz	Internet Engineering Task Force (IETF) L. Seitz
	Request for Comments: 9200 Combitech	Request for Comments: 9200 Combitech
	Category: Standards Track G. Selander	Category: Standards Track G. Selander
	ISSN: 2070-1721 Ericsson	ISSN: 2070-1721 Ericsson
	E. Wahlstroem	E. Wahlstroem

	S. Erdtman	S. Erdtman
	Spotify AB	Spotify AB
	H. Tschofenig	H. Tschofenig
	Arm Ltd.	Arm Ltd.

	June 2022	August 2022

	Authentication and Authorization for Constrained Environments Using the	Authentication and Authorization for Constrained Environments Using the
	OAuth 2.0 Framework (ACE-OAuth)	OAuth 2.0 Framework (ACE-OAuth)

	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	authorization in Internet of Things (IoT) environments called
	ACE-OAuth. The framework is based on a set of building blocks	ACE-OAuth. The framework is based on a set of building blocks
	including OAuth 2.0 and the Constrained Application Protocol (CoAP),	including OAuth 2.0 and the Constrained Application Protocol (CoAP),

	skipping to change at line 196 ¶	skipping to change at line 196 ¶
	phones and tablets, may implement multiple profiles and will	phones and tablets, may implement multiple profiles and will
	therefore be able to interact with a wider range of constrained	therefore be able to interact with a wider range of constrained
	devices. Requirements on profiles are described at contextually	devices. Requirements on profiles are described at contextually
	appropriate places throughout this specification and also summarized	appropriate places throughout this specification and also summarized
	in Appendix C.	in Appendix C.

	2. Terminology	2. Terminology

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

	"OPTIONAL" in this document are to be interpreted as described in BCP	"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.

	Certain security-related terms, such as "authentication",	Certain security-related terms, such as "authentication",
	"authorization", "confidentiality", "(data) integrity", "message	"authorization", "confidentiality", "(data) integrity", "message
	authentication code", and "verify", are taken from [RFC4949].	authentication code", and "verify", are taken from [RFC4949].

	Since exchanges in this specification are described as RESTful	Since exchanges in this specification are described as RESTful

	protocol interactions, HTTP [RFC7231] offers useful terminology.	protocol interactions, HTTP [RFC9110] offers useful terminology.
	(Note that "RESTful" refers to the Representational State Transfer	(Note that "RESTful" refers to the Representational State Transfer
	(REST) architecture.)	(REST) architecture.)

	Terminology for entities in the architecture is defined in OAuth 2.0	Terminology for entities in the architecture is defined in OAuth 2.0
	[RFC6749], such as client (C), resource server (RS), and	[RFC6749], such as client (C), resource server (RS), and
	authorization server (AS).	authorization server (AS).

	Note that the term "endpoint" is used here following its OAuth	Note that the term "endpoint" is used here following its OAuth
	definition, which is to denote resources, such as token and	definition, which is to denote resources, such as token and
	introspection at the AS and authz-info at the RS (see Section 5.10.1	introspection at the AS and authz-info at the RS (see Section 5.10.1

	skipping to change at line 258 ¶	skipping to change at line 258 ¶
	widespread deployment. Many IoT devices can support OAuth 2.0	widespread deployment. Many IoT devices can support OAuth 2.0
	without any additional extensions, but for certain constrained	without any additional extensions, but for certain constrained
	settings, additional profiling is needed.	settings, additional profiling is needed.

	Another building block is the lightweight web transfer protocol CoAP	Another building block is the lightweight web transfer protocol CoAP
	[RFC7252], for those communication environments where HTTP is not	[RFC7252], for those communication environments where HTTP is not
	appropriate. CoAP typically runs on top of UDP, which further	appropriate. CoAP typically runs on top of UDP, which further
	reduces overhead and message exchanges. While this specification	reduces overhead and message exchanges. While this specification
	defines extensions for the use of OAuth over CoAP, other underlying	defines extensions for the use of OAuth over CoAP, other underlying
	protocols are not prohibited from being supported in the future, such	protocols are not prohibited from being supported in the future, such

	as HTTP/2 [RFC7540], Message Queuing Telemetry Transport (MQTT)	as HTTP/2 [RFC9113], Message Queuing Telemetry Transport (MQTT)
	[MQTT5.0], Bluetooth Low Energy (BLE) [BLE], and QUIC [RFC9000].	[MQTT5.0], Bluetooth Low Energy (BLE) [BLE], and QUIC [RFC9000].
	Note that this document specifies protocol exchanges in terms of	Note that this document specifies protocol exchanges in terms of
	RESTful verbs, such as GET and POST. Future profiles using protocols	RESTful verbs, such as GET and POST. Future profiles using protocols
	that do not support these verbs MUST specify how the corresponding	that do not support these verbs MUST specify how the corresponding
	protocol messages are transmitted instead.	protocol messages are transmitted 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. When CoAP is not	payloads are encoded in CBOR when CoAP is used. When CoAP is not
	used, the use of CBOR remains RECOMMENDED.	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,	[RFC9147] or TLS [RFC8446]). COSE is used to secure self-contained
	such as proof-of-possession (PoP) tokens, which are an extension to	tokens, such as proof-of-possession (PoP) tokens, which are an
	the OAuth bearer tokens. The default token format is defined in CBOR	extension to the OAuth bearer tokens. The default token format is
	Web Token (CWT) [RFC8392]. Application-layer security for CoAP using	defined in CBOR Web Token (CWT) [RFC8392]. Application-layer
	COSE can be provided with Object Security for Constrained RESTful	security for CoAP using COSE can be provided with Object Security for
	Environments (OSCORE) [RFC8613].	Constrained RESTful Environments (OSCORE) [RFC8613].

	With the building blocks listed above, solutions satisfying various	With the building blocks listed above, solutions satisfying various
	IoT device and network constraints are possible. A list of	IoT device and network constraints are possible. A list of
	constraints is described in detail in [RFC7228], and a description of	constraints is described in detail in [RFC7228], and a description of
	how the building blocks mentioned above relate to the various	how the building blocks mentioned above relate to the various
	constraints can be found in Appendix A.	constraints can be found in Appendix A.

	Luckily, not every IoT device suffers from all constraints.	Luckily, not every IoT device suffers from all constraints.
	Nevertheless, the ACE framework takes all these aspects into account	Nevertheless, the ACE framework takes all these aspects into account
	and allows several different deployment variants to coexist, rather	and allows several different deployment variants to coexist, rather

	skipping to change at line 535 ¶	skipping to change at line 535 ¶
	the response parameters defined by OAuth 2.0 and the PoP access	the response parameters defined by OAuth 2.0 and the PoP access
	token extension, this framework defines parameters that can be	token extension, this framework defines parameters that can be
	used to inform the client about capabilities of the RS, e.g., the	used to inform the client about capabilities of the RS, e.g., the
	profile the RS supports. More information about these parameters	profile the RS supports. More information about these parameters
	can be found in Section 5.8.4.	can be found in Section 5.8.4.

	Resource Request (C):	Resource Request (C):
	The client interacts with the RS to request access to the	The client interacts with the RS to request access to the
	protected resource and provides the access token. The protocol to	protected resource and provides the access token. The protocol to
	use between the client and the RS is not restricted to CoAP.	use between the client and the RS is not restricted to CoAP.

	HTTP, HTTP/2 [RFC7540], QUIC [RFC9000], MQTT [MQTT5.0], Bluetooth	HTTP, HTTP/2 [RFC9113], QUIC [RFC9000], MQTT [MQTT5.0], Bluetooth
	Low Energy [BLE], etc., are also viable candidates.	Low Energy [BLE], etc., are also viable candidates.

	Depending on the device limitations and the selected protocol,	Depending on the device limitations and the selected protocol,
	this exchange may be split up into two parts:	this exchange may be split up into two parts:

	(1) the client sends the access token containing, or referencing,	(1) the client sends the access token containing, or referencing,
	the authorization information to the RS that will be used for	the authorization information to the RS that will be used for
	subsequent resource requests by the client, and	subsequent resource requests by the client, and

	(2) the client makes the resource access request using the	(2) the client makes the resource access request using the

	skipping to change at line 2947 ¶	skipping to change at line 2947 ¶
	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	[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", STD 94, RFC 8949,	Representation (CBOR)", STD 94, RFC 8949,
	DOI 10.17487/RFC8949, December 2020,	DOI 10.17487/RFC8949, December 2020,
	<https://www.rfc-editor.org/info/rfc8949>.	<https://www.rfc-editor.org/info/rfc8949>.

	[RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication	[RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication
	and Authorization in Constrained Environments (ACE)",	and Authorization in Constrained Environments (ACE)",

	RFC 9201, DOI 10.17487/RFC9201, June 2022,	RFC 9201, DOI 10.17487/RFC9201, August 2022,
	<https://www.rfc-editor.org/info/rfc9201>.	<https://www.rfc-editor.org/info/rfc9201>.

	9.2. Informative References	9.2. Informative References

	[BLE] Bluetooth Special Interest Group, "Core Specification	[BLE] Bluetooth Special Interest Group, "Core Specification
	5.3", Section 4.4, July 2021,	5.3", Section 4.4, July 2021,
	<https://www.bluetooth.com/specifications/bluetooth-core-	<https://www.bluetooth.com/specifications/bluetooth-core-
	specification/>.	specification/>.

	[DCAF] Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP	[DCAF] Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP

	skipping to change at line 3015 ¶	skipping to change at line 3015 ¶

	[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth	[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
	2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,	2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
	August 2013, <https://www.rfc-editor.org/info/rfc7009>.	August 2013, <https://www.rfc-editor.org/info/rfc7009>.

	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228,	Constrained-Node Networks", RFC 7228,
	DOI 10.17487/RFC7228, May 2014,	DOI 10.17487/RFC7228, May 2014,
	<https://www.rfc-editor.org/info/rfc7228>.	<https://www.rfc-editor.org/info/rfc7228>.


	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,
	<https://www.rfc-editor.org/info/rfc7231>.

	[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,	[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
	"Assertion Framework for OAuth 2.0 Client Authentication	"Assertion Framework for OAuth 2.0 Client Authentication
	and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,	and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
	May 2015, <https://www.rfc-editor.org/info/rfc7521>.	May 2015, <https://www.rfc-editor.org/info/rfc7521>.


	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,
	<https://www.rfc-editor.org/info/rfc7540>.

	[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and	[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
	P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",	P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
	RFC 7591, DOI 10.17487/RFC7591, July 2015,	RFC 7591, DOI 10.17487/RFC7591, July 2015,
	<https://www.rfc-editor.org/info/rfc7591>.	<https://www.rfc-editor.org/info/rfc7591>.

	[RFC7641] Hartke, K., "Observing Resources in the Constrained	[RFC7641] Hartke, K., "Observing Resources in the Constrained
	Application Protocol (CoAP)", RFC 7641,	Application Protocol (CoAP)", RFC 7641,
	DOI 10.17487/RFC7641, September 2015,	DOI 10.17487/RFC7641, September 2015,
	<https://www.rfc-editor.org/info/rfc7641>.	<https://www.rfc-editor.org/info/rfc7641>.


	skipping to change at line 3089 ¶	skipping to change at line 3079 ¶
	[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,	[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
	"OAuth 2.0 Device Authorization Grant", RFC 8628,	"OAuth 2.0 Device Authorization Grant", RFC 8628,
	DOI 10.17487/RFC8628, August 2019,	DOI 10.17487/RFC8628, August 2019,
	<https://www.rfc-editor.org/info/rfc8628>.	<https://www.rfc-editor.org/info/rfc8628>.

	[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based	[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,	Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,	DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/info/rfc9000>.	<https://www.rfc-editor.org/info/rfc9000>.


		[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
		Ed., "HTTP Semantics", STD 97, RFC 9110,
		DOI 10.17487/RFC9110, June 2022,
		<https://www.rfc-editor.org/info/rfc9110>.

		[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
		DOI 10.17487/RFC9113, June 2022,
		<https://www.rfc-editor.org/info/rfc9113>.

	[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The	[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version	Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,	1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
	<https://www.rfc-editor.org/info/rfc9147>.	<https://www.rfc-editor.org/info/rfc9147>.

	[RFC9202] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and	[RFC9202] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
	L. Seitz, "Datagram Transport Layer Security (DTLS)	L. Seitz, "Datagram Transport Layer Security (DTLS)
	Profile for Authentication and Authorization for	Profile for Authentication and Authorization for
	Constrained Environments (ACE)", RFC 9202,	Constrained Environments (ACE)", RFC 9202,

	DOI 10.17487/RFC9202, June 2022,	DOI 10.17487/RFC9202, August 2022,
	<https://www.rfc-editor.org/info/rfc9202>.	<https://www.rfc-editor.org/info/rfc9202>.

	[RFC9203] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,	[RFC9203] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
	"The Object Security for Constrained RESTful Environments	"The Object Security for Constrained RESTful Environments
	(OSCORE) Profile of the Authentication and Authorization	(OSCORE) Profile of the Authentication and Authorization
	for Constrained Environments (ACE) Framework", RFC 9203,	for Constrained Environments (ACE) Framework", RFC 9203,

	DOI 10.17487/RFC9203, June 2022,	DOI 10.17487/RFC9203, August 2022,
	<https://www.rfc-editor.org/info/rfc9203>.	<https://www.rfc-editor.org/info/rfc9203>.

	Appendix A. Design Justification	Appendix A. Design Justification

	This section provides further insight into the design decisions of	This section provides further insight into the design decisions of
	the solution documented in this document. Section 3 lists several	the solution documented in this document. Section 3 lists several
	building blocks and briefly summarizes their importance. The	building blocks and briefly summarizes their importance. The
	justification for offering some of those building blocks, as opposed	justification for offering some of those building blocks, as opposed
	to using OAuth 2.0 as is, is given below.	to using OAuth 2.0 as is, is given below.


End of changes. 12 change blocks.
	25 lines changed or deleted	24 lines changed or added
This html diff was produced by rfcdiff 1.48.