Checking G_X in EDHOC Message 1

[marco-tiloca-sics]

In the Editor's copy, the second bullet point at [1] says:

Verify that G_X is not equal to G_X in a simultanous EDHOC message exchange initiated by the Responder.

Could you clarify the exact meaning of "simultaneous EDHOC message exchange" and which of the existing EDHOC sessions should be checked?

In particular, is this limited to checking the sessions that the Responder has started but are still not completed, while simply skipping all the other ones? If so, can a session be considered completed when TH_4 has been computed and stored, or even earlier than that?

[1] https://lake-wg.github.io/edhoc/draft-ietf-lake-edhoc.html#section-5.2.3

[emanjon]

Yes, let's clarify that.

[chrysn]

It would also help narrowing that statement to where it is actually relevant. Reading over "all the state" in a system can be costly, and becomes less and less well-defined the more a system becomes distributed. Reading (for example, if that is the case) over "all the state of exchanges that use a particular PSK" would be more doable.

[pbtgit]

It would also help narrowing that statement to where it is actually relevant. Reading over "all the state" in a system can be costly, and becomes less and less well-defined the more a system becomes distributed. Reading (for example, if that is the case) over "all the state of exchanges that use a particular PSK" would be more doable.
I certainly agree.

[emanjon]

I agree. The G_X is a leftover from the time when we had a PSK mode, It was left as it theoretically is a nice way to stop selfie-attacks for future methods. Given the practical problems and that this is not needed for any of the current methods with mutual authentication I think it should be removed from processing and moved back to security considerations.

• For method 0-3 with mutual authentication, selfie-attacks are not a problem, I will authenticate R.
• For method 0-3 with TOFU, selfie-attacks are a problem, but can then be solved by the looking at CRED_R and making sure CRED_R was not previously sent by I. This is easier to do then checking active G_X.
• For a hypothetical future EDHOC PSK mode, selfie-attack can be mitigated by doing the G_X check, assign strict roles (I or R) to each PSK, or adding some identifier string to e.g. EAD ("42-50-31-FF-EF-37-32-39").

[emanjon]

I made a PR which should address all the aspects of this issue.

• Deleted all G_X checking text
• Separated reflection attack checking from simultanous sessions.

Added the following text

To mititgate reflection attacks, the Initiator MUST verify that the the Responder's identity is not equal to Initiator's, e.g., by checking that ID_CRED_R was not previosly created by the Intiator. Any future EHDOC methods using e.g., pre-shared keys might need to mitigate this in other ways.

Should it be mentioned in message_2 processing? Should it be MUST? Should it take specifically about TOFU?

[emanjon]

Addresses Marcos comments. Seems to be agreement on new text. Merging and closing