eap Mailing List: Proposed resolution of issue 251

[Pasi.Eronen (Pasi.Eronen]

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.

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

Best regards,
Pasi