Subject: [eap] RE: rfc2284bis issue

From: [email-masked] ([email-masked])
Date: Fri, 7 Mar 2003 16:46:36 +0200

> -----Original Message-----
> From: ext John Vollbrecht [mailto:[email-masked]]
> Sent: Friday, March 07, 2003 3:27 PM
> To: Eronen Pasi (NRC/Helsinki); [email-masked]
> Subject: Re: [eap] Re: rfc2284bis issue
 ...
> > 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)?
>=20
> I am not sure how this would be done.  Do you have a suggestion?

We could specify a "recommended subset behavior" (something like=20
the "strict interpretation" proposed by Bernard) that is used when=20
the client or server only allows a single EAP method (and recommend=20
that this should be used, since the method negotiation in EAP is not
secure).

This would create a very simple state machine (MUCH simpler than
the current one, which has to work with multiple methods).=20
The client state machine could look something like this (ignoring=20
retransmissions):

Initialize:
- request(type=3Didentity): send answer, stay here
- request(type=3Dsupported type): go to Method state and use rule there
- request(type=3Dother type): send Nak, stay here
- timeout: go to Failure
- silently discard everything else

Method:
- request(type=3Dsupported type): pass it to method. The method=20
  returns exactly one of the following indications:
  - continue(answer): send answer, stay here
    [this is the normal case]
  - probable_success(answer): send answer, go to ProbableSuccess
    [this was the last message, and we're happy, but don't know yet
    if the server will be happy with our answer]
  - protected_success(answer): send answer, go to Success
    [the method knows that the server will be happy, too]
  - failure(optional_answer): send optional_answer, go to Failure
    [this will be used when the method sees no point in continuing]
  - discard: silently discard
    [the message wasn't OK, but the method wants to continue anyway,=20
    in case the message was spoofed by an attacker]
  (note: probably a single method won't actually use all five)
- timeout: go to Failure
- silently discard everything else
  - discarding Failures works because even if it wasn't spoofed,
    we will timeout and fail anyway
  - discarding Successes works if there aren't any methods which
    have several possible success points
  - discarding other method types works, because we won't=20
    support them anyway

ProbableSuccess:
- success: go to Success
- failure: go to Failure
- "link enabled" indication outside EAP: go to Success?
- timeout: go to Success?
- silently discard everything else

Failure: end state
Success: end state

Do you think something like this would be worthwhile? If
supporting exactly one EAP method is the most common case, it
certainly would simplify life for implementors, instead of
trying to navigate through all the MAYs and SHOULDs in the spec
(the client state machine above does not have any alternatives
to choose from, other than the indication received from EAP
method).

If this looks good, I could try to write something more
coherent about this (and also try to figure out the server
state machine)...

Best regards,
Pasi

---

From: [email-masked] (John Vollbrecht)
Date: Sun, 09 Mar 2003 20:51:52 -0500

Pasi -

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 machine.  I 
think what is required is to define the Policy functions 
(Policy.isSatisfied, Policy.allow, Policy.getNextMethod) and how they are 
initiated.

let me know if you would like to pursue this

John

--On Friday, March 7, 2003 4:46 PM +0200 [email-masked] wrote:

> > > probably the best solution anyway. Should this common case be treated
> We could specify a "recommended subset behavior" (something like
> the "strict interpretation" proposed by Bernard) that is used when
> the client or server only allows a single EAP method (and recommend
> the current one, which has to work with multiple methods).
> The client state machine could look something like this (ignoring
> retransmissions):
>
> Initialize:
> - request(type=identity): send answer, stay here
> - request(type=supported type): go to Method state and use rule there
> - request(type=other type): send Nak, stay here
> - timeout: go to Failure
> - request(type=supported type): pass it to method. The method
>     [the message wasn't OK, but the method wants to continue anyway,
>   - discarding other method types works, because we won't
>     support them anyway
>
> ProbableSuccess:
> - success: go to Success
> - failure: go to Failure
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap