Document: draft-ietf-emu-eap-edhoc Title: Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) Reviewer: Ines Robles Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-emu-eap-edhoc-07 Reviewer: Ines Robles Review Date: 2026-02-13 IETF LC End Date: 2026-02-13 IESG Telechat date: Not scheduled for a telechat Summary: This document specifies the EAP authentication method EAP-EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). Overall, the document is comprehensive. I have a few comments and questions that would be good to address before publication. Comments: 1- Section 3.1.2: The intro sentence is unconditional (‘all requirements are fulfilled’), but the detailed text makes it conditional (‘reordering is only OK if the lower layer guarantees ordering’), the wording should reflect the dependency rather than claiming EAP always fulfills it. What about to replace "All these requirements are fulfilled by the EAP protocol, EAP method, or EAP lower layer, as specified in [RFC3748]." for something like "These requirements can be met by a combination of the EAP framework, the EAP-EDHOC method specification, and properties of the EAP lower layer, as specified in [RFC3748]. In particular, correct operation assumes that the EAP lower layer preserves packet ordering within an EAP conversation."? 2- Section 3.1.6:"Implementations MUST NOT set any of the L flag bits to 1 in unfragmented messages. However, implementations MUST accept unfragmented messages regardless of the value of the L flag bits." -> This is ambiguous for Type-Data parsing: if L=1 normally implies the EDHOC Message Length field semantics, but the packet is otherwise unfragmented, how should the receiver parse it? What does ‘accept’ mean operationally in this case? 3- Section 3.1.6: Fragment ACK text uses “no data” for ACK packets. The wire encoding is unclear: does “no data” mean an empty EAP Data field (no Type-Data), or a Type-Data header (e.g., flags) with zero EDHOC payload? Please specify the exact Type-Data encoding for ACK packets (e.g., “flags octet present with S=0, M=0, L=0, zero EDHOC payload”, or explicitly “EAP Data field empty”). 4- Section 3.1.6: Please extend Figure 6 (or add a small table) to include EAP Identifier values on each message (including retransmissions), to make Identifier progression unambiguous. 5- Section 3.5- "...EDHOC error messages are unprotected"-> This means anyone on path can inject/modify an error, so the receiver can’t treat the error code as a trustworthy reason for failure; it only indicates the exchange did not complete. Suggest adding something like: “Because EDHOC error messages are unauthenticated, they must not/(or MUST NOT?) be relied upon to determine the cause of failure; they only indicate that the exchange did not complete and are vulnerable to injection by an attacker (DoS).” 6- Section 6.1.1: RFC 3748 Section 7.2.1 defines the EAP-method security claim ‘Confidentiality’ as encryption of EAP messages (Requests/Responses) and success/failure result indications (EAP-Success/EAP-Failure). In EAP-EDHOC, in my understanding, EDHOC protection applies to the method payload carried in EAP-Request/EAP-Response, but the EAP-Success/EAP-Failure packets themselves are not encrypted or otherwise protected by EDHOC. The current ‘Confidentiality’ claim (message_2 vs message_3/message_4) therefore appears to describe confidentiality of EDHOC payload fields rather than confidentiality of the EAP exchange/result indications. Please consider rewording to specify exactly which EDHOC fields are confidential. 7- Section 6.9: Please add 1–2 sentences explaining why the analogous TLS 1.3 resumption cross-protocol issue cannot occur in EAP-EDHOC (or under what assumptions). Nits: 8- "...from left to right. following" --> from left to right, following 9- beetween -> between Thanks for this document, Ines. _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
