Re: [Emu] Suggestion for eap-tunnel-method on Phase 1 failure
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
[Emu] Suggestion for eap-tunnel-method on Phase 1 failure
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
Re: [Emu] Suggestion for eap-tunnel-method on Phase 1 failure
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
Re: [Emu] Suggestion for eap-tunnel-method on Phase 1 failure
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
