hostapd

[Sergio M. Ammirata]

> -----Original Message-----
> From: hostap-admin at shmoo.com [mailto:hostap-admin at shmoo.com] On Behalf
Of
> Jacques Caron
> Sent: Tuesday, December 24, 2002 2:40 PM
> To: Sergio M. Ammirata
> Cc: 'hostap mailing list'
> Subject: Re: hostapd
> Importance: High
> 
> Hi,
> 
> At 17:04 24/12/2002, Sergio M. Ammirata wrote:
> >2)      Is there a way to enable a rotating key with the m option. I
dont
> >care about authenticating based on the 802.1X against a radius
server, I
> >just want to leverage the rotating key functionality if the client
> >supports it to at least prevent WEP password cracking.
> 
> I don't know the details of the hostapd implementation, but I don't
quite
> see how key rotation could happen without 802.1X: EAPOL-Key frames are
> part
> of 802.1X, and they rely on the session key negotiated between the
> supplicant (client) and the auth server (RADIUS server) within the
> selected
> EAP method. Without this, anybody could decrypt the key sent and this
> would
> not be very useful, would it?

I am not suggesting that we do a proprietary key exchanging mechanism. I
am suggesting that hostapd be enhanced to do what the radius server does
as far as key rotation. Perhaps starting with a random key for each
client and keeping track of the key changes per client.

That way if a client supports 802.1X it can be leveraged for key
rotation.

> The only other option is to have the AP and client be synchronized on
keys
> that change at regular intervals, using a pre-shared seed. But that's
a
> totally different thing.

Any proprietary method of key exchange would require special client
software. The idea is to leverage existing Windows, MAC and linux
clients that already have support for 802.1X without having to have a
complex authentication setup.

> >3)      Is there a way to leverage the radius client inside hostapd
to
> >authenticate the MAC address for association? Right now the two
options
> >are either to allow open access or to authenticate against a list of
MAC
> >addresses that gets populated with iwpriv wlan0 wds_add
MAC-goes-here.
> The
> >idea is to be able to use a central server for global authentication
of
> >MAC addresses throughout a network of Access Points without having to
> >maintain the same list in each of them. I know that 802.1X does this
but
> >the idea is to not have to require it on the client side. Perhaps it
can
> >use radius with the MAC as Username and Password and hit the radius
> server
> >using PAP.
> 
> The big problem with MAC addresses is that they are so easy to change
that
> it doesn't even qualify as a security feature, and certainly not for a
> large-scale setup where you need/use a central auth server.

I agree that this layer of security is easily hackable. But why discard
it? It will detour at least the roaming users that are not supposed to
link to your network. 

> >4)      How does the radius client inside hostapd communicate with
the
> >server? Is it PAP, CHAP, MsChapV2 or am I way off in understanding
how
> >this works?
> 
> Errr... RADIUS? And within RADIUS, EAP messages (exchanged between the
> supplicant and the auth server) are encapsulated in the appropriate
AVPs.
> And EAP messages themselves can use one of several different methods,
the
> most common being EAP-TLS, but there's also EAP-MD5 (to be avoided),
> EAP-OTP, EAP-SRP, PEAP (with another protocol within, like
EAP-MSCHAPv2),
> etc. Hostapd is transparent to those message, it just passes them
between
> the supplicant and the auth server, just changing the encapsulation
(EAPOL
> aka 802.1X on one side, RADIUS on the other).

I guess it will not be as simple to emulate the radius server for the
EAP messages.

However, for the custom MAC address authentication against a radius
server, the hostapd program can create a few simple Radius Value Pairs
that emulate PAP authentication and then parse the response.

Sergio