James Carlson wrote:
> Anurag Maskey writes:
>
>> Rather than using the nwam-ESSID-BSSID as it currently does, nwam will
>> create a MD5/SHA1 (which one?) hash of the name(s) that it will use for
>> the names of secure objects. The name is be "nwam_hash". If the
>> tunable nwamd/strict_bssid from CR 6773627 is set, then the hash will be
>> of the string "ESSID-BSSID" ('-' between the two values), otherwise the
>> hash will be just "ESSID". Since libdladm has a length restriction of
>> DLD_SECOBJ_NAME_MAX (32) on the names, only the first 27 from the
>> characters from the hash will be used in the secobj name.
>>
>
> Does this mean that when I set or reset strict_bssid, I lose my keys?
>
> The current NWAM code still differentiates on BSSID, even after CR
> 6773627. I haven't redesigned that. I'm not so sure that new flag
> should affect how key objects are named.
>
"hash" in this text can be replaced whatever we choose: hash, encoding,
CRC, etc, etc.
Are we always hashing ESSID-BSSID? If so, then a user cannot roam
multiple WEP/WPA protected AP's which the same ESSID.
So, my idea was to use the fact that the user has indicated how strictly
s/he wants the ESSID/BSSID pair to be considered. If the user says
strict_bssid, then use both to generate the name. The user won't be
able to roam. If not_strict_bssid, then only the ESSID is used to
generate the name and the user can roam.
This means going from strict_bssid to not_strict_bssid or vice versa
would make the previously generated key names useless for NWAM.
> ("nwam-" is enough -- no need to add the
> word "hash", but perhaps a hash function name would help)
"hash" was supposed to be replaced with the computed hash. I should
have said "nwam-$hash", where $hash =
some_hash_function(some_combination_of_ESSID_and_BSSID).
>
>> The second situation is where there are secobjs already out there that
>> don't follow the character restrictions (either through nwam or dladm).
>> These could contain @*% and other characters. These secobj's should
>> still be allowed to be loaded by dladm, and used by both dladm and
>> NWAM. Thus, NWAM will need to failover to the current nwam-ESSID-BSSID
>> naming scheme if the new nwam_hash scheme fails when it tries to connect
>> to a WEP/WPA network.
>>
>
> I'd rather see the start-up script for the 'network/physical:nwam' SMF
> service search for those old secobj values and rename them. (Too bad
> there's no 'rename-secobj' function ...)
>
Yes, we can rename (delete+create) the names, but we don't know how much
was truncated from the secobj name. Then, nwam may not be able to use
that secobj. (And we'll get a bug from a user saying "nwam asks for key
even though I already entered and was able to use it until today").
We'd have to keep the old secobj also around for the failsafe.
Anurag
> Failing that, continuing to use use the object under the old name if
> it's found (but never creating new ones that way) seems ok.
>
>
_______________________________________________
networking-discuss mailing list
[email protected]
