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

[John Vollbrecht (jrv]

Some discussion below -


--On Friday, June 25, 2004 6:33 PM +0200 Florent Bersani 
<florent.bersani [at] rd.francetelecom.fr> wrote:

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

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, 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.

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.

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.

--

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

John