On Nov 10, 2025, at 1:58 PM, Eliot Lear <[email protected]> wrote: >> My $0.02 would be to just use EAP-TLS. The signal of EAP Identity being >> @tls.eap.arp should be enough for people to tell the difference between that >> and normal TLS. > If I understand correctly, Heikki wants a signal to indicate to signal > unauthenticated TLS. Is that on both ends or one?
Only the client would be unauthenticated. It's likely still valuable to authenticate the server > If it's just the client, it should not ever bother to support authenticated > EAP-TLS if it's going to support unauthenticated, because there will be a > constant risk of a downgrade. In that case, maybe it's possible simply to > register something in eap.arpa, but make clear that it's the same EAP-TLS > method (we might want to do the same for TEAP if we're going to play this > game at all). I'm not really worried about downgrade attacks: * If the supplicant doesn't send a client certificate, and uses an EAP Identity of "[email protected]", all EAP authenticators will reject them * If the supplicant doesn't send a client certificate, and uses an EAP Identity of "[email protected]", then they will get on the provisioning network, where they can't do anything other than provision themselves. If the local network is misconfigured, and gives unauthenticated clients full network access, well, that isn't an issue with EAP-TLS. That misconfiguration can happy for any other EAP type, too. Alan DeKok. _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
