Hi.
Please, find below some comments about draft-ietf-emu-eap-edhoc-02. Mostly
editorial…
Best regards, Gabi.
[Section 1]
s/"The Extensible Authentication Protocol (EAP), defined in [RFC3748], provides
a standard mechanism for support of multiple authentication methods./ "The
Extensible Authentication Protocol (EAP), as defined in [RFC3748], serves as a
standardized framework for supporting various authentication methods.”
s/"EDHOC is a very compact and lightweight authenticated key exchange protocol
designed for highly constrained settings.”/"EDHOC is an exceptionally compact
and lightweight authenticated key exchange protocol specifically designed for
resource-constrained environments.”
s/"The main objective for EDHOC is to be a matching security handshake protocol
to OSCORE”/“The main objective for EDHOC is to be a matching security handshake
protocol for OSCORE”"
s/"and specifies the use of CoAP but is not bound to a particular
transport”/"and specifies the use of CoAP, but is not bound to a particular
transport”
[Section 3.1]
s/"In an EDHOC session, EAP-EDHOC uses all messages including message_4, which
is mandatory and acts as a protected success indication.”/“In an EAP-EDHOC,
message_4 is mandatory and functions as a protected success indication."
s/"with EAP-Type=EAP-EDHOC as described in this document”/"with
EAP-Type=EAP-EDHOC, as described in this document”
“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.
I think the descripción of the EAP entities can be improved with something
like:
“As a reminder of the EAP entities and their roles involved in the EAP
exchange, EAP defines the following entities: EAP peer, EAP authenticator and
EAP server. The EAP authenticator verifies the identity of the EAP peer by
forwarding its authentication credentials to the EAP server, the EAP peer is
entity being authenticated, which provides its credentials to prove its
identity to the authenticator. The EAP server performs the actual
authentication of the EAP peer and determines the authentication method to be
used.”
s/“ 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.” / "If
the EAP server is not located on a backend authentication server (Passthrough
behavior), the EAP server is part of the EAP authenticator (No-passthrough
behavior). For simplicity, this document assumes the No-passthrough scenario."
s/"EAP-EDHOC provides forward secrecy, by means of the ephemeral
Diffie-Hellman” / “EAP-EDHOC provides forward secrecy by means of the ephemeral
Diffie-Hellman"
[Section 3.1.1]]
s/“Figure 1 shows an example message flow for a successful execution of
EAP-EDHOC” / “Figure 1 shows an example of the message flow for a successful
execution of EAP-EDHOC”
[Section 3.1.2]]
s/“to use with EDHOC”/“to be used with EDHOC"
s/“For message loss, this can be either fulfilled by the EAP layer, or the EAP
lower layer, or both.” / “For message loss, this can be either fulfilled by the
EAP layer, the EAP lower layer, or both.”
s/“The EAP framework [RFC3748], specifies “ / “The EAP framework [RFC3748]
specifies “
[Section 3.1.3]
s/“Figure 4, and Figure 5” / “Figure 4 and Figure 5”
[Section 3.1.5]
“EAP-EDHOC is always used with privacy.” —> Can you elaborate this? Is there
any other alternative? this paragraph sounds ambiguous.
[Section 3.1.6]
s/“as well as a (conditional) EAP-EDHOC Message Length field that can be one to
four octets.” / "as well as a (conditional) EAP-EDHOC Message Length field,
which can be between one and four octets.
s/"fields that allow for the specification”/"fields allowing the specification”
s/“Of these fields, we will highlight” / “Among these fields, we will highlight"
—> a new figure with the octet field would help here
s/"which is in the”/“defined in the"
s/ small and the length of the certificate chains short.” / "small, while
ensuring the certificate chains are kept short."
“In addition, it is RECOMMENDED to use mechanisms that reduce the sizes of
Certificate messages.” —> sizes of Certificate messages or size of
Certificates? examples of mechanisms would help here
“EAP-EDHOC fragmentation support is provided …” —> should this paragraph be
moved to the beginning of this section? at least, to be aligned with paragraph
2 and 3.
s/“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 an no data.” / “
"When an EAP-EDHOC peer receives an EAP-Request packet with the M bit set, it
MUST respond with an EAP-Response, where EAP-Type is set to EAP-EDHOC and no
data is included.”
"the EAP server MUST increment the Identifier field for each fragment contained
within an EAP-Request” —> align this sentence according the comments received
by Josh and Francisco. Same for the EAP peer (next paragraph)
[Section 3.2]
“The EAP server identity in the EDHOC server certificate is typically a fully
qualified domain name (FQDN) in the SubjectAltName (SAN) extension.” —> Is this
extension mandatory in this case? and if not present?
"EAP peers MAY implement a Trust On First
Use (TOFU) mechanism where the peer trusts and stores the server
certificate during the first connection attempt.”
—> A reference would help here.
[Section 3.3]
"The Key_Material and Method-Id SHALL be derived” —> Key_Material is not used
again —> “key material”?
TBD2, TBD3 and TBD4 are not mentioned in the text —> refer to 5.2
[Section 4.1]
s/“The EDHOC Message Length field can have a size of one to four octets and”/
"The EDHOC Message Length field can range in size from one to four octets, and "
El 23 ene 2025, a las 13:54, Dan Garcia Carrillo
<garcia...@uniovi.es<mailto:garcia...@uniovi.es>> escribió:
Dear Josh,
Thank you for confirming comment about ordering.
We will incorporate the changes in the next version of the draft.
Best regards.
El 2/12/24 a las 12:27, josh.howl...@gmail.com<mailto:josh.howl...@gmail.com>
escribió:
Re the text about the EAP Session Identifier
* "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."
The EAP Session Identifier does not provide sequencing information. RFC3478
Section 3.1: "EAP does not require the Identifier to be monotonically
increasing, and so is reliant on lower layer ordering guarantees for correct
operation". As Francisco says, it is the lock-step operation of EAP that
guarantees ordering.
Josh
_______________________________________________
Emu mailing list -- emu@ietf.org<mailto:emu@ietf.org>
To unsubscribe send an email to emu-le...@ietf.org<mailto:emu-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<mailto:garcia...@uniovi.es>
_______________________________________________
Emu mailing list -- emu@ietf.org<mailto:emu@ietf.org>
To unsubscribe send an email to emu-le...@ietf.org<mailto:emu-le...@ietf.org>
-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: gab...@um.es<mailto:gab...@um.es>
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
