[PATCH] dbus: Change WPA/RSNIE byte array props to dicts

[Witold Sowa]

Jouni Malinen pisze:
> Please note that APs may require management frame protection to be
> enabled and there needs to be a way for the client to figure that out.
> Now, it would need to go through the IEs property and parse RSN IE to
> know..
> 
OK, let's add MgmtGroup string entry to RSN dictionary then.

>> I still have some doubts about key management
>> 1) Is it ok to expose all psk suites (PSK, FT_PSK and PSK_SHA256) as
>> the same value "wpa-psk"? Same for wpa-eap
> 
> What would this value be used for? Please note that when adding a
> network, the key_mgmt value will need to either include all allowed
> options or have the correct value. In other words, if the BSS entry has
> "wpa-psk", but the AP is configured to allow only PSK with SHA256,
> key_mgmt=WPA-PSK will not result in connection.
> 
So we need to distinguish key management to wpa-psk, wpa-ft-psk and
wpa-psk-sha256. Same for eap.

>> 2) How should we interpret and expose key management with
>> WPA_KEY_MGMT_NONE flag set in ie_data->key_mgmt?
> 
> This value does not show up in struct wpa_ie_data that is parsed from a
> WPA or RSN IE, i.e., it is only used internally to indicate that
> WPA/RSN/IEEE 802.1X is not used.
> 
> 
>> +	<h3>WPA - a{sv} - (read)</h3>
>> +	<p>WPA information of the BSS. Empty dictionary indicated no WPA support. Dictionary entries are:</p>
>> +	  <tr><td>KeyMgmt</td><td>as</td><td>Possible array elements: "wpa-psk", "wpa-eap", "none"</td>
> 
> What is "none"? Is this referring to WPA-None? If so, it should be
> renamed.
> 
Yes, I'll rename it to wpa-none

>> +	<h3>RSN - a{av} - (read)</h3>
>> +	<p>RSN information of the BSS. Empty dictionary indicated no RSN support. Dictionary entries are:</p>
>> +	  <tr><td>KeyMgmt</td><td>as</td><td>Possible array elements: "wpa-psk", "wpa-eap", "none"</td>
> 
> "none" is not a valid value for KeyMgmt in case of RSN.
> 
ok.

> In addition, an array of suite selectors would be clearer way
> to indicate the exact values used in the BSS. If we need to use some
> kind of simplified version of that, the documentation should describe
> how the real value is mapped to these possible values used here. It
> should also be understood that this is a one way mapping and you cannot
> get from this value to correct network configuration block with explicit
> key_mgmt parameter needed by some drivers.
> 
Assuming that we add wpa-ft-psk, wpa-ft-eap, wpa-psk-sha256 and
wpa-eap-sha256 key management values for RSN, I think that we can do one
to one mapping from cipher/amk suite oui to string. Am I missing something?
String mapped values are
1) much more human readable then OUIs
2) easy comparable to Interface.Capabilities values.

>> -	<h3>WPSIE - ay - (read)</h3>
>> -	<p>WPS information element of the BSS. The second byte contain number of bytes following it.</p>
>> +	<h3>IEs - ay - (read)</h3>
>> +	<p>All IEs of the BSS as a chain of TLVs</p>
> 
> It might be worthwhile to continue including the WPSIE, or well, rename
> it to WPSTLVs etc. since it may be concatenated from more than one WPS
> IE. Alternatively, we should consider adding another property for
> providing some parsed WPS information so that the client would not need
> to use IEs to figure out whether WPS is enabled in the BSS.
> 
We can do that, but I thought that we settled earlier that we add some
parsed WPS information later, when clients will start to use WPS.

Regards,
Witek.