Optional Security Measures

 < Day Day Up > 



Most if not all of the preceding measures should be mandatory for all WLANs. But for comprehensive security within a wireless environment, you should also consider other security measures, such as:

  • Implementation of additional authentication procedures, e.g. dynamic session-based encryption keys that would be changed automatically at fixed intervals and on re-authentication.

  • Deployment of other forms of authentication for the wireless network, e.g. RADIUS and Kerberos.

  • Deployment of other authentication methods, e.g. biometrics, smart cards, two-factor authentication, or PKI.

  • Installation of Layer 2 switches in lieu of hubs for AP connectivity.

  • Deployment of IPsec-based VPN technology for wireless communications. Enhance AP management traffic security through the use of SNMPv3 or an equivalent cryptographically protected protocol.

  • Upgrading existing WLAN equipment so they can use WPA.

  • Deployment of intrusion detection sensors on the wireless part of the network to detect suspicious behavior or unauthorized access and activity.

Now let's look more closely at these optional network security measures.

WPA

As the reader should now understand, WEP is ineffective in securing confidential business communications. The IEEE 802.11i standard, a longer term security solution for wireless networking, has had several delays and is not expected to be ratified until toward the end of 2003. These delays caused several members of the Wi-Fi Alliance to team up with members of the IEEE 802.11i task group to develop a significant near-term enhancement to Wi-Fi's security. Together this team developed the Wi-Fi Protected Access (WPA) standard.

In November 2002, the Wi-Fi Alliance released WPA as an interim replacement for WEP and other aspects of Wi-Fi security. As an interim version of the IEEE's 802.11i security specification, WPA adopts TKIP-based fixes to WEP, adds the packet integrity upgrade, and introduces standardized support for 802.1X/EAP network authentication.

WPA is designed to run on existing hardware as a software upgrade. Plus, since it is derived from the IEEE 802.11i standard, WPA is designed to be forward compatible with 802.11i, once that standard is ratified. When properly installed, WPA can provide a high level of assurance that as network data traverse the airwaves, it will remain protected and that only authorized network users can access the network.

But what exactly does WPA offer? While no security solution can ever claim to be "absolutely secure," the protection that WPA provides is significant. In fact, many cryptographers are confident that WPA addresses all of WEP's known deficiencies.

WPA requires that clients and access points use a shared network password (technically called the "preshared secret"). But unlike the WEP's "passphrase," which merely converts ASCII into hexadecimal, the WPA password actually creates a cryptographic outcome that's sufficiently random so that breaking a key is an unlikely event. And because the implementer only needs to enter a password, this improves the likelihood it will be used. Still, it should be noted that WPA will fall back to WEP if even a single device on a network cannot use WPA.

Next, WPA uses Temporal Key Integrity Protocol (TKIP), which is part of the 802.11i specification. The IEEE 802.11i Task Group designed TKIP to distance the encryption key from the actual data by (1) performing several algorithms to the key before generating the encrypted data; (2) performing dynamic key management (i.e. changing the temporal keys frequently); and (3) performing message integrity checks (MICs) to prevent forgery and replay.

WPA, therefore, constructs encryption keys differently.

WPA also employs the IEEE 802.1X access control protocol (which is usable on wired networks as well). Although 802.1X requires special server software, that software is commonly found in most corporate networks. However, since WPA uses TKIP in addition to the 802.1X access control protocol, it still can be used to improve the security in home and small-office networks that don't use such servers.

Besides products from the aforementioned vendors, Cisco's AIR AP1230B access point, Intel's Pro/Wireless 2100 LAN 3B Mini-PCI Adapter (used in Centrino notebooks), and Symbol's Wireless Networker CompactFlash Wireless LAN Adapter Model LA-4137 have received the Wi-Fi Alliance's WPA certification. In the near future, WPA certification will be a standard aspect of Wi-Fi certification.

