(CONTIUED)Securing the air: Don't let your wireless LAN be a moving targ
A TLS handshake (see Figure 1) is used to authenticate the access point to the wireless client. First, the wireless client sends a message to a backend server announcing that is connected to the wireless access point. The message tells the server that a new connection should be initiated, and also tells which cryptographic algorithms the client understands so that secure messages sent between the two can be understood. After receiving this message, the backend server responds with a new session ID, a list of algorithms that will be used to correspond, and a public key certificate that allows the client to trust the access point it has used to establish the connection to the network. The wireless client verifies the signature and validity of the server certificate, and then responds by generating a secret key and encrypting it with the public key obtained from the server certificate. This protected information is sent back to the server and, if the server is able to decrypt this information, it is authenticated: only the server's private key would be able to decrypt messages encrypted with its public key. After this last exchange, authentication of the access point is complete and a secure TLS session is established to protect the user authentication credentials which will be passed in phase two.
Figure 1. TLS handshake
An added layer of protection is provided in the second phase of Protected EAP through the use of EAP, which is able to strongly authenticate the end user of the wireless client by challenging the user with a suitable EAP mechanism (see Figure 2). Suitable EAP mechanisms include the use of passwords, smart cards, digital certificates, or time-synchronous tokens like the RSA SecurID token, which produce one-time passcode challenges. The EAP challenges are passed to backend authentication servers connected to the wireless access points sitting on a company's wireless LAN. The versatility here is really the key, because EAP allows enterprises to continue to use any appropriate EAP method already deployed to their employees and extend its use to the wireless LAN.
Figure 2. Protected EAP authentication phase
The real benefit will be felt by users who are roaming within a corporation's wireless LAN and require a seamless connection. Users want mobility and convenience. If they are asked to authenticate themselves each time they pass from one conference room to another, they will want to give up security in favor of convenience. "It's the two week rule," says Pete Wann, systems engineer at RSA Security. "Security mechanisms in the enterprise are removed in as little as two weeks if users are inconvenienced. We see this over and over again. It really puts the importance on building in user-friendly security at the beginning -- in the product development phase."
And that's the point for choosing TLS for Protected EAP in the 802.1x standard. Using the connection re-establishment mechanism provided in the TLS handshake allows users to have one seamless connection while roaming between different access points connected to the same backend server. If the session ID is still valid, the wireless client and server can share old secrets to negotiate a new handshake and keep the connection alive and secure (see Figure 3).
Figure 3. Roaming in Protected EAP
What the future holds
Moving forward, we can expect 802.1x to be adopted into a variety of 802.11 standards, like 802.11a. From a security perspective, this is good news, because products being built today can use 802.1x. These products will offer advantages to enterprises by allowing them to take the same strong authentication solutions currently deployed in enterprises and use them with wireless LAN products. In addition, implementing 802.1x in wireless LAN products will offer the advantage of allowing users to roam more conveniently and securely. It is a long-term fix to solve user and access point authentication in a roaming environment.
On the encryption side, Task Group I is working out a solution to fix WEP for the long-term. The group meets this week in Dallas to finalize its work and we can expect to hear more public announcements from the group after Thanksgiving. The buzz will begin to hit the streets in December when vendors follow up with announcements about how they plan to incorporate the merits of the Task Group's work into a quick fix for WEP to clean up the mess in all of the 802.11b hardware currently deployed. Watch this space.
For the longer-term solution, expect Task Group I to roll its work into an 802.11i standard that will eventually replace 802.11b. It seems logical to draw the conclusion that Task Group I's work will also be incorporated into the 802.11a standard to secure WLAN products that will be capable of offering higher bandwidth to users sometime next year. Vendors working with 802.11a should also start evaluating the Protected EAP proposal in the 802.1x standard today.
But the moral of the 802.11b story has really been a chapter on the importance of writing good security protocols that will allow vendors to offer high levels of data protection, user authentication, and interoperability. This will happen only if security experts are involved earlier in the standards development phase. Unfortunately, the 802.11b lesson illustrates a long-supported claim in the security industry -- that security is still an afterthought. 802.11b painfully demonstrates the importance of reversing this trend. 802.1x and the work coming out of Task Group I are important steps in the right direction.
Special thanks go to Chris Wysopal from @Stake, and Magnus Nystrom, Dag Stroman, HÄ«kan Andersson, Pete Wann, and Mike Vergara from RSA Security. Not only did each give up valuable time to be interviewed or review this article, but each is playing a critical role in solving the security problems described here.
Peter Shipley finds unsecured LANs in the San Francisco Bay Area. (Document in PDF format.)
Extremetech finds more unsecured networks in Silicon Valley and the New York City area.
Orthus and RSA Security Survey uncover insecure WLANs in London.
Visit @Stake's homepage.
Check out papers on WEP vulnerability from Intel (in Microsoft Word format), UC Berkeley (PDF) and the University of Maryland (PDF).
Fluhrer, Mantin, and Shamir describe a successful attack launched by Stubblefield, Ioanndis, and Rubin using a hidden WEP key.
Download AirSnort and WEPCrack.
Read RSA Security's WEP advisory.
See the Protected EAP proposal made to the IETF.
Find out more about what's going on with the TLS standard.
Read about an example of a hardware token for user authentication.
Read up on IV and cryptography research from IBM, RSA Security, and Microsoft.
developerWorks' Larry Loeb examines the Wired Equivalent Protocol.
Check out IBM's prototype Wireless Security Auditor.
About the author
Kim Getgen is a product marketing manager at RSA Security in San Mateo, CA. She is responsible for the marketing of the RSA BSAFE product line and the RSA Wireless Security Portfolio. Prior to joining RSA Security, Ms. Getgen worked in the professional services organization at Compaq. she earned her BA from Wake Forest University and her MPhil from Oxford University. You can contact her at email@example.com.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...