WPS Technology for a WISP 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 enterprise or a WISP, you can deploy WPS technology by using IP filters for client computer isolation. In this circumstance, client computers are provided access to network resources, such as the provisioning server 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 a WISP network using IP filters are described, and how the components work together during new customer sign-up are detailed.

Components of WPS technology for a WISP using IP filters

When an ISP deploys Wi-Fi hotspots as a WISP, WPS technology can be configured with IP filters for client computer isolation during the account sign-up process.

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

Components of a WISP 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 WISP 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 server deployed on the WISP LAN. The wireless access points used 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 should 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 WISP IAS 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 and block access to all other locations.

Router

The router must provide multiple ports for connection to access points, the WISP LAN, and the Internet.

Provisioning server

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

Web application

The WISP Web server is configured with an account processing Web application that processes data provided during customer sign-up or account renewal. When a customer uses the sign-up wizard on a client computer to create and pay for a WISP account, the customer enters data, such as name, address, and credit card information, that is converted to an XML document on the client. Windows XP sends this XML document 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 master file and subfiles

The WISP provisioning server stores the XML master file and 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 the XML master file and subfiles, see “XML Schemas” in this paper.

Server certificate

For server authentication to client computers, the WISP 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. 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 using the sign-up wizard, 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 extension DLLs 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.

Extension DLL and URL PEAP-TLV

An IAS authentication 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 SP2 with the location of the WISP provisioning server. With this URL and parameter, 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.

Server certificate

For server authentication to client computers, the WISP IAS 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 is issued by a public certification authority (CA), such as Verisign or Thawte, that is trusted by client computers. 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.

DHCP server

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

How a WISP works using IP filters

The Internet connection process with WPS technology for a WISP 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 a WISP and establishes an account, the following four basic stages occur:

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

2. The customer authenticates as guest

3. The client is provisioned and the customer establishes an account

4. The customer is authenticated with the new account credentials

5. IP filters are removed and the customer gains access to the Internet

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

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

When a customer arrives at the WISP Wi-Fi hotspot with a portable computer running Windows XP Home Edition with SP1, Windows XP Professional with SP1, or Windows XP Tablet PC Edition with SP1, the computer comes within range of the WISP 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 WISP network through the access point, automatically passing a null user name and a blank password to the WISP IAS server.

The IAS server is the PEAP authenticator and TLS endpoint for customers who connect as guest, and the TLS tunnel is created between the client and the IAS server. All subsequent messages between client and server pass through this tunnel.

Server authentication is performed when the 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 certification authority (CA).

The IAS 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 provisioning server. This URL provides the client with the location of the XML master file.

The IAS 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 WISP provisioning server.

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

3.  The client is provisioned and the customer creates an account

The XML master file on the provisioning server contains pointers to the XML subfiles. Windows XP downloads the XML master file and subfiles. When the XML sign-up schema is downloaded, the sign-up wizard is launched 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. 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 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.

4.  The customer is authenticated with the new account credentials

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

Wireless Auto Configuration finds the correct 802.11 profile which was downloaded with the other WISP information. Wireless Auto Configuration re-associates with the access point 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 with PEAP-MS-CHAP v2 authentication, a TLS channel is created between the customer’s client computer and the WISP IAS server.

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

5.  IP filters are removed and the customer gains access to the Internet

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

You can determine the types of account plans that you want to offer your customers. These plans can range from fees based on hourly use to accounts with life spans 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 WISP, the customer chooses an access account 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 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 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 with the account credentials.

• During authentication with the 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.