Hello, during a discussion yesterday with some folks on EAP-PWD, we hit an issue which I think is also of relevance for TEAP.
The issue is: assume an ongoing TEAP tunnel setup, the server sends a certificate, but it's not the one the client expects. With the current tunneled EAP methods (and also PWD in its current form), the client will recognise that it doesn't like the remote end and will stop communicating immediately. For the client, there is no negative side-effect to that. It can simply discard all EAP session state and that's it. The server side though only sees its last EAP-Request going out to the EAP peer, and will wait for a response. The response will never come, but the server needs to keep EAP session state for the conversation until it hits a (potentially very long) timeout. The underlying problem is that the EAP state machine doesn't finish, it just hangs mid-air. One end knows and discards, the other doesn't. This means the server will pile up useless state information. It also makes debugging client problems harder, because there is no final Reject going out to the client (when doing EAP over RADIUS, often Accepts and Rejects are logged, but intermediate Access-Challenges aren't). If there were a "bailout" trailer to end a failed server ID verification, things could get much cleaner in that respect. I'm not sure how exactly to encode it; maybe a EAP-Response with a TLS alert. Upon receiving the alert, the EAP server could craft its final EAP-Failure, send it out, and discard session state. Of course one argument is: if the ID verification failure is because you were connecting to a rogue server, you as a client shouldn't be so kind to help the rogue clean up his state. While that's true, verification failures are extremely often simply due to user misconfiguration (typo in expected server name, wrong CA box ticked) or subtle mis-configuration on the server side (not adding the TLS Web Server OID as Extended Usage, which the Windows supplicant chokes about). In these cases, it is quite helpful to make the server actively aware that something went wrong. I wonder if "something like that" could be considered for TEAP. In eduroam, we sort of miss it in PEAP at least. FreeRADIUS has a heuristic that "guesses" that it's an ID verification problem, but only does so in debug mode. And it being a heuristic, sometimes it's just wrong. So getting a clear "The client didn't like me" message to act upen would be a good thing IMHO. Greetings, Stefan Winter _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
