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

[Florent Bersani (florent.bersani]

Some more in-line

Nick Petroni wrote:

> There can certainly be cases, at
> least theoretically, where the entity playing the role of EAP Peer
> provides some sort of network service. 
>  
Thx here is the alternate success indication I was looking for :-)

> > I precisely mention the case, when the server has sent his initial
> > request and an attacker replies with a NAKs before the peer replies with
> > the correct response. In this scenario, IINM, although the server may be
> >    
> However, the server has no way to know the Peer was not a valid peer.
> Think about a new person trying to use the network or simply someone using
> the wrong configuration file for their peer software. Even legacy
> software that doesn't support the deployed method could be an issue. If
> they send a Nak and get NO RESPONSE this would make for difficult
> debugging. Sending a Nak at this point is valid and they should at least
> receive a Failure to indicate that their proposal was rejected.
>  
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

>  
>
> > sure that a valid peer won't NAK (a policy decision), figure 4 mandates
> > that it processes the NAK. I find it an unnecessary open a door to a
> > stupid & useless & inefficient DoS (and when one cans close such doors
> > without much trouble, then I recommend closing them although the DoS
> > attack is not dramatic). So my proposed resolution is to allow the
> > policy to set methodstate directly to CONTINUE (while still authorizing
> > it to set the state to PROPOSED) in the PROPOSE_METHOD state. What do
> > you think?
> >    
> I think this is not a useful mitigation. 
I disagree

> 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)

> 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?)

> I think the general rule of "it's no worse than a DoS that
> we know we can't mitigate so why mitigate this one." 
I won't engage in a big fight either here. I think this is a minor issue 
and that it is easy to solve. If people don't want to solve it (because 
they think the resolution costs more than the issue), I respect that 
although i disagree

> 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!

> > > > Comment #17 - Technical
> > > >
> > > > I fail to understand the transition in Figure 7 from
> > > > INITIALIZE_PASSTHROUGH to AAA_IDLE when currentId==None, given that
> > > > AAA_IDLE sets aaaEapResp=TRUE
> > > >
> > > >
> > > >        
> > > I think the point here is that aaaEapResp is telling the lower layer that
> > > it's time for that layer to do something. In this case, no packets have
> > > been sent from anyone so the lower layer will see aaaEapRespData is NONE
> > > and know to start. At least I *think* this is what's going on. Others may
> > > be able to correct me.
> > >
> > >      
> > well, according to the definition of aaaEapResp (section 7.1.1 "Set to
> > TRUE in lower layer, FALSE in authenticator state machine. Indicates an
> > EAP response is available for processing."), aaaEapResp is *not* a vague
> > flag to say to the lower layer to do to do something but a precise flag
> > to say to it that it has a  response available for processing.
> > So I still hold onto this issue. It arises when an authenticator boots
> > and decides directly that it will be pass-through whatever the id of the
> > peer (this behavior appears to be allowed by the state machine). I think
> > it needs a fix.
> >    
> What is the issue precisely?
you say to AAA that you have a response to send (aaaEspResp=TRUE) when 
you don't (aaaRespData=NONE).
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)

> The problem as I see it is if you DON'T set
> aaaEapResp in AAA_IDLE then you will just hang waiting for the lower layer
> when it doesn't know that it's its turn.
>  
I agree : my problem is not with the state but the transition from 
INITIALIZE_PASSTHROUGH to AAA_IDLE with currentid==NONE

Did I clarify?