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

From: Jim Burns <[email-masked]>
Date: Thu, 22 Jan 2004 15:58:55 -0500

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

---

From: John Vollbrecht <[email-masked]>
Date: Fri, 23 Jan 2004 15:21:23 -0500

--On Thursday, January 22, 2004 12:30 PM -0800 Bernard Aboba 
<[email-masked]> wrote:

> 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.
>
> Is this because there is no support for tie-breaking?  If so, I'd change
> this to:
>
I think this is not *just* for tie breaking.  In some cases it may be for 
tie breaking, but it is possible that each bridge may have its own 
requirement for authentication/authorization that is only implemented in 
one direction (probably the authenticator), but be willing to respond as 
supplicant to the other.

---

From: Jim Burns <[email-masked]>
Date: Fri, 23 Jan 2004 15:34:05 -0500

Hi John,
    Correct.  The bridge-to-bridge case is more than tie-breaking and I 
believe that your description of the reason that bridge-to-bridge may 
use the two one-way authentication transports is succinct.  I will 
borrow it to add to the 6.7 text.
Thanks,
Jim B.

John Vollbrecht wrote:

> I think this is not *just* for tie breaking.  In some cases it may be 
> for tie breaking, but it is possible that each bridge may have its own 
> requirement for authentication/authorization that is only implemented 
> in one direction (probably the authenticator), but be willing to 
> respond as supplicant to the other.
>

---

From: Jim Burns <[email-masked]>
Date: Fri, 23 Jan 2004 19:27:44 -0500

Hi Folks,
    Rev 4 of section 6.7 is not going to make it out today.
    It will be out on Monday.
Sorry for the delay,
Jim B.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jim Burns <[email-masked]>
Date: Sun, 25 Jan 2004 16:01:39 -0500

Hello,
I have taken the input from last week and modified the proposal for 
section 6.7 of IEEE 802.1XRev.
This is version 4 of the proposal.
Jim B.
----------------------------------------
Version 1:
-original release

Version 2:
-rewrite of text for readability by B. Aboba
-remove discussion of specific applications
-remove suggestions that specific applications define .1X
roles and EAP methods.

Version 3:
-asymmetric connections are created when a device change 2nd
to last paragraph to indicate that with both roles
encounters a device with just an authenticator.
-add a short paragraph suggesting that specific applications
define .1X roles.

Version 4:
-Ensure the text indicates that two controlled ports
enables enforcement of mutual authorization. (paragraph 3 &
5)
-Indicate that it is creation of group keys not unicast
keys in 802.11 adhoc that requires bi-directional
transport. (#2 in list of reasons to utilize bi-directional
transport)
-Better specify why two bridges utilize bi-directional
transport. (#3 in list of reasons to utilize bi-directional
transport)
-Make clear that the addition of the controlled port for
the supplicant is for clarity on what to do with the
authorization variable on the supplicant. (paragraph 5)
-Mention that 802.1X does not support tie-breaking.
(paragraph 6)
-In general ensure careful use of terms and language.

-------------------------------------------------------------
6.7 Coupling two 802.1X authentications

This section discusses the ability of 802.1X to run two
simultaneous transports in opposite directions, how
implementation asymmetries affect authentication results
and how simultaneous bi-directional transport may be
utilized.

In 802.1X there is a requestor role (authenticator) and a
responder role (supplicant). The authenticator transmits
frames to the supplicant and the supplicant responds to
those frames with frames of its own. 802.1X, like the
authentication protocol carried within it (EAP), is a
request/response protocol, and the state machines reflect
this. Such a transport is sometimes called 'one-way'
meaning the protocol exchanges always originate from one
side (the requestor).

However, it is not the 802.1X transport that controls
whether the authentication is mutual or one-way. Rather,
it is the chosen EAP method and controlled ports able to
mutually enforce the authorization of the authentication.

Despite the asymmetry of 802.1X and EAP transports, if a
mutually authenticating EAP method (such as EAP-TLS) is
carried within 802.1X frames, then the supplicant and
authenticator can mutually authenticate. However, if an
EAP method is chosen which only authenticates the
supplicant to the authenticator (e.g. EAP MD5-CHALLENGE),
then the authentication will be one-way.

In an earlier version of 802.1X (802.1X-2001), only the
authenticator was specified to affect the controlled port.
This one-sided specification prevented mutual
authentications from being mutually enforced, essentially
preventing mutual authentication. However, this was due to
the lack of a specification of the controlled port on the
supplicant, not due to the one-way nature of the 802.1X
transport protocol. The current version of 802.1X remedies
this by specifying how both authenticator and supplicant
roles affect the controlled port.

