So, looks like we have consensus on the characters: a-zA-z0-9_ (no need
for other characters according to the proposal below).
Here's a proposal from NWAM to create secure object names from the
discussions in this thread:
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.
Let's say, there's agreement on the above naming scheme (or some
variation of it). There's still a question of what to do with secure
object names that are already out there.
There are ones that don't work (with spaces from the ESSID), so the user
probably has already switched to a ESSID/secobj with no spaces. The
user also could not use dladm because the secobj's cannot loaded into
the kernel.
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.
Comments?
Anurag
Peter Memishian wrote:
> > Going back to what this thread was about: what characters to allow in
> > secobj names?
> >
> > 1. Are we allowing just alphanumeric and '_' for the secure object
> > names? What about '-' and '.' which are already used explicitly by NWAM?
>
> I think it's OK to allow those if it'd be useful to NWAM.
>
> > 2. What's the plan of action for secobj names that will be invalidated
> > by the implementation of (1)?
>
> It's only really an issue for upgrade, right? If the user has to re-input
> their key in the case where their ESSID used characters that are invalid
> for a secobj, that doesn't seem so bad, at least based on where we are
> with Indiana these days.
>
>
_______________________________________________
networking-discuss mailing list
[email protected]
