Re: [PATCH 6/7] mac80211: Parse RSN information element to determine if a peer needs authentication

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2011-03-04 at 11:06 -0800, Javier Cardona wrote:
> On Fri, Mar 4, 2011 at 3:37 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Thu, 2011-03-03 at 19:11 -0800, Thomas Pedersen wrote:
> >> From: Javier Cardona <javier@cozybit.com>
> >
> > [...]
> >
> > If you manage stations in userspace, then this code is unnecessary.
> > That'd be a big win in my eyes. The only thing the kernel would need to
> > know is not to create station entries, right?
> 
> If userspace manages only rsn mesh stations then we do still need
> this.  That would be my preference:  only require an authentication
> daemon if you intend to join a secure mesh.  In the same way that you
> can connect to an open AP without a daemon.
> Would you object to this approach?

No, I wouldn't, but I don't see why you'd still need this? I'm not sure
exactly how all this works, but conceptually, is there anything wrong
with this:
 * when creating the mesh, you'd say "this is a secure mesh"
 * when an auth frame is received, you just pass it to userspace, as you
   already have
 * userspace is responsible for adding/removing stations
 * the kernel doesn't need to parse RSN since if it's a secure mesh it
   will know because userspace said it was


Actually, looking at your patch in more detail, it would seem like it
allows somebody to hijack the mesh by pretending it is an open network.
If the RSN IE isn't present, mesh_neighbour_update() gets passed false
for the rsn_enabled parameter -- even if the mesh should be secure --
and then the peer would be allowed to join just because it said it
didn't support RSN. Surely in that case it shouldn't be allowed to join?
Maybe I'm not reading this correctly.

johannes