Hi all, See below some comments about draft-ietf-emu-eap-edhoc-02. While I do not have extensive experience in reviewing IETF documents, I have been working on an EAP-EDHOC implementation and its analysis for nearly a year, which I hope provides useful insights.
I hope these comments are helpful! Best regards, Francisco. --------------------------------------------------------- [Section 3.1. Overview of the EAP-EDHOC Conversation] * "As a reminder of the EAP entities and their roles involved in the EAP exchange, we have the EAP peer, EAP authenticator and EAP server. The EAP authenticator is the entity initiating the EAP authentication. The EAP peer is the entity that responds to the EAP authenticator. The EAP server is the entity that determines the EAP authentication method to be used. If the EAP server is not located on a backend authentication server, the EAP server is part of the EAP authenticator. For simplicity, we will show in the Figures with flows of operation only the EAP peer and EAP server." > Proposed rephrasing to clarify the EAP entities and their roles: "The EAP exchange involves three key entities: the EAP peer, the EAP authenticator, and the EAP server. The EAP authenticator is a network device that enforces access control and initiates the EAP authentication process. The EAP peer is the device seeking network access and communicates directly with the EAP authenticator. The EAP server is responsible for selecting and implementing the authentication methods and for authenticating the EAP peer. When the EAP server is not located on a separate backend authentication server, it is integrated into the EAP authenticator. For simplicity, the operational flow diagrams in this document decipt only the EAP peer and the EAP server." [Section 3.1.4. Identity] * "It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity Response as such identities are routable and privacy-friendly." > Proposed rephrasing to improve readability: "It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity Response, as these identities are both routable and privacy-preserving." [Section 3.1.6. Fragmentation] * "EAP-EDHOC fragmentation support is provided through the addition of a flags octet within the EAP-Response and EAP-Request packets, as well as a (conditional) EAP-EDHOC Message Length field that can be one to four octets. To do so, the EAP request and response messages of EAP-EDHOC have a set of information fields that allow for the specification of the fragmentation process (See Section 4 for the detailed description). Of these fields, we will highlight the one that contains the flag octet, which is used to steer the fragmentation process." > These two paragraphs seem redundant, or at least the second one is not > entirely clear. In my opinion, the first paragraph is enough to explain this > content. Additionally, in the first paragraph "EAP-Response and EAP-Request > packets" is used, while in the second paragraph "EAP request and response > messages" is used. At least, I will unify the terminology. ====== * "Implementations MUST NOT set the L bit in unfragmented messages, but they MUST accept unfragmented messages with and without the L bit set. Some EAP implementations and access networks may limit the number of EAP packet exchanges that can be handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes of EAP-EDHOC peer, EAP-EDHOC server, and trust anchor authentication credentials small and the length of the certificate chains short. In addition, it is RECOMMENDED to use mechanisms that reduce the sizes of Certificate messages." > Proposed rephrasing to improve readability: "Implementations MUST NOT set the L bit in unfragmented messages. However, they MUST accept unfragmented messages regardless of whether the L bit is set. Some EAP implementations and access networks impose limits on the number of EAP packet exchanges that can be processed. To minimize fragmentation, it is RECOMMENDED to use compact EAP-EDHOC peer, EAP-EDHOC server, and trust anchor authentication credentials, as well as to limit the length of certificate chains. Additionally, mechanisms that reduce the size of Certificate messages are RECOMMENDED." ====== * "EDHOC is designed to perform well in constrained networks where message sizes are restricted for performance reasons. In the basic message construction, the size of the plaintext in message_2 is limited to the length of the output of the key derivation function, which in turn is determined by the EDHOC hash algorithm of the EDHOC cipher suite that is used in the EDHOC session. For example, with SHA-256 as EDHOC hash algorithm, the maximum size of plaintext in message_2 is 8160 bytes. However, EDHOC also defines an optional backward compatible method for handling arbitrarily long message_2 plaintext sizes, see Appendix G in [RFC9528]. The other three EAP- EDHOC messages do not have an upper bound." > Proposed rephrasing to improve readability: "EDHOC is optimized for use in constrained networks where message size limitations are critical for maintaining performance. In its basic message construction, the plaintext size of message_2 is restricted by the output length of the key derivation function, which is determined by the EDHOC hash algorithm specified in the chosen cipher suite. For instance, when SHA-256 is used as the hash algorithm, the maximum plaintext size for message_2 is 8160 bytes. However, EDHOC provides an optional, backward-compatible mechanism to handle plaintext sizes in message_2 that are arbitrarily long, see Appendix G in [RFC9528]. Notably, the other three EAP-EDHOC messages (message_1, message_3, and message_4) are not subject to a defined upper size limit." ===== * "Since EAP is a simple ACK-NAK protocol, fragmentation support can be easily added." > The "ACK-NAK protocol" terminology sounds strange for me or, at least, is not > typically used. I will replace it by "lock-step protocol". ===== * "In EAP, fragments that are lost or damaged in transit will be retransmitted, and since sequencing information is provided by the Identifier field in EAP, there is no need for a fragment offset field as is provided in IPv4." > Proposed rephrasing to improve readability: "In EAP, lost or corrupted fragments are automatically retransmitted, and sequencing of fragments is managed using the Identifier field within EAP messages. As a result, EAP does not require a fragment offset field, such as the one used in IPv4, to handle reassembly." ===== * "EAP-EDHOC fragmentation support is provided through the addition of flags octet within the EAP-Response and EAP-Request packets, as well as an EDHOC Message Length field." > This text is repeated with the first paragraph of this section. ===== * "The L flag is set to indicate the presence of the EDHOC Message Length field, and MUST be set for the first fragment of a fragmented EDHOC message. The M flag is set on all but the last fragment. The S flag is set only within the EAP-EDHOC start message sent by the EAP server to the peer. The EDHOC Message Length field provides the total length of the EDHOC message that is being fragmented; this simplifies buffer allocation." > Two annotations about this text. First, it seems strange to me to mention and > explain the L bit in the first paragraphs of this section, but then > explaining all the flags later in this text. Additionally, I would clarify > that the S flag has nothing to be with fragmentation, since it simply marks > the EAP-EDHOC Start message. ===== * "When an EAP-EDHOC peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-EDHOC and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. To prevent errors in the processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value. Similarly, when the EAP-EDHOC server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-EDHOC and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. To prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP- Response." > These two paragraphs can be summarized in this: "When an EAP-EDHOC entity receives an EAP-EDHOC packet with the M bit set, it MUST respond with an EAP packet with EAP-Type=EAP-EDHOC and no data, which serves as a fragment ACK. The other EAP entity MUST wait for this ACK before transmitting the next fragment. To ensure correct fragment processing, the EAP server MUST increment the Identifier value for each EAP-Request, whether it contains a fragment or a fragment ACK. The EAP peer MUST include this Identifier value in the subsequent EAP-Response, irrespective of whether the response is a fragment ACK or a fragment. Retransmitted fragments will contain the same Identifier value." > I am not really sure if your paragraphs are better in IETF terminology, but I > send this text for you to consider it. Additionally, regarding the Identifier > field management, it is something managed by the EAP layer itself, not the > EAP-method layer, since its operation is the same than when there is no > fragmentation, consisting on increasing its value for every Request-Response > pair. Then, I don't know if it is something that should be highlighted here. ===== * "In the case where the EAP-EDHOC mutual authentication is successful, and fragmentation is required, the conversation, illustrated in Figure 6 will appear as follows:" > Proposed rephrasing to improve readability: "Figure 6 depicts a successful EAP-EDHOC exchange with fragmentation. In this example, message_2 and message_3 are each divided into three fragments." [Section 4.1. EAP-EDHOC Request Packet] > Regarding the flags byte, I personally prefer the format used in > draft-ietf-emu-eap-edhoc-00 due to its simplicity. This approach facilitates > protocol implementation and sightly reduces message processing overhead for > both communication parties. Moreover, EAP-TLS also employs a single L bit > along with a fixed-size 4-byte EDHOC Message Length field, making it a well > known and already used format. > Conversely, I understand that the updated flags byte format introduced in > draft-ietf-emu-eap-edhoc-01, combined with the variable-sized EDHOC Message > Length field (ranging from 1 to 4 bytes), provides potential size > optimizations. Specifically, this format can save up to 3 bytes in the > best-case scenario (where the Message Length field occupies only 1 byte) or > none in the worst case (where it still occupies 4 bytes). However, I am not > sure that this benefit is enough to alleviate the previously mentioned > drawbacks. I am aware that you have probably already debated this topic, but > there is a new opinion from the point of view of an implementator of the > method in case it might be of some use. [Section 4.2. EAP-EDHOC Response Packet] > The same discussion than in the previous section. ===== * "EDHOC Message Length The EDHOC Message Length field can be one to four octets and is present only if the L bit is set." > This phrase seems to be outdated, maybe carried from previous versions of the > draft where there was only an L bit. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
