Network Architecture

No Security

No security is like leaving your door wide open . Anyone can come in and use the network access. Basically, it is ignoring potential security problems.

Public Access

Public access is like handing out keys to everyone you know and trust. NoCat Auth, Sputnik, and Wayport all restrict access to public users by authenticating them. The authentication process protects the network by verifying the access credentials. In some cases, billing is exchanged for granting access to the system. In NoCat Auth's case, access can be removed from people abusing the system. Many of these solutions do not provide a secure tunnel for their users. The data sent over the air is in the clear. Users must provide their own protection against breaches of confidentiality such as using a VPN to tunnel back to their enterprise network.

Basic Access Control

Currently, basic access is like hiding a key under the mat. The key is hidden out there for clever people to find, but the network access and data are accessed to not be worth the trouble to break-in. It's easier for crooks to go where no security is in place.

At minimum, you should turn on WEP, password protect shared drives and resources, change the network name from the default (SSID), use MAC address filtering, and turn off broadcasts if possible. The Institute of Electrical and Electronics Engineers (IEEE) is working to remove the key from under the mat with two solutions—WEP enhancements in the short term and WEP replacements in the long term .

802.11 Security Measures Beyond WEP

Wi-Fi Protected Access (WPA) In November 2002, the Wi-Fi Alliance announced the WPA security standard. ^[14] It will replace the current—and comparably weak—WEP standard offered now on W-Fi equipment. New equipment shipping with WPA should be available starting in mid-2003. By the fall of 2003, WPA will be a requirement. It is anticipated that many vendors will offer firmware and software upgrades for existing Wi-Fi products that will make them work with WPA. When the products are finally available, they will be marked as being Wi-Fi WPA certified.

WPA uses the Temporal Key Integrity Protocol (TKIP), a more hardened encryption scheme than that used in WEP. TKIP uses key hashing (KeyMix) and nonlinear message integrity check (MIC). TKIP also uses a rapid-rekeying (ReKey) protocol that changes the encryption key about every 10,000 packets. However, TKIP does not eliminate fundamental flaws in Wi-Fi security. If an attacker hacks TKIP, he or she not only breaks confidentiality, but also access control and authentication.

WPA will work in two different ways, depending on the type of network. In homes and small offices lacking authentication servers (ASs), the technology will work in a so-called preshared key mode. Users simply enter the network key to gain access.

In the managed mode, it will work with ASs and will require the support of 802.1x and EAP. 802.1x and EAP enable a client network adapter to negotiate via an AP with a back-end AS using securely encrypted transactions to exchange session keys.

Every device on a wireless network must be upgraded to WPA in order for it to work. If a network is sewn together from several manufacturers' devices and the upgrade for one of the manufacturers is not available yet, you will have to wait to be able to deploy WPA. A mixed network can run with both WPA and WEP installed. However, security in the networks will default to WEP, which offers less protection.

WPA contains many parts of 802.11i. However, some of the key elements are not included such as support for a new encryption algorithm called Advanced Encryption Standard (AES), which will replace the RC4-based encryption algorithm when 802.11i becomes available. Migrating to AES encryption will require hardware changes since AES is computationally more complex than RC4. Secure fast handoff preauthentication, secure deassociation and deauthentication, and secure peer-to-peer communications (ad hoc mode) will also follow when 802.11i is released. When 802.11i is a deployed standard, products will be labeled as Wi-Fi WPA2 certified.

802.11 Security Measures Beyond WPA

WPA, when it becomes available, will be a good step toward securing a home or SOHO WLAN. However, for larger enterprises , 802.1x/EAP and VPN are still viable means of securing the WLAN. 802.1x/EAP offers more EAP choices, and a VPN enables workers to access the enterprise's network from any location.

802.1x and EAP—Advanced Security

