WPS Technology for an HSP with IP Filters

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

If your organization is an HSP, you can deploy WPS technology by using IP filters for client computer isolation. In this circumstance, client computers are provided access to HSP and WISP network resources, such as provisioning servers and IAS servers, and IP filters block access to the Internet until the customer establishes a paid account. After the account is established, the IP filters are lifted, and traffic is allowed between the client computer and the Internet.

In the sections that follow, the components of an HSP network using IP filters are described, and how the components work together during new customer sign-up are detailed.

Components of WPS technology for an HSP network using IP filters

A Hotspot Service Provider (HSP) can deploy WPS technology with IP filters for client computer isolation during the account sign-up process.

The following illustration depicts the components of an HSP network using IP filters for client computer isolation.

Components of an HSP network using IP filters

This configuration consists of the following components.

Wireless client

A computer running Windows XP Home Edition with SP2, Windows XP Professional with SP2, or Windows XP Tablet PC Edition with SP2. The wireless client connects to the HSP network, which is in a public location and is accessible to customers with portable computers and wireless network adapters.

Wireless access point (RADIUS client)

The wireless access point is configured as a RADIUS client to the IAS proxy server deployed on the HSP LAN. The wireless access points used by an HSP for WPS technology must meet the following requirements:

• Support for the IEEE standard 802.1X authentication.

• Support for Wi-Fi Protected Access (WPA) is preferred

• The ability to implement client isolation by applying IP filters to the connection with the client.

• Support for RADIUS authentication and RADIUS accounting, including:

  • Support for the Class attribute as defined in RFC 2865, “Remote Authentication Dial-in User Service (RADIUS),” to allow session correlation for RADIUS authentication and accounting records. For session correlation, when you configure RADIUS accounting at your IAS server or proxy, you must log all accounting data that allow applications (such as billing applications) to query the database, correlate related fields, and return a cohesive view of each session in the query results. At a minimum, to provide session correlation, you must log the following IAS accounting data: NAS-IP-Address; NAS-Identifier (you need both NAS-IP-Address and NAS-Identifier because the access server can send either attribute); Class; Acct-Session-Id; Acct-Multi-Session-Id; Packet-Type; Acct-Status-Type; Acct-Interim-Interval; NAS-Port; and Event-Timestamp.

  • Support for accounting interim requests, which are sent periodically by some access servers during a user session, that can be logged. This type of request can be used when the Acct-Interim-Interval RADIUS attribute is configured to support periodic requests in the remote access profile on the IAS server. The access server, in this case a wireless access point, must support the use of accounting interim requests if you want the interim requests to be logged on the IAS server.

  • Support for IP address range filtering.

  • Support for dynamic retransmit timeout (RTO) estimation or exponential backoff to handle congestion and delays in a wide area network (WAN) environment.

In addition, there are some filtering features that the access points must support to provide enhanced security for the network. These filtering options include:

• DHCP filtering. The access point must filter on IP ports to prevent the transmission of DHCP broadcast messages in the instance that the client is a DHCP server. The access point must block the client from sending IP packets from port 68 to the network.

• DNS filtering. The access point must filter on IP ports to prevent a client from performing as a DNS server. The access point must block the client from sending IP packets from port 53 to the network.

IP filters

IP filters that isolate client computers connecting as guest are configured in the remote access policy on the HSP IAS proxy server, and are applied to the client connection by the wireless access point. The IP filters must grant the client computer access to the provisioning server at the HSP and the WISP, and must block access to all other locations.

Router

The router must provide multiple ports for connection to access points, the HSP LAN, and the Internet or a WISP, depending on your configuration.

HSP LAN

The HSP local area network (LAN) consists of the following components.

Provisioning server

The HSP provisioning server is configured with the following components.

HTTPS Web server

The Internet Information Services (IIS) or third-party Web server must be deployed with HTTPS.

HSP XML master files

