Search Linux Wireless

Re: [ipw3945-devel] [PATCH 1/5] mac80211: allows driver to request a Phase 2 key

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >  > This is actually quite a bug in mac80211. There is substantial
> >  > difference between dynamic and static key.
> >  > While static key  is used for crypto of all stations in BSS. Dynamic
> >  > key is also called pairwise key and is generated for 'pair'
> >
> >  Gee, can you then please stick to terminology used in the spec so other
> >  people can understand it?
> 
> What spec. ieee80211i. WPA, WPA2? .

Preferably one that is actually readable to mere mortals (unlike WPA...)

> >  Actually, you're making it look like a much larger problem than it is.
> >  If you assume anything WEP is a "static key" and everything else is a
> >  "dynamic key" (using your terminology), the only problem will be with
> >  dynamic WEP, and even then it's not really a problem because as far as I
> >  understand even dynamic WEP doesn't distinguish between group and
> >  pairwise keys.
> 
> This is incorrect.  WPA enable using WEP as dynamic key and this
> setting is very common.
> WEP key is enabled for legacy stations this force also broadcast to be
> WEP.  This setup is still quite common.

I have no idea about WPA's non-IEEE modes. I don't seem to be able to
find such a thing in the IEEE spec so you'll have to actually elaborate
on this.

> >  In any case, actual TX key selection is done by mac80211 anyway, so
> >  you're never interested in that. Only RX key selection is interesting to
> >  the driver, and as far as I can tell it ought to work if you simply
> >  always use the broadcast address key when it's WEP, and otherwise the
> >  pairwise keys and/or the broadcast key for bc/mc frames.
> 
> Nothing to add to just that the assumption about WEP and broadcast is wrong.

> >  Note that there's another case in AP mode where bc/mc keys are TX-only,
> >  those are added with a zeroed MAC address.
> 
> I would prefer also in this case a clear flag rather then playing with
> ambiguity of destination address.

Yes, that would indeed help. Except that WEXT can't actually give you
the distinction so discussing these points right now is pretty moot when
we can't even do it properly as far as I can tell. Might be possible to
infer the information with the key management enabled flag thing...

johannes

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux