eap Mailing List: Changes to the EAP state machine to fix DoS

[Bernard Aboba (aboba]

Overall, I agree with Jari that trying to fix EAP DoS vulnerabilities via
the state machine is probably not a worthwhile task.

> To reiterate the NAK case - If we disallow NAKs initially, then in an error
> situation where the peer is unable to do the requested method, the
> authenticator will receive a NAK, not accept it, and eventually timeout.

In pass-through mode, the authenticator does not have an option to ignore
the NAK, correct?

> If the peer is able to do the requested method then everything works as
> expected.  Disallowing the NAK eliminates the possibility that an attacker
> could send a bogus NAK and terminate the connection.

In a situation in which a NAK will never occur, it is possible for a
server to ignore it.  As you mention, this isn't recommended unless it is
truly known that all clients implement the given method.

> I think the case of a Failure attack on the Peer is also interesting.  If a
> peer knows that it is going to do an identity and then method-X, then it
> can ignore everything that is not in that sequence.

That is not advisable, and I don't believe that it's compliant with RFC
3748.  Multiple identities are possible, for example, in EAP network
discovery.  It is also possible that the client will receive a proposal
that it did not expect, for a variety of reasons.  Being unable to deal
with this by refusing to send a NAK makes the protocol more brittle.

> It seems that the Authenticator
> can however initiate EAP authentication using an "empty EAP message" or
> whatever.

An "empty EAP message" is not legal in RFC 3748, so EAP authentication
cannot be initiated this way.  Perhaps you're thinking about the
"EAP-Start" in RFC 3579.