802.1x provides an authentication framework for WLANs, enabling a user to be authenticated by a central authority. The actual algorithm that is used to determine whether a user is authentic is left open and multiple algorithms are possible. Examples are certificate-based solutions (such as EAP—Transport Layer Security [ EAP-TLS ]), password-based solutions (such as EAP-One Time Password [EAP-OTP] and EAP-Message Digest 5 [EAP-MD5]), smart-card-based solutions (such as EAP—Subscriber Identification Module [EAP-SIM]), and hybrids (such as EAP-Tunneled TLS Authentication Protocol [EAP-TTLS]) that use both certificates and passwords. Some companies offer their own proprietary EAP solution, such as Cisco's Lightweight EAP (LEAP).

802.1x uses EAP, an existing protocol (RFC 2284) that works on Ethernet, Token Ring, or WLANs for message exchange during the authentication process.

802.1x Network Port Authentication 802.1x authentication for WLANs has three main components : the supplicant (usually the client software), the authenticator (usually the AP), and the AS (usually a RADIUS server, although RADIUS is not specifically required by 802.1x). ^[15] The authenticator connects to the LAN network. Figure 4-14 illustrates this process.

Figure 4-14: 802.1x authentication

The normal flow for an 802.11x authentication is as follows : The supplicant (in the client) tries to connect to the AP by sending a start message. The AP detects the supplicant and enables the supplicant's port in an unauthorized state, so only 802.1x/EAP messages are forwarded. All other traffic is blocked.

The supplicant then sends an EAP-start message. The AP relies on an EAP-request identity message to obtain the supplicant's identity. The client's EAP-response packet containing the supplicant's identity is forwarded to the AS.

The AS authenticates the supplicant and either responds by accepting or rejecting the supplicant. Depending on the response from the AS, a positive authentication response will enable the port and negative authentication response will result in the port remaining blocked.

Extensible Authentication Protocol (EAP) To address the shortcomings of WEP for authentication, the industry is working toward solutions based on the 802.1x specification, which is based on the Internet Engineering Task Force (IETF) EAP. EAP was designed with flexibility in mind, and it has been used as the basis for many types of network authentication.

802.1x is based on EAP. EAP is formally specified in RFC 2284 and was initially developed for use with the Point-to-Point Protocol (PPP). When PPP was first introduced, two protocols were available to authenticate users, each of which required the use of a PPP protocol number. Authentication is not a one- size -fits-all problem, and it was an advanced area of research at the time. Rather than burn up PPP numbers for authentication protocols that might become obsolete, the IETF standardized EAP. ^[16]

IEEE 802.1x is not a single authentication method; rather, it utilizes EAP as its authentication framework. This means that 802.1x-enabled switches and APs can support a wide variety of authentication methods , including certificate-based authentication, smart cards, token cards, one-time passwords, and so on. However, the 802.1x specification itself does not specify or mandate any authentication methods. Figure 4-15 illustrates an 802.1x protocol stack showing the use of a variety of EAP types.

Figure 4-15: 802.1x protocol stack

Since switches and APs act as a pass through for EAP, new authentication methods can be added without upgrading the switch or AP, by adding software on the host and back-end AS.

Since IEEE 802.1x does not involve encapsulation (unlike Point-to-Point Protocol over Ethernet [PPPOE] or VPN), it adds no per-packet overhead and can be implemented on existing switches and APs with no performance impact. This means that IEEE 802.1x can scale from speeds of 11 Mbps (802.11) to 10+ Gbps and can be enabled on existing switches with a firmware upgrade without the need to buy new hardware. On hosts , since IEEE 802.1x can be implemented in the NIC driver, support can be enabled by obtaining updating drivers from the NIC vendor; you do not need to install a new operating system.

IEEE 802.1x integrates well with open standards for authentication , authorization , and accounting (AAA) (including RADIUS and Lightweight Directory Access Protocol [LDAP]) so it fits in well with the existing infrastructure for managing dial-up networks and VPNs. RADIUS servers (including Windows 2000 IAS) that support EAP can be used to manage IEEE 802.1x-based network access.

These specifications describe how IEEE 802.1x works, and how it can be managed via RADIUS and SNMP. Through RADIUS, IEEE 802.1x permits the management of authorization on a per-user basis. Per-user services include filtering (layer 2 or layer 3), tunneling, dynamic virtual LANs (VLANs), rate limits, and so on. ^[17] , ^[18] , ^[19]

