eap Mailing List: Re: Proposed resolution of issue 251

[Yoshihiro Ohba (yohba]

I prefer the latter approach (i.e., the one that uses
AllowImmediateSuccess), too.

Thanks,

Yoshihiro Ohba


On Tue, Aug 10, 2004 at 12:56:21PM +0300, Jari Arkko wrote:
> Pasi.Eronen [at] nokia.com wrote:
> >Hi,
> >
> >To summarize the discussion about issue #251 at San Diego,
> >the conclusion seemed to be that
> >
> >- The "canned" success/failure prohibited by RFC3748 
> >  means success/failure sent immediately after a 
> >  connection is established.
> >
> >- The 1X-REV behavior of sending success/failure on 
> >  administrative change is not totally in line with this. 
> >
> >- However, you could argue that those canned messages are not 
> >  really part of an EAP conversation, but just use EAPOL frame 
> >  type.
> >
> >- Perhaps using something else would have been prettier, but     
> >  the current behavior doesn't seem to be that harmful either
> >  (e.g. if you disable the port, the client is not going to get
> >  access anyway), and it's too late to change it. 
> >
> >- EAP peer state machine discards canned success/failure 
> >  (because "reqId == lastId" can't be true, since lastId 
> >  is NONE). Thus, no changes required there.
> >
> >- EAP authenticator state machine does not explicitly mention
> >  that canned success/failure is prohibited. If desired, we 
> >  could add something like "Policy.getDecision MUST comply with 
> >  RFC3748 restrictions about canned Success and Failure messages."
> >  in author's 48 hours.
> >
> >- Sending success/failure after an identity request/response 
> >  pair is allowed by RFC3748 (and is explicitly mentioned
> >  in an example). The peer can, of course, have a policy 
> >  requiring authentication of the server.
> 
> Agreed. Thanks for the summary.
> 
> >I didn't notice this at San Diego, but additionally it 
> >seems that:
> >
> >- The current version of EAP peer state machine does not accept 
> >  a Success message after identity request (because decision is FAIL;
> >  this still worked in version -01 where decision could be also
> >  COND_SUCC). 
> >
> >- We could add text saying that "The peer state machine assumes 
> >  that the peer's policy requires that an authentication method 
> >  is always run. That is, an EAP Success message immediately
> >  following an EAP Identity or Notification exchange is ignored."
> >
> >- Or, we could add a constant AllowImmediateSuccess, and 
> >  change "decision = FAIL" to "if (AllowImmediateSuccess) 
> >  decision = COND_SUCC; else decision = FAIL;" in the 
> >  INITIALIZE state.
> 
> Oops. I would actually prefer the latter. (Not sure why
> you think only the former can be done in AUTH48.)
> 
> --Jari
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap