Industry Standard Security and guest wifi access best practice

Have you checked all of the "hotspot" products listed in the wikis below?

On 13 Nov 2006 08:50:36 -0800, snipped-for-privacy@buildingconcepts.com wrote in :

Thanks for the response,

Pretty much everything listed there is on a smaller scale than what I'm looking for and still doesn't address the security concerns I have. Nonetheless, the information I found there has led to more options by, if nothing else, informing me of better terminology under which to do my searching.

I now know the proper term for the unit I'm looking for is a "captive portal" (probably obvious to the more seasoned in this particular field, but if you don't know what language to use in a search you don't get very far until you stumble upon the correct terminology.) but where my needs differ from what I continue to find is that I would like the captive portal to establish an SSL VPN session upon completing user registration (as oposed to merely providing SSL for the registration process itself) so as to encrypt over the air traffic without using WPA encryption.

Of course I could have missed something and this product might not exist because it is a very bad idea.

John Navas wrote:

On 13 Nov 2006 09:47:46 -0800, snipped-for-privacy@buildingconcepts.com wrote in :

I'm guessing it doesn't exist because there's no seamless way to do it, and because the available options work well:

1. Use WPA to encrypt wireless traffic, with wireless isolation to prevent wireless hosts from seeing each other.
2. Support and enforce VPN, either with downloadable software (e.g., OpenVPN ), or VPN support built into the host OS (e.g., PPTP).

See also HotSpotVPN

snipped-for-privacy@buildingconcepts.com hath wroth:

Could you elaborate on the "scale" that you're looking for? Number of connected wireless clients? Number of connected wired clients? Type and bandwidth or backhaul? Number of backhauls? Approximate area of required coverage? Type of building construction? Number of floors? Indoor, outdoor, or both? Is "illumination" from outside the building possible? Availability of offsite support and admin? Any monitoring required? How do you plan to deal with abuse, worm infected machines, outages, support, account administration, and billing?

In effect, you're asking for a detailed bid and proposal, which is rather difficult without numbers.

There are a few assumption in your list of requirements. One that's wrong is the you cannot simultaneously run WPA encryption and open access on the same wireless router. See Sonicwall "security zones" and the beta version of DD-WRT 2.4 for how it's done. Also, the latest FON firmware has this feature. Some 3com access points also support this feature. Look for devices that support multiple SSID's as they usually also have this feature. I can dig out the models later if your interested.

Another assumption is that you can deploy such a system without any available maintenance or support services. That's not going to work. In effect, you're setting up something similar to a wire line ISP, but with the added entertainment value of a non-reliable delivery mechanism. Your customers need to have someone to call for help or they won't pay the bill.

Gotta run...

Unfortunately for my situation those alternatives don't really provide what I am looking for.

2 VPN use-This is something I want to rule out from the start. First, it requires me either to put an IPSEC gateway in place and pay for proprietary clients or it requires server infrastructure to maintain and either way it means supporting a piece of software on a client's computer. I don't want clients to need to do anything technical because they will mess it up and I will be responsible. My experience with IPSEC VPN clients has not been positive. Likewise, providing instructions on how to set up OS based VPN connections will also result in tech calls.

The picture I'm trying to paint is that people will be connecting equipment and expecting it to work. Who knows what time of day or night this will be, but if they can't figure it out they will expect immediate answers.

Further, I may need to connect wireless devices other than PC's that don't support WPA, and if they did then rule out changing the key ever. With an access gateway I could at least white list the MAC and give the device open access. This is secondary and I may need to compromise on it no matter what.

I may get stuck allowing guest users access to the WPA key, but entering this key exactly one time is the most I feel I can expect of the end user.

I don't see why there couldn't be a seamless way to add SSL VPN capability to a captive portal. All traffic is open an unencrypted up to the portal, but then the user connects to log in, and ends up on a secure connection through authentication. Upon authentication the device would establish a tunnel between itself and the client and all traffic between it and the client would be encrypted. Seems reasonable to me, but it must not be for some reason or else I'm sure some company out there would be doing it.

John Navas wrote:

On 13 Nov 2006 12:36:12 -0800, snipped-for-privacy@buildingconcepts.com wrote in :

No need -- *encryption* security of WPA has nothing to do with key strength. The key is only for *authentication* (not encryption), and can be made very weak when no authentication is needed; e.g., passphrase of "password" or "key". Encryption will still be strong, and wireless isolation can be used to keep one host from eavesdropping another.

That will be an issue no matter what you do.

IPSEC isn't the only choice -- read what I wrote more carefully.

That's going to happen no matter what you do.

Then they probably won't support other forms of security.

MAC *isn't* a viable authentication option -- too easily spoofed.

See above.

Then you need to bone up on how VPN works. There's no way for a gateway to switch all connections into SSL mode.

It's not reasonable -- security depends on support in the device.

