Industry Standard Security and guest wifi access best practice
tyo...@buildingconcepts.com
I am looking for a solution to provide wifi access in a multi dwelling
residential unit such that it provides as many of the following points
as possible:
1 When a user connects for the first time they see a page displaying a
usage policy and a login screen. Guest login is allowed, but
registered login is optional and recommended, passwords and logins
administered through the building management.
2 The Network Access Controller to provide the ability to throttle down
guest connections to around 256k down, 128k up, while leaving
registered users' connections a great deal more robust.
3 Connection is simple for the end user and requires no VPN client
software.
4 The connection is nonetheless secured in a responsible fashion
5 The equipment may have high initial cost, but must run relatively
trouble free (no on-site IT support needed). Preferibly it will
involve a rack mounted gateway appliance rather than any sort of server
and will be administrated remotely.
6 Wireless subnet roaming would be really nice as well.
I am aware of the basic access controllers such as those provided by
BlueSocket. Basically what I want is a BlueSocket controller that can
secure the wireless connection via SSL VPN so that the wireless portion
is encrypted despite transmission over an open authentication access
point system. However, I do not want to subject the user to multiple
login pages (Authentication and then VPN) which would be necessary it I
use two separate devices.
Inability to run my access points both WPA-PSK encrypted and open means
that I can't reasonably leave guest access "at your own risk" while
securing tennant acces, plus tennants will not be happy switching a
highly random WPA key every week, but I also don't feel secure leaving
the same key in place for a year allowing it to be compromised in that
way.
Any major architectural restructuring is also right out. I can't see
implementing 802.1X as the complexity in supporting tennants would
require an onsite technician. Also transparent domain login
authentication would be a hassle as many of the tennants would be using
business laptops and no alteration to the setup they use at work would
be acceptable.
So far I feel that I am asking too much and that even if a device is
possible to do what I am looking for, it doesn't yet exist. Please
advise. I have spent many hours looking through product brochures and
searching the web and I have found nothing to fit the bill.
Just to clarify, I am asking for product recommendations. If you are
connected to a company which provides a solution, then a sales pitch is
invited.
Thanks in advance,
Tim
John Navas
below?
On 13 Nov 2006 08:50:36 -0800, tyo...@buildingconcepts.com wrote in
<1163436636.8...@e3g2000cwe.googlegroups.com>:
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
tyo...@buildingconcepts.com
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
<1163440066.7...@f16g2000cwb.googlegroups.com>:
>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.
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 <http://openvpn.net/>), or VPN support built into the host OS
(e.g., PPTP).
See also HotSpotVPN <http://www.hotspotvpn.com/>
Jeff Liebermann
>Pretty much everything listed there is on a smaller scale than what I'm
>looking for ...
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...
--
Jeff Liebermann je...@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
tyo...@buildingconcepts.com
what I am looking for.
1 WPA-like I said the key would be too complicated for me to force end
users to change it frequently (they would not be happy having to do it,
especially as when I change the key on my end it kicks off all users
who have yet to change). Further, lack of end user expertise
translates to dollars spent on supporting IT personnel.
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
<1163450172.4...@e3g2000cwe.googlegroups.com>:
>Unfortunately for my situation those alternatives don't really provide
>what I am looking for.
>
>1 WPA-like I said the key would be too complicated for me to force end
>users to change it frequently (they would not be happy having to do it,
>especially as when I change the key on my end it kicks off all users
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.
>who have yet to change). Further, lack of end user expertise
>translates to dollars spent on supporting IT personnel.
That will be an issue no matter what you do.
>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.
IPSEC isn't the only choice -- read what I wrote more carefully.
>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.
That's going to happen no matter what you do.
>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.
Then they probably won't support other forms of security.
> 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.
MAC *isn't* a viable authentication option -- too easily spoofed.
>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.
See above.
>I don't see why there couldn't be a seamless way to add SSL VPN
>capability to a captive portal.
Then you need to bone up on how VPN works. There's no way for a gateway
to switch all connections into SSL mode.
>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.
It's not reasonable -- security depends on support in the device.
--
tyo...@buildingconcepts.com
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
Stuart Miller
see things a bit differently.
I may be mistaken on a few things, but here goes...
<tyo...@buildingconcepts.com> wrote in message
news:1163436636.8...@e3g2000cwe.googlegroups.com...
> Hello All,
>
> I am looking for a solution to provide wifi access in a multi dwelling
> residential unit such that it provides as many of the following points
> as possible:
>
> 1 When a user connects for the first time they see a page displaying a
> usage policy and a login screen. Guest login is allowed, but
> registered login is optional and recommended, passwords and logins
> administered through the building management.
>
> 2 The Network Access Controller to provide the ability to throttle down
> guest connections to around 256k down, 128k up, while leaving
> registered users' connections a great deal more robust.
>
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
> 3 Connection is simple for the end user and requires no VPN client
> software.
>
Usual windoze idiot-proof connections...
> 4 The connection is nonetheless secured in a responsible fashion
conflicts with above, so separate them
>
8<---------------------------------
How do you intend to service these clients? Specifically, what kind of
internet connection will you have?
Does your ISP allow you to sub-let your connection?
What about spammers who use your unsecured connection to do their stuff?
Stuart
Frazer Jolly Goodfellow
news:o2nhl2lrdo6kaof4v...@4ax.com:
> 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, ...
>
>
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?
John Navas
<no-...@hotmail.com> wrote in <Xns987AF3...@80.5.182.99>:
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.
Frazer Jolly Goodfellow
> On Mon, 13 Nov 2006 23:58:58 GMT, Frazer Jolly Goodfellow
> <no-...@hotmail.com> wrote in
> <Xns987AF3...@80.5.182.99>:
>
>>John Navas <spamf...@navasgroup.com> wrote in
>>news:o2nhl2lrdo6kaof4v...@4ax.com:
>>
>>> 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, ...
>>
>>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?
>
> 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.
>
So what's the point of encryption if wireless isolation hides your
network traffic?
John Navas
<no-...@hotmail.com> wrote in <Xns987B79...@62.253.170.163>:
>John Navas <spamf...@navasgroup.com> wrote in
>news:qv3il25c99gs95tr8...@4ax.com:
>> 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.
>
>So what's the point of encryption if wireless isolation hides your
>network traffic?
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.
Jeff Liebermann
>> With wireless isolation, even if someone
>> unauthorized authenticates, they still won't be able to see your
>> other network traffic.
>So what's the point of encryption if wireless isolation hides your
>network traffic?
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.
John Navas
<je...@comix.santa-cruz.ca.us> wrote in
<5g0kl2hm0oacjvqe4...@4ax.com>:
>Frazer Jolly Goodfellow <no-...@hotmail.com> hath wroth:
>
>>> With wireless isolation, even if someone
>>> unauthorized authenticates, they still won't be able to see your
>>> other network traffic.
>
>>So what's the point of encryption if wireless isolation hides your
>>network traffic?
>
>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.
More than "implies" -- it actually works to isolate wireless hosts.
>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.
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*.
>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.
It's not a matter of traffic -- it's a matter of access.
>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.
The major use is actually to prevent one wireless host from being able
to access (attack or otherwise compromise) another wireless host.
Frazer Jolly Goodfellow
> 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).
>
I'm thoroughly confused now. The reference you cite in your warnings
re WPA can be less secure than WEP -
http://wifinetnews.com/archives/002452.html
- contradicts the above. Specifically the summary states:
"... if a weak passphrase is used, for example, a short passphrase,
an offline dictionary attack can readily guess the PSK. Since the
common usage will be a single PSK for the ESS, once this is learned
by the attacker, the attacker is now a member of the ESS, and the
whole ESS is compromised. The attacker can now read and forge any
traffic in the ESS."
Jeff Liebermann
>More than "implies" -- it actually works to isolate wireless hosts.
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".
>>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.
>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.
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.
>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).
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:
| http://www.aircrack-ng.org/doku.php?id=airdecap-ng
| http://www.wirelessdefence.org/Contents/Aircrack-ng_WinAirdecap.htm
I also tried decrypting the capture file with WireShark:
Edit -> Preferences -> Protocols -> IEEE 802.11
and supply the WEP/WPA key.
in reference to another question in this newsgroup. In both cases, I
was able to read plain text in the capture file, so I assume that it
worked.
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...)
>The insecurity of PSK is thus a matter of *authentication* (wireless
>network access), not *encryption*.
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.
>It's not a matter of traffic -- it's a matter of access.
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.
>>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.
>The major use is actually to prevent one wireless host from being able
>to access (attack or otherwise compromise) another wireless host.
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
<je...@comix.santa-cruz.ca.us> wrote in
<ld9kl21rgjftj6vjm...@4ax.com>:
>John Navas <spamf...@navasgroup.com> hath wroth:
>
>>More than "implies" -- it actually works to isolate wireless hosts.
>
>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".
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. :)
>>>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.
>
>>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.
>
>I was thinking of a coffee shop environment, where no encryption is
>used.
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.)
>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.
You're confusing the WPA access pass-phrase with the session encryption
key. (But see below.)
>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.
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.)
>>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).
>
>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.
That's what I've been saying. (But see below.)
>Well, I just finished doing
>exactly that with airdecap-ng:
>| http://www.aircrack-ng.org/doku.php?id=airdecap-ng
>| http://www.wirelessdefence.org/Contents/Aircrack-ng_WinAirdecap.htm
>I also tried decrypting the capture file with WireShark:
> Edit -> Preferences -> Protocols -> IEEE 802.11
> and supply the WEP/WPA key.
>in reference to another question in this newsgroup. In both cases, I
>was able to read plain text in the capture file, so I assume that it
>worked.
>...
>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.
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. <http://www.tamos.com/htmlhelp/commwifi/wpa.htm>
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.
John Navas
<no-...@hotmail.com> wrote in <Xns987BD4...@80.5.182.99>:
Correct. I was relying on previous bad information. Sorry.
Frazer Jolly Goodfellow
> On Tue, 14 Nov 2006 20:52:09 GMT, Frazer Jolly Goodfellow
> <no-...@hotmail.com> wrote in
> <Xns987BD4...@80.5.182.99>:
>
>>John Navas <spamf...@navasgroup.com> wrote in
>>news:p73kl2tgiui02r3e1...@4ax.com:
>>
>>> 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).
>>
>>I'm thoroughly confused now. The reference you cite in your
>>warnings re WPA can be less secure than WEP -
>>http://wifinetnews.com/archives/002452.html
>>- contradicts the above. Specifically the summary states:
>>"... if a weak passphrase is used, for example, a short
>>passphrase, an offline dictionary attack can readily guess the
>>PSK. Since the common usage will be a single PSK for the ESS,
>>once this is learned by the attacker, the attacker is now a
>>member of the ESS, and the whole ESS is compromised. The
>>attacker can now read and forge any traffic in the ESS."
>
> Correct. I was relying on previous bad information. Sorry.
>
No problem, thanks for clearing it up for me.
Axel Hammerschmidt
> On Tue, 14 Nov 2006 12:45:36 -0800, Jeff Liebermann
> <je...@comix.santa-cruz.ca.us> wrote in
> <ld9kl21rgjftj6vjm...@4ax.com>:
>
> >John Navas <spamf...@navasgroup.com> hath wroth:
> >
> >>More than "implies" -- it actually works to isolate wireless hosts.
> >
> >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".
>
> 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. :)
In 802.11-speak these are called stations (STA).
Jeff Liebermann
Yep. From 802.11-1999:
3.42 station (STA): Any device that contains an IEEE 802.11
conformant medium access control (MAC) and physical layer
(PHY) interface to the wireless medium (WM).
http://standards.ieee.org/getieee802/802.11.html
Not terribly useful or clear. I'll stay with "client adapter" if you
don't mind.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 je...@comix.santa-cruz.ca.us
# http://802.11junk.com je...@cruzio.com
# http://www.LearnByDestroying.com AE6KS
tyo...@buildingconcepts.com
come to a reasonable conclusion for the time being.
After being shown products which can broadcast in both open mode and
wpa-psk mode without cost-prohibitive increases in architecture I have
decided the best solution would be to allow an open connection to the
captive portal which would then allow a guest to register for a
temporary username/password and issue them the wpa psk key (keeping the
key relatively secured rather than publicly posted, changeable without
too much fuss, and requiring one more level of security through the
login process before resources may be used).
Upon receiving the above information the guest will then switch to the
secured connection used by the regular tennants. AP separation will be
employed for obvious reasons. Any non wpa compliant wireless equipment
will be considered deprecated and no support will be provided for it
(though perhaps an exception could be made by implementing a walled
garden setup on the unsecured network i.e. a non-wpa phone could be
allowed to reach its sip provider at a specific ip address/port which
would not be useful for someone looking to use the open network
improperly and that address/port would not be published anywhere).
Thus the solution meets the conditions needed. It allows both tennants
and guests access to the network that is encrypted over the air, and
yet their primary point of contact is a web portal with clear, concise
instructions and the phone number for a centralized help desk in case
of issues.
One specific manufacturer providing the means to implement such a
solution is Colubris.
Thank you all for your time and input.
Tim
John Navas
On 16 Nov 2006 09:23:10 -0800, tyo...@buildingconcepts.com wrote in
<1163697789.7...@f16g2000cwb.googlegroups.com>:
--