draft-ietf-lake-edhoc-02.txt		draft-ietf-lake-edhoc-03.txt
	Network Working Group G. Selander		Network Working Group G. Selander
	Internet-Draft J. Mattsson		Internet-Draft J. Mattsson
	Intended status: Standards Track F. Palombini		Intended status: Standards Track F. Palombini
	Expires: May 6, 2021 Ericsson AB		Expires: June 21, 2021 Ericsson AB
	November 02, 2020		December 18, 2020
	Ephemeral Diffie-Hellman Over COSE (EDHOC)		Ephemeral Diffie-Hellman Over COSE (EDHOC)
	draft-ietf-lake-edhoc-02		draft-ietf-lake-edhoc-03
	Abstract		Abstract
	This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a		This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
	very compact, and lightweight authenticated Diffie-Hellman key		very compact, and lightweight authenticated Diffie-Hellman key
	exchange with ephemeral keys. EDHOC provides mutual authentication,		exchange with ephemeral keys. EDHOC provides mutual authentication,
	perfect forward secrecy, and identity protection. EDHOC is intended		perfect forward secrecy, and identity protection. EDHOC is intended
	for usage in constrained scenarios and a main use case is to		for usage in constrained scenarios and a main use case is to
	establish an OSCORE security context. By reusing COSE for		establish an OSCORE security context. By reusing COSE for
	cryptography, CBOR for encoding, and CoAP for transport, the		cryptography, CBOR for encoding, and CoAP for transport, the
	additional code footprint can be kept very low.		additional code size can be kept very low.
	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 https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 6, 2021.		This Internet-Draft will expire on June 21, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Rationale for EDHOC . . . . . . . . . . . . . . . . . . . 4		1.1. Rationale for EDHOC . . . . . . . . . . . . . . . . . . . 5
	1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Use of EDHOC . . . . . . . . . . . . . . . . . . . . . . 6
	1.3. Terminology and Requirements Language . . . . . . . . . . 6		1.3. Terminology and Requirements Language . . . . . . . . . . 6
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. EDHOC Outline . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 8		3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Transport and Message Correlation . . . . . . . . . . . . 9		3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Authentication Keys and Identities . . . . . . . . . . . 10		3.2. Method and Correlation . . . . . . . . . . . . . . . . . 9
	3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 11		3.3. Authentication Parameters . . . . . . . . . . . . . . . . 11
	3.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 11		3.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 14
	3.5. Communication/Negotiation of Protocol Features . . . . . 12		3.5. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 16
	3.6. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 13		3.6. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 16
	3.7. Ephemeral Public Keys . . . . . . . . . . . . . . . . . . 13		3.7. Communication of Protocol Features . . . . . . . . . . . 17
	3.8. Key Derivation . . . . . . . . . . . . . . . . . . . . . 13		4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 17
	4. EDHOC Authenticated with Asymmetric Keys . . . . . . . . . . 16		4.1. EDHOC-Exporter Interface . . . . . . . . . . . . . . . . 19
	4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16		5. Message Formatting and Processing . . . . . . . . . . . . . . 20
	4.2. Encoding of Public Authentication Key Identifiers . . . . 16		5.1. Encoding of bstr_identifier . . . . . . . . . . . . . . . 20
	4.3. Encoding of bstr_identifier . . . . . . . . . . . . . . . 18		5.2. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 21
	4.4. EDHOC Message 1 . . . . . . . . . . . . . . . . . . . . . 18		5.3. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 23
	4.5. EDHOC Message 2 . . . . . . . . . . . . . . . . . . . . . 20		5.4. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 26
	4.6. EDHOC Message 3 . . . . . . . . . . . . . . . . . . . . . 23		6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 29
	5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 27		6.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 29
	5.1. EDHOC Error Message . . . . . . . . . . . . . . . . . . . 27		7. Transferring EDHOC and Deriving an OSCORE Context . . . . . . 32
	6. Transferring EDHOC and Deriving an OSCORE Context . . . . . . 29		7.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 32
	6.1. Transferring EDHOC in CoAP . . . . . . . . . . . . . . . 29		8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 32		8.1. Security Properties . . . . . . . . . . . . . . . . . . . 35
	7.1. Security Properties . . . . . . . . . . . . . . . . . . . 32		8.2. Cryptographic Considerations . . . . . . . . . . . . . . 36
	7.2. Cryptographic Considerations . . . . . . . . . . . . . . 33		8.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 37
	7.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 34		8.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 37
	7.4. Unprotected Data . . . . . . . . . . . . . . . . . . . . 34		8.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 38
	7.5. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 35		8.6. Implementation Considerations . . . . . . . . . . . . . . 38
	7.6. Implementation Considerations . . . . . . . . . . . . . . 35		8.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 39
	7.7. Other Documents Referencing EDHOC . . . . . . . . . . . . 36		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36		9.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 39
	8.1. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 36		9.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 41
	8.2. EDHOC Method Type Registry . . . . . . . . . . . . . . . 37		9.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 41
	8.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 37		9.4. Media Types Registry . . . . . . . . . . . . . . . . . . 41
	8.4. Media Types Registry . . . . . . . . . . . . . . . . . . 38		9.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 42
	8.5. CoAP Content-Formats Registry . . . . . . . . . . . . . . 39		9.6. Expert Review Instructions . . . . . . . . . . . . . . . 42
	8.6. Expert Review Instructions . . . . . . . . . . . . . . . 39		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39		10.1. Normative References . . . . . . . . . . . . . . . . . . 43
	9.1. Normative References . . . . . . . . . . . . . . . . . . 39		10.2. Informative References . . . . . . . . . . . . . . . . . 45
	9.2. Informative References . . . . . . . . . . . . . . . . . 41		Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 47
	Appendix A. Use of CBOR, CDDL and COSE in EDHOC . . . . . . . . 44		A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 47
	A.1. CBOR and CDDL . . . . . . . . . . . . . . . . . . . . . . 44		A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 48
	A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 45		Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 48
	Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 45
	B.1. Test Vectors for EDHOC Authenticated with Signature Keys		B.1. Test Vectors for EDHOC Authenticated with Signature Keys
	(x5t) . . . . . . . . . . . . . . . . . . . . . . . . . . 45		(x5t) . . . . . . . . . . . . . . . . . . . . . . . . . . 48
	B.2. Test Vectors for EDHOC Authenticated with Static Diffie-		B.2. Test Vectors for EDHOC Authenticated with Static Diffie-
	Hellman Keys . . . . . . . . . . . . . . . . . . . . . . 60		Hellman Keys . . . . . . . . . . . . . . . . . . . . . . 63
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 73		Appendix C. Applicability Statement Template . . . . . . . . . . 76
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73		C.1. Use of EDHOC in the XX Protocol . . . . . . . . . . . . . 76
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 77
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
	1. Introduction		1. Introduction
	Security at the application layer provides an attractive option for		Security at the application layer provides an attractive option for
	protecting Internet of Things (IoT) deployments, for example where		protecting Internet of Things (IoT) deployments, for example where
	protection needs to work over a variety of underlying protocols. IoT		protection needs to work over a variety of underlying protocols. IoT
	devices may be constrained in various ways, including memory,		devices may be constrained in various ways, including memory,
	storage, processing capacity, and energy [RFC7228]. A method for		storage, processing capacity, and energy [RFC7228]. A method for
	protecting individual messages at the application layer suitable for		protecting individual messages at the application layer suitable for
	constrained devices, is provided by CBOR Object Signing and		constrained devices, is provided by CBOR Object Signing and
	Encryption (COSE) [RFC8152]), which builds on the Concise Binary		Encryption (COSE) [RFC8152]), which builds on the Concise Binary
	Object Representation (CBOR) [RFC7049]. Object Security for		Object Representation (CBOR) [RFC8949]. Object Security for
	Constrained RESTful Environments (OSCORE) [RFC8613] is a method for		Constrained RESTful Environments (OSCORE) [RFC8613] is a method for
	application-layer protection of the Constrained Application Protocol		application-layer protection of the Constrained Application Protocol
	(CoAP), using COSE.		(CoAP), using COSE.
	In order for a communication session to provide forward secrecy, the		In order for a communication session to provide forward secrecy, the
	communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH)		communicating parties can run an Elliptic Curve Diffie-Hellman (ECDH)
	key exchange protocol with ephemeral keys, from which shared key		key exchange protocol with ephemeral keys, from which shared key
	material can be derived. This document specifies Ephemeral Diffie-		material can be derived. This document specifies Ephemeral Diffie-
	Hellman Over COSE (EDHOC), a lightweight key exchange protocol		Hellman Over COSE (EDHOC), a lightweight key exchange protocol
	providing perfect forward secrecy and identity protection.		providing perfect forward secrecy and identity protection.
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 35 ¶
	message_1 37 37		message_1 37 37
	message_2 46 117		message_2 46 117
	message_3 20 91		message_3 20 91
	----------------------------------		----------------------------------
	Total 103 245		Total 103 245
	=================================		=================================
	Figure 1: Example of message sizes in bytes.		Figure 1: Example of message sizes in bytes.
	The ECDH exchange and the key derivation follow known protocol		The ECDH exchange and the key derivation follow known protocol
	constructions such as [SIGMA], NIST SP-800-56A [SP-800-56A], and HKDF		constructions such as [SIGMA], NIST SP-800-56A [SP-800-56A], and
	[RFC5869]. CBOR [RFC7049] and COSE [RFC8152] are used to implement		Extract-and-Expand [RFC5869]. CBOR [RFC8949] and COSE [RFC8152] are
	these standards. The use of COSE provides crypto agility and enables		used to implement these standards. The use of COSE provides crypto
	use of future algorithms and headers designed for constrained IoT.		agility and enables use of future algorithms and headers designed for
			constrained IoT.
	This document is organized as follows: Section 2 describes how EDHOC		This document is organized as follows: Section 2 describes how EDHOC
	authenticated with digital signatures builds on SIGMA-I, Section 3		authenticated with digital signatures builds on SIGMA-I, Section 3
	specifies general properties of EDHOC, including message flow,		specifies general properties of EDHOC, including message flow and
	formatting of the ephemeral public keys, and key derivation,		formatting of the ephemeral public keys, Section 4 specifies the key
	Section 4 specifies EDHOC with signature key and static Diffie-		derivation, Section 5 specifies EDHOC with signature key and static
	Hellman key authentication, Section 5 specifies the EDHOC error		Diffie-Hellman key authentication, Section 6 specifies the EDHOC
	message, and Section 6 describes how EDHOC can be transferred in CoAP		error message, and Section 7 describes how EDHOC can be transferred
	and used to establish an OSCORE security context.		in CoAP and used to establish an OSCORE security context.
	1.1. Rationale for EDHOC		1.1. Rationale for EDHOC
	Many constrained IoT systems today do not use any security at all,		Many constrained IoT systems today do not use any security at all,
	and when they do, they often do not follow best practices. One		and when they do, they often do not follow best practices. One
	reason is that many current security protocols are not designed with		reason is that many current security protocols are not designed with
	constrained IoT in mind. Constrained IoT systems often deal with		constrained IoT in mind. Constrained IoT systems often deal with
	personal information, valuable business data, and actuators		personal information, valuable business data, and actuators
	interacting with the physical world. Not only do such systems need		interacting with the physical world. Not only do such systems need
	security and privacy, they often need end-to-end protection with		security and privacy, they often need end-to-end protection with
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 24 ¶
	A typical setting is when one of the endpoints is constrained or in a		A typical setting is when one of the endpoints is constrained or in a
	constrained network, and the other endpoint is a node on the Internet		constrained network, and the other endpoint is a node on the Internet
	(such as a mobile phone) or at the edge of the constrained network		(such as a mobile phone) or at the edge of the constrained network
	(such as a gateway). Thing-to-thing interactions over constrained		(such as a gateway). Thing-to-thing interactions over constrained
	networks are also relevant since both endpoints would then benefit		networks are also relevant since both endpoints would then benefit
	from the lightweight properties of the protocol. EDHOC could e.g. be		from the lightweight properties of the protocol. EDHOC could e.g. be
	run when a device/device(s) connect(s) for the first time, or to		run when a device/device(s) connect(s) for the first time, or to
	establish fresh keys which are not compromised by a later compromise		establish fresh keys which are not compromised by a later compromise
	of the long-term keys. (Further security properties are described in		of the long-term keys. (Further security properties are described in
	Section 7.1.)		Section 8.1.)
	1.3. Terminology and Requirements Language		1.3. Terminology and Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Readers are expected to be familiar with the terms and concepts		Readers are expected to be familiar with the terms and concepts
	described in CBOR [RFC7049], CBOR Sequences [RFC8742], COSE		described in CBOR [RFC8949], CBOR Sequences [RFC8742], COSE
	[RFC8152], and CDDL [RFC8610]. The Concise Data Definition Language		[RFC8152], and CDDL [RFC8610]. The Concise Data Definition Language
	(CDDL) is used to express CBOR data structures [RFC7049]. Examples		(CDDL) is used to express CBOR data structures [RFC8949]. Examples
	of CBOR and CDDL are provided in Appendix A.1.		of CBOR and CDDL are provided in Appendix A.1.
	2. Background		2. EDHOC Outline
	EDHOC specifies different authentication methods of the Diffie-		EDHOC specifies different authentication methods of the Diffie-
	Hellman key exchange: digital signatures and static Diffie-Hellman		Hellman key exchange: digital signatures and static Diffie-Hellman
	keys. This section outlines the digital signature based method.		keys. This section outlines the digital signature based method.
			Further details of protocol elements and other authentication methods
			are provided in the remainder of this document.
	SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a		SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
	large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS		large number of variants [SIGMA]. Like IKEv2 [RFC7296] and (D)TLS
	1.3 [RFC8446], EDHOC authenticated with digital signatures is built		1.3 [RFC8446], EDHOC authenticated with digital signatures is built
	on a variant of the SIGMA protocol which provide identity protection		on a variant of the SIGMA protocol which provide identity protection
	of the initiator (SIGMA-I), and like IKEv2 [RFC7296], EDHOC		of the initiator (SIGMA-I), and like IKEv2 [RFC7296], EDHOC
	implements the SIGMA-I variant as Mac-then-Sign. The SIGMA-I		implements the SIGMA-I variant as MAC-then-Sign. The SIGMA-I
	protocol using an authenticated encryption algorithm is shown in		protocol using an authenticated encryption algorithm is shown in
	Figure 2.		Figure 2.
	Initiator Responder		Initiator Responder
	| G_X |		| G_X |
	+-------------------------------------------------------->|		+-------------------------------------------------------->|
	| |		| |
	| G_Y, AEAD( K_2; ID_CRED_R, Sig(R; CRED_R, G_X, G_Y) ) |		| G_Y, AEAD( K_2; ID_CRED_R, Sig(R; CRED_R, G_X, G_Y) ) |
	|<--------------------------------------------------------+		|<--------------------------------------------------------+
	| |		| |
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 24 ¶
	o Transport of opaque auxiliary data.		o Transport of opaque auxiliary data.
	EDHOC is designed to encrypt and integrity protect as much		EDHOC is designed to encrypt and integrity protect as much
	information as possible, and all symmetric keys are derived using as		information as possible, and all symmetric keys are derived using as
	much previous information as possible. EDHOC is furthermore designed		much previous information as possible. EDHOC is furthermore designed
	to be as compact and lightweight as possible, in terms of message		to be as compact and lightweight as possible, in terms of message
	sizes, processing, and the ability to reuse already existing CBOR,		sizes, processing, and the ability to reuse already existing CBOR,
	COSE, and CoAP libraries.		COSE, and CoAP libraries.
	To simplify for implementors, the use of CBOR in EDHOC is summarized		To simplify for implementors, the use of CBOR and COSE in EDHOC is
	in Appendix A and test vectors including CBOR diagnostic notation are		summarized in Appendix A and test vectors including CBOR diagnostic
	given in Appendix B.		notation are given in Appendix B.
	3. EDHOC Overview		3. Protocol Elements
			3.1. General
	EDHOC consists of three messages (message_1, message_2, message_3)		EDHOC consists of three messages (message_1, message_2, message_3)
	that maps directly to the three messages in SIGMA-I, plus an EDHOC		between Initiator and Responder, plus an EDHOC error message. EDHOC
	error message. EDHOC messages are CBOR Sequences [RFC8742], where		messages are CBOR Sequences [RFC8742], see Figure 3. The protocol
	the first data item (METHOD_CORR) of message_1 is an int specifying		elements in the figure are introduced in the following sections.
	the method and the correlation properties of the transport used, see		Message formatting and processing is specified in Section 5 and
	Section 3.1. The method specifies the authentication methods used		Section 6. An implementation may support only Initiator or only
	(signature, static DH), see Section 8.2. An implementation may		Responder.
	support only Initiator or Responder. An implementation may support
	only a single method. The Initiator and the Responder need to have
	agreed on a single method to be used for EDHOC.
	While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0		Application data is protected using the agreed application algorithms
	structures, only a subset of the parameters is included in the EDHOC		(AEAD, hash) in the selected cipher suite (see Section 3.4) and the
	messages. The unprotected COSE header in COSE_Sign1, and		application can make use of the established connection identifiers
	COSE_Encrypt0 (not included in the EDHOC message) MAY contain		C_I and C_R (see Section 3.2.4). EDHOC may be used with the media
	parameters (e.g. 'alg'). After creating EDHOC message_3, the		type application/edhoc defined in Section 9.
	Initiator can derive symmetric application keys, and application
	protected data can therefore be sent in parallel with EDHOC
	message_3. The application may protect data using the algorithms
	(AEAD, hash, etc.) in the selected cipher suite and the connection
	identifiers (C_I, C_R). EDHOC may be used with the media type
	application/edhoc defined in Section 8.
	Initiator Responder		The Initiator can derive symmetric application keys after creating
	| |		EDHOC message_3, see Section 4.1. Application protected data can
	| ------------------ EDHOC message_1 -----------------> |		therefore be sent in parallel with EDHOC message_3, optionally in the
	| |		same CoAP message [I-D.palombini-core-oscore-edhoc].
	| <----------------- EDHOC message_2 ------------------ |
	| |
	| ------------------ EDHOC message_3 -----------------> |
	| |
	| <----------- Application Protected Data ------------> |
	| |
	Figure 3: EDHOC message flow		Initiator Responder
			| METHOD_CORR, SUITES_I, G_X, C_I, AD_1 |
			+------------------------------------------------------------------>|
			| message_1 |
			| |
			| C_I, G_Y, C_R, Enc(K_2e; ID_CRED_R, Signature_or_MAC_2, AD_2) |
			|<------------------------------------------------------------------+
			| message_2 |
			| |
			| C_R, AEAD(K_3ae; ID_CRED_I, Signature_or_MAC_3, AD_3) |
			+------------------------------------------------------------------>|
			| message_3 |
	3.1. Transport and Message Correlation		Figure 3: EDHOC Message Flow
	Cryptographically, EDHOC does not put requirements on the lower		3.2. Method and Correlation
	layers. EDHOC is not bound to a particular transport layer, and can
	be used in environments without IP. The transport is responsible to		The first data item of message_1, METHOD_CORR (see Section 5.2.1), is
	handle message loss, reordering, message duplication, fragmentation,		an integer specifying the method and the correlation properties of
	and denial of service protection, where necessary. The Initiator and		the transport, which are described in this section.
	the Responder need to have agreed on a transport to be used for
	EDHOC. It is recommended to transport EDHOC in CoAP payloads, see		3.2.1. Method
	Section 6.
			EDHOC supports authentication with signature or static Diffie-Hellman
			keys, as defined in the four authentication methods: 0, 1, 2, and 3,
			see Figure 4. (Method 0 corresponds to the case outlined in
			Section 2 where both Initiator and Responder authenticate with
			signature keys.)
			An implementation may support only a single method. The Initiator
			and the Responder need to have agreed on a single method to be used
			for EDHOC, see Appendix C.
			+-------+-------------------+-------------------+-------------------+
			| Value | Initiator | Responder | Reference |
			+-------+-------------------+-------------------+-------------------+
			| 0 | Signature Key | Signature Key | [[this document]] |
			| 1 | Signature Key | Static DH Key | [[this document]] |
			| 2 | Static DH Key | Signature Key | [[this document]] |
			| 3 | Static DH Key | Static DH Key | [[this document]] |
			+-------+-------------------+-------------------+-------------------+
			Figure 4: Method Types
			3.2.2. Connection Identifiers
	EDHOC includes connection identifiers (C_I, C_R) to correlate		EDHOC includes connection identifiers (C_I, C_R) to correlate
	messages. The connection identifiers C_I and C_R do not have any		messages. The connection identifiers C_I and C_R do not have any
	cryptographic purpose in EDHOC. They contain information		cryptographic purpose in EDHOC. They contain information
	facilitating retrieval of the protocol state and may therefore be		facilitating retrieval of the protocol state and may therefore be
	very short. The connection identifier MAY be used with an		very short. One byte connection identifiers are realistic in many
	application protocol (e.g. OSCORE) for which EDHOC establishes keys,		scenarios as most constrained devices only have a few connections.
	in which case the connection identifiers SHALL adhere to the		In cases where a node only has one connection, the identifiers may
	requirements for that protocol. Each party choses a connection		even be the empty byte string.
	identifier it desires the other party to use in outgoing messages.
	(For OSCORE this results in the endpoint selecting its Recipient ID,		The connection identifier MAY be used with an application protocol
	see Section 3.1 of [RFC8613]).		(e.g. OSCORE) for which EDHOC establishes keys, in which case the
			connection identifiers SHALL adhere to the requirements for that
			protocol. Each party choses a connection identifier it desires the
			other party to use in outgoing messages. (For OSCORE this results in
			the endpoint selecting its Recipient ID, see Section 3.1 of
			[RFC8613]).
			3.2.3. Transport
			Cryptographically, EDHOC does not put requirements on the lower
			layers. EDHOC is not bound to a particular transport layer, and can
			be used in environments without IP. The transport is responsible to
			handle message loss, reordering, message duplication, fragmentation,
			and denial of service protection, where necessary.
			The Initiator and the Responder need to have agreed on a transport to
			be used for EDHOC, see Appendix C. It is recommended to transport
			EDHOC in CoAP payloads, see Section 7.
			3.2.4. Message Correlation
	If the transport provides a mechanism for correlating messages, some		If the transport provides a mechanism for correlating messages, some
	of the connection identifiers may be omitted. There are four cases:		of the connection identifiers may be omitted. There are four cases:
	o corr = 0, the transport does not provide a correlation mechanism.		o corr = 0, the transport does not provide a correlation mechanism.
	o corr = 1, the transport provides a correlation mechanism that		o corr = 1, the transport provides a correlation mechanism that
	enables the Responder to correlate message_2 and message_1.		enables the Responder to correlate message_2 and message_1.
	o corr = 2, the transport provides a correlation mechanism that		o corr = 2, the transport provides a correlation mechanism that
	enables the Initiator to correlate message_3 and message_2.		enables the Initiator to correlate message_3 and message_2.
	o corr = 3, the transport provides a correlation mechanism that		o corr = 3, the transport provides a correlation mechanism that
	enables both parties to correlate all three messages.		enables both parties to correlate all three messages.
	For example, if the key exchange is transported over CoAP, the CoAP		For example, if the key exchange is transported over CoAP, the CoAP
	Token can be used to correlate messages, see Section 6.1.		Token can be used to correlate messages, see Section 7.1.
	3.2. Authentication Keys and Identities		3.3. Authentication Parameters
	The EDHOC message exchange may be authenticated using raw public keys		3.3.1. Authentication Keys
	(RPK) or public key certificates. The certificates and RPKs can
	contain signature keys or static Diffie-Hellman keys. In X.509		The authentication key MUST be a signature key or static Diffie-
	certificates, signature keys typically have key usage		Hellman key. The Initiator and the Responder MAY use different types
	"digitalSignature" and Diffie-Hellman keys typically have key usage		of authentication keys, e.g. one uses a signature key and the other
	"keyAgreement".		uses a static Diffie-Hellman key. When using a signature key, the
			authentication is provided by a signature. When using a static
			Diffie-Hellman key the authentication is provided by a Message
			Authentication Code (MAC) computed from an ephemeral-static ECDH
			shared secret which enables significant reductions in message sizes.
			The MAC is implemented with an AEAD algorithm. When using a static
			Diffie-Hellman keys the Initiator's and Responder's private
			authentication keys are called I and R, respectively, and the public
			authentication keys are called G_I and G_R, respectively.
			o Only the Responder SHALL have access to the Responder's private
			authentication key.
			o Only the Initiator SHALL have access to the Initiator's private
			authentication key.
			3.3.2. Identities
	EDHOC assumes the existence of mechanisms (certification authority,		EDHOC assumes the existence of mechanisms (certification authority,
	trusted third party, manual distribution, etc.) for specifying and		trusted third party, manual distribution, etc.) for specifying and
	distributing authentication keys and identities. Policies are set		distributing authentication keys and identities. Policies are set
	based on the identity of the other party, and parties typically only		based on the identity of the other party, and parties typically only
	allow connections from a specific identity or a small restricted set		allow connections from a specific identity or a small restricted set
	of identities. For example, in the case of a device connecting to a		of identities. For example, in the case of a device connecting to a
	network, the network may only allow connections from devices which		network, the network may only allow connections from devices which
	authenticate with certificates having a particular range of serial		authenticate with certificates having a particular range of serial
	numbers in the subject field and signed by a particular CA. On the		numbers in the subject field and signed by a particular CA. On the
	skipping to change at page 11, line 16 ¶		skipping to change at page 12, line 30 ¶
	certificate), the trust anchor is the public authentication key of		certificate), the trust anchor is the public authentication key of
	the other party. In this case, the identity is typically directly		the other party. In this case, the identity is typically directly
	associated to the public authentication key of the other party.		associated to the public authentication key of the other party.
	For example, the name of the subject may be a canonical		For example, the name of the subject may be a canonical
	representation of the public key. Alternatively, if identities		representation of the public key. Alternatively, if identities
	can be expressed in the form of unique subject names assigned to		can be expressed in the form of unique subject names assigned to
	public keys, then a binding to identity can be achieved by		public keys, then a binding to identity can be achieved by
	including both public key and associated subject name in the		including both public key and associated subject name in the
	protocol message computation: CRED_I or CRED_R may be a self-		protocol message computation: CRED_I or CRED_R may be a self-
	signed certificate or COSE_Key containing the public		signed certificate or COSE_Key containing the public
	authentication key and the subject name, see Figure 2. Before		authentication key and the subject name, see Section 3.3.3.
	running EDHOC, each endpoint needs a specific public		Before running EDHOC, each endpoint needs a specific public
	authentication key/unique associated subject name, or a set of		authentication key/unique associated subject name, or a set of
	public authentication keys/unique associated subject names, which		public authentication keys/unique associated subject names, which
	it is allowed to communicate with. EDHOC provides proof that the		it is allowed to communicate with. EDHOC provides proof that the
	other party possesses the private authentication key corresponding		other party possesses the private authentication key corresponding
	to the public authentication key.		to the public authentication key.
	3.3. Identifiers		3.3.3. Authentication Credentials
	One byte connection and credential identifiers are realistic in many		The authentication credentials, CRED_I and CRED_R, contain the public
	scenarios as most constrained devices only have a few keys and		authentication key of the Initiator and the Responder, respectively.
	connections. In cases where a node only has one connection or key,		The Initiator and the Responder MAY use different types of
	the identifiers may even be the empty byte string.		credentials, e.g. one uses an RPK and the other uses a public key
			certificate.
			The credentials CRED_I and CRED_R are signed or MAC:ed (depending on
			method) by the Initiator and the Responder, respectively, see
			Section 5.4 and Section 5.3.
			When the credential is a certificate, CRED_x is an end-entity
			certificate (i.e. not the certificate chain) encoded as a CBOR bstr.
			In X.509 certificates, signature keys typically have key usage
			"digitalSignature" and Diffie-Hellman keys typically have key usage
			"keyAgreement"
			When the credential is a COSE_Key, CRED_x is a CBOR map only
			containing specific fields from the COSE_Key:
			o For COSE_Keys of type OKP the CBOR map SHALL only include the
			parameters 1 (kty), -1 (crv), and -2 (x-coordinate).
			o For COSE_Keys of type EC2 the CBOR map SHALL only include the
			parameters 1 (kty), -1 (crv), -2 (x-coordinate), and -3
			(y-coordinate).
			To prevent misbinding attacks in systems where an attacker can
			register public keys without proving knowledge of the private key,
			SIGMA [SIGMA] enforces a MAC to be calculated over the "Identity",
			which in case of a X.509 certificate would be the 'subject' and
			'subjectAltName' fields. EDHOC follows SIGMA by calculating a MAC
			over the whole certificate. While SIGMA paper only focuses on the
			identity, the same principle is true for any information such as
			policies connected to the public key.
			If the parties have agreed on an identity besides the public key, the
			identity is included in the CBOR map with the label "subject name",
			otherwise the subject name is the empty text string. The parameters
			SHALL be encoded in decreasing order with int labels first and text
			string labels last. An example of CRED_x when the RPK contains an
			X25519 static Diffie-Hellman key and the parties have agreed on an
			EUI-64 identity is shown below:
			CRED_x = {
			1: 1,
			-1: 4,
			-2: h'b1a3e89460e88d3a8d54211dc95f0b90
			3ff205eb71912d6db8f4af980d2db83a',
			"subject name" : "42-50-31-FF-EF-37-32-39"
			}
			3.3.4. Identification of Credentials
			ID_CRED_I and ID_CRED_R are identifiers of the public authentication
			keys of the Initiator and the Responder, respectively. ID_CRED_I and
			ID_CRED_R do not have any cryptographic purpose in EDHOC.
			o ID_CRED_R is intended to facilitate for the Initiator to retrieve
			the Responder's public authentication key.
			o ID_CRED_I is intended to facilitate for the Responder to retrieve
			the Initiator's public authentication key.
			The identifiers ID_CRED_I and ID_CRED_R are COSE header_maps, i.e.
			CBOR maps containing COSE Common Header Parameters, see Section 3.1
			of [RFC8152]). In the following we give some examples of COSE
			header_maps.
			Raw public keys are most optimally stored as COSE_Key objects and
			identified with a 'kid' parameter:
			o ID_CRED_x = { 4 : kid_x }, where kid_x : bstr, for x = I or R.
			Public key certificates can be identified in different ways. Header
			parameters for identifying X.509 certificates are defined in
			[I-D.ietf-cose-x509], for example:
			o by a hash value with the 'x5t' parameter;
			* ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,
			o by a URL with the 'x5u' parameter;
			* ID_CRED_x = { 35 : uri }, for x = I or R,
			ID_CRED_x MAY contain the actual credential used for authentication,
			CRED_x. It is RECOMMENDED that they uniquely identify the public
			authentication key as the recipient may otherwise have to try several
			keys. ID_CRED_I and ID_CRED_R are transported in the ciphertext, see
			Section 5.4 and Section 5.3.
			When ID_CRED_x does not contain the actual credential it may be very
			short. One byte credential identifiers are realistic in many
			scenarios as most constrained devices only have a few keys. In cases
			where a node only has one key, the identifier may even be the empty
			byte string.
	3.4. Cipher Suites		3.4. Cipher Suites
	EDHOC cipher suites consist of an ordered set of COSE algorithms: an		An EDHOC cipher suite consists of an ordered set of COSE code points
	EDHOC AEAD algorithm, an EDHOC hash algorithm, an EDHOC ECDH curve,		from the "COSE Algorithms" and "COSE Elliptic Curves" registries:
	an EDHOC signature algorithm, an EDHOC signature algorithm curve, an
	application AEAD algorithm, and an application hash algorithm from		o EDHOC AEAD algorithm
	the COSE Algorithms and Elliptic Curves registries. Each cipher
	suite is identified with a pre-defined int label. This document		o EDHOC hash algorithm
	specifies four pre-defined cipher suites.
			o EDHOC ECDH curve
			o EDHOC signature algorithm
			o EDHOC signature algorithm curve
			o Application AEAD algorithm
			o Application hash algorithm
			Each cipher suite is identified with a pre-defined int label.
			EDHOC can be used with all algorithms and curves defined for COSE.
			Implementation can either use one of the pre-defined cipher suites
			(Section 9.1) or use any combination of COSE algorithms to define
			their own private cipher suite. Private cipher suites can be
			identified with any of the four values -24, -23, -22, -21.
			The following cipher suites are for constrained IoT where message
			overhead is a very important factor:
	0. ( 10, -16, 4, -8, 6, 10, -16 )		0. ( 10, -16, 4, -8, 6, 10, -16 )
	(AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519,		(AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519,
	AES-CCM-16-64-128, SHA-256)		AES-CCM-16-64-128, SHA-256)
	1. ( 30, -16, 4, -8, 6, 10, -16 )		1. ( 30, -16, 4, -8, 6, 10, -16 )
	(AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519,		(AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519,
	AES-CCM-16-64-128, SHA-256)		AES-CCM-16-64-128, SHA-256)
	2. ( 10, -16, 1, -7, 1, 10, -16 )		2. ( 10, -16, 1, -7, 1, 10, -16 )
	(AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256,		(AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256,
	AES-CCM-16-64-128, SHA-256)		AES-CCM-16-64-128, SHA-256)
	3. ( 30, -16, 1, -7, 1, 10, -16 )		3. ( 30, -16, 1, -7, 1, 10, -16 )
	(AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256,		(AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256,
	AES-CCM-16-64-128, SHA-256)		AES-CCM-16-64-128, SHA-256)
	The different methods use the same cipher suites, but some algorithms		The following cipher suite is for general non-constrained
	are not used in some methods. The EDHOC signature algorithm and the		applications. It uses very high performance algorithms that also are
	EDHOC signature algorithm curve are not used is methods without		widely supported:
	signature authentication.
	The Initiator need to have a list of cipher suites it supports in		4. ( 1, -16, 4, -7, 1, 1, -16 )
	order of preference. The Responder need to have a list of cipher		(A128GCM, SHA-256, X25519, ES256, P-256,
	suites it supports.		A128GCM, SHA-256)
	3.5. Communication/Negotiation of Protocol Features		The following cipher suite is for high security application such as
			government use and financial applications. It is compatible with the
			CNSA suite [CNSA].
	EDHOC allows the communication or negotiation of various protocol		5. ( 3, -43, 2, -35, 2, 3, -43 )
	features during the execution of the protocol.		(A256GCM, SHA-384, P-384, ES384, P-384,
			A256GCM, SHA-384)
	o The Initiator proposes a cipher suite (see Section 3.4), and the		The different methods use the same cipher suites, but some algorithms
	Responder either accepts or rejects, and may make a counter		are not used in some methods. The EDHOC signature algorithm and the
	proposal.		EDHOC signature algorithm curve are not used in methods without
			signature authentication.
	o The Initiator decides on the correlation parameter corr (see		The Initiator needs to have a list of cipher suites it supports in
	Section 3.1). This is typically given by the transport which the		order of preference. The Responder needs to have a list of cipher
	Initiator and the Responder have agreed on beforehand. The		suites it supports. SUITES_I is a CBOR array containing cipher
	Responder either accepts or rejects.		suites that the Initiator supports. SUITES_I is formatted and
			processed as detailed in Section 5.2.1 to secure the cipher suite
			negotation.
	o The Initiator decides on the method parameter, see Section 8.2.		3.5. Ephemeral Public Keys
	The Responder either accepts or rejects.
	o The Initiator and the Responder decide on the representation of		The ECDH ephemeral public keys are formatted as a COSE_Key of type
	the identifier of their respective credentials, ID_CRED_I and		EC2 or OKP according to Sections 13.1 and 13.2 of [RFC8152], but only
	ID_CRED_R. The decision is reflected by the label used in the		the 'x' parameter is included G_X and G_Y. For Elliptic Curve Keys
	CBOR map, see for example Section 4.2.		of type EC2, compact representation as per [RFC6090] MAY be used also
			in the COSE_Key. If the COSE implementation requires an 'y'
			parameter, any of the possible values of the y-coordinate can be
			used, see Appendix C of [RFC6090]. COSE [RFC8152] always use compact
			output for Elliptic Curve Keys of type EC2.
	3.6. Auxiliary Data		3.6. Auxiliary Data
	In order to reduce round trips and number of messages, and in some		In order to reduce round trips and number of messages, and in some
	cases also streamline processing, certain security applications may		cases also streamline processing, certain security applications may
	be integrated into EDHOC by transporting auxiliary data together with		be integrated into EDHOC by transporting auxiliary data together with
	the messages. One example is the transport of third-party		the messages. One example is the transport of third-party
	authorization information protected outside of EDHOC		authorization information protected outside of EDHOC
	[I-D.selander-ace-ake-authz]. Another example is the embedding of a		[I-D.selander-ace-ake-authz]. Another example is the embedding of a
	certificate enrolment request or a newly issued certificate.		certificate enrolment request or a newly issued certificate.
	skipping to change at page 13, line 27 ¶		skipping to change at page 17, line 5 ¶
	message_1 and message_2, respectively. Protected Auxiliary Data		message_1 and message_2, respectively. Protected Auxiliary Data
	(AD_3) may be sent in message_3.		(AD_3) may be sent in message_3.
	Since data carried in AD_1 and AD_2 may not be protected, and the		Since data carried in AD_1 and AD_2 may not be protected, and the
	content of AD_3 is available to both the Initiator and the Responder,		content of AD_3 is available to both the Initiator and the Responder,
	special considerations need to be made such that the availability of		special considerations need to be made such that the availability of
	the data a) does not violate security and privacy requirements of the		the data a) does not violate security and privacy requirements of the
	service which uses this data, and b) does not violate the security		service which uses this data, and b) does not violate the security
	properties of EDHOC.		properties of EDHOC.
	3.7. Ephemeral Public Keys		3.7. Communication of Protocol Features
	The ECDH ephemeral public keys are formatted as a COSE_Key of type		EDHOC allows the communication or negotiation of various protocol
	EC2 or OKP according to Sections 13.1 and 13.2 of [RFC8152], but only		features during the execution of the protocol.
	the 'x' parameter is included in the EDHOC messages. For Elliptic
	Curve Keys of type EC2, compact representation as per [RFC6090] MAY
	be used also in the COSE_Key. If the COSE implementation requires an
	'y' parameter, any of the possible values of the y-coordinate can be
	used, see Appendix C of [RFC6090]. COSE [RFC8152] always use compact
	output for Elliptic Curve Keys of type EC2.
	3.8. Key Derivation		o The Initiator proposes a cipher suite (see Section 3.4), and the
			Responder either accepts or rejects, and may make a counter
			proposal.
	EDHOC uses HKDF [RFC5869] with the EDHOC hash algorithm in the		o The Initiator decides on the correlation parameter corr (see
	selected cipher suite to derive keys. HKDF-Extract is used to derive		Section 3.2.4). This is typically given by the transport which
	fixed-length uniformly pseudorandom keys (PRK) from ECDH shared		the Initiator and the Responder have agreed on beforehand. The
	secrets. HKDF-Expand is used to derive additional output keying		Responder either accepts or rejects.
	material (OKM) from the PRKs. The PRKs are derived using HKDF-
	Extract [RFC5869].
	PRK = HKDF-Extract( salt, IKM )		o The Initiator decides on the method parameter, see Figure 4. The
			Responder either accepts or rejects.
			o The Initiator and the Responder decide on the representation of
			the identifier of their respective credentials, ID_CRED_I and
			ID_CRED_R. The decision is reflected by the label used in the
			CBOR map, see for example Section 3.3.4.
			Editor's note: This section needs to be aligned with Appendix C.
			4. Key Derivation
			EDHOC uses Extract-and-Expand [RFC5869] with the EDHOC hash algorithm
			in the selected cipher suite to derive keys. Extract is used to
			derive fixed-length uniformly pseudorandom keys (PRK) from ECDH
			shared secrets. Expand is used to derive additional output keying
			material (OKM) from the PRKs. The PRKs are derived using Extract.
			PRK = Extract( salt, IKM )
			If the EDHOC hash algorithm is SHA-2, then Extract( salt, IKM ) =
			HKDF-Extract( salt, IKM ) [RFC5869]. If the EDHOC hash algorithm is
			SHAKE128, then Extract( salt, IKM ) = KMAC128( salt, IKM, 256, "" ).
			If the EDHOC hash algorithm is SHAKE256, then Extract( salt, IKM ) =
			KMAC256( salt, IKM, 512, "" ).
	PRK_2e is used to derive key and IV to encrypt message_2. PRK_3e2m		PRK_2e is used to derive key and IV to encrypt message_2. PRK_3e2m
	is used to derive keys and IVs produce a MAC in message_2 and to		is used to derive keys and IVs produce a MAC in message_2 and to
	encrypt message_3. PRK_4x3m is used to derive keys and IVs produce a		encrypt message_3. PRK_4x3m is used to derive keys and IVs produce a
	MAC in message_3 and to derive application specific data.		MAC in message_3 and to derive application specific data.
	PRK_2e is derived with the following input:		PRK_2e is derived with the following input:
	o The salt SHALL be the empty byte string. Note that [RFC5869]		o The salt SHALL be the empty byte string. Note that [RFC5869]
	specifies that if the salt is not provided, it is set to a string		specifies that if the salt is not provided, it is set to a string
	skipping to change at page 14, line 26 ¶		skipping to change at page 18, line 24 ¶
	Example: Assuming the use of SHA-256 the extract phase of HKDF		Example: Assuming the use of SHA-256 the extract phase of HKDF
	produces PRK_2e as follows:		produces PRK_2e as follows:
	PRK_2e = HMAC-SHA-256( salt, G_XY )		PRK_2e = HMAC-SHA-256( salt, G_XY )
	where salt = 0x (the empty byte string).		where salt = 0x (the empty byte string).
	The pseudorandom keys PRK_3e2m and PRK_4x3m are defined as follow:		The pseudorandom keys PRK_3e2m and PRK_4x3m are defined as follow:
	o If the Reponder authenticates with a static Diffie-Hellman key,		o If the Responder authenticates with a static Diffie-Hellman key,
	then PRK_3e2m = HKDF-Extract( PRK_2e, G_RX ), where G_RX is the		then PRK_3e2m = Extract( PRK_2e, G_RX ), where G_RX is the ECDH
	ECDH shared secret calculated from G_R and X, or G_X and R, else		shared secret calculated from G_R and X, or G_X and R, else
	PRK_3e2m = PRK_2e.		PRK_3e2m = PRK_2e.
	o If the Initiator authenticates with a static Diffie-Hellman key,		o If the Initiator authenticates with a static Diffie-Hellman key,
	then PRK_4x3m = HKDF-Extract( PRK_3e2m, G_IY ), where G_IY is the		then PRK_4x3m = Extract( PRK_3e2m, G_IY ), where G_IY is the ECDH
	ECDH shared secret calculated from G_I and Y, or G_Y and I, else		shared secret calculated from G_I and Y, or G_Y and I, else
	PRK_4x3m = PRK_3e2m.		PRK_4x3m = PRK_3e2m.
	Example: Assuming the use of curve25519, the ECDH shared secrets		Example: Assuming the use of curve25519, the ECDH shared secrets
	G_XY, G_RX, and G_IY are the outputs of the X25519 function		G_XY, G_RX, and G_IY are the outputs of the X25519 function
	[RFC7748]:		[RFC7748]:
	G_XY = X25519( Y, G_X ) = X25519( X, G_Y )		G_XY = X25519( Y, G_X ) = X25519( X, G_Y )
	The keys and IVs used in EDHOC are derived from PRK using HKDF-Expand		The keys and IVs used in EDHOC are derived from PRK using Expand
	[RFC5869] where the EDHOC-KDF is instantiated with the EDHOC AEAD		[RFC5869] where the EDHOC-KDF is instantiated with the EDHOC AEAD
	algorithm in the selected cipher suite.		algorithm in the selected cipher suite.
	OKM = EDHOC-KDF( PRK, transcript_hash, label, length )		OKM = EDHOC-KDF( PRK, transcript_hash, label, length )
	= HKDF-Expand( PRK, info, length )		= Expand( PRK, info, length )
	where info is the CBOR encoding of		where info is the CBOR encoding of
	info = [		info = [
	edhoc_aead_id : int / tstr,		edhoc_aead_id : int / tstr,
	transcript_hash : bstr,		transcript_hash : bstr,
	label : tstr,		label : tstr,
	length : uint		length : uint
	]		]
	where		where
	o edhoc_aead_id is an int or tstr containing the algorithm		o edhoc_aead_id is an int or tstr containing the algorithm
	identifier of the EDHOC AEAD algorithm in the selected cipher		identifier of the EDHOC AEAD algorithm in the selected cipher
	suite encoded as defined in [RFC8152]. Note that a single fixed		suite encoded as defined in [RFC8152]. Note that a single fixed
	edhoc_aead_id is used in all invocations of EDHOC-KDF, including		edhoc_aead_id is used in all invocations of EDHOC-KDF, including
	the derivation of K_2e and invocations of the EDHOC-Exporter.		the derivation of K_2e and invocations of the EDHOC-Exporter.
	o transcript_hash is a bstr set to one of the transcript hashes		o transcript_hash is a bstr set to one of the transcript hashes
	TH_2, TH_3, or TH_4 as defined in Sections 4.5.1, 4.6.1, and		TH_2, TH_3, or TH_4 as defined in Sections 5.3.1, 5.4.1, and 4.1.
	3.8.1.
	o label is a tstr set to the name of the derived key or IV, i.e.		o label is a tstr set to the name of the derived key or IV, i.e.
	"K_2m", "IV_2m", "K_2e", "K_3m", "IV_3m", "K_3ae", or "IV_3ae".		"K_2m", "IV_2m", "K_2e", "IV_2e", "K_3m", "IV_3m", "K_3ae", or
			"IV_3ae".
	o length is the length of output keying material (OKM) in bytes		o length is the length of output keying material (OKM) in bytes
	K_2m and IV_2m are derived using the transcript hash TH_2 and the		If the EDHOC hash algorithm is SHA-2, then Expand( PRK, info, length
	pseudorandom key PRK_3e2m. K_3ae and IV_3ae are derived using the		) = HKDF-Expand( PRK, info, length ) [RFC5869]. If the EDHOC hash
	transcript hash TH_3 and the pseudorandom key PRK_3e2m. K_3m and		algorithm is SHAKE128, then Expand( PRK, info, length ) = KMAC128(
	IV_3m are derived using the transcript hash TH_3 and the pseudorandom		PRK, info, L, "" ). If the EDHOC hash algorithm is SHAKE256, then
	key PRK_4x3m. IVs are only used if the EDHOC AEAD algorithm uses		Expand( PRK, info, length ) = KMAC256( PRK, info, L, "" ).
	IVs.
	3.8.1. EDHOC-Exporter Interface		K_2e and IV_2e are derived using the transcript hash TH_2 and the
			pseudorandom key PRK_2e. K_2m and IV_2m are derived using the
			transcript hash TH_2 and the pseudorandom key PRK_3e2m. K_3ae and
			IV_3ae are derived using the transcript hash TH_3 and the
			pseudorandom key PRK_3e2m. K_3m and IV_3m are derived using the
			transcript hash TH_3 and the pseudorandom key PRK_4x3m. IVs are only
			used if the EDHOC AEAD algorithm uses IVs.
			4.1. EDHOC-Exporter Interface
	Application keys and other application specific data can be derived		Application keys and other application specific data can be derived
	using the EDHOC-Exporter interface defined as:		using the EDHOC-Exporter interface defined as:
	EDHOC-Exporter(label, length)		EDHOC-Exporter(label, length)
	= EDHOC-KDF(PRK_4x3m, TH_4, label, length)		= EDHOC-KDF(PRK_4x3m, TH_4, label, length)
	where label is a tstr defined by the application and length is a uint		where label is a tstr defined by the application and length is a uint
	defined by the application. The label SHALL be different for each		defined by the application. The label SHALL be different for each
	different exporter value. The transcript hash TH_4 is a CBOR encoded		different exporter value. The transcript hash TH_4 is a CBOR encoded
	bstr and the input to the hash function is a CBOR Sequence.		bstr and the input to the hash function is a CBOR Sequence.
	TH_4 = H( TH_3, CIPHERTEXT_3 )		TH_4 = H( TH_3, CIPHERTEXT_3 )
	where H() is the hash function in the selected cipher suite. Example		where H() is the hash function in the selected cipher suite. Example
	use of the EDHOC-Exporter is given in Sections 6.1.1.		use of the EDHOC-Exporter is given in Sections 7.1.1.
	4. EDHOC Authenticated with Asymmetric Keys
	4.1. Overview
	This section specifies authentication method = 0, 1, 2, and 3, see
	Section 8.2. EDHOC supports authentication with signature or static
	Diffie-Hellman keys in the form of raw public keys (RPK) and public
	key certificates with the requirements that:
	o Only the Responder SHALL have access to the Responder's private
	authentication key,
	o Only the Initiator SHALL have access to the Initiator's private
	authentication key,
	o The Initiator is able to retrieve the Responder's public
	authentication key using ID_CRED_R,
	o The Responder is able to retrieve the Initiator's public
	authentication key using ID_CRED_I,
	where ID_CRED_I and ID_CRED_R are the identifiers of the public
	authentication keys. Their encoding is specified in Section 4.2.
	Initiator Responder
	| METHOD_CORR, SUITES_I, G_X, C_I, AD_1 |
	+------------------------------------------------------------------>|
	| message_1 |
	| |
	| C_I, G_Y, C_R, Enc(K_2e; ID_CRED_R, Signature_or_MAC_2, AD_2) |
	|<------------------------------------------------------------------+
	| message_2 |
	| |
	| C_R, AEAD(K_3ae; ID_CRED_I, Signature_or_MAC_3, AD_3) |
	+------------------------------------------------------------------>|
	| message_3 |
	Figure 4: Overview of EDHOC with asymmetric key authentication.
	4.2. Encoding of Public Authentication Key Identifiers
	The identifiers ID_CRED_I and ID_CRED_R are COSE header_maps, i.e.
	CBOR maps containing COSE Common Header Parameters, see Section 3.1
	of [RFC8152]). ID_CRED_I and ID_CRED_R need to contain parameters
	that can identify a public authentication key. In the following
	paragraph we give some examples of possible COSE header parameters
	used.
	Raw public keys are most optimally stored as COSE_Key objects and
	identified with a 'kid' parameter:
	o ID_CRED_x = { 4 : kid_x }, where kid_x : bstr, for x = I or R.
	Public key certificates can be identified in different ways. Header
	parameters for identifying X.509 certificates are defined in
	[I-D.ietf-cose-x509], for example:
	o by a hash value with the 'x5t' parameter;
	* ID_CRED_x = { 34 : COSE_CertHash }, for x = I or R,		To provide forward secrecy in an even more efficient way than re-
			running EDHOC, EDHOC provides the function EDHOC-Exporter-FS. When
			EHDOC-Exporter-FS is called the old PRK_4x3m is deleted and the new
			PRk_4x3m is calculated as a "hash" of the old key using the Extract
			function as illustrated by the following pseudocode:
	o by a URL with the 'x5u' parameter;		EHDOC-Exporter-FS( nonce ):
			PRK_4x3m = Extract( [ "TH_4", nonce ], PRK_4x3m )
	* ID_CRED_x = { 35 : uri }, for x = I or R,		5. Message Formatting and Processing
	The purpose of ID_CRED_I and ID_CRED_R is to facilitate retrieval of		This section specifies formatting of the messages and processing
	a public authentication key and when they do not contain the actual		steps. Error messages are specified in Section 6.
	credential, they may be very short. ID_CRED_I and ID_CRED_R MAY
	contain the actual credential used for authentication. It is
	RECOMMENDED that they uniquely identify the public authentication key
	as the recipient may otherwise have to try several keys. ID_CRED_I
	and ID_CRED_R are transported in the ciphertext, see Section 4.5.2
	and Section 4.6.2.
	The authentication key MUST be a signature key or static Diffie-		An EDHOC message is encoded as a sequence of CBOR data (CBOR
	Hellman key. The Initiator and the Responder MAY use different types		Sequence, [RFC8742]). Additional optimizations are made to reduce
	of authentication keys, e.g. one uses a signature key and the other		message overhead.
	uses a static Diffie-Hellman key. When using a signature key, the
	authentication is provided by a signature. When using a static
	Diffie-Hellman key the authentication is provided by a Message
	Authentication Code (MAC) computed from an ephemeral-static ECDH
	shared secret which enables significant reductions in message sizes.
	The MAC is implemented with an AEAD algorithm. When using a static
	Diffie-Hellman keys the Initiator's and Responder's private
	authentication keys are called I and R, respectively, and the public
	authentication keys are called G_I and G_R, respectively.
	The actual credentials CRED_I and CRED_R are signed or MAC:ed by the		While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
	Initiator and the Responder respectively, see Section 4.6.1 and		structures, only a subset of the parameters is included in the EDHOC
	Section 4.5.1. The Initiator and the Responder MAY use different		messages. The unprotected COSE header in COSE_Sign1, and
	types of credentials, e.g. one uses RPK and the other uses		COSE_Encrypt0 (not included in the EDHOC message) MAY contain
	certificate. When the credential is a certificate, CRED_x is end-		parameters (e.g. 'alg').
	entity certificate (i.e. not the certificate chain) encoded as a CBOR
	bstr. When the credential is a COSE_Key, CRED_x is a CBOR map only
	contains specific fields from the COSE_Key. For COSE_Keys of type
	OKP the CBOR map SHALL only include the parameters 1 (kty), -1 (crv),
	and -2 (x-coordinate). For COSE_Keys of type EC2 the CBOR map SHALL
	only include the parameters 1 (kty), -1 (crv), -2 (x-coordinate), and
	-3 (y-coordinate). If the parties have agreed on an identity besides
	the public key, the indentity is included in the CBOR map with the
	label "subject name", otherwise the subject name is the empty text
	string. The parameters SHALL be encoded in decreasing order with int
	labels first and text string labels last. An example of CRED_x when
	the RPK contains an X25519 static Diffie-Hellman key and the parties
	have agreed on an EUI-64 identity is shown below:
	CRED_x = {		5.1. Encoding of bstr_identifier
	1: 1,
	-1: 4,
	-2: h'b1a3e89460e88d3a8d54211dc95f0b90
	3ff205eb71912d6db8f4af980d2db83a',
	"subject name" : "42-50-31-FF-EF-37-32-39"
	}
	4.3. Encoding of bstr_identifier		Byte strings are encoded in CBOR as two or more bytes, whereas
			integers in the interval -24 to 23 are encoded in CBOR as one byte.
	A bstr_identifier is a special encoding for byte strings, used		bstr_identifier is a special encoding of byte strings, used
	throughout the protocol.		throughout the protocol to enable the encoding of the shortest byte
			strings as integers that only require one byte of CBOR encoding.
	Byte strings of length greater than one are encoded as CBOR byte		The bstr_identifier encoding is defined as follows: Byte strings in
	strings. Byte strings of length one are encoded as the corresponding		the interval h'00' to h'2f' are encoded as the corresponding integer
	integer - 24.		minus 24, which are all represented by one byte CBOR ints. Other
			byte strings are encoded as CBOR byte strings.
	For example, the byte string h'59e9' encoded as a bstr_identifier is		For example, the byte string h'59e9' encoded as a bstr_identifier is
	equal to h'59e9', while the byte string h'2a' is encoded as the		equal to h'59e9', while the byte string h'2a' is encoded as the
	integer 18.		integer 18.
	The CDDL definition of the bstr_identifier is given below:		The CDDL definition of the bstr_identifier is given below:
	bstr_identifier = bstr / int		bstr_identifier = bstr / int
	Note that, despite what could be interpreted by the CDDL definition		Note that, despite what could be interpreted by the CDDL definition
	only, bstr_identifier once decoded are always byte strings.		only, bstr_identifier once decoded are always byte strings.
	4.4. EDHOC Message 1		5.2. EDHOC Message 1
	4.4.1. Formatting of Message 1		5.2.1. Formatting of Message 1
	message_1 SHALL be a CBOR Sequence (see Appendix A.1) as defined		message_1 SHALL be a CBOR Sequence (see Appendix A.1) as defined
	below		below
	message_1 = (		message_1 = (
	METHOD_CORR : int,		METHOD_CORR : int,
	SUITES_I : [ selected : suite, supported : 2* suite ] / suite,		SUITES_I : [ selected : suite, supported : 2* suite ] / suite,
	G_X : bstr,		G_X : bstr,
	C_I : bstr_identifier,		C_I : bstr_identifier,
	? AD_1 : bstr,		? AD_1 : bstr,
	)		)
	suite = int		suite = int
	skipping to change at page 19, line 17 ¶		skipping to change at page 21, line 36 ¶
	G_X : bstr,		G_X : bstr,
	C_I : bstr_identifier,		C_I : bstr_identifier,
	? AD_1 : bstr,		? AD_1 : bstr,
	)		)
	suite = int		suite = int
	where:		where:
	o METHOD_CORR = 4 * method + corr, where method = 0, 1, 2, or 3 (see		o METHOD_CORR = 4 * method + corr, where method = 0, 1, 2, or 3 (see
	Section 8.2) and the correlation parameter corr is chosen based on		Figure 4) and the correlation parameter corr is chosen based on
	the transport and determines which connection identifiers that are		the transport and determines which connection identifiers that are
	omitted (see Section 3.1).		omitted (see Section 3.2.4).
	o SUITES_I - cipher suites which the Initiator supports in order of		o SUITES_I - cipher suites which the Initiator supports in order of
	(decreasing) preference. The list of supported cipher suites can		(decreasing) preference. The list of supported cipher suites can
	be truncated at the end, as is detailed in the processing steps		be truncated at the end, as is detailed in the processing steps
	below. One of the supported cipher suites is selected. If a		below. One of the supported cipher suites is selected. The
	single supported cipher suite is conveyed then that cipher suite		selected suite is the first suite in the SUITES_I CBOR array. If
			a single supported cipher suite is conveyed then that cipher suite
	is selected and the selected cipher suite is encoded as an int		is selected and the selected cipher suite is encoded as an int
	instead of an array.		instead of an array.
	o G_X - the ephemeral public key of the Initiator		o G_X - the ephemeral public key of the Initiator
	o C_I - variable length connection identifier, encoded as a		o C_I - variable length connection identifier, encoded as a
	bstr_identifier (see Section 4.3).		bstr_identifier (see Section 5.1).
	o AD_1 - bstr containing unprotected opaque auxiliary data		o AD_1 - bstr containing unprotected opaque auxiliary data
	4.4.2. Initiator Processing of Message 1		5.2.2. Initiator Processing of Message 1
	The Initiator SHALL compose message_1 as follows:		The Initiator SHALL compose message_1 as follows:
	o The supported cipher suites and the order of preference MUST NOT		o The supported cipher suites and the order of preference MUST NOT
	be changed based on previous error messages. However, the list		be changed based on previous error messages. However, the list
	SUITES_I sent to the Responder MAY be truncated such that cipher		SUITES_I sent to the Responder MAY be truncated such that cipher
	suites which are the least preferred are omitted. The amount of		suites which are the least preferred are omitted. The amount of
	truncation MAY be changed between sessions, e.g. based on previous		truncation MAY be changed between sessions, e.g. based on previous
	error messages (see next bullet), but all cipher suites which are		error messages (see next bullet), but all cipher suites which are
	more preferred than the least preferred cipher suite in the list		more preferred than the least preferred cipher suite in the list
	skipping to change at page 20, line 17 ¶		skipping to change at page 22, line 36 ¶
	o Generate an ephemeral ECDH key pair as specified in Section 5 of		o Generate an ephemeral ECDH key pair as specified in Section 5 of
	[SP-800-56A] using the curve in the selected cipher suite and		[SP-800-56A] using the curve in the selected cipher suite and
	format it as a COSE_Key. Let G_X be the 'x' parameter of the		format it as a COSE_Key. Let G_X be the 'x' parameter of the
	COSE_Key.		COSE_Key.
	o Choose a connection identifier C_I and store it for the length of		o Choose a connection identifier C_I and store it for the length of
	the protocol.		the protocol.
	o Encode message_1 as a sequence of CBOR encoded data items as		o Encode message_1 as a sequence of CBOR encoded data items as
	specified in Section 4.4.1		specified in Section 5.2.1
	4.4.3. Responder Processing of Message 1		5.2.3. Responder Processing of Message 1
	The Responder SHALL process message_1 as follows:		The Responder SHALL process message_1 as follows:
	o Decode message_1 (see Appendix A.1).		o Decode message_1 (see Appendix A.1).
	o Verify that the selected cipher suite is supported and that no		o Verify that the selected cipher suite is supported and that no
	prior cipher suites in SUITES_I are supported.		prior cipher suite in SUITES_I is supported.
	o Pass AD_1 to the security application.		o Pass AD_1 to the security application.
	If any verification step fails, the Initiator MUST send an EDHOC		If any verification step fails, the Responder MUST send an EDHOC
	error message back, formatted as defined in Section 5, and the		error message back, formatted as defined in Section 6, and the
	protocol MUST be discontinued. If the Responder does not support the		protocol MUST be discontinued. If the Responder does not support the
	selected cipher suite, then SUITES_R MUST include one or more		selected cipher suite, then SUITES_R MUST include one or more
	supported cipher suites. If the Responder does not support the		supported cipher suites. If the Responder does not support the
	selected cipher suite, but supports another cipher suite in SUITES_I,		selected cipher suite, but supports another cipher suite in SUITES_I,
	then SUITES_R MUST include the first supported cipher suite in		then SUITES_R MUST include the first supported cipher suite in
	SUITES_I.		SUITES_I.
	4.5. EDHOC Message 2		5.3. EDHOC Message 2
	4.5.1. Formatting of Message 2		5.3.1. Formatting of Message 2
	message_2 and data_2 SHALL be CBOR Sequences (see Appendix A.1) as		message_2 and data_2 SHALL be CBOR Sequences (see Appendix A.1) as
	defined below		defined below
	message_2 = (		message_2 = (
	data_2,		data_2,
	CIPHERTEXT_2 : bstr,		CIPHERTEXT_2 : bstr,
	)		)
	data_2 = (		data_2 = (
	? C_I : bstr_identifier,		? C_I : bstr_identifier,
	G_Y : bstr,		G_Y : bstr,
	C_R : bstr_identifier,		C_R : bstr_identifier,
	)		)
	where:		where:
	o G_Y - the ephemeral public key of the Responder		o G_Y - the ephemeral public key of the Responder
	skipping to change at page 21, line 15 ¶		skipping to change at page 23, line 32 ¶
	? C_I : bstr_identifier,		? C_I : bstr_identifier,
	G_Y : bstr,		G_Y : bstr,
	C_R : bstr_identifier,		C_R : bstr_identifier,
	)		)
	where:		where:
	o G_Y - the ephemeral public key of the Responder		o G_Y - the ephemeral public key of the Responder
	o C_R - variable length connection identifier, encoded as a		o C_R - variable length connection identifier, encoded as a
	bstr_identifier (see Section 4.3).		bstr_identifier (see Section 5.1).
	4.5.2. Responder Processing of Message 2		5.3.2. Responder Processing of Message 2
	The Responder SHALL compose message_2 as follows:		The Responder SHALL compose message_2 as follows:
	o If corr (METHOD_CORR mod 4) equals 1 or 3, C_I is omitted,		o If corr (METHOD_CORR mod 4) equals 1 or 3, C_I is omitted,
	otherwise C_I is not omitted.		otherwise C_I is not omitted.
	o Generate an ephemeral ECDH key pair as specified in Section 5 of		o Generate an ephemeral ECDH key pair as specified in Section 5 of
	[SP-800-56A] using the curve in the selected cipher suite and		[SP-800-56A] using the curve in the selected cipher suite and
	format it as a COSE_Key. Let G_Y be the 'x' parameter of the		format it as a COSE_Key. Let G_Y be the 'x' parameter of the
	COSE_Key.		COSE_Key.
	skipping to change at page 21, line 44 ¶		skipping to change at page 24, line 14 ¶
	hash TH_2 is a CBOR encoded bstr and the input to the hash		hash TH_2 is a CBOR encoded bstr and the input to the hash
	function is a CBOR Sequence.		function is a CBOR Sequence.
	o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of		o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of
	[RFC8152], with the EDHOC AEAD algorithm in the selected cipher		[RFC8152], with the EDHOC AEAD algorithm in the selected cipher
	suite, K_2m, IV_2m, and the following parameters:		suite, K_2m, IV_2m, and the following parameters:
	* protected = << ID_CRED_R >>		* protected = << ID_CRED_R >>
	+ ID_CRED_R - identifier to facilitate retrieval of CRED_R,		+ ID_CRED_R - identifier to facilitate retrieval of CRED_R,
	see Section 4.2		see Section 3.3.4
	* external_aad = << TH_2, CRED_R, ? AD_2 >>		* external_aad = << TH_2, CRED_R, ? AD_2 >>
	+ CRED_R - bstr containing the credential of the Responder,		+ CRED_R - bstr containing the credential of the Responder,
	see Section 4.2.		see Section 3.3.4.
	+ AD_2 = bstr containing opaque unprotected auxiliary data		+ AD_2 = bstr containing opaque unprotected auxiliary data
	* plaintext = h''		* plaintext = h''
	COSE constructs the input to the AEAD [RFC5116] as follows:		COSE constructs the input to the AEAD [RFC5116] as follows:
	* Key K = EDHOC-KDF( PRK_3e2m, TH_2, "K_2m", length )		* Key K = EDHOC-KDF( PRK_3e2m, TH_2, "K_2m", length )
	* Nonce N = EDHOC-KDF( PRK_3e2m, TH_2, "IV_2m", length )		* Nonce N = EDHOC-KDF( PRK_3e2m, TH_2, "IV_2m", length )
	* Plaintext P = 0x (the empty string)		* Plaintext P = 0x (the empty string)
	* Associated data A =		* Associated data A =
	[ "Encrypt0", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >> ]		[ "Encrypt0", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >> ]
	MAC_2 is the 'ciphertext' of the inner COSE_Encrypt0.		MAC_2 is the 'ciphertext' of the inner COSE_Encrypt0.
	o If the Reponder authenticates with a static Diffie-Hellman key		o If the Responder authenticates with a static Diffie-Hellman key
	(method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the		(method equals 1 or 3), then Signature_or_MAC_2 is MAC_2. If the
	Reponder authenticates with a signature key (method equals 0 or		Responder authenticates with a signature key (method equals 0 or
	2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1		2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1
	object as defined in Section 4.4 of [RFC8152] using the signature		object as defined in Section 4.4 of [RFC8152] using the signature
	algorithm in the selected cipher suite, the private authentication		algorithm in the selected cipher suite, the private authentication
	key of the Responder, and the following parameters:		key of the Responder, and the following parameters:
	* protected = << ID_CRED_R >>		* protected = << ID_CRED_R >>
	* external_aad = << TH_2, CRED_R, ? AD_2 >>		* external_aad = << TH_2, CRED_R, ? AD_2 >>
	* payload = MAC_2		* payload = MAC_2
	skipping to change at page 22, line 34 ¶		skipping to change at page 25, line 4 ¶
	2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1		2), then Signature_or_MAC_2 is the 'signature' of a COSE_Sign1
	object as defined in Section 4.4 of [RFC8152] using the signature		object as defined in Section 4.4 of [RFC8152] using the signature
	algorithm in the selected cipher suite, the private authentication		algorithm in the selected cipher suite, the private authentication
	key of the Responder, and the following parameters:		key of the Responder, and the following parameters:
	* protected = << ID_CRED_R >>		* protected = << ID_CRED_R >>
	* external_aad = << TH_2, CRED_R, ? AD_2 >>		* external_aad = << TH_2, CRED_R, ? AD_2 >>
	* payload = MAC_2		* payload = MAC_2
	COSE constructs the input to the Signature Algorithm as:		COSE constructs the input to the Signature Algorithm as:
	* The key is the private authentication key of the Responder.		* The key is the private authentication key of the Responder.
	* The message M to be signed =		* The message M to be signed =
	[ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >>,		[ "Signature1", << ID_CRED_R >>, << TH_2, CRED_R, ? AD_2 >>,
	MAC_2 ]		MAC_2 ]
	o CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a		o Compute an outer COSE_Encrypt0 as defined in Section 5.3 of
	plaintext with the following common parameters:		[RFC8152], with the EDHOC AEAD algorithm in the selected cipher
			suite, K_2e, IV_2e, and the following parameters. The protected
			header SHALL be empty.
	* plaintext = ( ID_CRED_R / bstr_identifier, Signature_or_MAC_2,		* plaintext = ( ID_CRED_R / bstr_identifier, Signature_or_MAC_2,
	? AD_2 )		? AD_2 )
	+ Note that if ID_CRED_R contains a single 'kid' parameter,		+ Note that if ID_CRED_R contains a single 'kid' parameter,
	i.e., ID_CRED_R = { 4 : kid_R }, only the byte string kid_R		i.e., ID_CRED_R = { 4 : kid_R }, only the byte string kid_R
	is conveyed in the plaintext encoded as a bstr_identifier,		is conveyed in the plaintext encoded as a bstr_identifier,
	see Section 4.2 and Section 4.3.		see Section 3.3.4 and Section 5.1.
	* CIPHERTEXT_2 = plaintext XOR K_2e		COSE constructs the input to the AEAD [RFC5116] as follows:
	* K_2e = EDHOC-KDF( PRK_2e, TH_2, "K_2e", length ), where length		* Key K = EDHOC-KDF( PRK_2e, TH_2, "K_2e", length )
	is the length of the plaintext.
			* Nonce N = EDHOC-KDF( PRK_2e, TH_2, "IV_2e", length )
			* Plaintext P = ( ID_CRED_R / bstr_identifier,
			Signature_or_MAC_2, ? AD_2 )
			* Associated data A = [ "Encrypt0", h'', TH_2 ]
			CIPHERTEXT_2 is the 'ciphertext' of the outer COSE_Encrypt0 with
			the tag removed.
	o Encode message_2 as a sequence of CBOR encoded data items as		o Encode message_2 as a sequence of CBOR encoded data items as
	specified in Section 4.5.1.		specified in Section 5.3.1.
	4.5.3. Initiator Processing of Message 2		5.3.3. Initiator Processing of Message 2
	The Initiator SHALL process message_2 as follows:		The Initiator SHALL process message_2 as follows:
	o Decode message_2 (see Appendix A.1).		o Decode message_2 (see Appendix A.1).
	o Retrieve the protocol state using the connection identifier C_I		o Retrieve the protocol state using the connection identifier C_I
	and/or other external information such as the CoAP Token and the		and/or other external information such as the CoAP Token and the
	5-tuple.		5-tuple.
	o Decrypt CIPHERTEXT_2. The decryption process depends on the		o Decrypt CIPHERTEXT_2 by computing an outer COSE_Encrypt0 as
	method, see Section 4.5.2.		defined in see Section 5.3.2 and XORing CIPHERTEXT_2 with the
			'ciphertext' of the outer COSE_Encrypt0 with the tag removed.
	o Verify that the identity of the Responder is an allowed identity		o Verify that the identity of the Responder is an allowed identity
	for this connection, see Section 3.2.		for this connection, see Section 3.3.
	o Verify Signature_or_MAC_2 using the algorithm in the selected		o Verify Signature_or_MAC_2 using the algorithm in the selected
	cipher suite. The verification process depends on the method, see		cipher suite. The verification process depends on the method, see
	Section 4.5.2.		Section 5.3.2.
	o Pass AD_2 to the security application.		o Pass AD_2 to the security application.
	If any verification step fails, the Responder MUST send an EDHOC		If any verification step fails, the Responder MUST send an EDHOC
	error message back, formatted as defined in Section 5, and the		error message back, formatted as defined in Section 6, and the
	protocol MUST be discontinued.		protocol MUST be discontinued.
	4.6. EDHOC Message 3		5.4. EDHOC Message 3
	4.6.1. Formatting of Message 3		5.4.1. Formatting of Message 3
	message_3 and data_3 SHALL be CBOR Sequences (see Appendix A.1) as		message_3 and data_3 SHALL be CBOR Sequences (see Appendix A.1) as
	defined below		defined below
	message_3 = (		message_3 = (
	data_3,		data_3,
	CIPHERTEXT_3 : bstr,		CIPHERTEXT_3 : bstr,
	)		)
	data_3 = (		data_3 = (
	? C_R : bstr_identifier,		? C_R : bstr_identifier,
	)		)
	4.6.2. Initiator Processing of Message 3		5.4.2. Initiator Processing of Message 3
	The Initiator SHALL compose message_3 as follows:		The Initiator SHALL compose message_3 as follows:
	o If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted,		o If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted,
	otherwise C_R is not omitted.		otherwise C_R is not omitted.
	o Compute the transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3)		o Compute the transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3)
	where H() is the hash function in the the selected cipher suite.		where H() is the hash function in the the selected cipher suite.
	The transcript hash TH_3 is a CBOR encoded bstr and the input to		The transcript hash TH_3 is a CBOR encoded bstr and the input to
	the hash function is a CBOR Sequence.		the hash function is a CBOR Sequence.
	o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of		o Compute an inner COSE_Encrypt0 as defined in Section 5.3 of
	[RFC8152], with the EDHOC AEAD algorithm in the selected cipher		[RFC8152], with the EDHOC AEAD algorithm in the selected cipher
	suite, K_3m, IV_3m, and the following parameters:		suite, K_3m, IV_3m, and the following parameters:
	* protected = << ID_CRED_I >>		* protected = << ID_CRED_I >>
	+ ID_CRED_I - identifier to facilitate retrieval of CRED_I,		+ ID_CRED_I - identifier to facilitate retrieval of CRED_I,
	see Section 4.2		see Section 3.3.4
	* external_aad = << TH_3, CRED_I, ? AD_3 >>		* external_aad = << TH_3, CRED_I, ? AD_3 >>
	+ CRED_I - bstr containing the credential of the Initiator,		+ CRED_I - bstr containing the credential of the Initiator,
	see Section 4.2.		see Section 3.3.4.
	+ AD_3 = bstr containing opaque protected auxiliary data		+ AD_3 = bstr containing opaque protected auxiliary data
	* plaintext = h''		* plaintext = h''
	COSE constructs the input to the AEAD [RFC5116] as follows:		COSE constructs the input to the AEAD [RFC5116] as follows:
	* Key K = EDHOC-KDF( PRK_4x3m, TH_3, "K_3m", length )		* Key K = EDHOC-KDF( PRK_4x3m, TH_3, "K_3m", length )
	* Nonce N = EDHOC-KDF( PRK_4x3m, TH_3, "IV_3m", length )		* Nonce N = EDHOC-KDF( PRK_4x3m, TH_3, "IV_3m", length )
	skipping to change at page 25, line 41 ¶		skipping to change at page 28, line 21 ¶
	header SHALL be empty.		header SHALL be empty.
	* external_aad = TH_3		* external_aad = TH_3
	* plaintext = ( ID_CRED_I / bstr_identifier, Signature_or_MAC_3,		* plaintext = ( ID_CRED_I / bstr_identifier, Signature_or_MAC_3,
	? AD_3 )		? AD_3 )
	+ Note that if ID_CRED_I contains a single 'kid' parameter,		+ Note that if ID_CRED_I contains a single 'kid' parameter,
	i.e., ID_CRED_I = { 4 : kid_I }, only the byte string kid_I		i.e., ID_CRED_I = { 4 : kid_I }, only the byte string kid_I
	is conveyed in the plaintext encoded as a bstr_identifier,		is conveyed in the plaintext encoded as a bstr_identifier,
	see Section 4.2 and Section 4.3.		see Section 3.3.4 and Section 5.1.
	COSE constructs the input to the AEAD [RFC5116] as follows:		COSE constructs the input to the AEAD [RFC5116] as follows:
	* Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length )		* Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length )
	* Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length )		* Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length )
	* Plaintext P = ( ID_CRED_I / bstr_identifier,		* Plaintext P = ( ID_CRED_I / bstr_identifier,
	Signature_or_MAC_3, ? AD_3 )		Signature_or_MAC_3, ? AD_3 )
	skipping to change at page 26, line 4 ¶		skipping to change at page 28, line 33 ¶
	COSE constructs the input to the AEAD [RFC5116] as follows:		COSE constructs the input to the AEAD [RFC5116] as follows:
	* Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length )		* Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length )
	* Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length )		* Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length )
	* Plaintext P = ( ID_CRED_I / bstr_identifier,		* Plaintext P = ( ID_CRED_I / bstr_identifier,
	Signature_or_MAC_3, ? AD_3 )		Signature_or_MAC_3, ? AD_3 )
	* Associated data A = [ "Encrypt0", h'', TH_3 ]		* Associated data A = [ "Encrypt0", h'', TH_3 ]
	CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0.		CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0.
	o Encode message_3 as a sequence of CBOR encoded data items as		o Encode message_3 as a sequence of CBOR encoded data items as
	specified in Section 4.6.1.		specified in Section 5.4.1.
	Pass the connection identifiers (C_I, C_R) and the application		Pass the connection identifiers (C_I, C_R) and the application
	algorithms in the selected cipher suite to the application. The		algorithms in the selected cipher suite to the application. The
	application can now derive application keys using the EDHOC-Exporter		application can now derive application keys using the EDHOC-Exporter
	interface.		interface.
	After sending message_3, the Initiator is assured that no other party		After sending message_3, the Initiator is assured that no other party
	than the Responder can compute the key PRK_4x3m (implicit key		than the Responder can compute the key PRK_4x3m (implicit key
	authentication). The Initiator does however not know that the		authentication). The Initiator does however not know that the
	Responder has actually computed the key PRK_4x3m. While the		Responder has actually computed the key PRK_4x3m. While the
	Initiator can securely send protected application data, the Initiator		Initiator can securely send protected application data, the Initiator
	SHOULD NOT store the keying material PRK_4x3m and TH_4 until the		SHOULD NOT store the keying material PRK_4x3m and TH_4 until the
	Initiator is assured that the Responder has actually computed the key		Initiator is assured that the Responder has actually computed the key
	PRK_4x3m (explicit key confirmation). Explicit key confirmation is		PRK_4x3m (explicit key confirmation). Explicit key confirmation is
	e.g. assured when the Initiator has verified an OSCORE message from		e.g. assured when the Initiator has verified an OSCORE message from
	the Responder.		the Responder.
	4.6.3. Responder Processing of Message 3		5.4.3. Responder Processing of Message 3
	The Responder SHALL process message_3 as follows:		The Responder SHALL process message_3 as follows:
	o Decode message_3 (see Appendix A.1).		o Decode message_3 (see Appendix A.1).
	o Retrieve the protocol state using the connection identifier C_R		o Retrieve the protocol state using the connection identifier C_R
	and/or other external information such as the CoAP Token and the		and/or other external information such as the CoAP Token and the
	5-tuple.		5-tuple.
	o Decrypt and verify the outer COSE_Encrypt0 as defined in		o Decrypt and verify the outer COSE_Encrypt0 as defined in
	Section 5.3 of [RFC8152], with the EDHOC AEAD algorithm in the		Section 5.3 of [RFC8152], with the EDHOC AEAD algorithm in the
	selected cipher suite, K_3ae, and IV_3ae.		selected cipher suite, K_3ae, and IV_3ae.
	o Verify that the identity of the Initiator is an allowed identity		o Verify that the identity of the Initiator is an allowed identity
	for this connection, see Section 3.2.		for this connection, see Section 3.3.
	o Verify Signature_or_MAC_3 using the algorithm in the selected		o Verify Signature_or_MAC_3 using the algorithm in the selected
	cipher suite. The verification process depends on the method, see		cipher suite. The verification process depends on the method, see
	Section 4.6.2.		Section 5.4.2.
	o Pass AD_3, the connection identifiers (C_I, C_R), and the		o Pass AD_3, the connection identifiers (C_I, C_R), and the
	application algorithms in the selected cipher suite to the		application algorithms in the selected cipher suite to the
	security application. The application can now derive application		security application. The application can now derive application
	keys using the EDHOC-Exporter interface.		keys using the EDHOC-Exporter interface.
	If any verification step fails, the Responder MUST send an EDHOC		If any verification step fails, the Responder MUST send an EDHOC
	error message back, formatted as defined in Section 5, and the		error message back, formatted as defined in Section 6, and the
	protocol MUST be discontinued.		protocol MUST be discontinued.
	After verifying message_3, the Responder is assured that the		After verifying message_3, the Responder is assured that the
	Initiator has calculated the key PRK_4x3m (explicit key confirmation)		Initiator has calculated the key PRK_4x3m (explicit key confirmation)
	and that no other party than the Responder can compute the key. The		and that no other party than the Responder can compute the key. The
	Responder can securely send protected application data and store the		Responder can securely send protected application data and store the
	keying material PRK_4x3m and TH_4.		keying material PRK_4x3m and TH_4.
	5. Error Handling		6. Error Handling
	5.1. EDHOC Error Message		6.1. EDHOC Error Message
	This section defines a message format for the EDHOC error message,		This section defines a message format for the EDHOC error message,
	used during the protocol. An EDHOC error message can be sent by both		used during the protocol. An EDHOC error message can be sent by both
	parties as a reply to any non-error EDHOC message. After sending an		parties as a reply to any non-error EDHOC message. After sending an
	error message, the protocol MUST be discontinued. Errors at the		error message, the protocol MUST be discontinued. Errors at the
	EDHOC layer are sent as normal successful messages in the lower		EDHOC layer are sent as normal successful messages in the lower
	layers (e.g. CoAP POST and 2.04 Changed). An advantage of using		layers (e.g. CoAP POST and 2.04 Changed). An advantage of using
	such a construction is to avoid issues created by usage of cross		such a construction is to avoid issues created by usage of cross
	protocol proxies (e.g. UDP to TCP).		protocol proxies (e.g. UDP to TCP).
	error SHALL be a CBOR Sequence (see Appendix A.1) as defined below		error SHALL be a CBOR Sequence (see Appendix A.1) as defined below
	error = (		error = (
	? C_x : bstr_identifier,		? C_x : bstr_identifier,
	ERR_MSG : tstr,		ERR_MSG : tstr,
	? SUITES_R : [ supported : 2* suite ] / suite,		? SUITES_R : [ supported : 2* suite ] / suite,
	)		)
	where:		where:
	o C_x - variable length connection identifier, encoded as a		o C_x - (optional) variable length connection identifier, encoded as
	bstr_identifier (see Section 4.3). If error is sent by the		a bstr_identifier (see Section 5.1). If error is sent by the
	Responder and corr (METHOD_CORR mod 4) equals 0 or 2 then C_x is		Responder and corr (METHOD_CORR mod 4) equals 0 or 2 then C_x is
	set to C_I, else if error is sent by the Initiator and corr		set to C_I, else if error is sent by the Initiator and corr
	(METHOD_CORR mod 4) equals 0 or 1 then C_x is set to C_R, else C_x		(METHOD_CORR mod 4) equals 0 or 1 then C_x is set to C_R, else C_x
	is omitted.		is omitted.
	o ERR_MSG - text string containing the diagnostic payload, defined		o ERR_MSG - text string containing the diagnostic payload, defined
	in the same way as in Section 5.5.2 of [RFC7252]. ERR_MSG MAY be		in the same way as in Section 5.5.2 of [RFC7252]. ERR_MSG MAY be
	a 0-length text string.		a 0-length text string. This text string is mandatory and
			characteristic for error messages, which enables the receiver to
			distinguish between a normal message and an error message of the
			protocol.
	o SUITES_R - cipher suites from SUITES_I or the EDHOC cipher suites		o SUITES_R - (optional) cipher suites from SUITES_I or the EDHOC
	registry that the Responder supports. SUITES_R MUST only be		cipher suites registry that the Responder supports. SUITES_R MUST
	included in replies to message_1. If a single supported cipher		only be included in replies to message_1. If a single supported
	suite is conveyed then the supported cipher suite is encoded as an		cipher suite is conveyed then the supported cipher suite is
	int instead of an array.		encoded as an int instead of an array.
	After receiving SUITES_R, the Initiator can determine which selected		After receiving SUITES_R, the Initiator can determine which selected
	cipher suite to use for the next EDHOC run with the Responder. If		cipher suite to use for the next EDHOC run with the Responder. If
	the Initiator intends to contact the Responder in the future, the		the Initiator intends to contact the Responder in the future, the
	Initiator SHOULD remember which selected cipher suite to use until		Initiator SHOULD remember which selected cipher suite to use until
	the next message_1 has been sent, otherwise the Initiator and		the next message_1 has been sent, otherwise the Initiator and
	Responder will likely run into an infinite loop. After a successful		Responder will likely run into an infinite loop. After a successful
	run of EDHOC, the Initiator MAY remember the selected cipher suite to		run of EDHOC, the Initiator MAY remember the selected cipher suite to
	use in future EDHOC runs. Note that if the Initiator or Responder is		use in future EDHOC runs. Note that if the Initiator or Responder is
	updated with new cipher suite policies, any cached information may be		updated with new cipher suite policies, any cached information may be
	outdated.		outdated.
	5.1.1. Example Use of EDHOC Error Message with SUITES_R		6.1.1. Example Use of EDHOC Error Message with SUITES_R
	Assuming that the Initiator supports the five cipher suites 5, 6, 7,		Assuming that the Initiator supports the five cipher suites 5, 6, 7,
	8, and 9 in decreasing order of preference, Figures 5 and 6 show		8, and 9 in decreasing order of preference, Figures 5 and 6 show
	examples of how the Responder can truncate SUITES_I and how SUITES_R		examples of how the Initiator can truncate SUITES_I and how SUITES_R
	is used by the Responder to give the Initiator information about the		is used by the Responder to give the Initiator information about the
	cipher suites that the Responder supports. In Figure 5, the		cipher suites that the Responder supports.
	Responder supports cipher suite 6 but not the selected cipher suite
	5.		In Figure 5, the Responder supports cipher suite 6 but not the
			initially selected cipher suite 5.
	Initiator Responder		Initiator Responder
	| METHOD_CORR, SUITES_I = [5, 5, 6, 7], G_X, C_I, AD_1 |		| METHOD_CORR, SUITES_I = 5, G_X, C_I, AD_1 |
	+------------------------------------------------------------------>|		+------------------------------------------------------------------>|
	| message_1 |		| message_1 |
	| |		| |
	| C_I, ERR_MSG, SUITES_R = 6 |		| C_I, ERR_MSG, SUITES_R = 6 |
	|<------------------------------------------------------------------+		|<------------------------------------------------------------------+
	| error |		| error |
	| |		| |
	| METHOD_CORR, SUITES_I = [6, 5, 6], G_X, C_I, AD_1 |		| METHOD_CORR, SUITES_I = [6, 5, 6], G_X, C_I, AD_1 |
	+------------------------------------------------------------------>|		+------------------------------------------------------------------>|
	| message_1 |		| message_1 |
	Figure 5: Example use of error message with SUITES_R.		Figure 5: Example use of error message with SUITES_R.
	In Figure 6, the Responder supports cipher suite 7 but not cipher		In Figure 6, the Responder supports cipher suite 7 and 9 but not the
	suites 5 and 6.		more preferred (by the Initiator) cipher suites 5 and 6. The order
			of cipher suites in SUITES_R does not matter.
	Initiator Responder		Initiator Responder
	| METHOD_CORR, SUITES_I = [5, 5, 6], G_X, C_I, AD_1 |		| METHOD_CORR, SUITES_I = 5, G_X, C_I, AD_1 |
	+------------------------------------------------------------------>|		+------------------------------------------------------------------>|
	| message_1 |		| message_1 |
	| |		| |
	| C_I, ERR_MSG, SUITES_R = [7, 9] |		| C_I, ERR_MSG, SUITES_R = [9, 7] |
	|<------------------------------------------------------------------+		|<------------------------------------------------------------------+
	| error |		| error |
	| |		| |
	| METHOD_CORR, SUITES_I = [7, 5, 6, 7], G_X, C_I, AD_1 |		| METHOD_CORR, SUITES_I = [7, 5, 6, 7], G_X, C_I, AD_1 |
	+------------------------------------------------------------------>|		+------------------------------------------------------------------>|
	| message_1 |		| message_1 |
	Figure 6: Example use of error message with SUITES_R.		Figure 6: Example use of error message with SUITES_R.
	As the Initiator's list of supported cipher suites and order of		Note that the Initiator's list of supported cipher suites and order
	preference is fixed, and the Responder only accepts message_1 if the		of preference is fixed (see Section 5.2.1 and Section 5.2.2).
			Furthermore, the Responder shall only accept message_1 if the
	selected cipher suite is the first cipher suite in SUITES_I that the		selected cipher suite is the first cipher suite in SUITES_I that the
	Responder supports, the parties can verify that the selected cipher		Responder supports (see Section 5.2.3). Following this procedure
	suite is the most preferred (by the Initiator) cipher suite supported		ensures that the selected cipher suite is the most preferred (by the
	by both parties. If the selected cipher suite is not the first		Initiator) cipher suite supported by both parties.
	cipher suite in SUITES_I that the Responder supports, the Responder
	will discontinue the protocol.
	6. Transferring EDHOC and Deriving an OSCORE Context		If the selected cipher suite is not the first cipher suite which the
			Responder supports in SUITES_I received in message_1, then Responder
			MUST discontinue the protocol, see Section 5.2.3. If SUITES_I in
			message_1 is manipulated then the integrity verification of message_2
			containing the transcript hash TH_2 = H( message_1, data_2 ) will
			fail and the Initiator will discontinue the protocol.
	6.1. Transferring EDHOC in CoAP		7. Transferring EDHOC and Deriving an OSCORE Context
			7.1. Transferring EDHOC in CoAP
	It is recommended to transport EDHOC as an exchange of CoAP [RFC7252]		It is recommended to transport EDHOC as an exchange of CoAP [RFC7252]
	messages. CoAP is a reliable transport that can preserve packet		messages. CoAP is a reliable transport that can preserve packet
	ordering and handle message duplication. CoAP can also perform		ordering and handle message duplication. CoAP can also perform
	fragmentation and protect against denial of service attacks. It is		fragmentation and protect against denial of service attacks. It is
	recommended to carry the EDHOC messages in Confirmable messages,		recommended to carry the EDHOC messages in Confirmable messages,
	especially if fragmentation is used.		especially if fragmentation is used.
	By default, the CoAP client is the Initiator and the CoAP server is		By default, the CoAP client is the Initiator and the CoAP server is
	the Responder, but the roles SHOULD be chosen to protect the most		the Responder, but the roles SHOULD be chosen to protect the most
	sensitive identity, see Section 7. By default, EDHOC is transferred		sensitive identity, see Section 8. By default, EDHOC is transferred
	in POST requests and 2.04 (Changed) responses to the Uri-Path:		in POST requests and 2.04 (Changed) responses to the Uri-Path:
	"/.well-known/edhoc", but an application may define its own path that		"/.well-known/edhoc", but an application may define its own path that
	can be discovered e.g. using resource directory		can be discovered e.g. using resource directory
	[I-D.ietf-core-resource-directory].		[I-D.ietf-core-resource-directory].
	By default, the message flow is as follows: EDHOC message_1 is sent		By default, the message flow is as follows: EDHOC message_1 is sent
	in the payload of a POST request from the client to the server's		in the payload of a POST request from the client to the server's
	resource for EDHOC. EDHOC message_2 or the EDHOC error message is		resource for EDHOC. EDHOC message_2 or the EDHOC error message is
	sent from the server to the client in the payload of a 2.04 (Changed)		sent from the server to the client in the payload of a 2.04 (Changed)
	response. EDHOC message_3 or the EDHOC error message is sent from		response. EDHOC message_3 or the EDHOC error message is sent from
	skipping to change at page 30, line 33 ¶		skipping to change at page 33, line 25 ¶
	| |		| |
	+--------->| Header: POST (Code=0.02)		+--------->| Header: POST (Code=0.02)
	| POST | Uri-Path: "/.well-known/edhoc"		| POST | Uri-Path: "/.well-known/edhoc"
	| | Content-Format: application/edhoc		| | Content-Format: application/edhoc
	| | Payload: EDHOC message_3		| | Payload: EDHOC message_3
	| |		| |
	|<---------+ Header: 2.04 Changed		|<---------+ Header: 2.04 Changed
	| 2.04 |		| 2.04 |
	| |		| |
	Figure 7: Transferring EDHOC in CoAP		Figure 7: Transferring EDHOC in CoAP when the Initiator is CoAP
			Client
	The exchange in Figure 7 protects the client identity against active		The exchange in Figure 7 protects the client identity against active
	attackers and the server identity against passive attackers. An		attackers and the server identity against passive attackers. An
	alternative exchange that protects the server identity against active		alternative exchange that protects the server identity against active
	attackers and the client identity against passive attackers is shown		attackers and the client identity against passive attackers is shown
	in Figure 8. In this case the CoAP Token enables the Responder to		in Figure 8. In this case the CoAP Token enables the Responder to
	correlate message_2 and message_3 so the correlation parameter corr =		correlate message_2 and message_3 so the correlation parameter corr =
	2.		2.
	Client Server		Client Server
	skipping to change at page 31, line 24 ¶		skipping to change at page 34, line 24 ¶
	+--------->| Header: POST (Code=0.02)		+--------->| Header: POST (Code=0.02)
	| POST | Uri-Path: "/.well-known/edhoc"		| POST | Uri-Path: "/.well-known/edhoc"
	| | Content-Format: application/edhoc		| | Content-Format: application/edhoc
	| | Payload: EDHOC message_2		| | Payload: EDHOC message_2
	| |		| |
	|<---------+ Header: 2.04 Changed		|<---------+ Header: 2.04 Changed
	| 2.04 | Content-Format: application/edhoc		| 2.04 | Content-Format: application/edhoc
	| | Payload: EDHOC message_3		| | Payload: EDHOC message_3
	| |		| |
	Figure 8: Transferring EDHOC in CoAP		Figure 8: Transferring EDHOC in CoAP when the Initiator is CoAP
			Server
	To protect against denial-of-service attacks, the CoAP server MAY		To protect against denial-of-service attacks, the CoAP server MAY
	respond to the first POST request with a 4.01 (Unauthorized)		respond to the first POST request with a 4.01 (Unauthorized)
	containing an Echo option [I-D.ietf-core-echo-request-tag]. This		containing an Echo option [I-D.ietf-core-echo-request-tag]. This
	forces the initiator to demonstrate its reachability at its apparent		forces the initiator to demonstrate its reachability at its apparent
	network address. If message fragmentation is needed, the EDHOC		network address. If message fragmentation is needed, the EDHOC
	messages may be fragmented using the CoAP Block-Wise Transfer		messages may be fragmented using the CoAP Block-Wise Transfer
	mechanism [RFC7959].		mechanism [RFC7959].
	6.1.1. Deriving an OSCORE Context from EDHOC		7.1.1. Deriving an OSCORE Context from EDHOC
	When EDHOC is used to derive parameters for OSCORE [RFC8613], the		When EDHOC is used to derive parameters for OSCORE [RFC8613], the
	parties make sure that the EDHOC connection identifiers are unique,		parties make sure that the EDHOC connection identifiers are unique,
	i.e. C_R MUST NOT be equal to C_I. The CoAP client and server MUST		i.e. C_R MUST NOT be equal to C_I. The CoAP client and server MUST
	be able to retrieve the OSCORE protocol state using its chosen		be able to retrieve the OSCORE protocol state using its chosen
	connection identifier and optionally other information such as the		connection identifier and optionally other information such as the
	5-tuple. In case that the CoAP client is the Initiator and the CoAP		5-tuple. In case that the CoAP client is the Initiator and the CoAP
	server is the Responder:		server is the Responder:
	o The client's OSCORE Sender ID is C_R and the server's OSCORE		o The client's OSCORE Sender ID is C_R and the server's OSCORE
	skipping to change at page 32, line 8 ¶		skipping to change at page 35, line 12 ¶
	o The AEAD Algorithm and the hash algorithm are the application AEAD		o The AEAD Algorithm and the hash algorithm are the application AEAD
	and hash algorithms in the selected cipher suite.		and hash algorithms in the selected cipher suite.
	o The Master Secret and Master Salt are derived as follows where		o The Master Secret and Master Salt are derived as follows where
	length is the key length (in bytes) of the application AEAD		length is the key length (in bytes) of the application AEAD
	Algorithm.		Algorithm.
	Master Secret = EDHOC-Exporter( "OSCORE Master Secret", length )		Master Secret = EDHOC-Exporter( "OSCORE Master Secret", length )
	Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 )		Master Salt = EDHOC-Exporter( "OSCORE Master Salt", 8 )
	7. Security Considerations		8. Security Considerations
	7.1. Security Properties		8.1. Security Properties
	EDHOC inherits its security properties from the theoretical SIGMA-I		EDHOC inherits its security properties from the theoretical SIGMA-I
	protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides		protocol [SIGMA]. Using the terminology from [SIGMA], EDHOC provides
	perfect forward secrecy, mutual authentication with aliveness,		perfect forward secrecy, mutual authentication with aliveness,
	consistency, peer awareness. As described in [SIGMA], peer awareness		consistency, peer awareness. As described in [SIGMA], peer awareness
	is provided to the Responder, but not to the Initiator.		is provided to the Responder, but not to the Initiator.
	EDHOC protects the credential identifier of the Initiator against		EDHOC protects the credential identifier of the Initiator against
	active attacks and the credential identifier of the Responder against		active attacks and the credential identifier of the Responder against
	passive attacks. The roles should be assigned to protect the most		passive attacks. The roles should be assigned to protect the most
	skipping to change at page 33, line 42 ¶		skipping to change at page 36, line 46 ¶
	ephemeral secret key can only attack that specific protocol run.		ephemeral secret key can only attack that specific protocol run.
	Repudiation: In EDHOC authenticated with signature keys, the		Repudiation: In EDHOC authenticated with signature keys, the
	Initiator could theoretically prove that the Responder performed a		Initiator could theoretically prove that the Responder performed a
	run of the protocol by presenting the private ephemeral key, and vice		run of the protocol by presenting the private ephemeral key, and vice
	versa. Note that storing the private ephemeral keys violates the		versa. Note that storing the private ephemeral keys violates the
	protocol requirements. With static Diffie-Hellman key		protocol requirements. With static Diffie-Hellman key
	authentication, both parties can always deny having participated in		authentication, both parties can always deny having participated in
	the protocol.		the protocol.
	7.2. Cryptographic Considerations		8.2. Cryptographic Considerations
	The security of the SIGMA protocol requires the MAC to be bound to		The security of the SIGMA protocol requires the MAC to be bound to
	the identity of the signer. Hence the message authenticating		the identity of the signer. Hence the message authenticating
	functionality of the authenticated encryption in EDHOC is critical:		functionality of the authenticated encryption in EDHOC is critical:
	authenticated encryption MUST NOT be replaced by plain encryption		authenticated encryption MUST NOT be replaced by plain encryption
	only, even if authentication is provided at another level or through		only, even if authentication is provided at another level or through
	a different mechanism. EDHOC implements SIGMA-I using the same Sign-		a different mechanism. EDHOC implements SIGMA-I using the same Sign-
	then-MAC approach as TLS 1.3.		then-MAC approach as TLS 1.3.
	To reduce message overhead EDHOC does not use explicit nonces and		To reduce message overhead EDHOC does not use explicit nonces and
	skipping to change at page 34, line 25 ¶		skipping to change at page 37, line 27 ¶
	Initiator and the Responder should enforce a minimum security level.		Initiator and the Responder should enforce a minimum security level.
	The data rates in many IoT deployments are very limited. Given that		The data rates in many IoT deployments are very limited. Given that
	the application keys are protected as well as the long-term		the application keys are protected as well as the long-term
	authentication keys they can often be used for years or even decades		authentication keys they can often be used for years or even decades
	before the cryptographic limits are reached. If the application keys		before the cryptographic limits are reached. If the application keys
	established through EDHOC need to be renewed, the communicating		established through EDHOC need to be renewed, the communicating
	parties can derive application keys with other labels or run EDHOC		parties can derive application keys with other labels or run EDHOC
	again.		again.
	7.3. Cipher Suites		8.3. Cipher Suites
	Cipher suite number 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA,		Cipher suite number 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA,
	Ed25519, AES-CCM-16-64-128, SHA-256) is mandatory to implement.		Ed25519, AES-CCM-16-64-128, SHA-256) is mandatory to implement.
	Implementations only need to implement the algorithms needed for		Implementations only need to implement the algorithms needed for
	their supported methods. For many constrained IoT devices it is		their supported methods. For many constrained IoT devices it is
	problematic to support more than one cipher suites, so some		problematic to support more than one cipher suites, so some
	deployments with P-256 may not support the mandatory cipher suite.		deployments with P-256 may not support the mandatory cipher suite.
	This is not a problem for local deployments.		This is not a problem for local deployments.
	The HMAC algorithm HMAC 256/64 (HMAC w/ SHA-256 truncated to 64 bits)		The HMAC algorithm HMAC 256/64 (HMAC w/ SHA-256 truncated to 64 bits)
	SHALL NOT be supported for use in EDHOC.		SHALL NOT be supported for use in EDHOC.
	7.4. Unprotected Data		8.4. Unprotected Data
	The Initiator and the Responder must make sure that unprotected data		The Initiator and the Responder must make sure that unprotected data
	and metadata do not reveal any sensitive information. This also		and metadata do not reveal any sensitive information. This also
	applies for encrypted data sent to an unauthenticated party. In		applies for encrypted data sent to an unauthenticated party. In
	particular, it applies to AD_1, ID_CRED_R, AD_2, and ERR_MSG. Using		particular, it applies to AD_1, ID_CRED_R, AD_2, and ERR_MSG. Using
	the same AD_1 in several EDHOC sessions allows passive eavesdroppers		the same AD_1 in several EDHOC sessions allows passive eavesdroppers
	to correlate the different sessions. Another consideration is that		to correlate the different sessions. Another consideration is that
	the list of supported cipher suites may potentially be used to		the list of supported cipher suites may potentially be used to
	identify the application.		identify the application.
	The Initiator and the Responder must also make sure that		The Initiator and the Responder must also make sure that
	unauthenticated data does not trigger any harmful actions. In		unauthenticated data does not trigger any harmful actions. In
	particular, this applies to AD_1 and ERR_MSG.		particular, this applies to AD_1 and ERR_MSG.
	7.5. Denial-of-Service		8.5. Denial-of-Service
	EDHOC itself does not provide countermeasures against Denial-of-		EDHOC itself does not provide countermeasures against Denial-of-
	Service attacks. By sending a number of new or replayed message_1 an		Service attacks. By sending a number of new or replayed message_1 an
	attacker may cause the Responder to allocate state, perform		attacker may cause the Responder to allocate state, perform
	cryptographic operations, and amplify messages. To mitigate such		cryptographic operations, and amplify messages. To mitigate such
	attacks, an implementation SHOULD rely on lower layer mechanisms such		attacks, an implementation SHOULD rely on lower layer mechanisms such
	as the Echo option in CoAP [I-D.ietf-core-echo-request-tag] that		as the Echo option in CoAP [I-D.ietf-core-echo-request-tag] that
	forces the initiator to demonstrate reachability at its apparent		forces the initiator to demonstrate reachability at its apparent
	network address.		network address.
	7.6. Implementation Considerations		8.6. Implementation Considerations
	The availability of a secure pseudorandom number generator and truly		The availability of a secure pseudorandom number generator and truly
	random seeds are essential for the security of EDHOC. If no true		random seeds are essential for the security of EDHOC. If no true
	random number generator is available, a truly random seed must be		random number generator is available, a truly random seed must be
	provided from an external source. As each pseudorandom number must		provided from an external source. As each pseudorandom number must
	only be used once, an implementation need to get a new truly random		only be used once, an implementation need to get a new truly random
	seed after reboot, or continuously store state in nonvolatile memory,		seed after reboot, or continuously store state in nonvolatile memory,
	see ([RFC8613], Appendix B.1.1) for issues and solution approaches		see ([RFC8613], Appendix B.1.1) for issues and solution approaches
	for writing to nonvolatile memory. If ECDSA is supported,		for writing to nonvolatile memory. If ECDSA is supported,
	"deterministic ECDSA" as specified in [RFC6979] is RECOMMENDED.		"deterministic ECDSA" as specified in [RFC6979] is RECOMMENDED.
	skipping to change at page 36, line 18 ¶		skipping to change at page 39, line 22 ¶
	If two nodes unintentionally initiate two simultaneous EDHOC message		If two nodes unintentionally initiate two simultaneous EDHOC message
	exchanges with each other even if they only want to complete a single		exchanges with each other even if they only want to complete a single
	EDHOC message exchange, they MAY terminate the exchange with the		EDHOC message exchange, they MAY terminate the exchange with the
	lexicographically smallest G_X. If the two G_X values are equal, the		lexicographically smallest G_X. If the two G_X values are equal, the
	received message_1 MUST be discarded to mitigate reflection attacks.		received message_1 MUST be discarded to mitigate reflection attacks.
	Note that in the case of two simultaneous EDHOC exchanges where the		Note that in the case of two simultaneous EDHOC exchanges where the
	nodes only complete one and where the nodes have different preferred		nodes only complete one and where the nodes have different preferred
	cipher suites, an attacker can affect which of the two nodes'		cipher suites, an attacker can affect which of the two nodes'
	preferred cipher suites will be used by blocking the other exchange.		preferred cipher suites will be used by blocking the other exchange.
	7.7. Other Documents Referencing EDHOC		8.7. Other Documents Referencing EDHOC
	EDHOC has been analyzed in several other documents. A formal		EDHOC has been analyzed in several other documents. A formal
	verification of EDHOC was done in [SSR18], an analysis of EDHOC for		verification of EDHOC was done in [SSR18], an analysis of EDHOC for
	certificate enrollment was done in [Kron18], the use of EDHOC in		certificate enrollment was done in [Kron18], the use of EDHOC in
	LoRaWAN is analyzed in [LoRa1] and [LoRa2], the use of EDHOC in IoT		LoRaWAN is analyzed in [LoRa1] and [LoRa2], the use of EDHOC in IoT
	bootstrapping is analyzed in [Perez18], and the use of EDHOC in		bootstrapping is analyzed in [Perez18], and the use of EDHOC in
	6TiSCH is described in [I-D.ietf-6tisch-dtsecurity-zerotouch-join].		6TiSCH is described in [I-D.ietf-6tisch-dtsecurity-zerotouch-join].
	8. IANA Considerations		9. IANA Considerations
	8.1. EDHOC Cipher Suites Registry		9.1. EDHOC Cipher Suites Registry
	IANA has created a new registry titled "EDHOC Cipher Suites" under		IANA has created a new registry titled "EDHOC Cipher Suites" under
	the new heading "EDHOC". The registration procedure is "Expert		the new heading "EDHOC". The registration procedure is "Expert
	Review". The columns of the registry are Value, Array, Description,		Review". The columns of the registry are Value, Array, Description,
	and Reference, where Value is an integer and the other columns are		and Reference, where Value is an integer and the other columns are
	text strings. The initial contents of the registry are:		text strings. The initial contents of the registry are:
	Value: -24		Value: -24
	Algorithms: N/A		Algorithms: N/A
	Desc: Reserved for Private Use		Desc: Reserved for Private Use
	Reference: [[this document]]		Reference: [[this document]]
	Value: -23		Value: -23
	Algorithms: N/A		Algorithms: N/A
	Desc: Reserved for Private Use		Desc: Reserved for Private Use
	Reference: [[this document]]		Reference: [[this document]]
			Value: -22
			Algorithms: N/A
			Desc: Reserved for Private Use
			Reference: [[this document]]
			Value: -21
			Algorithms: N/A
			Desc: Reserved for Private Use
			Reference: [[this document]]
	Value: 0		Value: 0
	Array: 10, 5, 4, -8, 6, 10, 5		Array: 10, 5, 4, -8, 6, 10, 5
	Desc: AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519,		Desc: AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519,
	AES-CCM-16-64-128, SHA-256		AES-CCM-16-64-128, SHA-256
	Reference: [[this document]]		Reference: [[this document]]
	Value: 1		Value: 1
	Array: 30, 5, 4, -8, 6, 10, 5		Array: 30, 5, 4, -8, 6, 10, 5
	Desc: AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519,		Desc: AES-CCM-16-128-128, SHA-256, X25519, EdDSA, Ed25519,
	AES-CCM-16-64-128, SHA-256		AES-CCM-16-64-128, SHA-256
	Reference: [[this document]]		Reference: [[this document]]
	Value: 2		Value: 2
	Array: 10, 5, 1, -7, 1, 10, 5		Array: 10, 5, 1, -7, 1, 10, 5
	Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256,		Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256,
	AES-CCM-16-64-128, SHA-256		AES-CCM-16-64-128, SHA-256
	skipping to change at page 37, line 22 ¶		skipping to change at page 40, line 38 ¶
	Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256,		Desc: AES-CCM-16-64-128, SHA-256, P-256, ES256, P-256,
	AES-CCM-16-64-128, SHA-256		AES-CCM-16-64-128, SHA-256
	Reference: [[this document]]		Reference: [[this document]]
	Value: 3		Value: 3
	Array: 30, 5, 1, -7, 1, 10, 5		Array: 30, 5, 1, -7, 1, 10, 5
	Desc: AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256,		Desc: AES-CCM-16-128-128, SHA-256, P-256, ES256, P-256,
	AES-CCM-16-64-128, SHA-256		AES-CCM-16-64-128, SHA-256
	Reference: [[this document]]		Reference: [[this document]]
	8.2. EDHOC Method Type Registry		Value: 4
			Array: 1, -16, 4, -7, 1, 1, -16
			Desc: A128GCM, SHA-256, X25519, ES256, P-256,
			A128GCM, SHA-256
			Reference: [[this document]]
			Value: 5
			Array: 3, -43, 2, -35, 2, 3, -43
			Desc: A256GCM, SHA-384, P-384, ES384, P-384,
			A256GCM, SHA-384
			Reference: [[this document]]
			9.2. EDHOC Method Type Registry
	IANA has created a new registry titled "EDHOC Method Type" under the		IANA has created a new registry titled "EDHOC Method Type" under the
	new heading "EDHOC". The registration procedure is "Expert Review".		new heading "EDHOC". The registration procedure is "Expert Review".
	The columns of the registry are Value, Description, and Reference,		The columns of the registry are Value, Description, and Reference,
	where Value is an integer and the other columns are text strings.		where Value is an integer and the other columns are text strings.
	The initial contents of the registry are:		The initial contents of the registry is shown in Figure 4.
	+-------+-------------------+-------------------+-------------------+
	| Value | Initiator | Responder | Reference |
	+-------+-------------------+-------------------+-------------------+
	| 0 | Signature Key | Signature Key | [[this document]] |
	| 1 | Signature Key | Static DH Key | [[this document]] |
	| 2 | Static DH Key | Signature Key | [[this document]] |
	| 3 | Static DH Key | Static DH Key | [[this document]] |
	+-------+-------------------+-------------------+-------------------+
	Figure 9: Method Types
	8.3. The Well-Known URI Registry		9.3. The Well-Known URI Registry
	IANA has added the well-known URI 'edhoc' to the Well-Known URIs		IANA has added the well-known URI 'edhoc' to the Well-Known URIs
	registry.		registry.
	o URI suffix: edhoc		o URI suffix: edhoc
	o Change controller: IETF		o Change controller: IETF
	o Specification document(s): [[this document]]		o Specification document(s): [[this document]]
	o Related information: None		o Related information: None
	8.4. Media Types Registry		9.4. Media Types Registry
	IANA has added the media type 'application/edhoc' to the Media Types		IANA has added the media type 'application/edhoc' to the Media Types
	registry.		registry.
	o Type name: application		o Type name: application
	o Subtype name: edhoc		o Subtype name: edhoc
	o Required parameters: N/A		o Required parameters: N/A
	skipping to change at page 39, line 5 ¶		skipping to change at page 42, line 22 ¶
	"Authors' Addresses" section.		"Authors' Addresses" section.
	o Intended usage: COMMON		o Intended usage: COMMON
	o Restrictions on usage: N/A		o Restrictions on usage: N/A
	o Author: See "Authors' Addresses" section.		o Author: See "Authors' Addresses" section.
	o Change Controller: IESG		o Change Controller: IESG
	8.5. CoAP Content-Formats Registry		9.5. CoAP Content-Formats Registry
	IANA has added the media type 'application/edhoc' to the CoAP		IANA has added the media type 'application/edhoc' to the CoAP
	Content-Formats registry.		Content-Formats registry.
	o Media Type: application/edhoc		o Media Type: application/edhoc
	o Encoding:		o Encoding:
	o ID: TBD42		o ID: TBD42
	o Reference: [[this document]]		o Reference: [[this document]]
	8.6. Expert Review Instructions		9.6. Expert Review Instructions
	The IANA Registries established in this document is defined as		The IANA Registries established in this document is defined as
	"Expert Review". This section gives some general guidelines for what		"Expert Review". This section gives some general guidelines for what
	the experts should be looking for, but they are being designated as		the experts should be looking for, but they are being designated as
	experts for a reason so they should be given substantial latitude.		experts for a reason so they should be given substantial latitude.
	Expert reviewers should take into consideration the following points:		Expert reviewers should take into consideration the following points:
	o Clarity and correctness of registrations. Experts are expected to		o 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.
	skipping to change at page 39, line 46 ¶		skipping to change at page 43, line 15 ¶
	o Experts should take into account the expected usage of fields when		o Experts should take into account the expected usage of fields when
	approving point assignment. The length of the encoded value		approving point assignment. The length of the encoded value
	should be weighed against how many code points of that length are		should be weighed against how many code points of that length are
	left, the size of device it will be used on, and the number of		left, the size of device it will be used on, and the number of
	code points left that encode to that size.		code points left that encode to that size.
	o Specifications are recommended. When specifications are not		o Specifications are recommended. When specifications are not
	provided, the description provided needs to have sufficient		provided, the description provided needs to have sufficient
	information to verify the points above.		information to verify the points above.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[I-D.ietf-core-echo-request-tag]		[I-D.ietf-core-echo-request-tag]
	Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,		Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
	Request-Tag, and Token Processing", draft-ietf-core-echo-		Request-Tag, and Token Processing", draft-ietf-core-echo-
	request-tag-10 (work in progress), July 2020.		request-tag-11 (work in progress), November 2020.
	[I-D.ietf-cose-x509]		[I-D.ietf-cose-x509]
	Schaad, J., "CBOR Object Signing and Encryption (COSE):		Schaad, J., "CBOR Object Signing and Encryption (COSE):
	Header parameters for carrying and referencing X.509		Header parameters for carrying and referencing X.509
	certificates", draft-ietf-cose-x509-07 (work in progress),		certificates", draft-ietf-cose-x509-08 (work in progress),
	September 2020.		December 2020.
	[I-D.ietf-lake-reqs]		[I-D.ietf-lake-reqs]
	Vucinic, M., Selander, G., Mattsson, J., and D. Garcia-		Vucinic, M., Selander, G., Mattsson, J., and D. Garcia-
	Carillo, "Requirements for a Lightweight AKE for OSCORE",		Carillo, "Requirements for a Lightweight AKE for OSCORE",
	draft-ietf-lake-reqs-04 (work in progress), June 2020.		draft-ietf-lake-reqs-04 (work in progress), June 2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 40, line 45 ¶		skipping to change at page 44, line 10 ¶
	[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic		[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
	Curve Cryptography Algorithms", RFC 6090,		Curve Cryptography Algorithms", RFC 6090,
	DOI 10.17487/RFC6090, February 2011,		DOI 10.17487/RFC6090, February 2011,
	<https://www.rfc-editor.org/info/rfc6090>.		<https://www.rfc-editor.org/info/rfc6090>.
	[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature		[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
	Algorithm (DSA) and Elliptic Curve Digital Signature		Algorithm (DSA) and Elliptic Curve Digital Signature
	Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August		Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
	2013, <https://www.rfc-editor.org/info/rfc6979>.		2013, <https://www.rfc-editor.org/info/rfc6979>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[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-editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves		[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
	for Security", RFC 7748, DOI 10.17487/RFC7748, January		for Security", RFC 7748, DOI 10.17487/RFC7748, January
	2016, <https://www.rfc-editor.org/info/rfc7748>.		2016, <https://www.rfc-editor.org/info/rfc7748>.
	[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in		[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
	skipping to change at page 41, line 41 ¶		skipping to change at page 45, line 5 ¶
	[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,		(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
	<https://www.rfc-editor.org/info/rfc8613>.		<https://www.rfc-editor.org/info/rfc8613>.
	[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)		[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
	Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,		Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
	<https://www.rfc-editor.org/info/rfc8742>.		<https://www.rfc-editor.org/info/rfc8742>.
	9.2. Informative References		[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
			Representation (CBOR)", STD 94, RFC 8949,
			DOI 10.17487/RFC8949, December 2020,
			<https://www.rfc-editor.org/info/rfc8949>.
			10.2. Informative References
	[CborMe] Bormann, C., "CBOR Playground", May 2018,		[CborMe] Bormann, C., "CBOR Playground", May 2018,
	<http://cbor.me/>.		<http://cbor.me/>.
			[CNSA] (Placeholder), ., "Commercial National Security Algorithm
			Suite", August 2015,
			<https://apps.nsa.gov/iaarchive/programs/iad-initiatives/
			cnsa-suite.cfm>.
	[I-D.ietf-6tisch-dtsecurity-zerotouch-join]		[I-D.ietf-6tisch-dtsecurity-zerotouch-join]
	Richardson, M., "6tisch Zero-Touch Secure Join protocol",		Richardson, M., "6tisch Zero-Touch Secure Join protocol",
	draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in		draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in
	progress), July 2019.		progress), July 2019.
	[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) using the OAuth 2.0		Constrained Environments (ACE) using the OAuth 2.0
	Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36
	(work in progress), June 2020.		(work in progress), November 2020.
	[I-D.ietf-core-resource-directory]		[I-D.ietf-core-resource-directory]
	Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P.		Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P.
	Stok, "CoRE Resource Directory", draft-ietf-core-resource-		Stok, "CoRE Resource Directory", draft-ietf-core-resource-
	directory-26 (work in progress), November 2020.		directory-26 (work in progress), November 2020.
	[I-D.ietf-lwig-security-protocol-comparison]		[I-D.ietf-lwig-security-protocol-comparison]
	Mattsson, J., Palombini, F., and M. Vucinic, "Comparison		Mattsson, J., Palombini, F., and M. Vucinic, "Comparison
	of CoAP Security Protocols", draft-ietf-lwig-security-		of CoAP Security Protocols", draft-ietf-lwig-security-
	protocol-comparison-05 (work in progress), November 2020.		protocol-comparison-05 (work in progress), November 2020.
	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-38 (work in progress), May		1.3", draft-ietf-tls-dtls13-39 (work in progress),
	2020.		November 2020.
			[I-D.palombini-core-oscore-edhoc]
			Palombini, F., Tiloca, M., Hoeglund, R., Hristozov, S.,
			and G. Selander, "Combining EDHOC and OSCORE", draft-
			palombini-core-oscore-edhoc-01 (work in progress),
			November 2020.
	[I-D.selander-ace-ake-authz]		[I-D.selander-ace-ake-authz]
	Selander, G., Mattsson, J., Vucinic, M., Richardson, M.,		Selander, G., Mattsson, J., Vucinic, M., Richardson, M.,
	and A. Schellenbaum, "Lightweight Authorization for		and A. Schellenbaum, "Lightweight Authorization for
	Authenticated Key Exchange.", draft-selander-ace-ake-		Authenticated Key Exchange.", draft-selander-ace-ake-
	authz-01 (work in progress), March 2020.		authz-02 (work in progress), November 2020.
	[Kron18] Krontiris, A., "Evaluation of Certificate Enrollment over		[Kron18] Krontiris, A., "Evaluation of Certificate Enrollment over
	Application Layer Security", May 2018,		Application Layer Security", May 2018,
	<https://www.nada.kth.se/~ann/exjobb/		<https://www.nada.kth.se/~ann/exjobb/
	alexandros_krontiris.pdf>.		alexandros_krontiris.pdf>.
	[LoRa1] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S.,		[LoRa1] Sanchez-Iborra, R., Sanchez-Gomez, J., Perez, S.,
	Fernandez, P., Santa, J., Hernandez-Ramos, J., and A.		Fernandez, P., Santa, J., Hernandez-Ramos, J., and A.
	Skarmeta, "Enhancing LoRaWAN Security through a		Skarmeta, "Enhancing LoRaWAN Security through a
	Lightweight and Authenticated Key Management Approach",		Lightweight and Authenticated Key Management Approach",
	skipping to change at page 44, line 8 ¶		skipping to change at page 47, line 31 ¶
	[SSR18] Bruni, A., Sahl Joergensen, T., Groenbech Petersen, T.,		[SSR18] Bruni, A., Sahl Joergensen, T., Groenbech Petersen, T.,
	and C. Schuermann, "Formal Verification of Ephemeral		and C. Schuermann, "Formal Verification of Ephemeral
	Diffie-Hellman Over COSE (EDHOC)", November 2018,		Diffie-Hellman Over COSE (EDHOC)", November 2018,
	<https://www.springerprofessional.de/en/formal-		<https://www.springerprofessional.de/en/formal-
	verification-of-ephemeral-diffie-hellman-over-cose-		verification-of-ephemeral-diffie-hellman-over-cose-
	edhoc/16284348>.		edhoc/16284348>.
	Appendix A. Use of CBOR, CDDL and COSE in EDHOC		Appendix A. Use of CBOR, CDDL and COSE in EDHOC
	This Appendix is intended to simplify for implementors not familiar		This Appendix is intended to simplify for implementors not familiar
	with CBOR [RFC7049], CDDL [RFC8610], COSE [RFC8152], and HKDF		with CBOR [RFC8949], CDDL [RFC8610], COSE [RFC8152], and HKDF
	[RFC5869].		[RFC5869].
	A.1. CBOR and CDDL		A.1. CBOR and CDDL
	The Concise Binary Object Representation (CBOR) [RFC7049] is a data		The Concise Binary Object Representation (CBOR) [RFC8949] is a data
	format designed for small code size and small message size. CBOR		format designed for small code size and small message size. CBOR
	builds on the JSON data model but extends it by e.g. encoding binary		builds on the JSON data model but extends it by e.g. encoding binary
	data directly without base64 conversion. In addition to the binary		data directly without base64 conversion. In addition to the binary
	CBOR encoding, CBOR also has a diagnostic notation that is readable		CBOR encoding, CBOR also has a diagnostic notation that is readable
	and editable by humans. The Concise Data Definition Language (CDDL)		and editable by humans. The Concise Data Definition Language (CDDL)
	[RFC8610] provides a way to express structures for protocol messages		[RFC8610] provides a way to express structures for protocol messages
	and APIs that use CBOR. [RFC8610] also extends the diagnostic		and APIs that use CBOR. [RFC8610] also extends the diagnostic
	notation.		notation.
	CBOR data items are encoded to or decoded from byte strings using a		CBOR data items are encoded to or decoded from byte strings using a
	type-length-value encoding scheme, where the three highest order bits		type-length-value encoding scheme, where the three highest order bits
	of the initial byte contain information about the major type. CBOR		of the initial byte contain information about the major type. CBOR
	supports several different types of data items, in addition to		supports several different types of data items, in addition to
	integers (int, uint), simple values (e.g. null), byte strings (bstr),		integers (int, uint), simple values (e.g. null), byte strings (bstr),
	and text strings (tstr), CBOR also supports arrays [] of data items,		and text strings (tstr), CBOR also supports arrays [] of data items,
	maps {} of pairs of data items, and sequences [RFC8742] of data		maps {} of pairs of data items, and sequences [RFC8742] of data
	items. Some examples are given below. For a complete specification		items. Some examples are given below. For a complete specification
	and more examples, see [RFC7049] and [RFC8610]. We recommend		and more examples, see [RFC8949] and [RFC8610]. We recommend
	implementors to get used to CBOR by using the CBOR playground		implementors to get used to CBOR by using the CBOR playground
	[CborMe].		[CborMe].
	Diagnostic Encoded Type		Diagnostic Encoded Type
	------------------------------------------------------------------		------------------------------------------------------------------
	1 0x01 unsigned integer		1 0x01 unsigned integer
	24 0x1818 unsigned integer		24 0x1818 unsigned integer
	-24 0x37 negative integer		-24 0x37 negative integer
	-25 0x3818 negative integer		-25 0x3818 negative integer
	null 0xf6 simple value		null 0xf6 simple value
	skipping to change at page 45, line 23 ¶		skipping to change at page 48, line 44 ¶
	Appendix B. Test Vectors		Appendix B. Test Vectors
	This appendix provides detailed test vectors to ease implementation		This appendix provides detailed test vectors to ease implementation
	and ensure interoperability. In addition to hexadecimal, all CBOR		and ensure interoperability. In addition to hexadecimal, all CBOR
	data items and sequences are given in CBOR diagnostic notation. The		data items and sequences are given in CBOR diagnostic notation. The
	test vectors use the default mapping to CoAP where the Initiator acts		test vectors use the default mapping to CoAP where the Initiator acts
	as CoAP client (this means that corr = 1).		as CoAP client (this means that corr = 1).
	A more extensive test vector suite covering more combinations of		A more extensive test vector suite covering more combinations of
	authentication method used between Initiator and Responder and		authentication method used between Initiator and Responder and
	related code to generate them can be found at		related code to generate them can be found at https://github.com/
	https://github.com/EricssonResearch/EDHOC/tree/master/Test%20Vectors		lake-wg/edhoc/tree/master/test-vectors .
	.
	B.1. Test Vectors for EDHOC Authenticated with Signature Keys (x5t)		B.1. Test Vectors for EDHOC Authenticated with Signature Keys (x5t)
	EDHOC with signature authentication and X.509 certificates is used.		EDHOC with signature authentication and X.509 certificates is used.
	In this test vector, the hash value 'x5t' is used to identify the		In this test vector, the hash value 'x5t' is used to identify the
	certificate.		certificate.
	method (Signature Authentication)		method (Signature Authentication)
	0		0
	skipping to change at page 46, line 14 ¶		skipping to change at page 49, line 33 ¶
	Supported Cipher Suites (4 bytes)		Supported Cipher Suites (4 bytes)
	00 01 02 03		00 01 02 03
	The cipher suite selected by the Initiator is the most preferred:		The cipher suite selected by the Initiator is the most preferred:
	Selected Cipher Suite (int)		Selected Cipher Suite (int)
	0		0
	The mandatory-to-implement cipher suite 0 is supported by both the		The mandatory-to-implement cipher suite 0 is supported by both the
	Initiator and the Responder, see Section 7.3.		Initiator and the Responder, see Section 8.3.
	B.1.1. Message_1		B.1.1. Message_1
	X (Initiator's ephemeral private key) (32 bytes)		X (Initiator's ephemeral private key) (32 bytes)
	8f 78 1a 09 53 72 f8 5b 6d 9f 61 09 ae 42 26 11 73 4d 7d bf a0 06 9a 2d		8f 78 1a 09 53 72 f8 5b 6d 9f 61 09 ae 42 26 11 73 4d 7d bf a0 06 9a 2d
	f2 93 5b b2 e0 53 bf 35		f2 93 5b b2 e0 53 bf 35
	G_X (Initiator's ephemeral public key) (32 bytes)		G_X (Initiator's ephemeral public key) (32 bytes)
	89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 ec 07 6b ba		89 8f f7 9a 02 06 7a 16 ea 1e cc b9 0f a5 22 46 f5 aa 4d d6 ec 07 6b ba
	02 59 d9 04 b7 ec 8b 0c		02 59 d9 04 b7 ec 8b 0c
	skipping to change at page 47, line 36 ¶		skipping to change at page 50, line 51 ¶
	71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52		71 a3 d5 99 c2 1d a1 89 02 a1 ae a8 10 b2 b6 38 2c cd 8d 5f 9b f0 19 52
	81 75 4c 5e bc af 30 1e		81 75 4c 5e bc af 30 1e
	From G_X and Y or from G_Y and X the ECDH shared secret is computed:		From G_X and Y or from G_Y and X the ECDH shared secret is computed:
	G_XY (ECDH shared secret) (32 bytes)		G_XY (ECDH shared secret) (32 bytes)
	2b b7 fa 6e 13 5b c3 35 d0 22 d6 34 cb fb 14 b3 f5 82 f3 e2 e3 af b2 b3		2b b7 fa 6e 13 5b c3 35 d0 22 d6 34 cb fb 14 b3 f5 82 f3 e2 e3 af b2 b3
	15 04 91 49 5c 61 78 2b		15 04 91 49 5c 61 78 2b
	The key and nonce for calculating the ciphertext are calculated as		The key and nonce for calculating the ciphertext are calculated as
	follows, as specified in Section 3.8.		follows, as specified in Section 4.
	HKDF SHA-256 is the HKDF used (as defined by cipher suite 0).		HKDF SHA-256 is the HKDF used (as defined by cipher suite 0).
	PRK_2e = HMAC-SHA-256(salt, G_XY)		PRK_2e = HMAC-SHA-256(salt, G_XY)
	Salt is the empty byte string.		Salt is the empty byte string.
	salt (0 bytes)		salt (0 bytes)
	From there, PRK_2e is computed:		From there, PRK_2e is computed:
	skipping to change at page 48, line 22 ¶		skipping to change at page 51, line 37 ¶
	ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f		ec 62 92 a0 67 f1 37 fc 7f 59 62 9d 22 6f bf c4 e0 68 89 49 f6 62 a9 7f
	d8 2f be b7 99 71 39 4a		d8 2f be b7 99 71 39 4a
	The Responder chooses a connection identifier C_R.		The Responder chooses a connection identifier C_R.
	Connection identifier chosen by Responder (1 byte)		Connection identifier chosen by Responder (1 byte)
	2b		2b
	Note that since C_R is a byte string of length one, it is encoded as		Note that since C_R is a byte string of length one, it is encoded as
	the corresponding integer subtracted by 24 (see bstr_identifier in		the corresponding integer subtracted by 24 (see bstr_identifier in
	Section 4.3). Thus 0x2b = 43, 43 - 24 = 19, and 19 in CBOR encoding		Section 5.1). Thus 0x2b = 43, 43 - 24 = 19, and 19 in CBOR encoding
	is equal to 0x13.		is equal to 0x13.
	C_R (1 byte)		C_R (1 byte)
	13		13
	Data_2 is constructed, as the CBOR Sequence of G_Y and C_R.		Data_2 is constructed, as the CBOR Sequence of G_Y and C_R.
	data_2 =		data_2 =
	(		(
	h'71a3d599c21da18902a1aea810b2b6382ccd8d5f9bf0195281754c5ebcaf301e',		h'71a3d599c21da18902a1aea810b2b6382ccd8d5f9bf0195281754c5ebcaf301e',
	skipping to change at page 60, line 44 ¶		skipping to change at page 63, line 52 ¶
	Supported Cipher Suites (4 bytes)		Supported Cipher Suites (4 bytes)
	00 01 02 03		00 01 02 03
	The cipher suite selected by the Initiator is the most preferred:		The cipher suite selected by the Initiator is the most preferred:
	Selected Cipher Suite (int)		Selected Cipher Suite (int)
	0		0
	The mandatory-to-implement cipher suite 0 is supported by both the		The mandatory-to-implement cipher suite 0 is supported by both the
	Initiator and the Responder, see Section 7.3.		Initiator and the Responder, see Section 8.3.
	B.2.1. Message_1		B.2.1. Message_1
	X (Initiator's ephemeral private key) (32 bytes)		X (Initiator's ephemeral private key) (32 bytes)
	ae 11 a0 db 86 3c 02 27 e5 39 92 fe b8 f5 92 4c 50 d0 a7 ba 6e ea b4 ad		ae 11 a0 db 86 3c 02 27 e5 39 92 fe b8 f5 92 4c 50 d0 a7 ba 6e ea b4 ad
	1f f2 45 72 f4 f5 7c fa		1f f2 45 72 f4 f5 7c fa
	G_X (Initiator's ephemeral public key) (32 bytes)		G_X (Initiator's ephemeral public key) (32 bytes)
	8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80 a5 38 a4 44		8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80 a5 38 a4 44
	ee 9e 2b 57 e2 44 1a 7c		ee 9e 2b 57 e2 44 1a 7c
	The Initiator chooses a connection identifier C_I:		The Initiator chooses a connection identifier C_I:
	Connection identifier chosen by Initiator (1 bytes)		Connection identifier chosen by Initiator (1 bytes)
	16		16
	Note that since C_I is a byte strings of length one, it is encoded as		Note that since C_I is a byte strings of length one, it is encoded as
	skipping to change at page 61, line 14 ¶		skipping to change at page 64, line 21 ¶
	G_X (Initiator's ephemeral public key) (32 bytes)		G_X (Initiator's ephemeral public key) (32 bytes)
	8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80 a5 38 a4 44		8d 3e f5 6d 1b 75 0a 43 51 d6 8a c2 50 a0 e8 83 79 0e fc 80 a5 38 a4 44
	ee 9e 2b 57 e2 44 1a 7c		ee 9e 2b 57 e2 44 1a 7c
	The Initiator chooses a connection identifier C_I:		The Initiator chooses a connection identifier C_I:
	Connection identifier chosen by Initiator (1 bytes)		Connection identifier chosen by Initiator (1 bytes)
	16		16
	Note that since C_I is a byte strings of length one, it is encoded as		Note that since C_I is a byte strings of length one, it is encoded as
	the corresponding integer - 24 (see bstr_identifier in Section 4.3),		the corresponding integer - 24 (see bstr_identifier in Section 5.1),
	i.e. 0x16 = 22, 22 - 24 = -2, and -2 in CBOR encoding is equal to		i.e. 0x16 = 22, 22 - 24 = -2, and -2 in CBOR encoding is equal to
	0x21.		0x21.
	C_I (1 byte)		C_I (1 byte)
	21		21
	Since no unprotected opaque auxiliary data is sent in the message		Since no unprotected opaque auxiliary data is sent in the message
	exchanges:		exchanges:
	AD_1 (0 bytes)		AD_1 (0 bytes)
	skipping to change at page 62, line 24 ¶		skipping to change at page 65, line 28 ¶
	52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db fc 33		52 fb a0 bd c8 d9 53 dd 86 ce 1a b2 fd 7c 05 a4 65 8c 7c 30 af db fc 33
	01 04 70 69 45 1b af 35		01 04 70 69 45 1b af 35
	From G_X and Y or from G_Y and X the ECDH shared secret is computed:		From G_X and Y or from G_Y and X the ECDH shared secret is computed:
	G_XY (ECDH shared secret) (32 bytes)		G_XY (ECDH shared secret) (32 bytes)
	de fc 2f 35 69 10 9b 3d 1f a4 a7 3d c5 e2 fe b9 e1 15 0d 90 c2 5e e2 f0		de fc 2f 35 69 10 9b 3d 1f a4 a7 3d c5 e2 fe b9 e1 15 0d 90 c2 5e e2 f0
	66 c2 d8 85 f4 f8 ac 4e		66 c2 d8 85 f4 f8 ac 4e
	The key and nonce for calculating the ciphertext are calculated as		The key and nonce for calculating the ciphertext are calculated as
	follows, as specified in Section 3.8.		follows, as specified in Section 4.
	HKDF SHA-256 is the HKDF used (as defined by cipher suite 0).		HKDF SHA-256 is the HKDF used (as defined by cipher suite 0).
	PRK_2e = HMAC-SHA-256(salt, G_XY)		PRK_2e = HMAC-SHA-256(salt, G_XY)
	Salt is the empty byte string.		Salt is the empty byte string.
	salt (0 bytes)		salt (0 bytes)
	From there, PRK_2e is computed:		From there, PRK_2e is computed:
	PRK_2e (32 bytes)		PRK_2e (32 bytes)
	93 9f cb 05 6d 2e 41 4f 1b ec 61 04 61 99 c2 c7 63 d2 7f 0c 3d 15 fa 16		93 9f cb 05 6d 2e 41 4f 1b ec 61 04 61 99 c2 c7 63 d2 7f 0c 3d 15 fa 16
	71 fa 13 4e 0d c5 a0 4d		71 fa 13 4e 0d c5 a0 4d
	SK_R (Responders's private authentication key) (32 bytes)
	bb 50 1a ac 67 b9 a9 5f 97 e0 ed ed 6b 82 a6 62 93 4f bb fc 7a d1 b7 4c
	1f ca d6 6a 07 94 22 d0
	Since the Responder authenticates with a static Diffie-Hellman key,		Since the Responder authenticates with a static Diffie-Hellman key,
	PRK_3e2m = HKDF-Extract( PRK_2e, G_RX ), where G_RX is the ECDH		PRK_3e2m = HKDF-Extract( PRK_2e, G_RX ), where G_RX is the ECDH
	shared secret calculated from G_R and X, or G_X and R.		shared secret calculated from G_R and X, or G_X and R.
	R (Responder's private authentication key) (32 bytes)		R (Responder's private authentication key) (32 bytes)
	bb 50 1a ac 67 b9 a9 5f 97 e0 ed ed 6b 82 a6 62 93 4f bb fc 7a d1 b7 4c		bb 50 1a ac 67 b9 a9 5f 97 e0 ed ed 6b 82 a6 62 93 4f bb fc 7a d1 b7 4c
	1f ca d6 6a 07 94 22 d0		1f ca d6 6a 07 94 22 d0
	G_R (Responder's public authentication key) (32 bytes)		G_R (Responder's public authentication key) (32 bytes)
	a3 ff 26 35 95 be b3 77 d1 a0 ce 1d 04 da d2 d4 09 66 ac 6b cb 62 20 51		a3 ff 26 35 95 be b3 77 d1 a0 ce 1d 04 da d2 d4 09 66 ac 6b cb 62 20 51
	b8 46 59 18 4d 5d 9a 32		b8 46 59 18 4d 5d 9a 32
	skipping to change at page 63, line 25 ¶		skipping to change at page 66, line 25 ¶
	PRK_3e2m (32 bytes)		PRK_3e2m (32 bytes)
	75 07 7c 69 1e 35 01 2d 48 bc 24 c8 4f 2b ab 89 f5 2f ac 03 fe dd 81 3e		75 07 7c 69 1e 35 01 2d 48 bc 24 c8 4f 2b ab 89 f5 2f ac 03 fe dd 81 3e
	43 8c 93 b1 0b 39 93 07		43 8c 93 b1 0b 39 93 07
	The Responder chooses a connection identifier C_R.		The Responder chooses a connection identifier C_R.
	Connection identifier chosen by Responder (1 byte)		Connection identifier chosen by Responder (1 byte)
	20		20
	Note that since C_R is a byte strings of length one, it is encoded as		Note that since C_R is a byte strings of length one, it is encoded as
	the corresponding integer - 24 (see bstr_identifier in Section 4.3),		the corresponding integer - 24 (see bstr_identifier in Section 5.1),
	i.e. 0x20 = 32, 32 - 24 = 8, and 8 in CBOR encoding is equal to 0x08.		i.e. 0x20 = 32, 32 - 24 = 8, and 8 in CBOR encoding is equal to 0x08.
	C_R (1 byte)		C_R (1 byte)
	08		08
	Data_2 is constructed, as the CBOR Sequence of G_Y and C_R.		Data_2 is constructed, as the CBOR Sequence of G_Y and C_R.
	data_2 =		data_2 =
	(		(
	h'52FBA0BDC8D953DD86CE1AB2FD7C05A4658C7C30AFDBFC3301047069451BAF35',		h'52FBA0BDC8D953DD86CE1AB2FD7C05A4658C7C30AFDBFC3301047069451BAF35',
	skipping to change at page 66, line 50 ¶		skipping to change at page 69, line 50 ¶
	64 21 0d 2e 18 b9 28 cd		64 21 0d 2e 18 b9 28 cd
	CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a		CIPHERTEXT_2 is the ciphertext resulting from XOR encrypting a
	plaintext constructed from the following parameters and the key K_2e.		plaintext constructed from the following parameters and the key K_2e.
	o plaintext = CBOR Sequence of the items ID_CRED_R and the CBOR		o plaintext = CBOR Sequence of the items ID_CRED_R and the CBOR
	encoded Signature_or_MAC_2, in this order. Note that since		encoded Signature_or_MAC_2, in this order. Note that since
	ID_CRED_R contains a single 'kid' parameter, i.e., ID_CRED_R = { 4		ID_CRED_R contains a single 'kid' parameter, i.e., ID_CRED_R = { 4
	: kid_R }, only the byte string kid_R is conveyed in the plaintext		: kid_R }, only the byte string kid_R is conveyed in the plaintext
	encoded as a bstr_identifier. kid_R is encoded as the		encoded as a bstr_identifier. kid_R is encoded as the
	corresponding integer - 24 (see bstr_identifier in Section 4.3),		corresponding integer - 24 (see bstr_identifier in Section 5.1),
	i.e. 0x07 = 7, 7 - 24 = -17, and -17 in CBOR encoding is equal to		i.e. 0x07 = 7, 7 - 24 = -17, and -17 in CBOR encoding is equal to
	0x30.		0x30.
	The plaintext is the following:		The plaintext is the following:
	P_2e (CBOR Sequence) (10 bytes)		P_2e (CBOR Sequence) (10 bytes)
	30 48 64 21 0d 2e 18 b9 28 cd		30 48 64 21 0d 2e 18 b9 28 cd
	K_2e = HKDF-Expand( PRK, info, length ), where length is the length		K_2e = HKDF-Expand( PRK, info, length ), where length is the length
	of the plaintext, so 80.		of the plaintext, so 10.
	info for K_2e =		info for K_2e =
	[		[
	10,		10,
	h'6A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FF',		h'6A2878E84B2CC021CC1AEBA2965253EF42F7FA300CAF9C491A52E6836A2564FF',
	"K_2e",		"K_2e",
	10		10
	]		]
	Which as a CBOR encoded data item is:		Which as a CBOR encoded data item is:
	skipping to change at page 71, line 20 ¶		skipping to change at page 74, line 20 ¶
	Signature_or_MAC_3 (8 bytes)		Signature_or_MAC_3 (8 bytes)
	1f b7 5a c1 aa d2 34 25		1f b7 5a c1 aa d2 34 25
	Finally, the outer COSE_Encrypt0 is computed.		Finally, the outer COSE_Encrypt0 is computed.
	The Plaintext is the following CBOR Sequence: plaintext = ( ID_CRED_I		The Plaintext is the following CBOR Sequence: plaintext = ( ID_CRED_I
	, Signature_or_MAC_3 ). Note that since ID_CRED_I contains a single		, Signature_or_MAC_3 ). Note that since ID_CRED_I contains a single
	'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, only the byte		'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, only the byte
	string kid_I is conveyed in the plaintext encoded as a		string kid_I is conveyed in the plaintext encoded as a
	bstr_identifier. kid_I is encoded as the corresponding integer - 24		bstr_identifier. kid_I is encoded as the corresponding integer - 24
	(see bstr_identifier in Section 4.3), i.e. 0x24 = 36, 36 - 24 = 12,		(see bstr_identifier in Section 5.1), i.e. 0x24 = 36, 36 - 24 = 12,
	and 12 in CBOR encoding is equal to 0x0c.		and 12 in CBOR encoding is equal to 0x0c.
	P_3ae (CBOR Sequence) (10 bytes)		P_3ae (CBOR Sequence) (10 bytes)
	0c 48 1f b7 5a c1 aa d2 34 25		0c 48 1f b7 5a c1 aa d2 34 25
	The Associated data A is the following: Associated data A = [		The Associated data A is the following: Associated data A = [
	"Encrypt0", h'', TH_3 ]		"Encrypt0", h'', TH_3 ]
	A_3ae (CBOR-encoded) (45 bytes)		A_3ae (CBOR-encoded) (45 bytes)
	83 68 45 6e 63 72 79 70 74 30 40 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53		83 68 45 6e 63 72 79 70 74 30 40 58 20 51 dd 22 43 a6 b8 3f 13 16 dc 53
	skipping to change at page 73, line 8 ¶		skipping to change at page 76, line 8 ¶
	(		(
	h'08',		h'08',
	h'53C3991999A5FFB86921E99B607C067770E0'		h'53C3991999A5FFB86921E99B607C067770E0'
	)		)
	Which encodes to the following byte string:		Which encodes to the following byte string:
	message_3 (CBOR Sequence) (20 bytes)		message_3 (CBOR Sequence) (20 bytes)
	08 52 53 c3 99 19 99 a5 ff b8 69 21 e9 9b 60 7c 06 77 70 e0		08 52 53 c3 99 19 99 a5 ff b8 69 21 e9 9b 60 7c 06 77 70 e0
			Appendix C. Applicability Statement Template
			EDHOC requires certain parameters to be agreed upon between Initiator
			and Responder. A cipher suite is negotiated with the protocol, but
			certain other parameters need to be agreed beforehand:
			1. Method and correlation of underlying transport messages
			(METHOD_CORR, see Section 3.2.1 and Section 3.2.4).
			2. Type of authentication credentials (CRED_I, CRED_R, see
			Section 3.3.4).
			3. Type for identifying authentication credentials (ID_CRED_I,
			ID_CRED_R, see Section 3.3.4).
			4. Type and use of Auxiliary Data AD_1, AD_2, AD_3 (see
			Section 3.6).
			5. Identifier used as identity of endpoint (see Section 3.3).
			An example of an applicability statement is shown in the next
			section.
			Note that for some of the parameters, like METHOD_CORR, ID_CRED_x,
			type of AD_x, the receiver is able to assert whether it supports the
			parameter or not and thus, if it fails, to infer why.
			For other parameters, like type of authentication credential, it may
			be more difficult to detect if the receiver got the wrong type since
			the credential is not necessarily transported, and a failed integrity
			of the received message may be caused by other circumstances. For
			example in the case of public key certificates there is a large
			variety of profiles and alternative encodings, which the
			applicability statement needs to nail down.
			Note also that it is not always necessary for the endpoints to agree
			on the transport for the EDHOC messages. For example, a mix of CoAP
			and HTTP may be used along the path and still allow correlation
			between message_1 and message_2.
			C.1. Use of EDHOC in the XX Protocol
			For use of EDHOC in the XX protocol, the following assumptions are
			made on the parameters.
			o METHOD_CORR = 5
			* method = 1 (I uses signature key, R uses static DH key.)
			* corr = 1 (CoAP Token or other transport data enables
			correlation between message_1 and message_2.)
			o CRED_I is an 802.1AR IDevID encoded as a CBOR Certificate of type
			0
			* R acquires CRED_I out-of-band, indicated in AD_1
			* ID_CRED_I = {4: h''} is a kid with value empty byte string
			o CRED_R is a COSE_Key of type OKP as specified in Section 3.3.4.
			* The CBOR map has parameters 1 (kty), -1 (crv), and -2
			(x-coordinate).
			o ID_CRED_R = CRED_R
			o AD_1 contains Auxiliary Data of type A (TBD)
			o AD_2 contains Auxiliary Data of type B (TBD)
			Auxiliary Data is processed as specified in
			[I-D.ietf-ace-oauth-authz].
			o Need to specify use of C_I/C_R ? (TBD)
	Acknowledgments		Acknowledgments
	The authors want to thank Alessandro Bruni, Karthikeyan Bhargavan,		The authors want to thank Alessandro Bruni, Karthikeyan Bhargavan,
	Martin Disch, Theis Groenbech Petersen, Dan Harkins, Klaus Hartke,		Martin Disch, Theis Groenbech Petersen, Dan Harkins, Klaus Hartke,
	Russ Housley, Alexandros Krontiris, Ilari Liusvaara, Karl Norrman,		Russ Housley, Alexandros Krontiris, Ilari Liusvaara, Karl Norrman,
	Salvador Perez, Eric Rescorla, Michael Richardson, Thorvald Sahl		Salvador Perez, Eric Rescorla, Michael Richardson, Thorvald Sahl
	Joergensen, Jim Schaad, Carsten Schuermann, Ludwig Seitz, Stanislav		Joergensen, Jim Schaad, Carsten Schuermann, Ludwig Seitz, Stanislav
	Smyshlyaev, Valery Smyslov, Rene Struik, Vaishnavi Sundararajan, Erik		Smyshlyaev, Valery Smyslov, Rene Struik, Vaishnavi Sundararajan, Erik
	Thormarker, and Michel Veillette for reviewing and commenting on		Thormarker, and Michel Veillette for reviewing and commenting on
	intermediate versions of the draft. We are especially indebted to		intermediate versions of the draft. We are especially indebted to
End of changes. 176 change blocks.
	455 lines changed or deleted		697 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/