| Internet-Draft | EDHOC Credential Hash | October 2025 |
| Selander, et al. | Expires 23 April 2026 | [Page] |
This document defines a COSE header parameter which signals that an authentication credential is replaced by the hash of the authentication credential in the protocol message computations. This further relaxes the need for transporting authentication credentials in EDHOC, which reduces protocol message sizes and improves performance in constrained networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman over COSE (EDHOC, [RFC9528]) supports a variety of authentication credentials and different options for identifying credentials during the protocol execution. The latter allows the protocol messages to carry, for example, references or unique identifiers instead of the authentication credentials, thereby reducing message size and improving performance in constrained networks.¶
In this document we describe a new mode of processing authentication credentials in EDHOC which further relaxes the need for transporting them. This new mode is signalled with a new COSE header parameter using an existing protocol mechanism and does not require any changes to the message format.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Public key authentication credentials in EDHOC are described in Section 3.5 of [RFC9528]. (Pre-shared keys are out of scope.)¶
The authentication credentials for the Initiator (I) and the Responder (R) are denoted CRED_I and CRED_R, respectively. To allow more flexibility in identifying and obtaining the credential, the EDHOC protocol does not have dedicated message fields for CRED_I and CRED_R. Instead the fields ID_CRED_I and ID_CRED_R are intended to facilitate the retrieval of the authentication credentials and the authentication keys. ID_CRED_I and ID_CRED_R are of type COSE header_map and contain one or more COSE header parameters, see corresponding IANA register. Some examples below for the case when the authentication credential (here CRED_R, similar applies to CRED_I) is an X.509 certificate:¶
CRED_R may be referenced by including the COSE header parameter x5u in the ID_CRED_R field of EDHOC message 2. x5u contains a URI to the Responder's certificate, for example, at some certificate repository.¶
If the certificate is already available to the Initiator, then it can be identified using the COSE header parameter x5t in ID_CRED_R. x5t contains the certificate hash.¶
ID_CRED_R can contain both x5u and x5t, allowing retrival and/or verification of the X.509 certificate.¶
(Note that in case the certificate do need to be transported it can be included with the COSE header parameter x5chain in ID_CRED_R or ID_CRED_I.)¶
EST-OSCORE [I-D.ietf-ace-coap-est-oscore] specifies a lightweight certificate enrolment protocol protecting EST payloads over CoAP with OSCORE [RFC8613].¶
In the same spirit as in Section 2.1, the EST-OSCORE enrolment request from the EST client may result in a response from the Certification Authority (CA) containing a reference to and/or hash of the issued certificate, rather than the certificate itself. In this case the certificate is not available to the client (= the subject of the certificate) but of course the public/private key pair is. Hence, the client should be able to authenticate using EDHOC to a peer by providing a reference and/or hash of the certificate as described Section 2.1. This could be favorable if the client is on a constrained network and the peer and CA is on a non-constrained network, since the certificate is only transported over the non-constrained network compared to twice over the constrained network.¶
However, this doesn't work directly with the current message processing in [RFC9528] as we explain in Section 3, followed by a straightforward fix that makes it work in Section 4.¶
When the EDHOC protocol was designed it was assumed that each endpoint has access to its own credential, and that it obtained the other endpoint's credential at least the first time it was used. Hence it was feasible to include the authentication credentials in the protocol message computations:¶
CRED_R is used in the computation of the message field Signature_or_MAC_2 (see Section 5.3.2 of [RFC9528]):¶
CRED_R is included in the transcript hash TH_3 which is used to calculate, e.g., keys for message 3:¶
TH_3 = H(TH_2, PLAINTEXT_2, CRED_R), where H() is the EDHOC hash algorithm of the selected cipher suite.¶
CRED_I is used in the computation of the message field Signature_or_MAC_3 (see Section 5.4.2 of [RFC9528]):¶
CRED_I is included in the transcript hash TH_4 which is used to calculate, e.g., keys for message 4 and the session key PRK_out:¶
TH_4 = H(TH_3, PLAINTEXT_3, CRED_I), where H() is the EDHOC hash algorithm of the selected cipher suite.¶
Since [RFC9528] requires the peers to use the authentication credentials to perform the protocol computations, and a client enrolling a certificate as described in the example in Section 2.2 only obtains a reference and/or a hash, it would not be able to use that certificate when authenticating to other peers.¶
To ensure the integrity of the authentication credentials it is sufficient to include in the computation a digest of the relevant authentication credentials using a secure hash function.¶
With this in mind we define a new mode of processing credentials in EDHOC where an authentication credential is replaced by a secure hash of that credential. The hash function used is the EDHOC hash function of the selected cipher suite, see Section 3.6 of [RFC9528].¶
The new processing mode is indicated with the COSE header parameter 'Hashed Credential', see Section 7.1. The parameter has no value.¶
The presence of the COSE header parameter 'Hashed Credential' in an ID_CRED_R indicates that CRED_R SHALL be replaced with H(CRED_R) in all EDHOC protocol computations, where H() is the EDHOC hash algorithm of the selected cipher suite. Analogously, the presence of the 'Hashed Credential' in an ID_CRED_I indicates that CRED_I SHALL be replaced with H(CRED_I) in all EDHOC protocol computations.¶
Note that this parameter may be (typically is) present together with other COSE header parameters identifying the credential.¶
The EDHOC processing described in Section 3 is thus replaced by the following:¶
H(CRED_R) is used in the computation of the message field Signature_or_MAC_2:¶
H(CRED_R) is included in the transcript hash TH_3:¶
TH_3 = H(TH_2, PLAINTEXT_2, H(CRED_R)).¶
H(CRED_I) is used in the computation of the message field Signature_or_MAC_3:¶
H(CRED_I) is included in the transcript hash TH_4:¶
TH_4 = H(TH_3, PLAINTEXT_3, H(CRED_I)).¶
Replacing the credential with the hash value from a secure hash function does not impact the integrity properties. But it must be the correct hash and computed over the correct credential.¶
In case the Initiator's own credential is hashed without it having access to the credential, like the client in the example of Section 2.2, then the Initiator needs to obtain the hash of the credential from a trusted source. Similar for the Responder.¶
In case the Responder's credential is hashed, the then Initiator MUST verify that the credential hash is correct, and vice versa. Each peer typically needs access to the other peer's credential anyway, to be able to authenticate, verify credential and/or meta-data, etc.¶
There are no privacy considerations.¶
IANA is requested to register the entry 'Hashed Credential' in the "COSE Header Parameters" registry under the registry group "CBOR Object Signing and Encryption (COSE)" (see Figure 1). The parameter has no value. The Value Registry for this item is empty and omitted from the table below.¶