Startup problems

[Bryan Kadzban]

Christian Frankerl wrote:
> 
> I want to configure an AP for my parents. They should connect from 
> WindowsXP to the linux AP.
> 
> How should i solve the security problem? Should i use OpenVPN or can
> i use hostap if there are WindowsXP clients too? Can i use the RADIUS
> solution with WindowsXP? Is RADIUS only the authentication sytem or 
> does it encrypt the connection too?

RADIUS isn't exactly the authentication system, but it's close enough.
To be pedantic, the authentication protocol is EAPOL (EAP over LAN),
which is also called 802.1x.  (Or at least, that's the authentication
protocol used between the supplicant (the wireless device) and the
access point.  Between the access point and the authentication server,
the protocol used is RADIUS.  But those RADIUS packets are tunnelling
EAPOL packets.)  And no, it doesn't do encryption on its own.

Anyway, the first thing to realize is that authentication is orthogonal
to encryption.  Your choices for encryption are WEP, TKIP, and AES
(ordered by security, increasing -- AES is the most secure, and WEP is
the weakest).  Your choices for authentication are nothing, shared-key
(WEP), pre-shared-key (TKIP or AES), or WPA/WPA2 (any encryption
algorithm).

Shared-key and pre-shared-key authentication are basically "if the
wireless device knows the key, it can connect".  Shared-key is actually
less secure than no authentication (sometimes also called "open system"
authentication), because basically what happens is the AP sends a random
bitstring to the client, and the client sends it back, encrypted by the
WEP key.  If the encryption is performed successfully, the client is
allowed onto the network.

The problem is, an attacker can intercept both packets (the bitstring
and its ciphertext), and I believe that allows the attacker to derive
the WEP key directly.  (That may be incorrect, though, I'm not sure.)
Otherwise (with open system auth), an adversary would still have to know
the WEP key (if packets are encrypted with the wrong key, they're
dropped), but they'd have to capture about 3-4 minutes worth of packets
to find it.  Not just 2 packets.

Pre-shared key (with TKIP or AES) is *much* more secure, and it doesn't
require anything more than shared-key or open-system with WEP -- i.e.,
basically you only need to know the key/passphrase/password/whatever.
(Actually you also need to know the SSID, because the master keys depend
on both the pre-shared key value and the SSID, but whatever.)  You
program that value into your client, and you'll get on the network.

But none of these methods provide positive identification of the client.
All they can prove is that the client knows the key -- and anything with
pre-shared keys is vulnerable to an offline dictionary attack on the
pre-shared key itself.  (I.e., an attacker can capture a WHOLE LOT of
packets, and from those packets, try an exhaustive search for the
pre-shared key.  Eventually they'll find it (the time required is
longest for AES), so you need to have changed it by the time they do.
Changing it is as hard as changing WEP keys, because you have to change
every device at the same time.)

If you need positive identification of the client, then you start to get
into what some AP vendors call WPA-Enterprise or WPA2-Enterprise.
Basically, that's TKIP or AES encryption (TKIP for WPA, AES for WPA2),
along with EAPOL/RADIUS for authentication.  You need a RADIUS server
running somewhere on your network for any of these EAP types.

There are several EAP types that rely on usernames and passwords.  If
the client knows the password, they'll be authorized.  The problem with
those methods are weak passwords -- anything that's easy to remember is
usually pretty weak.  And you *DON'T* want your users writing their
passwords down, so you want them relatively easy to remember.

Anyway, some of these EAP types (EAP-MD5, EAP-PAP, EAP-CHAP, EAP-MSCHAP,
EAP-MSCHAPv2) are fairly insecure -- the encryption of the password is
fairly weak.  However, there are also EAP-PEAP and EAP-TTLS -- "tunnel"
EAP types.  You can put any secondary EAP type inside a PEAP tunnel
(EAP-MSCHAPv2 is popular), and you can put any RADIUS type at all inside
an EAP-TTLS tunnel.  Both of those tunnels use SSL-equivalent security
for the encryption of the contained credential exchange.  Both require
an SSL certificate on the RADIUS server, and the client must trust that
cert.

There is one other EAP type, which isn't based on passwords -- EAP-TLS.
It requires a cert on the RADIUS server (just like TTLS and PEAP), but
it also requires one on all the clients.  The server and client go
through the normal TLS (SSL) exchange, and the server checks the
client's cert against something.  In Microsoft's IAS (their RADIUS
server), the cert must be mapped to the machine or user account, it must
be signed by a trusted root cert, and it must not be on any CRL.  In
FreeRADIUS, the cert must be signed by the cert that FreeRADIUS is
configured to trust (and if configured, FreeRADIUS will check CRLs too).
If the client's cert passes the check, then the client will be
authorized.

I think EAP-TLS is much more secure, because the private key for a
certificate has much more entropy than an average password.  (A 1024-bit
private key (which is small) is about equivalent to 128 bits of entropy,
which is about a 16-character password, if you assume each byte value is
equally probable for each byte of the password.  I don't believe that's
actually the probability, though; I think the entropy of a 1024-bit
private key is closer to a typical 32-character password.  But that's a
personal view; I doubt anyone else would agree with it exactly.)

EAP-TLS and EAP-MSCHAPv2 (I think) also allow the RADIUS server to
generate a different encryption key (for WEP, TKIP, or AES) for every
client.  This is much better than pre-shared keys, because the key
changes every time reauthentication happens.  (And it's different on
different clients.)  If an attacker compromised a key through some kind
of exhaustive search on captured packets, the client would almost
assuredly have changed keys already, and the captured key wouldn't do
the attacker any good.  (Unless you're using WEP, because those keys can
be found pretty quickly now.)

Right, so enough of that.  You could use VPNs to encrypt your traffic,
yes, but that won't necessarily restrict who may connect to the wireless
itself (but EAP will).  XP does support WPA-Enterprise with SP1 or SP2
(can't remember which), and it supports WPA2-Enterprise with a freely
available download from Microsoft (first hit on Google for "microsoft
wpa2 update" -- article #893357).  Your wireless devices and drivers
have to support the encryption method you choose (almost everything
supports TKIP, but AES is better if you can do it).  But the EAP stuff
can be handled by XP itself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20050921/495318dd/attachment.pgp