eap Mailing List: Re: Re: Issue 251

[Jim Burns (jeb]

Hi Yoshihiro,
Sorry for the delay in response, please see below:

Yoshihiro Ohba wrote:

>On Wed, Jul 28, 2004 at 11:00:30AM -0400, Nick Petroni wrote:
>  
>
>>Yoshihiro,
>>
>>    
>>
>>>I think the text points to a case where the authenticator can sends
>>>Success message in response to Identity Response from the peer.  So
>>>it would not appear as a canned success.
>>>      
>>>
>>Even if this were not canned, it seems to still violate the rule that a
>>higher-layer authentication method must be run. Furthermore, Identity is
>>always optional so what works with Identity should work without (IMHO).
>>Perhaps I am missing some subtleties.
>>    
>>
>
>You are right.  I should have said "Success message in response to
>Identity Response in a tunneling method".
>  
>
I am probably thick (and I apologize for wasting folks time if this is
the case), but this does not appear to be the way the paragraph reads in
RFC 3748, Section 4.2, page 25, paragraph 2:

"If the peer attempts to authenticate to the authenticator and fails to
do so, the authenticator MUST send a Failure packet and MUST NOT grant
access by sending a Success packet. However, an authenticator MAY omit
having the peer authenticate to it in situations where limited access is
offered (e.g., guest access). In this case, the authenticator MUST send
a Success packet."

There is no discussion of tunneling methods here. There is some
discussion prior to this paragraph of the 'result indications' within an
EAP method, but this does not seem to apply to this paragraph. So, this
paragraph would lead me to believe that for guest access the
authenticator can send a Success packet without having the peer
authenticate to it. Since, as Nick points out, the identity request is
optional, this would mean that the authenticator sends an EAP Success
immediately for guest access.

This paragraph does seem to contradict the early paragraph about
'canned' successes. It would be impossible, from the peer, to
differentiate the behavior described above from a 'canned' success.

I believe that your intention was to disallow this behavior. Nick's
statement seems correct that "...it seems to still violate the rule that
a higher-layer authentication method must be run."

So, if our goal is to disallow canned successes/failures then I would
think removal of the sentence "However, an authenticator MAY omit having
the peer authenticate to it in situations where limited access is
offered (e.g., guest access). In this case, the authenticator MUST send
a Success packet." would be necessary as well.

If, on the other hand, our goal was to allow guest access, then I would
suggest that FORCE_AUTH and FORCE_UNAUTH states defined in IEEE
802.1XRev are one way to implement this 'limited access' to supplicants.

Thanks for your time folks,
Jim B.

>Yoshihiro Ohba
>
>
>  
>
>>Best,
>>nick
>>
>>    
>>
>>>Yoshihiro Ohba
>>>
>>>
>>>      
>>>
>>>>I am concerned about this contradiction though.  Did I miss
>>>>something in the doc?
>>>>Thanks,
>>>>Jim B.
>>>>
>>>>
>>>>
>>>>Nick Petroni wrote:
>>>>
>>>>        
>>>>
>>>>>Paul,
>>>>>
>>>>>Thanks for jumping in. The way I understand these messages is, I think, as
>>>>>you have described. Basically, if 802.1X is off, but the Peer comes in and
>>>>>sends an EAPoL Start, then the authenticator will immediately respond with
>>>>>an EAP Success or an EAP Fail without doing a run of the Identity method
>>>>>or an actual authentication method. Is this correct? If so, I *think* this
>>>>>would violate RFC3748 per Bernard's and Jari's comments. Any thoughts,
>>>>>corrections, or clarifications to my assessment?
>>>>>
>>>>>Thanks,
>>>>>nick
>>>>>
>>>>>Nick L. Petroni, Jr.
>>>>>Graduate Student, Computer Science
>>>>>Maryland Information Systems Security Lab
>>>>>University of Maryland
>>>>>http://www.cs.umd.edu/~npetroni
>>>>>
>>>>>On Tue, 27 Jul 2004, Congdon, Paul T (ProCurve) wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>The 'canned' messages are only send when the 802.1X port is
>>>>>>administratively forced authorized or unauthorized.   This is basically
>>>>>>when management turns off 802.1X and forces the port open or closed.
>>>>>>These message are also discussed in the text.
>>>>>>
>>>>>>Paul
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com]
>>>>>>>On Behalf Of Nick Petroni
>>>>>>>Sent: Tuesday, July 27, 2004 8:13 AM
>>>>>>>To: Bernard Aboba
>>>>>>>Cc: eap [at] frascone.com
>>>>>>>Subject: Re: [eap] Re: Issue 251
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>802.1X "canned" messages are encapsulated EAP packets.  So
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>an 802.1X
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>packet containing an EAP Success is expressly forbidden under RFC
>>>>>>>>3748, even though I think it is still mentioned in IEEE
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>802.1X-2004.
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>Similarly, our discussion of whether "canned" EAP Failure
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>is illegal
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>also applies to "canned" 802.1X packets.
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>Ok, this was the source of my confusion. I guess I assumed
>>>>>>>that since they were in another standard they were going to
>>>>>>>be allowed for backwards compatibility or some other legacy
>>>>>>>argument. They are, indeed, still in the latest version,
>>>>>>>which was another source of my confusion. They are in the
>>>>>>>802.1X SM diagrams, not just the text.
>>>>>>>
>>>>>>>Thanks,
>>>>>>>nick
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>_______________________________________________
>>>>>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
>>>>        
>>>>
>_______________________________________________
>eap mailing list
>eap [at] frascone.com
>http://mail.frascone.com/mailman/listinfo/eap
>
>  
>