Subject: [eap] Re: rfc2284bis issue

From: [email-masked] ([email-masked])
Date: Mon, 10 Mar 2003 11:55:12 +0200

Hi John,

Whether this can be implemented using the policy functions
depends on whether we want to silently discard some messages or
not. For example, Bernard's "strict interpretation" (and the
"quick hack" state machine in my last e-mail) says that the
client should

- silently discard Success and Failure if we're in the=20
  middle of a method and it shouldn't have happened
- silently discard Requests for other types

The current state machine in vollbrecht-eap-state-01 doesn't
allow this (Failure messages can't be ignored, and requests for
other methods are Nak'ed if we don't support that method).

So, the question is, do we want to silently discard some
messages or not? From the client's perspective,

1) Messages which could not have been sent by any sane=20
   server can always be discarded.
2) If the message could have been sent by the real server,=20
   we can (but not necessarily should; see below) silently=20
   discard a message only if the end result will be=20
   failure anyway (no matter if we discard it or process it).
3) If the message could have been sent by the real server,=20
   and processing it could lead to success, then we can't=20
   really discard it.

Strictly from a protocol perspective, I think we should discard
only messages in the first category (that shouldn't exist
anyway). If silently discarding messages in the second category
does actually prevent a DoS attack that would otherwise possible
(or makes it more difficult by non-insignificant amount), then
we maybe should discard them.

But does discarding those messages actually change the DoS
situation?  In PPP or plain 802.1X, it seems the answer is "no"
(a DoS is possible by sending non-EAP packets anyway). I'm not
sure about 802.11i; it might, with certain EAP methods? (does
anyone have more information about this?)

If the answer to this question is "yes", then a separate state
machine for clients and servers supporting only a single method
might make sense, because such a state machine can better
distinguish between messages in categories 2 (can be safely
ignored) and 3 (cannot be ignored). This would be something like
the "strict interpretation" proposed by Bernard, but it would
not be specific to an EAP method.

If the answer to the DoS question is "no, EAP can't do anything
that significantly changes this; or any feasible EAP method
can't distinguish 100% reliably between categories 2 and 3
anyway", then the situation is simplified considerably. We could
forget the "strict interpretation" and the state machine in your
I-D is basically OK..

BTW, there was a problem in the "quick hack" state machine in my
last e-mail: some methods have points where they can either
continue or succeed (e.g. generic token card), and the client
doesn't know which. This required a small change (an additional
method indication and a new state). I've also drawn a picture
of it: http://www.cs.hut.fi/~peronen/simple_eap_statemachine.gif.

Best regards,
Pasi

> -----Original Message-----
> From: ext John Vollbrecht [mailto:[email-masked]]
> Sent: Monday, March 10, 2003 3:52 AM
> To: Eronen Pasi (NRC/Helsinki); [email-masked]
> Subject: Re: [eap] RE: rfc2284bis issue
>=20
> Pasi -
>=20
> I think the sequence you describe is close to what the state machine=20
> document is proposing.  I would be interested in trying to=20
> demonstrate whether the scenario you suggest is possible with our=20
> state macchine.  I think what is required is to define the Policy=20
> functions (Policy.isSatisfied, Policy.allow, Policy.getNextMethod)
> and how they are initiated.
>=20
> let me know if you would like to pursue this
>=20
> John

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 11 Mar 2003 13:00:59 -0500

Hello Pasi -

Thanks for the response and the diagram.  I think we are actually quite 
close and perhaps we should try to come up with a common state machine. 
There are differences to be talked through however.  If you are interested 
we might want to try to have a conversation this week before ietf, or 
certainly at ietf.

Our diagrams are in somewhat different styles.  Ours is in 802 style, in 
which the actions are all in States, yours is more what i would expect, 
with actions associated with events on transitions between states.  While I 
like yours better, I think the group wants to use the 8u2 style.  It 
certainly helps with coordination with 802.1x an 802.11i state machines.

So much for the formatting - more comments inline and at the end.
-----------------------

--On Monday, March 10, 2003 11:55 AM +0200 [email-masked] wrote:

> - silently discard Success and Failure if we're in the
Failure is ignored if methodState is CON-SUCC.
You are righat that the STRICT feature is not supported.   My understanding 
of The proposal at the last conf call was to add an additional state or 
variable indicating strict-interpretation.  Also at the DIALOG state add 
(if STRICT && currenttype!=prevtype) and transition to an new state 
NAK-CURRENT to send a NAK with current-type.  Also change the failure 
condition to (if rxFailure && !(methodState==CON_SUCC !! 
methodState==STRICT).  We will make a change and resend the diagram.

> 1) Messages which could not have been sent by any sane
> 2) If the message could have been sent by the real server,
>    we can (but not necessarily should; see below) silently
>    discard a message only if the end result will be
> 3) If the message could have been sent by the real server,
>    and processing it could lead to success, then we can't
>    really discard it.
>

I think these are good categories, and I agree with your conclusions.

> anyone have more information about this?)
I am not certain, but it seems the number of DOS attacks possible is large 
and this will not get rid of all of them.  However one of the simplest is 
sending an EAP Failure.

> of it: http://www.cs.hut.fi/~peronen/simple_eap_statemachine.gif.
 Yes - there may well be a need for the extra state.  I think the same 
effect can be had in our state machine by assuming the method has two 
parts, and allowing the same method to continue using the policy.Allow 
function to describe what is allowed.

Some overall comments

1.  the diagram you present seems to deal only with strict interpretation. 
Is that your intent or am i missing something?
2. I am not clear how Requests and other messages that don't match 
policy.type are handled - are they silently discarded?  I thought Requests 
would be NAK'd?
3. Are you using link-enabled and link-disabled as two separate signals.  I 
assume these are meant to be "alternate indications"?
4. I think your "PROBABLE SUCCESS" and our "IDLE" states are pretty close, 
except that we allow another method to start if allowed by policy rather 
than only allowing success or failure.

 -- thanks again for the input.  working this out would be much easier face 
to face, but this is good conversation.

John

> > I think the sequence you describe is close to what the state machine
> > document is proposing.  I would be interested in trying to
> > demonstrate whether the scenario you suggest is possible with our
> > state macchine.  I think what is required is to define the Policy
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap