Dear Christian: Thanks for your review.
Please see my comments inline. El 15 jul 2025, a las 14:56, Christian Amsüss <[email protected]<mailto:[email protected]>> escribió: Hello EAP-EDHOC authors, thanks for providing this document, which I think is in a good shape; I'm looking forward to using this combination of technologies. I'm late for the WGLC, but hope that these comments still help. BR Christian Protocol flow ============= * Looking at figure 1 it seems odd that there's a full round-trip before starting EDHOC messages. The EAP-Response/Identity should be able to easily carry a message_1, and there is no identifiying data in there (most sensitive is method and cipher suite, but that's not many bits of identification, it's mostly pure entropy). This looks like a needless round-trip to me. Or are the Identity messages actually more of an exception (it is stated they are optional), so doing anything there would just make matters complicated for little practical gain? (But then, why is it in every example?) [Rafa] I agree with you but the “problem” is the following: we are defining the EAP-EDHOC method with a particular “Type". EAP Response/Identity is the response for the EAP Identity “Type” and it is used to so carry the identity in NAI format (e.g. [email protected]<mailto:[email protected]>), regardless the EAP method. In fact, it might be used to select the EAP method. EAP Request/Identity and EAP Response/Identity are defined in RFC 3748. Having said that, no EAP method defined is using EAP Response/Identity to carry content of a specific EAP method. As an example please take a look at EAP-TLS 1.3 https://www.rfc-editor.org/rfc/rfc9190.html This may be obvious to readers coming from the EAP side, but for me coming from EDHOC and knowning EAP mainly as a user, it is not. * Cipher suite negotiation: EDHOC says that "The Initiator SHOULD remember which selected cipher suite to use until the next message_1 has been sent". The initiator here is the peer, so remembering this information means recognizing that it's the same server (and same authenticator) that is making the request. Is that something EAP provides in general, and can you make a recommendation as to what precisely to key the memory on? (This is a general concern in EDHOC (see [thread]), but until that is resolved, I hope that EAP has the easy way out and can remember). [thread]: https://mailarchive.ietf.org/arch/msg/lake/Aq2KEecA1PnX5rXHBYLytoXLuqw [Rafa] Yes, that is part of EAP and it was somehow discussed earlier. https://mailarchive.ietf.org/arch/msg/emu/C88edBSi52ZLUqxr4tIFeIJF2eU/ . Also in the meeting the packets of EDHOC in an EAP authentication session will happen between the same EAP peer and the EAP server. We can assume different EAP authentication session are distinguishable. https://mailarchive.ietf.org/arch/msg/emu/C88edBSi52ZLUqxr4tIFeIJF2eU/ Ecosystem interactions ====================== * Section 3.2 talks at length about how server certificate is verified. Exceeding the typical certificate mechanisms, EDHOC extensions provide additional means to verify the server's credentials, such as [ELA]; this could be a useful poiner to anyone struggling to provide the right root CA. [ELA]: https://datatracker.ietf.org/doc/draft-ietf-lake-authz/ [Rafa] I think we could reference this. Editorial ========= * "The optimization combining the execution of EDHOC with the first subsequent OSCORE": "not supported" sounds like one could potentially make it supported; "not applicable" might describe things better. [Rafa] Ok * "EAP_1" and "EAP_2" are mentioned only once, and are not terms I found in the referenced documents. Which are those, and where do they show up in the hashes? (Should those say "EAD_1" and "EAD_2"? Or are they really TBD5? TBD1 x 1/2 for Code Request/Response?) [Rafa] Yes, there should be EAD_1 and EAD_2 Thank you! -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
