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

[Florent Bersani (florent.bersani]

Hi John,

I think you have captured the gist of the conversation and I tend to 
agree with your views.

Some more in-line.

Florent

John Vollbrecht wrote:

> Some discussion below -
>
>
> --On Friday, June 25, 2004 6:33 PM +0200 Florent Bersani 
> <florent.bersani [at] rd.francetelecom.fr> wrote:
>
> > 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 am not sure I understand all the nuances of this conversation. From 
> what I understand and have read, I think Florent has seen and 
> described a possible DOS attack that could be mitigated.   My 
> impression is that Nick is right, that this is not worse than other 
> possible attacks,

I agree: there are many little venues for annoying stupid DoS attacks in 
EAP :-(

I call these attacks annoying because, from a conceptual POV, their 
presence bugs me.

I call these attacks stupid because I don't think that they are very 
efficient and practical (e.g. compared to jamming the link layer) - the 
only advantage I potentially see for now is that they would improve the 
attacker's stealthiness, say, in a wireless setting compared to a 
microwave oven attack (where radiogoniometry can be of some help).

So I understand the "DoS-like" points I raise are well known and that 
there has been a consensus not to solve them, e.g., to preserve backward 
compatibility or to improve EAP behavior when errors occur. If this 
consensus is well-established, which it seems to be, my tentative is 
rather to have text added so that the reader's attention will be drawn 
on these points (and he will be able to understand why they exist). Of 
course, when it is possible to address some of these points, I am 
probably not against it ;-)


> that the Failure attack on the peer is also possible -  and I am not 
> sure how many cases it will help.
>
> 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. 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.
>
> The question in my mind is whether there is ever a situation where a 
> provider might decide that it would only deal with peers that do a 
> particular method, and would be content to let the connection time out 
> if the peer were unable to do the method.
>
> My understanding is that Florent is suggesting that companies might 
> desire to implement such a case, and setting the authenticator to 
> ignore NAKs would eliminate a possible DOS attack.

Right, I am talking of a corporate scenario in which a company wishes to 
provide wireless access to its employees.

> Further, Florent has suggested that the authenticator be allowed to 
> set the initial state "CONTINUE" rather than "PROPOSED" which will 
> cause NAKs to be ignored as proposed.  I think this is possible, but I 
> am not sure it is useful.
>
> In particular, I am not sure how many companies would want to deploy a 
> service which requires all peers to support the same method forever. 
> Presumably at some point new methods might be introduced, and not all 
> clients will have the methods installed at the same time.  There are 
> ways around this, but I think allowing multiple methods makes this 
> sort of transition much easier.

I agree that:
1) I have no idea of the percentage of companies that will have their 
employees use only one method (although I know a good many that do)
2) There is the migration issue

It's just that for now, due to the lack of mature EAP methods, there are 
few alternatives for EAP methods... ;-)

> My proposed change would be to put some words in the description of 
> the PROPOSE METHOD State that mentions that it is possible to set the 
> initial state to CONTINUE, but it is not recommended.  This leaves the 
> door open if there are future NAK attacks, but does not encourage 
> inflexible implementation in normal situations.

Sounds great to me.
(however, if I am the only one in favor of this text, I won't fight for 
it and burden the nice state machine document with my metaphysical 
concerns).

> --
>
> 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.  I think 
> this avoid the possibility of a Failure DOS attack - where an attacker 
> sends a Failure when it sees an identity Response.
>
> I am interested in whether I am missing something here.
>
> If I am right, then some words in the peer could indicate this 
> possibility. 

I also concur

> It does not fit the existing state machine well, so I don't think 
> adding it would be a good idea, but mentioning it somewhere seems 
> reasonable - perhaps in the implementation issues.

I tend to agree.

FYI, the possibility I saw however to mitigate this attack in the peer 
state machine was to tweak the methodState initial value since it is
1) set to NONE in the INITIALIZE state
2) updated in the GET_METHOD and METHOD states if they are reached
3) and checked in the transition to FAILURE from RECEIVED (methodState 
!= CONT)

so setting it to CONT instead of NONE in INITIALIZE would work IINM...