Scale is left intentionally ambiguous as I am not looking to suit a specific project, but instead am looking for a conceptual approach to this project. However, when I made the comment previously I was indicating that the hotspot devices where the WAP and authentication unit were integrated are not sufficient. What I need is a system that ties multiple wireless access points together for authentication and security. I am specifically looking for prices for a vendor neutral access controller to serve the above objective. If the access controller provides the necessary functions but must be paired with same brand access points then I will still consider it.

As far as help desk functions, I know that the tennants will need tech support. Don't get me wrong, this has always been understood. However, what is specifically unacceptable is requiring technician intervention to grant a system access to the network. Also unacceptable is a system which cannot accomodate remote administration. An end user can only be expected to handle so much before a professional is required to intervene. In a corporate setting one does not give the employees a checklist of instructions on how to get hooked in to the 802.1X system, the IT staff does this. In a hotel one does not keep a staff IT person around to help out with the complimentary WIFI access. You either have ultra-secure and complex, minimally secure and easy, or something in between. My goal is to figure out how to gain basicly secure internet connections (WPA level or better) for tennants and guests without making it any more complicated than logging in to a hotel or airport hotspot.

Thanks,

Tim

Jeff Liebermann wrote:

I'm a relative newcomer to the wireless game, and perhaps for that reason I see things a bit differently. I may be mistaken on a few things, but here goes...

Seems to me you have two classes of users, so you need two sub-nets here. Since they are both internet only, there is no need to interconnect them Therefore two separate wired/wireless routers should satisy things separate channels, separate id's etc configure each to suit the separate needs

Usual windoze idiot-proof connections...

conflicts with above, so separate them

John Navas wrote in news: snipped-for-privacy@4ax.com:

You *appear* to be contradicting your own advice re WPA: i.e. "ALERT: WPA can be less secure than WEP", "USE A PASSPHRASE WITH MORE THAN 20 CHARACTERS" and "the only value PSK has is if only truly random keys are used", etc. What have I misunderstood?

On Mon, 13 Nov 2006 23:58:58 GMT, Frazer Jolly Goodfellow wrote in :

The difference between (a) authentication and (b) encryption.

The point of having a strong passphrase is secure *authentication*, in order to prevent unauthorized access to your network. *Encryption* is still strong even with a weak passphrase. With wireless isolation, even if someone unauthorized authenticates, they still won't be able to see your other network traffic.

John Navas wrote in news: snipped-for-privacy@4ax.com:

So what's the point of encryption if wireless isolation hides your network traffic?

On Tue, 14 Nov 2006 11:57:08 GMT, Frazer Jolly Goodfellow wrote in :

If there were no encryption, then anyone could simply intercept your wireless data without regard to authentication.

On the other hand, encryption with wireless isolation, even without strong authentication, would protect your data, with encryption protecting your data, and wireless isolation protecting your wireless hosts from authenticated users (legitimate or otherwise). This is why wireless isolation is an important feature in open wireless hotspots (or sharing Internet service with a neighbor).

By the same token, wireless isolation would prevent you from networking between your own wireless hosts. If that's important to you, then you can't use wireless isolation.

When a wireless access point (or router) lacks wireless isolation, or has it turned off, then authentication becomes important, since anyone authenticated would then have access to all your wireless hosts, with the only remaining line of defense being software (personal) firewalls.

Frazer Jolly Goodfellow hath wroth:

Wireless isolation (also known as AP Isolation) prevent bridging between wireless clients. With it enabled, you can't connect from one laptop to another, which implies that you can't attack another laptop through the access point. However, there's nothing to stop you or another laptop from sniffing everyone's traffic, decrypting the captured traffic, and doing evil and dastardly things with the information. If you're in a coffee shop or busy office, you probably won't even notice the difference in over the air traffic with wireless isolation enabled or disabled. There's so little client to client traffic, that nothing much has changed. The major use of wireless isolation is to prevent propagation of worms and virus's from client to client through the access point.

On Tue, 14 Nov 2006 09:55:53 -0800, Jeff Liebermann wrote in :

More than "implies" -- it actually works to isolate wireless hosts.

Sure there is -- different wireless sessions use different encryption, and WPA will stop you or anyone else, even if authenticated, even if a PSK is known, from decrypting captured traffic.

It's a common misconception that knowing a PSK pass-phrase is enough to decrypt encrypted wireless traffic. It's not, because WPA uses dynamic session keys: per user, per session, and even per packet (plus protection against replay attacks).

The insecurity of PSK is thus a matter of *authentication* (wireless network access), not *encryption*.

It's not a matter of traffic -- it's a matter of access.

The major use is actually to prevent one wireless host from being able to access (attack or otherwise compromise) another wireless host.

John Navas hath wroth:

What's a host? I suspect it should be called "client isolation" but nobody seems to use that. It's always "wireless isolation" or "AP isolation".

I was thinking of a coffee shop environment, where no encryption is used.

