EDHOC client initiator's waiting behavior

eriptic / uoscore-uedhoc

C implementations for constrained (and non-constrained) devices of the IETF protocols OSCORE and EDHOC

Other

15 stars 15 forks source link

EDHOC client initiator's waiting behavior #48

Open actyp opened 1 year ago

actyp commented 1 year ago

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 fbaa96caa1a2028d369c70e24a173caa60a0ce15 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.