On Mar 19, 2026, at 6:51 AM, Alexander Clouter <[email protected]> wrote: > I think this always comes back to who is going to implement this in a > supplicant. Android may be 'straight forward' but getting Microsoft and Apple > onboard, I have no idea how to do that.
That is difficult. > We might be able to retrofit this EAP-TLS as if we force the the L(ength) > attribute, commandeer a reserved bit to state Outer TLVs are present and slip > on some (unsecured) Outer TLVs. A bad actor could push that down to 200ish > bytes which means a 5x increase in round trips though maybe this is not the > end of the world. The issue is how to do that without breaking existing supplicants. i.e. if they get extra data / flags, do they ignore it, or do they stop doing EAP? > Easier may be to add this to EAP-TTLS and PEAP as there are inner attributes > we should be able to add and existing implementations hopefully would ignore. I think it's too late to add something in the inner attributes. The certs have already been exchanged, and any remaining applications data left is tiny. > On a related note, Mark Donnelly and I are working (read as "barely started") > on tweaks to hostapd and FreeRADIUS to 'repack' EAP-TLS/TTLS/PEAP/... > fragments to split a single EAP message over multiple RADIUS requests. > Hopefully that leads to an informational draft. I suspect that will work, but it definitely scares me. Alan DeKok.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