Supplicants for 802.1x/EAP The supplicant for 802.1x/EAP is included in Windows XP. In November 2002, Microsoft not only released a Windows 2000 client, ^[20] but also pledged future client support for the older Windows 98, ME, and NT 4 releases. It is planned to be developed under Linux, FreeBSD, and OpenBSD with the Open1X project. ^[21] Apple has not implemented an 802.1x/EAP supplicant at the time of this writing.

802.1x/EAP Authenticators Many commercial APs such as Cisco, Lucent/Orinoco/Agere, and Enterasys feature 802.1x authentication support. Support for homebrew authenticators is provided with the Open1X project.

Remote Access Dial-In User Service (RADIUS) RADIUS ^[22] is currently the de facto standard for remote authentication. It is a widely deployed protocol for network access AAA in both new and legacy systems. Although a few security and transport issues are associated with it, it is very likely that RADIUS will continue to be widely used for many years to come. ^[23] , ^[24] , ^[25] Eventually, RADIUS may be replaced by a new protocol called DIAMETER. RADIUS is simple, efficient, and easy to implement—making it possible for RADIUS to fit into even the most inexpensive embedded devices.

The security issues revolve around the shallowness of the protocol and poor implementation of the specification. The protocol lacks confidentiality, authentication of client messages, and protection against a replay attack (integrity). The shared secret scheme does not allow for enough entropy in the keys and it seems to be open to offline dictionary attacks. RADIUS needs to be secured with an external protocol like IPSec.

The issues with transport are most relevant for accounting, in situations where services are billed according to usage. RADIUS runs on the User Datagram Protocol (UDP) and has no defined retransmission or accounting record retention policy, and does not support application-layer acknowledgments or error messages. Lost packets can mean revenue loss. This makes RADIUS accounting unreliable for usage-based billing services, particularly in interdomain usage (such as roaming) where substantial packet loss can occur over the Internet.

Two specifications make up the RADIUS protocol suite: authentication and accounting. The authentication portion can be used to determine if a user can gain access to the network. The authentication can be done locally or by proxy to another RADIUS server.

If you're a wireless Internet service provider (WISP), and you're reselling access on your APs to roaming parties, you can recognize these roamers by a suffix on their username. The RADIUS server should have a policy implemented as to who, when, and where to proxy to, and the extent to which you allow the remote server's answer to define the response that is sent to the roamer.

The remote server may be chosen based on a part of the username, the network specified in the username, or any other piece of information that's available about a request. You can also get the IP addresses and shared secrets for your remote server from any external source you like, so that you can easily maintain these destinations.

A couple of open-source implementations of RADIUS are available from www.freeradius.org/ and www.xs4all.nl/~evbergen/openradius/index.html. FreeRADIUS is available for a wide range of platforms, including Linux, FreeBSD, OpenBSD, OSF/Unix, and Solaris. Open-RADIUS is a RADIUS server that can be compiled to run on many variations of Unix.

EAP-MD5 EAP-MD5, or the Challenge Handshake Authentication Protocol (CHAP), ^[26] represents a kind of base-level EAP support among 802.1x devices. It is the least secure version of EAP because it uses usernames and passwords for authentication that are easily socialized. It is also vulnerable to dictionary attacks. In addition, EAP-MD5 does not support dynamic WEP keys, which is a critical liability.

LEAP

Cisco was one of the first vendors to market with its proprietary LEAP. ^[27] LEAP works only with Cisco client 802.11 cards, RADIUS servers, and Cisco APs. LEAP is vulnerable to man-in-the-middle dictionary attacks.

EAP-TLS EAP-TLS is an open standard that is supported by many vendors. ^[28] It uses Public Key Infrastructure (PKI) and thus is very secure by using asymmetric public and private keys. EAP-TLS is supported natively in Windows XP and by Windows 2000 severs. The only burden is that a PKI must be set up because every device needs an x.509 certificate. However, once EAP-TLS is set up, it is virtually transparent to the user.

