Stefan: Actually this is already specified in TEAP. Section 3.6.1, states:
If the TEAP peer detects an error at any point in the TLS layer, the TEAP peer should send a TEAP response encapsulating a TLS record containing the appropriate TLS alert message. The server may restart the conversation by sending an TEAP request packet encapsulating the TLS HelloRequest handshake message. The peer may allow the TEAP conversation to be restarted or it may terminate the conversation by sending an TEAP response with an zero-length message. So the peer should send back a TLS alert, like unknown_ca, certificate_unknown, bad_certificate etc to alert the server that the server certificate failed authentication. On 3/27/12 5:25 AM, "Stefan Winter" <stefan.win...@restena.lu> wrote: > 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
