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

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

I like most of the changes.  They clean up the language a lot.  I do have a 
few comments below. -

--On Tuesday, January 27, 2004 2:44 PM -0800 Bernard Aboba 
<[email-masked]> wrote:

> Thanks for taking this on.  The text keeps getting and better each time.
> Just a few comments ;)
>
> > 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.
>
> I'd rephrase to say:
>
> "Rather, the chosen EAP method controls whether the
> authentication is mutual or one-way, and support for
> a supplicant controlled-port determines whether
> authorization is mutual or one-way."
>
<very nice>

> > In an earlier version of 802.1X (802.1X-2001), only the
> > authenticator was specified to affect the controlled port.
>
> I'd rephrase to say "only the authenticator was specified to
> have a controlled port."
<nice>

>
> > This one-sided specification prevented mutual
> > authentications from being mutually enforced, essentially
> > preventing mutual authentication.
>
> I'd rephrase to say "The lack of a supplicant controlled port prevented
> mutual authentication from being enforced on both sides."
<nice>
>
> > 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.
>
> would change to "remedies this by specifying controlled ports
> for both the authentication and supplicant."
>
> > 1) When the devices require the creation of separate
> > keying material as in group keys for 802.11 adhoc networks.
>
> The issue here was not that each side required separate keying material;
> it was that the 802.11 group key handshake was uni-directional (AP only
> provided a group key to the supplicant, not the other way around).  So
> I'd rephrase to say:
>
> "When the devices require the creation of separate key material in
> each direction but the keying protocol is uni-directional (as in the group
> handshake in 802.11 adhoc networks)."
<nice>

>
> > 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.
>
> Would rephrase to:  "When two bridges are connected, each
> bridge may implement the Supplicant role, but may have
> authorization requirements that can only be enforced by
> the Authenticator ("Supplicant Access Control with Authenticator"
> variable set to active)."
<nice>

>
> > 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.
>
> As John noted, I think this is problematic.  Do we really need to
> get into this here?  Personally, I delete the above paragraph.
<I think Jim has a good suggestion for dealing with this>

> > 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.
>
> Let me make sure I understand this fully.
> If one device is only an authenticator, then it could authenticate the
> dual role device.  If a mutual authentication is successful, the dual role
> device could decide it is satisfied, and then data would flow in both
> directions.  However, if the dual role device decided it needed to
> initiate authentication in the other direction (e.g. mutual authentication
> didn't provide it with sufficient authorization), would presumably send an
> EAP-Request/Identity to the authenticator-only device, who would
> not respond.  As a result, the authentication in the other direction would
> fail.  At that point, presumably the dual role device would close off
> communication in *both* directions, no?  So I'm not clear how we can
> get data flowing in only one direction.
<I think Jim has a good handle on fixing this>
>
> > 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.
>
> This is good advice -- but I wonder if it's enough.  In looking at
> Section 2.4 of RFC 2284bis, there are really quite a few requirements for
> successful peer-to-peer usage of EAP:
<here I think the reference is to the fact that ports may have supplicant, 
authenticator, or both and connecting between ports with different 
capabilities doesn't work in all cases.  For example two ports that are 
configured as only authenticator will not successfully connect.  So this 
does not have anyth9ing to do with EAP. >

> a. Need both authenticator and supplicant 802.1X roles.
> b. Need both authenticator and peer layer support within the EAP
> implementation. c. Need both authentication and peer support within the
> implemented EAP method. d. Need both authenticator and peer credentials
> provisioned on both sides.  This is made easier if the selected EAP
> method is peer-to-peer so that the same credential can be used both ways.
>
> Perhaps you should add  "See Section 2.4 of RFC 2284bis for other issues
> which may arise in peer-to-peer usage of EAP."
>

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jim Burns <[email-masked]>
Date: Fri, 30 Jan 2004 11:51:47 -0500

Hi  Bernard,
    Thanks for your input (and cleanup of my pedantic text).  I accept 
all of your comments except two which I believe need a bit more 
discussion just to be certain we are on the same wavelength.

> for both the authentication and supplicant."

    The issue here is that making this change could mislead folks into 
believing there are two controlled ports.  In reality, 802.1XRev still 
only specifies a single controlled port.  The difference between 
802.1X-2001 and 802.1XRev is that the controlled port will not become 
authorized until both the supplicant and authenticator set their 
individual authorization variables.
    So, your sentence above is accurate in the case that the 
authenticator and supplicant are in separate devices since in one device 
only the authenticator role is implemented and it controls the 
controlled port alone and in the other only the supplicant. 
     The sentence becomes inaccurate (or less precise) in a device that 
implements both the authenticator and supplicant roles.  In this case 
the above sentence would indicate that a device with both roles actually 
has two separate controlled ports.

> directions.  

     Yes, but this procedure is not directly defined in the standard.  
An implementation of the dual role device would need to detect that the 
supplicant was fully satisfied and then ignore the authenticator's result.

> However, if the dual role device decided it needed to

    Everything you say in this paragraph is accurate.  Our difference 
appears to be on the definition of 'asymmetric' data flow (which is 
possibly because it is a poor choice for a name).  What I mean to 
indicate is the single-role device has opened its controlled port and 
believes it has access to the network and is blissfully unaware that the 
other side of the connection has a closed port.  So, from the point of 
view of the single-role device the data link is asymmetric -- it can 
send data out its port, but data never comes in its port.  The main 
issue here is one of end-user experience -- all the network protocols 
will see the operable port, send their frames and then time out.  
Perhaps new text around 'asymmetric data flow':
    "...asymmetric data link (one entity's controlled port is authorized 
while the other entity's controlled port is not)."