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
