New cipher in RSN IE
Fri Nov 27 01:04:15 PST 2009
Thanks for the reply !
I did not mean the new cipher suite type value would be 6, it is
likely to be anything between 6-255, and I would make sure the
collision would not take place. Is there a way to know what are the
reserved values that have been already taken? Any idea on what cipher
suite type the value "6" corresponds to?
My only goal is to see the the new cipher suite type in RSN IE
contained within the probe response or beacon frame, and for that
changes in hostapd would suffice? I am aware of that to accomplish the
confidentiality in the data path using the the new cipher, I need to
make changes in the driver code.
On Fri, Nov 27, 2009 at 2:06 PM, Jouni Malinen <j at w1.fi> wrote:
> On Fri, Nov 27, 2009 at 09:47:40AM +0530, alan furlong wrote:
>> I am using hostapd-0.6.9 with madwifi(0.9.4) on Linux Fedora. I intend
>> to introduce a new cipher using suite type anything between 6-255
>> (reserved), so that beacons or probe response would contain the RSN IE
>> with this new cipher suite type.
> I would strongly discourage using those reserved values for something
> that is not defined by IEEE. Vendor-specific OUI should be used instead
> when defining other ciphers. By using those "reserved" values, you
> easily end up conflicting with something else (as an example, the value
> 6 that you listed as reserved has already been used).
>> Would it suffice to make changes only in hostapd code to accomplish
>> above? OR I need to look at madwifi code too? I would appreciate if I
>> could pointers on same.
> hostapd does not take care of actually frame encryption/decryption, so
> you would need to implement that in the driver.
> Jouni Malinen ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PGP id EFC895FA
> HostAP mailing list
> HostAP at lists.shmoo.com
More information about the Hostap