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://github.com/InkbridgeNetworks/teapv2/pull/1 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]
