rfc9668v1.txt		rfc9668.txt
	Internet Engineering Task Force (IETF) F. Palombini		Internet Engineering Task Force (IETF) F. Palombini
	Request for Comments: 9668 Ericsson		Request for Comments: 9668 Ericsson AB
	Category: Standards Track M. Tiloca		Category: Standards Track M. Tiloca
	ISSN: 2070-1721 R. Höglund		ISSN: 2070-1721 R. Höglund
	RISE AB		RISE AB
	S. Hristozov		S. Hristozov
	Fraunhofer AISEC		Fraunhofer AISEC
	G. Selander		G. Selander
	Ericsson		Ericsson
	October 2024		October 2024
	Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained		Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained
	skipping to change at line 69 ¶		skipping to change at line 69 ¶
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. Terminology		1.1. Terminology
	2. EDHOC Overview		2. EDHOC Overview
	3. EDHOC Combined with OSCORE		3. EDHOC Combined with OSCORE
	3.1. EDHOC Option		3.1. EDHOC Option
	3.2. Client Processing		3.2. Client Processing
	3.2.1. Processing of the EDHOC + OSCORE Request		3.2.1. Processing of the EDHOC + OSCORE Request
	3.2.2. Supporting Block-Wise		3.2.2. Supporting Block-Wise Transfers
	3.3. Server Processing		3.3. Server Processing
	3.3.1. Processing of the EDHOC + OSCORE Request		3.3.1. Processing of the EDHOC + OSCORE Request
	3.3.2. Supporting Block-Wise		3.3.2. Supporting Block-Wise Transfers
	3.4. Example of the EDHOC + OSCORE Request		3.4. Example of the EDHOC + OSCORE Request
	4. Use of EDHOC Connection Identifiers with OSCORE		4. Use of EDHOC Connection Identifiers with OSCORE
	4.1. Additional Processing of EDHOC Messages		4.1. Additional Processing of EDHOC Messages
	4.1.1. Initiator Processing of Message 1		4.1.1. Initiator Processing of Message 1
	4.1.2. Responder Processing of Message 2		4.1.2. Responder Processing of Message 2
	4.1.3. Initiator Processing of Message 2		4.1.3. Initiator Processing of Message 2
	5. Extension and Consistency of Application Profiles		5. Extension and Consistency of Application Profiles
	6. Web Linking		6. Web Linking
	7. Security Considerations		7. Security Considerations
	8. IANA Considerations		8. IANA Considerations
	skipping to change at line 130 ¶		skipping to change at line 130 ¶
	The minimum number of two round trips can be achieved only if the		The minimum number of two round trips can be achieved only if the
	default forward message flow of EDHOC is used, i.e., when a CoAP		default forward message flow of EDHOC is used, i.e., when a CoAP
	client acts as EDHOC Initiator and a CoAP server acts as EDHOC		client acts as EDHOC Initiator and a CoAP server acts as EDHOC
	Responder. The performance advantage of using this optimization can		Responder. The performance advantage of using this optimization can
	be lost when used in combination with Block-wise transfers [RFC7959]		be lost when used in combination with Block-wise transfers [RFC7959]
	that rely on specific parameter values and block sizes.		that rely on specific parameter values and block sizes.
	Furthermore, this document defines a number of parameters		Furthermore, this document defines a number of parameters
	corresponding to different information elements of an EDHOC		corresponding to different information elements of an EDHOC
	application profile (see Section 6). These can be specified as		application profile (see Section 6). These parameters can be
	target attributes in the link to an EDHOC resource associated with		specified as target attributes in the link to an EDHOC resource
	that application profile, thus enabling an enhanced discovery of such		associated with that application profile, thus enabling an enhanced
	a resource for CoAP clients.		discovery of such a resource for CoAP clients.
	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.
	The reader is expected to be familiar with terms and concepts defined		The reader is expected to be familiar with terms and concepts defined
	in CoAP [RFC7252], Concise Binary Object Representation (CBOR)		in CoAP [RFC7252], Concise Binary Object Representation (CBOR)
	[RFC8949], OSCORE [RFC8613], and EDHOC [RFC9528].		[RFC8949], OSCORE [RFC8613], and EDHOC [RFC9528].
	2. EDHOC Overview		2. EDHOC Overview
	This section is not normative and summarizes what is specified in		This section is not normative and summarizes what is specified in
	[RFC9528] (specifically Appendix A.2 of [RFC9528]). Thus, it		[RFC9528] (specifically Appendix A.2 of [RFC9528]). Thus, it
	provides a baseline for the enhancements in the subsequent sections.		provides a baseline for the enhancements in the subsequent sections.
	The EDHOC protocol specified in [RFC9528] allows two peers to agree		The EDHOC protocol specified in [RFC9528] allows two peers to agree
	on a cryptographic secret in a mutually authenticated way and by		on a cryptographic secret in a mutually-authenticated way and
	using Diffie-Hellman ephemeral keys to achieve forward secrecy. The		achieves forward secrecy by using Diffie-Hellman ephemeral keys. The
	two peers are denoted as the "Initiator" and "Responder", as the one		two peers are denoted as the "Initiator" and "Responder", as the one
	sending or receiving the initial EDHOC message_1, respectively.		sending or receiving the initial EDHOC message_1, respectively.
	After successful processing of EDHOC message_3, both peers agree on a		After successful processing of EDHOC message_3, both peers agree on a
	cryptographic secret that can be used to derive further security		cryptographic secret that can be used to derive further security
	material and establish an OSCORE Security Context [RFC8613]. The		material and establish an OSCORE Security Context [RFC8613]. The
	Responder can also send an optional EDHOC message_4 to achieve key		Responder can also send an optional EDHOC message_4 in order for the
	confirmation, e.g., in deployments where no protected application		Initiator to achieve key confirmation, e.g., in deployments where no
	message is sent from the Responder to the Initiator.		protected application message is sent from the Responder to the
			Initiator.
	Appendix A.2 of [RFC9528] specifies how to transfer EDHOC over CoAP.		Appendix A.2 of [RFC9528] specifies how to transfer EDHOC over CoAP.
	That is, the EDHOC data (i.e., the EDHOC message possibly with a		That is, the EDHOC data (i.e., the EDHOC message possibly with a
	prepended connection identifier) is transported in the payload of		prepended connection identifier) is transported in the payload of
	CoAP requests and responses. The default forward message flow of		CoAP requests and responses. The default forward message flow of
	EDHOC consists in the CoAP client acting as Initiator and the CoAP		EDHOC consists in the CoAP client acting as Initiator and the CoAP
	server acting as Responder (see Appendix A.2.1 of [RFC9528]).		server acting as Responder (see Appendix A.2.1 of [RFC9528]).
	Alternatively, the two roles can be reversed as per the reverse		Alternatively, the two roles can be reversed as per the reverse
	message flow of EDHOC (see Appendix A.2.2 of [RFC9528]). In the rest		message flow of EDHOC (see Appendix A.2.2 of [RFC9528]). In the rest
	of this document, EDHOC messages are considered to be transferred		of this document, EDHOC messages are considered to be transferred
	over CoAP.		over CoAP.
	Figure 1 shows a successful execution of EDHOC, with a CoAP client		Figure 1 shows a successful execution of EDHOC, with a CoAP client
	and a CoAP server running EDHOC as Initiator and Responder,		and a CoAP server running EDHOC as Initiator and Responder,
	respectively. In particular, it extends Figure 10 from		respectively. In particular, it extends Figure 10 from
	Appendix A.2.1 of [RFC9528] by highlighting when the two peers		Appendix A.2.1 of [RFC9528] by highlighting when the two peers
	perform EDHOC verification and establish the OSCORE Security Context,		perform EDHOC verification and establish the OSCORE Security Context,
	and by adding an exchange of OSCORE-protected CoAP messages after		and by adding an exchange of OSCORE-protected CoAP messages after
	completing the EDHOC execution.		completing the EDHOC execution.
	That is, the client sends a POST request to a reserved _EDHOC		That is, the client sends a POST request to a reserved EDHOC resource
	resource_ at the server by default at the Uri-Path "/.well-known/		at the server, by default at the Uri-Path "/.well-known/edhoc". The
	edhoc". The request payload consists of the CBOR simple value true		request payload consists of the CBOR simple value true (0xf5)
	(0xf5) concatenated with EDHOC message_1, which also includes the		concatenated with EDHOC message_1, which also includes the EDHOC
	EDHOC connection identifier C_I of the client encoded as per		connection identifier C_I of the client encoded as per Section 3.3 of
	Section 3.3 of [RFC9528]. The request has Content-Format		[RFC9528]. The request has Content-Format application/cid-
	application/cid-edhoc+cbor-seq.		edhoc+cbor-seq.
	This triggers the EDHOC execution at the server, which replies with a		This triggers the EDHOC execution at the server, which replies with a
	2.04 (Changed) response. The response payload consists of EDHOC		2.04 (Changed) response. The response payload consists of EDHOC
	message_2, which also includes the EDHOC connection identifier C_R of		message_2, which also includes the EDHOC connection identifier C_R of
	the server encoded as per Section 3.3 of [RFC9528]. The response has		the server encoded as per Section 3.3 of [RFC9528]. The response has
	Content-Format application/edhoc+cbor-seq.		Content-Format application/edhoc+cbor-seq.
	Finally, the client sends a POST request to the same EDHOC resource		Finally, the client sends a POST request to the same EDHOC resource
	used earlier when it sent EDHOC message_1. The request payload		used earlier when it sent EDHOC message_1. The request payload
	consists of the EDHOC connection identifier C_R encoded as per		consists of the EDHOC connection identifier C_R encoded as per
	Section 3.3 of [RFC9528] concatenated with EDHOC message_3. The		Section 3.3 of [RFC9528] concatenated with EDHOC message_3. The
	request has Content-Format application/cid-edhoc+cbor-seq.		request has Content-Format application/cid-edhoc+cbor-seq.
	After this exchange takes place, and after successful verifications		After this exchange takes place, and after successful verifications
	as specified in the EDHOC protocol, the client and server can derive		as specified in the EDHOC protocol, the client and server can derive
	an OSCORE Security Context as defined in Appendix A.1 of [RFC9528].		an OSCORE Security Context as defined in Appendix A.1 of [RFC9528].
	After that, the client and server can use OSCORE to protect their		After that, the client and server can use OSCORE to protect their
	communications as per [RFC8613]. Note that the EDHOC Connection		communications as per [RFC8613]. Note that the EDHOC connection
	Identifier C_R is used as the OSCORE Sender ID of the client (see		identifier C_R is used as the OSCORE Sender ID of the client (see
	Appendix A.1 of [RFC9528]). Therefore, C_R is transported in the		Appendix A.1 of [RFC9528]). Therefore, C_R is transported in the
	'kid' field of the OSCORE Option of the OSCORE Request (see		'kid' field of the OSCORE option of the OSCORE Request (see
	Section 6.1 of [RFC8613]).		Section 6.1 of [RFC8613]).
	The client and server are required to agree in advance on certain		The client and server are required to agree in advance on certain
	information and parameters describing how they should use EDHOC.		information and parameters describing how they should use EDHOC.
	These are specified in an application profile associated with the		These are specified in an application profile associated with the
	EDHOC resource addressed (see Section 3.9 of [RFC9528]).		EDHOC resource addressed (see Section 3.9 of [RFC9528]).
	CoAP client CoAP server		CoAP client CoAP server
	(EDHOC Initiator) (EDHOC Responder)		(EDHOC Initiator) (EDHOC Responder)
	| |		| |
	skipping to change at line 267 ¶		skipping to change at line 268 ¶
	| Header: 0.02 (POST) |		| Header: 0.02 (POST) |
	| OSCORE: { ... ; kid: C_R } |		| OSCORE: { ... ; kid: C_R } |
	| Payload: OSCORE-protected data |		| Payload: OSCORE-protected data |
	| |		| |
	| <--------------- OSCORE Response ----------------- |		| <--------------- OSCORE Response ----------------- |
	| Header: 2.04 (Changed) |		| Header: 2.04 (Changed) |
	| OSCORE: { ... } |		| OSCORE: { ... } |
	| Payload: OSCORE-protected data |		| Payload: OSCORE-protected data |
	| |		| |
	Figure 1: EDHOC and OSCORE run sequentially. The optional		Figure 1: Sequential Flow of EDHOC and OSCORE with the Optional
	message_4 is included in this example.		message_4 Included
	As shown in Figure 1, this sequential flow where EDHOC is run first		The sequential flow of EDHOC and OSCORE (where EDHOC runs first and
	and then OSCORE is used takes three round trips to complete.		OSCORE is used after) takes three round trips to complete, as shown
			in Figure 1.
	Section 3 defines an optimization for combining EDHOC with the first		Section 3 defines an optimization for combining EDHOC with the first
	OSCORE transaction. This reduces the number of round trips required		OSCORE transaction. This reduces the number of round trips required
	to set up an OSCORE Security Context and complete an OSCORE		to set up an OSCORE Security Context and complete an OSCORE
	transaction using that Security Context.		transaction using that Security Context.
	3. EDHOC Combined with OSCORE		3. EDHOC Combined with OSCORE
	This section defines an optimization for combining the EDHOC message		This section defines an optimization for combining the EDHOC message
	exchange with the first OSCORE transaction, thus minimizing the		exchange with the first OSCORE transaction, thus minimizing the
	skipping to change at line 309 ¶		skipping to change at line 311 ¶
	CoAP client CoAP server		CoAP client CoAP server
	(EDHOC Initiator) (EDHOC Responder)		(EDHOC Initiator) (EDHOC Responder)
	| |		| |
	| ------------------ EDHOC Request -----------------> |		| ------------------ EDHOC Request -----------------> |
	| Header: 0.02 (POST) |		| Header: 0.02 (POST) |
	| Uri-Path: "/.well-known/edhoc" |		| Uri-Path: "/.well-known/edhoc" |
	| Content-Format: application/cid-edhoc+cbor-seq |		| Content-Format: application/cid-edhoc+cbor-seq |
	| Payload: true, EDHOC message_1 |		| Payload: true, EDHOC message_1 |
	| |		| |
	| <----------------- EDHOC Response------------------ |		| <----------------- EDHOC Response------------------ |
	| Header: Changed (2.04) |		| Header: 2.04 (Changed) |
	| Content-Format: application/edhoc+cbor-seq |		| Content-Format: application/edhoc+cbor-seq |
	| Payload: EDHOC message_2 |		| Payload: EDHOC message_2 |
	| |		| |
	EDHOC verification |		EDHOC verification |
	+ |		+ |
	OSCORE Sec Ctx |		OSCORE Sec Ctx |
	Derivation |		Derivation |
	| |		| |
	| -------------- EDHOC + OSCORE Request ------------> |		| -------------- EDHOC + OSCORE Request ------------> |
	| Header: 0.02 (POST) |		| Header: 0.02 (POST) |
	skipping to change at line 343 ¶		skipping to change at line 345 ¶
	Figure 2: EDHOC and OSCORE Combined		Figure 2: EDHOC and OSCORE Combined
	To this end, the specific approach defined in this section consists		To this end, the specific approach defined in this section consists
	of sending a single EDHOC + OSCORE request, which conveys the pair		of sending a single EDHOC + OSCORE request, which conveys the pair
	(C_R, EDHOC message_3) within an OSCORE-protected CoAP message.		(C_R, EDHOC message_3) within an OSCORE-protected CoAP message.
	That is, the EDHOC + OSCORE request is composed of the following two		That is, the EDHOC + OSCORE request is composed of the following two
	parts combined together in a single CoAP message. The steps for		parts combined together in a single CoAP message. The steps for
	processing the EDHOC + OSCORE request and the two parts combined in		processing the EDHOC + OSCORE request and the two parts combined in
	there are defined in Sections 3.2.1 and 3.3.1.		the request itself are defined in Sections 3.2.1 and 3.3.1.
	* The OSCORE Request from Figure 1, which, in this case, is also		* The OSCORE Request from Figure 1, which, in this case, is also
	sent to a protected resource with the correct CoAP method and		sent to a protected resource with the correct CoAP method and
	options intended for accessing that resource.		options intended for accessing that resource.
	* EDHOC data consisting of the pair (C_R, EDHOC message_3) required		* EDHOC data consisting of the pair (C_R, EDHOC message_3) required
	for completing the EDHOC session transported as follows:		for completing the EDHOC session transported as follows:
	- C_R is the OSCORE Sender ID of the client; hence, it is		- C_R is the OSCORE Sender ID of the client; hence, it is
	transported in the 'kid' field of the OSCORE Option (see		transported in the 'kid' field of the OSCORE option (see
	Section 6.1 of [RFC8613]). Unlike the sequential workflow		Section 6.1 of [RFC8613]). Unlike the sequential workflow
	shown in Figure 1, C_R is not transported in the payload of the		shown in Figure 1, C_R is not transported in the payload of the
	EDHOC + OSCORE request.		EDHOC + OSCORE request.
	- EDHOC message_3 is transported in the payload of the EDHOC +		- EDHOC message_3 is transported in the payload of the EDHOC +
	OSCORE request and prepended to the payload of the OSCORE		OSCORE request and prepended to the payload of the OSCORE
	Request. This is because EDHOC message_3 may be too large to		Request. This is because EDHOC message_3 may be too large to
	be included in a CoAP Option, e.g., when conveying a large		be included in a CoAP option, e.g., when conveying a large
	public key certificate chain such as ID_CRED_I (see		public key certificate chain in the ID_CRED_I field (see
	Section 3.5.3 of [RFC9528]), or when conveying large External		Section 3.5.3 of [RFC9528]), or when conveying large External
	Authorization Data such as EAD_3 (see Section 3.8 of		Authorization Data in the EAD_3 field (see Section 3.8 of
	[RFC9528]).		[RFC9528]).
	The rest of this section specifies how to transport the data in the		The rest of this section specifies how to transport the data in the
	EDHOC + OSCORE request and their processing order. In particular,		EDHOC + OSCORE request and their processing order. In particular,
	the use of this approach is explicitly signalled by including an		the use of this approach is explicitly signalled by including an
	EDHOC Option (Section 3.1) in the EDHOC + OSCORE request. The		EDHOC option (Section 3.1) in the EDHOC + OSCORE request. The
	processing of the EDHOC + OSCORE request is specified in Section 3.2		processing of the EDHOC + OSCORE request is specified in Section 3.2
	for the client side and in Section 3.3 for the server side.		for the client side and in Section 3.3 for the server side.
	3.1. EDHOC Option		3.1. EDHOC Option
	This section defines the EDHOC Option. This option is used in a CoAP		This section defines the EDHOC option. This option is used in a CoAP
	request to signal that the request payload conveys both an EDHOC		request to signal that the request payload conveys both an EDHOC
	message_3 and OSCORE-protected data: combined together.		message_3 and OSCORE-protected data combined together.
	The EDHOC Option has the properties summarized in Table 1, which		The EDHOC option has the properties summarized in Table 1, which
	extends Table 4 of [RFC7252]. The option is Critical, Safe-to-		extends Table 4 of [RFC7252]. The option is Critical, Safe-to-
	Forward, and part of the Cache-Key. The option MUST occur at most		Forward, and part of the Cache-Key. The option MUST occur at most
	once and MUST be empty. If any value is sent, the recipient MUST		once and MUST be empty. If any value is sent, the recipient MUST
	ignore it. (Future documents may update the definition of the option		ignore it. (Future documents may update the definition of the option
	by expanding its semantics and specifying admitted values.) The		by expanding its semantics and specifying admitted values.) The
	option is intended only for CoAP requests and is of Class U for		option is intended only for CoAP requests and is of Class U for
	OSCORE [RFC8613].		OSCORE [RFC8613].
	+=====+===+===+===+===+=======+========+========+=========+		+=====+===+===+===+===+=======+========+========+=========+
	| No. | C | U | N | R | Name | Format | Length | Default |		| No. | C | U | N | R | Name | Format | Length | Default |
	+=====+===+===+===+===+=======+========+========+=========+		+=====+===+===+===+===+=======+========+========+=========+
	| 21 | x | | | | EDHOC | Empty | 0 | (none) |		| 21 | x | | | | EDHOC | Empty | 0 | (none) |
	+-----+---+---+---+---+-------+--------+--------+---------+		+-----+---+---+---+---+-------+--------+--------+---------+
	Table 1: The EDHOC Option		Table 1: The EDHOC Option. C=Critical, U=Unsafe,
			N=NoCacheKey, R=Repeatable
	C=Critical
	U=Unsafe
	N=NoCacheKey
	R=Repeatable
	The presence of this option means that the message payload also		The presence of this option means that the message payload also
	contains EDHOC data that must be extracted and processed as defined		contains EDHOC data that must be extracted and processed as defined
	in Section 3.3 before the rest of the message can be processed.		in Section 3.3 before the rest of the message can be processed.
	Figure 3 shows an example of a CoAP message that is transported over		Figure 3 shows an example of a CoAP message that is transported over
	UDP and that contains both the EDHOC data and the OSCORE ciphertext		UDP and that contains both the EDHOC data and the OSCORE ciphertext
	using the newly defined EDHOC option for signalling.		using the newly defined EDHOC option for signalling.
	0 1 2 3		0 1 2 3
	skipping to change at line 424 ¶		skipping to change at line 422 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Token (if any, TKL bytes) ...		| Token (if any, TKL bytes) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Observe Option| OSCORE Option ...		| Observe Option| OSCORE Option ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| EDHOC Option | Other Options (if any) ...		| EDHOC Option | Other Options (if any) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1 1 1 1 1 1 1 1| Payload ...		|1 1 1 1 1 1 1 1| Payload ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Example of CoAP Message Transported over UDP Combining		Figure 3: Example of a CoAP Message Containing the Combined EDHOC
	EDHOC Data and OSCORE Data as Signalled with the EDHOC Option		and OSCORE Data, Signalled by the EDHOC Option and Transported
			over UDP
	3.2. Client Processing		3.2. Client Processing
	This section describes the processing on the client side.		This section describes the processing on the client side.
	3.2.1. Processing of the EDHOC + OSCORE Request		3.2.1. Processing of the EDHOC + OSCORE Request
	The client prepares an EDHOC + OSCORE request as follows.		The client prepares an EDHOC + OSCORE request as follows.
	Step 1. Compose EDHOC message_3 into EDHOC_MSG_3 as per		Step 1. Compose EDHOC message_3 into EDHOC_MSG_3 as per
	skipping to change at line 467 ¶		skipping to change at line 466 ¶
	* OSCORE_PAYLOAD is the OSCORE ciphertext of the OSCORE-		* OSCORE_PAYLOAD is the OSCORE ciphertext of the OSCORE-
	protected CoAP request resulting from Step 2.		protected CoAP request resulting from Step 2.
	Step 4. Compose the EDHOC + OSCORE request, as the OSCORE-protected		Step 4. Compose the EDHOC + OSCORE request, as the OSCORE-protected
	CoAP request resulting from Step 2, where the payload is		CoAP request resulting from Step 2, where the payload is
	replaced with COMB_PAYLOAD built at Step 3.		replaced with COMB_PAYLOAD built at Step 3.
	Note that the new payload includes EDHOC message_3, but it		Note that the new payload includes EDHOC message_3, but it
	does not include the EDHOC connection identifier C_R. As		does not include the EDHOC connection identifier C_R. As
	the client is the EDHOC Initiator, C_R is the OSCORE Sender		the client is the EDHOC Initiator, C_R is the OSCORE Sender
	ID of the client, which is already specified as 'kid' in the		ID of the client, which is already specified as the value of
	OSCORE Option of the request from Step 2, hence of the EDHOC		the 'kid' field in the OSCORE option of the request from
	+ OSCORE request.		Step 2; hence, C_R is specified as the value of the 'kid'
			field of the EDHOC + OSCORE request.
	Step 5. Include the new EDHOC Option defined in Section 3.1 into the		Step 5. Include the new EDHOC option defined in Section 3.1 into the
	EDHOC + OSCORE request.		EDHOC + OSCORE request.
	The application/cid-edhoc+cbor-seq media type does not apply		The application/cid-edhoc+cbor-seq media type does not apply
	to this message, whose media type is unnamed.		to this message, whose media type is unnamed.
	Step 6. Send the EDHOC + OSCORE request to the server.		Step 6. Send the EDHOC + OSCORE request to the server.
	With the same server, the client SHOULD NOT have multiple		With the same server, the client SHOULD NOT have multiple
	simultaneous outstanding interactions (see Section 4.7 of [RFC7252]),		simultaneous outstanding interactions (see Section 4.7 of [RFC7252]),
	such that they consist of an EDHOC + OSCORE request and their EDHOC		such that they consist of an EDHOC + OSCORE request and their EDHOC
	data pertains to the EDHOC session with the same connection		data pertains to the EDHOC session with the same connection
	identifier C_R.		identifier C_R.
	An exception might apply for clients that operate under particular		An exception might apply for clients that operate under particular
	time constraints over particularly unreliable networks, thus raising		time constraints over particularly unreliable networks, thus raising
	the chances to promptly complete the EDHOC execution with the server		the chances to promptly complete the EDHOC execution with the server
	through multiple simultaneous EDHOC + OSCORE requests. As discussed		through multiple simultaneous EDHOC + OSCORE requests. As discussed
	in Section 7, this does not have any impact in terms of security.		in Section 7, this does not have any impact in terms of security.
	3.2.2. Supporting Block-Wise		3.2.2. Supporting Block-Wise Transfers
	If Block-wise [RFC7959] is supported, the client may fragment the		If Block-wise transfers [RFC7959] are supported, the client may
	first application CoAP request before protecting it as an original		fragment the first CoAP application request before protecting it as
	message with OSCORE as defined in Section 4.1.3.4.1 of [RFC8613].		an original message with OSCORE as defined in Section 4.1.3.4.1 of
			[RFC8613].
	In such a case, the OSCORE processing in Step 2 of Section 3.2.1 is		In such a case, the OSCORE processing in Step 2 of Section 3.2.1 is
	performed on each inner block of the first application CoAP request.		performed on each inner block of the first CoAP application request.
	The following also applies.		The following also applies.
	* The client takes the following additional step between Steps 2 and		* The client takes the following additional step between Steps 2 and
	3 of Section 3.2.1.		3 of Section 3.2.1.
	- If the OSCORE-protected request from Step 2 conveys a non-first		Step 2.1. If the OSCORE-protected request from Step 2 conveys a
	inner block of the first application CoAP request (i.e., the		non-first inner block of the first CoAP application
	Block1 Option processed at Step 2 had NUM different than 0),		request (i.e., the Block1 option processed at Step 2 had
	then the client skips the following steps and sends the OSCORE-		NUM different than 0), then the client skips the
	protected request to the server. In particular, the client		following steps and sends the OSCORE-protected request
	MUST NOT include the EDHOC Option in the OSCORE-protected		to the server. In particular, the client MUST NOT
	request.		include the EDHOC option in the OSCORE-protected
			request.
	* The client takes the following additional step between Steps 3 and		* The client takes the following additional step between Steps 3 and
	4 of Section 3.2.1.		4 of Section 3.2.1.
	- If the size of COMB_PAYLOAD exceeds MAX_UNFRAGMENTED_SIZE (see		Step 3.1. If the size of COMB_PAYLOAD exceeds
	Section 4.1.3.4.2 of [RFC8613]), the client MUST stop		MAX_UNFRAGMENTED_SIZE (see Section 4.1.3.4.2 of
	processing the request and MUST abandon the Block-wise		[RFC8613]), the client MUST stop processing the request
	transfer. Then, the client can continue by switching to the		and MUST abandon the Block-wise transfer. Then, the
	sequential workflow shown in Figure 1. That is, the client		client can continue by switching to the sequential
	first sends EDHOC message_3 prepended by the EDHOC Connection		workflow shown in Figure 1. That is, the client first
	Identifier C_R encoded as per Section 3.3 of [RFC9528]. Then,		sends EDHOC message_3 prepended by the EDHOC connection
	the client sends the OSCORE-protected CoAP request once the		identifier C_R encoded as per Section 3.3 of [RFC9528].
	EDHOC execution is completed.		Then, the client sends the OSCORE-protected CoAP request
			once the EDHOC execution is completed.
	The performance advantage of using the EDHOC + OSCORE request can be		The performance advantage of using the EDHOC + OSCORE request can be
	lost when used in combination with Block-wise transfers that rely on		lost when used in combination with Block-wise transfers that rely on
	specific parameter values and block sizes. Application policies at		specific parameter values and block sizes. Application policies at
	the CoAP client can define when and how to detect whether the		the CoAP client can define when and how to detect whether the
	performance advantage is lost. If that is the case, they can also		performance advantage is lost. If that is the case, they can also
	define whether to appropriately adjust the parameter values and block		define whether to appropriately adjust the parameter values and block
	sizes or to fall back on the sequential workflow of EDHOC.		sizes or to fall back on the sequential workflow of EDHOC.
	3.3. Server Processing		3.3. Server Processing
	skipping to change at line 552 ¶		skipping to change at line 555 ¶
	Step 1. Check that the EDHOC + OSCORE request includes the OSCORE		Step 1. Check that the EDHOC + OSCORE request includes the OSCORE
	option and that the request payload has the format defined		option and that the request payload has the format defined
	at Step 3 of Section 3.2.1 for COMB_PAYLOAD. If this is not		at Step 3 of Section 3.2.1 for COMB_PAYLOAD. If this is not
	the case, the server MUST stop processing the request and		the case, the server MUST stop processing the request and
	MUST reply with a 4.00 (Bad Request) error response.		MUST reply with a 4.00 (Bad Request) error response.
	Step 2. Extract EDHOC message_3 from the payload COMB_PAYLOAD of the		Step 2. Extract EDHOC message_3 from the payload COMB_PAYLOAD of the
	EDHOC + OSCORE request as the first element EDHOC_MSG_3 (see		EDHOC + OSCORE request as the first element EDHOC_MSG_3 (see
	Step 3 of Section 3.2.1).		Step 3 of Section 3.2.1).
	Step 3. Take the value of 'kid' from the OSCORE option of the EDHOC		Step 3. Take the value of the 'kid' field from the OSCORE option of
	+ OSCORE request (i.e., the OSCORE Sender ID of the client),		the EDHOC + OSCORE request (i.e., the OSCORE Sender ID of
	and use it as the EDHOC connection identifier C_R.		the client), and use it as the EDHOC connection identifier
			C_R.
	Step 4. Retrieve the correct EDHOC session by using the connection		Step 4. Retrieve the correct EDHOC session by using the connection
	identifier C_R from Step 3.		identifier C_R from Step 3.
	If the application profile used in the EDHOC session		If the application profile used in the EDHOC session
	specifies that EDHOC message_4 shall be sent, the server		specifies that EDHOC message_4 shall be sent, the server
	MUST stop the EDHOC processing and consider it failed due to		MUST stop the EDHOC processing and consider it failed due to
	a client error.		a client error.
	Otherwise, perform the EDHOC processing on the EDHOC		Otherwise, perform the EDHOC processing on the EDHOC
	skipping to change at line 624 ¶		skipping to change at line 628 ¶
	OSCORE. As per Section 9.5 of [RFC9528], the server has to make sure		OSCORE. As per Section 9.5 of [RFC9528], the server has to make sure
	that the error message does not reveal sensitive information. The		that the error message does not reveal sensitive information. The
	CoAP response conveying the EDHOC error message MUST have Content-		CoAP response conveying the EDHOC error message MUST have Content-
	Format set to application/edhoc+cbor-seq registered in Section 10.9		Format set to application/edhoc+cbor-seq registered in Section 10.9
	of [RFC9528].		of [RFC9528].
	If Step 4 (EDHOC processing) is successfully completed but Step 8		If Step 4 (EDHOC processing) is successfully completed but Step 8
	(OSCORE processing) fails, the same OSCORE error handling as defined		(OSCORE processing) fails, the same OSCORE error handling as defined
	in Section 8.2 of [RFC8613] applies.		in Section 8.2 of [RFC8613] applies.
	3.3.2. Supporting Block-Wise		3.3.2. Supporting Block-Wise Transfers
	If Block-wise [RFC7959] is supported, the server takes the additional		If Block-wise transfers [RFC7959] are supported, the server takes the
	following step before any other in Section 3.3.1.		additional following step before any other in Section 3.3.1.
	* If Block-wise is present in the request, then process the Outer		Step 0. If a Block option is present in the request, then process
	Block options according to [RFC7959] until all blocks of the		the Outer Block options according to [RFC7959] until all
	request have been received (see Section 4.1.3.4 of [RFC8613]).		blocks of the request have been received (see
			Section 4.1.3.4 of [RFC8613]).
	3.4. Example of the EDHOC + OSCORE Request		3.4. Example of the EDHOC + OSCORE Request
	Figure 4 shows an example of an EDHOC + OSCORE Request transported		Figure 4 shows an example of an EDHOC + OSCORE request transported
	over UDP. In particular, the example assumes that:		over UDP. In particular, the example assumes that:
	* The OSCORE Partial IV in use is 0 consistently with the first		* The OSCORE Partial IV in use is 0 consistently with the first
	request protected with the new OSCORE Security Context.		request protected with the new OSCORE Security Context.
	* The OSCORE Sender ID of the client is 0x01.		* The OSCORE Sender ID of the client is 0x01.
	As per Section 3.3.3 of [RFC9528], this straightforwardly		As per Section 3.3.3 of [RFC9528], this straightforwardly
	corresponds to the EDHOC connection identifier C_R 0x01.		corresponds to the EDHOC connection identifier C_R 0x01.
	skipping to change at line 662 ¶		skipping to change at line 667 ¶
	This results in the following components shown in Figure 4:		This results in the following components shown in Figure 4:
	OSCORE option value: 0x090001 (3 bytes)		OSCORE option value: 0x090001 (3 bytes)
	EDHOC option value: - (0 bytes)		EDHOC option value: - (0 bytes)
	EDHOC message_3: 0x52d5535f3147e85f1cfacd9e78abf9e0a81bbf (19 bytes)		EDHOC message_3: 0x52d5535f3147e85f1cfacd9e78abf9e0a81bbf (19 bytes)
	OSCORE ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes)		OSCORE ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes)
	Protected CoAP request (OSCORE message): See Figure 4.		0x44025d1f ; CoAP 4-byte Header
	0x44025d1f ; CoAP 4-byte header
	00003974 ; Token		00003974 ; Token
	93 090001 ; OSCORE Option		93 090001 ; OSCORE Option
	c0 ; EDHOC Option		c0 ; EDHOC Option
	ff 52d5535f3147e85f1cfacd9e78abf9e0a81bbf		ff 52d5535f3147e85f1cfacd9e78abf9e0a81bbf
	612f1092f1776f1c1668b3825e		612f1092f1776f1c1668b3825e
	(46 bytes)		(46 bytes)
	Figure 4: Example of CoAP Message Transported over UDP, Combining		Figure 4: Example of a Protected CoAP Request Combining EDHOC and
	EDHOC Data and OSCORE Data as Signalled with the EDHOC Option		OSCORE Data
	4. Use of EDHOC Connection Identifiers with OSCORE		4. Use of EDHOC Connection Identifiers with OSCORE
	The OSCORE Sender/Recipient IDs are the EDHOC connection identifiers		The OSCORE Sender/Recipient IDs are the EDHOC connection identifiers
	(see Section 3.3.3 of [RFC9528]). This applies also to the optimized		(see Section 3.3.3 of [RFC9528]). This applies also to the optimized
	workflow defined in Section 3 of this document.		workflow defined in Section 3 of this document.
	Note that the value of 'kid' in the OSCORE Option of the EDHOC +		Note that the value of the 'kid' field in the OSCORE option of the
	OSCORE request is both the server's Recipient ID (i.e., the client's		EDHOC + OSCORE request is both the server's Recipient ID (i.e., the
	Sender ID) and the EDHOC Connection Identifier C_R of the server at		client's Sender ID) and the EDHOC connection identifier C_R of the
	Step 3 of Section 3.3.1.		server at Step 3 of Section 3.3.1.
	4.1. Additional Processing of EDHOC Messages		4.1. Additional Processing of EDHOC Messages
	When using EDHOC to establish an OSCORE Security Context, the client		When using EDHOC to establish an OSCORE Security Context, the client
	and server MUST perform the following additional steps during an		and server MUST perform the following additional steps during an
	EDHOC execution, thus extending Section 5 of [RFC9528].		EDHOC execution, thus extending Section 5 of [RFC9528].
	4.1.1. Initiator Processing of Message 1		4.1.1. Initiator Processing of Message 1
	The Initiator selects an EDHOC Connection Identifier C_I as follows.		The Initiator selects an EDHOC connection identifier C_I as follows.
	The Initiator MUST choose a C_I that is neither used in any current		The Initiator MUST choose a C_I that is neither used in any current
	EDHOC session as this peer's EDHOC Connection Identifier nor the		EDHOC session as this peer's EDHOC connection identifier nor the
	Recipient ID in a current OSCORE Security Context where the ID		Recipient ID in a current OSCORE Security Context where the ID
	Context is not present.		Context is not present.
	The chosen C_I SHOULD NOT be the Recipient ID of any current OSCORE		The chosen C_I SHOULD NOT be the Recipient ID of any current OSCORE
	Security Context. Note that, unless the two peers concurrently use		Security Context. Note that, unless the two peers concurrently use
	alternative methods to establish OSCORE Security Contexts, this		alternative methods to establish OSCORE Security Contexts, this
	allows the Responder to always omit the 'kid context' in the OSCORE		allows the Responder to always omit the 'kid context' in the OSCORE
	Option of its messages sent to the Initiator when protecting those		option of its messages sent to the Initiator when protecting those
	with an OSCORE Security Context where C_I is the Responder's OSCORE		with an OSCORE Security Context where C_I is the Responder's OSCORE
	Sender ID (see Section 6.1 of [RFC8613]).		Sender ID (see Section 6.1 of [RFC8613]).
	4.1.2. Responder Processing of Message 2		4.1.2. Responder Processing of Message 2
	The Responder selects an EDHOC Connection Identifier C_R as follows.		The Responder selects an EDHOC connection identifier C_R as follows.
	The Responder MUST choose a C_R that is none of the following:		The Responder MUST choose a C_R that is none of the following:
	* used in any current EDHOC session as this peer's EDHOC Connection		* used in any current EDHOC session as this peer's EDHOC connection
	Identifier,		identifier,
	* equal to the EDHOC Connection Identifier C_I specified in the		* equal to the EDHOC connection identifier C_I specified in the
	EDHOC message_1 of the present EDHOC session, or		EDHOC message_1 of the present EDHOC session, or
	* the Recipient ID in a current OSCORE Security Context where the ID		* the Recipient ID in a current OSCORE Security Context where the ID
	Context is not present.		Context is not present.
	The chosen C_R SHOULD NOT be the Recipient ID of any current OSCORE		The chosen C_R SHOULD NOT be the Recipient ID of any current OSCORE
	Security Context. Note that, for a reason analogous to the one given		Security Context. Note that, for a reason analogous to the one given
	above with C_I, this allows the Initiator to always omit the 'kid		in Section 4.1.1 with C_I, this allows the Initiator to always omit
	context' in the OSCORE Option of its messages sent to the Responder		the 'kid context' in the OSCORE option of its messages sent to the
	when protecting those with an OSCORE Security Context where C_R is		Responder when protecting those with an OSCORE Security Context where
	the Initiator's OSCORE Sender ID (see Section 6.1 of [RFC8613]).		C_R is the Initiator's OSCORE Sender ID (see Section 6.1 of
			[RFC8613]).
	4.1.3. Initiator Processing of Message 2		4.1.3. Initiator Processing of Message 2
	If the EDHOC Connection Identifier C_I is equal to the EDHOC		If the EDHOC connection identifier C_I is equal to the EDHOC
	Connection Identifier C_R specified in EDHOC message_2, then the		connection identifier C_R specified in EDHOC message_2, then the
	Initiator MUST abort the session and reply with an EDHOC error		Initiator MUST abort the session and reply with an EDHOC error
	message with error code 1 formatted as defined in Section 6.2 of		message with error code 1 formatted as defined in Section 6.2 of
	[RFC9528].		[RFC9528].
	5. Extension and Consistency of Application Profiles		5. Extension and Consistency of Application Profiles
	It is possible to include the information below in the application		It is possible to include the information below in the application
	profile referred by the client and server according to the specified		profile referred by the client and server according to the specified
	consistency rules.		consistency rules.
	If the server supports the EDHOC + OSCORE request within an EDHOC		If the server supports the EDHOC + OSCORE request within an EDHOC
	execution started at a certain EDHOC resource, then the application		execution started at a certain EDHOC resource, then the application
	profile associated with that resource SHOULD explicitly specify		profile associated with that resource SHOULD explicitly specify
	support for the EDHOC + OSCORE request.		support for the EDHOC + OSCORE request.
	In the case where the application profile indicates that the server		In the case where the application profile indicates that the server
	supports the optional EDHOC message_4 (see Section 5.5 of [RFC9528]),		supports the optional EDHOC message_4 (see Section 5.5 of [RFC9528]),
	it is still possible to use the optimized workflow based on the EDHOC		it is still possible to use the optimized workflow based on the EDHOC
	+ OSCORE request. However, this means the server is not going to		+ OSCORE request. However, this means that the server is not going
	send EDHOC message_4 since it is not applicable to the optimized		to send EDHOC message_4 since it is not applicable to the optimized
	workflow (see Section 3.3.1).		workflow (see Section 3.3.1).
	Also, in the case where the application profile indicates that the		Also, in the case where the application profile indicates that the
	server shall send EDHOC message_4, the application profile MUST NOT		server shall send EDHOC message_4, the application profile MUST NOT
	specify support for the EDHOC + OSCORE request. There is no point		specify support for the EDHOC + OSCORE request. There is no point
	for the client to use the optimized workflow that is bound to fail		for the client to use the optimized workflow that is bound to fail
	(see Section 3.3.1).		(see Section 3.3.1).
	6. Web Linking		6. Web Linking
	skipping to change at line 791 ¶		skipping to change at line 795 ¶
	That is, while discovering an EDHOC resource, a client can		That is, while discovering an EDHOC resource, a client can
	contextually obtain relevant pieces of information from the		contextually obtain relevant pieces of information from the
	application profile associated with that resource. The resource		application profile associated with that resource. The resource
	discovery can occur by means of a direct interaction with the server		discovery can occur by means of a direct interaction with the server
	or by means of the CoRE Resource Directory [RFC9176] where the server		or by means of the CoRE Resource Directory [RFC9176] where the server
	may have registered the links to its resources.		may have registered the links to its resources.
	In order to enable the above, this section defines a number of		In order to enable the above, this section defines a number of
	parameters, each of which can be optionally specified as a target		parameters, each of which can be optionally specified as a target
	attribute with the same name in the link to the respective EDHOC		attribute with the same name in the link to the respective EDHOC
	resource or as filter criteria in a discovery request from the		resource or as filter criterion in a discovery request from the
	client. When specifying these parameters in a link to an EDHOC		client. When specifying these parameters in a link to an EDHOC
	resource, the target attribute rt="core.edhoc" MUST be included and		resource, the target attribute rt="core.edhoc" MUST be included and
	the same consistency rules defined in Section 5 for the corresponding		the same consistency rules defined in Section 5 for the corresponding
	information elements of an application profile MUST be followed.		information elements of an application profile MUST be followed.
	The following parameters are defined.		The following parameters are defined.
	'ed-i': If present, specifies that the server supports the EDHOC		'ed-i': If present, specifies that the server supports the EDHOC
	Initiator role, hence the reverse message flow of EDHOC. A value		Initiator role, hence the reverse message flow of EDHOC. A value
	MUST NOT be given to this parameter and any present value MUST be		MUST NOT be given to this parameter and any present value MUST be
	skipping to change at line 839 ¶		skipping to change at line 843 ¶
	'ed-idcred-t': Specifies a type of identifier supported by the		'ed-idcred-t': Specifies a type of identifier supported by the
	server for identifying authentication credentials. This parameter		server for identifying authentication credentials. This parameter
	MUST specify a single value, which is taken from the 'Label'		MUST specify a single value, which is taken from the 'Label'
	column of the "COSE Header Parameters" registry		column of the "COSE Header Parameters" registry
	[COSE.Header.Parameters]. This parameter MAY occur multiple		[COSE.Header.Parameters]. This parameter MAY occur multiple
	times, with each occurrence specifying a type of identifier for		times, with each occurrence specifying a type of identifier for
	authentication credentials.		authentication credentials.
	Note that the values in the 'Label' column of the "COSE Header		Note that the values in the 'Label' column of the "COSE Header
	Parameters" registry are strongly typed. On the contrary, Link		Parameters" registry are strongly typed. On the contrary, CoRE
	Format is weakly typed; thus, it does not distinguish between, for		Link Format is weakly typed; thus, it does not distinguish
	instance, the string value -10 and the integer value -10.		between, for instance, the string value "-10" and the integer
	Therefore, if responses in Link Format are returned, string values		value -10. Therefore, if responses in CoRE Link Format are
	that look like an integer are not supported. Thus, such values		returned, string values that look like an integer are not
	MUST NOT be used in the 'ed-idcred-t' parameter.		supported. Thus, such values MUST NOT be used in the 'ed-idcred-
			t' parameter.
	'ed-ead': Specifies the support of the server for an External		'ed-ead': Specifies the support of the server for an External
	Authorization Data (EAD) item (see Section 3.8 of [RFC9528]).		Authorization Data (EAD) item (see Section 3.8 of [RFC9528]).
	This parameter MUST specify a single value, which is taken from		This parameter MUST specify a single value, which is taken from
	the 'Label' column of the "EDHOC External Authorization Data"		the 'Label' column of the "EDHOC External Authorization Data"
	registry defined in Section 10.5 of [RFC9528]. This parameter MAY		registry defined in Section 10.5 of [RFC9528]. This parameter MAY
	occur multiple times, with each occurrence specifying the		occur multiple times, with each occurrence specifying the
	'ead_label' of an EAD item that the server supports.		ead_label of an EAD item that the server supports.
	'ed-comb-req': If present, specifies that the server supports the		'ed-comb-req': If present, specifies that the server supports the
	EDHOC + OSCORE request defined in Section 3. A value MUST NOT be		EDHOC + OSCORE request defined in Section 3. A value MUST NOT be
	given to this parameter and any present value MUST be ignored by		given to this parameter and any present value MUST be ignored by
	the recipient.		the recipient.
	Future documents may update the definition of the parameters 'ed-i',		Future documents may update the definition of the parameters 'ed-i',
	'ed-r', and 'ed-comb-req' by expanding their semantics and specifying		'ed-r', and 'ed-comb-req' by expanding their semantics and specifying
	what they can take as value.		what they can take as value.
	The example in Figure 5 shows how a client discovers one EDHOC		The example in Figure 5 shows how a client discovers one EDHOC
	resource at a server and obtains information elements from the		resource at a server and obtains information elements from the
	respective application profile. The Link-Format notation from		respective application profile. The CoRE Link Format notation from
	Section 5 of [RFC6690] is used.		Section 5 of [RFC6690] is used.
	REQ: GET /.well-known/core		REQ: GET /.well-known/core
	RES: 2.05 Content		RES: 2.05 Content
	</sensors/temp>;osc,		</sensors/temp>;osc,
	</sensors/light>;if=sensor,		</sensors/light>;if=sensor,
	</.well-known/edhoc>;rt=core.edhoc;ed-csuite=0;ed-csuite=2;		</.well-known/edhoc>;rt=core.edhoc;ed-csuite=0;ed-csuite=2;
	ed-method=0;ed-cred-t=1;ed-cred-t=3;ed-idcred-t=4;		ed-method=0;ed-cred-t=0;ed-cred-t=1;ed-idcred-t=4;
	ed-i;ed-r;ed-comb-req		ed-i;ed-r;ed-comb-req
	Figure 5: The Web Link		Figure 5: The Web Link
	7. Security Considerations		7. Security Considerations
	The same security considerations from OSCORE [RFC8613] and EDHOC		The same security considerations from OSCORE [RFC8613] and EDHOC
	[RFC9528] hold for this document. In addition, the following		[RFC9528] hold for this document. In addition, the following
	considerations also apply.		considerations apply.
	Section 3.2.1 specifies that a client SHOULD NOT have multiple		Section 3.2.1 specifies that a client SHOULD NOT have multiple
	outstanding EDHOC + OSCORE requests pertaining to the same EDHOC		outstanding EDHOC + OSCORE requests pertaining to the same EDHOC
	session. Even if a client did not fulfill this requirement, it would		session. Even if a client did not fulfill this requirement, it would
	not have any impact in terms of security. That is, the server would		not have any impact in terms of security. That is, the server would
	still not process different instances of the same EDHOC message_3		still not process different instances of the same EDHOC message_3
	more than once in the same EDHOC session (see Section 5.1 of		more than once in the same EDHOC session (see Section 5.1 of
	[RFC9528]) and would still enforce replay protection of the OSCORE-		[RFC9528]) and would still enforce replay protection of the OSCORE-
	protected request (see Sections 7.4 and 8.2 of [RFC8613]).		protected request (see Sections 7.4 and 8.2 of [RFC8613]).
	skipping to change at line 931 ¶		skipping to change at line 936 ¶
	That is, the rebuilt OSCORE-protected application request from Step 7		That is, the rebuilt OSCORE-protected application request from Step 7
	in Section 3.3.1 MUST undergo the same access-control checks that		in Section 3.3.1 MUST undergo the same access-control checks that
	would be performed on a traditional OSCORE-protected application		would be performed on a traditional OSCORE-protected application
	request sent individually as shown in Figure 1.		request sent individually as shown in Figure 1.
	To this end, validated information to perform access-control checks		To this end, validated information to perform access-control checks
	(e.g., an access token issued by a trusted party) has to be available		(e.g., an access token issued by a trusted party) has to be available
	at the server before starting to process the rebuilt OSCORE-protected		at the server before starting to process the rebuilt OSCORE-protected
	application request. Such information may have been provided to the		application request. Such information may have been provided to the
	server separately before starting the EDHOC execution altogether, or		server separately before starting the EDHOC execution altogether, or
	instead, as External Authorization Data during the EDHOC execution		instead as External Authorization Data during the EDHOC execution
	(see Section 3.8 of [RFC9528]).		(see Section 3.8 of [RFC9528]).
	Thus, a successful completion of the EDHOC protocol and the following		Thus, a successful completion of the EDHOC protocol and the following
	derivation of the OSCORE Security Context at the server do not play a		derivation of the OSCORE Security Context at the server do not play a
	role in determining whether the rebuilt OSCORE-protected request is		role in determining whether the rebuilt OSCORE-protected request is
	authorized to access the target protected resource at the server.		authorized to access the target protected resource at the server.
	8. IANA Considerations		8. IANA Considerations
	This document has the following actions for IANA.		This document has the following actions for IANA.
	skipping to change at line 965 ¶		skipping to change at line 970 ¶
	Table 2: Registration in		Table 2: Registration in
	the "CoAP Option Numbers"		the "CoAP Option Numbers"
	Registry		Registry
	8.2. Target Attributes Registry		8.2. Target Attributes Registry
	IANA has registered the following entries in the "Target Attributes"		IANA has registered the following entries in the "Target Attributes"
	registry [CORE.Target.Attributes] within the "Constrained RESTful		registry [CORE.Target.Attributes] within the "Constrained RESTful
	Environments (CoRE) Parameters" registry group as per [RFC9423]. For		Environments (CoRE) Parameters" registry group as per [RFC9423]. For
	all entries, the Change Controller is "IETF" and the reference is		all entries, the Change Controller is "IETF" and the reference is
	"RFC 9668".		"[RFC 9668]".
	+================+=============================================+		+================+=============================================+
	| Attribute Name | Brief Description |		| Attribute Name | Brief Description |
	+================+=============================================+		+================+=============================================+
	| ed-i | Hint: support for the EDHOC Initiator role |		| ed-i | Hint: support for the EDHOC Initiator role |
	+----------------+---------------------------------------------+		+----------------+---------------------------------------------+
	| ed-r | Hint: support for the EDHOC Responder role |		| ed-r | Hint: support for the EDHOC Responder role |
	+----------------+---------------------------------------------+		+----------------+---------------------------------------------+
	| ed-method | A supported authentication method for EDHOC |		| ed-method | A supported authentication method for EDHOC |
	+----------------+---------------------------------------------+		+----------------+---------------------------------------------+
	skipping to change at line 999 ¶		skipping to change at line 1004 ¶
	+----------------+---------------------------------------------+		+----------------+---------------------------------------------+
	Table 3: Registrations in the "Target Attributes" Registry		Table 3: Registrations in the "Target Attributes" Registry
	8.3. EDHOC Authentication Credential Types Registry		8.3. EDHOC Authentication Credential Types Registry
	IANA has created the "EDHOC Authentication Credential Types" registry		IANA has created the "EDHOC Authentication Credential Types" registry
	within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry		within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry
	group defined in [RFC9528].		group defined in [RFC9528].
	The registration policy is either "Standards Action with Expert		The registration policy is either "Private Use", "Standards Action
	Review" or "Specification Required" per [RFC8126]. "Expert Review"		with Expert Review", or "Specification Required" per [RFC8126].
	guidelines are provided in Section 8.4.		"Expert Review" guidelines are provided in Section 8.4.
	All assignments according to "Standards Action with Expert Review"		All assignments according to "Standards Action with Expert Review"
	are made on a "Standards Action" basis per Section 4.9 of [RFC8126]		are made on a "Standards Action" basis per Section 4.9 of [RFC8126]
	with "Expert Review" additionally required per Section 4.5 of		with "Expert Review" additionally required per Section 4.5 of
	[RFC8126]. The procedure for early IANA allocation of "standards		[RFC8126]. The procedure for early IANA allocation of "standards
	track code points" defined in [RFC7120] also applies. When such a		track code points" defined in [RFC7120] also applies. When such a
	procedure is used, review and approval by the designated expert are		procedure is used, IANA will ask the designated expert(s) to approve
	also required in order for the working group chairs to determine that		the early allocation before registration. In addition, working group
	the conditions for early allocation are met (see Step 2 in		chairs are encouraged to consult the expert(s) early during the
	Section 3.1 of [RFC7120]).		process outlined in Section 3.1 of [RFC7120].
	The columns of this registry are:		The columns of this registry are:
	Value: This field contains the value used to identify the type of		Value: This field contains the value used to identify the type of
	authentication credential. These values MUST be unique. The		authentication credential. These values MUST be unique. The
	value can be an unsigned integer or a negative integer in the		value can be an unsigned integer or a negative integer. Different
	range from -65536 to 65535. Different ranges of values use		ranges of values use different registration policies:
	different registration policies:
	* Integer values from -24 to 23 are designated as "Standards		* Integer values from -24 to 23 are designated as "Standards
	Action With Expert Review".		Action With Expert Review".
	* Integer values from -65536 to -25 and from 24 to 65535 are		* Integer values from -65536 to -25 and from 24 to 65535 are
	designated as "Specification Required".		designated as "Specification Required".
	* Integer values smaller than -65536 and greater than 65535 are		* Integer values smaller than -65536 and greater than 65535 are
	marked as "Private Use".		marked as "Private Use".
	skipping to change at line 1055 ¶		skipping to change at line 1059 ¶
	| | claims. CCS is defined in RFC 8392. | |		| | claims. CCS is defined in RFC 8392. | |
	+-------+--------------------------------------------+-----------+		+-------+--------------------------------------------+-----------+
	| 2 | X.509 certificate | [RFC5280] |		| 2 | X.509 certificate | [RFC5280] |
	+-------+--------------------------------------------+-----------+		+-------+--------------------------------------------+-----------+
	Table 4: Initial Entries in the "EDHOC Authentication		Table 4: Initial Entries in the "EDHOC Authentication
	Credential Types" Registry		Credential Types" Registry
	8.4. Expert Review Instructions		8.4. Expert Review Instructions
	The IANA registry established in Section 8.3 is defined as using		"Standards Action with Expert Review" and "Specification Required"
	"Standards Action with Expert Review" or "Specification Required" as		are two of the registration policies defined for the IANA registry
	a Registration Procedure depending on the range of values for which		established in Section 8.3. This section gives some general
	an assignment is requested. This section gives some general
	guidelines for what the experts should be looking for; however, they		guidelines for what the experts should be looking for; however, they
	are being designated as experts for a reason, so they should be given		are being designated as experts for a reason, so they should be given
	substantial latitude.		substantial latitude.
	Expert reviewers should take into consideration the following points:		Expert reviewers should take into consideration the following points:
	* Clarity and correctness of registrations. Experts are expected to		* Clarity and correctness of registrations. Experts are expected to
	check the clarity of purpose and use of the requested entries.		check the clarity of purpose and use of the requested entries.
	Experts need to make sure that registered identifiers indicate a		Experts need to make sure that registered identifiers indicate a
	type of authentication credential whose format and encoding is		type of authentication credential whose format and encoding is
	skipping to change at line 1090 ¶		skipping to change at line 1093 ¶
	* Specifications are required for the "Standards Action With Expert		* Specifications are required for the "Standards Action With Expert
	Review" range of point assignment. Specifications should exist		Review" range of point assignment. Specifications should exist
	for "Specification Required" ranges, but early assignment before a		for "Specification Required" ranges, but early assignment before a
	specification is available is considered to be permissible. When		specification is available is considered to be permissible. When
	specifications are not provided, the description provided needs to		specifications are not provided, the description provided needs to
	have sufficient information to identify what the point is being		have sufficient information to identify what the point is being
	used for.		used for.
	* Experts should take into account the expected usage of fields when		* Experts should take into account the expected usage of fields when
	approving point assignment. The fact that there is a range for		approving point assignment. Documents published via Standards
	Standards Track documents does not mean that a Standards Track		Action can also register points outside the Standards Action
	document cannot have points assigned outside of that range. The		range. The length of the encoded value should be weighed against
	length of the encoded value should be weighed against how many		how many code points of that length are left, the size of device
	code points of that length are left, the size of device it will be		it will be used on, and the number of code points left that encode
	used on, and the number of code points left that encode to that		to that size.
	size.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[CORE.Target.Attributes]		[CORE.Target.Attributes]
	IANA, "Target Attributes",		IANA, "Target Attributes",
	<https://www.iana.org/assignments/core-parameters>.		<https://www.iana.org/assignments/core-parameters>.
	[COSE.Header.Parameters]		[COSE.Header.Parameters]
	skipping to change at line 1192 ¶		skipping to change at line 1194 ¶
	Acknowledgments		Acknowledgments
	The authors sincerely thank Christian Amsüss, Emmanuel Baccelli,		The authors sincerely thank Christian Amsüss, Emmanuel Baccelli,
	Carsten Bormann, Roman Danyliw, Esko Dijk, Joel Halpern, Wes		Carsten Bormann, Roman Danyliw, Esko Dijk, Joel Halpern, Wes
	Hardaker, Klaus Hartke, John Preuß Mattsson, David Navarro, Shuping		Hardaker, Klaus Hartke, John Preuß Mattsson, David Navarro, Shuping
	Peng, Jim Schaad, Jürgen Schönwälder, John Scudder, Orie Steele,		Peng, Jim Schaad, Jürgen Schönwälder, John Scudder, Orie Steele,
	Gunter Van de Velde, Mališa Vučinić, and Paul Wouters for their		Gunter Van de Velde, Mališa Vučinić, and Paul Wouters for their
	feedback and comments.		feedback and comments.
	The work on this document has been partly supported by VINNOVA and		The work on this document has been partly supported by the Sweden's
	the Celtic-Next project CRITISEC and by the H2020 project SIFIS-Home		Innovation Agency VINNOVA and the Celtic-Next project CRITISEC, and
	(Grant agreement 952652).		by the H2020 project SIFIS-Home (Grant agreement 952652).
	Authors' Addresses		Authors' Addresses
	Francesca Palombini		Francesca Palombini
	Ericsson		Ericsson AB
			Torshamnsgatan 23
			SE-164 40 Kista
			Sweden
	Email: francesca.palombini@ericsson.com		Email: francesca.palombini@ericsson.com
	Marco Tiloca		Marco Tiloca
	RISE AB		RISE AB
	Isafjordsgatan 22		Isafjordsgatan 22
	SE-16440 Stockholm Kista		SE-164 40 Kista
	Sweden		Sweden
	Email: marco.tiloca@ri.se		Email: marco.tiloca@ri.se
	Rikard Höglund		Rikard Höglund
	RISE AB		RISE AB
	Isafjordsgatan 22		Isafjordsgatan 22
	SE-16440 Stockholm Kista		SE-16440 Stockholm Kista
	Sweden		Sweden
	Email: rikard.hoglund@ri.se		Email: rikard.hoglund@ri.se
End of changes. 62 change blocks.
	142 lines changed or deleted		147 lines changed or added
This html diff was produced by rfcdiff 1.48.