Subject: [eap] Discrepancies between 802.1XREV and RFC 2248bis

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 Jan 2004 11:00:42 -0800 (PST)

I just reread RFC 2284bis section 2.4 and 802.1XREV Section 6.7, and they
seem miles apart.  This needs to be resolved before 802.1X-REV is
published.

Here is my reading of the differences and what needs to be done to fix
them:

a. Section 6.7 of 802.1X-REV indicates that EAP authentication
can only be uni-directional.  RFC 2284bis Section 2.4 states the
conditions under which bi-directional authentication is achievable.
Since 802.1X-REV now leaves authentication to EAP, it is not possible for
IEEE 802 encapsulation to change the fundamental properties of EAP, so the
two specs cannot disagree on this point.

b. Section 6.7 appears to assume (contrary to recent discussion) that
there is no way for the AAA server or higher layer to communicate the peer
decision down to the lower layer on the authenticator side.  Given the new
interface variables and discussion on AAA key implications, I think we've
settled this issue. While I'm ok with not changing 802.1X-REV to discuss
the new interface variables or AAA implications (this can go in the EAP
State Machine document), I do think that the implications for the text of
Section 6.7 do need to be addresssed.

To fix these issues, it would probably be best if Section 6.7 referenced
RFC 2284bis Section 2.4 and removed the paragraphs that appear to
contradict RFC 2284bis. Given that 802.1X-REV is entering sponsor ballot,
it is relatively late for these fixes to be put in -- but I fear that if
the changes are not made now the pain will be much greater down the line,
particularly since 802.1af appears to want to address some of the same
peer-to-peer issues.

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

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 19 Jan 2004 16:08:12 -0500

> two specs cannot disagree on this point.
I agree that this is confusing and should change.

> Section 6.7 do need to be addresssed.
The current proposal to fix this, as descrbed by Jim Burns (and myself and 
others) does not need to pass any signal down, so I don't think this needs 
to be done.

> particularly since 802.1af appears to want to address some of the same
I agree that this should be done.  It is in addition to the small changes 
that Jim Burns has described.  I also realize this is late and am not sure 
how it should be handled.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 Jan 2004 15:06:38 -0800 (PST)

> how it should be handled.

Do we have a proposal for a revised Section 6.7 of 802.1X-REV?  If not, do
we need to come up with one?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 19 Jan 2004 16:09:20 -0800

[email-masked] wrote:
> I just reread RFC 2284bis section 2.4 and 802.1XREV Section
> 6.7, and they seem miles apart.  This needs to be resolved
> before 802.1X-REV is published.
> 
> Here is my reading of the differences and what needs to be done to
> fix them: 
> 
> a. Section 6.7 of 802.1X-REV indicates that EAP
> authentication can only be uni-directional.  RFC 2284bis
> Section 2.4 states the conditions under which bi-directional
> authentication is achievable. Since 802.1X-REV now leaves
> authentication to EAP, it is not possible for IEEE 802
> encapsulation to change the fundamental properties of EAP, so
> the two specs cannot disagree on this point.
> 

[Joe] I'm looking at section 6.7 of 802-1X-REV-d8.pdf and it appears to
be somewhat ambiguous, last paragraph gives EAP-TLS as an example of
mutual authentication.  

> b. Section 6.7 appears to assume (contrary to recent
> discussion) that there is no way for the AAA server or higher
> layer to communicate the peer decision down to the lower
> layer on the authenticator side.  Given the new interface
> variables and discussion on AAA key implications, I think
> we've settled this issue. While I'm ok with not changing
> 802.1X-REV to discuss the new interface variables or AAA
> implications (this can go in the EAP State Machine document),
> I do think that the implications for the text of Section 6.7
> do need to be addresssed.
> 

[Joe] I'm still unclear as to what the "decision" really is and its
impact on authorization, but this currently does not seem to be an issue
discussed in section 6.7.  Is this discussed elsewhere in the 802.1XREV
document?

> To fix these issues, it would probably be best if Section 6.7
> referenced RFC 2284bis Section 2.4 and removed the paragraphs
> that appear to contradict RFC 2284bis. Given that 802.1X-REV
> is entering sponsor ballot, it is relatively late for these
> fixes to be put in -- but I fear that if the changes are not
> made now the pain will be much greater down the line,
> particularly since 802.1af appears to want to address some of
> the same peer-to-peer issues.
>

---

From: Jim Burns <[email-masked]>
Date: Mon, 19 Jan 2004 19:08:58 -0500

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 believe the points we want to make in 6.7 are the following:
   .1X is an asymmetric transport protocol (it has two separate 
roles).   It is asymmetric due to history when only the authenticator 
had a controlled port.
   Now that both the supplicant and authenticator both have a controlled 
port the asymmetry of the .1X transport does not disallow a mutual 
authentication EAP method from doing a bi-directional authentication 
over the .1X transport.
   There are some idiosyncracies of the asymmetric nature of the .1X 
transport, the main one being that two simultaneous authentications can 
be run if both .1X machines are implemented and both must complete 
successfully for the controlled port to be unblocked.
   There are reasons that you may want to utilize two simultaneous 
authentications, as described in section 2.4 of 2284 (as well as some of 
the verbage in 6.7).
   It should be made clear that two coupled one-way authentications does 
not provide the same security as a single mutual authentication.
   Each application should define which roles of the .1X state machines 
each device is to implement as well as the class of EAP methods (mutual 
authenticating or unidirectional authentication or both) that are required.
   One must be careful of certain combinations of the number of 
machines, and be aware that a device with both .1X machines encountering 
a device with just the .1X authenticator will result in an asymmetric 
network connection (controlled port open on one device and closed on the 
other).  I have a table that defines all the cases clearly.
--------------------------
Known uses are: 
   802.11 infrastructure:  1 supplicant on client and 1 authenticator on 
AP using mutual authenticating EAP methods.
   802.11 adhoc:  Each adhoc station should run both supplicant and 
authenticator with key generating EAP methods.  The key used for group 
key is from the highest numbered MAC address.
   802.1 bridges:  Both supplicant and authenticator with special 
variable that makes controlled port controlled only by authenticator 
enabled.  EAP method type not defined.

   The current text of 6.7 along with the above points could be the 
starting point for a revised 6.7 if that is still possible in the IEEE 
cycle.
   Please critique and add to the above list and I will create a revised 
6.7 and issue it for critique.   I can present it to the IEEE to see if 
it will be accepted at this time.
Thanks,
Jim B.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 Jan 2004 20:11:08 -0800 (PST)

> 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?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jim Burns <[email-masked]>
Date: Tue, 20 Jan 2004 09:04:34 -0500

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.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Jan 2004 08:26:26 +0200

Jim,

Your list looks good to me.

--Jari

>   .1X is an asymmetric transport protocol (it has two separate roles).   
> It is asymmetric due to history when only the authenticator had a 
> controlled port.
>   One must be careful of certain combinations of the number of machines, 
> and be aware that a device with both .1X machines encountering a device 
> with just the .1X authenticator will result in an asymmetric network 
> connection (controlled port open on one device and closed on the 
> Known uses are:   802.11 infrastructure:  1 supplicant on client and 1 
> authenticator on AP using mutual authenticating EAP methods.

---

From: Jim Burns <[email-masked]>
Date: Wed, 21 Jan 2004 18:41:00 -0500

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:

> =>IEEE 802.1 Email List user information:
> http://www.ieee802.org/1/email-pages/
>