Subject: [Emu] Suggestion for eap-tunnel-method on Phase 1 failure

From: Stefan Winter <[email-masked]>
Date: Tue, 27 Mar 2012 11:25:41 +0200

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

---

From: Hao Zhou <[email-masked]>
Date: Tue, 27 Mar 2012 07:41:45 -0400

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" <[email-masked]> wrote:

> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Mar 2012 17:06:47 +0200

> 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.

> getting a clear "The client didn't like me" message to act upen would be

  That heuristic is simple: An EAP conversation is ongoing, and then
pauses for ~10s.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Wed, 28 Mar 2012 09:43:40 +0200

Hi,

> 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