< draft-ietf-ace-oauth-authz-28.txt		draft-ietf-ace-oauth-authz-29.txt >
	skipping to change at page 1, line 17 ¶		skipping to change at page 1, line 17 ¶
	E. Wahlstroem		E. Wahlstroem
	S. Erdtman		S. Erdtman
	Spotify AB		Spotify AB
	H. Tschofenig		H. Tschofenig
	Arm Ltd.		Arm Ltd.
	December 14, 2019		December 14, 2019
	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-28		draft-ietf-ace-oauth-authz-29
	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 CoAP, thus transforming a well-known and widely used		OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
	authorization solution into a form suitable for IoT devices.		transforming a well-known and widely used authorization solution into
	Existing specifications are used where possible, but extensions are		a form suitable for IoT devices. Existing specifications are used
	added and profiles are defined to better serve the IoT use cases.		where possible, but extensions are added and profiles are defined to
			better serve the IoT use cases.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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/.
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 45 ¶
	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.
	While prior work on authorization solutions for the Web and for the		While prior work on authorization solutions for the Web and for the
	mobile environment also applies to the Internet of Things (IoT)		mobile environment also applies to the Internet of Things (IoT)
	environment, many IoT devices are constrained, for example, in terms		environment, many IoT devices are constrained, for example, in terms
	of processing capabilities, available memory, etc. For web		of processing capabilities, available memory, etc. For web
	applications on constrained nodes, this specification RECOMMENDS the		applications on constrained nodes, this specification RECOMMENDS the
	use of CoAP [RFC7252] as replacement for HTTP.		use of the Constrained Application Protocol (CoAP) [RFC7252] as
			replacement for HTTP.
	A detailed treatment of constraints can be found in [RFC7228], and		Appendix A gives an overview of the constraints considered in this
	the different IoT deployments present a continuous range of device		design, and a more detailed treatment of constraints can be found in
	and network capabilities. Taking energy consumption as an example:		[RFC7228]. This design aims to accommodate different IoT deployments
	At one end there are energy-harvesting or battery powered devices		and thus a continuous range of device and network capabilities.
	which have a tight power budget, on the other end there are mains-		Taking energy consumption as an example: At one end there are energy-
	powered devices, and all levels in between.		harvesting or battery powered devices which have a tight power
			budget, on the other end there are mains-powered devices, and all
			levels in between.
	Hence, IoT devices may be very different in terms of available		Hence, IoT devices may be very different in terms of available
	processing and message exchange capabilities and there is a need to		processing and message exchange capabilities and there is a need to
	support many different authorization use cases [RFC7744].		support many different authorization use cases [RFC7744].
	This specification describes a framework for authentication and		This specification describes a framework for authentication and
	authorization in constrained environments (ACE) built on re-use of		authorization in constrained environments (ACE) built on re-use of
	OAuth 2.0 [RFC6749], thereby extending authorization to Internet of		OAuth 2.0 [RFC6749], thereby extending authorization to Internet of
	Things devices. This specification contains the necessary building		Things devices. This specification contains the necessary building
	blocks for adjusting OAuth 2.0 to IoT environments.		blocks for adjusting OAuth 2.0 to IoT environments.
	More detailed, interoperable specifications can be found in profiles.		More detailed, interoperable specifications can be found in separate
	Implementations may claim conformance with a specific profile,		profile specifications. Implementations may claim conformance with a
	whereby implementations utilizing the same profile interoperate while		specific profile, whereby implementations utilizing the same profile
	implementations of different profiles are not expected to be		interoperate while implementations of different profiles are not
	interoperable. Some devices, such as mobile phones and tablets, may		expected to be interoperable. Some devices, such as mobile phones
	implement multiple profiles and will therefore be able to interact		and tablets, may implement multiple profiles and will therefore be
	with a wider range of low end devices. Requirements on profiles are		able to interact with a wider range of low end devices. Requirements
	described at contextually appropriate places throughout this		on profiles are described at contextually appropriate places
	specification, and also summarized in Appendix C.		throughout this specification, and also summarized 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 BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		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",
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 38 ¶
	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], MQTT [MQTT5.0], BLE [BLE] and QUIC		as HTTP/2 [RFC7540], Message Queuing Telemetry Transport (MQTT)
			[MQTT5.0], Bluetooth Low Energy (BLE) [BLE] and QUIC
	[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 CBOR [RFC7049], for encodings where JSON		A third building block is the Concise Binary Object Representation
	[RFC8259] is not sufficiently compact. CBOR is a binary encoding		(CBOR) [RFC7049], for encodings where JSON [RFC8259] is not
	designed for small code and message size, which may be used for		sufficiently compact. CBOR is a binary encoding designed for small
	encoding of self contained tokens, and also for encoding payloads		code and message size, which may be used for encoding of self
	transferred in protocol messages.		contained tokens, and also for encoding payloads transferred in
			protocol messages.
	A fourth building block is the CBOR-based secure message format 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].
	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
	skipping to change at page 18, line 46 ¶		skipping to change at page 18, line 49 ¶
	Payload :		Payload :
	{		{
	"AS" : "coaps://as.example.com/token",		"AS" : "coaps://as.example.com/token",
	"audience" : "coaps://rs.example.com"		"audience" : "coaps://rs.example.com"
	"scope" : "rTempC",		"scope" : "rTempC",
	"cnonce" : h'e0a156bb3f'		"cnonce" : h'e0a156bb3f'
	}		}
	Figure 3: AS Request Creation Hints payload example		Figure 3: AS Request Creation Hints payload example
	In this example, the attribute AS points the receiver of this message		In the example above, the response parameter "AS" points the receiver
	to the URI "coaps://as.example.com/token" to request access		of this message to the URI "coaps://as.example.com/token" to request
	permissions. The originator of the AS Request Creation Hints payload		access tokens. The RS sending this response (i.e., RS) uses an
	(i.e., RS) uses a local clock that is loosely synchronized with a		internal clock that is only loosely synchronized with the clock of
	time scale common between RS and AS (e.g., wall clock time).		the AS. Therefore it can not reliably verify the expiration time of
	Therefore, it has included a parameter "nonce" (see Section 5.1.2.1).		access tokens it receives. To ensure a certain level of access token
			freshness nevetheless, the RS has included a "cnonce" parameter (see
			Section 5.1.2.1) in the response.
	Figure 4 illustrates the mandatory to use binary encoding of the		Figure 4 illustrates the mandatory to use binary encoding of the
	message payload shown in Figure 3.		message payload shown in Figure 3.
	a4 # map(4)		a4 # map(4)
	01 # unsigned(1) (=AS)		01 # unsigned(1) (=AS)
	78 1c # text(28)		78 1c # text(28)
	636f6170733a2f2f61732e657861		636f6170733a2f2f61732e657861
	6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token"		6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token"
	05 # unsigned(5) (=audience)		05 # unsigned(5) (=audience)
	skipping to change at page 19, line 35 ¶		skipping to change at page 19, line 39 ¶
	5.1.2.1. The Client-Nonce Parameter		5.1.2.1. The Client-Nonce Parameter
	If the RS does not synchronize its clock with the AS, it could be		If the RS does not synchronize its clock with the AS, it could be
	tricked into accepting old access tokens, that are either expired or		tricked into accepting old access tokens, that are either expired or
	have been compromised. In order to ensure some level of token		have been compromised. In order to ensure some level of token
	freshness in that case, the RS can use the "cnonce" (client-nonce)		freshness in that case, the RS can use the "cnonce" (client-nonce)
	parameter. The processing requirements for this parameter are as		parameter. The processing requirements for this parameter are as
	follows:		follows:
	o A RS sending a "cnonce" parameter in an an AS Request Creation		o A RS sending a "cnonce" parameter in an AS Request Creation Hints
	Hints message MUST store information to validate that a given		message MUST store information to validate that a given cnonce is
	cnonce is fresh. How this is implemented internally is out of		fresh. How this is implemented internally is out of scope for
	scope for this specification. Expiration of client-nonces should		this specification. Expiration of client-nonces should be based
	be based roughly on the time it would take a client to obtain an		roughly on the time it would take a client to obtain an access
	access token after receiving the AS Request Creation Hints		token after receiving the AS Request Creation Hints message, with
	message, with some allowance for unexpected delays.		some allowance for unexpected delays.
	o A client receiving a "cnonce" parameter in an AS Request Creation		o A client receiving a "cnonce" parameter in an AS Request Creation
	Hints message MUST include this in the parameters when requesting		Hints message MUST include this in the parameters when requesting
	an access token at the AS, using the "cnonce" parameter from		an access token at the AS, using the "cnonce" parameter from
	Section 5.6.4.4.		Section 5.6.4.4.
	o If an AS grants an access token request containing a "cnonce"		o If an AS grants an access token request containing a "cnonce"
	parameter, it MUST include this value in the access token, using		parameter, it MUST include this value in the access token, using
	the "cnonce" claim specified in Section 5.8.		the "cnonce" claim specified in Section 5.8.
	skipping to change at page 29, line 8 ¶		skipping to change at page 29, line 8 ¶
	5.6.4.1. Grant Type		5.6.4.1. Grant Type
	The abbreviations specified in the registry defined in Section 8.4		The abbreviations specified in the registry defined in Section 8.4
	MUST be used in CBOR encodings instead of the string values defined		MUST be used in CBOR encodings instead of the string values defined
	in [RFC6749], if CBOR payloads are used.		in [RFC6749], if CBOR payloads are used.
	/--------------------+------------+------------------------\		/--------------------+------------+------------------------\
	| Name | CBOR Value | Original Specification |		| Name | CBOR Value | Original Specification |
	|--------------------+------------+------------------------|		|--------------------+------------+------------------------|
	| password | 0 | RFC6749 |		| password | 0 | [RFC6749] |
	| authorization_code | 1 | RFC6749 |		| authorization_code | 1 | [RFC6749] |
	| client_credentials | 2 | RFC6749 |		| client_credentials | 2 | [RFC6749] |
	| refresh_token | 3 | RFC6749 |		| refresh_token | 3 | [RFC6749] |
	\--------------------+------------+------------------------/		\--------------------+------------+------------------------/
	Figure 11: CBOR abbreviations for common grant types		Figure 11: CBOR abbreviations for common grant types
	5.6.4.2. Token Type		5.6.4.2. Token Type
	The "token_type" parameter, defined in section 5.1 of [RFC6749],		The "token_type" parameter, defined in section 5.1 of [RFC6749],
	allows the AS to indicate to the client which type of access token it		allows the AS to indicate to the client which type of access token it
	is receiving (e.g., a bearer token).		is receiving (e.g., a bearer token).
End of changes. 11 change blocks.
	45 lines changed or deleted		53 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/