EDHOC client initiator's waiting behavior

[actyp]

Hello,

We are developing a model learning tool for EDHOC clients and servers and we have used the implementations found in samples/linux_edhoc and samples/linux_edhoc_oscore, in order to learn their models and analyze their behavior.

Regarding the samples/linux_edhoc/initiator of the main branch's commit fbaa96c we observed the following behavior:

The client initiator sends the EDHOC Message 1, receives the EDHOC Message 2 and then sends the final EDHOC Message 3. Interestingly, the client does not wait for a response to the EDHOC Message 3 and terminates immediately.

Is it an issue or is this deliberate ? According to the RFC, shouldn't the client initiator wait for a response to the EDHOC Message 3, in case this response is an (EDHOC) error message ?

[StefanHri]

Hi,

this is just an example showing the happy path of interaction. Generally for me it sounds reasonable what you are saying and I will be happy to merge a PR if you provide one with this fix.

[actyp]

I understand your view on the samples/ directory, but I think that this behavior traces back to the src/edhoc/initiator.c file. Specifically this rx call is not present in the default case (without EDHOC Message 4 support) so the response to EDHOC Message 3 is not received.

Some Questions:

• Can you confirm this behavior?
• Were you aware of it?
• Is it intentional or an oversight?

[StefanHri]

The spec is very clear on this. See EDHOC Message 4.

• Can you confirm this behavior?
  -> yes, message 4 is optional and if the initiator and the responder have a setup where they confirm the the derived key, e.g., through a OSCORE message, message 4 does not need to be send and it is not expected to be received.
• Were you aware of it?

• yes

• Is it intentional or an oversight?
  -> it is a configuration option.

Again the example is showing only a happy path with 3 messages. In this case the application needs to continue with an OSCORE message.