WinXP+PEAP+Cert Behavior

[Benn]

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.

Any suggestions?
--B

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?
>