Furthermore, the Wi-Fi Alliance supports WPA with a certification program. The Alliance announced in late April 2003 that nine products from six vendors had been certified as meeting the specifications for WPA. Out of those six companies—Atheros, Broadcom, Cisco, Intel, Intersil, and Symbol—three are Wi-Fi chip vendors (Atheros, Broadcom, and Intersil) and together they supply the chips for most Wi-Fi network cards and access points. That means that the vendors whose Wi-Fi components use those chipsets can produce WPA compliant products very quickly.

Moreover, most vendors are expected to provide WPA security for their existing installed product base, through downloadable software updates. If you have an existing WLAN, check your vendors' websites to see if updates are available. Note that if you do upgrade your WLAN or build an additional WLAN around WPA security, and your organization is also using older Wi-Fi gear that isn't upgradable, that gear will not be able to access the WPA-secured network. And if the legacy gear is allowed to access a WPA network, the WPA-enabled gear will revert to its old WEP ways.

The WPA effort also has been driven by the need for enhanced Wi-Fi security that would be software-upgradeable to the more than 490 Wi-Fi certified products in existence today. Since after 802.11i is ratified, obtaining all of the advantages of the full IEEE 802.11i standard likely will require a hardware change, WPA will have a place in the Wi-Fi security picture for the near future.

The concern with WPA, though, is how such an upgrade will affect organizations that use, or want to deploy, network authentication. EAP, which is the most prevalent authentication method in use today, is not a secure protocol—it sends its messages as cleartext. While a method of tunneling EAP using TLS (Transport Layer Security) is available, it requires installing client certificates on every computer that wants to connect. And even TLS leaves some information in the clear, which potential intruders might find useful. Nonetheless, an EAP/TLS combo offers mutual authentication in which the client and authentication server can verify each other's identity before the transaction starts.

A fix to this problem is in the works. It is referred to as "EAP-TTLS," "Tunneled TLS," or just "TTLS." This solution allows the computing device first to connect using a generic TLS connection to the server, and only after the connection is obtained does it send its user information to start an EAP/TLS session, i.e. encryption is tunneled within encryption.

Another aspect of TTLS is that in addition to EAP, it supports several older messaging standards. As of this writing, TTLS is in draft form at the Internet Engineering Task Force (IETF). However, client software is available for most major platforms, including OS X, all Windows flavors, Linux, and several commercial versions of Unix.

TTLS isn't the only method available to secure EAP transactions. Microsoft and Cisco are pushing PEAP (Protected EAP). This solution uses an approach that is almost identical to the TTLS method, but it only supports EAP and CHAP, an older Microsoft authentication protocol. PEAP is also in front of the IETF. Microsoft has shipped PEAP updates to Windows XP and 2000, and is expected to follow with Windows 98 (both versions), NT 4.0, and ME.

In the ideal world, the two standards would merge into a single one. Whether that occurs is anyone's guess. Microsoft's lack of support for non-EAP protocols could be a way for the software giant to push users away from other authentication systems.

Public Key Infrastructure (PKI)

Consider PKI for networks or end-users requiring high levels of security. This comprehensive system provides public key encryption and digital signature services through a framework of services for the generation, production, distribution, control, and accounting of public key certificates. The purpose of PKI is to manage keys and certificates (also known as digital IDs) that are used for identification, entitlements, verification, and privacy. By managing keys and certificates through PKI, an organization establishes and maintains a secure and trustworthy networking environment. In the past few years, PKI technology has become the preferred means for providing stronger levels of identification, privacy, verification, and security management capabilities.

Since PKI provides strong authentication through user certificates, users can use those same certificates with application-level security, such as signing and encrypting (i.e., using encryption certificates) messages. Thus PKI provides applications with secure encryption, and authenticates network transactions as well as data integrity and non-repudiation.

It wouldn't be too difficult for WLANs to integrate PKI into their ecosystem for authentication and secure network transactions. Third-party manufacturers, for instance, provide wireless PKI, handsets, and smart cards that integrate with WLANs. Smart cards could provide even greater utility (e.g., portability, mobility) since the certificates are integrated in the card. Users requiring lower levels of security, on the other hand, need to consider carefully the complexity and cost of implementing and administering a PKI before adopting this solution.

RADIUS

