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". [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)."
* 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)".
[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."
[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.
[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."
* "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.
* The caption of Figure 1 can instead be "EAP-EDHOC Message Flow". [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."
* "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."
* "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).
* "... 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.
* "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.
[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."
[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.
[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" ?
* Figure 6The 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)
[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."
[Section 3.4] * "defined in Section 7 of [RFC9528]" This should refer to Section 8 instead. [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."
* "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."
[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 -- 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
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
