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

From: Jim Burns <[email-masked]>
Date: Thu, 22 Jan 2004 09:47:35 -0500

Hello,

Thanks for the 2nd revision Bernard, it was much improved.
Below is a 3rd revision that began with the 2nd and modified the last two paragraphs:

1. Changed the text in the 2nd to last paragraph to indicate that if a device with two roles implemented encounters one with just an authenticator implemented then an asymmetric network flow can occur (one controlled port open, the other closed).  It is only an encounter with a single authenticator that causes this, encounters with a single supplicant will eventually result in a symmetric network flow (supplicant will time out after making 3 attempts to contact a non-existant authenticator and since the authenticator that is running in the same device will have made the link secure the supplicant should enter the authenticated state).

2. Put back a paragraph about suggested use of .1X in applications, but did not put back the discussion about EAP nor about specific applications that currently use .1X.  I just want to stress that to avoid the asymmetric network flow an application must ensure that the two role device encountering an authenticator-only role device is avoided. 

REVISION 3:
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
asymetries 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 802.1X that controls whether the
authentication is mutual or one-way but rather
the chosen EAP method and the existence of a controlled
port on both the supplicant and authenticator.

Despite the asymmetry of 802.1X and EAP, 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. This previous version of 802.1X
did in fact restrict the authentication result to be
one-way (no matter what EAP method was chosen). However,
this was due to the lack of a controlled port on the
supplicant, not due to the inherent properties of the
802.1X protocol. The current version of 802.1X remedies 
this by specifying a controlled port on the supplicant.

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 exchanges will take place in
opposite directions. This is sometimes referred to as a
bi-directional authentication transport or two coupled
one-way authentication exchanges.

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 unicast 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 implementing both roles
  are connected together and they wish to authenticate each
  other.

When a device which 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. |                  |
-----------------------------------------------------------------------.

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Jan 2004 15:27:10 +0200

> Below is a 3rd revision that began with the 2nd and modified the last 

Looks good to me, thanks!

--Jari