Subject: [eap] Re: rfc2284bis issue

From: [email-masked] ([email-masked])
Date: Fri, 7 Mar 2003 11:07:52 +0200

(See comments inline)

> -----Original Message-----
> From: ext John Vollbrecht [mailto:[email-masked]]
> Sent: Wednesday, March 05, 2003 4:53 PM
> To: Eronen Pasi (NRC/Helsinki); [email-masked]
> Subject: Re: [eap] RE: rfc2284bis issue
  ...=20
> > 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.
> >
> 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=20
> continue the old.
>=20
> But I wonder if this is good practice.  Can a server=20
> negotiate down in the middle of a method?  this seems particularly=20
> bad if client has negotiated to a mutual authentication method=20
> which is satisfactory to it, then the server is trying to "negotiate=20
> down".

Is this "negotiating down" in the middle of a method any different
from "negotiating down" after the method has completed (and failed)?
After all, the server could always continue the current method to
its end (and send intentionally invalid messages).

Also, I think "negotiating down" is a policy issue.  An active
man-in-the-middle can always choose the negotiation result if multiple
methods are allowed, so the client's and server's policy has to
specify what methods are considered acceptable. EAP currently can't
provide "ordering guarantees" for allowed methods (meaning that if
methods A and B are allowed, and both parties would prefer A,=20
then A is actually used). Both parties have to take this into
account when selecting what methods are acceptable.

> > 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).
> >
> silent discard is not necessarily for DOS, but to make the=20
> state sequence "logical" - it refuses messages which logically=20
> should not be there.  What you are suggesting is that logically=20
> they could be there, so we should talk about it and see if we agree. =20
> If so, the state machine can be changed.

Very well put! Totally illegal messages (which couldn't have been sent
by a party following the specs) can (and maybe should) be silently=20
discarded, but these messages actually could be there.

BTW, this issue also applies to methods that "silently discard"
messages with invalid MACs, such as EAP-SIM and EAP-AKA. The reason
for wrong MAC could be that an attacker (trying to DoS) sent the
message, but it could be simply that the authentication didn't work
out. If the method silently discards the message, it's not possible to
try some other method in the same EAP conversation. So, these methods
can be really used only when the client and the server have only a
single common allowed method.

In many cases, having only a single allowed method in the policy is
probably the best solution anyway. Should this common case be treated
separately in the specs (it might simplify things)?

Best regards,
Pasi

---

From: [email-masked] (John Vollbrecht)
Date: Fri, 07 Mar 2003 08:27:23 -0500

--On Friday, March 7, 2003 11:07 AM +0200 [email-masked] wrote:

>   ...
> > 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".
>
I think it is not different, and I don't think it should normally be 
allowed after method completion.  I suppose there might be cases where 
trying something different after a method fails would be ok but I haven't 
seen it.

Perhaps I am missing your point.  Are you suggesting that the method might 
want to send a Failure before all the possible steps are complete in order 
to terminate in fewer steps?  I think this is a reasonable situation and 
could be handled by the state machine.

> methods A and B are allowed, and both parties would prefer A,
I agree with this as well.  I do think policy must be used to decide which 
methods to use, and each chosen method must succeed.  Is this what you mean?

> > 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.
> by a party following the specs) can (and maybe should) be silently
I think you are suggesting that one should be able to try a second method 
if the first one fails.  This is being highly discouraged because of the 
negotiating down problem.  Are there cases where this is expected to be the 
practice?

> separately in the specs (it might simplify things)?
I am not sure how this would be done.  Do you have a suggestion?

> Pasi
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap