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

[Marco Tiloca <[e-mail]>]

Hi all,

Please see below a few comments on draft-ietf-lake-ra. Hope it helps!

Best,
/Marco

---------------

[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.


[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 ...


[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?


[Section 5.2.1.1.4]

It says:

 > The ead_value can be empty, as the ead_label serves as the trigger.

and

 > * ead_value = null

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


[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.


[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?


[Section 5.2.2.1.4]

It says:

 > The ead_value can be empty, as the ead_label serves as the trigger.

and

 > * ead_value = null

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


[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.


[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.


[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.

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se