EAP-TTLS EAP-TTLS and EAP-TLS are similar in that both use TLS (the successor to Secure Sockets Layer [SSL]) as the underlying strong cryptography. However, EAP-TTLS differs in that only the RADIUS servers, not the users, are required to have certificates. The user is authenticated to the network using ordinary password-based credentials, whose use is made proof against active and passive attacks by enclosing it in the TLS security wrapper.

EAP-SIM EAP-SIM is an EAP method designed by Nokia that allows hardware authentication to a SIM chip. A SIM is a secure processor about the size of a small postage stamp. SIMs are currently used in Global System for Mobile Communications (GSM) mobile phones to authenticate a user on a mobile network. After clicking connect and optionally entering a personal identification number (PIN), the system authenticates with the network and then connects to the Internet. The beauty of a SIM chip is that it makes cloning authentication secrets very difficult. It is likely that many GSM carriers like T-Mobile and Sonera will implement EAP-SIM to secure their public WLAN offering.

PEAP Protected EAP (PEAP) is another Cisco-developed protocol. Although EAP was originally created for use with PPP, it has since been adopted for use with IEEE 802.1x network port authentication. Since its deployment, a number of weaknesses in EAP have become apparent. These include a lack of protection of the user identity or the EAP negotiation, no standardized mechanism for key exchange, no built-in support for fragmentation and reassembly, and a lack of support for fast reconnect .

By wrapping the EAP protocol within TLS, PEAP addresses these deficiencies. ^[29] Any EAP method running within PEAP is provided with built-in support for key exchange, session resumption and fragmentation, and reassembly. PEAP provides the ability to seamlessly roam between APs. In the near future, PEAP will support the same EAP types that EAP supports.

The Downfall of 802.1x/EAP The downfall of 801.1x/EAP is a lack of supplicants. Although an 802.1x supplicant is supplied in Windows XP, and a patch is available for Windows 2000, no supplicants are available for Windows 98, ME, CE, NT-4, Linux and its variants, and Apple 9 and X operating systems. A Linux open project called open1x has been started at http://www.open1x.org/links.html. Since Apple X is essentially based on Unix, once the open 1x implementation works, it will probably be ported over. The bottom line is that unless supplicants are available that are compatible with the operating systems that are being used, 802.1x/EAP won't be able to provide a complete solution.

VPNs

A VPN enables a specific group of users to access private network data and resources securely over the Internet or other networks. VPNs are characterized by the concurrent use of tunneling, encryption, authentication, and access control over a public network.

VPNs create virtual point-to-point connections using a technique called tunneling . As the name suggests, tunneling acts like a pipe that bores through a network cloud to connect two points. Typically started by a remote user, the tunneling process encapsulates data and encrypts it into standard TCP/IP packets, which can then securely travel across the Internet to a VPN server on the other side where they are decrypted and de-encapsulated onto the private LAN network.

Two basic VPN types are available:

• Remote access VPNs These securely connect remote users, such as mobile users and telecommuters, to the enterprise. This type of VPN can be used by 802.11 users to initiate a session back to their corporate LAN—for example, salespeople equipped with laptops and telecommuters who would like to connect intermittently from diverse locations such as hotels, airports, convention centers, and coffee shops. The key concerns are encryption and authentication. Performance and bandwidth can also be sacrificed because the connection is broadband.

• LAN-to-LAN VPNs These securely connect remote and branch offices to the enterprise (intranet VPNs). They also securely connect third parties, such as customers, suppliers, and business partners , to the enterprise (extranet VPNs). Intranet or extranet VPNs can be used to secure wireless point-to-point links. For example, a wireless back haul may connect a hot spot back to a central location. This type of VPN needs to be encrypted and authenticated as well as meet strict performance and bandwidth requirements since this kind of connection carries network traffic.

How VPN Works for 802.11 To support 802.11 WLANs, VPN client software application is deployed on all machines that will use the WLAN, and a VPN gateway is introduced into the network between the AP and the WLAN segment, as shown in Figure 4-16.

