Hashing Authentication Credentials in LAKE

Introduction The Lightweight Authenticated Key Exchange protocol (LAKE) 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 LAKE 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.

Terminology 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 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with . This document uses the acronym LAKE, expanded to Lightweight Authenticated Key Exchange, to denote the protocol specified as EDHOC in . LAKE is also used in place of EDHOC in descriptive terms such as LAKE message_1 or LAKE EAD item. Identifiers defined literally in or in IANA registries (e.g., EDHOC_Exporter, the EDHOC registries, media types, and URIs) are unchanged.

Background

Authentication Credentials in LAKE Public key authentication credentials in LAKE are described in . (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 LAKE 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 LAKE 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.)

Lightweight Certificate Enrolment with EST-OSCORE EST-OSCORE specifies a lightweight certificate enrolment protocol protecting EST payloads over CoAP with OSCORE . In the same spirit as in , 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 LAKE to a peer by providing a reference and/or hash of the certificate as described . 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 as we explain in , followed by a straightforward fix that makes it work in .

Authentication Credentials in LAKE Message Processing When the LAKE 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 ):
- MAC_2 is computed with context_2 = << C_R, ID_CRED_R, TH_2, CRED_R, ? EAD_2 >>.
- The 'signature' field of the COSE_Sign1 object is computed with external_aad = << TH_2, CRED_R, ? EAD_2 >>.
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 ):
- MAC_3 is computed with context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>.
- The 'signature' field of the COSE_Sign1 object is computed with external_aad = << TH_3, CRED_I, ? EAD_3 >>.
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 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 only obtains a reference and/or a hash, it would not be able to use that certificate when authenticating to other peers.

Replacing Authentication Credential with Hash 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 LAKE 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 .

New COSE Header Parameter The new processing mode is indicated with the COSE header parameter 'Hashed Credential', see . The parameter has no value.

New Processing 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 LAKE 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 LAKE protocol computations. Note that this parameter may be (typically is) present together with other COSE header parameters identifying the credential. The LAKE processing described in is thus replaced by the following:

H(CRED_R) is used in the computation of the message field Signature_or_MAC_2:
- MAC_2 is computed with context_2 = << C_R, ID_CRED_R, TH_2, H(CRED_R), ? EAD_2 >>.
- The 'signature' field of the COSE_Sign1 object is computed with external_aad = << TH_2, H(CRED_R), ? EAD_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:
- MAC_3 is computed with context_3 = << ID_CRED_I, TH_3, H(CRED_I), ? EAD_3 >>.
- The 'signature' field of the COSE_Sign1 object is computed with external_aad = << TH_3, H(CRED_I), ? EAD_3 >>.
H(CRED_I) is included in the transcript hash TH_4:
- TH_4 = H(TH_3, PLAINTEXT_3, H(CRED_I)).

Security Considerations 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 , 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.

Privacy Considerations There are no privacy considerations.

IANA Considerations

COSE Header Parameters Registry 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 ). The parameter has no value. The Value Registry for this item is empty and omitted from the table below.

COSE Header Parameter.