eap Mailing List: Re: Proposed resolution of issue 251

[John Vollbrecht (jrv]

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.

> - 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