Figure 4-16: A WLAN with VPN

An encrypted VPN tunnel is built from the laptop through the wireless gateway and terminated at the VPN gateway in order to gain access to the wired LAN through the wireless AP. All traffic passing through the AP must go through the VPN gateway before entering the LAN. The cleartext data on the other side of the secure tunnel can then continue onto its destination inside the local network. The VPN tunnel provides authentication, data confidentiality, and data integrity. Thus, other encryption mechanisms such as WEP are no longer needed.

A VPN solution also enables mobile workers to access their network from a remote location where security may or may not be provided, as shown in Figure 4-17.

Figure 4-17: A WLAN with VPN using remote network access

The secure tunnel extends from the client's computer, through the Internet, and through the firewall/VPN gateway to the VPN server. From the VPN server, the data continues to its destination inside the corporate network.

Vulnerabilities of VPNs Although VPNs are touted as a secure solution for WLANs, VPNs using one-way authentication are still vulnerable to exploitation such as man-in-the-middle attacks.

The deployment of WLANs in large organizations can create a nightmare of distributing and maintaining client software to all clients . Almost all VPN solutions shipping today are proprietary (not IETF standard) in some form or another and are generally not interoperable. Because of this fact, not all devices may have client software available for any one VPN supplier. Also, it is often the case that once a VPN is installed, a different VPN won't operate on the same machine. Thus, VPNs are impractical for securing a public access WLAN.

It is also important to note that many of the proprietary security extensions may have security flaws due to the lack of cryptographic rigor applied to them. Despite these vulnerabilities, encryption, authentication, and integrity remain essential elements of WLAN security. ^[30]

VPN Standards Many protocols have been written for use with VPNs. These protocols attempt to close some of the security holes inherent in VPNs. These protocols continue to compete with each other for acceptance in the industry and are not compatible with each other.

IPSec IPSec VPNs have nearly become accepted as the de facto standard for securing IP data transmission over shared public data networks since VPN software has been developed for a wide variety of clients. It addresses authentication, data confidentiality, integrity, and key management, in addition to tunneling.

Basically, IPSec encapsulates a packet by wrapping another packet around it. It then encrypts the entire packet. This encrypted stream of traffic forms a secure tunnel across an otherwise unsecured network. Interoperability issues still exist between different vendors' implementations.

PPTP PPTP is a protocol specification developed by several companies. Nearly all flavors of Windows include built-in support for the protocol. PPTP was the dominant VPN before IPSec was deployed. PPTP tunnels data, encrypts user data, and authenticates users.

PPTP is a tunneling protocol that provides remote users encrypted, multiprotocol access to a corporate network over the Internet. PPTP uses generic routing encapsulation (GRE). PPTP wraps IP packets in GRE packets before sending them down the tunnel. Network layer protocols, such as Internetwork Packet Exchange (IPX) and NetBIOS Enhanced User Interface (NetBEUI), are encapsulated by the PPTP protocol for transport over the Internet.

The initial releases of PPTP for Windows by Microsoft contained security features that some experts claimed were too weak for serious use. However, Microsoft continues to improve its PPTP support.

L2TP L2TP was developed by Cisco. L2TP supports non-TCP/IP clients and protocols (such as frame relay, Asynchronous Transfer Mode [ATM], and Synchronous Optical Network [SONET]), but fails to define any encryption standard. Although L2TP is compatible with most network protocols, it is not widely deployed, but is common in certain telco and ISP networks.

L2TP over IPSec L2TP over IPSec offers tunneling, user authentication, mutual computer authentication, encryption, data authentication, and data integrity. L2TP offers multiprotocol support.

SSL SSL, working only with TCP/IP protocols, is the primary protocol for secure connections from web browsers to web servers, usually for secure credit card connections or sensitive data. SSL requires a valid site certificate issued from an authorized certificate authority. SSL provides tunneling, data encryption, mutual authentication, integrity, and nonrepudiation.

