wps_enrollee-20071029

Thu Nov 1 14:01:36 PDT 2007

Dan,

Thank you very much for the feedback.
Yes, Atheros' interest is for embedded systems, but changes to hostap tree 
should of course work for a variety of systems.
I was unaware of the NetworkManager project until this point... i realize i 
have knetworkmanager available (i'm using Kubuntu 7.10) but haven't used it 
(i'm not a big laptop user).
NetworkManager should definitely be extended to support WPS because it makes 
it so easy to get really good security!  just push a button on the AP, select 
the AP from your gui, and a profile that includes a random 64 bit key is 
downloaded.
WPS is new (last year) but should be part of every new AP that provides good 
security (i.e. WPA2 ... anything less is broken).

I'm still trying to understand the Atheros Linux wps_enrollee program (i'm 
learning as i'm rewriting it) so i'm not sure about whether it can coexist 
with wpa_supplicant... i think not.
My prior experience was a wps enrollee implementation for a small Atheros 
prototype product with a non-Linux o.s. (my message handling code from that 
project was used for wps_enrollee program).
In that case, a menu on the device allowed the user to do the following:
-- Select the WPS security mode: pushbutton or PIN (and if PIN, have a PIN 
generated for copy to AP or enter AP's PIN into device).
-- Scan to find an access point in the appropriate mode.
-- Begin the WPS protocol process.
Once WPS was begun, wpa_supplicant was allowed to continue running but was 
forced to use a "open security" wlan profile as required for WPS.
(May need to use filtering during this time to allow only WPS packets 
through).
All incoming network packets with the EAPOL ethernet type were diverted to the 
WPS code, and EAPOL packets were sent by the WPS code.
The result was a new wlan profile which was saved in nonvolatile storage, then 
wpa_supplicant was given all profiles and allowed to cycle through them to 
find one that works... hopefully the one that we just obtained...

I would imagine that NetworkManager should provide similar user interface 
features as the above mentioned device, although you could scan first (there 
are some security issues in this case that have to be addressed).
NOTE that it is necessary to obtain and interpret the wps-specific information 
elements from the beacons (in addition to the information that you must 
already get from beacons to prepare the scan list).
One the SSID has been selected by user and WPS security mode (and PIN number 
if required) has been given by the user, it will be necessary for you to tell 
wpa_supplicant to forget any profiles it knows about (at least for the wifi 
device you have been scanning on :~) and use an "open" profile.
You will need to learn somehow that association via the open profile has 
happened, then begin the wps protocol, obtain the new profile downloaded from 
the AP, store it in non-volatile storage, then tell wpa_supplicant to use all 
profiles again (at least for this device :~).
An alternate approach would be to terminate wpa_supplicant entirely, run a 
standalone program such as wps_enrollee (minus it's feature to auto restart 
wps_supplicant), then start wps_supplicant again (assuming that 
wps_supplicant handles only one network device).

I'm rewriting wps_enrollee to have a clean modular design (and fix bugs!) and 
will keep your situation in mind.
Let me know if you have any/more questions.

Thanks,
Ted Merrill
Atheros Communications

On Thursday 01 November 2007 12:50:45 Dan Williams wrote:
> On Wed, 2007-10-31 at 21:32 -0700, Ted Merrill wrote:
> > On Wednesday 31 October 2007 20:14:57 Jouni Malinen wrote:
> > > On Mon, Oct 29, 2007 at 03:07:41PM -0700, Ted Merrill wrote:
> > > > Here is the wps enrollee code that Atheros is currently developing.
> > > > It was based upon the simpleconfig code i last sent you as well as
> > > > the wpa_supplicant code.
> > > > It could use some restructuring and is incorrect in places... i've
> > > > noted some of the problems in the README file.
> > > > It is not ready for use at this point, but may be close.
> > >
> > > Thanks!
> > >
> > > > Anyway, i'd appreciate if you could post this and then if we discuss
> > > > how this could be re-architected to fit into the hostap tree.
> > >
> > > It is now available at http://w1.fi/contrib/wps_enrollee-20071029.tgz
> > >
> > > I took only a quick look at it now and will need to spend some more
> > > time to be able to discuss in more details what would be best way to
> > > integrate WPS functinality into the main tree.
> >
> > Thanks
> >
> > > If I understood correctly, this is taking in just the parts of
> > > wpa_supplicant that is needed to implements WPS and the end result
> > > (e.g., SSID + WPA PSK) would be used with another program.
> >
> > Right, the end result is a wlan profile which can be used by
> > wpa_supplicant, hostapd, and wsccmd (since a device can be sometimes a
> > client and sometimes a server).
> > The code has been written to automatically start up these programs when
> > appropriate.
> >
> > > Is this design (and/or future goals for it) limited to only using WPS
> > > over EAP transport and only act as an enrollee in IEEE 802.1X
> > > supplicant? Personally, I kind of like the idea of tightly integrated
> > > WPS enrollee in wpa_supplicant, but I would expect large parts of the
> > > WPS implementation to be re-usable for other transports and usage
> > > scenarios.
> >
> > This wps_enrollee program is simply designed for the WPS enrollee
> > situation, and is run with wpa_supplicant NOT running.
> > In this situation, a client needs to not use any other wlan profiles it
> > might have and just use an "open system" profile... an AP which
> > advertises WPS capability should allow the enrollee to associate without
> > authentication or encryption, although the packets exchanged must be
> > limited by the AP to WPS. The approach this program takes is that
> > wpa_supplicant should not be running; this program handles the open
> > system association and when done it writes a configuration file for
> > wps_supplicant and starts wps_supplicant up. Integrating this into the
> > wpa_supplicant program itself certainly seems doable, although i'm not
> > aware of a strong advantage to doing so.
>
> Is this meant mostly for embedded setups?  What we're doing with
> NetworkManager and desktop/server on Linux is to run wpa_supplicant
> _all_ the time and communicate with it over the D-Bus interface.  So to
> do WPS in that situation we'd need to be able to feed that information
> to wpa_supplicant over the control interface long after it's started up.
> We don't even give wpa_supplicant a configuration file, and all
> interfaces are added and removed after wpa_supplicant starts up.  The
> command line is essentially "wpa_supplicant -u".  So whatever
> information WPS needs ought be able to be added after-the-fact as a
> network configuration block or something, hopefully.
>
> If this usage is completely irrelevant to the discussion, please
> ignore...
>
> Thanks,
> Dan
>
> > I'm working on a cleanup of the wps_enrollee code and could be done with
> > that in a few weeks (i want to get the hostapd patches for WPS server to
> > you soon, perhaps tomorrow).
> >
> > -Ted Merrill
> >
> >
> >
> >
> >
> > _______________________________________________
> > HostAP mailing list
> > HostAP at shmoo.com
> > http://lists.shmoo.com/mailman/listinfo/hostap