draft-ietf-ace-dtls-authorize-02.txt		draft-ietf-ace-dtls-authorize-03.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: May 3, 2018 Universitaet Bremen TZI		Expires: September 6, 2018 Universitaet Bremen TZI
	G. Selander		G. Selander
	Ericsson		Ericsson
	L. Seitz		L. Seitz
	RISE SICS		RISE SICS
	October 30, 2017		March 05, 2018
	Datagram Transport Layer Security (DTLS) Profiles 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-02		draft-ietf-ace-dtls-authorize-03
	Abstract		Abstract
	This specification defines two profiles 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
	authorization information to a trusted host with less severe		authorization information to a trusted host with less severe
	limitations regarding processing power and memory.		limitations regarding processing power and memory.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://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 3, 2018.		This Internet-Draft will expire on September 6, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	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 . . . . . . . 6		2.2. Dynamic Update of Authorization Information . . . . . . . 7
	2.3. Token Expiration . . . . . . . . . . . . . . . . . . . . 7		2.3. Token Expiration . . . . . . . . . . . . . . . . . . . . 8
	3. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . . . 8		3. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . . . 9
	4. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . . . 10		4. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. DTLS Channel Setup Between C and RS . . . . . . . . . . . 11		4.1. DTLS Channel Setup Between C and RS . . . . . . . . . . . 12
	4.2. Updating Authorization Information . . . . . . . . . . . 13		4.2. Updating Authorization Information . . . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . 15
	8.2. Informative References . . . . . . . . . . . . . . . . . 15		8.2. Informative References . . . . . . . . . . . . . . . . . 16
	8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		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
	server use CoAP [RFC7252] over DTLS [RFC6347] to communicate. The		server use CoAP [RFC7252] over DTLS [RFC6347] to communicate. The
	client uses an access token, bound to a key (the proof-of-possession		client uses an access token, bound to a key (the proof-of-possession
	key) to authorize its access to protected resources hosted by the		key) to authorize its access to protected resources hosted by the
	resource server. DTLS provides communication security, proof of		resource server. DTLS provides communication security, proof of
	possession, and server authentication. Optionally the client and the		possession, and server authentication. Optionally the client and the
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	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.
	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]. If C wants to use the CoAP		specified in [I-D.ietf-ace-oauth-authz]. As the Access Token request
	RawPublicKey mode as described in Section 9 of RFC 7252 [2] it MUST		as well as the response may contain confidential data, the
	provide a key or key identifier within a "cnf" object in the token		communication between the client and the authorization server MUST be
	request. If the authorization server AS decides that the request is		confidentiality-protected and ensure authenticity. How the mutual
	to be authorized it generates an access token response for the client		authentication between the client and the authorization server is
	C containing a "profile" parameter with the value "coap_dtls" to		achieved is out of scope for this document; the client may have been
	indicate that this profile MUST be used for communication between the		configured with a public key of the authorization server and have
	client C and the resource server. Is also adds a "cnf" parameter		been registered at the AS via the OAuth client registration mechanism
	with additional data for the establishment of a secure DTLS channel		as outlined in section 5.3 of draft-ietf-ace-oauth-authz [2].
	between the client and the resource server. The semantics of the
	'cnf' parameter depend on the type of key used between the client and		If C wants to use the CoAP RawPublicKey mode as described in
	the resource server, see Section 3 and Section 4.		Section 9 of RFC 7252 [3] it MUST provide a key or key identifier
			within a "cnf" object in the token request. If the authorization
			server AS decides that the request is to be authorized it generates
			an access token response for the client C containing a "profile"
			parameter with the value "coap_dtls" to indicate that this profile
			MUST be used for communication between the client C and the resource
			server. Is also adds a "cnf" parameter with additional data for the
			establishment of a secure DTLS channel between the client and the
			resource server. The semantics of the 'cnf' parameter depend on the
			type of key used between the client and the resource server and
			control whether the client must use RPK mode or PSK mode to establish
			a DTLS session with the resource server, see Section 3 and 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 [3]. If only symmetric cryptography is		draft-ietf-ace-oauth-authz [4]. 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 5, line 44 ¶		skipping to change at page 6, line 7 ¶
	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 [4].		draft-ietf-ace-oauth-authz [5].
	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 session key 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:
	skipping to change at page 6, line 24 ¶		skipping to change at page 6, line 35 ¶
	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-
	08#section-5.1.1		10#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 [5] as response to its requests, it SHOULD request a new		oauth-authz [6] 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 11 ¶		skipping to change at page 7, line 24 ¶
	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 [6].		Section 5.6.3 of draft-ietf-ace-oauth-authz [7].
	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 7 ¶		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 [7], the		As specified in section 5.8.2 of draft-ietf-ace-oauth-authz [8], 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 [8]. The resource server SHOULD add a "kid"		ietf-ace-oauth-authz [9]. 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 [9] with the new "kid" parameter in accordance with [RFC8152].		authz [10] 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
	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 requests an Access Token from the authorization		access, the client requests an Access Token from the authorization
	server. The client MUST add a "cnf" object carrying either its raw		server. The client MUST add a "cnf" object carrying either its raw
	public key or a unique identifier for a public key that it has		public key or a unique identifier for a public key that it has
	previously made known to the authorization server.		previously made known to the authorization server. To prove that the
			client is in possession of this key, it MUST use the same public key
			as in certificate message that is used to establish the DTLS session
			with the authorization server.
	An example Access Token request from the client to the resource		An example Access Token request from the client to the resource
	server is depicted in Figure 4.		server is depicted in Figure 4.
	POST coaps://as.example.com/token		POST coaps://as.example.com/token
	Content-Format: application/cbor		Content-Format: application/cbor
	{		{
	grant_type: client_credentials,		grant_type: client_credentials,
	aud: "tempSensor4711",		aud: "tempSensor4711",
	cnf: {		cnf: {
	skipping to change at page 9, line 37 ¶		skipping to change at page 10, line 13 ¶
	Access Token and a "cnf" object in the AS-to-Client response. Before		Access Token and a "cnf" object in the AS-to-Client response. Before
	the client initiates the DTLS handshake with the resource server, it		the client initiates the DTLS handshake with the resource server, it
	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
			least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
			[RFC7251] with the ed25519 curve (cf. [RFC8032],
			[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. the client is therefore expected to offer at		NIST P-256 curve. As discussed in [RFC7748], new ECC curves have
	least this ciphersuite to the resource server.		been defined recently that are considered superior to the so-
			called NIST curves. The curve that is mandatory to implement in
			this specification is said to be efficient and less dangerous
			regarding implementation errors than the secp256r1 curve mandated
			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 [I-D.ietf-ace-cbor-web-token] are
	used as recommended in [I-D.ietf-ace-oauth-authz], the authorization		used as recommended in [I-D.ietf-ace-oauth-authz], the authorization
	server MUST include a "COSE_Key" object in the "cnf" claim of the		server MUST include a "COSE_Key" object in the "cnf" claim of the
	Access Token. This "COSE_Key" object MAY contain a reference to a		Access Token. This "COSE_Key" object MAY contain a reference to a
	key for the client that is already known by the resource server		key for the client that is already known by the resource server
	(e.g., from previous communication). If the authorization server has		(e.g., from previous communication). If the authorization server has
	no certain knowledge that the Client's key is already known to the		no certain knowledge that the Client's key is already known to the
	skipping to change at page 10, line 36 ¶		skipping to change at page 11, line 22 ¶
	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 session key to be used between the client and the resource
	server as illustrated in Figure 5.		server 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		Max-Age: 86400
	{		{
	access_token: b64'SlAV32hkKG ...		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'
	}		}
	}		}
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 45 ¶
	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]. The
	Max-Age option tells the receiving Client how long this token will be		Max-Age option tells the receiving Client how long this token will be
	valid.		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 [10], (cf.		constructed according to Section 5.2 of RFC 6749 [11], (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 11, line 41 ¶		skipping to change at page 12, line 31 ¶
	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 session key by the client
	and the resource server is used for mutual authentication between		and the resource server is used for mutual authentication between
	both peers. Therefore, the resource server must be able to determine		both peers. Therefore, the resource server must be able to determine
	the session key from the Access Token. Following the general ACE		the session key from the Access Token. Following the general ACE
	authorization framework, the client can upload the Access Token to		authorization framework, the client can upload the Access Token to
	the resource server's authz-info resource before starting the DTLS		the resource server's authz-info resource before starting the DTLS
	handshake. Alternatively, the client MAY provide the most recent		handshake. Alternatively, the client MAY provide the most recent
	base64-encoded Access Token in the "psk_identity" field of the		Access Token in the "psk_identity" field of the ClientKeyExchange
	ClientKeyExchange message.		message. To do so, the client MUST treat the contents of the
			"access_token" field from the AS-to-Client response as opaque data
			and not perform any re-coding.
			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
			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 MUST		contains a "psk_identity" with a length greater zero, it uses the
	base64-decode its contents and use the resulting byte sequence as		contents as index for its key store (i.e., treat the contents as key
	index for its key store (i.e., treat the contents as key identifier).		identifier). The resource server MUST check if it has one or more
	The resource server MUST check if it has one or more Access Tokens		Access Tokens that are associated with the specified key. If no
	that are associated with the specified key. If no valid Access Token		valid Access Token is available for this key, the DTLS session setup
	is available for this key, the DTLS session setup is terminated with		is terminated with an "illegal_parameter" DTLS alert message.
	an "illegal_parameter" DTLS alert message.
	If no key with a matching identifier is found the resource server the		If no key with a matching identifier is found the resource server the
	resource server MAY process the decoded contents of the		resource server MAY process the decoded contents of the
	"psk_identity" field as access token that is stored with the		"psk_identity" field as access token that is stored with the
	authorization information endpoint before continuing the DTLS		authorization information endpoint before continuing the DTLS
	handshake. If the decoded contents of the "psk_identity" do not		handshake. If the decoded contents of the "psk_identity" do not
	yield a valid access token for the requesting client, the DTLS		yield a valid access token for the requesting client, the DTLS
	session setup is terminated with an "illegal_parameter" DTLS alert		session setup is terminated with an "illegal_parameter" DTLS alert
	message.		message.
	skipping to change at page 12, line 44 ¶		skipping to change at page 13, line 38 ¶
	provided in the "psk_identity" field. Usually, this is done by		provided in the "psk_identity" field. Usually, this is done by
	including a "COSE_Key" object carrying either a key that has been		including a "COSE_Key" object carrying either a key that has been
	encrypted with a shared secret between the authorization server and		encrypted with a shared secret between the authorization server and
	the resource server, or a key identifier that can be used by the		the resource server, or a key identifier that can be used by the
	resource server to lookup the session key.		resource server to lookup the session key.
	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 session 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 [11]. The authorization server MUST		Section 12.1.2 of RFC 8152 [12]. 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 session 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
	skipping to change at page 14, line 29 ¶		skipping to change at page 15, line 29 ¶
	Profile Description: Profile for delegating client authentication and		Profile Description: Profile for delegating client authentication and
	authorization in a constrained environment by establishing a Datagram		authorization in a constrained environment by establishing a Datagram
	Transport Layer Security (DTLS) channel between resource-constrained		Transport Layer Security (DTLS) channel between resource-constrained
	nodes.		nodes.
	Profile ID: 1		Profile ID: 1
	Change Controller: IESG		Change Controller: IESG
	Specification Document(s): [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)", draft-ietf-ace-oauth-
	authz-08 (work in progress), October 2017.		authz-10 (work in progress), February 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-01 (work in
	progress), October 2017.		progress), October 2017.
	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	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>.
	[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,		[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
	"Transport Layer Security (TLS) Renegotiation Indication		"Transport Layer Security (TLS) Renegotiation Indication
	Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,		Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
	<https://www.rfc-editor.org/info/rfc5746>.		<https://www.rfc-editor.org/info/rfc5746>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014, <https://www.rfc-		DOI 10.17487/RFC7252, June 2014,
	editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
			[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
			Security (TLS) / Datagram Transport Layer Security (DTLS)
			Profiles for the Internet of Things", RFC 7925,
			DOI 10.17487/RFC7925, July 2016,
			<https://www.rfc-editor.org/info/rfc7925>.
	[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]		[I-D.ietf-ace-cbor-web-token]
	Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,		Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-09		"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-12
	(work in progress), October 2017.		(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, <https://www.rfc-		DOI 10.17487/RFC6655, July 2012,
	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>.
	[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-		[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
	CCM Elliptic Curve Cryptography (ECC) Cipher Suites for		CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
	TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,		TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
	<https://www.rfc-editor.org/info/rfc7251>.		<https://www.rfc-editor.org/info/rfc7251>.
			[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
			for Security", RFC 7748, DOI 10.17487/RFC7748, January
			2016, <https://www.rfc-editor.org/info/rfc7748>.
			[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
			Signature Algorithm (EdDSA)", RFC 8032,
			DOI 10.17487/RFC8032, January 2017,
			<https://www.rfc-editor.org/info/rfc8032>.
	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-
	08#section-5.8.1		10#section-5.8.1
	[2] https://tools.ietf.org/html/rfc7252#section-9		[2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
			10#section-5.3
	[3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[3] https://tools.ietf.org/html/rfc7252#section-9
	08#section-5.8.1
	[4] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[4] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	08#section-5.5.1		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-
	08#section-5.1.1		10#section-5.1.1
	[6] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[6] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	08#section-5.6.3		10#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-
	08#section-5.8.2		10#section-5.6.3
	[8] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[8] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	08#section-5.1.2		10#section-5.8.2
	[9] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-		[9] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	08#section-5.1.2		10#section-5.1.2
	[10] https://tools.ietf.org/html/rfc6749#section-5.2		[10] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
			10#section-5.1.2
	[11] https://tools.ietf.org/html/rfc8152#section-12.1.2		[11] https://tools.ietf.org/html/rfc6749#section-5.2
			[12] 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. 46 change blocks.
	80 lines changed or deleted		132 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/