wps_enrollee-20071029

[Ted Merrill]

Hi Dan,
Thanks for the feedback.

Do you have access to a copy of the WPS specification? 
And do you have access to a WPS enabled access point?

In my modifications to driver_wext.c and to ctrl_iface.c, wps information is 
always provided based on the probe reply and beacon WPS information elements 
that are seen.
The SCAN_RESULTS command will always print out [WPS] if the AP advertises WPS 
capability, except if it is in WPS ready state when it will print out 
[WPS-PB-ready] or [WPS-PIN-ready].
WPS-PB-ready means that the user has pushed the WPS button on the AP within 
the last two minutes, and WPS-PIN-ready means that the user has enabled PIN 
mode on the AP within the last two minutes.

Don't get the probe request WPS information element confused with the AP's 
probe reply / beacon WPS information element!

When using the WPS push button method, the WPS i.e. that is added to the probe 
request has the affect of gaining an exclusive lock... the AP is not supposed 
to allow any other client to do WPS push button method until the previous one 
finishes, with a timeout of two minutes.
This is intended to provide security against hostile attacks, and also to 
simply avoid identity confusion.
I think you can see that you don't always want to be sending this information 
element every time you scan!

With regards to adding a WPS_SCAN command instead of using existing SCAN and 
SCAN_RESULTS commands, my thinking is that the existing SCAN and SCAN_RESULTS 
commands are somewhat broken because the results are not necessarily directly 
related to the SCAN command... as best as i can determine, you have to wait 
some undefined amount of time before SCAN_RESULTS will really reflect the 
SCAN command, with a danger of waiting too short or too long a period.
By contrast, for WPS we specifically want to enable the WPS i.e., do scanning, 
obtain the results knowing that they were obtained with the i.e. enabled, and 
then turn off the probe i.e. when we are done.
We >could< rewrite SCAN and SCAN_RESULTS but it might break existing software, 
so it sounds like a bad idea.
(I'm not sure that my WPS_SCAN implementation totally solves these timing 
issues, but at least it provides the right framework).

The WPS_SCAN step can be skipped and WPS will still (usually?) work, just not 
as securely... the WPS spec is vague on this point, but it appears that 
existing implementations on APs don't force you to have done a scan with 
probe request i.e.s in place...
However, you are still left with the problem of determining which AP to talk 
to, to do WPS with.
It has to be an AP which is in a WPS "ready" mode corresponding to the method 
the client will be using -- push button or PIN.
This can be determined from a normal scan (with my fix) provided that the scan 
results really reflect current reality (see above for my complaint about the 
current SCAN/SCAN_RESULTS commands).

Note: my WPS_SCAN command simply ignores errors in setting the probe request 
i.e. -- if the driver doesn't support it, then we just carry on (with reduced 
security of course).

I hope this answers all of your questions.

-Ted