SOCKS Network Security Protocol SOCKS is a VPN protocol that operates on layer 5, whereas most others operate at layer 2 or 3. SOCKS version 5 is a circuit-level proxy protocol that was originally designed to facilitate authenticated firewall traversal. Functioning at a higher level means that SOCKS only operates with certain applications. SOCKS v5 supports a broad range of authentication, encryption, tunneling, and key management schemes. It is generally considered to be a market failure.

IP Addresses—Network Address Translation (NAT)/Port Address Translation (PAT) Many VPNs require fully routable/ public IP addresses and no port blocking on any ports except incoming port 80 and port 139 (VPNs do not use these ports). This is because the VPNs cannot tolerate NAT or PAT. However, NAT/PAT is necessary in order to provide network security, prevent subscribers from running host servers on their LAN, and preserve valuable IP address space.

A growing number of VPN clients support emerging standards for UDP encapsulation to push IPSec through NAT/PAT. PPTP often passes through NAT/PAT without trouble, but L2TP over IPSec also requires encapsulation.

Kerberos

Kerberos provides a third method of securing the 802.11 over the air link. It is mainly used by Symbol Technologies, Inc. with their Spectrum24 WLANs. Kerberos provides robust security, uninterrupted network connectivity for voice and data devices, and addresses the security needs and concerns of network managers.

Kerberos provides both user authentication and encryption key management, and can guard networks from attacks on data in transmission, including interruption, interception, modification, and fabrication. Kerberos was voted as the "mandatory-to-implement" security service for 802.11e authentication and encryption key management. Kerberos provides confidentiality, authentication, integrity, access control, and availability. Kerberos also works very well during handoffs between APs resulting in uninterrupted application connectivity. Reauthentication to the network is very quick.

How Kerberos Works for 802.11 Kerberos is based on the key distribution model developed by Needham and Schroeder. ^[31] Network authentication using Kerberos involves four processes: authentication exchange, ticket-granting service exchange, user/server exchange, and secure communications between user and server. ^[32] This is illustrated in Figure 4-18.

Figure 4-18: Kerberos authentication flow

Authentication Exchange The user sends a request to the AS for a ticket to the ticket-granting server (TGS). The AS looks up the user in its database, finds the client's secret key, and then generates a session key (SK1) for use between the client and the TGS.

The AS encrypts the session key using the user's secret key to form a message. The AS also uses the TGS's secret key (known only to the AS and the TGS) to encrypt the session key and the user's name to form a ticket-granting ticket (TGT). The TGT and the message are sent back to the user.

Ticket-Granting Service Exchange The user decrypts the message and recovers the session key. The user creates an authenticator by encrypting the user's name, IP address, and a timestamp with the session key. The user sends this authenticator, along with the TGT, to the TGS, requesting access to the target server. The TGS decrypts the TGT to recover SK1 and then uses the SK1 inside the TGT to decrypt the authenticator. It verifies information in the authenticator, the ticket, the user's network address, and the timestamp. If everything matches, it lets the request proceed.

Then the TGS creates a new session key (SK2) for the user and target server to use, encrypts it using SK1, and sends it to the user. The TGS also sends a ticket containing the user's name, a network address, a timestamp, and an expiration time for the ticket—all encrypted with the target server's secret key—and the name of the server.

