Thu Nov 30 08:29:03 PST 2006
Hi Bryan -
Thanks again for the excellent answers :)
Succinctly, I don't care about who the clients are, I'm not running any software on the client side (otherwise this would all be moot, I could configure it myself from there), and even having the initial handshake in plaintext would be acceptable if the rest of the connection is within a pipe. Yeah, I know, not very cryptographically secure, but that's what the mgmt's looking for.
Therefor, I'm willing to play a bit silly with the EAP protocol, or really any other component of the exchange, as long as the end result is a not-directly-sniffable transport.
On Thu, Nov 30, 2006 at 07:11:57AM -0500, Bryan Kadzban wrote:
> Benn wrote:
> > Thanks for the well crafted answer, that was basically what I
> > expected to hear, but was hoping otherwise :) The interesting thing
> > is, the client is definitely sending out some kind of packet which
> > gets turned into a request to the radius server:
> Yes, these frames show up with any EAP type. EAP starts with a frame of
> type "request-identity" from the AP, and the client responds with a
> "response-identity" frame that has the username in it (but nothing else,
> so you *can't* make security decisions based on just that info). That's
> the frame that you're seeing here.
> > received EAP packet (...) from STA: EAP Response-Identity (1)
> Or at least, that's what hostapd thinks. :-) (And I agree with it.)
> > EAP-Message = 0x0201000501
> Yep, this looks like the tiny message at the start of an EAP exchange.
> > Now, ideally I would somehow encourage the radius server to send back
> > a "yup, all good" reply (or modify the internal-to-hostapd radius
> > server to do the same), hostapd would consider everything kosher, and
> > we'd be off.
> But all it knows is the username. You have no idea that this is
> actually the user that it claims to be. Anyone else that sniffs that
> username (because it is sent in the clear) can immediately connect as
> the user. ;-)
> > Any other day, that'd probably be perfect. The operational
> > requirements however are "0 user input". Cheatings acceptable,
> > fractured security is even somewhat acceptable, as long as the
> > traffic is not directly sniffable, or so the management says.
> Well, the EAP Request-Identity frame is sent in the clear, so it is
> directly sniffable. If you want something that isn't, you'll need to
> set up some kind of encrypted tunnel, which is what PEAP does. Or,
> you'll need to set up some other EAP type (e.g., in a Windows domain,
> you can set up a cert server that will automatically issue certs to each
> machine; then you might be able to somehow automatically use these certs
> for wireless without user input; this requires a lot of control over the
> client, though).
> I assume you're using some kind of API on the XP machine to add this
> network, right? Doesn't that API have a way to either turn off cert
> validation or to select a (set of) cert(s)? I mean, your users aren't
> going to be able to connect to this network without selecting it, so
> there will have to be *some* input at some point. Right?
More information about the Hostap