eap Mailing List: Re: [802.1] Re: Strawman for a modified section 6.7 (V3) for IEEE 802.1XRev

[Jim Burns (jeb]

Hello Bernard,
  Thanks for the catch on group vs unicast keys.
  Actually, the bridge-to-bridge case is a bit more complex.  It is 
partially tie-breaking.  In addition there is an issue of access to a 
single authentication server.  The most common bridge-to-bridge 
configuration is that there is a single authentication server that both 
bridges are utilizing.  One of the bridges has immediate access to the 
authentication server (no intervening .1X controlled port), the second 
bridge accesses the authentication server through the first bridge 
(there is an intervening .1X controlled port).  So, in a bridge to 
bridge configuration, a special .1X variable (Supplicant Access Control 
With Authenticator ) is set to 'inactive' which means that the 
controlled port is soley under the control of the authenticator role 
(the supplicant has no 'say' in the status of the controlled port).  
Then, both bridges immediately begin to attempt an authentication with 
each other.
  B1 = Bridge 1 that has immediate access to authentication server
  B2 = Bridge 2 that accesses the authentication server through B1 (has 
an intervening controlled port)
--B2's authenticator will be (temporarily) be unable to communicate with 
its authentication server so the authentication from B1's supplicant to 
B2's authenticator will 'pause' waiting for a reply from the requests 
sent to the authentication server.
--B1's authenticator will authenticate B2's supplicant and open the 
controlled port (due to the setting of the 1X variable)
--B2's authenticator will now be able to communicate to the 
authentication server through B1 and authenticate B1's supplicant and 
open its controlled port.
  It is difficult to describe this succinctly, so I have dropped a 
great deal of detail in section 6.7 and just indicated that the bridge 
to bridge case requires the coupled one-way authentications.  Still, the 
way it is now it is unclear why the bridge case is called out as a 
required case.
  I expect to produce a V4 of the document on Friday for continued 
review and will incorporate all comments.
Thanks,
Jim B.

Bernard Aboba wrote:

> Some refinements:
>
> > If a
> > device implementing both roles encounters another
> > device implementing both roles, then two separate (and
> > simultaneous) 802.1X exchanges will take place in
> > opposite directions.
>
>
> Is this "will take place in opposite directions."  or "may take place 
> in opposite directions, depending on the circumstances."  Later on, 
> those circumstances are described.
>
> >  1)  When the devices require the creation of
> >  separate keying material as in unicast keys for 802.11
> >  adhoc networks.
>
>
> Actually, it's the "group keys" not "unicast keys" that are 
> uni-directional in 802.11.
>
> >  3) When two bridge devices implementing both roles
> >  are connected together and they wish to authenticate each
> >  other.
>
>
> Is this because there is no support for tie-breaking?  If so, I'd 
> change this to:
>
> "3)  When two bridge devices implementing both roles are
> connected together and they wish to authenticate each other.
> 802.1X does not support "tie breaking" wherein two
> hosts initiating authentication with each other will only go
> forward with a single authentication."
>
> _________________________________________________________________
> Check out the coupons and bargains on MSN Offers! 
> http://shopping.msn.com/softcontent/softcontent.aspx?scmId=1418