search

lake-wg / edhoc

Ephemeral Diffie-Hellman Over COSE (EDHOC)
Other
6 stars 12 forks source link

Potential errata/updates #457

Open emanjon opened 2 weeks ago

emanjon commented 2 weeks ago

Hi,

When discussing EDHOC during and after the Paris Hackathon on Lightweight IoT Security I noticed the following to things in RFC 9528 that does not seem optimal:

Storing the information here for discussion. If people agree, this could be filed as errata, be included in implementation guidance, be included in a future document updating EDHOC, or be included in a RFC9528bis, etc, ....

OLD:
   The Initiator SHOULD NOT persistently
   store PRK_out or application keys until the Initiator has verified
   message_4 or a message protected with a derived application key, such
   as an OSCORE message, from the Responder and the application has
   authenticated the Responder.

NEW:
   The Initiator SHOULD NOT persistently
   store C_I, C_R, PRK_out, or application keys until the Initiator has verified
   message_4 or a message protected with a derived application key, such
   as an OSCORE message, from the Responder and the application has
   authenticated the Responder.

Motivation: This applies to C_I and C_R equally much as the keys.

OLD:
In deployments where no protected application message is sent from the
Responder to the Initiator, message_4 MUST be supported and MUST be used.

NEW:
?

Motivation: I don't think there is reason to mandate use a forth message if EHDOC is only used for authentication and receipt of messase_3 is signaled by the Responder opening a door/bridge..., i.e., message_4 can be replaced by an action in the real-world.

chrysn commented 2 weeks ago

Interpreting real-world actions sounds like an invitation for mismatches. (Like, if the gate opens after I sent "please open for 6 minutes", how do I known it's not just because someone else asked for 3 minutes open time?)

But maybe the criterion is not having received feedback through some band, but rather the lack of intention to keep communicating, which would make:

NEW:
In deployments where no protected application message is sent from the
Responder to the Initiator *and the initiator uses the key material
after message 3*, message_4 MUST be supported and MUST be used.