Implementing Thesis Project

Ludwig Nussel ludwig.nussel
Wed Mar 16 10:15:03 PDT 2011

Jouni Malinen wrote:
> On Wed, Mar 09, 2011 at 08:39:49PM -0700, AltF4 wrote:
> > But the TL;DR is that it's an EAP type like TTLS that uses a CA signed
> > server side certificate, and no inner (client) authentication. I did
> > make a really hackish proof-of-concept out of wpa_supplicant and hostapd
> > using some config files. But it's not anything someone would actually
> > want to use.
> > 
> > So I'm looking to make a "proper" implementation. Where would a good
> > place to start, aside from just kind of digging through the code? (Which
> > I fully intend to do, but I figured I'd ask.)
> Is there any particular reason for using another EAP type for this? It
> would sound much simpler to just use an existing type like TTLS with a
> fixed username/password for this particular purpose. The extension of
> binding SSID to the server certificate could (and probably should) be
> done completely outside the scope of the EAP method. The EAP method
> would just expose the server certificate that was used and after
> successfully completed authentication, the upper layer code in the
> supplicant would verify that the current SSID matches with the one
> encoded in the CN.

Note that interpreting any meaning into the CN rather than using it
simply as some human readable string is considered deprecated. Ie
host names are supposed to be listed as subjectAlternativeName of
type dNSName. There's a new RFC coming up which intends to
standardize that?.
However, in contrast to DNS domain names there is no central
registry for SSIDs. So how should a CA determine who the legit owner
of a SSID is? You'd need a dedicated CA for your purpose IMO. Using
"system certificates" ie internet CAs isn't suitable for
authenticating wireless networks.



 (o_   Ludwig Nussel
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

More information about the Hostap mailing list