Using hostapd behind the AP (on the wired side)

[Bryan J. Smith]

On Mon, 2005-09-26 at 20:43 -0400, Bryan Kadzban wrote:
> I assume s/WAP/WPA/g, right?  ;-)

Oh, yeah, right.  Great, already off to a great start!
Well, at least we share the fact that we spell our names correctly.  ;->

> If so, I'm not sure this is possible, though I don't know for sure.  The
> existence of encryption probably means the AP *MUST* be involved; if
> it's not, it can't find out the pairwise key that the RADIUS server
> generates, which means it won't be able to decrypt the directed traffic
> from the STA in question.

Understand that.  Let me restate/refocus my question, my primary
interest is actually in authenticating a node, not encryption.  For
encryption, I'll rely on the capabilities of the AP.

Know that even though this "solution" might work for standard 802 APs,
it is also going to be designed for proprietary APs as well.  But even
then, it would be nice to have a way to dynamically hand out new WEP
keys for older, WEP-only APs.

> It also has to have a hand in handing out the group key, since I believe
> it's the only participant that knows that key.

In our case, we might be doing an HTTP PUT to the AP from the wired
interface to upload the new WEP key to the AP, as well as sending them
out to the associated nodes.  Again, that's really secondary.  Our
primary interest is in establishing authentication behind the AP.

If that means -- in the worst case -- the legacy, WEP-only AP is in
"Open System" mode as the node associates so it can see local traffic,
that's tolerable.  We'll block it beyond the AP.  But this solution will
also be catering as an augmentation for various APs to use -- possibly
on the AP itself.

> Unless you're going to hand out basic WEP keys (where the group key ==
> the pairwise key, and everyone uses the same pairwise key); then that
> might work.

Yep.  Again, our focus is more on authentication than encryption.
Especially for non-802.11a/b/g APs.

> (Assuming you change the key in the AP whenever you change
> the key you hand out in the EAP exchange, with e.g. an HTTP POST if need
> be.  And with WEP, you should probably change keys every few minutes.
> Which means you'll need to trigger a reassociation or a reauthentication
> somehow, every few minutes, so that all the clients get the same new WEP
> key.)  But there's still an issue:
> The clients won't even know to *attempt* EAP, unless you can modify the
> (non-WPA-capable) AP's beacons and probe responses.  You'd have to add a
> WPA or RSN IE, with key management set to 802.1x, to the normal set of
> IEs.  If that's not there, then standard STAs won't even attempt EAP.

Correct.  This would be something that is _forced_ -- i.e., explicitly
configured -- on the client, not auto-negotiated.  Which brings me
really to what I'm looking for ...

Is it even possible?  I was hoping so.  I know this seems rather
broad/generic of a question, but I just didn't want to get too deep into
using hostapd if it wasn't possible for an STA to reach a node on the
wired portion of a bridging AP at all.  I assume it always is,
especially if the frames are 802.1X.

> (You might also have to modify the association response, I'm not sure on
> that.)

That's fine.  We have our own peer-to-peer replication, because we work
on mesh (i.e., the backend might not be, and typically isn't, available
for authenticating anyway).  So adding additional chat is not an issue.

> Again, standard WPA STAs won't even attempt to do EAP unless the beacon
> or probe response (and maybe association response) tells them to.  So
> you'd have no way to eventually allow that client to pass traffic.

Can you force a client to sent it regardless, if the client is so
explicitly configured?  Again, I'm new to all this, but I've seen WPA in
action from a normal setup.  I'm trying to go beyond normal, where the
AP can be augmented with limited capabilities.

> Unless you're going to rewrite the STA code as well -- then, I'd think
> you can pretty much do whatever you want, and get it to work.  ;-)  You
> could even WEP-encrypt the EAP exchange, if you really wanted to (though
> that wouldn't give you much in terms of security; TTLS is much better).

Indeed.  I'm still trying to come up with what is and isn't feasible.
In the end, we're probably going to use hostapd on our product directly.

But for now, we're also seeing what we can do with a "drop in sister
node" beyond an AP that has limited capabilities.

Especially for proprietary APs for more standalone mesh situations.
Something where the AP might already be RADIUS enabled and have it's own
chat with the clients.  I think the solution we're looking for is tied
to a problem that is too broad among both standard and proprietary APs
to make generic enough.


-- 
Bryan J. Smith     b.j.smith at ieee.org     http://thebs413.blogspot.com
----------------------------------------------------------------------
The best things in life are NOT free - which is why life is easiest if
you save all the bills until you can share them with the perfect woman