HSP XML master files are stored on the HSP provisioning server. Because an HSP can provide customers with a choice of Internet access plans with a variety of WISPs, one XML master file is configured at the HSP and stored on the HSP provisioning server for each WISP available to HSP customers. Each HSP XML master file contains a master XML schema that describes a list of URLs to other XML documents, which are XML subfiles stored on WISP provisioning servers. The XML master schema also describes properties of the WISP for which the XML master file was created and the Time-To-Live (TTL) for the XML master file before it is updated by the HSP provisioning server from the WISP provisioning server. The XML master file schema is:

• The domain name of the WISP. For example, if Microsoft Corporation is the WISP, the domain name is “microsoft.com.”

• The friendly name of the WISP. For example, Microsoft Corporation.

• The TTL for the XML master file. When client computers connect to the HSP provisioning server and download the master file, the TTL value tells Wireless Provisioning Services on the client computer when to request an update of the master file from the HSP provisioning server.

• The list of URLs that point to XML subfiles. The XML subfiles are located on the WISP provisioning server for which the XML master file was created. Only HTTPS URLs are supported for use within the XML schema, and by WISP provisioning servers. The name of the XML schema described in the subfile is included, as is the version number for the subfile. Possible subfile names include: Signup, SSID, EAP, Location, and Help. For more information, see “XML Schemas” in this paper.

Server certificate

For server authentication to client computers, the provisioning server must maintain a valid certificate in its certificate store. The certificate must contain the Server Authentication purpose in Enhanced Key Usage (EKU) extensions and be issued by a public certification authority (CA), such as Verisign or Thawte, that is trusted by client computers connecting to the HSP wireless LAN. The Trusted Root Certification Authorities certificate store on computers running Windows XP is installed by default with a multitude of certificates issued by public CAs. You must obtain your server certificate from one of the public CAs for which clients already have trust.

IAS proxy server

The HSP IAS proxy server is configured with the following components.

Internet Authentication Service (IAS)

The IAS proxy server must be a computer running Windows Server 2003, Standard Edition with Service Pack 1 (SP1); Windows Server 2003, Enterprise Edition with SP1; or Windows Server 2003, Datacenter Edition with SP1; and Internet Authentication Service (IAS). IAS is the Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) proxy and server.

The IAS proxy functions both as an IAS proxy and as an IAS server. The IAS proxy server is configured to locally process connection requests for users that authenticate as guest, and to forward non-guest authentication and accounting requests to the IAS servers located at individual WISPS based on the realm name configuration specified in Connection Request Policies in the IAS console.

On the IAS proxy, the IAS servers at each WISP are added to a remote RADIUS server group, with a minimum of one remote RADIUS server group created for each WISP. Because Windows Server 2003, Standard Edition, permits the creation of only two remote RADIUS server groups, an HSP offering Internet connectivity to more than two WISPs must deploy IAS proxies and servers running Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition.

Server certificate

For server authentication to client computers, the provisioning server must maintain a valid certificate in its certificate store. The certificate must contain the Server Authentication purpose in Enhanced Key Usage (EKU) extensions and be issued by a public certification authority (CA), such as Verisign or Thawte, that is trusted by client computers connecting to the HSP wireless LAN. The Trusted Root Certification Authorities certificate store on computers running Windows XP is installed by default with a multitude of certificates issued by public CAs. You must obtain your server certificate from one of the public CAs for which clients already have trust.

DHCP server

The DHCP server must be able to assign valid public IP addresses to computers accessing the network through the wireless access points.

WISP 1 LAN

The WISP 1 LAN is configured with the following components.

Provisioning server

The WISP provisioning server is configured with the following components.

HTTPS Web server

Like the HSP Web server, the WISP Web server must use HTTPS. The WISP provisioning server stores XML subfiles that are downloaded over HTTPS by client computers running Windows XP with SP2.

Web application

