eap Mailing List: Re: Changes to the EAP state machine to fix DoS

[John Vollbrecht (jrv]

--On Wednesday, June 30, 2004 9:00 AM -0700 Bernard Aboba 
<aboba [at] internaut.com> wrote:

> Overall, I agree with Jari that trying to fix EAP DoS vulnerabilities via
> the state machine is probably not a worthwhile task.
>
> > 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.
>
> In pass-through mode, the authenticator does not have an option to ignore
> the NAK, correct?

As you say, the passthru will have to pass the NAK.  It doesn't know that 
it is not going to be accepted by the backend.  The backend however could 
be set to not accept the NAK as described.

I think then if a passthru authenticator gets a NAK and forwards it to the 
backend, the backend will not respond.  If the passthru retries the NAK, 
the backend will still not reply.  If the original NAK was a DOS attack and 
a the real peer send an ACK, it gets through only if the passthru does not 
try to resend the original EAP NAK.

I am not sure what most RADIUS Servers do when they get an unaccepted 
message, and in particular what they do if they get an unexpected NAK or 
Response.  One possibility is for the Server to treat the message as and 
error.  According to RFC 3579  on getting an error - (see sec 2.2)

  A RADIUS server determining that a non-fatal error has occurred MAY
  send an Access-Challenge to the NAS including EAP-Message
  attribute(s) as well as an Error-Cause attribute [RFC3576] with value
  202 (decimal), "Invalid EAP Packet (Ignored)".  The Access-Challenge
  SHOULD encapsulate within EAP-Message attribute(s) the most recently
  sent EAP-Request packet (including the same Identifier value).  On
  receiving such an Access-Challenge, a NAS implementing previous
  versions of this specification will decapsulate the EAP-Request and
  send it to the peer, which will retransmit the EAP-Response.

The backend could treat receiving unexpected info as an error and use the 
above mechanism.  The backend does not do this now - it just goes into 
idle.  A possible solution may be to have the DISCARD state send an Error 
(as above).

This seems a pretty big change.  My first reaction is that it is better to 
let NAKs through and accept that a DOS can happen this way, rather than 
either of the solutions proposed above - e.g.

1) tie up the connection and make it timeout with the same attack by 
setting   methodState to CONTINUE, or,
2) adding sending of failure to DISCARD state in the backend, to allow 
dealing with unexpected messages.

This is an interesting case -- Perhaps someone can propose a better 
solution?

> > 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.
>
> In a situation in which a NAK will never occur, it is possible for a
> server to ignore it.  As you mention, this isn't recommended unless it is
> truly known that all clients implement the given method.
>
> > 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.
>
> That is not advisable, and I don't believe that it's compliant with RFC
> 3748.  Multiple identities are possible, for example, in EAP network
> discovery.  It is also possible that the client will receive a proposal
> that it did not expect, for a variety of reasons.  Being unable to deal
> with this by refusing to send a NAK makes the protocol more brittle.
I tend to agree it is not advisable, but it does seem plausible that a 
company might deploy clients that have a particular sequence.  Anything 
else is not permitted by that company.  The Server(s) need only work for 
the company's client.  In this situation, if a client gets a Failure before 
authentication it ignores it.  If it later gets a Success it accepts it. 
If it does not get a success the client times out, or the connection is 
dropped by the NAS.

Since there is no backend to the peer there is no retransmission via RADIUS 
as in the authenticator case.

> > It seems that the Authenticator
> > can however initiate EAP authentication using an "empty EAP message" or
> > whatever.
>
> An "empty EAP message" is not legal in RFC 3748, so EAP authentication
> cannot be initiated this way.  Perhaps you're thinking about the
> "EAP-Start" in RFC 3579.