IETF working group for EAP Methods Update (EMU)

Stefan Winter | 27 Mar 2012 11:25

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.

(Continue reading)

headers

Hao Zhou | 27 Mar 2012 13:41

Re: 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.winter <at> 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.
>

(Continue reading)

headers

Stefan Winter | 28 Mar 2012 09:43

Re: 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.winter <at> restena.lu> wrote:
>
>> Hello,
>>

(Continue reading)

headers

Alan DeKok | 27 Mar 2012 17:06

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

(Continue reading)