Skip navigation

Guide for selecting equipment to implement Penn State Wireless

This Guide is intended to assist University network administrators in the selection of equipment to implement the next generation of wireless computing at Penn State.

Overview

The currently available ITS Wireless SecureNet service depends on the use of an ITS-provided Virtual Private Network (VPN) concentrator at each campus location to support the service, for both authentication and over-the-air encryption. Penn State Wireless will move both of these functions to the network edge, in which case access points or other wireless equipment installed in the future, whether by ITS or by administrative units choosing to deploy equipment themselves, will need to fulfill those functions. To accomplish this, the equipment used will need to have certain capabilities, based upon the architectural model chosen.

System Requirements

Wireless equipment vendors now provide a variety of network architecture models: a traditional standalone access point (sometimes called a “fat” access point), an intelligent wireless switch with “thin” access points, or a centralized controller with “thin” (or “fat”) access points. Penn State Wireless is not dependent on any particular architecture and can be compatible with any of these if they have the required capabilities. However, this development does make it difficult to discuss “access point” requirements, since some of the architectures distribute the functionality among several pieces of equipment. The administrative unit’s equipment must satisfy these requirements regardless of which piece of equipment implements each requirement. For the purposes of this document, we will refer to the totality of the administrative unit’s equipment as “the system.”

  1. The system must provide IEEE 802.11b and IEEE 802.11g connectivity. In addition, administrative units may choose to provide IEEE 802.11a connectivity.
  2. Initially, the system must implement encryption using the Temporal Key Integrity Protocol (TKIP). At some point in the future, the service will require encryption using the Counter mode with Cipher-block chaining with Message authentication code Protocol (CCMP) based on the Advanced Encryption Standard (AES) as described in IEEE 802.11i. Customers purchasing equipment now should ensure an upgrade path to AES-CCMP or plan to replace equipment in the future.1
  3. The system must be able to offer a minimum of two Service Set Identifiers (SSID): “pennstate” and “psu.”
  4. The system must broadcast the “pennstate” SSID.
  5. Systems that cannot broadcast more than one SSID are not required to broadcast the “psu” SSID.
  6. New systems should be able to broadcast both the “pennstate” SSID and the “psu” SSID.
  7. The system must be able to provide a unique Basic Service Set Identifier (BSSID)2 for each SSID.
  8. The system must be able to specify an authentication method per SSID.
  9. The system must act as an IEEE 802.1X authenticator for the “psu” SSID.
  10. The system must support RADIUS as an IEEE 802.1X authentication server using Extensible Authentication Protocol (EAP) encapsulation over LAN (EAPOL) transport.3
  11. The system must provide sufficient logging to satisfy a security inquiry from Security Operations and Services (SOS).4
  12. The system must be able to assign client IP addresses, using DHCP, from one subnet for the “pennstate” SSID and for a separate subnet for the “psu” SSID. Some vendors may be able to implement this directly. Others may be able to implement it indirectly by statically assigning a unique VLAN to each SSID and assigning a unique subnet to each VLAN at the router interface. If an administrative unit chooses the latter method, the system must also be able to set the VLAN for the system address of the RADIUS traffic.

Frequently Asked Questions

  1. Q: Why is ITS modifying the wireless service?

    A: While the existing ITS Wireless SecureNet service provides secure, authenticated access, it creates issues for certain administrative units:

    • It does not allow connection to administrative unit owned VPN Concentrators.
    • It creates a bottleneck for all wireless traffic at the VPN Concentrator.

    ITS is taking advantage of advances in technology to offer a system that provides authentication, adequate data confidentiality, and improved performance.

  2. Q: My users cannot authenticate with 802.1X. Will the existing service continue to be offered?

    A: Support for the existing VPN-based service is included within Penn State Wireless during a transition period. Users will continue to be able to use it for the duration of the transition.

  3. Q: How long is the transition period? How long will the VPN Concentrator be available?

    A: While the lifespan of a piece of equipment is not entirely within the control of ITS, we currently envision retaining the VPN Concentrator at least until July 2008.

  4. Q: When will the service transition to AES encryption?

    A: ITS will monitor the adoption rate of client equipment that can support AES encryption and periodically evaluate transitioning to AES encryption.

  5. Q: My department wants to provide Penn State Wireless to our users, but we do not want to design and maintain our own network. What options are available to us?

    A: ITS will continue to provide an option to obtain a TNS designed and maintained network for those administrative units who desire a turnkey solution.

  6. Q: How does SOS handle security incidents within Penn State Wireless?

    A: The goal of SOS is to contact the user directly with instructions on what they need to do and where to get help. In order to do this, SOS needs sufficient information to identify the user.

    If the network in question uses the ITS DHCP service, SOS can get all of the information it needs from the ITS RADIUS and DHCP logs. In this case, the only contact with the network administrator would be to notify them as a courtesy that the incident occurred. In this case, you may specify SOS as the security contact.

    On the other hand, if the network in question uses a DHCP server run by the administrative unit, SOS would need to contact the network administrator with an IP address and time to obtain the MAC Address from DHCP logs for user identification. For most incidents, SOS requests log information be returned within a day of the request, though critical incidents may require immediate user identification. Contact security@psu.edu for more information on the data retention requirements for DHCP servers run by administrative units.

  7. Q: Who handles user support issues within Penn State Wireless?

    A: The administrative unit specifies the group that will handle user support issues when they register the network. The default, and preferred, user support group in the registration system is the ITS Help Desk. However, administrative units may specify a group within their own organization if there is a particular desire to do so.

  8. Q: If the ITS Help Desk handles user support issues, why do I need to provide my network administrator contact information?

    A: If, in the process of working with a user, the ITS Help Desk determines that a network issue is likely, they will notify the network administrator contact directly. Only the ITS Help Desk and existing network administrators can see this information. Ordinary users cannot see the subnet or contact information.

  9. Q: Why do I have to use the ITS RADIUS server for Penn State Wireless?

    A: There is a trivial exploit allowing anyone — including people not associated with Penn State — to steal Penn State user IDs and passwords. In order to circumvent this exploit, ITS has configured the IEEE 802.1X client software to only trust the ITS RADIUS server when using the “psu” SSID. The supplicant only allows the specification of one server or DNS zone, so others cannot be added.

1 The Wi-Fi Alliance refers to the combination of IEEE 802.1X authentication with TKIP encryption as Wi-Fi Protected Access-Enterprise (WPA-Enterprise) and to the combination of IEEE 802.1X authentication with AES encryption as WPA2-Enterprise. Wi-Fi® and Wi-Fi Alliance® are registered trademarks of the Wi-Fi Alliance. WPA™ and WPA2™ are trademarks of the Wi-Fi Alliance.

2 Media Access Control (MAC) Address

3 The system must authenticate users associating with the “psu” SSID against an ITS authentication server. If an administrative unit wishes to provide an additional SSID using authentication to an administrative unit authentication server, the equipment must be able to assign an authentication server per SSID.

4 Identification of a user given an IP address and date/time is required in the event of a security incident. Typically, administrative units authenticating to RADIUS can accomplish this by coordinating RADIUS logs, DHCP logs, and the RADIUS Accounting start and stop records. However, there are means to bypass this typical identification process, such as the use of static IP address assignment by the end user. Procedures must be in place to ensure user identification can be accomplished in all instances.

Presented to University IT Directors and Managers by Steve Updegrove, Senior Director, Telecommunications and Networking Services, ITS; February 14, 2006.

Updated by the ITS Wireless Committee, May 2, 2006.

Go to Penn State Wireless Home Page.