eap Mailing List: Re: Discrepancies between 802.1XREV and RFC 2248bis

[Jim Burns (jeb]

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.


> 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
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>
>