eap Mailing List: Re: Proposed resolution of issue 251

[Jari Arkko (jari.arkko]

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