Issues with new D-Bus API

[Witold Sowa]

Jouni Malinen pisze:
> On Thu, Jan 07, 2010 at 05:02:20PM +0100, Witold Sowa wrote:
>> Marcel Holtmann pisze:
>>> Either we do "WPA : dict" and "RSN : dict" wich then contains the same
>>> key names from the Interface capabilities.
>>>
>> I have a patch for that almost done, but I have afew I questions first:
>> Is it possible to have other suite than psk or eap in WPA/RSN IE?
> 
> Yes. Unlikely with WPA (but possible), but with RSN, there are number of
> new key management suites defines.
> 
Looking at wpa_selector_to_bitfield and wpa_key_mgmt_to_bitfield in
src/rsn_supp/wpa_ie.c and at rsn_selector_to_bitfield and
rsn_key_mgmt_to_bitfield in src/common/wpa_common.c it seems that we
support following key managements and cipher suites:
For WPA:
PSK, EAP and NONE key management suite. What does mean none? I mean
WPA_KEY_MGMT_WPA_NONE constant. Does it mean that there is no support
for WPA in a BSS? I think that I'm lacking of some basic knowledge, so
please explain me what is the meaning of NONE key management suite in WPA.

TKIP, CCMP, WEP104, WEP40, NONE cipher suite. And again. What does it
mean NONE? Does it mean WPA without a group and/or pairwise cipher? Can
both (group/pairwise) be NONE or only the group cipher?

For RSN:
PSK, EAP key managements and both in three versions: regular, 802.11r
and 802.11w

Same cipher suites as for WPA and additional AES128CMAC. The NONE cipher
is here too again.

We can expose key management suites in DBus either as "psk", "eap",
"psk-ft", "eap-"ft", "psk-sha256", "eap-sha256" or we can just divide
them on two groups "psk" and "eap".

>> Is it possible to have other pairwise ciphers than ccmp or tkip?
>> Is it possible to have other group cipher than ccmp, tkip, wep40, wep104.
> 
> In theory, you could have vendor specific cipher suites. Not that we
> really support them, but as far as the WPA/RSN IE is concerned, it would
> be possible. I would consider just using the suite selector (e.g.,
> 00-0F-AC:4 and encoding it as four octets should be fine) as the
> contents and not try to map it into "ccmp" or some other string (same
> for key management suite).
> 
I think that instead of exposing raw suite octets we could translate
them to strings only if we can support the suite. I would not expose not
supported suites in any way. Most common suites are supported and would
be translated and exposed to clients as strings. In case of not
supported suites client can always parse IEs data itself. That would
apply to both key management and cipher suites.

>> Is it possible to have "none" cipher/suite in any of above?
> 
> What are you referring to with "none"? There is no such cipher suite
> defined in IEEE 802.11.
> 
I am referring to WPA_CIPHER_NONE constant which can be parsed from WPA
and RSN IEs and to WPA_KEY_MGMT_WPA_NONE constant which can be parsed
from WPA IE. Please explain me semantics of these constants.

Regards,
Witek.