The WISP Web server is configured with an account processing Web application. When a customer uses the sign-up wizard on the client computer to create and pay for an account, the customer enters data, such as name, address, and credit card information, that is converted to an XML document and sent to the WISP provisioning server.

The account processing Web application on the provisioning server must be capable of accepting and processing the XML documents containing the user data. For example, the account processing Web application must dynamically create an account in the Active Directory user accounts database, and must contain a credit card verification component to process customers’ payment information. The account processing Web application must permit new customers to sign up and to permit existing customers to renew their subscriptions for service.

XML subfiles

The WISP provisioning server maintains the XML subfiles that provide the client with all configuration information needed to access the network, create an account, pay for the account, and ultimately access the Internet. For more information about XML subfiles, see “XML Schemas” in this paper.

Server certificate

For server authentication to client computers, the provisioning server must maintain a valid certificate in its certificate store. The certificate must contain the Server Authentication purpose in Enhanced Key Usage (EKU) extensions and be issued by a public certification authority (CA), such as Verisign or Thawte, that is trusted by client computers connecting to the HSP wireless LAN. The Trusted Root Certification Authorities certificate store on computers running Windows XP is installed by default with a multitude of certificates issued by public CAs. You must obtain your server certificate from one of the public CAs for which clients already have trust.

Domain controller and IAS server

The WISP domain controller and IAS server is configured with the following components.

Active Directory

The user accounts database on the domain controller must be an Active Directory user accounts database or a database that uses Lightweight Directory Access Protocol (LDAP) and supports dynamic creation of user accounts. When a customer signs up for an account, the account processing Web application on the provisioning server creates a new account in the user accounts database, and adds the user to a group that has clearly defined access privileges that match the type of account the customer purchased when signing up.

If you use an accounts database other than Active Directory, IAS authentication and authorization extensions must be written and installed for this process to function correctly.

For information about configuring Active Directory replication, see “Active Directory Replication” in this paper.

Internet Authentication Service (IAS)

IAS is the Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy, and is used to authenticate and authorize users connecting to your network. IAS is configured with remote access policies that allow guest authentication for non-domain member computers and users. It is also configured to provide IP filters to RADIUS clients (access points) that apply the filters to client connections during guest authentication. IAS also provides unrestricted access to users with valid accounts.

Server certificate

For server authentication to client computers, the provisioning server must maintain a valid certificate in its certificate store. The certificate must contain the Server Authentication purpose in Enhanced Key Usage (EKU) extensions and be issued by a public certification authority (CA), such as Verisign or Thawte, that is trusted by client computers connecting to the HSP wireless LAN. The Trusted Root Certification Authorities certificate store on computers running Windows XP is installed by default with a multitude of certificates issued by public CAs. You must obtain your server certificate from one of the public CAs for which clients already have trust. If you install IAS and Active Directory on the same computer, the computer must have a certificate. If you install IAS and Active Directory on different computers, only the IAS server needs a certificate.

Extension DLL and URL PEAP-TLV

An IAS extension DLL defining a URL PEAP-TLV provides IAS with the ability to send the location of the provisioning server to client computers.

PEAP-Type-Length-Value (PEAP-TLV) is an Extensible Authentication Protocol (EAP) authentication type that allows the IAS server to pass information to client computers attempting to connect to your network.

In this circumstance, the value contained in the PEAP-TLV is an HTTPS Uniform Resource Locator (URL) that provides client computers running Windows XP with the location of the WISP provisioning server. With this URL, Windows XP can download the WISP XML files to the client computer.

In addition to the URL of the provisioning server, the URL PEAP-TLV includes an action parameter. The action parameter directs the client to perform a specific task.  The action parameter included in the URL PEAP-TLV defines tasks such as new customer sign-up, existing account renewal, and password change.

For more information, see “How to Create an IAS Extension DLL and a URL PEAP-TLV” in this paper.

WISP 2 LAN

