< draft-ietf-ace-oauth-authz-27.txt		draft-ietf-ace-oauth-authz-28.txt >
	ACE Working Group L. Seitz		ACE Working Group L. Seitz
	Internet-Draft RISE		Internet-Draft Combitech
	Intended status: Standards Track G. Selander		Intended status: Standards Track G. Selander
	Expires: May 24, 2020 Ericsson		Expires: June 16, 2020 Ericsson
	E. Wahlstroem		E. Wahlstroem
	S. Erdtman		S. Erdtman
	Spotify AB		Spotify AB
	H. Tschofenig		H. Tschofenig
	Arm Ltd.		Arm Ltd.
	November 21, 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-27		draft-ietf-ace-oauth-authz-28
	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 CoAP, thus transforming a well-known and widely used
	authorization solution into a form suitable for IoT devices.		authorization solution into a form suitable for IoT devices.
	Existing specifications are used where possible, but extensions are		Existing specifications are used where possible, but extensions are
	added and profiles are defined to better serve the IoT use cases.		added and profiles are defined to better serve the IoT use cases.
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 May 24, 2020.		This Internet-Draft will expire on June 16, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 18 ¶		skipping to change at page 3, line 18 ¶
	5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39		5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39
	5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40		5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40
	5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41		5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 42		6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42		6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42
	6.2. Communication Security . . . . . . . . . . . . . . . . . 43		6.2. Communication Security . . . . . . . . . . . . . . . . . 43
	6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 43		6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 43
	6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44		6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44
	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 . . . . . . . . . . . . . . . . . . . 46		6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 47
	6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47		6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47
	6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 47		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
	8.1. ACE Authorization Server Request Creation Hints . . . . . 50		8.1. ACE Authorization Server Request Creation Hints . . . . . 50
	8.2. OAuth Extensions Error Registration . . . . . . . . . . . 50		8.2. OAuth Extensions Error Registration . . . . . . . . . . . 51
	8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51		8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51
	8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 51		8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 51
	8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 52		8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 52
	8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52		8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52
	8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 52		8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 52
	8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 52		8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53
	8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 53		8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 53
	8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 53		8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 53
	8.10. OAuth Introspection Response Parameter Registration . . . 54		8.10. OAuth Introspection Response Parameter Registration . . . 54
	8.11. OAuth Token Introspection Response CBOR Mappings Registry 54		8.11. OAuth Token Introspection Response CBOR Mappings Registry 54
	8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55		8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55
	8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 55		8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 55
	8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56		8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56
	8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57		8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57
	8.16. Expert Review Instructions . . . . . . . . . . . . . . . 57		8.16. Expert Review Instructions . . . . . . . . . . . . . . . 57
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
	10.1. Normative References . . . . . . . . . . . . . . . . . . 59		10.1. Normative References . . . . . . . . . . . . . . . . . . 59
	10.2. Informative References . . . . . . . . . . . . . . . . . 61		10.2. Informative References . . . . . . . . . . . . . . . . . 61
	Appendix A. Design Justification . . . . . . . . . . . . . . . . 64		Appendix A. Design Justification . . . . . . . . . . . . . . . . 64
	Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 67		Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68
	Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70		Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70
	Appendix D. Assumptions on AS knowledge about C and RS . . . . . 70		Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71
	Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71		Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71
	E.1. Local Token Validation . . . . . . . . . . . . . . . . . 71		E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72
	E.2. Introspection Aided Token Validation . . . . . . . . . . 75		E.2. Introspection Aided Token Validation . . . . . . . . . . 76
	Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 79		Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80
	F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 80		F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81
	F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 80		F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81
	F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 80		F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81
	F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 80		F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81
	F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 80		F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81
	F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 80		F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 81
	F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 81		F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 82
	F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 81		F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 82
	F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 81		F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 82
	F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 81		F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 82
	F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 82		F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 83
	F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 82		F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 83
	F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 82		F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 83
	F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 82		F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 83
	F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 82		F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 83
	F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 83		F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 84
	F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 83		F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 84
	F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 83		F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 84
	F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 84		F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 85
	F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 84		F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 85
	F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 84		F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 85
	F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 85		F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 86
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
	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 42, line 43 ¶		skipping to change at page 42, line 43 ¶
	If the token is intended for multiple recipients (i.e. an audience		If the token is intended for multiple recipients (i.e. an audience
	that is a group), integrity protection of the token with a symmetric		that is a group), integrity protection of the token with a symmetric
	key, shared between the AS and the recipients, is not sufficient,		key, shared between the AS and the recipients, is not sufficient,
	since any of the recipients could modify the token undetected by the		since any of the recipients could modify the token undetected by the
	other recipients. Therefore a token with a multi-recipient audience		other recipients. Therefore a token with a multi-recipient audience
	MUST be protected with an asymmetric signature.		MUST be protected with an asymmetric signature.
	It is important for the authorization server to include the identity		It is important for the authorization server to include the identity
	of the intended recipient (the audience), typically a single resource		of the intended recipient (the audience), typically a single resource
	server (or a list of resource servers), in the token. Using a single		server (or a list of resource servers), in the token. The same
	shared secret as proof-of-possession key with multiple resource		shared secret MUST NOT be used as proof-of-possession key with
	servers is NOT RECOMMENDED since the benefit from using the proof-of-		multiple resource servers since the benefit from using the proof-of-
	possession concept is then significantly reduced.		possession concept is then significantly reduced.
	If clients are capable of doing so, they should frequently request		If clients are capable of doing so, they should frequently request
	fresh access tokens, as this allows the AS to keep the lifetime of		fresh access tokens, as this allows the AS to keep the lifetime of
	the tokens short. This allows the AS to use shorter proof-of-		the tokens short. This allows the AS to use shorter proof-of-
	possession key sizes, which translate to a performance benefit for		possession key sizes, which translate to a performance benefit for
	the client and for the resource server. Shorter keys also lead to		the client and for the resource server. Shorter keys also lead to
	shorter messages (particularly with asymmetric keying material).		shorter messages (particularly with asymmetric keying material).
	When authorization servers bind symmetric keys to access tokens, they		When authorization servers bind symmetric keys to access tokens, they
	skipping to change at page 43, line 21 ¶		skipping to change at page 43, line 21 ¶
	that is still valid. Client-initiated revocation is specified in		that is still valid. Client-initiated revocation is specified in
	[RFC7009] for OAuth 2.0. Other revocation mechanisms are currently		[RFC7009] for OAuth 2.0. Other revocation mechanisms are currently
	not specified, as the underlying assumption in OAuth is that access		not specified, as the underlying assumption in OAuth is that access
	tokens are issued with a relatively short lifetime. This may not		tokens are issued with a relatively short lifetime. This may not
	hold true for disconnected constrained devices, needing access tokens		hold true for disconnected constrained devices, needing access tokens
	with relatively long lifetimes, and would therefore necessitate		with relatively long lifetimes, and would therefore necessitate
	further standardization work that is out of scope for this document.		further standardization work that is out of scope for this document.
	6.2. Communication Security		6.2. Communication Security
	The authorization server MUST offer confidentiality protection for		Communication with the authorization server MUST use confidentiality
	any interactions with the client. This step is extremely important		protection. This step is extremely important since the client or the
	since the client may obtain the proof-of-possession key from the		RS may obtain the proof-of-possession key from the authorization
	authorization server for use with a specific access token. Not using		server for use with a specific access token. Not using
	confidentiality protection exposes this secret (and the access token)		confidentiality protection exposes this secret (and the access token)
	to an eavesdropper thereby completely negating proof-of-possession		to an eavesdropper thereby completely negating proof-of-possession
	security. Profiles MUST specify how communication security according		security. Profiles MUST specify how communication security according
	to the requirements in Section 5 is provided.		to the requirements in Section 5 is provided.
	Additional protection for the access token can be applied by		Additional protection for the access token can be applied by
	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).
	skipping to change at page 44, line 12 ¶		skipping to change at page 44, line 12 ¶
	need to be protected against unauthorized access. In constrained		need to be protected against unauthorized access. In constrained
	devices, deployed in publicly accessible places, such protection can		devices, deployed in publicly accessible places, such protection can
	be difficult to achieve without specialized hardware (e.g. secure key		be difficult to achieve without specialized hardware (e.g. secure key
	storage memory).		storage memory).
	If credentials are lost or compromised, the operator of the affected		If credentials are lost or compromised, the operator of the affected
	devices needs to have procedures to invalidate any access these		devices needs to have procedures to invalidate any access these
	credentials give and to revoke tokens linked to such credentials.		credentials give and to revoke tokens linked to such credentials.
	The loss of a credential linked to a specific device MUST NOT lead to		The loss of a credential linked to a specific device MUST NOT lead to
	a compromise of other credentials not linked to that device,		a compromise of other credentials not linked to that device,
	therefore sharing secret keys between more than two parties is NOT		therefore secret keys used for authentication MUST NOT be shared
	RECOMMENDED.		between more than two parties.
	Operators of clients or RS should have procedures in place to replace		Operators of clients or RS SHOULD have procedures in place to replace
	credentials that are suspected to have been compromised or that have		credentials that are suspected to have been compromised or that have
	been lost.		been lost.
	Operators also need to have procedures for decommissioning devices,		Operators also SHOULD have procedures for decommissioning devices,
	that include securely erasing credentials and other security critical		that include securely erasing credentials and other security critical
	material in the devices being decommissioned.		material in the devices being decommissioned.
	6.4. Unprotected AS Request Creation Hints		6.4. Unprotected AS Request Creation Hints
	Initially, no secure channel exists to protect the communication		Initially, no secure channel exists to protect the communication
	between C and RS. Thus, C cannot determine if the AS Request		between C and RS. Thus, C cannot determine if the AS Request
	Creation Hints contained in an unprotected response from RS to an		Creation Hints contained in an unprotected response from RS to an
	unauthorized request (see Section 5.1.2) are authentic. It is		unauthorized request (see Section 5.1.2) are authentic. It is
	therefore advisable to provide C with a (possibly hard-coded) list of		therefore advisable to provide C with a (possibly hard-coded) list of
	skipping to change at page 45, line 38 ¶		skipping to change at page 45, line 38 ¶
	exchanged either a shared secret, or their public keys in order to		exchanged either a shared secret, or their public keys in order to
	negotiate a secure communication. Furthermore the RS MUST be able		negotiate a secure communication. Furthermore the RS MUST be able
	to determine whether an AS has the authority to issue access		to determine whether an AS has the authority to issue access
	tokens itself. This is usually configured out of band, but could		tokens itself. This is usually configured out of band, but could
	also be performed through an online lookup mechanism provided that		also be performed through an online lookup mechanism provided that
	it is also secured in the same way.		it is also secured in the same way.
	C-RS The initial communication between the client and the Resource		C-RS The initial communication between the client and the Resource
	Server can not be secured in general, since the RS is not in		Server can not be secured in general, since the RS is not in
	possession of on access token for that client, which would carry		possession of on access token for that client, which would carry
	the necessary parameters. Certain security mechanisms (e.g. DTLS		the necessary parameters. If both parties support DTLS without
	with server-side authentication via a certificate or a raw public		client authentication it is RECOMMEND to use this mechanism for
	key) can be possible and are RECOMMEND if supported by both		protecting the initial communication. After the client has
	parties. After the client has successfully transmitted the access		successfully transmitted the access token to the RS, a secure
	token to the RS, a secure communication protocol MUST be		communication protocol MUST be established between client and RS
	established between client and RS for the actual resource request.		for the actual resource request. This protocol MUST provide
	This protocol MUST provide confidentiality, integrity and replay		confidentiality, integrity and replay protection as well as a
	protection as well as a binding between requests and responses.		binding between requests and responses. This requires that the
	This requires that the client learned either the RS's public key		client learned either the RS's public key or received a symmetric
	or received a symmetric proof-of-possession key bound to the		proof-of-possession key bound to the access token from the AS.
	access token from the AS. The RS must have learned either the		The RS must have learned either the client's public key or a
	client's public key or a shared symmetric key from the claims in		shared symmetric key from the claims in the token or an
	the token or an introspection request. Since ACE does not provide		introspection request. Since ACE does not provide profile
	profile negotiation between C and RS, the client MUST have learned		negotiation between C and RS, the client MUST have learned what
	what profile the RS supports (e.g. from the AS or pre-configured)		profile the RS supports (e.g. from the AS or pre-configured) and
	and initiate the communication accordingly.		initiate the communication accordingly.
	6.6. Token Freshness and Expiration		6.6. Token Freshness and Expiration
	An RS that is offline faces the problem of clock drift. Since it		An RS that is offline faces the problem of clock drift. Since it
	cannot synchronize its clock with the AS, it may be tricked into		cannot synchronize its clock with the AS, it may be tricked into
	accepting old access tokens that are no longer valid or have been		accepting old access tokens that are no longer valid or have been
	compromised. In order to prevent this, an RS may use the nonce-based		compromised. In order to prevent this, an RS may use the nonce-based
	mechanism defined in Section 5.1.2 to ensure freshness of an Access		mechanism defined in Section 5.1.2 to ensure freshness of an Access
	Token subsequently presented to this RS.		Token subsequently presented to this RS.
	Another problem with clock drift is that evaluating the standard		Another problem with clock drift is that evaluating the standard
	token expiration claim "exp" can give unpredictable results.		token expiration claim "exp" can give unpredictable results.
			Acceptable ranges of clock drift are highly dependent on the concrete
			application. Important factors are how long access tokens are valid,
			and how critical timely expiration of access token is.
	The expiration mechanism implemented by the "exi" claim, based on the		The expiration mechanism implemented by the "exi" claim, based on the
	first time the RS sees the token was defined to provide a more		first time the RS sees the token was defined to provide a more
	predictable alternative. The "exi" approach has some drawbacks that		predictable alternative. The "exi" approach has some drawbacks that
	need to be considered:		need to be considered:
	A malicious client may hold back tokens with the "exi" claim in		A malicious client may hold back tokens with the "exi" claim in
	order to prolong their lifespan.		order to prolong their lifespan.
	If an RS loses state (e.g. due to an unscheduled reboot), it may		If an RS loses state (e.g. due to an unscheduled reboot), it may
	loose the current values of counters tracking the "exi" claims of		loose the current values of counters tracking the "exi" claims of
	skipping to change at page 47, line 12 ¶		skipping to change at page 47, line 19 ¶
	client and the RS in combination with a CoAP-DTLS profile for		client and the RS in combination with a CoAP-DTLS profile for
	interactions between the client and the AS. The security of a		interactions between the client and the AS. The security of a
	profile MUST NOT depend on the assumption that the profile is used		profile MUST NOT depend on the assumption that the profile is used
	for all the different types of interactions in this framework.		for all the different types of interactions in this framework.
	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. For example error responses for		leak information to an adversary, or may be manipulated by active
	requests to the Authorization Information endpoint can reveal		attackers to induce incorrect behavior. For example error responses
			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
	who has intercepted this token.		who has intercepted this token.
	As far as error messages are concerned, this framework is written		As far as error messages are concerned, this framework is written
	under the assumption that, in general, the benefits of detailed error		under the assumption that, in general, the benefits of detailed error
	messages outweigh the risk due to information leakage. For		messages outweigh the risk due to information leakage. For
	particular use cases, where this assessment does not apply, detailed		particular use cases, where this assessment does not apply, detailed
	error messages can be replaced by more generic ones.		error messages can be replaced by more generic ones.
	In some scenarios it may be possible to protect the communication		In some scenarios it may be possible to protect the communication
	skipping to change at page 47, line 38 ¶		skipping to change at page 47, line 46 ¶
	If the initial unauthorized resource request message (see		If the initial unauthorized resource request message (see
	Section 5.1.1) is used, the client MUST make sure that it is not		Section 5.1.1) is used, the client MUST make sure that it is not
	sending sensitive content in this request. While GET and DELETE		sending sensitive content in this request. While GET and DELETE
	requests only reveal the target URI of the resource, POST and PUT		requests only reveal the target URI of the resource, POST and PUT
	requests would reveal the whole payload of the intended operation.		requests would reveal the whole payload of the intended operation.
	Since the client is not authenticated at the point when it is		Since the client is not authenticated at the point when it is
	submitting an access token to the authz-info endpoint, attackers may		submitting an access token to the authz-info endpoint, attackers may
	be pretending to be a client and trying to trick an RS to use an		be pretending to be a client and trying to trick an RS to use an
	obsole profile that in turn specifies a vulnerable security mechanism		obsolete profile that in turn specifies a vulnerable security
	via the authz-info endpoint. Such an attack would require a valid		mechanism via the authz-info endpoint. Such an attack would require
	access token containing a "profile" claim requesting the use of said		a valid access token containing an "ace_profile" claim requesting the
	obsolete profile. Resource Owners should update the configuration of		use of said obsolete profile. Resource Owners should update the
	their RS's to prevent them from using such obsolete profiles.		configuration of their RS's to prevent them from using such obsolete
			profiles.
	6.9. Identifying audiences		6.9. Identifying audiences
	The audience claim as defined in [RFC7519] and the equivalent		The audience claim as defined in [RFC7519] and the equivalent
	"audience" parameter from [I-D.ietf-oauth-token-exchange] are		"audience" parameter from [I-D.ietf-oauth-token-exchange] are
	intentionally vague on how to match the audience value to a specific		intentionally vague on how to match the audience value to a specific
	RS. This is intended to allow application specific semantics to be		RS. This is intended to allow application specific semantics to be
	used. This section attempts to give some general guidance for the		used. This section attempts to give some general guidance for the
	use of audiences in constrained environments.		use of audiences in constrained environments.
	skipping to change at page 57, line 20 ¶		skipping to change at page 57, line 25 ¶
	Macintosh file type code(s): n/a		Macintosh file type code(s): n/a
	Person & email address to contact for further information:		Person & email address to contact for further information:
	<iesg@ietf.org>		<iesg@ietf.org>
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: None		Restrictions on usage: None
	Author: Ludwig Seitz <ludwig.setiz@ri.se>		Author: Ludwig Seitz <ludwig.setiz@combitech.se>
	Change controller: IESG		Change controller: IESG
	8.15. CoAP Content-Format Registry		8.15. CoAP Content-Format Registry
	This specification registers the following entry to the "CoAP		This specification registers the following entry to the "CoAP
	Content-Formats" registry:		Content-Formats" registry:
	Media Type: application/ace+cbor		Media Type: application/ace+cbor
	skipping to change at page 58, line 6 ¶		skipping to change at page 58, line 12 ¶
	Expert reviewers should take into consideration the following points:		Expert reviewers should take into consideration the following points:
	o Point squatting should be discouraged. Reviewers are encouraged		o Point squatting should be discouraged. Reviewers are encouraged
	to get sufficient information for registration requests to ensure		to get sufficient information for registration requests to ensure
	that the usage is not going to duplicate one that is already		that the usage is not going to duplicate one that is already
	registered, and that the point is likely to be used in		registered, and that the point is likely to be used in
	deployments. The zones tagged as private use are intended for		deployments. The zones tagged as private use are intended for
	testing purposes and closed environments; code points in other		testing purposes and closed environments; code points in other
	ranges should not be assigned for testing.		ranges should not be assigned for testing.
			o Specifications are needed for the first-come, first-serve range if
			they are expected to be used outside of closed environments in an
			interoperable way. When specifications are not provided, the
			description provided needs to have sufficient information to
			identify what the point is being used for.
	o Experts should take into account the expected usage of fields when		o Experts should take into account the expected usage of fields when
	approving point assignment. The fact that there is a range for		approving point assignment. The fact that there is a range for
	standards track documents does not mean that a standards track		standards track documents does not mean that a standards track
	document cannot have points assigned outside of that range. The		document cannot have points assigned outside of that range. The
	length of the encoded value should be weighed against how many		length of the encoded value should be weighed against how many
	code points of that length are left, the size of device it will be		code points of that length are left, the size of device it will be
	used on.		used on.
	o Since a high degree of overlap is expected between these		o Since a high degree of overlap is expected between these
	registries and the contents of the OAuth parameters		registries and the contents of the OAuth parameters
	[IANA.OAuthParameters] registries, experts should require new		[IANA.OAuthParameters] registries, experts should require new
	skipping to change at page 59, line 27 ¶		skipping to change at page 59, line 34 ¶
	in Constrained Environments (ACE)", draft-ietf-ace-oauth-		in Constrained Environments (ACE)", draft-ietf-ace-oauth-
	params-06 (work in progress), November 2019.		params-06 (work in progress), November 2019.
	[I-D.ietf-oauth-token-exchange]		[I-D.ietf-oauth-token-exchange]
	Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.		Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
	Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth-		Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth-
	token-exchange-19 (work in progress), July 2019.		token-exchange-19 (work in progress), July 2019.
	[IANA.CborWebTokenClaims]		[IANA.CborWebTokenClaims]
	IANA, "CBOR Web Token (CWT) Claims",		IANA, "CBOR Web Token (CWT) Claims",
	<https://www.iana.org/assignments/cwt/		<https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
	cwt.xhtml#claims-registry>.		registry>.
	[IANA.JsonWebTokenClaims]		[IANA.JsonWebTokenClaims]
	IANA, "JSON Web Token Claims",		IANA, "JSON Web Token Claims",
	<https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.		<https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.
	[IANA.OAuthAccessTokenTypes]		[IANA.OAuthAccessTokenTypes]
	IANA, "OAuth Access Token Types",		IANA, "OAuth Access Token Types",
	<https://www.iana.org/assignments/oauth-parameters/		<https://www.iana.org/assignments/oauth-parameters/oauth-
	oauth-parameters.xhtml#token-types>.		parameters.xhtml#token-types>.
	[IANA.OAuthExtensionsErrorRegistry]		[IANA.OAuthExtensionsErrorRegistry]
	IANA, "OAuth Extensions Error Registry",		IANA, "OAuth Extensions Error Registry",
	<https://www.iana.org/assignments/oauth-parameters/		<https://www.iana.org/assignments/oauth-parameters/oauth-
	oauth-parameters.xhtml#extensions-error>.		parameters.xhtml#extensions-error>.
	[IANA.OAuthParameters]		[IANA.OAuthParameters]
	IANA, "OAuth Parameters",		IANA, "OAuth Parameters",
	<https://www.iana.org/assignments/oauth-parameters/		<https://www.iana.org/assignments/oauth-parameters/oauth-
	oauth-parameters.xhtml#parameters>.		parameters.xhtml#parameters>.
	[IANA.TokenIntrospectionResponse]		[IANA.TokenIntrospectionResponse]
	IANA, "OAuth Token Introspection Response",		IANA, "OAuth Token Introspection Response",
	<https://www.iana.org/assignments/oauth-parameters/		<https://www.iana.org/assignments/oauth-parameters/oauth-
	oauth-parameters.xhtml#token-introspection-response>.		parameters.xhtml#token-introspection-response>.
	[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>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	skipping to change at page 61, line 34 ¶		skipping to change at page 61, line 43 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,		[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,		"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
	May 2018, <https://www.rfc-editor.org/info/rfc8392>.		May 2018, <https://www.rfc-editor.org/info/rfc8392>.
	10.2. Informative References		10.2. Informative References
	[BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1",		[BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1",
	Section 4.4, January 2019,		Section 4.4, January 2019,
	<https://www.bluetooth.com/specifications/		<https://www.bluetooth.com/specifications/bluetooth-core-
	bluetooth-core-specification/>.		specification/>.
	[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-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-24 (work		and Secure Transport", draft-ietf-quic-transport-24 (work
	in progress), November 2019.		in progress), November 2019.
	[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-34 (work in progress), November		1.3", draft-ietf-tls-dtls13-34 (work in progress),
	2019.		November 2019.
	[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
	Version 5.0", OASIS Standard, March 2019,		Version 5.0", OASIS Standard, March 2019,
	<https://docs.oasis-open.org/mqtt/mqtt/v5.0/		<https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-
	mqtt-v5.0.html>.		v5.0.html>.
	[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link		[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
	Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,		Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
	<https://www.rfc-editor.org/info/rfc6690>.		<https://www.rfc-editor.org/info/rfc6690>.
	[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0		[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
	Threat Model and Security Considerations", RFC 6819,		Threat Model and Security Considerations", RFC 6819,
	DOI 10.17487/RFC6819, January 2013,		DOI 10.17487/RFC6819, January 2013,
	<https://www.rfc-editor.org/info/rfc6819>.		<https://www.rfc-editor.org/info/rfc6819>.
	skipping to change at page 85, line 41 ¶		skipping to change at page 86, line 41 ¶
	o 5.3.2. Defined success and error responses from the RS when		o 5.3.2. Defined success and error responses from the RS when
	receiving an access token.		receiving an access token.
	o 5.6.:Added section giving guidance on how to handle token		o 5.6.:Added section giving guidance on how to handle token
	expiration in the absence of reliable time.		expiration in the absence of reliable time.
	o Appendix B Added list of roles and responsibilities for C, AS and		o Appendix B Added list of roles and responsibilities for C, AS and
	RS.		RS.
	Authors' Addresses		Authors' Addresses
	Ludwig Seitz		Ludwig Seitz
	RISE		Combitech
	Scheelevaegen 17		Djaeknegatan 31
	Lund 223 70		Malmoe 211 35
	Sweden		Sweden
	Email: ludwig.seitz@ri.se		Email: ludwig.seitz@combitech.se
	Goeran Selander		Goeran Selander
	Ericsson		Ericsson
	Faroegatan 6		Faroegatan 6
	Kista 164 80		Kista 164 80
	Sweden		Sweden
	Email: goran.selander@ericsson.com		Email: goran.selander@ericsson.com
	Erik Wahlstroem		Erik Wahlstroem
	Sweden		Sweden
End of changes. 34 change blocks.
	92 lines changed or deleted		103 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/