[Lake] Re: Comments for remote attestation over EDHOC

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

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.

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.

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



From: Michael Richardson <[e-mail]>
Date: Tuesday, 28 May 2024 at 10:23
To: Muhammad Usama Sardar <[e-mail]>, [e-mail] <[e-mail]>
Subject: [Lake] Re: Comments for remote attestation over EDHOC

Muhammad Usama Sardar <[e-mail]> wrote:
    >> > 1. /Clarify the EDHOC and RA combinations/: EDHOC has two participants
    >> > (Initiator and Responder) and RATS architecture (RFC9334) defines three roles
    >> > (Relying Party, Verifier and Attester). I think it is important to clarify
    >> > which combinations are not possible or otherwise possible but not covered by
    >> > the specs.
    >>
    >> I don't see the conflict.

    > I never mentioned any "conflict", so I am not sure what you conceived as the
    > "conflict." In my mind, it was about:

Any and all combinations are *possible*

    >> I don't expect two constrained devices to be able to perform remote
    >> attestation on each other.

    > The editor of the draft does! I also heard someone else mentioning this
    > during the Hackathon.

Well, I don't see how a constrained device is going to be able to act as a
Verifier.   As a RP?  Maybe.

    >> But, even if they were CRAYs with the padded
    >> seats, it still makes no-sense.
    >> In the context of lake-authz, the Attester is the new device (U), the Verifier is
    >> W (or it's designate), and the Relying Party is V.

    > The draft under discussion never makes a reference to lake-authz.

It should.

    >> I have a half-written document on putting EAT into the full BRSKI protocol.
    >> A reason that I stopped is that I realized that doing security posture
    >> evaluation at onboarding time (only) wasn't enough.  It has to be done
    >> regularly.  So having a protocol used at onboarding time and another one
    >> during normal operation meant that the onboarding one would have bugs that
    >> never get fixed, since the code only runs once.

    > It seems very interesting. What kind of bugs? Can you give a few examples of
    > the "bugs that never get fixed"? Which "code" exactly? Are you advocating
    > that having attestation during secure channel establishment for IoT
    > onboarding is useless?

Code that runs only once in a device's lifetime likely has bugs that nobody
notices and never get fixed.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide