eap Mailing List: dos vulnerabilities of NAKs and Failures (Was: Re: [eap] [Issue 248] Comments on EAP state machine v4)

[Jari Arkko (jari.arkko]

Florent, Nick -- thanks for discussing the state machine
issues in detail. I'll write my thoughts below about the
DoS-protection for NAKs & Failures part:

I agree that these attacks described by Florent and Nick
do exist. But it is indeed so that EAP was not originally
designed with denial-of-service in mind. While we could
do some things to improve its resilience, I do not
believe that we can make EAP and its current lower
layers bulletproof. A new set of protocols would be
needed for that. While this is a potentially interesting
issue for some of us (including myself), it is not in the
charter of the working group to redesign EAP or make it
incompatible with past implementations.

We are, however, chartered to document EAP behaviour and
security considerations in detail. This should include a
description of the various vulnerabilities we have talked
about here. In some cases we can also specify behaviour which
protects against a specific vulnerability, if interoperability
and other considerations allow this.

As a result, I would recommend documenting the specific
vulnerabilities to accepting NAKs and Failures. I think
RFC 3748 already has some general text about this, but it
would be OK for the state machine document to talk about
specific issues related to specific state transitions.
I am a bit uneasy about changing the actual diagram or
behaviour, however. This is not because of the general
EAP DoS situation, but rather the implications for
debugging, eventual transitions to new EAP methods, and
ability of the network side to fail for various reasons
such as suddenly running out of resources. It looks like
disallowing NAKs and early Failures could be made to
work, but I am just not sure the tradeoff is worth it.

--Jari