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

[Florent Bersani (florent.bersani]

Some more in-line to clarify: I had missed the transition :-((

Nick Petroni wrote:

> > processing any new requests, he updates his m.check function to answer
> > TRUE whatever the input (or sets methodstate to DONE) and waits for the
> > time out, that's his best option (this comes from the examination of the
> >    
> why does he wait for the timeout? There is a direct transition from METHOD
> to FAILURE with no condition for timeout. No? I am referring to the
> rightmost transition in the diagram.
>  
Ooooooooooooops, sorry I had missed that one :-(

All my apologies, sorry for the time i made you loose :-( and many 
thanks for your patience and clarity

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 :-(

> > 2) I did not find a place in RFC 3748 saying that it is forbidden to
> > have multiple round trips of the Identity method. If this is the case,
> > the state machine reflects this... sadly, this leads to an unnecessary
> > (& stupid & not dramatic) DoS attack: the attacker keeps sending EAP
> > Identity request and the peer may keep replying to these requests (and
> > discarding the valid requests of the server). I thought about this when
> > talking about the methodstate variable and noticing that there was a
> > difference between Identity/Notification (which are from a theoretical
> > POV two methods) and the other methods. Namely, while the identity and
> > notification methods do not impact the methodstate variable nor the
> > decision one...
> > I'll post these issues in a separate mail for those who won't have read
> > this lengthy one (I very much understand them ;-))
> >
> >    
> As I said before, if you are looking for DoS mitigation from stray
> messages, EAP is not the place for you. My understanding is that you can
> repeat Identity requests within the protocol, yes. But at this point you
> could have just sent a Failure and ended the conversation anyway, so an
> attacker is not much helped by this fact IMHO.
>  
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?