On Monday 26 November 2007 13:19:59 Dan Williams wrote:
> On Mon, 2007-11-26 at 12:19 -0800, Ted Merrill wrote:
> > I have patches to the hostap almost ready (some bugs i want to work out
> > first) that embed WPS into wpa_supplicant will allow a GUI to drive
> > wpa_supplicant. And of course i'll need to address issues that Jouni has
> > or may have.
> >
> > The modifications to the wpa_ctrl commands (in my patch) are:
> >
> > -- In the "flags" part of scan results, it prints out [WPS] if the AP is
> > WPS capable.  If the AP has been activated to do WPS then it instead
> > prints out [WPS-PB-ready] or [WPS-PIN-ready] according to the activated
> > mode.
> >
> > -- There is a new command "WPS_SCAN" which is the same as the regular
> > "SCAN" except for the following differences:
> > It adds appropriate WPS information element to probe requests during
> > scanning (and removes it after done scanning), as required (strongly
> > suggested?) by the WPS standard.
> > It filters the results to only those which indicated activated WPS in the
> > right mode (normally there should be exactly one).
> > The results are reported asyncronously.
>
> This seems like overkill.  Ideally, wpa_supplicant _always_ requests
> that the driver do the WPS probe, and returns the WPS results if WPS is
> available, otherwise not.  For example, it's certainly valid to
> interpret the WPA IEs and return them even if your card _can't_ do
> WPA.
>
> On the WEXT side, we should make a new capability for WPS and make
> wpa_supplicant read that before trying WPS.  I don't really like having
> duplicate commands, because there's no reason the driver shouldn't know
> if WPS is supported or not.
>
> Alternatively, if I just don't understand the flow of WPS, do you _not_
> always want to know the WPS IEs?  Do you only ever want to see the WPS
> IEs on demand?  If so, then we should add a flag to the WEXT scan
> command to request WPS probes, but the results should always return WPS
> IEs if available.
>
> I think the WPS stuff should be an additional option to the scan command
> in the wpa_supplicant control interface, not a separate command.
>
> Thoughts?
>
> Dan
>
> > -- There is a new command "WPS" which does the actual message protocol
> > exchange and reports the results asyncronously (via wpa_supplicant
> > messages) when done... it is up to the GUI or etc. to make use of the
> > results and e.g. reconfigure wpa_supplicant.
> >
> > To support this, i've added a new driver ops function pointer
> > *set_wps_probe_req_ie()
> > to get a WPS probe request information element added to probe requests
> > during WPS scanning,
> > and actual support for this for madwifi... i don't feel responsible for
> > getting it to work for other hardware.
> >
> > Also the scan result structure has two new fields,
> >         u8 wps_ie[SSID_MAX_WPS_IE_LEN];
> >         size_t wps_ie_len;
> > ... just like what is done for wpa/rsn ; this is supported in
> > driver_wext.c which is used for various (although not all) hardware.
> > I'm not sure why  Johannes thinks a kernel API change is required.
> >
> > I'm curious if people have WPS capable access points available to them
> > for testing... i might be able to do something about that if that is an
> > issue.
> >
> > More to come,
> >
> > -Ted Merrill
> > Atheros Communications
> >
> > On Monday 26 November 2007 07:07:23 Dan Williams wrote:
> > > On Thu, 2007-11-22 at 00:57 +0100, Johannes Berg wrote:
> > > > [steps snipped]
> > > >
> > > > That looks like it would be very usable from GUI programs like
> > > > network manager too.
> > > >
> > > > > -- on success it gets a little more complicated... typically we
> > > > > will want to save the new configuration to a file for later use,
> > > > > and begin using it immediately as well, probably in preference to
> > > > > anything existing... but there could be exceptions...
> > > > >
> > > > > Also of course note that determining the ssid to use is best done
> > > > > by scanning, filtering the results to find those that are "wps
> > > > > ready", and getting user OK to proceed... presumeably this would
> > > > > use wpa_ctrl ...
> > > >
> > > > As you said, I also think that most of the code to do WPS should be
> > > > in wpa_supplicant. I guess for testing there should also be a simple
> > > > command-line wpa_cli-like program that does the UI steps of wps and
> > > > simply outputs a configuration file to stdout or so. This could be
> > > > used in scripts etc., it would probably take the SSID, pin and other
> > > > configuration on the command line. Afterwards, the user would have to
> > > > take this configuration file and feed it back to wpa_supplicant.
> > > >
> > > > On the other hand, when using network manager, the WPS command line
> > > > tool wouldn't be used but NM would instruct wpa_supplicant directly
> > > > to do WPS. That way, NM could offer a simple UI for doing WPS.
> > > > Instead of writing a config file it would store the settings and
> > > > change the running wpa_supplicant to use them if desired.
> > >
> > > Right.
> > >
> > > > Right now there is probably no way to determine whether an AP is "WPS
> > > > ready" without changing the kernel API... But with nl80211 I'll
> > > > probably just embed the information elements in the scan result so
> > > > userspace can parse from it whatever it needs.
> > >
> > > Ideally, wpa_supplicant can find out whether the AP supports WPS from
> > > the IEs and advertise that in the scan results it provides over the
> > > control interfaces.
> > >
> > > Dan