[Lake] Re: Comments for remote attestation over EDHOC

[Göran Selander <[e-mail]>]

Hi Usama,

Thanks. Some comments inline labelled [GS].

From: Muhammad Usama Sardar <[e-mail]>
Date: Wednesday, 29 May 2024 at 08:53
To: Göran Selander <[e-mail]>, Michael Richardson <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Lake] Re: Comments for remote attestation over EDHOC

Hi Göran,

very helpful; thanks for sharing your thoughts. Coupla questions (see inline below); fully agree with the rest.

Regards,

Usama
On 28.05.24 12:03, Göran Selander wrote:
Hi,

Here are some thoughts on this topic.

I think it would be good to be explicit about any assumptions about EDHOC roles vs. RATS architecture to simplify for the reader.

The draft intends to specify how to perform remote attestation as part of EDHOC. While EDHOC is designed with constrained nodes and networks in mind, it is not a priori clear which endpoint is constrained, if any. With this in mind I think the draft should consider all three cases: R attests I, I attests R, and I and R attest each other. Perhaps these are part of one common protocol, or perhaps some case is different.

Even if the onboarding example is an illustrative use case when remote attestation could be useful,  the specification should not be restricted to this use case. Indeed, if the authentication procedure is repeated at a later stage, for whatever reason, e.g. key rotation, it should be possible to repeat the attestation procedure.

What limits the same protocol (EDHOC) from being used during the normal operation? I am asking this because Michael mentioned "having a protocol used at onboarding time and another one during normal operation..."

[GS] The authentication protocol may be identical first and subsequent times, but there may also be differences. For example, the authentication credential used to transport and allow verification of the public key may only be transported the first time,  and instead just refererenced subsequent times for reasons of message overhead. The authorization steps in lake-authz, including the EAD items carried in EAD_1 and EAD_2, may be carried out only at first EDHOC session setup (or every time if there is a reason to assume that the conditions are changed).

Even if the code run during onboarding would be less tested than that used during normal operation, it may still important to verify the state with respect to that code to be able to make some asseessment about the device, for example that old versions are not used.
I am curious about this. Can you explain this a little more? Particularly, what exactly are you referring to when you say "code run during onboarding"? Is it meant to refer to the attested EDHOC protocol run at the onboarding time? or the firmware? In any case, what kind of bugs may remain undetected (referring back to Michael's statement)? Do you have a concrete example?

[GS] As illustrated above there may be different branches of the code, e.g., the processing of certain EAD items, and the same executed each time EDHOC is run, perhaps because some processing performed during onboarding is of one-time nature, handling the situation that the endpoints have never previously been in contact before. I don’t have a concrete example myself, just trying to match Michael’s comment which seemed relevant.

Göran

While the relationship and potential synergies with lake-authz could be elaborated, perhaps in an appendix, lake-authz is independent of remote attestation, and should IMHO not be a pre-requisite for this draft.

I don’t know if this helps. Perhaps others have more input?

Göran