Subject: [eap] RE: rfc2284bis issue

From: [email-masked] ([email-masked])
Date: Wed, 5 Mar 2003 14:54:52 +0200

(BTW, there is already open issue (#87) related to this.)

Both the current and proposed text (sort of) assume that EAP
methods either have a single well-defined "final round", or they
have internal mechanisms for signalling end of method (e.g. TLS
alert in EAP-TLS). I don't think this applies to all methods; 
and the correct action to take also depends on the client's and
server's local policy (see below).

First, not all methods have a well-defined final round: consider
a method that first authenticates the client to the server, and
then the server to the client. Suppose that the client
authentication fails (but the client doesn't know this!), and
several more rounds are still left in the method.

What should the server do, if the method does not have an
internal "failure" message (which adds another round-trip
anyway), but the server's policy allows trying other methods?
Clearly sending a new Request for the next method type (or
Identity) seems reasonable in this case.

(Obviously, if only a single method is supported by both
the client and the server, this issue is quite trivial.)

When the client receives this Request (with new Type), it 
can silently discard it only if
1) the current method can only fail after the last Response, or
2) the current method has an internal "failure" message
   (which should have been used instead, so the request with
   new type shouldn't have been sent), or
3) the client's policy allows only a single EAP method, or
4) the client's policy says that if one method has been started 
   (Response sent) and fails (either after final round or in the middle),
   the whole EAP conversation fails.

In cases 3 and 4, the client can ignore the message hoping that
it was spoofed by the attacker (if it was not, then the whole
conversation fails anyway); however, see below for this DoS
point.

If none of these hold (method can fail in the middle but no
internal failure message; multiple methods allowed; if one method
fails, trying others is allowed), the client should either send a
Response (if it permits the new method), or Nak it (so the server
can propose something else), no matter if the previous method was
completed or not.

Methods in which the server can discover failure before the last
message, and which don't have any internal "failure end of
method" message include at least EAP-SIM, EAP-AKA and EAP-SRP.

However, even if the method has an internal failure mechanism,
silently discarding the message (cases 3-4 above) doesn't change
the DoS situation significantly because the internal failure
messages are not authenticated anyway in most cases
(e.g. MS-CHAPv2, EAP-TLS alerts).

If the EAP state machine includes a concept of "packet filter",
an EAP method could use it to specify rule "ignore all other
messages except my messages, until I change this otherwise"
(However, it seems that the state machine will end up specifying
only a subset of behavior allowed by 2284bis anyway; I think this
is sad, but getting the two to agree seems to require a lot of
restrictions to 2284bis which weren't in RFC2284, and many people 
seem to oppose adding such restrictions on behavior?).

Best regards,
Pasi

---Original message----
> Description of issue
> Submitter name: John Vollbrecht
> Submitter email address: [email-masked]
> Date first submitted: 3/4/03
> Document: Document Requiring change RFC2284bis
> Comment type: T
> Priority: S
> Section: 2.1
> Rationale/Explanation of issue:Peer Continuing after NAK to unexpected REQ
> Length description of problem
> As described in the current draft, the Authenticator can send a Request for 
> a new method type before completing the current method.  As described, the 
> peer would then NAK the Request with the data field containing the current 
> type.
> 
> while I thought this might work at one time, I am now convinced that this 
> would be a bad idea for the following reasons:
> 1. sending a new REQ in the middle of a method seems like it would be an 
> attempt to "negotiate" after seeing how the method is going - seems like 
> bad security practice.
> 2. if the peer and authenticator don't understand how to do a method in the 
> same way, then probably this should just fail.  It is badly implemented or 
> badly designed.
> 3. if the intent is to avoid a DOS attack the better way would be to have 
> the peer silently discard the unexpected Req rather than NAK it.  The 
> unexpected Request is treated as an invalid message, which it is.  this is 
> the way the current state machine treats it.
> 4. if the intent is to allow parallel methods to operate, this doesn't do 
> it.

> Requested change:
> Proposal
> 
> change:
>   If the
>   authenticator sends a message of a different Type prior to completion
>   of the final round of a given method the peer SHOULD silently discard
>   such a Request.  Otherwise it MAY send a Response with the same Type as
>   the Request.  Since an EAP packet with a different Type may be sent
>   by an attacker, an authenticator receiving a Nak including a
>   preference for the Type in progress SHOULD log the event, but
>   otherwise not take any action.
>
> to:
>
>   If the authenticator sends a message of a different Type prior to
>   completion of the final round of a given method the peer SHOULD silently
>   discard the Request.  Since an EAP packet with a different Type may be
>   sent by an attacker, this behaviour will allow the peer to continue if
>   the authenticator sends additional Request for the current type.  If it
>   does not receive a request for the current type it will time out and the
>   EAP conversation will fail.

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 05 Mar 2003 09:53:04 -0500

> Identity) seems reasonable in this case.
this is a good question.  it is not handled well in the current state 
machine.

> conversation fails anyway); however, see below for this DoS
I guess you could make 3 a subset of 4

> can propose something else), no matter if the previous method was
I think this can be made to work in the state machine- it requires changes 
but seems doable - as long as methods are single threaded, i.e. the 
authenticator doesn't send a request for a new method and continue the old.

But I wonder if this is good practice.  Can a server negotiate down in the 
middle of a method?  this seems particularly bad if client has negotiated 
to a mutual authentication method which is satisfactory to it, then the 
server is trying to "negotiate down".

> (e.g. MS-CHAPv2, EAP-TLS alerts).
silent discard is not necessarily for DOS, but to make the state sequence 
"logical" - it refuses messages which logically should not be there.  What 
you are suggesting is that logically they could be there, so we should talk 
about it and see if we agree.  If so, the state machine can be changed.

> seem to oppose adding such restrictions on behavior?).
I am not sure what subset of behaviour you are suggesting will be 
prohibited.   Some of what you are suggesting can be allowed even with the 
current state machine if the methods are written to allow it.

I do think that what you are suggesting is different than allowing 
"parallel" methods.  That still seems hard to me.

Hopefully we will continue this conversation.

John

> > Rationale/Explanation of issue:Peer Continuing after NAK to unexpected
> > REQ Length description of problem
> > As described in the current draft, the Authenticator can send a Request
> > for  a new method type before completing the current method.  As
> > described, the  peer would then NAK the Request with the data field
> > containing the current  type.
> >
> > while I thought this might work at one time, I am now convinced that
> > this  would be a bad idea for the following reasons:
> > 1. sending a new REQ in the middle of a method seems like it would be
> > an  attempt to "negotiate" after seeing how the method is going - seems
> > like  bad security practice.
> > 2. if the peer and authenticator don't understand how to do a method in
> > the  same way, then probably this should just fail.  It is badly
> > implemented or  badly designed.
> > 3. if the intent is to avoid a DOS attack the better way would be to
> > have  the peer silently discard the unexpected Req rather than NAK it.
> > The  unexpected Request is treated as an invalid message, which it is.
> > this is  the way the current state machine treats it.
> > 4. if the intent is to allow parallel methods to operate, this doesn't
> > do  it.
>
> > Requested change:
> > Proposal
> >
> > change:
> >   If the
> >   such a Request.  Otherwise it MAY send a Response with the same Type
> >   as the Request.  Since an EAP packet with a different Type may be sent
> >   completion of the final round of a given method the peer SHOULD
> >   silently discard the Request.  Since an EAP packet with a different
> >   Type may be sent by an attacker, this behaviour will allow the peer
> >   to continue if the authenticator sends additional Request for the
> >   current type.  If it does not receive a request for the current type
> >   it will time out and the EAP conversation will fail.
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap