[prev in list] [next in list] [prev in thread] [next in thread] 

List:       open1x-xsupplicant
Subject:    [Open1x-xsupplicant] Machine authentication feedback requested..
From:       Chris Hessing <chris () open1x ! org>
Date:       2008-12-18 18:24:29
Message-ID: 494A955D.5000901 () open1x ! org
[Download RAW message or body]

All -

Anyone that has been paying attention to the SVN commits will have 
noticed that machine authentication capability has been added to the 
supplicant.  This isn't to say that with the new code you get the same 
functionality as the built-in Windows machine authentication just yet.  
Which is actually the reason for this e-mail.  Getting machine 
authentication going in the way that most people expect has some 
potentially major impacts on how the supplicant works.

Just to bring people up to speed real quickly on what has been going on 
since the last development release, and to help you understand the 
issues.  In the current subversion versions the supplicant's 
configuration was split.   In the past, the supplicant relied on a 
single configuration file stored in the "All Users" section of the file 
system.  The result was that every user on the machine had the same set 
of configuration information.  That central configuration file remains, 
and will continue to function in the same way as it always did, but new 
additions to non-global configuration options are now written to the 
user's home directory, and will only show up for that user.

This change allows for a lot of new functionality in the supplicant.  
For one, EAP-TLS is now exposed through the UI, the individual user's 
certificate store is now used, and user passwords stored in user 
configurations are encrypted with a user specific key.  (This last one 
is important.  The encryption used in the global configuration could be 
decrypted by anyone with access to the same machine.  Now, someone would 
have to have access to the machine, and be logged in as your user account.)

This change in functionality breaks some of the functionality that 
previously existed.  Specifically, the default wired option.  Currently 
the default wired option is a global setting, which means that there 
would need to be some magic to make it keep working as it does.  
Basically, if a user changed the default wired option to something that 
was in their own configuration, that configuration would need to be 
copied to the global config, and the stored password for that 
configuration would need to be encrypted with the machine key.  
Depending on how the authentication was set up, this could expose a 
password that might be the same password used on the Windows domain.  
This seems to be an unacceptable security issue.

Now for the core issue, how to make machine authentication work in a way 
that makes sense to as many people as possible.  As I think about it, I 
have come up with two different ways of putting machine authentication 
in to the supplicant.

The first option would be to keep the existing strong binding between 
interfaces and connections.  This strong binding is what makes it so 
that when you are on the login screen the connection options you have 
available change depending on which interface is selected.  If we chose 
to continue with this model, then we need to set up a connection for 
each interface in the machine.  Any time a new interface was inserted, 
the user would have to enable machine authentication on that interface 
manually.  This works, but the UI implementation seems like it would be 
ugly because you would need to show a list of all of your interfaces, an 
option to enable machine auth on the interface, and some means of 
specifying the SSID to use if the interface is wireless.

 

Another option would be to break the binding of interfaces and 
connections, and only have a single connection for the machine 
authentication.  This single connection would have a value indicating if 
we should be doing machine auth on wired and/or wireless, and a superset 
of the information needed to authenticate on either type of interface.  
The pros of this is breaking the binding provides some nice advantages 
in functionality across the whole supplicant. (All wireless 
configurations would be available on all wireless interfaces, and all 
wired configurations would be available on all wired interfaces.)  The 
con is that this method only allows for a single means of connecting to 
a machine authenticated network.  I am not sure this con is that big of 
a deal because you can only have a single set of machine credentials, so 
the only time this would be a problem is if you had multiple SSIDs that 
your machine credentials would be valid on.   The other major con to 
this method is that it would have a pretty major impact on the code, so 
the potential for introduction of larger bugs is likely.  If this path 
were taken, the UI becomes a bit cleaner.  It would probably be a 
checkbox to enable machine authentication, a checkbox to enable it on 
wired and wireless interfaces, and some way to pick the server 
certificate and SSID to be used with wireless.


Whatever is chosen will have a significant impact on the future of the 
supplicant, which is why I am trying to get as much input as possible.  
So, if you love or hate one of these options, or have a better option of 
your own, please speak up!

Thanks!



------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Open1x-xsupplicant mailing list
Open1x-xsupplicant@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open1x-xsupplicant
[prev in list] [next in list] [prev in thread] [next in thread]