Stefan Winter wrote: > 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.
This may be more of a TLS issue. There's a provision for an alert in TLS (IIRC). The client could send an alert saying "closed connection". Sending any more information would mean leaking authentication data. I think it's useful to send a pro-active notification. The reason is that I've seen a lot of support questions asking "why is EAP broken". The typical assumption is that the RADIUS server is broken, because they're looking at the logs on the RADIUS server. Being able to prove that the client is responsible for the connection failure would be very beneficial. > 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. That heuristic is simple: An EAP conversation is ongoing, and then pauses for ~10s. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