RADIUS (Remote Authentication Dial-In User Service) is an IETF security management protocol that lets you easily control which remote and/or wireless LAN users connect to your network, and what resources they can access. While RADIUS isn't an official standard, the RADIUS specification is maintained by a working group of the IETF.

A RADIUS server authenticates dial-in users on a network. For example, when you log into your favorite ISP, the remote access server you talk to sends your login info to a RADIUS server which answers with your rights and configuration details. If your password is wrong, you won't be able to log in.

RADIUS is a widely deployed protocol for network access authentication, authorization and accounting (AAA). And even though RADIUS has problems relating to issues with security and transport, RADIUS is a part of the 802.11i specification. This is primarily due to the fact that RADIUS is simple, efficient, and easy to implement—making it possible for RADIUS to fit into the most inexpensive embedded devices. Furthermore, the issues with transport are most relevant for accounting in situations where services are billed according to usage. This is because RADIUS runs on UDP, with no defined retransmission or accounting record retention policy, and does not support Application Layer acknowledgments or error messages. As a result, usage-based billing is often done with SNMP, which also runs over UDP, although a TCP transport mapping has been developed.

In terms of security, RADIUS offers some Application Layer security such as:

  • Trust established between RADIUS clients and servers via a shared secret, which is an encryption key used by RADIUS to send authentication information over a network.

  • Support for per-packet integrity and authentication.

  • Support for hiding of specific attributes such as User-Password, Tunnel-Password and Microsoft Vendor Specific Attributes.

But RADIUS security is particularly poor when dealing with the cleartext Password Authentication Protocol (PAP). IETF's RFC 2865 document requires that the RADIUS Response Authenticator be globally and temporally unique, since the stream cipher that RADIUS uses to encrypt User-Password is based on the Response Authenticator, and thus if it were to repeat, the keystream would be compromised. And, unfortunately, not all implementations of RADIUS ensure that the Response Authenticator is not repeated.

Furthermore, the RADIUS Response Authenticator and Message-Authenticator attributes are both vulnerable to dictionary attack. And simple shared secrets are commonly shared with many or even all network access servers.

Note 

A network access server, commonly referred to as a "NAS," is a computer or a special device designed to provide access to the network. For example, a NAS can be a computer connected to the network and equipped with several modems to allow outside end-users to access the network. Also services, such as PPP, SLIP, telnet, etc., use a NAS.

