| Re: Strawman for a modified section 6.7 (V3) for IEEE 802.1XRev | <– Date –> <– Thread –> |
From: Jim Burns (jeb mtghouse.com)
|
|
| Date: Thu, 22 Jan 2004 09:36:30 -0500 (EST) | |
Hello,
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.
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.
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).
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. | |
-----------------------------------------------------------------------.
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. | |
-----------------------------------------------------------------------.
-
Re: Strawman for a modified section 6.7 (V3) for IEEE 802.1XRev Jim Burns, January 22 2004
- Re: Strawman for a modified section 6.7 (V3) for IEEE 802.1XRev Jari Arkko, January 23 2004
Results generated by Tiger Technologies using MHonArc.