rfc9528v6.txt		rfc9528.txt
	skipping to change at line 221 ¶		skipping to change at line 221 ¶
	constrained networks are also relevant since both endpoints would		constrained networks are also relevant since both endpoints would
	then benefit from the lightweight properties of the protocol. EDHOC		then benefit from the lightweight properties of the protocol. EDHOC
	could, e.g., be run when a device connects for the first time or to		could, e.g., be run when a device connects for the first time or to
	establish fresh keys that are not revealed by a later compromise of		establish fresh keys that are not revealed by a later compromise of
	the long-term keys.		the long-term keys.
	1.2. Message Size Examples		1.2. Message Size Examples
	Examples of EDHOC message sizes are shown in Table 1, which use		Examples of EDHOC message sizes are shown in Table 1, which use
	different kinds of authentication keys and COSE header parameters for		different kinds of authentication keys and COSE header parameters for
	identification, i.e., static Diffie-Hellman keys or signature keys,		identification, including static Diffie-Hellman keys or signature
	either in CWT/CCS [RFC8392] identified by a key identifier using		keys, either in CWT/CCS [RFC8392] identified by a key identifier
	'kid' [RFC9052] or in X.509 certificates identified by a hash value		using 'kid' [RFC9052] or in X.509 certificates identified by a hash
	using 'x5t' [RFC9360]. EDHOC always uses ephemeral-ephemeral key		value using 'x5t' [RFC9360]. EDHOC always uses ephemeral-ephemeral
	exchange. As a comparison, in the case of RPK authentication and		key exchange. As a comparison, in the case of RPK authentication and
	when transferred in CoAP, the EDHOC message size can be less than 1/7		when transferred in CoAP, the EDHOC message size can be less than 1/7
	of the DTLS 1.3 handshake [RFC9147] with Ephemeral Elliptic Curve		of the DTLS 1.3 handshake [RFC9147] with Ephemeral Elliptic Curve
	Diffie-Hellman (ECDHE) and connection ID; see [CoAP-SEC-PROT].		Diffie-Hellman (ECDHE) and connection ID; see [CoAP-SEC-PROT].
	+===========+================+================+		+===========+================+================+
	| | Static DH Keys | Signature Keys |		| | Static DH Keys | Signature Keys |
	+===========+==========+=====+==========+=====+		+===========+==========+=====+==========+=====+
	| | kid | x5t | kid | x5t |		| | kid | x5t | kid | x5t |
	+===========+==========+=====+==========+=====+		+===========+==========+=====+==========+=====+
	| message_1 | 37 | 37 | 37 | 37 |		| message_1 | 37 | 37 | 37 | 37 |
	skipping to change at line 281 ¶		skipping to change at line 281 ¶
	and CCS [RFC8392], and the Concise Data Definition Language (CDDL)		and CCS [RFC8392], and the Concise Data Definition Language (CDDL)
	[RFC8610], which is used to express CBOR data structures. Examples		[RFC8610], which is used to express CBOR data structures. Examples
	of CBOR and CDDL are provided in Appendix C.1. When referring to		of CBOR and CDDL are provided in Appendix C.1. When referring to
	CBOR, this specification always refers to Deterministically Encoded		CBOR, this specification always refers to Deterministically Encoded
	CBOR, as specified in Sections 4.2.1 and 4.2.2 of [RFC8949]. The		CBOR, as specified in Sections 4.2.1 and 4.2.2 of [RFC8949]. The
	single output from authenticated encryption (including the		single output from authenticated encryption (including the
	authentication tag) is called "ciphertext", following [RFC5116].		authentication tag) is called "ciphertext", following [RFC5116].
	2. EDHOC Outline		2. EDHOC Outline
	EDHOC specifies different authentication methods of the ephemeral-		EDHOC supports different authentication methods of the ephemeral-
	ephemeral Diffie-Hellman key exchange, i.e., signature keys and		ephemeral Diffie-Hellman key exchange. This document specifies
	static Diffie-Hellman keys. This section outlines the signature-key-		authentication methods based on signature keys and static Diffie-
	based method. Further details of protocol elements and other		Hellman keys. This section outlines the signature-key-based method.
	authentication methods are provided in the remainder of this		Further details of protocol elements and other authentication methods
	document.		are provided in the remainder of this document.
	SIGn-and-MAc (SIGMA) is a family of theoretical protocols with a		SIGn-and-MAc (SIGMA) is a family of theoretical protocols with a
	number of variants [SIGMA]. Like in Internet Key Exchange Protocol		number of variants [SIGMA]. Like in Internet Key Exchange Protocol
	Version 2 (IKEv2) [RFC7296] and (D)TLS 1.3 [RFC8446] [RFC9147], EDHOC		Version 2 (IKEv2) [RFC7296] and (D)TLS 1.3 [RFC8446] [RFC9147], EDHOC
	authenticated with signature keys is built on a variant of the SIGMA		authenticated with signature keys is built on a variant of the SIGMA
	protocol, SIGMA-I, which provides identity protection against active		protocol, SIGMA-I, which provides identity protection against active
	attacks on the party initiating the protocol. Also like IKEv2, EDHOC		attacks on the party initiating the protocol. Also like IKEv2, EDHOC
	implements the MAC-then-Sign variant of the SIGMA-I protocol. The		implements the MAC-then-Sign variant of the SIGMA-I protocol. The
	message flow (excluding an optional fourth message) is shown in		message flow (excluding an optional fourth message) is shown in
	Figure 1.		Figure 1.
	skipping to change at line 1160 ¶		skipping to change at line 1160 ¶
	An example of an application profile is shown in Appendix F.		An example of an application profile is shown in Appendix F.
	For some parameters, like METHOD, the type of the ID_CRED field, or		For some parameters, like METHOD, the type of the ID_CRED field, or
	EAD, the receiver of an EDHOC message is able to verify compliance		EAD, the receiver of an EDHOC message is able to verify compliance
	with the application profile and, if it needs to fail because of the		with the application profile and, if it needs to fail because of the
	lack of compliance, to infer the reason why the EDHOC session failed.		lack of compliance, to infer the reason why the EDHOC session failed.
	For other encodings, like the profiling of CRED_x in the case that it		For other encodings, like the profiling of CRED_x in the case that it
	is not transported, it may not be possible to verify that the lack of		is not transported, it may not be possible to verify that the lack of
	compliance with the application profile was the reason for failure,		compliance with the application profile was the reason for failure.
	i.e., integrity verification in message_2 or message_3 may fail not		For example, integrity verification in message_2 or message_3 may
	only because of a wrong credential. For example, in case the		fail not only because of a wrong credential. For example, in case
	Initiator uses a public key certificate by reference (i.e., not		the Initiator uses a public key certificate by reference (i.e., not
	transported within the protocol), then both endpoints need to use an		transported within the protocol), then both endpoints need to use an
	identical data structure as CRED_I or else the integrity verification		identical data structure as CRED_I or else the integrity verification
	will fail.		will fail.
	Note that it is not necessary for the endpoints to specify a single		Note that it is not necessary for the endpoints to specify a single
	transport for the EDHOC messages. For example, a mix of CoAP and		transport for the EDHOC messages. For example, a mix of CoAP and
	HTTP may be used along the path, and this may still allow correlation		HTTP may be used along the path, and this may still allow correlation
	between messages.		between messages.
	The application profile may be dependent on the identity of the other		The application profile may be dependent on the identity of the other
	skipping to change at line 2478 ¶		skipping to change at line 2478 ¶
	9.3. Cipher Suites and Cryptographic Algorithms		9.3. Cipher Suites and Cryptographic Algorithms
	When using a private cipher suite or registering new cipher suites,		When using a private cipher suite or registering new cipher suites,
	the choice of the key length used in the different algorithms needs		the choice of the key length used in the different algorithms needs
	to be harmonized so that a sufficient security level is maintained		to be harmonized so that a sufficient security level is maintained
	for authentication credentials, the EDHOC session, and the protection		for authentication credentials, the EDHOC session, and the protection
	of application data. The Initiator and Responder should enforce a		of application data. The Initiator and Responder should enforce a
	minimum security level.		minimum security level.
	The output size of the EDHOC hash algorithm MUST be at least 256		The output size of the EDHOC hash algorithm MUST be at least 256
	bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256		bits. In particular, the hash algorithms SHA-1 and SHA-256/64
	truncated to 64 bits) SHALL NOT be supported for use in EDHOC except		(SHA-256 truncated to 64 bits) SHALL NOT be supported for use in
	for certificate identification with x5t and c5t. For security		EDHOC except for certificate identification with x5t and c5t. For
	considerations of SHA-1, see [RFC6194]. As EDHOC integrity protects		security considerations of SHA-1, see [RFC6194]. As EDHOC integrity
	all the authentication credentials, the choice of hash algorithm in		protects all the authentication credentials, the choice of hash
	x5t and c5t does not affect security and using the same hash		algorithm in x5t and c5t does not affect security and using the same
	algorithm as in the cipher suite, but with as much truncation as		hash algorithm as in the cipher suite, but with as much truncation as
	possible, is RECOMMENDED. That is, when the EDHOC hash algorithm is		possible, is RECOMMENDED. That is, when the EDHOC hash algorithm is
	SHA-256, using SHA-256/64 in x5t and c5t is RECOMMENDED. The EDHOC		SHA-256, using SHA-256/64 in x5t and c5t is RECOMMENDED. The EDHOC
	MAC length MUST be at least 8 bytes and the tag length of the EDHOC		MAC length MUST be at least 8 bytes and the tag length of the EDHOC
	AEAD algorithm MUST be at least 64 bits. Note that secp256k1 is only		AEAD algorithm MUST be at least 64 bits. Note that secp256k1 is only
	defined for use with ECDSA and not for ECDH. Note that some COSE		defined for use with ECDSA and not for ECDH. Note that some COSE
	algorithms are marked as not recommended in the COSE IANA registry.		algorithms are marked as not recommended in the COSE IANA registry.
	9.4. Post-Quantum Considerations		9.4. Post-Quantum Considerations
	As of the publication of this specification, it is unclear when or		As of the publication of this specification, it is unclear when or
	skipping to change at line 3492 ¶		skipping to change at line 3492 ¶
	Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April		Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
	2022, <https://www.rfc-editor.org/info/rfc9176>.		2022, <https://www.rfc-editor.org/info/rfc9176>.
	[RFC9397] Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,		[RFC9397] Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
	"Trusted Execution Environment Provisioning (TEEP)		"Trusted Execution Environment Provisioning (TEEP)
	Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023,		Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023,
	<https://www.rfc-editor.org/info/rfc9397>.		<https://www.rfc-editor.org/info/rfc9397>.
	[RFC9529] Selander, G., Preuß Mattsson, J., Serafin, M., Tiloca, M.,		[RFC9529] Selander, G., Preuß Mattsson, J., Serafin, M., Tiloca, M.,
	and M. Vučinić, "Traces of Ephemeral Diffie-Hellman Over		and M. Vučinić, "Traces of Ephemeral Diffie-Hellman Over
	COSE (EDHOC)", RFC RFC9529, DOI 10.17487/RFC9529, March		COSE (EDHOC)", RFC 9529, DOI 10.17487/RFC9529, March 2024,
	2024, <https://www.rfc-editor.org/info/rfc9529>.		<https://www.rfc-editor.org/info/rfc9529>.
	[SECG] Certicom Research, "SEC 1: Elliptic Curve Cryptography",		[SECG] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
	Standards for Efficient Cryptography, May 2009,		Standards for Efficient Cryptography, May 2009,
	<https://www.secg.org/sec1-v2.pdf>.		<https://www.secg.org/sec1-v2.pdf>.
	[SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to		[SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to
	Authenticated Diffie-Hellman and Its Use in the IKE-		Authenticated Diffie-Hellman and Its Use in the IKE-
	Protocols", June 2003,		Protocols", June 2003,
	<https://www.iacr.org/cryptodb/archive/2003/		<https://www.iacr.org/cryptodb/archive/2003/
	CRYPTO/1495/1495.pdf>.		CRYPTO/1495/1495.pdf>.
End of changes. 5 change blocks.
	24 lines changed or deleted		24 lines changed or added
This html diff was produced by rfcdiff 1.48.