I didn't know that different wireless sessions use different encrytion keys. That's true for WPA-RADIUS where the RADIUS server issues unique keys for each session. However, that's not the way I understand WPA-PSK (WPA-Personal) works. It's one key for everyone. If you're a participant in a WPA-PSK encrypted network, and you have the common shared encryption key, the clients can see each other. I'm not 100.0% sure, so I'll RTFM when time permits.

I just happen to have two laptops here. Fire up WPA, try to find where I buried the key, connect, etc. Yep, I can connect between laptops (ping and net view \\\\clientname). Now, I turn on AP isolation on my WRT54G. Both laptops can surf the internet, but can't see each other. By your explanation of how WPA-PSK works, the two laptops should not be able to communicate throught the AP, with AP isolation disabled, because they have different session keys. I don't think so as I just demonstrated.

Oh, I see where you're going. You're suggesting that if I announce the WPA-PSK key to the world, it still would be insufficient to decrypt the captured traffic file. Well, I just finished doing exactly that with airdecap-ng: |

airdecap-ng even works with a TCPdump capture file with this incantation: /usr/sbin/tcpdump -r junk.cap -n -c 1 reading from file working.cap, link-type IEEE802_11 (802.11) (etc...)

I beg to differ. I'm passive sniffing the traffic. I don't need no authentication or authorization as I'm not trying to join the network.

If I were trying to open a share on a client computer, that's absolutely correct. However, I'm not. I'm sniffing. If I were attacking another client computer, I would not need to deal with the Windoze security if I were just port scanning or looking for exploits. However, if the Windoze firewall were doing it's job, I would have difficulties doing this.

Agreed. The major inspiration I've seen is where users either intentionally try to attack other users, or inadvertantly with a virus, work, trojan, spam bot, or such.

John Navas wrote in news: snipped-for-privacy@4ax.com:

I'm thoroughly confused now. The reference you cite in your warnings re WPA can be less secure than WEP -

On Tue, 14 Nov 2006 12:45:36 -0800, Jeff Liebermann wrote in :

These are wireless clients (in terms of Infrastructure Mode) but LAN hosts (in terms of network terminology). Confusing I know, but that's because they didn't listen to me, and now have to duck the issue. :)

Some do; some don't. I've advised open access public hotspots to at least use WPA with a simple published pass-phrase in order to encrypt all traffic, and to use a wireless access point with wireless isolation. (But see below.)

You're confusing the WPA access pass-phrase with the session encryption key. (But see below.)

What I've actually been saying is that having the WPA-PSK does not make it possible for you to directly decrypt the wireless traffic of other wireless clients. (But see below.)

That's what I've been saying. (But see below.)

OK, you're prompted me to research this again, and I now see that I've been relying on out-of-date information. [sigh] While it isn't possible to directly decrypt the traffic with just the WPA pass-phrase, it's now known to be possible to do it if you snoop the necessary traffic.

WPA (Wi-Fi Protected Access) came as a replacement for the less secure WEP standard. WPA addresses many of WEP's security and privacy concerns, significantly increasing the level of data protection and access control for WLANs. Unlike WEP, WPA is a dynamic encryption system that uses rekeying, unique per-station keys, and a number of other measures to improve security. WPA features two modes, PSK (Pre-Shared Key) and Enterprise, which differ in a number of ways. CommView for WiFi supports decryption of WPA in PSK mode.

Given the dynamic nature of WPA encryption, knowing the WPA passphrase alone doesn't allow you to decrypt traffic immediately after entering the correct passphrase. To be able to decrypt WPA-encrypted traffic, CommView for WiFi must be running and capturing packets during the key exchange phase (key exchange is carried out using the EAPOL protocol). It's important that all of the EAPOL key exchange packets be successfully captured. A damaged or missing EAPOL packet will make it impossible for CommView for WiFi to decrypt packets that will be sent to/from the given station, and capturing the next EAPOL conversation between the AP and station may be required. This is an important distinction in the way WEP and WPA traffic is decrypted.

The principles explained above mean that once you have entered the WPA passphrase, closed the WEP/WPA Keys dialog, and started capturing packets, you will need to wait for the next authentication and key exchange event before the packets can be decrypted for the station that has been authenticated. Naturally, it's not uncommon that the program can decrypt packets to/from one client, but not to/from another, as it may have not yet captured EAPOL packets for all of the clients.

Re-authentication can be triggered by using the Node Reassociation tool, by restarting the AP (for all authenticated stations), or by reconnecting to the network (for the given client).

And so I stand corrected. Thank you.

For open access public hotspots I'll now be recommending only access points with both wireless isolation and WPA Enterprise security, handing out unique logins on demand. This could be easily automated with an HTTPS login page.

On Tue, 14 Nov 2006 20:52:09 GMT, Frazer Jolly Goodfellow wrote in :

Correct. I was relying on previous bad information. Sorry.

John Navas wrote in news: snipped-for-privacy@4ax.com:

No problem, thanks for clearing it up for me.