eap Mailing List: Re: [Issue 248] Comments on EAP state machine v4

[Nick Petroni (npetroni]

No worries! I do that kind of stuff all the time.

Some more comments...

> But my point could still apply to a peer that would like to transition
> quickly to success. Here, the difference is probably that the expected
> behavior of the peer is to wait for a success and if it doesn't receive
> one, then if it has had a protected result indication transition to
> success. So I don't think my point is very interesting in this case :-(
The peer should not go to success unless he receives notice from the
authenticator. I will note that there are conditions into SUCCESS that do
not have timers on them, e.g.
(rxSuccess && (reqId == lastId) && (decision != FAIL)) and
(altAccept && decision != FAIL)

The peer cannot spontaneously decide to succeed. Timeout, Success, and
altSuccess are it.

> Hummm
> I had understood that EAP left many doors open for abuses... and I agree
> it is probably too late to try and fix them (and probably not worth it)
> But I deeply regret that
>
> So here is another stupid scenario:
> 1) The valid server sends EAPrequest identity
> 2) The valid peer replies with EAP response identity
> 3) The attacker sends Failure to the peer
>
> In this scenario, for now, whatever the protection of the method the
> peer wants to use, he fails :-( (again in some scenarios - typically
> corporate or domestic - this is sth which we could want to avoid)
>
> It does not harm much (cf. the easier micro-wave oven attack) but it
> would not have been that hard to avoid, wouldn'it?
It is hard to avoid. The peer has to accept certain things based on the
protocol at certain times. Perhaps we could have rewritten EAP so that it
didn't have to fit the old protocol, but ultimately there would be new
places for DoS abuse even in the new version. The peer has no way to
authenticate immediate failures since some implementations really do send
immediate failures. Think of the case where you mistyped your username.
It's likely you would immediately get a Failure, but if you didn't accept
it you would just keep trying and never get any further. Furthermore, it
would take you a lot longer to determine the Authenticator really doesn't
want to authenticate you since you would have to wait for a timeout. It's
impossible to distinguish this case from the forged case.

Regards,
nick