Hi Alexander,

The concern regarding MTU across EAP methods is well understood, particularly 
for methods involving large message exchanges. However, in the case of 
EAP-EDHOC, the expected impact seems to be limited due to the lightweight 
nature of the protocol. EAP-EDHOC is specifically designed to minimize both 
message sizes and the number of exchanges, following the design goals of EDHOC 
for constrained environments.

In addition, MTU constraints are typically already handled at lower layers, and 
no MTU negotiation mechanism is currently defined in other comparable EAP 
method specifications such as RFC9190 (EAP-TLS 1.3), a document which we 
followed during the development of EAP-EDHOC for consistency. Introducing a 
method-specific MTU negotiation mechanism in EAP-EDHOC would therefore add 
additional complexity and potential security considerations (e.g., modification 
of advertised values by an on-path attacker, as commented).

Regarding the use of the MTU for EAP method selection, we understand that the 
availability of a larger MTU does not necessarily imply the need for a heavier 
authentication method. Rather, the choice of EAP method is expected to be more 
related with deployment requirements, security policies...

For these reasons, our current inclination is to keep the EAP-EDHOC 
specification aligned with existing EAP method specifications and not define an 
explicit MTU negotiation mechanism at this stage. However, thank you for the 
proposal!

Best regards,
The EAP-EDHOC authors.

Francisco López Gómez

Predoctoral Researcher
Dept. Ingeniería de la Información y las Comunicaciones

[email protected]<mailto:[email protected]>
[logo UMU]<https://www.um.es>
[logo euniwell]<https://www.euniwell.eu/>
[logo hr]<https://www.um.es/web/hrs4r>
[logo CMN]<https://www.campusmarenostrum.es/>

________________________________
De: Alexander Clouter <[email protected]>
Enviado: viernes, 8 de mayo de 2026 10:36
Para: EMU WG <[email protected]>
Asunto: [Emu] Re: I-D Action: draft-ietf-emu-eap-edhoc-09.txt

On Fri, 17 Apr 2026, at 10:23, [email protected] wrote:
> Internet-Draft draft-ietf-emu-eap-edhoc-09.txt is now available. It is a work
> item of the EAP Method Update (EMU) WG of the IETF.
>
>    Title:   Using the Extensible Authentication Protocol (EAP) with
> Ephemeral Diffie-Hellman over COSE (EDHOC)
>    Authors: Dan Garcia-Carrillo
>             Rafael Marin-Lopez
>             Göran Selander
>             John Preuß Mattsson
>             Francisco Lopez-Gomez
>    Name:    draft-ietf-emu-eap-edhoc-09.txt
>    Pages:   33
>    Dates:   2026-04-17
>
> Abstract:
>
>    The Extensible Authentication Protocol (EAP), defined in RFC 3748,
>    provides a standard mechanism for support of multiple authentication
>    methods.  This document specifies the EAP authentication method EAP-
>    EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC).  EDHOC is
>    a lightweight security handshake protocol, enabling authentication
>    and establishment of shared secret keys suitable in constrained
>    settings.  This document also provides guidance on authentication and
>    authorization for EAP-EDHOC.

Section 3.1.6. Fragmentation,

As this EAP method targets low MTU environments (<256 bytes), it would be 
helpful to explicitly have the supplicant and server send a preferred MTU.

TEAPv2 is proposing a *maximum* MTU as this is even a problem at 1500 bytes for 
all the existing common EAP methods.

If the MTU is actually lower for new EAP methods you still have an opportunity 
to negotiate a lower value, something akin to my proposal for TEAPv2:

https://urldefense.com/v3/__https://github.com/InkbridgeNetworks/teapv2/pull/1__;!!D9dNQwwGXtA!RFeaxyoHroHPlLopsMNV-Tr_1wjTZk7giiMys8Q3M5M_QdCQ8E99QmAGwA_GtfXw3xijm1OSYYpjLq5k0u29D-yRg_XIq4QxEGwg$

Maybe use a reserved bit to indicate there is an MTU preference is included and 
then scale that value by at least 4x to get up to an MTU of 1024; after that I 
maybe using EDHOC makes less and instead an operator would use EAP-TLS.

Security concern, a MitM could amend that value, but if you specify a minimum 
value (32 bytes?), hopefully that impact is lessened.

Cheers

_______________________________________________
Emu mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Emu mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to