eap Mailing List: Strawman for a modified section 6.7 for IEEE 802.1XRev

[Jim Burns (jeb]

Folks,
Below is a strawman for section 6.7 of the IEEE 802.1XRev document.
It attempts to remedy the discrepencies with section 2.4 of IETF RFC 
2284bis.
I have incorporated ideas from original 6.7 and a number of folks, 
thanks to all.
Please send critiques, comments, concerns and I will try to make 
modifications to satisfy all.
As Tony J. indicated, we are very late in the 802.1XRev cycle and we 
will have only one official cycle on this so we should do all our 
cycling here and get it right the first time.
Thanks,
Jim B.

Modified IEEE 802.1XREV Section 6.7
Please use a fixed width font to view this. Also,
you may need to widen your window to view the table.
----------------------------------------------------
6.7 Coupling two 802.1X authentications
This section discusses the asymmetric nature of the
802.1X transport, how this asymmetry affects
authentication results, the ability of the 802.1X
transport mechanism to run two simultaneous transports
in opposite directions, how this affects authentication
results and why this simultaneous bi-directional
transport may be utilized.

802.1X's transport mechanism for authentication frames
is asymmetric; 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. It is
a request/response transport and the state machines
reflect this. This request/response transport mirrors
the authentication protocol that is carried within the
802.1X transport: EAP. Such a transport is sometimes
called 'one-way' meaning the protocol is always
originating from one side (the requestor).

This transport asymmetry (of 1X and EAP) does not affect
the symmetry (or asymmetry) of the authentication method
(EAP method) that is carried by the transport. Please
note the separate usage of 'authentication protocol
(EAP)' from 'authentication method (EAP method)' in this
discussion (for a deeper understanding please see RFC
2284). A mutually authenticating EAP method (such as
EAP-TLS) may run atop the asymmetric transport mechanism
and mutually authenticate both parties (it is symmetric
in that both parties contribute to the authentication
result). Likewise, if the EAP-method that is chosen is
assymmetric (EAP-MD5), then the authentication will be
assymmetric (only one party will be authenticated to the
other). In fact, it is not the 802.1X transport that
controls the symmetry of the authentication, but rather
the chosen EAP method and the existence of a controlled
port on both the supplicant and authenticator.

It should be noted that 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
asymmetric (no matter what EAP method was chosen), but
it was due to the lack of a controlled port on the
supplicant, not due to the asymmetric transport. The
current version of 802.1X remedies this by specifying a
controlled port on the supplicant.

The 802.1X transport asymmetry means that each role has
its own state machine and it is possible that a single
device can implement both roles (state machines). If a
device with both roles implemented encounters another
device with 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 transports.

One must understand that two coupled one-way
authentication transports is not equivalent in security
to a single transport of a mutually authenticating EAP
method (such as EAP-TLS). This is because the
authentications on the two separate transports are not
specified to be cryptographically bound together. In
other words there is no way to cryptographically
ascertain that the party involved in the first one-way
transport is the same party that is involved in the
alternate one-way transport.

Despite the ability to mutually authenticate two devices
with a single transport, there may exist other reasons
to simultaneously run two 802.1X transports in opposite
directions. When both devices require the creation of
separate keying material as in unicast keys for 802.11
adhoc networks. When different credentials are used for
different roles (one credential for the supplicant role
and one for the authenticator) then a bi-directional
transport with EAP-TLS using different certificates in
each direction may be used. When two bridge devices are
connected together and they wish to authenticate each
other then they may implement both roles on their
connecting ports. Some of these cases are discussed in
section 2.4 of RFC 2284.

Certain encounters between a device with both .1X
transport roles implemented and a device with a single
.1X transport role can result in an asymmetric traffic
flow (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.

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

Applications that utilize 802.1X should clearly specify
which .1X roles must be implemented to avoid encounters
that will result in failed network connections. In
addition, an application should consider specifying a
class of EAP methods or a limited set of EAP methods to
allow for simpler security analysis of the application.
Some examples of known applications and their common
usage of 802.1X and EAP are:

802.11i infrastructure mode
- Access point implements authenticator role
- Client implements the supplicant role
- A mutually authenticating EAP method is utilized

802.1 bridge to end node
- Bridge implements the authenticator role
- End node implements the supplicant role
- No EAP method type specified

802.11 adhoc mode
- Each adhoc device implements both the supplicant
and authenticator role
- A key-generating EAP method is utilized.

802.1 bridge to 802.1 bridge
- Each bridge implements both the supplicant and
authenticator role.
- Each bridge sets the Supplicant Access Control
With Authenticator administrative control
parameter to inactive so that only the
authenticator role controls the controlled port.


Jim Burns wrote:

> Hi Bernard,
> Yes, I would be happy to take a first crack at it and then accept input.
> My schedule is such that I will not get it out til this eve or 
> Wednesday AM.
> Sorry about the delay,
> Jim B.
>
> Bernard Aboba wrote:
>
> > > Hi folks,
> > > Yes, a reread of 6.7 leads me to believe that it could be confusing
> > > to implementers. My opinion is that the current 6.7 was written before
> > > there was a supplicant controlled port. With the addition of the
> > > supplicant controlled port, the uni-directional nature of the transport
> > > is no longer a blocking feature to a bi-directional EAP method.
> >
> > I agree (modulo the caveats in Section 2.4 of RFC 2284bis).
> >
> >
> >
> > > I believe the points we want to make in 6.7 are the following:
> >
> > This sounds like a good start. Do you want to draft some sample text for
> > review?
>
>
>
> =>IEEE 802.1 Email List user information:
> http://www.ieee802.org/1/email-pages/