wps_enrollee-20071029

[Jouni Malinen]

On Mon, Nov 26, 2007 at 04:19:59PM -0500, Dan Williams wrote:

> 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.  

As long as "WPS probe" does not actually mean including the WPS IE in
the Probe Request, I would expect this to be the case. Ted explained
some of the lovely details of WPS push button mode and how that is
related to the WPS IE in probe request. The WPS IE from ProbeResp/Beacon
will be made available regardless of whether the client is actively
trying to use WPS or not (and regardless of whether there is any support
for WPS in the driver).

> 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.

This new capability would be of quite little use since the only driver
changes would be to include support for adding WPS IE into Probe Request
(optional, though recommended, feature) and returning WPS IEs in scan
results (required). We need to extended scan result API to pass WPS IE
(or well, preferable do it properly this time and just pass all IEs to
user space which is actually already used by some driver with a vendor
specific mechanism).

> 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.

Agreed. This needs to be a dynamic option that can only be used when the
client is actively trying to do WPS since this is used as a
semi-reliable mechanism for detecting whether more than one STA is
trying to do this at the time (and to reject requests if a potential
attacker is trying to do the same). WPS in push button mode is not
exactly a good example of a secure design..

> I think the WPS stuff should be an additional option to the scan command
> in the wpa_supplicant control interface, not a separate command.

This, I would assume, is just a misunderstanding on how WPS works. I
would expect wpa_supplicant to be asked to use WPS with a network, not
just to send out a specific Probe Request. Sure, internally
wpa_supplicant would then use the scan flag to indicate it is trying to
use WPS, but that part would not need a separate trigger from the
control interface. I'm now of course assuming that the WPS enrollee
would be integrated to the same process with wpa_supplicant and it would
not need to use control interface to request this special scan. I need
to see the patch from Ted to fully understand the design here, though.

-- 
Jouni Malinen                                            PGP id EFC895FA