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

From: Jim Burns <[email-masked]>
Date: Mon, 02 Feb 2004 14:21:05 -0500

Hi folks,
I have incorporated the input from folks and produced V5 of the draft of 
section 6.7 for IEEE 802.1XRev.
The new text appears below preceded by a discussion of the changes that 
were made.
In addition, I have attached a .txt file containing the table xxxx that 
will appear at the bottom of section 6.7 - view this .txt with a fixed 
width font (courier).
I believe that this version is very close to the final draft (if not the 
final draft)
Thanks again for all the input, send along any issues, concerns, 
comments you have on this,
Jim B.
-------------------------------------------
Version 5 changes:

-Alter language to read more smoothly

-Change reason for bi-directional transport in relation to .11 adhoc 
networks to better match the discussion in section 2.4 of 2284bis.

-Remove the discussion of two bridges using a single authentication 
server. This does not work.

-Change text describing why two bridges utilize the bi-directional 
transport.

-Change the text describing the potential problems of a dual role device 
encountering a single authenticator role device to be more clear as to 
the elements that cause the problem.

-Change the term ‘asymmetric data flow’ to ‘asymmetric controlled port 
state’ and change its definition to mean one side authorizes controlled 
port, the other does not.

-Add a reference to 2284bis Section 2.4 in the paragraph that suggests 
that applications using 1X should define the 1X roles to be implemented.

-Update language in table xxxx to be more precise.

-----------------------------------------------------------------------

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, 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.

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 have a controlled port. The lack of a supplicant 
controlled port prevented mutual authentication from being enforced on 
both sides. 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 key material in 
each direction but the keying protocol is uni-directional (as in the 
group handshake in 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 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 inactive).

When a device that implements both 802.1X roles on a single port 
encounters a device that implements only a single authenticator role, 
this may result in asymmetric controlled port state (the single role 
device authorizes its controlled port while the dual role device does 
not because its authenticator role has not been satisfied). A complete 
table of encounters and results appears in Table xxxx.

It is suggested that applications utilizing 802.1X should specify which 
802.1X roles must be implemented to avoid encounters that will result in 
failed network connections. See Section 2.4 of RFC 2284bis for other 
issues that may arise in peer-to-peer usage of EAP.

Table xxxx: Result of encounters between 802.1X transport roles assuming 
key-generating EAP methods are run and authentication result is 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 authorized.
                |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 authorized,
                |choice of EAP    |EAP requests but  |but local 
                |method.          |no response will  |controlled port
                |                 |arrive.           |remains     
                |                 |                  |unauthorized.  
                |                 |                  |Remote 
                |                 |                  |authenticator 
                |                 |                  |and local 
                |                 |                  |supplicant are 
                |                 |                  |authorized, 
                |                 |                  |local 
                |                 |                  |authenticator 
                |                 |                  |remains 
                |                 |                  |unauthorized.
-----------------------------------------------------------------------
Both            |Works            |Fails             |Works
                |Authenticated    |Asymmetric link   | Authenticated
                |link             |Local controlled  | link
                |Authentication   |port is           | Authentication
                |policy set by    |authorized, but   | policy set by
                |choice of EAP    |remote controlled | choice of two
                |method.          |port remains      | uncoupled EAP
                |Local supplicant |unauthorized.     | methods.  Two
                |and remote       |Local             | keys will be
                |authenticator    |authenticator and | formed and some
                |are authorized.  |remote supplicant | mechanism must
                |Remote           |are authorized,   | exist so that
                |supplicant will  |remote            | local and
                |receive no       |authenticator     | remote choose
                |response and     |remains           | the same key.
                |assume no        |unauthorized.     |
                |authenticator.   |                  |
                |Successful       |                  |
                |authentication   |                  |
                |to the remote    |                  |
                |authenticator    |                  |
                |will have made   |                  |
                |the port secure. |                  |
-----------------------------------------------------------------------

---

From: John Vollbrecht <[email-masked]>
Date: Thu, 05 Feb 2004 10:26:34 -0500

Jim - I like this very much.  I do have a couple small changes I would 
suggest.  I apologize for the delay in replying - I was figuring out a 
specific suggested change.  I have noted my suggestions in the text.  -- 
the biggest change is to the terminology about two simultaneous tranports. 
I changed the "one-way" to uni-directional to avoid confusion with one-way 
authentication.

I also changed to indicate that without a suppllicant control of the port 
no authentication, including specifically mutual authentication, can be 
enforced.

I hope these are helpful.  I noted changes by enclosing them in **.

-- John

--On Monday, February 2, 2004 2:21 PM -0500 Jim Burns <[email-masked]> 
wrote:

> section 6.7 for IEEE 802.1XRev. The new text appears below preceded by a
> discussion of the changes that were made. In addition, I have attached a
> .txt file containing the table xxxx that will appear at the bottom of
> section 6.7 - view this .txt with a fixed width font (courier). I believe
> that this version is very close to the final draft (if not the final
> draft) Thanks again for all the input, send along any issues, concerns,
> comments you have on this, Jim B.
> -Change the term ?asymmetric data flow? to ?asymmetric controlled port
> state? and change its definition to mean one side authorizes controlled
> This section discusses the ability of 802.1X to *transport* two 
simultaneous
> *dialogs one* in *each* direction, how implementation asymmetries affect
> transport is sometimes called '*uni-directional*' meaning the protocol 
exchanges
> controls whether the authentication is mutual or one-way, and support for
> a supplicant controlled-port determines whether authorization is mutual
> or one-way.
>
> In an earlier version of 802.1X (802.1X-2001), only the authenticator was
> specified to have a controlled port. The lack of a supplicant controlled
> port prevented ** authentication from being enforced on both sides, *and 
was particularly a problem in that mutual authentication could not be 
enforced on the supplicant side*.  *[no more changes suggested after this - 
John]*
> 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.
>
> 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.
>
> (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.
>
> directions. RFC 2284bis, Section 2.4 discusses some of these cases, which
> include:
>
> 1) 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).
>
> Supplicant role, but may have authorization requirements that can only be
> enforced by the Authenticator ("Supplicant Access Control with
> device authorizes its controlled port while the dual role device does not
> because its authenticator role has not been satisfied). A complete table
> of encounters and results appears in Table xxxx.
>

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