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

[Nick Petroni (npetroni]

> I was talking here of a specific (though probably widespread) case: a
> corporation BigCo providing wireless access to its employees.
> Since BigCo is a great corporation, it knows that all its employees use
> EAP-TLS: so whoever tries to connect, if it is a valid employee, it will
> use EAP-TLS
I get it. I always have. You don't have to convince me of the scenario.
I think I am just saying there is an equally devastating attack
of sending a Failure to the peer instead of a Nak to the Authenticator.

> >The reason is simple- an attacker
> >can still spoof a Failure packet in the opposite direction at almost any
> >point for just as easy a DoS.
> >
> Right but this is a different problem that has a different mitigation
> (namely the protected result indication by the method and/or the
> decision/methodstate variable that allows to silently discard the bogus
> failure/success message)
Protected result indications are METHOD SPECIFIC. you have not started the
method at the point when your 'invalid Nak insertion' attack takes place.
You will notice on the Peer that the methodState variable is initialized
to NONE. Therefore, if immediately after (or before) an Identity exchange
the attacker forges a Failure the Peer MUST accept it.

> >Even if you are using a smart method, there
> >will be a window when the attacker can sneak in a Failure in most
> >environments.
> >
> I strongly disagree here: are you talking about protocols (then I'd like
> more precisions because I think it will be hard to demonstrate what you
> say ;-)) or about implementations (then I think this is out of scope
> since our main focus is not what people do or how they do it but rather
> what they should do, isn't it?)
No, this is a protocol issue. There is a window of opportunity at the
beginning where a Failure can be spoofed, just like there is the window
you describe where a Nak can be. The only protection from injected
Failures is methodState == CONT, which it does NOT start out as. Some
methods DO NOT indicate when they are done, and in fact the peer may not
even be able to know if they are.

> >Furthermore, IMHO the
> >protocol issue discussed above is all the more reason not to disallow
> >Naks at this point.
> >
> I didn't say that we should disallow them but allow them to be
> disallowed (i.e. silently discarded) according to a policy!
I know. I think we can agree to disagree and let others weigh in.


[Comment 17]
> >What is the issue precisely?
> >
> you say to AAA that you have a response to send (aaaEspResp=TRUE) when
> you don't (aaaRespData=NONE).
No, you do not. YOu have a respnse *received*. This makes all the
difference in the world. Authenticators *receive* responses and *send*
requests. Requests are generated by the lower layer. If you do not tell
the lower layer that it's time to go, you will hang forever.

> Apart from this IMHO unsatisfactory behavior, I think this is leaving
> the door open to buggy implementations (think of somebody who will send
> sth as soon as aaaEspResp=TRUE with encapsulated whatever garbage was in
> memory for aaaRespData (i.e. missing that aaaRespData=NONE)
send what? Eap Responses are PROCESSED by the lower layer, not SENT. if
the data is NONE then there will be nothing to process. eapRespData is
properly initialized, so your argument that there's garbage there is a bad
one. We can't account for people ignoring variables IMHO.

> Did I clarify?
Did I?