draft-ietf-ace-oscore-profile-00.txt		draft-ietf-ace-oscore-profile-01.txt
	ACE Working Group L. Seitz		ACE Working Group L. Seitz
	Internet-Draft RISE SICS AB		Internet-Draft RISE SICS AB
	Intended status: Standards Track F. Palombini		Intended status: Standards Track F. Palombini
	Expires: June 15, 2018 Ericsson AB		Expires: September 6, 2018 Ericsson AB
	M. Gunnarsson		M. Gunnarsson
	RISE SICS AB		RISE SICS AB
	December 12, 2017		G. Selander
			Ericsson AB
			March 5, 2018
	OSCORE profile of the Authentication and Authorization for Constrained		OSCORE profile of the Authentication and Authorization for Constrained
	Environments Framework		Environments Framework
	draft-ietf-ace-oscore-profile-00		draft-ietf-ace-oscore-profile-01
	Abstract		Abstract
	This memo specifies a profile for the Authentication and		This memo specifies a profile for the Authentication and
	Authorization for Constrained Environments (ACE) framework. It		Authorization for Constrained Environments (ACE) framework. It
	utilizes Object Security for Constrained RESTful Environments		utilizes Object Security for Constrained RESTful Environments
	(OSCORE) to provide communication security, server authentication,		(OSCORE) to provide communication security, server authentication,
	and proof-of-possession for a key owned by the client and bound to an		and proof-of-possession for a key owned by the client and bound to an
	OAuth 2.0 access token.		OAuth 2.0 access token.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 June 15, 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(http://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. Client to Resource Server . . . . . . . . . . . . . . . . . . 3		2. Client to Resource Server . . . . . . . . . . . . . . . . . . 3
	2.1. Signaling the use of OSCORE . . . . . . . . . . . . . . . 3		2.1. Signaling the use of OSCORE . . . . . . . . . . . . . . . 3
	2.2. Key establishment for OSCORE . . . . . . . . . . . . . . 4		2.2. Key establishment for OSCORE . . . . . . . . . . . . . . 4
	3. Client to Authorization Server . . . . . . . . . . . . . . . 6		3. Client to Authorization Server . . . . . . . . . . . . . . . 7
	4. Resource Server to Authorization Server . . . . . . . . . . . 7		4. Resource Server to Authorization Server . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 9		Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 10
	Appendix B. Using the pop-key with EDHOC (EDHOC+OSCORE) . . . . 10		Appendix B. Using the pop-key with EDHOC (EDHOC+OSCORE) . . . . 11
	B.1. Using Asymmetric Keys . . . . . . . . . . . . . . . . . . 10		B.1. Using Asymmetric Keys . . . . . . . . . . . . . . . . . . 12
	B.2. Using Symmetric Keys . . . . . . . . . . . . . . . . . . 12		B.2. Using Symmetric Keys . . . . . . . . . . . . . . . . . . 13
	B.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 13		B.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 15
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This memo specifies a profile of the ACE framework		This memo specifies 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] to communicate. The client uses an access		server use CoAP [RFC7252] to communicate. The client uses an access
	token, bound to a key (the proof-of-possession key) to authorize its		token, bound to a key (the proof-of-possession key) to authorize its
	access to the resource server. In order to provide communication		access to the resource server. In order to provide communication
	security, proof of possession, and server authentication they use		security, proof of possession, and server authentication they use
	Object Security for Constrained RESTful Environments (OSCORE)		Object Security for Constrained RESTful Environments (OSCORE)
	skipping to change at page 3, line 39 ¶		skipping to change at page 3, line 39 ¶
	document that a given resource on a specific RS is associated to a		document that a given resource on a specific RS is associated to a
	unique AS.		unique AS.
	2. Client to Resource Server		2. Client to Resource Server
	The use of OSCORE for arbitrary CoAP messages is specified in		The use of OSCORE for arbitrary CoAP messages is specified in
	[I-D.ietf-core-object-security]. This section defines the specific		[I-D.ietf-core-object-security]. This section defines the specific
	uses and their purpose for securing the communication between a		uses and their purpose for securing the communication between a
	client and a resource server, and the parameters needed to negotiate		client and a resource server, and the parameters needed to negotiate
	the use of this profile with the token resource at the authorization		the use of this profile with the token resource at the authorization
	server as specified in section 5.5 of the ACE framework		server as specified in section 5.6 of the ACE framework
	[I-D.ietf-ace-oauth-authz].		[I-D.ietf-ace-oauth-authz].
	2.1. Signaling the use of OSCORE		2.1. Signaling the use of OSCORE
	A client requests a token at an AS via the /token resource. This		A client requests a token at an AS via the /token resource. This
	follows the message formats specified in section 5.5.1 of the ACE		follows the message formats specified in section 5.6.1 of the ACE
	framework [I-D.ietf-ace-oauth-authz].		framework [I-D.ietf-ace-oauth-authz].
	The AS responding to a successful access token request as defined in		The AS responding to a successful access token request as defined in
	section 5.5.2 of the ACE framework can signal that the use of OSCORE		section 5.6.2 of the ACE framework can signal that the use of OSCORE
	is REQUIRED for a specific access token by including the "profile"		is REQUIRED for a specific access token by including the "profile"
	parameter with the value "coap_oscore" in the access token response.		parameter with the value "coap_oscore" in the access token response.
	This means that the client MUST use OSCORE towards all resource		This means that the client MUST use OSCORE towards all resource
	servers for which this access token is valid, and follow Section 2.2		servers for which this access token is valid, and follow Section 2.2
	to derive the security context to run OSCORE.		to derive the security context to run OSCORE.
	The error response procedures defined in section 5.5.3 of the ACE		The error response procedures defined in section 5.6.3 of the ACE
	framework are unchanged by this profile.		framework are unchanged by this profile.
	Note the the client and the authorization server MAY OPTIONALLY use		Note the the client and the authorization server MAY OPTIONALLY use
	OSCORE to protect the interaction via the /token resource. See		OSCORE to protect the interaction via the /token resource. See
	Section 3 for details.		Section 3 for details.
	2.2. Key establishment for OSCORE		2.2. Key establishment for OSCORE
	Section 3.2 of OSCORE [I-D.ietf-core-object-security] defines how to		Section 3.2 of OSCORE [I-D.ietf-core-object-security] defines how to
	derive a security context based on a shared master secret and a set		derive a security context based on a shared master secret and a set
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 27 ¶
	derive a security context based on a shared master secret and a set		derive a security context based on a shared master secret and a set
	of other parameters, established between client and server. The		of other parameters, established between client and server. The
	proof-of-possession key (pop-key) provisioned from the AS MAY, in		proof-of-possession key (pop-key) provisioned from the AS MAY, in
	case of pre-shared keys, be used directly as master secret in OSCORE.		case of pre-shared keys, be used directly as master secret in OSCORE.
	If OSCORE is used directly with the symmetric pop-key as master		If OSCORE is used directly with the symmetric pop-key as master
	secret, then the AS MUST provision the following data, in response to		secret, then the AS MUST provision the following data, in response to
	the access token request:		the access token request:
	o a master secret		o a master secret
	o the sender identifier		o the sender identifier
	o the recipient identifier		o the recipient identifier
	Additionally, the AS MAY provision the following data, in the same		Additionally, the AS MAY provision the following data, in the same
	response. In case these parameters are omitted, the default values		response. In case these parameters are omitted, the default values
	are used as described in section 3.2 of		are used as described in section 3.2 of
	[I-D.ietf-core-object-security].		[I-D.ietf-core-object-security].
	o an AEAD algorithm		o an AEAD algorithm
	o a KDF algorithm		o a KDF algorithm
	o a salt		o a salt
	o a replay window type and size		o a replay window type and size
	The master secret MUST be communicated as COSE_Key in the 'cnf'		The master secret MUST be communicated as COSE_Key in the 'cnf'
	parameter of the access token response as defined in section 5.5.4.5		parameter of the access token response as defined in section 5.6.4.5
	of [I-D.ietf-ace-oauth-authz]. The AEAD algorithm MAY be included as		of [I-D.ietf-ace-oauth-authz]. The AEAD algorithm MAY be included as
	the 'alg' parameter in the COSE_Key; the KDF algorithm MAY be		the 'alg' parameter in the COSE_Key; the KDF algorithm MAY be
	included as the 'kdf' parameter of the COSE_Key and the salt MAY be		included as the 'kdf' parameter of the COSE_Key and the salt MAY be
	included as the 'slt' parameter of the COSE_Key as defined in table		included as the 'slt' parameter of the COSE_Key as defined in table
	1. The same parameters MUST be included as metadata of the access		1.
	token; if the token is a CWT [I-D.ietf-ace-cbor-web-token], the same
			The same parameters MUST be included as metadata of the access token;
			if the token is a CWT [I-D.ietf-ace-cbor-web-token], the same
	COSE_Key structure MUST be placed in the 'cnf' claim of this token.		COSE_Key structure MUST be placed in the 'cnf' claim of this token.
			If a CWT is used it MUST be encrypted, since the token is transferred
			from the client to the RS over an unprotected channel.
	The AS MUST also assign identifiers to both client and RS, which are		The AS MUST also assign identifiers to both client and RS, which are
	then used as Sender ID and Recipient ID in the OSCORE context as		then used as Sender ID and Recipient ID in the OSCORE context as
	described in section 3.1 of [I-D.ietf-core-object-security]. These		described in section 3.1 of [I-D.ietf-core-object-security]. These
	identifiers MUST be unique in the set of all clients and RS		identifiers MUST be unique in the set of all clients and RS
	identifiers for a certain AS. Moreover, these MUST be included in		identifiers for a certain AS. Moreover, these MUST be included in
	the COSE_Key as header parameters, as defined in table 1.		the COSE_Key as header parameters, as defined in table 1.
	We assume in this document that a resource is associated to one		We assume in this document that a resource is associated to one
	single AS, which makes it possible to assume unique identifiers for		single AS, which makes it possible to assume unique identifiers for
	each client requesting a particular resource to a RS. If this is not		each client requesting a particular resource to a RS. If this is not
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 29 ¶
	case the RS needs to have a mechanism in place to disambiguate		case the RS needs to have a mechanism in place to disambiguate
	identifiers or mitigate their effect.		identifiers or mitigate their effect.
	Note that C should set the Sender ID of its security context to the		Note that C should set the Sender ID of its security context to the
	clientId value received and the Recipient ID to the serverId value,		clientId value received and the Recipient ID to the serverId value,
	and RS should do the opposite.		and RS should do the opposite.
	+----------+-------+--------------+------------+-------------------+		+----------+-------+--------------+------------+-------------------+
	| name | label | CBOR type | registry | description |		| name | label | CBOR type | registry | description |
	+----------+-------+--------------+------------+-------------------+		+----------+-------+--------------+------------+-------------------+
	| clientId | TBD | bstr | | Identifies the |		| clientId | 6 | bstr | | Identifies the |
	| | | | | client in an |		| | | | | client in an |
	| | | | | OSCORE context |		| | | | | OSCORE context |
	| | | | | using this key |		| | | | | using this key |
	| | | | | |		| | | | | |
	| serverId | TBD | bstr | | Identifies the |		| serverId | 7 | bstr | | Identifies the |
	| | | | | server in an |		| | | | | server in an |
	| | | | | OSCORE context |		| | | | | OSCORE context |
	| | | | | using this key |		| | | | | using this key |
	| | | | | |		| | | | | |
	| kdf | TBD | bstr | | Identifies the |		| kdf | 8 | bstr | | Identifies the |
	| | | | | KDF algorithm in |		| | | | | KDF algorithm in |
	| | | | | an OSCORE context |		| | | | | an OSCORE context |
	| | | | | using this key |		| | | | | using this key |
	| | | | | |		| | | | | |
	| slt | TBD | bstr | | Identifies the |		| slt | 9 | bstr | | Identifies the |
	| | | | | master salt in |		| | | | | master salt in |
	| | | | | an OSCORE context |		| | | | | an OSCORE context |
	| | | | | using this key |		| | | | | using this key |
	+----------+-------+--------------+------------+-------------------+		+----------+-------+--------------+------------+-------------------+
	Table 1: Additional common header parameters for COSE_Key		Table 1: Additional common header parameters for COSE_Key
	Figure 1 shows an example of such an AS response, in CBOR diagnostic		Figure 1 shows an example of such an AS response, in CBOR diagnostic
	notation without the tag and value abbreviations.		notation without the tag and value abbreviations.
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 50 ¶
	"kty" : "Symmetric",		"kty" : "Symmetric",
	"alg" : "AES-CCM-16-64-128",		"alg" : "AES-CCM-16-64-128",
	"clientId" : b64'Qg',		"clientId" : b64'Qg',
	"serverId" : b64'qA',		"serverId" : b64'qA',
	"k" : b64'+a+Dg2jjU+eIiOFCa9lObw'		"k" : b64'+a+Dg2jjU+eIiOFCa9lObw'
	}		}
	}		}
	Figure 2: Example CWT with OSCORE parameters.		Figure 2: Example CWT with OSCORE parameters.
			Note that the proof-of-possession required to bind the access token
			to the client is implicitly performed by generating the shared OSCORE
			context using the pop-key as master secret, both on the client and RS
			side. An attacker using a stolen token will not be able to generate
			a valid OSCORE context and thus not be able to prove possession of
			the pop-key.
	3. Client to Authorization Server		3. Client to Authorization Server
	As specified in the ACE framework section 5.5		As specified in the ACE framework section 5.6
	[I-D.ietf-ace-oauth-authz], the Client and AS can also use CoAP		[I-D.ietf-ace-oauth-authz], the Client and AS can also use CoAP
	instead of HTTP to communicate via the token resource. This section		instead of HTTP to communicate via the token resource. This section
	specifies how to use OSCORE between Client and AS together with CoAP.		specifies how to use OSCORE between Client and AS together with CoAP.
	The use of OSCORE for this communication is OPTIONAL in this profile,		The use of OSCORE for this communication is OPTIONAL in this profile,
	other security protocols (such as DTLS) MAY be used instead.		other security protocols (such as DTLS) MAY be used instead.
	The client and the AS are expected to have pre-established security		The client and the AS are expected to have pre-established security
	contexts in place. How these security contexts are established is		contexts in place. How these security contexts are established is
	out of scope for this profile. Furthermore the client and the AS		out of scope for this profile. Furthermore the client and the AS
	communicate using OSCORE ([I-D.ietf-core-object-security]) through		communicate using OSCORE ([I-D.ietf-core-object-security]) through
	the introspection resource as specified in section 5.6 of		the introspection resource as specified in section 5.7 of
	[I-D.ietf-ace-oauth-authz].		[I-D.ietf-ace-oauth-authz].
	4. Resource Server to Authorization Server		4. Resource Server to Authorization Server
	As specified in the ACE framework section 5.6		As specified in the ACE framework section 5.7
	[I-D.ietf-ace-oauth-authz], the RS and AS can also use CoAP instead		[I-D.ietf-ace-oauth-authz], the RS and AS can also use CoAP instead
	of HTTP to communicate via the introspection resource. This section		of HTTP to communicate via the introspection resource. This section
	specifies how to use OSCORE between RS and AS. The use of OSCORE for		specifies how to use OSCORE between RS and AS. The use of OSCORE for
	this communication is OPTIONAL in this profile, other security		this communication is OPTIONAL in this profile, other security
	protocols (such as DTLS) MAY be used instead.		protocols (such as DTLS) MAY be used instead.
	The RS and the AS are expected to have pre-established security		The RS and the AS are expected to have pre-established security
	contexts in place. How these security contexts are established is		contexts in place. How these security contexts are established is
	out of scope for this profile. Furthermore the RS and the AS		out of scope for this profile. Furthermore the RS and the AS
	communicate using OSCORE ([I-D.ietf-core-object-security]) through		communicate using OSCORE ([I-D.ietf-core-object-security]) through
	the introspection resource as specified in section 5.6 of		the introspection resource as specified in section 5.7 of
	[I-D.ietf-ace-oauth-authz].		[I-D.ietf-ace-oauth-authz].
	5. Security Considerations		5. Security Considerations
	TBD.		This document specifies a profile for the Authentication and
			Authorization for Constrained Environments (ACE) framework
			[I-D.ietf-ace-oauth-authz]. Thus the general security considerations
			from the framework also apply to this profile.
			Furthermore the general security considerations of OSCORE
			[I-D.ietf-core-object-security] also apply to this specific use of
			the OSCORE protocol.
			OSCORE is designed to secure point-to-point communication, providing
			a secure binding between the request and the response(s). Thus the
			basic OSCORE protocol is not intended for use in point-to-multipoint
			communication (e.g. multicast, publish-subscribe). Implementers of
			this profile should make sure that their usecase corresponds to the
			expected use of OSCORE, to prevent weakening the security assurances
			provided by OSCORE.
	6. Privacy Considerations		6. Privacy Considerations
	TBD.		TBD.
	7. IANA Considerations		7. IANA Considerations
	TBD. 'coap_oscore' as profile id. Header parameters 'sid', 'rid',		Note to RFC Editor: Please replace all occurrences of "[[this
	'kdf' and 'slt' for COSE_Key.		specification]]" with the RFC number of this specification and delete
			this paragraph.
			The following registration is done for the ACE OAuth Profile Registry
			following the procedure specified in section 8.6 of
			[I-D.ietf-ace-oauth-authz]:
			o Profile name: coap_oscore
			o Profile Description: Profile for using OSCORE to secure
			communication between constrained nodes using the Authentication
			and Authorization for Constrained Environments framework.
			o Profile ID: 2
			o Change Controller: IESG
			o Specification Document(s): [[this specification]]
			The following registrations are done for the COSE Key Common
			Parameter Registry specified in section 16.5 of [RFC8152]:
			o Name: clientId
			o Label: 6
			o CBOR Type: bstr
			o Value Registry: N/A
			o Description: Identifies the client in an OSCORE context
			o Reference: [[this specification]]
			o Name: serverId
			o Label: 7
			o Value Type: bstr
			o Value Registry: N/A
			o Description: Identifies the server in an OSCORE context
			o Reference: [[this specification]]
			o Name: kdf
			o Label: 8
			o Value Type: bstr
			o Value Registry: COSE Algorithms registry
			o Description: Identifies the KDF algorithm to be used in an OSCORE
			context
			o Reference: [[this specification]]
			o Name: slt
			o Label: 9
			o Value Type: bstr
			o Value Registry: N/A
			o Description: Identifies the master salt of to be used in an OSCORE
			context
			o Reference: [[this specification]]
	8. References		8. References
	8.1. Normative References		8.1. Normative 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-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-09 (work in progress), November 2017.		authz-10 (work in progress), February 2018.
	[I-D.ietf-core-object-security]		[I-D.ietf-core-object-security]
	Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", draft-ietf-core-object-security-07 (work in		(OSCORE)", draft-ietf-core-object-security-08 (work in
	progress), November 2017.		progress), January 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-
	<https://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[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,		DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7252>.		editor.org/info/rfc7252>.
	[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>.
	8.2. Informative References		8.2. Informative References
	[I-D.gerdes-ace-dcaf-authorize]		[I-D.gerdes-ace-dcaf-authorize]
	Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP		Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP
	Authentication and Authorization Framework (DCAF)", draft-		Authentication and Authorization Framework (DCAF)", draft-
	skipping to change at page 9, line 15 ¶		skipping to change at page 10, line 42 ¶
	[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",		[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
	RFC 6749, DOI 10.17487/RFC6749, October 2012,		RFC 6749, DOI 10.17487/RFC6749, October 2012,
	<https://www.rfc-editor.org/info/rfc6749>.		<https://www.rfc-editor.org/info/rfc6749>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.		October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,		DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7231>.		editor.org/info/rfc7231>.
	Appendix A. Profile Requirements		Appendix A. Profile Requirements
	This section lists the specifications on this profile based on the		This section lists the specifications on this profile based on the
	requirements on the framework, as requested in Appendix C. of		requirements on the framework, as requested in Appendix C. of
	[I-D.ietf-ace-oauth-authz].		[I-D.ietf-ace-oauth-authz].
	o (Optional) discovery process of how the client finds the right AS		o (Optional) discovery process of how the client finds the right AS
	for an RS it wants to send a request to: Not specified		for an RS it wants to send a request to: Not specified
	skipping to change at page 10, line 40 ¶		skipping to change at page 12, line 9 ¶
	Note that in the case described in this section, the 'expires_in'		Note that in the case described in this section, the 'expires_in'
	parameter, defined in section 4.2.2. of [RFC6749] defines the		parameter, defined in section 4.2.2. of [RFC6749] defines the
	lifetime in seconds of both the access token and the shared secret.		lifetime in seconds of both the access token and the shared secret.
	After expiration, C MUST acquire a new access token from the AS, and		After expiration, C MUST acquire a new access token from the AS, and
	run EDHOC again, as specified in this section		run EDHOC again, as specified in this section
	B.1. Using Asymmetric Keys		B.1. Using Asymmetric Keys
	In case of an asymmetric key, C MUST communicate its own asymmetric		In case of an asymmetric key, C MUST communicate its own asymmetric
	key to the AS in the 'cnf' parameter of the access token request, as		key to the AS in the 'cnf' parameter of the access token request, as
	specified in section 5.5.1 of [I-D.ietf-ace-oauth-authz]; the AS MUST		specified in section 5.6.1 of [I-D.ietf-ace-oauth-authz]; the AS MUST
	communicate the RS's public key to C in the response, in the 'rs_cnf'		communicate the RS's public key to C in the response, in the 'rs_cnf'
	parameter, as specified in section 5.5.1 of		parameter, as specified in section 5.6.1 of
	[I-D.ietf-ace-oauth-authz]. Note that the RS's public key MUST		[I-D.ietf-ace-oauth-authz]. Note that the RS's public key MUST
	include a 'kid' parameter, and that the value of the 'kid' MUST be		include a 'kid' parameter, and that the value of the 'kid' MUST be
	included in the access token, to let the RS know which of its public		included in the access token, to let the RS know which of its public
	keys C used. If the access token is a CWT		keys C used. If the access token is a CWT
	[I-D.ietf-ace-cbor-web-token], the key identifier MUST be placed		[I-D.ietf-ace-cbor-web-token], the key identifier MUST be placed
	directly in the 'cnf' structure (if the key is only referenced).		directly in the 'cnf' structure (if the key is only referenced).
	Figure 3 shows an example of such a request in CBOR diagnostic		Figure 3 shows an example of such a request in CBOR diagnostic
	notation without tag and value abbreviations.		notation without tag and value abbreviations.
	skipping to change at page 12, line 9 ¶		skipping to change at page 13, line 30 ¶
	}		}
	}		}
	}		}
	Figure 4: Example AS response (EDHOC+OSCORE, asymmetric).		Figure 4: Example AS response (EDHOC+OSCORE, asymmetric).
	B.2. Using Symmetric Keys		B.2. Using Symmetric Keys
	In the case of a symmetric key, the AS MUST communicate the key to		In the case of a symmetric key, the AS MUST communicate the key to
	the client in the 'cnf' parameter of the access token response, as		the client in the 'cnf' parameter of the access token response, as
	specified in section 5.5.2. of [I-D.ietf-ace-oauth-authz]. AS MUST		specified in section 5.6.2. of [I-D.ietf-ace-oauth-authz]. AS MUST
	also select a key identifier, that MUST be included as the 'kid'		also select a key identifier, that MUST be included as the 'kid'
	parameter either directly in the 'cnf' structure, as in figure 4 of		parameter either directly in the 'cnf' structure, as in figure 4 of
	[I-D.ietf-ace-oauth-authz], or as the 'kid' parameter of the		[I-D.ietf-ace-oauth-authz], or as the 'kid' parameter of the
	COSE_key, as in figure 6 of [I-D.ietf-ace-oauth-authz].		COSE_key, as in figure 6 of [I-D.ietf-ace-oauth-authz].
	Figure 5 shows an example of the necessary parameters in the AS		Figure 5 shows an example of the necessary parameters in the AS
	response to the access token request when EDHOC is used. The example		response to the access token request when EDHOC is used. The example
	uses CBOR diagnostic notation without tag and value abbreviations.		uses CBOR diagnostic notation without tag and value abbreviations.
	Header: Created (Code=2.01)		Header: Created (Code=2.01)
	skipping to change at page 13, line 35 ¶		skipping to change at page 15, line 16 ¶
	To provide forward secrecy and mutual authentication in the case of		To provide forward secrecy and mutual authentication in the case of
	pre-shared keys, pre-established raw public keys or with X.509		pre-shared keys, pre-established raw public keys or with X.509
	certificates it is RECOMMENDED to use EDHOC		certificates it is RECOMMENDED to use EDHOC
	[I-D.selander-ace-cose-ecdhe] to generate the keying material. EDHOC		[I-D.selander-ace-cose-ecdhe] to generate the keying material. EDHOC
	MUST be used as defined in Appendix C of		MUST be used as defined in Appendix C of
	[I-D.selander-ace-cose-ecdhe], with the following additions and		[I-D.selander-ace-cose-ecdhe], with the following additions and
	modifications.		modifications.
	The first EDHOC message is sent after the access token is posted to		The first EDHOC message is sent after the access token is posted to
	the /authz-info resource of the RS as specified in section 5.7.1 of		the /authz-info resource of the RS as specified in section 5.8.1 of
	[I-D.ietf-ace-oauth-authz]. Then the EDHOC message_1 is sent and the		[I-D.ietf-ace-oauth-authz]. Then the EDHOC message_1 is sent and the
	EDHOC protocol is initiated [I-D.selander-ace-cose-ecdhe]).		EDHOC protocol is initiated [I-D.selander-ace-cose-ecdhe]).
	Before the RS continues with the EDHOC protocol and responds to this		Before the RS continues with the EDHOC protocol and responds to this
	token submission request, additional verifications on the access		token submission request, additional verifications on the access
	token are done: the RS SHALL process the access token according to		token are done: the RS SHALL process the access token according to
	[I-D.ietf-ace-oauth-authz]. If the token is valid then the RS		[I-D.ietf-ace-oauth-authz]. If the token is valid then the RS
	continues processing EDHOC following Appendix C of		continues processing EDHOC following Appendix C of
	[I-D.selander-ace-cose-ecdhe], otherwise it discontinues EDHOC and		[I-D.selander-ace-cose-ecdhe], otherwise it discontinues EDHOC and
	responds with the error code as specified in		responds with the error code as specified in
	skipping to change at page 13, line 50 ¶		skipping to change at page 15, line 31 ¶
	token submission request, additional verifications on the access		token submission request, additional verifications on the access
	token are done: the RS SHALL process the access token according to		token are done: the RS SHALL process the access token according to
	[I-D.ietf-ace-oauth-authz]. If the token is valid then the RS		[I-D.ietf-ace-oauth-authz]. If the token is valid then the RS
	continues processing EDHOC following Appendix C of		continues processing EDHOC following Appendix C of
	[I-D.selander-ace-cose-ecdhe], otherwise it discontinues EDHOC and		[I-D.selander-ace-cose-ecdhe], otherwise it discontinues EDHOC and
	responds with the error code as specified in		responds with the error code as specified in
	[I-D.ietf-ace-oauth-authz].		[I-D.ietf-ace-oauth-authz].
	o In case the EDHOC verification fails, the RS MUST return an error		o In case the EDHOC verification fails, the RS MUST return an error
	response to the client with code 4.01 (Unauthorized).		response to the client with code 4.01 (Unauthorized).
	o If RS has an access token for C but not for the resource that C		o If RS has an access token for C but not for the resource that C
	has requested, RS MUST reject the request with a 4.03 (Forbidden).		has requested, RS MUST reject the request with a 4.03 (Forbidden).
	o If RS has an access token for C but it does not cover the action C		o If RS has an access token for C but it does not cover the action C
	requested on the resource, RS MUST reject the request with a 4.05		requested on the resource, RS MUST reject the request with a 4.05
	(Method Not Allowed).		(Method Not Allowed).
	o If all verifications above succeeds, further communication between		o If all verifications above succeeds, further communication between
	client and RS is protected with OSCORE, including the RS response		client and RS is protected with OSCORE, including the RS response
	to the OSCORE request.		to the OSCORE request.
	In the case of EDHOC being used with symmetric keys, the protocol in		In the case of EDHOC being used with symmetric keys, the protocol in
	section 5 of [I-D.selander-ace-cose-ecdhe] MUST be used. If the key		section 5 of [I-D.selander-ace-cose-ecdhe] MUST be used. If the key
	is asymmetric, the RS MUST also use an asymmetric key for		is asymmetric, the RS MUST also use an asymmetric key for
	authentication. This key is known to the client through the access		authentication. This key is known to the client through the access
	token response (see section 5.5.2 of the ACE framework). In this		token response (see section 5.6.2 of [I-D.ietf-ace-oauth-authz]). In
	case the protocol in section 4 of [I-D.selander-ace-cose-ecdhe] MUST		this case the protocol in section 4 of [I-D.selander-ace-cose-ecdhe]
	be used.		MUST be used.
	Figure 7 illustrates the message exchanges for using OSCORE+EDHOC		Figure 7 illustrates the message exchanges for using OSCORE+EDHOC
	(step C in figure 1 of [I-D.ietf-ace-oauth-authz]).		(step C in figure 1 of [I-D.ietf-ace-oauth-authz]).
	Resource		Resource
	Client Server		Client Server
	| |		| |
	| |		| |
	+--------->| Header: POST (Code=0.02)		+--------->| Header: POST (Code=0.02)
	| POST | Uri-Path:"authz-info"		| POST | Uri-Path:"authz-info"
	skipping to change at line 710 ¶		skipping to change at page 17, line 30 ¶
	Email: francesca.palombini@ericsson.com		Email: francesca.palombini@ericsson.com
	Martin Gunnarsson		Martin Gunnarsson
	RISE SICS AB		RISE SICS AB
	Scheelevagen 17		Scheelevagen 17
	Lund 22370		Lund 22370
	Sweden		Sweden
	Email: martin.gunnarsson@ri.se		Email: martin.gunnarsson@ri.se
			Goeran Selander
			Ericsson AB
			Farogatan 6
			Kista SE-16480 Stockholm
			Sweden
			Email: goran.selander@ericsson.com
End of changes. 48 change blocks.
	65 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/