Here are a few steps you can take to lessen RADIUS's security vulnerabilities:

  • To make an attack against the User-Password impossible, don't allow PAP.

  • Use a credible generator for Request Authenticator as described in IETF RFC 1760.

  • Include a Message-Authenticator attribute in all packets (RFC 2869 already requires this for EAP authentication).

  • If possible, use authentication methods that offer protection against an offline dictionary attack. These include the aforementioned EAP TLS or two methods that are still under development—EAP SRP (Secure Remote Password) and PEAP (Protected Extensible Authentication Protocol).

  • Use high-entropy shared secrets (i.e. don't limit shared secrets to 16 characters and utilize randomly generated shared secrets).

  • Use a different shared secret for each RADIUS client-server pair.

  • If the network access servers can support IPsec, then the best thing to do is to forsake RADIUS Application Layer security entirely and just run RADIUS over IPsec ESP (Encapsulating Security Payload) with a non-null transform, as described in IETF RFC 3162. This method supports per-packet integrity, authentication, confidentiality, and replay protection for both authentication and accounting packets. Unfortunately, many embedded systems do not have sufficient resources to run IPsec, so RADIUS/IPsec is not widely used.

Kerberos

Developed by MIT, the Kerberos security system helps to prevent individuals from stealing information that gets sent across the wires from one computer to another.

The name "Kerberos" comes from the mythological three-headed dog whose duty it was to guard the entrance to Hell. Kerberos guards the "entrance" to a network by encrypting the data so that only the computer that's supposed to receive the information can unscramble it.

Kerberos authenticates users by way of exchanging electronic tickets between clients and services. It cleverly encrypts and de-encrypts these tickets before and after transmitting them. The "heart" of a Kerberos system is the Key Distribution Center (KDC). All the computers associated with a KDC make up what's called a "strengthened realm"

With Kerberos, by exchanging time-sensitive tickets, you can make transactions secure without sending passwords in plaintext over the network. For a program to take advantage of Kerberos, it must be Kerberized, which basically means that it can obtain tickets from the Kerberos server and negotiate with a Kerberos-aware service. Just about any application can be Kerberized, and just about any computer service can be made Kerberos-aware.

Although Kerberos is a fairly complex protocol, here are a few basic characteristics:

Every user and every service has a password. Only the owner of the password and the Kerberos server know that password. (Passwords, however, must remain confidential, as Kerberos provides no inherent protection against those that are stolen.)

Kerberos works by providing a "principal" (which represents the end-user or a computerized service), "tickets" that can be used to identify that end-user or service to other principals, and "secret cryptographic keys" (like passwords) for secure communication with other principals. These tickets are similar to a personalized business card that only the principal can have, because the principal must provide its Kerberos password to get the tickets from the Kerberos server (also known as the Key Distribution Center, KDC).

A computer service that uses Kerberos receives its own ticket when the service is set up. A person requesting use of a "kerberized" service must obtain his or her own tickets by using a Kerberos initialization program called "kinit", and by providing kinit with his or her Kerberos password. When a person requests to use a kerberized service (usually a program on a personal computer which communicates with a server somewhere on the network), the program sends the ticket obtained from kinit to the computer service. The computer service inspects the user's ticket in conjunction with its own to make sure it is valid. If the ticket passes inspection, the service is confident that the person who sent the ticket is truly who and where (which computer) he or she claims to be. Conversely, the service, providing its own ticket for inspection, inherently proves its own identity. Both sides of the communication are now authenticated to each other and can securely exchange information.

Biometrics

If security is an absolute top priority for a networking environment, consider biometric solutions. Biometric devices include fingerprint/palm-print scanners, optical scanners (including retina and iris scanners), facial recognition scanners, and voice recognition scanners. Biometrics provides an added layer of protection when used either alone or along with other security solutions. For example, for organizations needing higher levels of security, biometrics can be integrated with wireless smart cards or wireless laptops or other wireless devices, and used in lieu of username and password to access a wired or wireless network. Additionally, biometrics can combine with VPN solutions to provide authentication and data confidentiality.

VPNs

You may think that a simple solution to WLAN security exists in the form of VPN technology, and some organizations do implement generic VPNs to provide wireless LAN security. But there are a number of new products that can enhance VPN capabilities to meet wireless networking's unique needs. In some cases, this may involve more sophisticated policy-based access controls. In other instances, it may include supporting VPN access while users roam between access points, not only on the same subnet but also between subnets, with session-persistence capabilities to ensure that applications are not interrupted.

Even though VPNs may solve key problems associated with WLAN security, they aren't a panacea—at least not yet.

VPN gateways are implemented within many organizations at the boundary of the enterprise LAN and the Internet, to provide secure data transmission across public network infrastructures. In recent years VPNs have allowed organizations to harness the power of the Internet for remote user access (dial-up, DSL, cable-modem). Today, VPNs typically are used in three different scenarios: remote user access, LAN-to-LAN (site-to-site) connectivity, and extranets. These VPNs are designed to provide authentication and privacy, some also can be integrated with firewall software to control access, and other VPN products come with traffic-shaping software to limit bandwidth consumption by application, user, or group.

The VPN / WLAN Connection

When VPNs are used in a WLAN environment, they provide data privacy via strong encryption to prevent eavesdropping, and facilitate authentication of wireless stations and their users. VPNs can employ simple user names and passwords in a Remote Authentication Dial-In User Server (RADIUS) directory to more sophisticated digital certificates and public key techniques; and cryptographic techniques to protect IP information as it passes from one network to the next, or from one location to the next. By the act of encapsulation and encryption of one protocol packet inside another, isolating those packets from other network traffic, you create a "VPN tunnel," which is how a VPN protects data as it traverses various network byways, including the Internet.

VPNs are commonly implemented to up a WLAN's security quotient, although VPNs can present challenges to the overall management of the network. To use a single VPN gateway to secure all WLAN traffic, all traffic must funnel through a connection to the VPN. In many organizations, a distinct wireless network is created and connected to other internal networks by a VPN gateway. But to support such a separation, you need an appropriate Ethernet network infrastructure, including plenty of bandwidth and virtual LAN (VLAN) capabilities. In addition, as with any VPN, you'll need to ensure that all users have appropriately configured VPN clients, which may require a software installation on every mobile device.

Most VPNs in use today make use of the IPsec protocol suite. IPsec, developed by the IETF, is a framework of open standards ensuring private communications over IP networks. It provides the following types of robust protection:

  • Confidentiality ensures that others cannot read the information in the message.

  • Connectionless integrity guarantees that a received message is unchanged from the original.

  • Data origin authentication guarantees that the received message was sent by the originator and not by a person masquerading as the originator.

  • Replay protection provides assurance that the same message is not delivered multiple times, and that messages are not out of order when delivered.

  • Traffic analysis protection provides assurance that an eavesdropper cannot determine who is communicating, or the frequency or volume of communications.

IPsec routes the messages via an encrypted tunnel by two special IPsec headers, which are inserted immediately after the IP header in each message. The Encapsulating Security Protocol (ESP) header provides privacy and protects against malicious modification, and the Authentication header (AH) protects against modification without providing privacy. The Internet Key Exchange (IKE) Protocol is a mechanism that allows for secret keys and other protection-related parameters to be exchanged prior to a communication without the intervention of a user.

As shown in Fig. 17.1, the IPsec tunnel is provided from the wireless client through the AP to the VPN device on the enterprise network edge. With IPsec, security services are provided at the network layer of the protocol stack. This means all applications and protocols operating above that layer (i.e., above layer 3) are IPsec protected. The IPsec security services are independent of the security that is occurring at layer 2, the WEP security. As a defense-in-depth strategy, if a VPN is in place, an organization can consider applying IPsec and WEP. With a configuration as shown in Fig. 17.2, the VPN encrypts (and otherwise protects) the transmitted data to and from the wired network.

click to expand
Figure 17.1: A WLAN with a VPN that uses IPsec in addition to WEP.

click to expand
Figure 17.2: An example of a wireless network with a "VPN overlay."

As shown in Fig. 17.2, a VPN overlay allows wireless devices to connect securely to the enterprise network through a VPN gateway on the enterprise edge. Wireless clients (computing devices) establish IPsec connections to the wireless VPN gateway—in addition to or as a substitute for WEP. (The computing device doesn't need special hardware, although it must be provided with IPsec/VPN client software.) The VPN gateway can use preshared cryptographic keys or digital certificates (public-key based) for authentication. Additionally, user authentication to the VPN gateway can occur using RADIUS or one-time-passwords (OTP) generated with SecureID, for example.

The VPN gateway may or may not have an integral firewall to restrict traffic to certain locations within the enterprise network. Additionally, the VPN gateway may or may not have the ability to create an audit journal of all activities. An audit trail is a chronological record of system activities that is sufficient to enable the reconstruction and examination of the sequence of environments and activities. A security manager may be able to use an audit trail on the VPN gateway to monitor compliance with security policy and to verify whether only authorized persons have gained access to the wireless network.

In short, consider using VPN technology in conjunction with other security methods to up a WLAN's security quotient. But keep in mind that while the VPN approach enhances the air-interface security significantly, this approach does not completely address security on the enterprise network. For instance, authentication and authorization to a particular enterprise application are not addressed with this security solution.

Where do security-minded organizations turn next? Some organizations may seek to develope a comprehensive enterprise security strategy utilizing specialized security products that have recently appeared on the market.



 < Day Day Up > 



Going Wi-Fi. A Practical Guide to Planning and Building an 802.11 Network
Going Wi-Fi: A Practical Guide to Planning and Building an 802.11 Network
ISBN: 1578203015
EAN: 2147483647
Year: 2003
Pages: 273

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net