Diff: draft-ietf-ace-oauth-authz-39.txt - draft-ietf-ace-oauth-authz-40.txt

	< draft-ietf-ace-oauth-authz-39.txt		draft-ietf-ace-oauth-authz-40.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: October 18, 2021 Ericsson		Expires: October 28, 2021 Ericsson
	E. Wahlstroem		E. Wahlstroem

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

	April 16, 2021		April 26, 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-39		draft-ietf-ace-oauth-authz-40

	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 October 18, 2021.		This Internet-Draft will expire on October 28, 2021.

	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 8 ¶		skipping to change at page 3, line 8 ¶
	5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31		5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31
	5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32		5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32
	5.9.2. Introspection Response . . . . . . . . . . . . . . . 33		5.9.2. Introspection Response . . . . . . . . . . . . . . . 33
	5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34		5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34
	5.9.4. Mapping Introspection Parameters to CBOR . . . . . . 35		5.9.4. Mapping Introspection Parameters to CBOR . . . . . . 35
	5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35		5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35
	5.10.1. The Authorization Information Endpoint . . . . . . . 36		5.10.1. The Authorization Information Endpoint . . . . . . . 36
	5.10.1.1. Verifying an Access Token . . . . . . . . . . . 37		5.10.1.1. Verifying an Access Token . . . . . . . . . . . 37
	5.10.1.2. Protecting the Authorization Information		5.10.1.2. Protecting the Authorization Information
	Endpoint . . . . . . . . . . . . . . . . . . . . 39		Endpoint . . . . . . . . . . . . . . . . . . . . 39

	5.10.2. Client Requests to the RS . . . . . . . . . . . . . 39		5.10.2. Client Requests to the RS . . . . . . . . . . . . . 40
	5.10.3. Token Expiration . . . . . . . . . . . . . . . . . . 40		5.10.3. Token Expiration . . . . . . . . . . . . . . . . . . 40
	5.10.4. Key Expiration . . . . . . . . . . . . . . . . . . . 42		5.10.4. Key Expiration . . . . . . . . . . . . . . . . . . . 42
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 42		6. Security Considerations . . . . . . . . . . . . . . . . . . . 42

	6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42		6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 43
	6.2. Communication Security . . . . . . . . . . . . . . . . . 43		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 . . 48
	7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49		7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50

	skipping to change at page 25, line 51 ¶		skipping to change at page 25, line 51 ¶
	knowledge of the capabilities of the client and the RS (see		knowledge of the capabilities of the client and the RS (see
	Appendix D). This prior knowledge may, for example, be set by the		Appendix D). This prior knowledge may, for example, be set by the
	use of a dynamic client registration protocol exchange [RFC7591]. If		use of a dynamic client registration protocol exchange [RFC7591]. If
	the client has requested a specific proof-of-possession key using the		the client has requested a specific proof-of-possession key using the
	"req_cnf" parameter from [I-D.ietf-ace-oauth-params], this may also		"req_cnf" parameter from [I-D.ietf-ace-oauth-params], this may also
	influence which profile the AS selects, as it needs to support the		influence which profile the AS selects, as it needs to support the
	use of the key type requested the client.		use of the key type requested the client.

	The content of the successful reply is the Access Information. When		The content of the successful reply is the Access Information. When
	using CoAP, the payload MUST be encoded as a CBOR map, when using		using CoAP, the payload MUST be encoded as a CBOR map, when using

	HTTP the encoding is a JSON map as specified in seciton 5.1 of		HTTP the encoding is a JSON map as specified in section 5.1 of

	[RFC6749]. In both cases the parameters specified in Section 5.1 of		[RFC6749]. In both cases the parameters specified in Section 5.1 of
	[RFC6749] are used, with the following additions and changes:		[RFC6749] are used, with the following additions and changes:

	ace_profile:		ace_profile:
	OPTIONAL unless the request included an empty ace_profile		OPTIONAL unless the request included an empty ace_profile
	parameter in which case it is MANDATORY. This indicates the		parameter in which case it is MANDATORY. This indicates the
	profile that the client MUST use towards the RS. See		profile that the client MUST use towards the RS. See
	Section 5.8.4.3 for the formatting of this parameter. If this		Section 5.8.4.3 for the formatting of this parameter. If this
	parameter is absent, the AS assumes that the client implicitly		parameter is absent, the AS assumes that the client implicitly

	skipping to change at page 37, line 11 ¶		skipping to change at page 37, line 11 ¶
	use. This is a difference to how access tokens are handled in OAuth		use. This is a difference to how access tokens are handled in OAuth
	2.0, where the access token is typically sent along with each		2.0, where the access token is typically sent along with each
	request, and therefore not stored at the RS.		request, and therefore not stored at the RS.

	When using this framework it is RECOMMENDED that an RS stores only		When using this framework it is RECOMMENDED that an RS stores only
	one token per proof-of-possession key. This means that an additional		one token per proof-of-possession key. This means that an additional
	token linked to the same key will supersede any existing token at the		token linked to the same key will supersede any existing token at the
	RS, by replacing the corresponding authorization information. The		RS, by replacing the corresponding authorization information. The
	reason is that this greatly simplifies (constrained) implementations,		reason is that this greatly simplifies (constrained) implementations,
	with respect to required storage and resolving a request to the		with respect to required storage and resolving a request to the

	applicable token.		applicable token. The use of multiple access tokens for a single
			client increases the strain on the resource server as it must
			consider every access token and calculate the actual permissions of
			the client. Also, tokens may contradict each other which may lead
			the server to enforce wrong permissions. If one of the access tokens
			expires earlier than others, the resulting permissions may offer
			insufficient protection.

	If the payload sent to the authz-info endpoint does not parse to a		If the payload sent to the authz-info endpoint does not parse to a
	token, the RS MUST respond with a response code equivalent to the		token, the RS MUST respond with a response code equivalent to the
	CoAP code 4.00 (Bad Request).		CoAP code 4.00 (Bad Request).

	The RS MAY make an introspection request to validate the token before		The RS MAY make an introspection request to validate the token before
	responding to the POST request to the authz-info endpoint, e.g. if		responding to the POST request to the authz-info endpoint, e.g. if
	the token is an opaque reference. Some transport protocols may		the token is an opaque reference. Some transport protocols may
	provide a way to indicate that the RS is busy and the client should		provide a way to indicate that the RS is busy and the client should
	retry after an interval; this type of status update would be		retry after an interval; this type of status update would be

	skipping to change at page 44, line 19 ¶		skipping to change at page 44, line 27 ¶
	encrypting it, for example encryption of CWTs is specified in		encrypting it, for example encryption of CWTs is specified in
	Section 5.1 of [RFC8392]. Such additional protection can be		Section 5.1 of [RFC8392]. Such additional protection can be
	necessary if the token is later transferred over an insecure		necessary if the token is later transferred over an insecure
	connection (e.g. when it is sent to the authz-info endpoint).		connection (e.g. when it is sent to the authz-info endpoint).

	Care must by taken by developers to prevent leakage of the PoP		Care must by taken by developers to prevent leakage of the PoP
	credentials (i.e., the private key or the symmetric key). An		credentials (i.e., the private key or the symmetric key). An
	adversary in possession of the PoP credentials bound to the access		adversary in possession of the PoP credentials bound to the access
	token will be able to impersonate the client. Be aware that this is		token will be able to impersonate the client. Be aware that this is
	a real risk with many constrained environments, since adversaries may		a real risk with many constrained environments, since adversaries may

	get physical access to the devices and can therefore use phyical		get physical access to the devices and can therefore use physical
	extraction techniques to gain access to memory contents. This risk		extraction techniques to gain access to memory contents. This risk
	can be mitigated to some extent by making sure that keys are		can be mitigated to some extent by making sure that keys are
	refreshed frequently, by using software isolation techniques and by		refreshed frequently, by using software isolation techniques and by
	using hardware security.		using hardware security.

	6.3. Long-Term Credentials		6.3. Long-Term Credentials

	Both clients and RSs have long-term credentials that are used to		Both clients and RSs have long-term credentials that are used to
	secure communications, and authenticate to the AS. These credentials		secure communications, and authenticate to the AS. These credentials
	need to be protected against unauthorized access. In constrained		need to be protected against unauthorized access. In constrained

	skipping to change at page 59, line 18 ¶		skipping to change at page 59, line 18 ¶

	9. Acknowledgments		9. Acknowledgments

	This document is a product of the ACE working group of the IETF.		This document is a product of the ACE working group of the IETF.

	Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and		Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and
	UMA in IoT scenarios, Robert Taylor for his discussion input, and		UMA in IoT scenarios, Robert Taylor for his discussion input, and
	Malisa Vucinic for his input on the predecessors of this proposal.		Malisa Vucinic for his input on the predecessors of this proposal.

	Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from		Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from

	where large parts of the security considerations where copied.		where parts of the security considerations where copied.

	Thanks to Stefanie Gerdes, Olaf Bergmann, and Carsten Bormann for		Thanks to Stefanie Gerdes, Olaf Bergmann, and Carsten Bormann for
	contributing their work on AS discovery from draft-gerdes-ace-dcaf-		contributing their work on AS discovery from draft-gerdes-ace-dcaf-

	authorize (see Section 5.1).		authorize (see Section 5.1) and the considerations on multiple access
			tokens.

	Thanks to Jim Schaad and Mike Jones for their comprehensive reviews.		Thanks to Jim Schaad and Mike Jones for their comprehensive reviews.

	Thanks to Benjamin Kaduk for his input on various questions related		Thanks to Benjamin Kaduk for his input on various questions related
	to this work.		to this work.

	Thanks to Cigdem Sengul for some very useful review comments.		Thanks to Cigdem Sengul for some very useful review comments.

	Thanks to Carsten Bormann for contributing the text for the CoRE		Thanks to Carsten Bormann for contributing the text for the CoRE
	Resource Type registry.		Resource Type registry.

	skipping to change at page 59, line 49 ¶		skipping to change at page 59, line 50 ¶
	Seitz was also received further funding for this work by Vinnova in		Seitz was also received further funding for this work by Vinnova in
	the context of the CelticNext project Critisec.		the context of the CelticNext project Critisec.

	10. References		10. References

	10.1. Normative References		10.1. Normative References

	[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-14 (work in progress), March 2021.		params-13 (work in progress), April 2020.

	[IANA.CborWebTokenClaims]		[IANA.CborWebTokenClaims]
	IANA, "CBOR Web Token (CWT) Claims",		IANA, "CBOR Web Token (CWT) Claims",
	<https://www.iana.org/assignments/cwt/cwt.xhtml#claims-		<https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
	registry>.		registry>.

	[IANA.CoreParameters]		[IANA.CoreParameters]
	IANA, "Constrained RESTful Environments (CoRE)		IANA, "Constrained RESTful Environments (CoRE)
	Parameters", <https://www.iana.org/assignments/core-		Parameters", <https://www.iana.org/assignments/core-
	parameters/core-parameters.xhtml>.		parameters/core-parameters.xhtml>.

	skipping to change at page 62, line 37 ¶		skipping to change at page 62, line 37 ¶
	[I-D.erdtman-ace-rpcc]		[I-D.erdtman-ace-rpcc]
	Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-		Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-
	Key as OAuth client credentials", draft-erdtman-ace-		Key as OAuth client credentials", draft-erdtman-ace-
	rpcc-02 (work in progress), October 2017.		rpcc-02 (work in progress), October 2017.

	[I-D.ietf-ace-dtls-authorize]		[I-D.ietf-ace-dtls-authorize]
	Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and		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)", draft-ietf-ace-dtls-		Constrained Environments (ACE)", draft-ietf-ace-dtls-

	authorize-16 (work in progress), March 2021.		authorize-15 (work in progress), January 2021.

	[I-D.ietf-ace-oscore-profile]		[I-D.ietf-ace-oscore-profile]
	Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,		Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
	"OSCORE Profile of the Authentication and Authorization		"OSCORE Profile of the Authentication and Authorization
	for Constrained Environments Framework", draft-ietf-ace-		for Constrained Environments Framework", draft-ietf-ace-

	oscore-profile-18 (work in progress), April 2021.		oscore-profile-15 (work in progress), January 2021.

	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-34 (work		and Secure Transport", draft-ietf-quic-transport-34 (work
	in progress), January 2021.		in progress), January 2021.

	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version

	1.3", draft-ietf-tls-dtls13-41 (work in progress),		1.3", draft-ietf-tls-dtls13-40 (work in progress), January
	February 2021.		2021.

	[Margi10impact]		[Margi10impact]
	Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr,		Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr,
	M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold,		M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold,
	"Impact of Operating Systems on Wireless Sensor Networks		"Impact of Operating Systems on Wireless Sensor Networks
	(Security) Applications and Testbeds", Proceedings of		(Security) Applications and Testbeds", Proceedings of
	the 19th International Conference on Computer		the 19th International Conference on Computer
	Communications and Networks (ICCCN), August 2010.		Communications and Networks (ICCCN), August 2010.

	[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT		[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT

End of changes. 15 change blocks.
	17 lines changed or deleted		24 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/