19-July-2025 EDHOC-PSK interop testing
Page to annotate the results of the interoperability test of EDHOC-PSK during the IETF-123 Hackathon.
📃NOTES
According to RFC9668 (EDHOC over CoAP), message_1 needs to be preceded by a True value 0xF5. https://www.rfc-editor.org/rfc/rfc9668.html
In message_3, c_r is prepended so that the server can verify that the message is part of the handshake. (Part of CoAP profile, RFC9668)
Label KEYSTREAM_3A was incorrect (it changes in EDHOC-PSK with respect to EDHOC RFC9528)
TH_4: Do we use CRED_PSK or key_CRED_PSK?
The issue here is that the CRED_PSK, if defined as the whole structure, contains as well the sub field, which will be different for I and R in order to avoid selfie attacks. Therefore, if we consider CRED_PSK as the whole structure, values such as PRK_4e3m and TH_4 will differ. It might be, therefore, useful to define a new label key_CRED_PSK to refer to the /k/ field (key) of the COSE_key field of the CRED_PSK
CRED_PSK { /CCS/ 2 : "mydotbot", /sub/ 8 : { /cnf/ 1 : { /COSE_Key/ 1 : 4, /kty/ 2 : h'0f', /kid/ -1 : h'50930FF462A77A3540CF546325DEA214' /k/ } } } key_CRED_PSK: 50930FF462A77A3540CF546325DEA214How to define ID_CRED_PSK in message_3? Since we are using the optimization for encoding, we have to follow https://www.rfc-editor.org/rfc/rfc9528.html#name-compact-encoding-of-id_cred . In our example, the value is 0x10, so we keep it as it is, no need for adding 0x41 etc.
✅SUMMARY
The main points are:
Update to the latest version of the draft and follow RFC9668 that specifies how to use EDHOC over CoAP.
Mistakes included using incorrect labels, incorrect versions of the draft (especially in k_3/iv_3 or prk_4e3m)
General comment: We need to clearly define what is CRED_PSK, and whether we use the whole credential or just the key of the COSE_key field. (This affects TH_4, PRK_4e3m)