Need help with off-standard 802.1x authentication on Linux

[Jouni Malinen]

On Sun, Sep 18, 2011 at 07:37:45PM +0800, Qian Hong wrote:
> I'm a Linux user from China, lot's of Linux users especially student
> users like me have great trouble while using Linux, that's the
> Internet connection. Many universities here use all kinds of private
> off-standard 802.1x authentication for network connection,
> unfortunately , those off-standard 802.1x authentication are usually
> not supported on Linux. The good news is, some of them now have open
> source implement by black-box analysis and disassemble on their close
> source Windows client.

> The actually questions I would like to get answers here are below:
> 1. If there is a private off-standard 802.1x authentication protocol
> ,which is supported by some third party open source client, then will
> wpa_supplicant project support it in the future to?

It depends.. In general, I like to promote use of standard-based
solutions and protocols that have open standard. That said, if there are
are authentication mechanisms that are in common use, it sounds
reasonable to consider adding support for them.

> Integrate those off-standard 802.1x protocal in wpa_supplicant will
> bring enormous benefits to end users :(1) users can use
> network-manager gui to connect to Internet gracefully without command
> line skills; (2) A new operating system without 802.1x client in
> college campus network is really painful for user, she should connect
> to internet to download a 802.1x client first -- if you want to
> connect to internet, you must connect to internet first... What a f**k
> loop, isn't it? If a Linux distribution ship those off-standard 802.1x
> client by default, then there will be more convenience.

I agree that it would be desirable for Linux distributions to work
out-of-box on networks that are widely deployed.

> If yes, how can we getting involved (maybe as an end user, not a
> developer right now)
> If no, how does it depend on legal issues and how does it depend on
> technical reasons ?

Sending a feature request to this mailing list and reporting which
protocols are being used is a good start. I've never even heard of many
of the examples you mentioned. Unfortunately, there is still quite a bit
of language barrier that can explain that and while some of the
automated translation services are making it easier to get the needed
information, it can still slow down efforts getting these implemented.
It can certainly if people familiar with the custom authentication
mechanisms (or at least familiar with the language used in their
specification and/or implementations) can participate in the effort.

As far as legal issues are concerned, there can be potential problems in
using proprietary solutions. It is difficult to give generic comments on
this as this will mostly need to be handled on case by case basis.
Ideally there would be a publicly available description of the used
protocol, but if not, 3rd party reverse engineered implementations could
be considered as documentation.

> 2. If some of private off-standard 802.1x authentication is still
> mystery, will  wpa_supplicant developer hack on them?

I'm not completely sure what you ask here. In general, it will be
difficult to work on custom protocols without having access to a test
setup that can be used to verify protocol and implementation behavior,
so many cases can be too time consuming to justify the effort.

> Here are some examples of private off-standard 802.1x authentication
> client (and there open source implement)
> 
> H3C INode
> Official Website(Chinese) :
> http://www.h3c.cn/Service/Document_Center/IP_Management/H3C_iNode/
> Third party open source implement: git://github.com/liuqun/njit8021xclient

This looks like some kind of design based in wired IEEE 802.1X
authentication and the 802.1X part itself could even be standard
compliant (didn't really review it in detail). There is some kind of
custom EAP method (EAP type 20 which is unassigned). There seem to be
even university-based differences in how exactly those messages are
processed based on the comments. In addition, EAP notification may be
used in some custom way. The client seems to include support for
EAP-MD5, so that may be used, too.

I don't really like the concept of picking an unassigned EAP type and
using it for some custom purpose taken into account that this can easily
conflict with other uses should the specific EAP type actually get
assigned in the future. Anyway, it sounds possible to add support for
this in wpa_supplicant.

Would you happen to know how widely this is deployed? The comments in
njit8021xclient seemed to point to at least some university use. I would
assume this is a wired network using something from H3C (Huawei-3Com?).
Any idea whether the technology is still being developed and supported
(as part of HP now?)?

Do you know whether there is any documentation of the custom EAP method
or changes to EAP? H3C seemed to have some related documentation in
English available at
http://www.h3c.com/portal/Technical_Support___Documents/Technical_Documents/Switches/H3C_S12500_Series_Switches/Configuration/Operation_Manual/H3C_S12500_CG-Release1335-5W130/11/201108/722596_1285_0.htm

> Ruijie
> Official Website: http://www.ruijienetworks.com/
> Third party open source implement: http://code.google.com/p/mentohust/

This seemed to include some functionality that would be outside the
scope of wpa_supplicant. I'm not completely sure what exactly is in
scope, but there were some references on 8021x.exe (but that was not
really used for more than extracting something from the binary) and the
group MAC address for Ruijie (01:d0:f8:00:00:03) was used similarly to
the IEEE 802.1X EAPOL group address, so there is some connection, but it
would take more time to figure out what exactly is being done here.

> Dr.com
> Official Website: http://www.doctorcom.com/en/index.php
> Third party open source implement: http://sourceforge.net/projects/drcom-client/

This seems to be out of scope for wpa_supplicant functionality, so it
looks like the project could be integrated on its own to network
management functionality in a distro.

-- 
Jouni Malinen                                            PGP id EFC895FA