Hi Marco,
Thank you very much for the review.
Please, see comments inline.
Best regards.
El 26/9/24 a las 13:51, Marco Tiloca escribió:
Hi all,
Please see below some comments about this document. Hope it helps!
Best,
/Marco
-------------------------------
[General]
* The title can include "(EAP)" after "Extensible Authentication
Protocol".
I think there should be no problem adding it to the title.
[Abstract]
* "This document specifies the use of EAP-EDHOC with Ephemeral
Diffie-Hellman Over COSE (EDHOC)."
Consistent with the phrasing in Section 1, this can be rephrased as
below:
"This document specifies the EAP authentication method EAP-EDHOC,
based on Ephemeral Diffie-Hellman Over COSE (EDHOC)."
Ok, this can be adapted as well.
* Here in the abstract, it is good to mention COSE and CBOR, but it
seems excessive to include their RFC numbers, i.e., "(RFC 9052, RFC
9053)" and "(RFC 8949)".
Thank you, we can remove that in the abstract of course.
[Section 1]
* "... utilizing the EDHOC protocol cipher suite negotiation and
establishment of shared secret keying material. Ephemeral Diffie-
Hellman Over COSE (EDHOC, [RFC9528]) is a very compact and lightweight
authenticated key exchange protocol designed for highly constrained
settings."
Proposed rephrasing:
"... utilizing the cipher suite negotiation and the establishment of
shared secret keying material provided by Ephemeral Diffie-Hellman
Over COSE (EDHOC) [RFC9528]. EDHOC is a very compact and lightweight
authenticated key exchange protocol designed for highly constrained
settings."
Thank you, the rephrasing looks good.
[Section 2]
* It would be good to also mention what the reader is expected to be
familiar with. This includes at least EAP and EDHOC.
Good point, we will add those comments to the section.
[Section 3.1]
* "EAP-EDHOC uses all messages in the exchange, and message_4 is
mandatory, as an protected success indication."
Proposed rephrasing:
"In an EDHOC session, EAP-EDHOC uses all messages including
message_4, which is mandatory and acts as a protected success indication."
* "... the conversation will continue with the EDHOC protocol
encapsulated in the data fields of EAP-Response and EAP-Request packets."
Proposed rephrasing:
"... the conversation will continue with the EDHOC messages
transported in the data fields of EAP-Response and EAP-Request packets."
[Section 3.1.1]
* "... by exchange of ephemeral Diffie-Hellman public keys in
message_1 and message_2."
Proposed rephrasing:
"... , by means of the ephemeral Diffie-Hellman public keys
exchanged in message_1 and message_2."
Thank you all the proposed rephrasing seem fine.
* "Figure 1 shows an example message flow for a successful EAP-EDHOC."
Is the figure actually showing an example? It seems to be *the* way
a successful execution of EAP-EDHOC works.
As the outcome of an EAP exchange can also be Failure, we just wanted to
clarify that, but we can add the clarification as well.
* The caption of Figure 1 can instead be "EAP-EDHOC Message Flow".
Sure, it might be clearer.
[Section 3.1.2]
* "Nonetheless, EDHOC specification has a set of requirements for its
transport protocol [RFC9528]."
I think you mean:
"Nonetheless, [RFC9528] provides a set of requirements for a
transport protocol to use with EDHOC."
Yes, thank you .
* "These include handling message loss, reordering, duplication,
fragmentation, demultiplex EDHOC messages from other types of
messages, denial-of-service protection, and message correlation."
Proposed rephrasing (also for better matching the order of the
following paragraphs):
"These include: handling the loss, reordering, duplication,
correlation, and fragmentation of messages; demultiplexing EDHOC
messages from other types of messages; and denial-of-service protection."
Good point, it might be clearer this way.
* "For duplication and message correlation, EAP has the Identifier
field, which allows both the peer and authenticator to detect
duplicates and match a request with a response."
As I understand Section 4.1 of RFC 3748, the Identifier field works
well for correlating an EAP-Request with the corresponding EAP-Response.
However, I don't understand how the EAP-EDHOC server can use the
Identifier field here in a way that:
- is consistent with the rules in Section 4.1 of RFC 3748; and
- ensures that the EAP-EDHOC peer recognizes the EAP-Requests
transporting EDHOC message_2 and message_4 as pertinent to the same
EDHOC session started by the EAP-Response transporting EDHOC message_1.
In other words, when the EAP-EDHOC peer receives an EAP-Request
transporting an EDHOC message, how does the EAP-EDHOC peer retrieve
the protocol state for the EDHOC session started with the previously
sent EDHOC message_1? See also Section 3.4.1 of RFC 9528 for more
details on message correlation in EDHOC.
In order to build that correlation among EDHOC messages belonging to
the same EDHOC session, RFC 9528 suggests a number of possible ways.
One of those consists in prepending EDHOC messages with the EDHOC
connection identifiers, as appropriate with the underlying transport
and its intrinsic message correlation properties.
As far as I can tell, EAP-EDHOC is akin to the EDHOC reverse message
flow when EDHOC messages are transported in CoAP messages (see
Appendix A.2.2 of RFC 9528).
In the same spirit, you may consider to extend the format of the
EAP-EDHOC Request Packet, later in Section 4.1. The additional content
would be the EDHOC connection identifier C_I of the EAP-EDHOC peer,
which allows the EAP-EDHOC peer to retrieve the protocol state of the
correct EDHOC session when receiving an EAP-EDHOC Request.
Since such a connection identifier is a hint and is *not* part of
the actual EDHOC message, an appropriate place to specify it is right
after the "Flags" byte. In particular, it can work with the following
two new fields, after the “Flags” byte.
- CID Length (1 byte): its value is the length Z in bytes of the
following field CID.
- CID (Z bytes): its value is the binary representation of a CBOR
data item, which encodes the connection identifier C_I as per Section
3.3.2 of RFC 9528.
If the EAP-Request is specifically EDHOC Start, then the CID field
can specify the CBOR Simple Value True (0xf5) as a sentinel value
(since, at that point, no C_I has been allocated as EDHOC connection
identifier of the EAP-EDHOC peer yet).
This is an interesting subject. We will surely work on improving the
explanation.
There are several points to have into account.
1) EAP is a lock-step protocol which means, 1) only supports a single
packet in flight, so other than the initial Request, a new Request
cannot be sent prior to receiving a valid Response.
2) If we look now at how the Identifier works in EAP.
According to RFC3748
• "The Identifier field is one octet and aids in matching Responses
with Requests. "
• " [...] the Identifier space is unique to each session,
authenticators are not restricted to only 256 simultaneous
authentication conversations."
This allows for a single EAP authentication in a session with separate
Identifier space between sessions between the EAP peer and the
authenticator.
Taking into account this, we think the text applicable regarding EDHOC
message correlation would be:
RFC9528 -- 3.4.1. EDHOC Message Correlation
[...]
"Note that correlation between EDHOC messages may be obtained without
transport support or connection identifiers, for example, if the
endpoints only accept a single instance of the protocol at a time and
execute conditionally on a correct sequence of messages."
So, we understand that by relying on this, the correlation should be
done correctly.
* "... which allows both the peer and authenticator to ..."
The "authenticator" appears here for the first time and is not shown
in the previous Figure 1. Its next instance as "EAP authenticator" in
Section 3.1.4 makes it evident that it is a different entity from the
EAP-EDHOC Server.
I think it's fine that the figures do not include the EAP
authenticator, but it would be better to introduce/remind the concept
of EAP authenticator early in the document (perhaps in Section 3.1),
so that it is not a surprise here in Section 3.1.2 and its role is
well understood.
Thank you, we should add a reminder or an introduction to the entity to
avoid confusion.
* "To demultiplex EDHOC messages from other types of messages, EAP
provides the Code field."
Is this correct? My understanding of Section 4.1 of RFC 3748 is that
the Code field is used to distinguish EAP requests and responses.
Instead, different message types are distinguished by means of the
Type field. This is also consistent with the figures of this document
that show EAP-Type=EAP-EDHOC for EAP messages transporting EDHOC messages.
Yes, you are correct.
[Section 3.1.3]
* It seems to me that the first two paragraphs are more appropriate in
Section 3.1.1 instead.
* As to the second paragraph:
"If the EAP-EDHOC server authenticates successfully, the EAP-EDHOC
peer MUST send an EAP-Response message with EAP-Type=EAP-EDHOC
containing no data. Finally, the EAP-EDHOC server sends an EAP-Success."
Actually, the EAP-EDHOC peer authenticates the EAP-EDHOC server
after receiving EDHOC message_2. Also, consistent with Figure 1, the
mentioned EAP-Response is specifically sent after EDHOC message_4,
i.e., after having achieved key confirmation. I think you mean:
"If the EAP-EDHOC server authenticates successfully, and the
EAP-EDHOC peer achieves key confirmation by successfully verifying
EDHOC message_4, then the EAP-EDHOC peer MUST send an EAP-Response
message with EAP-Type=EAP-EDHOC containing no data. Finally, the
EAP-EDHOC server sends an EAP-Success."
This is a good point and should be useful to clarify for the correct
understanding of the underlying protocol.
[Sections 3.1.4 and 3.1.5]
* The word "client" is apparently used to refer to either of the
EAP-EDHOC peer and EAP-EDHOC server.
Is that the intention? Perhaps a different word like "node" fits
better and with less ambiguity.
The intention here is to refer to the EAP peer, and that the server
should support it. But as you say, we will clarify this in the text.
[Section 3.1.6]
* "... derivation function which in turn is decided by the EDHOC hash
function."
This should be:
"... derivation function, which in turn is determined by the EDHOC
hash algorithm of the EDHOC cipher suite that is used in the EDHOC
session."
* "Furthermore, in the case of sending a certificate in a message
instead of a reference, a certificate ..."
Proposed rephrasing:
"Furthermore, when an EDHOC message specifies a certificate as the
sender's authentication credential and the certificate is transported
by value instead of identified by reference, the certificate ..."
* "... is provided in IPv4 EAP-EDHOC fragmentation ..."
Perhaps the sentence should end with "IPv4" and then a new sentence
start with "EAP-EDHOC" ?
Thank you, we will rephrase as suggested.
* Figure 6
The three fragments of EDHOC message_3 also mention "EDHOC
message_3" in their description.
Shouldn't then all the three fragments of EDHOC message_2 also
mention "EDHOC message_2 in their description? (Currently, that's the
case only for the first fragment)
Good point, we will correct it for clarity.
[Section 3.2]
* "If server name matching is not used, then it degrades the
confidence that the EAP server with which it is interacting is
authoritative for the given network."
I think you mean:
"If server name matching is not used, this degrades the confidence
that the EAP server with which the EAP peer is interacting is
authoritative for the given network."
Thank you, we will rephrase as you suggest.
[Section 3.4]
* "defined in Section 7 of [RFC9528]"
This should refer to Section 8 instead.
Yes, thank you.
[Section 4.1]
* "The Identifier field MUST be changed on each Request packet."
Based on Section 4.1 of RFC 3748, that's the case only for new
(non-retransmission) requests, while a retransmitted request uses the
same Identifier value.
Proposed rephrasing:
"The Identifier field MUST be changed on each new
(non-retransmission) Request packet, and MUST be the same if a Request
packet is retransmitted due to a timeout while waiting for a Response."
Good point, thank you.
* "The EDHOC data consists of the encapsulated EDHOC packet in EDHOC
message format."
Proposed rephrasing:
"The EDHOC data consists of the transported EDHOC message."
[Section 4.2]
* "The EDHOC data consists of the encapsulated EDHOC message."
Proposed rephrasing:
"The EDHOC data consists of the transported EDHOC message."
[Section 6.1]
* "... the selected cipher suite is the first cipher suite that the
Responder supports."
This should better say:
"... the selected cipher suite is the cipher suite that is most
preferred by the Initiator and that is supported by both the Initiator
and the Responder."
Thank you, we will rephrase as you suggest.
[Nits]
* Section 1
--- s/EAP-EDHOC which uses/EAP-EDHOC, which uses
--- s/use cases such as/use cases, such as
--- s/OSCORE, CBOR [RFC8949]/OSCORE, i.e., CBOR [RFC8949]
--- s/[RFC9053] and specifies/[RFC9053], and specifies
* Section 3.1
--- s/processing of the EDHOC message/processing of EDHOC messages
* Section 3.1.1
--- s/a successful EAP-EDHOC./a successful execution of EAP-EDHOC.
* Section 3.1.2
--- s/EAP layer or the EAP lower layer or both./EAP layer, or the EAP
lower layer, or both.
* Section 3.1.3
--- s/Figure 3 and Figure 4/Figure 3, and Figure 4
* Section 3.1.6
--- s/the size of plaintext in/the size of the plaintext in
--- s/may thus be larger/may be larger
--- s/a EDHOC Message/an EDHOC Message
--- s/sent from the EAP server/sent by the EAP server
* Section 3.3
--- s/EDHOC-Exporter/EDHOC_Exporter (4 instances)
* Section 6.1
--- s/compromise of one/compromise of a
--- s/ciphersuites/cipher suites
Just want to thank you for the thorough review.
Best regards,
--
Marco Tiloca
Ph.D., Senior Researcher
Phone: +46 (0)70 60 46 501
RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)
Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity
https://www.ri.se
_______________________________________________
Emu mailing list --emu@ietf.org
To unsubscribe send an email toemu-le...@ietf.org
--
Dan García Carrillo
---------------------
Departamento de Informática, Área de Telemática, Universidad de Oviedo
2.7.8 - Escuela Politécnica de Ingeniería, 33204, Campus de Viesques, Gijón
Tel.: +34 985182654 (Ext. 2654) | email:garcia...@uniovi.es
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
