Microsoft's Windows XP Service Pack 2 will be available soon, but they've got a little tweaking to do on their technical documentation: This page explains to developers how Wireless Provisioning Service (WPS) works. Never mind the fact that Service Set Identifier (SSID) is described as the Secure Set Identifier. More importantly, they overstate the current risk level for gateway-page logins at hotspots, a problem that WPS bypasses (with all Microsoft server and client components):

The current connection model for WISP signup and use is not secured. Most Wi-Fi hotspots are configured for open authentication and without data encryption. Users are generally required to launch a Web browser to initially sign up to the WISP service and for subsequent logins. WSP mitigates this threat by adding encryption and authentication to the communications between the client and the wireless network.

No, Mr. Gates, no, no, no. All authentication gateway pages I've visited are SSL-based, meaning that encryption (but not authentication) is already in the transaction. I don't know where they got the most from.

The SSL certificate has to be signed by an approved certificate authority, or a client's Web server would balk, and I haven't seen that kind of self-signed certificate problem that would allow man-in-the-middle attacks. (That is, if you were expecting to be warned about a self-signed certificate, then you might accept even a fake AP's certificate. But if you weren't expecting it, you probably wouldn't accept it.)

Browser based deployment is vulnerable to man-in-the-middle attacks, for example, by a malicious front-end server using a rogue access point. Users queried by this access point might unknowingly be giving away personal identification and credit card information. By eliminating the need for a Web login WSP reduces the vulnerability of WISP users to this type of attack.

This is definitely one of the coolest authentication elements of WPS. The transaction between XP SP2's WPS client and a WPS-equipped hotspot involves quite a lot of quasi-out-of-band confirmation. For instance, an SSL tunnel that's opened in one stage of the authentication is signed by a certificate authority already authorized in the WPS client. (So what's good for the goose should be good for the gander, above, in terms of Microsoft's characterization of hotspot authentication weakness currently.)

Without additional hotspot client software users can not easily detect hotspots and do not have a unified mechanism to sign up to them. It is not easy for users to find out information about the WISP or search for the hotspot locations for that WISP. If users sign up at one hotspot, they are not necessarily configured to automatically use the other hotspots. In addition, there is no standard mechanism to keep their provisioning and configuration information up-to-date.

Of course, this means that Microsoft expects its proprietary, single operating system with service pack, back-end requiring system to solve that problem--the unified mechanism is unified Microsoft software. I'm curious if they'll publish WPS as an open standard that could be overlaid onto FreeRADIUS and Open1x, for instance.

Add-on hotspot client software can help the user access that specific WISP’s network. However, add-on software can also conflict with the wireless services native to the operating system, or client software from other providers potentially causing interoperability problems, even instability of the system as they all attempt to control the wireless settings of entire system. Updates to the WISP configuration usually require updates to the client software. For these reasons, many corporate IT departments are reluctant to deploy 3rd party hotspot client software to their users.

Can I get a hallelujah? Praise Bill! This is part of the secret sauce that iPass and GoRemote bring to the table of the corporate enterprises they primarily serve. They customize their client software, and provide IT support for a unified platform that has security advantages, including policy enforcement (firewall must be on, VPN must be on, and other choices and combinations). Client software provided by other firms, like Sprint PCS's client (based on iPass's), isn't supported at the corporate level in the same way that iPass is: individual users can download and install it, and the authentication is through Sprint PCS's servers (in that case), not through an enterprise's existing authentication infrastructure, as iPass's is.

Now, don't get me wrong. WPS is a very interesting product, and we have to wait and see whether it gains real acceptance beyond those hotspot operators who have interest in the co-marketing dollars or other funds that Microsoft will surely offer. WPS as an idea--allowing a third-party authentication of a certificate coupled with XML-based transfer of standardized data--is a good one, and one that only the largest operating system seller in the world is in a position to distribute on the client side.

In addition to WPS, XP SP2 will include a wizard that will allow simple passing of Wi-Fi configuration information on multiple computers. This seems like a natural outgrowth of Microsoft's now-discontinued home Wi-Fi equipment's configuration tool, unique in encouraging a WEP key and unique in making it easy to configure other machines with the same key (albeit using a floppy disk).

The Wireless Network Setup Wizard provides a means for a Windows user to easily create and propagate network settings using an Extensible Markup Language (XML) schema and removable media.  In the future this XML schema may also be used to transfer settings for wide area networks (WANs), local area networks LANs, as well as wireless LANs (WLANs). However, the XML files created by the Wireless Network Setup Wizard for Windows XP SP2 will only be used to transfer configuration settings for WLANs.