[Lake] Re: Comments on draft-ietf-lake-ra-01

[Yuxuan Song <[e-mail]>]

Hi Marco, 

Thanks for sharing the comments! Although we went through these points together during the Hackathon, I’d like to document them inline here for clarity. 

> [Section 5.2.1.1.2]

> It says:
>> In case none of the evidence types is supported, the Relying Party rejects the
> > first message_1 with an error indicating support for another evidence type.
> This requires a separate error type, in addition to the one defined for a
> different reason in Section 8.1.

You are right, I've also raised it during the side meeting in Hacathon that Section 8.1 needs correction and clarification: either 

    * assigning distinct error codes for each scenario where the attestation process cannot be completed. 

or 

    * listing the different cases and consolidating them under a general error type that indicates failure to complete attestation. 

An open issue for this change can be tracked in [3]. 

> [Section 5.2.1.1.3]

> As to the definition of the measurements-format array, suggested changes:

> OLD:
> measurements-format = [
> content-type: coap-content-format,
> content-format: bytes .cbor measurements-body-cbor
> ]

> NEW:
> measurements-format = [
> content-format: uint,
> content: bytes .cbor measurements-body-cbor
> ]

> This still requires the defition of measurements-body-cbor ...

The current definition is based on draft-ietf-rats-eat[1], but as we discussed, the definition remains ambiguous. Since the measurements-body-cbor is simply a byte string without specific constraints, I will modify it to: 
NEW: 
measurements-format = [ 
content-format: uint, 
content: bytes .cbor 
] 
Tracked in open issue [2] 

> [Section 5.2.1.1.4]

> It says:

>> The receiver MUST reply with an EAD item corresponding to the background-check
> > model.

> Isn't such an EAD item exactly "Attestation_proposal" from Section 5.2.1.1.1?

The EAD item could be either "Attestation_proposal" (default) or "Evidence" (the simplified version that was just updated in the latest version). I will clarify it in the next version. Tracked in open issue [2]. 

> [Section 5.2.1.1.4]

> The intended and right way is to have ead_value not present.

This will be changed : 
OLD: The ead_value can be empty, as the ead_label serves as the trigger. 
NEW: The ead_value MUST not be present, as the ead_label serves as the trigger. 
Tracked in open issue [2]. 

> [Section 5.2.2.1.2]

> It says:

>> Relying Party generates a nonce to ensure the freshness of the attestation
> > result from the Verifier.

> Where is this nonce included? It is not shown in the Request_structure defined
> below or in the example in Figure 3.

The freshness guarantee in the passport model is still under discussion. We currently have two possible approaches: which is either a nonce or a timestamp with exipiry time indicated. This decision will be finalized in a future version. 

> [Section 5.2.2.1.4]

> It says:

> > The receiver MUST reply with an EAD item corresponding to the passport model.

> Isn't such an EAD item exactly "Result_proposal" from Section 5.2.2.1.1?

The EAD item could either be "Result_proposal" or "Result", I will clarify in the next version, can be tracked in [2] 

> -- [Section 5.2.2.1.4]
> The intended and right way is to have ead_value not present.

Noted in [2]. 

> [Section 6]

> It says:

> > Although there are 8 cases (IoT/Net, BG/PP, Fwd/Rev), ...

> I think you are also silently implying that:

> * Forward Message Flow means that the IoT device is the EDHOC
>       Initiator, while it should just mean that the EDHOC Initiator is a
>       CoAP client.

> * Reverse Message Flow means that the IoT device is the EDHOC
>       Responder, while it should just mean that the EDHOC Initiator is a
>       CoAP server.

> If you actually mean that, it's good to make it explicit.
>       Otherwise, the cases are more, and the tuple needs to also
>       indicate whether the Attester is the Initiator or the Responder.

A discussion of the cases has happened in this thread [5], and we will make the cases explicit in the next version. 

> [Section 6.1]

> The EDHOC connection identifier C_R appears for the first time
>       here in Figure 1, but it is never mentioned in the text here in
>       Section 6.1 or earlier in Section 5.2.1.

> I guess that the intent is to allow the Verifier to correlate an
>       Attestation Proposal with a later corresponding Evidence. If so:

> * Is that correlation actually required? After all, Evidence comes
>       back as including the Nonce that the Verifier offered together
>       with the EvidenceType(s).

> * A Verifier might be contacted by multiple Network Services
>       acting as Relying Party, which might accidentally be using the
>       same EDHOC Connection Identifier C_R in their respective EDHOC
>       sessions with different IoT devices, thus creating ambiguity at
>       the Verifier.

You are right. We also discussed during the Hackathon side meeting, that sending C_R to the Verifier is not a good idea. Nonce could be used for this correlation, we will remove this C_R in the next version. 

> [Section 10.1]

> It says:

> > The ead_label = TBD1 corresponds to the ead_value
>       Attestation_proposal in Section 5.2.1.1.1, Attestation_request in
>       Section 5.2.1.1.2 and Evidence in Section 5.2.1.1.3.

> When receiving an EDHOC message with the EAD item with label
>       -TBD1, how does the recipient distinguish whether it is exactly
>       about Attestation_proposal, Attestation_request or Evidence?

> The inclusion in one EDHOC message or other might still be
>       ambiguous, so is that based on the unique (?) structure of the
>       ead_value?

> The same goes for the later definition of the ead_label TBD3.

The reason that they use the same label is because the Attestation_request is only received by the Attester, and the Attestation_proposal and the Evidence are only received by the Relying Party in message_1 and message_3 separately. And they are never sent together in the same message. However, I will add a clarification in the section 5.2.1 and 5.2.2[4]. 

BR, 
Yuxuan. 

[1] [ https://www.ietf.org/archive/id/draft-ietf-rats-eat-31.html#name-measurements-measurements-c | https://www.ietf.org/archive/id/draft-ietf-rats-eat-31.html#name-measurements-measurements-c ] 
[2] [ https://github.com/lake-wg/ra/issues/14 | https://github.com/lake-wg/ra/issues/14 ] 
[3] [ https://github.com/lake-wg/ra/issues/13 | https://github.com/lake-wg/ra/issues/13 ] 
[4] [ https://github.com/lake-wg/ra/issues/15 | https://github.com/lake-wg/ra/issues/15 ] 
[5] [ https://mailarchive.ietf.org/arch/msg/lake/g4LRNn7pzqqHjoOz4WvpIdmYq7s/ | https://mailarchive.ietf.org/arch/msg/lake/g4LRNn7pzqqHjoOz4WvpIdmYq7s/ ]