eap Mailing List: Re: Proposed resolution of issue 251

[Jim Burns (jeb]

Hi Yoshiro,

You asked:
   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?


The answer is:
Yes. The 802.1X authenticator state machine shall restart when the port
cycles (802.1X portEnabled variable will toggle) and it will set
eapRestart to cause EAP state machine to restart as well. In fact, the
802.1X state machine will wait for the EAP state machine to reset
eapRestart before continuing.

Jim B.


Yoshihiro Ohba wrote:

>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
>>    
>>
>_______________________________________________
>eap mailing list
>eap [at] frascone.com
>http://mail.frascone.com/mailman/listinfo/eap
>
>  
>