Dear Ines,
Thank you for taking the time to review the document and for the
comments provided.
We have translated the comments to the document in this PR --
https://github.com/dangarciacarrillo/i-d-eap-edhoc/pull/11
<https://urldefense.com/v3/__https:/github.com/dangarciacarrillo/i-d-eap-edhoc/pull/11__;!!D9dNQwwGXtA!UrSUD6OHKIlBKteKuw_yA68CTelOIQ0WrXxnhOs6jWZvKTLI3Vtn3OgoahrZUzXP7rKiaVSrwa_-VYU$>
Please the our responses inline.
Best regards,
Dan García Carrillo
---------------------
Associate Professor
Dpto. de Informática, Área de Telemática, Universidad de Oviedo
Escuela Politécnica de Ingeniería, C.P. 33203, Campus de Viesques, Gijón
Dpcho. 2.7.8 - Edificio Polivalente
Tel.: +34 985182654 (Ext. 2654) | email:[email protected]
El 14/2/26 a las 4:14, Ines Robles via Datatracker escribió:
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://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!D9dNQwwGXtA!QYID6AYwnzT_5ApqAF_65qcjUIgd5KMWzbadOoGF-vbWpMRtoCtBynTWgFjVCCKiGZ-Zv_pzXQKJpxKe$
>.
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."?
[Authors] Thank you for the suggestion. Indeed, the proposed text is
appropriate to clarify the roles of the different entities in the EAP
framework, so we have included it in the text.
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?
[Authors] The text we have there is coming from EAP-TLS 1.3 RFC 9190.
In any case, we have removed that last phrase to solve the ambiguity.
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”).
[Authors] Thank you for the note. ACK messages will have Type=EAP-EDHOC,
with S=0, M=0, L=0, and empty EDHOC data field. We will clarify this in
the text.
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.
[Authors] We have updated the Figure with the identifiers and added a
retransmission as you suggested.
Hopefully now is clearer. Thank you.
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).”
[Authors] Thank you for pointing that out. We added the text to clarify
that in the document.
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.
[Authors] Thank you. We will clarify this in the text, with something
like the text below. Just mention that we followed the approach of
EAP-TLS 1.3 RFC 9190 that points to the EAP-TLS security claims (RFC
5216) where Confidentiality is set to YES, and the text in EAP-TLS 1.3
talks about encryption in TLS 1.3 , which means the payload.
(6) Confidentiality. *EDHOC protects the method payload transported
within the EAP-Request and EAP-Response messages; however, the
EAP-Success and EAP-Failure packets themselves are not encrypted or
protected by EDHOC. EDHOC message_1 is not confidential, but it does not
convey any private information*. EDHOC message_2 provides
confidentiality against passive attackers, while message_3 and message_4
provide confidentiality against active attackers.
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).
[Authors] Thank you, we clarified that in the text. The resumption
considerations are not an issue here as, this document does not specify
at present time resumption for EAP-EDHOC.
Nits:
8- "...from left to right. following" --> from left to right, following
9- beetween -> between
[Authors] Thank you for pointing this out.
Thanks for this document,
Ines.
_______________________________________________
Emu mailing list -- [email protected]
To unsubscribe send an email to [email protected]