The WISP 2 LAN is identical to the WISP 1 LAN described above, and is depicted in “Components of an HSP network using IP filters” to illustrate that an HSP can provide service offers to customers from multiple WISPs.

How an HSP works with IP filtering

The Internet connection process with WPS technology for an HSP with IP filtering differs depending on whether the customer attempting to connect is a new customer or an existing customer. The following example describes the process for a new customer. In addition, how IAS handles an expired account is explained.

New customer connection example

When a new customer connects to an HSP and establishes an account with a WISP, the following five basic stages occur:

1. The customer discovers the HSP network at a Wi-Fi hotspot

2. The customer authenticates as guest

3. The client is provisioned with the HSP XML master file

4. The customer selects a WISP and establishes an account

5. The customer is authenticated with the new account credentials

In the next section we will look at these stages in more detail.

1.  The customer discovers the HSP network at a Wi-Fi hotspot

When a customer arrives at the HSP hotspot with a portable computer running Windows XP Home Edition with SP2, Windows XP Tablet PC Edition with SP2, or Windows XP Professional with SP2, the computer comes within range of the HSP access point beacon.

The Wireless Auto Configuration service on the client computer detects the beacon information from the access point, which is enabled with broadcast Secure Set Identifier (SSID). The SSID is equivalent to the network name.

The customer is informed by Windows XP that a wireless network is available. The customer views information in Windows XP, and if interested, the customer clicks Connect.

2.  The customer authenticates as guest

Wireless Auto Configuration uses 802.1X and PEAP guest authentication to connect to the HSP network through the access point, automatically passing a null user name and a blank password to the HSP IAS proxy.

The IAS proxy is configured both as a proxy and as an IAS server. The IAS proxy/server is configured to locally process users that authenticate as guest, and to forward other messages to the WISP IAS servers based on the value of the User-Name attribute in the Access-Request message.

The HSP IAS proxy server acts as an IAS server for guest authentication, processing these requests locally rather than acting as a proxy and forwarding them. The HSP IAS proxy server is therefore the PEAP authenticator and TLS endpoint for customers who connect as guest, and the TLS tunnel is created between the client and the HSP IAS server. All subsequent messages between client and server pass through this tunnel.

Server authentication is performed when the HSP IAS server verifies its identity to the client computer using a certificate that contains the Server Authentication purpose in Enhanced Key Usage (EKU) extensions. This certificate is issued by a public trusted root CA.

The HSP IAS proxy server authenticates and authorizes the customer as guest. In the Access-Challenge message that the IAS server sends to the client is a URL PEAP-TLV. The URL PEAP-TLV is a container with a value that is the URL of the HSP provisioning server. This URL provides the client with the location of the HSP XML master file.

The HSP IAS proxy server also sends IP filters in the form of Vendor Specific Attributes (VSAs) to the access point. These IP filters are applied to the client connection by the access point and are used to isolate the client; the filters block access to all network resources except the HSP provisioning server and the WISP provisioning servers.

The customer client computer receives an IP address lease from the HSP DHCP server. The address is from a public IP address range configured in a scope on the DHCP server.

3.  The client is provisioned with the HSP XML master file

The HSP master XML file on the HSP provisioning server contains pointers to multiple WISP master XML files, which in turn contain pointers to each respective WISP’s XML subfiles. Windows XP downloads the HSP XML master file.

Windows displays to the customer a list of WISPs whose services are offered by the HSP.

For this example, the customer selects services from WISP 1.

4.  The customer selects a WISP

After the customer selects the WISP, Windows XP connects to the WISP and, using the Background Intelligent Transfer Service, downloads the WISP XML master file and subfiles. When the XML sign-up schema is downloaded, the sign-up wizard is opened on the client to allow the customer to create and pay for an account with the WISP.

Using the sign-up wizard on the client computer, the customer steps through the process of signing up for an account with WISP 1. The data entered by the customer is converted by Windows XP into an XML document.