User/Server Exchange The user decrypts the message and gets SK2. Finally ready to approach the target server, the user creates a new authenticator encrypted with SK2. The user sends the session ticket (already encrypted with the target server's secret key) and the encrypted authenticator. Because the authenticator contains plaintext encrypted with SK2, it proves that the user knows the key. The encrypted timestamp prevents an eavesdropper from recording both the ticket and authenticator and replaying them later. The target server decrypts and checks the ticket, authenticator, user address, and timestamp. For applications that require two-way authentication, the target server returns a message consisting of the timestamp plus one, encrypted with SK2. This proves to the user that the server actually knew its own secret key and thus could decrypt the ticket and the authenticator.

Secure Communications The target server knows that the user is who he or she claims to be, and the two now share an encryption key for secure communications. Because only the user and target server share this key, they can assume that a recent message encrypted in that key originated with the other party.

The Downfalls of Kerberos The following are inherent downfalls to the Kerberos authentication system:

• If an attacker is logged on the same computer at the same time as an authorized user, the cached keys located on that computer are accessible to the attacker.

• The Kerberos system relies on the synchronization of the clocks located on the different machines. If an intruder can mislead a host in terms of the correct time, the authentication ticket to the network can be used repeatedly as a result of the nonexpiring timestamp.

• You must trust that all three machines (time/authenticator servers [KDC], the client, and the network server) are void of an intruder.

• If a ticket is forwarded, the system must trust all of the other systems that the ticket has traveled through before reaching the current server. However, the server where the ticket arrives cannot tell where it has come from—it can only tell that it has been on other servers by a flag, which has been set to one.

• Passwords can be guessed by plugging a password guess into the public encryption key algorithm.

• The longer a ticket is granted, the more likely it is to be stolen and used by an unauthorized user.

• In a wireless system using MAC address registration as an authentication method, if the NIC is stolen, the card has the inherent authentication of the user that is tied to that NIC and will be granted access to the network. ^[33]

Standards Kerberos V5 is standardized under RFC 1521. ^[34]

^[14] Wi-Fi Alliance, "Overview—Wi-Fi Protected Access," www.wi-fi.com/OpenSection/pdf/Wi-Fi_Protected_Access_Overview.pdf October 31, 2002.

^[15] IEEE 802.1x, http://standards.ieee.org/getieee802/.

^[16] Matthew Gast, 802.11b Wireless Networks: The Definitive Guide (Sebastopol, California: O'Reilly & Associates, 2002), 100.

^[17] The Unofficial 802.11 Security Web Page, http://www.drizzle.com/~aboba/IEEE/.

^[18] Mishra, Arunesh, and Arbaugh, William A, "An Initial Security Analysis of the IEEE 802.1x Standard, Feb. 06, 2002, http://www.cs.umd.edu/~waa/1x.pdf.

^[19] Cisco Aironet Response to University of Maryland's Paper, "An Initial Security Analysis of the IEEE 802.1x Standard," March 2002, http://www.cisco.com/warp/public/cc/pd/witc/ao350ap/prodlit/1680_pp.htm.

^[20] "Microsoft 802.1x Authentication Client," www.microsoft.com/windows2000/server/evaluation/news/ bulletins /8021xclient.asp December 13, 2002.

^[21] "Open Source Implementation of IEEE 802.1x," www.openlx.org/.

^[22] "Remote Authentication Dial-in User Service (RADIUS)," www.ietf.org/rfc/rfc2865.txt, and "Radius Accounting," www.ietf.org/rfc/rfc2866.txt.

^[23] Joshua Hill, "An Analysis of the RADIUS Authentication Protocol," www.untruth.org/~josh/security/radius/radius-auth.html.

^[24] Bernard Aboba and Ashwin Palakar, "IEEE 802.1x and RADIUS Security."

^[25] "Radius Protocol and Best Practices," www.microsoft.com/windows2000/docs/RADIUS_Sec.doc.

^[26] "PPP Challenge Handshake Authentication Protocol (CHAP)," www.ietf.org/rfc/rfc1994.txt.

^[27] "Authentication with 802.1x and EAP Across Congested WAN Links," www.cisco.com/warp/public/cc/pd/witc/ao350ap/prodlit/authp_an.htm.

^[28] "PPP EAP-TLS Authentication Protocol," www.ietf.org/rfc/rfc2716.txt.

^[29] "Protected EAP Protocol (PEAP)," www.globecom.net/ietf/draft/draft-josefsson-pppext-eap-tls-eap-02.html.

^[30] "Practical Steps to Secure Your Wireless LAN," a white paper from AirDefense, www.airdefense.com.

^[31] R. M. Needham and M. D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers," Communications of the ACM 21, no. 12 (December 1978): 993-99.

^[32] Russel Kay, "Kerberos," Computer World, www.computerworld.com/news/2000/story/0,11280,46517,00.html, July 3, 2000.