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

[Florent Bersani (florent.bersani]

Nick, all

Nick Petroni wrote:

> Florent and all,
>
> As Monday 7/19 is the cut-off for document submission, I would like to ask
> for help in resolving as much of the remaining issues as possible in the
> state machine document. Here is a list of necessary changes as I see them
> for Issue 248. Please let me know how these look in principle and
> contribute text if possible. I also will attempt to contribute text over
> the next couple of days.
>
> Thanks,
> nick
>
>
>
> Comment #14 - Technical
>  Request text to describe the possible DoS issues and possible
>  mitigation techniques. Specific changes to the SM necessary to
>  achieve such mitigations would be great.
I am reluctant to provide text and modifications to the SM for this one 
(*although I already did in some of my previous mails*) because my 
understanding was that the group had not reached consensus on whether 
this issue has to be handled and how this has to be done...

If the group is (apart from silent) against this issue (and the stupid 
DoS ones in general) which seems to be the case IINM, then I might want 
to save my text/modifications for some other purposes... ;-)

Florent

Florent Bersani wrote:

> Comment #14  - Technical
>
> I am totally novice to DoS (I found a lot of papers on the subject, 
> for instance related to IKE - I plan to read them soon :-)) so this 
> point is probably not very important (my understanding is that one of 
> the difficulties with DoS is to understand what is really relevant and 
> what rather belongs to the .11 microwave oven attack, another one 
> could be set the trade off between DoS resilience and "efficiency").
>
> It just seems to me that Figure 4 prevents the standalone 
> authenticator from ignoring (bogus) NAKs. Indeed, let us consider a 
> corporate WLAN deployment where exactly one EAP method is allowed - so 
> that no valid user will ever NAK. In this setting, there is no point 
> in processing the NAK, possibly loosing the valid user's response if 
> the attacker's NAK arrived first and starting all over. I did not find 
> text on this in RFC 3748 (the text I found was about preventing NAKs 
> when a response to a method has already been received) which is not 
> our case here.