The XML document containing the customer’s sign-up data is sent by Windows XP to the Web application on the WISP 1 provisioning server.

The Web application processes the customer payment information. Once payment is verified and sign-up information is completed successfully, the Web application creates a user account in Active Directory, and permissions are applied to the user account by assigning group membership based on the account type chosen by the customer.

An XML document containing the new account credentials is sent from the WISP provisioning server to the client computer. The client computer uses the credentials to configure Wireless Auto Configuration and 802.1X under the name of the WISP.

5.  The customer is authenticated using the new account credentials and gains Internet access

Wireless Auto Configuration restarts the association to the SSID for the HSP.

Wireless Auto Configuration finds the correct 802.11 profile which was downloaded with the other WISP information. Wireless Auto Configuration re-associates using the correct profile.

802.1X restarts the authentication process using PEAP-MS-CHAP v2 and the new account credentials.

As the client starts the authentication process, the HSP IAS proxy forwards messages between the client and the WISP IAS server. The connection request policies on the HSP IAS proxy are configured to forward requests to WISP 1 where the ISP’s name exists in the realm portion of the RADIUS User-Name attribute. For example, if “user@wisp1.example” is the user name, the IAS proxy server uses the realm portion of the user name, “wisp1.example,” to choose the IAS server that should receive the connection request.

In the first stage of PEAP-MS-CHAP v2 authentication, a TLS channel is created between the customer’s client computer and the WISP 1 IAS server.

In the second stage of PEAP-MS-CHAP v2 authentication, the WISP 1 IAS server authenticates and authorizes the connection request against the new account in the user accounts database. The WISP IAS server sends an Access-Accept message that is forwarded by the HSP IAS proxy to the HSP access point.

Because IP filters are used to isolate the client, the IAS server message causes the access server to remove the IP filters from the client connection, granting the customer access to the Internet.

How IAS handles an expired account

Each WISP that offers connectivity through an HSP can determine the types of account plans to offer customers. These plans can range from fees based on hourly use to accounts with lifespans as long as a day, a month, or longer.

It is important for IAS to determine whether a connecting or connected client computer has a valid account, and to take the appropriate action if the customer’s account is expired. The following example illustrates how IAS determines that a twenty-four hour account is current, and how WPS technology behaves when the account expires.

Twenty-four hour connect option example

When the customer arrives at the HSP, the customer chooses an access account with WISP 1 that has a one-day (24-hour) lifespan. The customer and client computer proceed through the account creation process described above, and then connect to the Internet. The following process occurs:

• In the Access-Accept message sent by the WISP 1 IAS server, the IAS server sets a session timeout of 60 minutes for the client computer connection to the access point.

• After 60 minutes, the access point requests that the client reauthenticate. The client reauthenticates successfully and the customer’s session is not interrupted.

• Each 60 minutes thereafter, the access point requests that the client reauthenticate. During each authentication the IAS server checks the current time against the expiry time for the user account to discover whether the customer is authorized to access the network.

• On the last re-authentication, at hour 23 in the account lifespan and before 24 hours have passed, the IAS authorization check fails and the IAS server sends a URL PEAP-TLV message to the client that contains the account renewal action parameter and an HTTPS URL for an XML master file. The URL PEAP-TLV supplies the customer with the location of the provisioning server where the customer can renew the account.

• Upon receiving the URL in the URL PEAP-TLV, 802.1X requests that Windows XP display the account renewal application to the customer.

• The customer renews the account and 802.1X initiates authentication using the account credentials.

• During authentication with the WISP 1 IAS server, the IAS server authenticates and authorizes the customer against the user accounts database, and sends an Access-Accept message containing a session timeout of 60 minutes to the access point.

• During this process, because the account has not expired, the customer maintains connection to the Internet.

If the customer does not complete the renewal process before the 24 hour account lifespan is reached, then the access point reapplies IP filters and customer access to the Internet is terminated. The customer is then provided with the option of renewing the account for continued access.