In 802.1X, each role has its own state machine and it is
possible that a single device can implement both the
supplicant and authenticator roles (state machines). If a
device implementing both roles encounters another device
implementing both roles, then two separate (and
simultaneous) 802.1X transports will take place in opposite
directions. This is sometimes referred to as a bi-
directional authentication transport or two coupled one-way
authentication exchanges. 802.1X does not support "tie
breaking" wherein two hosts initiating authentication with
each other will only go forward with a single
authentication.

Two coupled one-way authentication exchanges are not
equivalent in security to a single exchange of a mutually
authenticating EAP method (such as EAP-TLS). Since the two
coupled one-way authentication exchanges are not
cryptographically bound together, there is no way to
ascertain that the party involved in the first one-way
exchange is the same party that is involved in the
alternate one-way exchange.

Even though a single 802.1X exchange may provide mutual
authentication, there may be other reasons to run two
802.1X exchanges in opposite directions. RFC 2284bis,
Section 2.4 discusses some of these cases, which include:

1) When the devices require the creation of separate
keying material as in group keys for 802.11 adhoc networks.

2) When different credentials are used for different roles
(one credential for the supplicant role and one for the
authenticator).

3) When two bridge devices are connected each bridge may
have its own requirement for authentication/authorization
that is only enforced by the authenticator ("Supplicant Access
Control With Authenticator" variable set to inactive), but will
implement the supplicant role to respond to the other
bridge. This configuration allows both bridges to utilize
the same authentication server even though one bridge is
separated from the authentication server by the other
bridge's controlled port. The first bridge with access to
the authentication server will complete authentication and
authorize its controlled port, this will allow the second
bridge to access the authentication server so that it may
authenticate and authorize the first bridge.

When a device that implements both 802.1X roles encounters
a device which implements only a single authenticator role,
this can result in asymmetric data flow (data traffic can
only flow in one direction). This occurs because one
device opens its controlled port while the other device
does not. A complete table of encounters and results
(assuming authentication successes) appears in Table xxxx.

It is suggested that applications utilizing 802.1X should
specify which .1X roles must be implemented to avoid
encounters that will result in failed network connections.

Table xxxx: Result of encounters between .1X transport
roles assuming key-generating EAP methods are run and
result in success.

Remote\Local--> | Supplicant | Authenticator | Both
| | | |
V | | |
----------------------------------------------------------------------
Supplicant |Fails gracefully | Works | Works
|No link will be | Authenticated | Authenticated
|formed if media | link | link
|is considered | Authentication | Authentication
|unsafe without | policy is set by | policy set by
|encryption | choice of EAP | choice of EAP
|(802.11). | method. | method
| | | Remote
|Unauthenticated | | supplicant and
|link will be | | local
|formed if media | | authenticator
|is considered | | are satisfied.
|safe by default | | Local
|(802.3) | | supplicant will
| | | receive no
| | | response and
| | | assume no
| | | authenticator.
| | | Successful
| | | authentication
| | | to the local
| | | authenticator
| | | will have made
| | | the port
| | | secure.
-----------------------------------------------------------------------
Authenticator |Works - |Fails gracefully |Fails –
|Authenticated |No link will be |Asymmetric link
|link – |formed. Each |Remote
|Authentication |authenticator |controlled port
|policy set by |will send initial |is operational,
|choice of EAP |EAP requests but |but local
|method. |no response will |controlled port
| |arrive. |remains non-
| | |operational.
| | |Remote
| | |authenticator
| | |and local
| | |supplicant are
| | |satisfied,
| | |local
| | |authenticator
| | |remains
| | |unsatisfied.
-----------------------------------------------------------------------
Both |Works |Fails |Works
|Authenticated |Asymmetric link | Authenticated
|link |Local controlled | link
|Authentication |port is | Authentication
|policy set by |operational, but | policy set by
|choice of EAP |remote controlled | choice of two
|method. |port remains non- | uncoupled EAP
|Local supplicant |operational. | methods. Two
|and remote |Local | keys will be
|authenticator |authenticator and | formed and some
|are satisfied. |remote supplicant | mechanism must
|Remote |are satisfied, | exist so that
|supplicant will |remote | local and
|receive no |authenticator | remote choose
|response and |remains | the same key.
|assume no |unsatisfied. |
|authenticator. | |
|Successful | |
|authentication | |
|to the remote | |
|authenticator | |
|will have made | |
|the port secure. | |
-----------------------------------------------------------------------

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 26 Jan 2004 10:53:20 -0500

This is good.  I do have a question about the dual bridge case, below.

-- John

--On Sunday, January 25, 2004 4:01 PM -0500 Jim Burns <[email-masked]> 
wrote:

> section 6.7 of IEEE 802.1XRev. This is version 4 of the proposal.
> Jim B.

I don't understand how completing one authentication allows the other 
authentication to complete.  My question -  If each authentication enables 
a variable and both must be on for traffic, then both must complete for 
traffic to flow.  Or is your thought that the supplicant side of each is 
not required (configured on) so only the authenticator *needs* to 
authenticate?  If so the control port can be on, but I still don't see how 
the other side's authenticator can do RADIUS (or other) to the 
authentication server since it does not have a port enabled on its side.

I was thinking that that in a two bridge situation both bridges would be 
set with variables for both authenticator and supplicant open.  The 
autenticator would start on its side.  The supplicant would time out if the 
other side did not start.  If both sides did start, both authentications 
would be required.

I don't see how this can allow a bridge coming up to get to a 
Authentication Server via RADIUS before the connection is made.  In my 
opinion it will require some sort of pass thru capability in EAPOL  (or 
equivalent) that allows passing of RADIUS accross the link, and then to the 
AS.  Somehow there would need to be a shared secret for message integrity 
between them.  Probably this is doable, but not easily, and not for this 
document.

So my thought is that the ability of a bridge to connect to another bridge, 
and go to an AS behind the bridge to which it is connecting is something 
that will happen in 802.1af, not here.  [Note however that some protection 
could be built in by using a special EAP method that passed policy info to 
the connecting bridge after doing authentication.  This would require 
enhancing existing methods to include sending of the info from the 
authenticator and requiring it (failing if not present) on the supplicant 
(the attaching bridge).]
> this can result in asymmetric data flow (data traffic can
I think no data flows into the unauthenticated port- a I right?  If so then 
I think this misleading.  Perhaps better to say one side can turn the port 
on but the other will not send or receive.  This does point out the timeout 
problem.

> | No link will be | Authenticated | Authenticated
> | formed if media | link | link
> | is considered | Authentication | Authentication
> | unsafe without | policy is set by | policy set by
> | encryption | choice of EAP | choice of EAP
> | (802.11). | method. | method
> | | | Remote
> | Unauthenticated | | supplicant and
> | link will be | | local
> | formed if media | | authenticator
> | is considered | | are satisfied.
> | safe by default | | Local
> | (802.3) | | supplicant will
> | | | receive no
> | | | response and
> | | | assume no
> | | | authenticator.
> | | | Successful
> | | | authentication
> | | | to the local
> | | | authenticator
> | | | will have made
> | | | the port
> | | | secure.
> Authenticator |Works - |Fails gracefully |Fails ?
> | Authenticated |No link will be |Asymmetric link
> | link ? |formed. Each |Remote
> | Authentication |authenticator |controlled port
> | policy set by |will send initial |is operational,
> | choice of EAP |EAP requests but |but local
> | method. |no response will |controlled port
> | | arrive. |remains non-
> | | | operational.
> | | | Remote
> | | | authenticator
> | | | and local
> | | | supplicant are
> | | | satisfied,
> | | | local
> | | | authenticator
> | | | remains
> | | | unsatisfied.
> | Authenticated |Asymmetric link | Authenticated
> | link |Local controlled | link
> | Authentication |port is | Authentication
> | policy set by |operational, but | policy set by
> | choice of EAP |remote controlled | choice of two
> | method. |port remains non- | uncoupled EAP
> | Local supplicant |operational. | methods. Two
> | and remote |Local | keys will be
> | authenticator |authenticator and | formed and some
> | are satisfied. |remote supplicant | mechanism must
> | Remote |are satisfied, | exist so that
> | supplicant will |remote | local and
> | receive no |authenticator | remote choose
> | response and |remains | the same key.
> | assume no |unsatisfied. |
> | authenticator. | |
> | Successful | |
> | authentication | |
> | to the remote | |
> | authenticator | |
> | will have made | |
> | the port secure. | |

---

From: Jim Burns <[email-masked]>
Date: Mon, 26 Jan 2004 12:14:55 -0500

John,
    The key to answering your question is understanding the 802.1X 
management variable "Supplicant Access Control With Authenticator" that 
is described in section 6.4  of 802.1XRev draft 8 (around p17 or so).
     In short, when this management variable is set to the inactive 
state then the controlled port will only be authorized by the 
authenticator, the supplicant plays no role in authorizing the 
controlled port.  Setting this variable to inactive causes the 
controlled port to work the way it did in 802.1X-2001.  This is required 
for backwards compatibility of 802.1XRev draft 8 with 802.1X-2001 on 
bridges.
     So, imagin you have two bridges: A and B (both with the "Supplicant 
Access Control With Authenticator" set to inactive) and addition you 
have a single authentication server (let us call it S) that A has access 
to (no intervening controlled port), but which B must go through A to 
reach.
    Graphically:
     -------------
    B<====>A<---->S
    Authentication/authorization would proceed as follows:
    ---------------------------------------------------------
    A's authenticator will begin an authentication with B's supplicant
    B's authenticator will begin an authentication with A's supplicant
    B's authenticator will send access-requests to S, but they will not 
reach S because the controlled port on A has not been authorized.  So 
these access-requests will timeout and B will do resends.
    A's authenticator will send access-requests to S and receive 
responses and eventually authenticate B's supplicant.
    A will authorize its controlled port.
    B's authenticator's access-requests will now reach S (through the 
authorized controlled port on A) and recieve responses and eventually 
authenticate A's supplicant.
    B will authorize its controlled port.

The key to understanding the bridge to bridge case is understanding the 
"Supplicant Access Control With Authenticator" variable that is 
described in section 6.4.  I can add a reference to 6.4 in my 
description of the bridge to bridge case in 6.7.
Hope this helps,
Jim B.

John Vollbrecht wrote:

> --On Sunday, January 25, 2004 4:01 PM -0500 Jim Burns 
> <[email-masked]> wrote:
>
>> Hello,
> authentication to complete.  My question -  If each authentication 
> enables a variable and both must be on for traffic, then both must 
> complete for traffic to flow.  Or is your thought that the supplicant 
> side of each is not required (configured on) so only the authenticator 
> *needs* to authenticate?  If so the control port can be on, but I 
> still don't see how the other side's authenticator can do RADIUS (or 
> other) to the authentication server since it does not have a port 
> enabled on its side.
>
> I was thinking that that in a two bridge situation both bridges would 
> be set with variables for both authenticator and supplicant open.  The 
> autenticator would start on its side.  The supplicant would time out 
> if the other side did not start.  If both sides did start, both 
> authentications would be required.
>
> opinion it will require some sort of pass thru capability in EAPOL  
> (or equivalent) that allows passing of RADIUS accross the link, and 
> then to the AS.  Somehow there would need to be a shared secret for 
> message integrity between them.  Probably this is doable, but not 
> easily, and not for this document.
>
> So my thought is that the ability of a bridge to connect to another 
> bridge, and go to an AS behind the bridge to which it is connecting is 
> something that will happen in 802.1af, not here.  [Note however that 
> some protection could be built in by using a special EAP method that 
> passed policy info to the connecting bridge after doing 
> authentication.  This would require enhancing existing methods to 
> include sending of the info from the authenticator and requiring it 
> (failing if not present) on the supplicant (the attaching bridge).]
>
>>
> I think no data flows into the unauthenticated port- a I right?  If so 
> then I think this misleading.  Perhaps better to say one side can turn 
> the port on but the other will not send or receive.  This does point 
> out the timeout problem.
>

---

From: Jim Burns <[email-masked]>
Date: Mon, 26 Jan 2004 12:21:10 -0500

Hi John,
    Just noticed your comment on asymmetric data flow definition below.  
I agree and will clarify this for V5 of this draft.
Jim B.

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 26 Jan 2004 21:18:07 -0500

--On Monday, January 26, 2004 12:14 PM -0500 Jim Burns <[email-masked]> 
wrote:

> In short, when this management variable is set to the inactive state then
> the controlled port will only be authorized by the authenticator, the
> supplicant plays no role in authorizing the controlled port.  Setting
> this variable to inactive causes the controlled port to work the way it
> did in 802.1X-2001.  This is required for backwards compatibility of
> 802.1XRev draft 8 with 802.1X-2001 on bridges.      So, imagin you have
> two bridges: A and B (both with the "Supplicant Access Control With
> Authenticator" set to inactive) and addition you have a single
> authentication server (let us call it S) that A has access to (no
> intervening controlled port), but which B must go through A to reach.
> Graphically:
>      -------------
>     B<====>A<---->S
> these access-requests will timeout and B will do resends.     A's
> authenticator will send access-requests to S and receive responses and
[A talks RADIUS to S right?]

> eventually authenticate B's supplicant.     A will authorize its
> controlled port.
> authenticate A's supplicant.     B will authorize its controlled port.
>
I don't have my copy of 6.4 here - it is at my desk at Merit.  But I don't 
understand how messages get from B's authenticator to S.  My understanding 
is that these are sent via RADIUS over IP.  Without B's port being turned 
on, I assume no IP traffic can be sent. So perhaps I am wrong, but how does 
B send traffic to S in this scenario?

> "Supplicant Access Control With Authenticator" variable that is described
> in section 6.4.  I can add a reference to 6.4 in my description of the
> bridge to bridge case in 6.7. Hope this helps,
> Jim B.
>
> John Vollbrecht wrote:
>

---

From: Jim Burns <[email-masked]>
Date: Tue, 27 Jan 2004 14:28:33 -0500

Hi John,
You are correct. B's controlled port will not allow RADIUS traffic on 
the port. I was wrong, and agree with that this is not defined in the 
standard. Hmmm. So, it is NOT possible for two bridges to utilize a 
single authentication server where one bridge accesses the 
authentication server through the other bridge because RADIUS will be 
blocked by B's controlled port.
It is conceivable that an implementation could run a RADIUS stack atop 
the uncontrolled port, but each new protocol atop the uncontrolled port 
makes the possibility of compromise that much greater. Or, as you 
indicate, there could be some sort of RADIUS transport. But, none of 
these are specified in the standards. So, from a standards perspective, 
it is not possible.
So, the text discussing the bridge to bridge case in relation to the 
bidirectional transport should instead just read:

"When two bridge devices are connected each bridge may have its own 
requirement for authentication/authorization that is only enforced by 
the authenticator (“/Supplicant Access Control With Authenticator/” 
variable set to inactive), but will implement the supplicant role to 
respond to the other bridge"

This text in addition to the sentence I added earlier about the lack of 
'tie-breaking' should sufficiently cover this case.
I will update V5 of the doc to include this.
Thanks for the catch John,
Jim B.

John Vollbrecht wrote:

>
>
> --On Monday, January 26, 2004 12:14 PM -0500 Jim Burns 
> I don't have my copy of 6.4 here - it is at my desk at Merit. But I 
> don't understand how messages get from B's authenticator to S. My 
> understanding is that these are sent via RADIUS over IP. Without B's 
> port being turned on, I assume no IP traffic can be sent. So perhaps I 
> am wrong, but how does B send traffic to S in this scenario?
>
>
>> described

---

From: John Vollbrecht <[email-masked]>
Date: Tue, 27 Jan 2004 19:25:19 -0500

sounds good to me -- John

--On Tuesday, January 27, 2004 2:28 PM -0500 Jim Burns <[email-masked]> 
wrote:

> Hi John,
> You are correct. B's controlled port will not allow RADIUS traffic on the
> port. I was wrong, and agree with that this is not defined in the
> single authentication server where one bridge accesses the authentication
> server through the other bridge because RADIUS will be blocked by B's
> controlled port. It is conceivable that an implementation could run a
> RADIUS stack atop the uncontrolled port, but each new protocol atop the
> uncontrolled port makes the possibility of compromise that much greater.
> Or, as you indicate, there could be some sort of RADIUS transport. But,
> none of these are specified in the standards. So, from a standards
> perspective, it is not possible. So, the text discussing the bridge to
> bridge case in relation to the bidirectional transport should instead
> just read:
>
> requirement for authentication/authorization that is only enforced by the
> authenticator (?/Supplicant Access Control With Authenticator/? variable
> set to inactive), but will implement the supplicant role to respond to
> the other bridge"
>
> 'tie-breaking' should sufficiently cover this case. I will update V5 of
> the doc to include this.
> >> > side of each is not required (configured on) so only the
> >> > authenticator *needs* to authenticate? If so the control port can be
> >> > on, but I still don't see how the other side's authenticator can do
> >> > RADIUS (or other) to the authentication server since it does not
> >> > have a port enabled on its side.
> >> >
> >> > bridge, and go to an AS behind the bridge to which it is connecting
> >> > is something that will happen in 802.1af, not here. [Note however
> >> > that some protection could be built in by using a special EAP method
> >> > that passed policy info to the connecting bridge after doing