Hi, > 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.
D'oh, I only looked in 3.2 "Phase 1" and overlooked that text further down. Sorry for the noise... and a +1 that this is the right response to send! Stefan > > > 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
