CoAP server's behavior on EDHOC Message 3 of second EDHOC Exchange

[actyp]

EDHOC-Fuzzer's learned model of the CoAP server (REL-0.1 -- commit a3abcbb) exposes the following behavior on EDHOC Message 3 of second EDHOC exchange.

a3abcbb Server Test: Unverified EDHOC Message 3 of Second EDHOC Exchange

    CLIENT            SERVER
(EDHOC-Fuzzer)    (Under Testing)
      |------  M1  ----->| * EDHOC Message 1 from EDHOC-Fuzzer
      |<-----  M2  ------| * EDHOC Message 2 from server
      |------  M3  ----->| * EDHOC Message 3 from EDHOC-Fuzzer
      |<----- EMPc ------| * The first EDHOC exchange is completed
      |------  M1  ----->| * EDHOC Message 1 from EDHOC-Fuzzer, starting a new EDHOC Exchange
      |<-----  M2  ------| * EDHOC Message 2 from server
      |------  M3  ----->| * EDHOC Message 3 from EDHOC-Fuzzer
      |<-----  ∅  ------| * The server does not verify the EDHOC Message 3, logs an error
                             and does not respond

Messages used

• M1 (EDHOC Message 1)
• M2 (EDHOC Message 2)
• M3 (EDHOC Message 3)
• EMPc (Empty CoAP message, which means it has no payload)
• ∅ (Timeout, which means that the server did not respond)

Accompanying Files

We can also provide you with the server's log and a wireshark capture of this interaction (either in this issue or via email).

Observed Behavior

The server is able to complete successfully the first EDHOC exchange. However, in the second EDHOC Exchange (that starts with the second EDHOC Message 1 from EDHOC-Fuzzer), the server does not verify the incoming EDHOC Message 3 and does not reply back.

The server receives the second EDHOC Message 3 and logs the following:

Received message from 127.0.0.1:48269
Received message 3
Found state with connection identifier 0
EDHOC processing error: Err(MacVerificationFailed)

Some Questions

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

[geonnave]

Thank you for reporting that.

The behaviour is confirmed and it is due to a reuse of connection identifiers, which for now are not yet dynamically generated. I created issue #83 to track that feature specifically.

[geonnave]

@actyp I believe this is now solved since the merging of #85. Could you please verify?

[actyp]

Using edhoc-fuzzer I have verified that the issue is corrected. I used the commit c40bd2d19561ec985dbcd1ee94cc3c41047cac3f, which showed that the server now generates different connection identifiers and replies correctly to every incoming EDHOC Message 1.

[geonnave]

Great, thank you for confirming this.