eap Mailing List: Re: Proposed resolution of issue 251

[Yoshihiro Ohba (yohba]

Hi John,

Please see my comments in line.

On Tue, Aug 10, 2004 at 11:37:45AM -0400, John Vollbrecht wrote:
> A couple questions --
> 
> --On Tuesday, August 10, 2004 12:48 PM +0300 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.
> >
> -- so not a success failure sent because of administrative changes
> 
> >- The 1X-REV behavior of sending success/failure on
> >  administrative change is not totally in line with this.
> >
> -- it does seem different.  so not specifically prohibited.
> 
> >- However, you could argue that those canned messages are not
> >  really part of an EAP conversation, but just use EAPOL frame
> >  type.
> >
> ok - this seems reasonable
> 
> >- 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.
> >
> this doesn't seem to deal with the case where a port is taken down and up, 
> sending a Success, and it may be in the middle of a conversation.

I don't understand the case where an authenticator sends a Success in
the middle of a conversation in this case.  When a port on an IEEE
802.1X authenticator is taken down and up, isn't the IEEE 802.1X
authenticator state machine initialized with restarting the EAP state
machine?  

Yoshihiro Ohba


> 
> >- EAP peer state machine discards canned success/failure
> >  (because "reqId == lastId" can't be true, since lastId
> >  is NONE). Thus, no changes required there.
> true - but this is not the administrative success/failure
> >
> >- 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.
> I think this is a good idea
> 
> >
> >- 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.
> >
> >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.
> >
> >Comments? What should we do about the last item?
> >(Personally, I'd prefer the first alternative, as we
> >could add that at author's 48 hours.)
> >
> I also prefer the first alternative, but I think input from the list would 
> be useful
> 
> - John
> 
> >Best regards,
> >Pasi
> >
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap