draft-ietf-ace-dtls-authorize-03.txt		draft-ietf-ace-dtls-authorize-04.txt
	ACE Working Group S. Gerdes		ACE Working Group S. Gerdes
	Internet-Draft O. Bergmann		Internet-Draft O. Bergmann
	Intended status: Standards Track C. Bormann		Intended status: Standards Track C. Bormann
	Expires: September 6, 2018 Universitaet Bremen TZI		Expires: March 10, 2019 Universitaet Bremen TZI
	G. Selander		G. Selander
	Ericsson		Ericsson
	L. Seitz		L. Seitz
	RISE SICS		RISE SICS
	March 05, 2018		September 06, 2018
	Datagram Transport Layer Security (DTLS) Profile for Authentication and		Datagram Transport Layer Security (DTLS) Profile for Authentication and
	Authorization for Constrained Environments (ACE)		Authorization for Constrained Environments (ACE)
	draft-ietf-ace-dtls-authorize-03		draft-ietf-ace-dtls-authorize-04
	Abstract		Abstract
	This specification defines a profile for delegating client		This specification defines a profile for delegating client
	authentication and authorization in a constrained environment by		authentication and authorization in a constrained environment by
	establishing a Datagram Transport Layer Security (DTLS) channel		establishing a Datagram Transport Layer Security (DTLS) channel
	between resource-constrained nodes. The protocol relies on DTLS for		between resource-constrained nodes. The protocol relies on DTLS for
	communication security between entities in a constrained network		communication security between entities in a constrained network
	using either raw public keys or pre-shared keys. A resource-		using either raw public keys or pre-shared keys. A resource-
	constrained node can use this protocol to delegate management of		constrained node can use this protocol to delegate management of
	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 September 6, 2018.		This Internet-Draft will expire on March 10, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3		2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Resource Access . . . . . . . . . . . . . . . . . . . . . 5		2.1. Resource Access . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Dynamic Update of Authorization Information . . . . . . . 7		2.2. Dynamic Update of Authorization Information . . . . . . . 7
	2.3. Token Expiration . . . . . . . . . . . . . . . . . . . . 8		2.3. Token Expiration . . . . . . . . . . . . . . . . . . . . 8
	3. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . . . 9		3. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . . . 9
	4. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . . . 10		4. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. DTLS Channel Setup Between C and RS . . . . . . . . . . . 12		4.1. DTLS Channel Setup Between C and RS . . . . . . . . . . . 12
	4.2. Updating Authorization Information . . . . . . . . . . . 14		4.2. Updating Authorization Information . . . . . . . . . . . 13
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Normative References . . . . . . . . . . . . . . . . . . 15		8.1. Normative References . . . . . . . . . . . . . . . . . . 15
	8.2. Informative References . . . . . . . . . . . . . . . . . 16		8.2. Informative References . . . . . . . . . . . . . . . . . 16
	8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17		8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	This specification defines a profile of the ACE framework		This specification defines a profile of the ACE framework
	[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource		[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	provide proof-of-possession for the key tied to the access token.		provide proof-of-possession for the key tied to the access token.
	Here the access token needs to be transferred to the resource server		Here the access token needs to be transferred to the resource server
	before the handshake is initiated, as described in section 5.8.1 of		before the handshake is initiated, as described in section 5.8.1 of
	draft-ietf-ace-oauth-authz [1].		draft-ietf-ace-oauth-authz [1].
	The DTLS PSK handshake [RFC4279] provides the proof-of-possession for		The DTLS PSK handshake [RFC4279] provides the proof-of-possession for
	the key tied to the access token. Furthermore the psk_identity		the key tied to the access token. Furthermore the psk_identity
	parameter in the DTLS PSK handshake is used to transfer the access		parameter in the DTLS PSK handshake is used to transfer the access
	token from the client to the resource server.		token from the client to the resource server.
	Note: While the scope of this draft is on client and resource server
	communicating using CoAP over DTLS, it is expected that it applies
	also to CoAP over TLS, possibly with minor modifications.
	However, that is out of scope for this version of the draft.
	1.1. Terminology		1.1. 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.
	Readers are expected to be familiar with the terms and concepts		Readers are expected to be familiar with the terms and concepts
	described in [I-D.ietf-ace-oauth-authz].		described in [I-D.ietf-ace-oauth-authz].
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	| --- Token Request ----------------------------> |		| --- Token Request ----------------------------> |
	| | |		| | |
	| <---------------------------- Access Token ----- |		| <---------------------------- Access Token ----- |
	| + RS Information |		| + RS Information |
	Figure 1: Retrieving an Access Token		Figure 1: Retrieving an Access Token
	To determine the AS in charge of a resource hosted at the RS, the		To determine the AS in charge of a resource hosted at the RS, the
	client C MAY send an initial Unauthorized Resource Request message to		client C MAY send an initial Unauthorized Resource Request message to
	the RS. The RS then denies the request and sends the address of its		the RS. The RS then denies the request and sends the address of its
	AS back to the client C.		AS back to the client C as specified in section 5.1.2 of draft-ietf-
			ace-oauth-authz [2].
	Once the client C knows the authorization server's address, it can		Once the client C knows the authorization server's address, it can
	send an Access Token request to the token endpoint at the AS as		send an Access Token request to the token endpoint at the AS as
	specified in [I-D.ietf-ace-oauth-authz]. As the Access Token request		specified in [I-D.ietf-ace-oauth-authz]. As the Access Token request
	as well as the response may contain confidential data, the		as well as the response may contain confidential data, the
	communication between the client and the authorization server MUST be		communication between the client and the authorization server MUST be
	confidentiality-protected and ensure authenticity. How the mutual		confidentiality-protected and ensure authenticity. How the mutual
	authentication between the client and the authorization server is		authentication between the client and the authorization server is
	achieved is out of scope for this document; the client may have been		achieved is out of scope for this document; the client may have been
	configured with a public key of the authorization server and have		configured with a public key of the authorization server and have
	been registered at the AS via the OAuth client registration mechanism		been registered at the AS via the OAuth client registration mechanism
	as outlined in section 5.3 of draft-ietf-ace-oauth-authz [2].		as outlined in section 5.3 of draft-ietf-ace-oauth-authz [3].
	If C wants to use the CoAP RawPublicKey mode as described in		If C wants to use the CoAP RawPublicKey mode as described in
	Section 9 of RFC 7252 [3] it MUST provide a key or key identifier		Section 9 of RFC 7252 [4] it MUST provide a key or key identifier
	within a "cnf" object in the token request. If the authorization		within a "cnf" object in the token request. If the authorization
	server AS decides that the request is to be authorized it generates		server AS decides that the request is to be authorized it generates
	an access token response for the client C containing a "profile"		an access token response for the client C containing a "profile"
	parameter with the value "coap_dtls" to indicate that this profile		parameter with the value "coap_dtls" to indicate that this profile
	MUST be used for communication between the client C and the resource		MUST be used for communication between the client C and the resource
	server. Is also adds a "cnf" parameter with additional data for the		server.
	establishment of a secure DTLS channel between the client and the
	resource server. The semantics of the 'cnf' parameter depend on the		For RPK mode, the authorization server also adds a "rs_cnf" parameter
	type of key used between the client and the resource server and		containing information about the public that is used by the resource
	control whether the client must use RPK mode or PSK mode to establish		server (see Section 3).
	a DTLS session with the resource server, see Section 3 and Section 4.
			For PSK mode, the authorization server adds a "cnf" parameter
			containing information about the shared secret that C can use to
			setup a DTLS session with the resource server (see Section 4).
	The Access Token returned by the authorization server then can be		The Access Token returned by the authorization server then can be
	used by the client to establish a new DTLS session with the resource		used by the client to establish a new DTLS session with the resource
	server. When the client intends to use asymmetric cryptography in		server. When the client intends to use asymmetric cryptography in
	the DTLS handshake with the resource server, the client MUST upload		the DTLS handshake with the resource server, the client MUST upload
	the Access Token to the authz-info resource on the resource server		the Access Token to the authz-info resource on the resource server
	before starting the DTLS handshake, as described in section 5.8.1 of		before starting the DTLS handshake, as described in section 5.8.1 of
	draft-ietf-ace-oauth-authz [4]. If only symmetric cryptography is		draft-ietf-ace-oauth-authz [5]. If only symmetric cryptography is
	used between the client and the resource server, the Access Token MAY		used between the client and the resource server, the Access Token MAY
	instead be transferred in the DTLS ClientKeyExchange message (see		instead be transferred in the DTLS ClientKeyExchange message (see
	Section 4.1).		Section 4.1).
	Figure 2 depicts the common protocol flow for the DTLS profile after		Figure 2 depicts the common protocol flow for the DTLS profile after
	the client C has retrieved the Access Token from the authorization		the client C has retrieved the Access Token from the authorization
	server AS.		server AS.
	C RS AS		C RS AS
	| [--- Access Token ------>] | |		| [--- Access Token ------>] | |
	skipping to change at page 6, line 7 ¶		skipping to change at page 6, line 13 ¶
	info resource hosted by the resource server.		info resource hosted by the resource server.
	On the resource server side, successful establishment of the DTLS		On the resource server side, successful establishment of the DTLS
	channel binds the client to the access token, functioning as a proof-		channel binds the client to the access token, functioning as a proof-
	of-possession associated key. Any request that the resource server		of-possession associated key. Any request that the resource server
	receives on this channel MUST be checked against these authorization		receives on this channel MUST be checked against these authorization
	rules that are associated with the identity of the client. Incoming		rules that are associated with the identity of the client. Incoming
	CoAP requests that are not authorized with respect to any Access		CoAP requests that are not authorized with respect to any Access
	Token that is associated with the client MUST be rejected by the		Token that is associated with the client MUST be rejected by the
	resource server with 4.01 response as described in Section 5.1.1 of		resource server with 4.01 response as described in Section 5.1.1 of
	draft-ietf-ace-oauth-authz [5].		draft-ietf-ace-oauth-authz [6].
	Note: The identity of the client is determined by the authentication		Note: The identity of the client is determined by the authentication
	process		process
	during the DTLS handshake. In the asymmetric case, the public key		during the DTLS handshake. In the asymmetric case, the public key
	will define the client's identity, while in the PSK case, the		will define the client's identity, while in the PSK case, the
	client's identity is defined by the session key generated by the		client's identity is defined by the shared secret generated by the
	authorization server for this communication.		authorization server for this communication.
	The resource server SHOULD treat an incoming CoAP request as		The resource server SHOULD treat an incoming CoAP request as
	authorized if the following holds:		authorized if the following holds:
	1. The message was received on a secure channel that has been		1. The message was received on a secure channel that has been
	established using the procedure defined in this document.		established using the procedure defined in this document.
	2. The authorization information tied to the sending peer is valid.		2. The authorization information tied to the sending peer is valid.
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 41 ¶
	4. The resource URI specified in the request is covered by the		4. The resource URI specified in the request is covered by the
	authorization information.		authorization information.
	5. The request method is an authorized action on the resource with		5. The request method is an authorized action on the resource with
	respect to the authorization information.		respect to the authorization information.
	Incoming CoAP requests received on a secure DTLS channel MUST be		Incoming CoAP requests received on a secure DTLS channel MUST be
	rejected according to [Section 5.1.1 of draft-ietf-ace-oauth-		rejected according to [Section 5.1.1 of draft-ietf-ace-oauth-
	authz](https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		authz](https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	10#section-5.1.1		13#section-5.1.1
	1. with response code 4.03 (Forbidden) when the resource URI		1. with response code 4.03 (Forbidden) when the resource URI
	specified in the request is not covered by the authorization		specified in the request is not covered by the authorization
	information, and		information, and
	2. with response code 4.05 (Method Not Allowed) when the resource		2. with response code 4.05 (Method Not Allowed) when the resource
	URI specified in the request covered by the authorization		URI specified in the request covered by the authorization
	information but not the requested action.		information but not the requested action.
	The client cannot always know a priori if an Authorized Resource		The client cannot always know a priori if an Authorized Resource
	Request will succeed. If the client repeatedly gets error responses		Request will succeed. If the client repeatedly gets error responses
	containing AS Information (cf. Section 5.1.1 of draft-ietf-ace-		containing AS Information (cf. Section 5.1.1 of draft-ietf-ace-
	oauth-authz [6] as response to its requests, it SHOULD request a new		oauth-authz [7] as response to its requests, it SHOULD request a new
	Access Token from the authorization server in order to continue		Access Token from the authorization server in order to continue
	communication with the resource server.		communication with the resource server.
	2.2. Dynamic Update of Authorization Information		2.2. Dynamic Update of Authorization Information
	The client can update the authorization information stored at the		The client can update the authorization information stored at the
	resource server at any time without changing an established DTLS		resource server at any time without changing an established DTLS
	session. To do so, the Client requests from the authorization server		session. To do so, the Client requests from the authorization server
	a new Access Token for the intended action on the respective resource		a new Access Token for the intended action on the respective resource
	and uploads this Access Token to the authz-info resource on the		and uploads this Access Token to the authz-info resource on the
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 28 ¶
	Figure 3 depicts the message flow where the client C requests a new		Figure 3 depicts the message flow where the client C requests a new
	Access Token after a security association between the client and the		Access Token after a security association between the client and the
	resource server RS has been established using this protocol. The		resource server RS has been established using this protocol. The
	token request MUST specify the key identifier of the existing DTLS		token request MUST specify the key identifier of the existing DTLS
	channel between the client and the resource server in the "kid"		channel between the client and the resource server in the "kid"
	parameter of the Client-to-AS request. The authorization server MUST		parameter of the Client-to-AS request. The authorization server MUST
	verify that the specified "kid" denotes a valid verifier for a proof-		verify that the specified "kid" denotes a valid verifier for a proof-
	of-possession ticket that has previously been issued to the		of-possession ticket that has previously been issued to the
	requesting client. Otherwise, the Client-to-AS request MUST be		requesting client. Otherwise, the Client-to-AS request MUST be
	declined with a the error code "unsupported_pop_key" as defined in		declined with a the error code "unsupported_pop_key" as defined in
	Section 5.6.3 of draft-ietf-ace-oauth-authz [7].		Section 5.6.3 of draft-ietf-ace-oauth-authz [8].
	When the authorization server issues a new access token to update		When the authorization server issues a new access token to update
	existing authorization information it MUST include the specified		existing authorization information it MUST include the specified
	"kid" parameter in this access token. A resource server MUST		"kid" parameter in this access token. A resource server MUST
	associate the updated authorization information with any existing		associate the updated authorization information with any existing
	DTLS session that is identified by this key identifier.		DTLS session that is identified by this key identifier.
	Note: By associating the access tokens with the identifier of an		Note: By associating the access tokens with the identifier of an
	existing DTLS session, the authorization information can be		existing DTLS session, the authorization information can be
	updated without changing the cryptographic keys for the DTLS		updated without changing the cryptographic keys for the DTLS
	skipping to change at page 8, line 33 ¶		skipping to change at page 8, line 33 ¶
	2.3. Token Expiration		2.3. Token Expiration
	DTLS sessions that have been established in accordance with this		DTLS sessions that have been established in accordance with this
	profile are always tied to a specific set of access tokens. As these		profile are always tied to a specific set of access tokens. As these
	tokens may become invalid at any time (either because the token has		tokens may become invalid at any time (either because the token has
	expired or the responsible authorization server has revoked the		expired or the responsible authorization server has revoked the
	token), the session may become useless at some point. A resource		token), the session may become useless at some point. A resource
	server therefore may decide to terminate existing DTLS sessions after		server therefore may decide to terminate existing DTLS sessions after
	the last valid access token for this session has been deleted.		the last valid access token for this session has been deleted.
	As specified in section 5.8.2 of draft-ietf-ace-oauth-authz [8], the		As specified in section 5.8.3 of draft-ietf-ace-oauth-authz [9], the
	resource server MUST notify the client with an error response with		resource server MUST notify the client with an error response with
	code 4.01 (Unauthorized) for any long running request before		code 4.01 (Unauthorized) for any long running request before
	terminating the session.		terminating the session.
	The resource server MAY also keep the session alive for some time and		The resource server MAY also keep the session alive for some time and
	respond to incoming requests with a 4.01 (Unauthorized) error message		respond to incoming requests with a 4.01 (Unauthorized) error message
	including AS Information to signal that the client needs to upload a		including AS Information to signal that the client needs to upload a
	new access token before it can continue using this DTLS session. The		new access token before it can continue using this DTLS session. The
	AS Information is created as specified in section 5.1.2 of draft-		AS Information is created as specified in section 5.1.2 of draft-
	ietf-ace-oauth-authz [9]. The resource server SHOULD add a "kid"		ietf-ace-oauth-authz [10]. The resource server SHOULD add a "kid"
	parameter to the AS Information denoting the identifier of the key		parameter to the AS Information denoting the identifier of the key
	that it uses internally for this DTLS session. The client then		that it uses internally for this DTLS session. The client then
	includes this "kid" parameter in a Client-to-AS request used to		includes this "kid" parameter in a Client-to-AS request used to
	retrieve a new access token to be used with this DTLS session. In		retrieve a new access token to be used with this DTLS session. In
	case the key identifier is already known by the client (e.g. because		case the key identifier is already known by the client (e.g. because
	it was included in the RS Information in an AS-to-Client response),		it was included in the RS Information in an AS-to-Client response),
	the "kid" parameter MAY be elided from the AS Information.		the "kid" parameter MAY be elided from the AS Information.
	Table 1 updates Figure 2 in section 5.1.2 of draft-ietf-ace-oauth-		Table 1 updates Figure 2 in section 5.1.2 of draft-ietf-ace-oauth-
	authz [10] with the new "kid" parameter in accordance with [RFC8152].		authz [11] with the new "kid" parameter in accordance with [RFC8152].
	+----------------+----------+-----------------+		+----------------+----------+-----------------+
	| Parameter name | CBOR Key | Major Type |		| Parameter name | CBOR Key | Major Type |
	+----------------+----------+-----------------+		+----------------+----------+-----------------+
	| kid | 4 | 2 (byte string) |		| kid | 4 | 2 (byte string) |
	+----------------+----------+-----------------+		+----------------+----------+-----------------+
	Table 1: Updated AS Information parameters		Table 1: Updated AS Information parameters
	3. RawPublicKey Mode		3. RawPublicKey Mode
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 15 ¶
	MUST send a "POST" request containing the new Access Token to the		MUST send a "POST" request containing the new Access Token to the
	authz-info resource hosted by the resource server. If this operation		authz-info resource hosted by the resource server. If this operation
	yields a positive response, the client SHOULD proceed to establish a		yields a positive response, the client SHOULD proceed to establish a
	new DTLS channel with the resource server. To use raw public key		new DTLS channel with the resource server. To use raw public key
	mode, the client MUST pass the same public key that was used for		mode, the client MUST pass the same public key that was used for
	constructing the Access Token with the SubjectPublicKeyInfo structure		constructing the Access Token with the SubjectPublicKeyInfo structure
	in the DTLS handshake as specified in [RFC7250].		in the DTLS handshake as specified in [RFC7250].
	An implementation that supports the RPK mode of this profile MUST at		An implementation that supports the RPK mode of this profile MUST at
	least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8		least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
	[RFC7251] with the ed25519 curve (cf. [RFC8032],		[RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]).
	[I-D.ietf-tls-rfc4492bis]).
	Note: According to [RFC7252], CoAP implementations MUST support the		Note: According to [RFC7252], CoAP implementations MUST support the
	ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251] and the		ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251] and the
	NIST P-256 curve. As discussed in [RFC7748], new ECC curves have		NIST P-256 curve. As discussed in [RFC7748], new ECC curves have
	been defined recently that are considered superior to the so-		been defined recently that are considered superior to the so-
	called NIST curves. The curve that is mandatory to implement in		called NIST curves. The curve that is mandatory to implement in
	this specification is said to be efficient and less dangerous		this specification is said to be efficient and less dangerous
	regarding implementation errors than the secp256r1 curve mandated		regarding implementation errors than the secp256r1 curve mandated
	in [RFC7252].		in [RFC7252].
	The Access Token is constructed by the authorization server such that		The Access Token is constructed by the authorization server such that
	the resource server can associate the Access Token with the Client's		the resource server can associate the Access Token with the Client's
	public key. If CBOR web tokens [I-D.ietf-ace-cbor-web-token] are		public key. If CBOR web tokens [RFC8392] are used as recommended in
	used as recommended in [I-D.ietf-ace-oauth-authz], the authorization		[I-D.ietf-ace-oauth-authz], the authorization server MUST include a
	server MUST include a "COSE_Key" object in the "cnf" claim of the		"COSE_Key" object in the "cnf" claim of the Access Token. This
	Access Token. This "COSE_Key" object MAY contain a reference to a		"COSE_Key" object MAY contain a reference to a key for the client
	key for the client that is already known by the resource server		that is already known by the resource server (e.g., from previous
	(e.g., from previous communication). If the authorization server has		communication). If the authorization server has no certain knowledge
	no certain knowledge that the Client's key is already known to the		that the Client's key is already known to the resource server, the
	resource server, the Client's public key MUST be included in the		Client's public key MUST be included in the Access Token's "cnf"
	Access Token's "cnf" parameter.		parameter.
	4. PreSharedKey Mode		4. PreSharedKey Mode
	To retrieve an access token for the resource that the client wants to		To retrieve an access token for the resource that the client wants to
	access, the client MAY include a "cnf" object carrying an identifier		access, the client MAY include a "cnf" object carrying an identifier
	for a symmetric key in its Access Token request to the authorization		for a symmetric key in its Access Token request to the authorization
	server. This identifier can be used by the authorization server to		server. This identifier can be used by the authorization server to
	determine the session key to construct the proof-of-possession token		determine the shared secret to construct the proof-of-possession
	and therefore MUST specify a symmetric key that was previously		token and therefore MUST specify a symmetric key that was previously
	generated by the authorization server as a session key for the		generated by the authorization server as a shared secret for the
	communication between the client and the resource server.		communication between the client and the resource server.
	Depending on the requested token type and algorithm in the Access		Depending on the requested token type and algorithm in the Access
	Token request, the authorization server adds RS Information to the		Token request, the authorization server adds RS Information to the
	response that provides the client with sufficient information to		response that provides the client with sufficient information to
	setup a DTLS channel with the resource server. For symmetric proof-		setup a DTLS channel with the resource server. For symmetric proof-
	of-possession keys (c.f. [I-D.ietf-ace-oauth-authz]), the client		of-possession keys (c.f. [I-D.ietf-ace-oauth-authz]), the client
	must ensure that the Access Token request is sent over a secure		must ensure that the Access Token request is sent over a secure
	channel that guarantees authentication, message integrity and		channel that guarantees authentication, message integrity and
	confidentiality.		confidentiality.
	When the authorization server authorizes the client it returns an AS-		When the authorization server authorizes the client it returns an AS-
	to-Client response with the profile parameter set to "coap_dtls" and		to-Client response with the profile parameter set to "coap_dtls" and
	a "cnf" parameter carrying a "COSE_Key" object that contains the		a "cnf" parameter carrying a "COSE_Key" object that contains the
	symmetric session key to be used between the client and the resource		symmetric key to be used between the client and the resource server
	server as illustrated in Figure 5.		as illustrated in Figure 5.
	2.01 Created		2.01 Created
	Content-Format: application/cbor		Content-Format: application/cbor
	Location-Path: /token/asdjbaskd		Location-Path: /token/asdjbaskd
	Max-Age: 86400
	{		{
	access_token: h'd08343a10...		access_token: h'd08343a10...
	(remainder of CWT omitted for brevity)		(remainder of CWT omitted for brevity)
	token_type: pop,		token_type: pop,
	alg: HS256,		alg: HS256,
	expires_in: 86400,		expires_in: 86400,
	profile: coap_dtls,		profile: coap_dtls,
	cnf: {		cnf: {
	COSE_Key: {		COSE_Key: {
	kty: symmetric,		kty: symmetric,
	k: h'73657373696f6e6b6579'		k: h'73657373696f6e6b6579'
	}		}
	}		}
	}		}
	Figure 5: Example Access Token response		Figure 5: Example Access Token response
	In this example, the authorization server returns a 2.01 response		In this example, the authorization server returns a 2.01 response
	containing a new Access Token. The information is transferred as a		containing a new Access Token. The information is transferred as a
	CBOR data structure as specified in [I-D.ietf-ace-oauth-authz]. The		CBOR data structure as specified in [I-D.ietf-ace-oauth-authz].
	Max-Age option tells the receiving Client how long this token will be
	valid.
	A response that declines any operation on the requested resource is		A response that declines any operation on the requested resource is
	constructed according to Section 5.2 of RFC 6749 [11], (cf.		constructed according to Section 5.2 of RFC 6749 [12], (cf.
	Section 5.7.3 of [I-D.ietf-ace-oauth-authz]).		Section 5.7.3 of [I-D.ietf-ace-oauth-authz]).
	4.00 Bad Request		4.00 Bad Request
	Content-Format: application/cbor		Content-Format: application/cbor
	{		{
	error: invalid_request		error: invalid_request
	}		}
	Figure 6: Example Access Token response with reject		Figure 6: Example Access Token response with reject
	skipping to change at page 12, line 24 ¶		skipping to change at page 12, line 16 ¶
	When a client receives an Access Token from an authorization server,		When a client receives an Access Token from an authorization server,
	it checks if the payload contains an "access_token" parameter and a		it checks if the payload contains an "access_token" parameter and a
	"cnf" parameter. With this information the client can initiate		"cnf" parameter. With this information the client can initiate
	establishment of a new DTLS channel with a resource server. To use		establishment of a new DTLS channel with a resource server. To use
	DTLS with pre-shared keys, the client follows the PSK key exchange		DTLS with pre-shared keys, the client follows the PSK key exchange
	algorithm specified in Section 2 of [RFC4279] using the key conveyed		algorithm specified in Section 2 of [RFC4279] using the key conveyed
	in the "cnf" parameter of the AS response as PSK when constructing		in the "cnf" parameter of the AS response as PSK when constructing
	the premaster secret.		the premaster secret.
	In PreSharedKey mode, the knowledge of the session key by the client		In PreSharedKey mode, the knowledge of the shared secret by the
	and the resource server is used for mutual authentication between		client and the resource server is used for mutual authentication
	both peers. Therefore, the resource server must be able to determine		between both peers. Therefore, the resource server must be able to
	the session key from the Access Token. Following the general ACE		determine the shared secret from the Access Token. Following the
	authorization framework, the client can upload the Access Token to		general ACE authorization framework, the client can upload the Access
	the resource server's authz-info resource before starting the DTLS		Token to the resource server's authz-info resource before starting
	handshake. Alternatively, the client MAY provide the most recent		the DTLS handshake. Alternatively, the client MAY provide the most
	Access Token in the "psk_identity" field of the ClientKeyExchange		recent Access Token in the "psk_identity" field of the
	message. To do so, the client MUST treat the contents of the		ClientKeyExchange message. To do so, the client MUST treat the
	"access_token" field from the AS-to-Client response as opaque data		contents of the "access_token" field from the AS-to-Client response
	and not perform any re-coding.		as opaque data and not perform any re-coding.
	Note: As stated in section 4.2 of [RFC7925], the PSK identity should		Note: As stated in section 4.2 of [RFC7925], the PSK identity should
	be treated as binary data in the Internet of Things space and not		be treated as binary data in the Internet of Things space and not
	assumed to have a human-readable form of any sort.		assumed to have a human-readable form of any sort.
	If a resource server receives a ClientKeyExchange message that		If a resource server receives a ClientKeyExchange message that
	contains a "psk_identity" with a length greater zero, it uses the		contains a "psk_identity" with a length greater zero, it uses the
	contents as index for its key store (i.e., treat the contents as key		contents as index for its key store (i.e., treat the contents as key
	identifier). The resource server MUST check if it has one or more		identifier). The resource server MUST check if it has one or more
	Access Tokens that are associated with the specified key. If no		Access Tokens that are associated with the specified key. If no
	skipping to change at page 13, line 21 ¶		skipping to change at page 13, line 13 ¶
	SHOULD NOT send a ServerKeyExchange message.		SHOULD NOT send a ServerKeyExchange message.
	Note2: According to [RFC7252], CoAP implementations MUST support the		Note2: According to [RFC7252], CoAP implementations MUST support the
	ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is		ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is
	therefore expected to offer at least this ciphersuite to the		therefore expected to offer at least this ciphersuite to the
	resource server.		resource server.
	This specification assumes that the Access Token is a PoP token as		This specification assumes that the Access Token is a PoP token as
	described in [I-D.ietf-ace-oauth-authz] unless specifically stated		described in [I-D.ietf-ace-oauth-authz] unless specifically stated
	otherwise. Therefore, the Access Token is bound to a symmetric PoP		otherwise. Therefore, the Access Token is bound to a symmetric PoP
	key that is used as session key between the client and the resource		key that is used as shared secret between the client and the resource
	server.		server.
	While the client can retrieve the session key from the contents of		While the client can retrieve the shared secret from the contents of
	the "cnf" parameter in the AS-to-Client response, the resource server		the "cnf" parameter in the AS-to-Client response, the resource server
	uses the information contained in the "cnf" claim of the Access Token		uses the information contained in the "cnf" claim of the Access Token
	to determine the actual session key when no explicit "kid" was		to determine the actual secret when no explicit "kid" was provided in
	provided in the "psk_identity" field. Usually, this is done by		the "psk_identity" field. Usually, this is done by including a
	including a "COSE_Key" object carrying either a key that has been		"COSE_Key" object carrying either a key that has been encrypted with
	encrypted with a shared secret between the authorization server and		a shared secret between the authorization server and the resource
	the resource server, or a key identifier that can be used by the		server, or a key identifier that can be used by the resource server
	resource server to lookup the session key.		to lookup the shared secret.
	Instead of the "COSE_Key" object, the authorization server MAY		Instead of the "COSE_Key" object, the authorization server MAY
	include a "COSE_Encrypt" structure to enable the resource server to		include a "COSE_Encrypt" structure to enable the resource server to
	calculate the session key from the Access Token. The "COSE_Encrypt"		calculate the shared key from the Access Token. The "COSE_Encrypt"
	structure MUST use the _Direct Key with KDF_ method as described in		structure MUST use the _Direct Key with KDF_ method as described in
	Section 12.1.2 of RFC 8152 [12]. The authorization server MUST		Section 12.1.2 of RFC 8152 [13]. The authorization server MUST
	include a Context information structure carrying a PartyU "nonce"		include a Context information structure carrying a PartyU "nonce"
	parameter carrying the nonce that has been used by the authorization		parameter carrying the nonce that has been used by the authorization
	server to construct the session key.		server to construct the shared key.
	This specification mandates that at least the key derivation		This specification mandates that at least the key derivation
	algorithm "HKDF SHA-256" as defined in [RFC8152] MUST be supported.		algorithm "HKDF SHA-256" as defined in [RFC8152] MUST be supported.
	This key derivation function is the default when no "alg" field is		This key derivation function is the default when no "alg" field is
	included in the "COSE_Encrypt" structure for the resource server.		included in the "COSE_Encrypt" structure for the resource server.
	4.2. Updating Authorization Information		4.2. Updating Authorization Information
	Usually, the authorization information that the resource server keeps		Usually, the authorization information that the resource server keeps
	for a client is updated by uploading a new Access Token as described		for a client is updated by uploading a new Access Token as described
	in Section 2.2.		in Section 2.2.
	If the security association with the resource server still exists and		The Client MAY also perform a new DTLS handshake according to
	the resource server has indicated support for session renegotiation		Section 4.1 that replaces the existing DTLS session. After
	according to [RFC5746], the new Access Token MAY be used to		successful completion of the DTLS handshake the resource server
	renegotiate the existing DTLS session. In this case, the Access
	Token is used as "psk_identity" as defined in Section 4.1. The
	Client MAY also perform a new DTLS handshake according to Section 4.1
	that replaces the existing DTLS session.
	After successful completion of the DTLS handshake the resource server
	updates the existing authorization information for the client		updates the existing authorization information for the client
	according to the new Access Token.		according to the new Access Token.
	5. Security Considerations		5. Security Considerations
	This document specifies a profile for the Authentication and		This document specifies a profile for the Authentication and
	Authorization for Constrained Environments (ACE) framework		Authorization for Constrained Environments (ACE) framework
	[I-D.ietf-ace-oauth-authz]. As it follows this framework's general		[I-D.ietf-ace-oauth-authz]. As it follows this framework's general
	approach, the general security and privacy considerations from		approach, the general security and privacy considerations from
	section 6 and section 7 also apply to this profile.		section 6 and section 7 also apply to this profile.
	skipping to change at page 15, line 38 ¶		skipping to change at page 15, line 20 ¶
	Reference: [RFC-XXXX]		Reference: [RFC-XXXX]
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-ace-oauth-authz]		[I-D.ietf-ace-oauth-authz]
	Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and		Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
	H. Tschofenig, "Authentication and Authorization for		H. Tschofenig, "Authentication and Authorization for
	Constrained Environments (ACE)", draft-ietf-ace-oauth-		Constrained Environments (ACE) using the OAuth 2.0
	authz-10 (work in progress), February 2018.		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-13
			(work in progress), July 2018.
	[I-D.tiloca-tls-dos-handshake]		[I-D.tiloca-tls-dos-handshake]
	Tiloca, M., Seitz, L., Hoeve, M., and O. Bergmann,		Tiloca, M., Seitz, L., Hoeve, M., and O. Bergmann,
	"Extension for protecting (D)TLS handshakes against Denial		"Extension for protecting (D)TLS handshakes against Denial
	of Service", draft-tiloca-tls-dos-handshake-01 (work in		of Service", draft-tiloca-tls-dos-handshake-02 (work in
	progress), October 2017.		progress), March 2018.
	[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>.
	[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key		[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
	Ciphersuites for Transport Layer Security (TLS)",		Ciphersuites for Transport Layer Security (TLS)",
	RFC 4279, DOI 10.17487/RFC4279, December 2005,		RFC 4279, DOI 10.17487/RFC4279, December 2005,
	<https://www.rfc-editor.org/info/rfc4279>.		<https://www.rfc-editor.org/info/rfc4279>.
	skipping to change at page 16, line 40 ¶		skipping to change at page 16, line 26 ¶
	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",		[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,		RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-ace-cbor-web-token]
	Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-12
	(work in progress), February 2018.
	[I-D.ietf-tls-rfc4492bis]
	Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
	Curve Cryptography (ECC) Cipher Suites for Transport Layer
	Security (TLS) Versions 1.2 and Earlier", draft-ietf-tls-
	rfc4492bis-17 (work in progress), May 2017.
	[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for		[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
	Transport Layer Security (TLS)", RFC 6655,		Transport Layer Security (TLS)", RFC 6655,
	DOI 10.17487/RFC6655, July 2012,		DOI 10.17487/RFC6655, July 2012,
	<https://www.rfc-editor.org/info/rfc6655>.		<https://www.rfc-editor.org/info/rfc6655>.
	[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,		[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
	Weiler, S., and T. Kivinen, "Using Raw Public Keys in		Weiler, S., and T. Kivinen, "Using Raw Public Keys in
	Transport Layer Security (TLS) and Datagram Transport		Transport Layer Security (TLS) and Datagram Transport
	Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,		Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
	June 2014, <https://www.rfc-editor.org/info/rfc7250>.		June 2014, <https://www.rfc-editor.org/info/rfc7250>.
	skipping to change at page 17, line 30 ¶		skipping to change at page 17, line 5 ¶
	[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves		[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
	for Security", RFC 7748, DOI 10.17487/RFC7748, January		for Security", RFC 7748, DOI 10.17487/RFC7748, January
	2016, <https://www.rfc-editor.org/info/rfc7748>.		2016, <https://www.rfc-editor.org/info/rfc7748>.
	[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital		[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
	Signature Algorithm (EdDSA)", RFC 8032,		Signature Algorithm (EdDSA)", RFC 8032,
	DOI 10.17487/RFC8032, January 2017,		DOI 10.17487/RFC8032, January 2017,
	<https://www.rfc-editor.org/info/rfc8032>.		<https://www.rfc-editor.org/info/rfc8032>.
			[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
			"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
			May 2018, <https://www.rfc-editor.org/info/rfc8392>.
			[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
			Curve Cryptography (ECC) Cipher Suites for Transport Layer
			Security (TLS) Versions 1.2 and Earlier", RFC 8422,
			DOI 10.17487/RFC8422, August 2018,
			<https://www.rfc-editor.org/info/rfc8422>.
	8.3. URIs		8.3. URIs
	[1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	10#section-5.8.1		13#section-5.8.1
	[2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	10#section-5.3		13#section-5.1.2
	[3] https://tools.ietf.org/html/rfc7252#section-9		[3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
			13#section-5.3
	[4] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[4] https://tools.ietf.org/html/rfc7252#section-9
	10#section-5.8.1
	[5] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[5] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	10#section-5.1.1		13#section-5.8.1
	[6] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[6] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	10#section-5.1.1		13#section-5.1.1
	[7] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[7] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	10#section-5.6.3		13#section-5.1.1
	[8] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[8] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	10#section-5.8.2		13#section-5.6.3
	[9] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[9] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	10#section-5.1.2		13#section-5.8.3
	[10] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[10] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	10#section-5.1.2		13#section-5.1.2
	[11] https://tools.ietf.org/html/rfc6749#section-5.2		[11] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
			13#section-5.1.2
	[12] https://tools.ietf.org/html/rfc8152#section-12.1.2		[12] https://tools.ietf.org/html/rfc6749#section-5.2
			[13] https://tools.ietf.org/html/rfc8152#section-12.1.2
	Authors' Addresses		Authors' Addresses
	Stefanie Gerdes		Stefanie Gerdes
	Universitaet Bremen TZI		Universitaet Bremen TZI
	Postfach 330440		Postfach 330440
	Bremen D-28359		Bremen D-28359
	Germany		Germany
	Phone: +49-421-218-63906		Phone: +49-421-218-63906
End of changes. 51 change blocks.
	110 lines changed or deleted		101 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/