On Tue, Aug 24, 2010 at 3:33 PM, Jeffrey Hutzelman <[email protected]> wrote: > --On Tuesday, August 24, 2010 02:10:34 PM -0400 Jeffrey Altman > <[email protected]> wrote: > >> I support this change. It is after all the PTS servers responsibility >> to understand whether two names refer to the same PTS ID. If the PTS >> server wants to treat all existing Kerberos v4 names as automatically >> having synonyms that are Kerberos v5 and GSS-KRB5 name forms, that is an >> implementation detail. > > The thing I want to avoid is having multiple, independently-managed > representations of Kerberos V5 principal names (or those of any other > underlying authentication mechanism), which would allow them to get out of > sync. Of course, it is possible to achieve this by requiring the ptserver > to pick a canonical internal representation and map both forms onto it and > back. However, this will be confusing to users -- since in practice > Kerberos V5 is the _only_ mechanism currently supported, we will forever be > answering bug reports of the form "I deleted one alias and they all went > away" when in fact there only ever was one alias which was reported in two > forms, or else bug reports of the form "I tried to add alias X and alias Y > appeared instead" or "I tried to add alias X and it said it already exists". > > In addition, one of the goals I had in mind during previous discussions on > this functionality was that the ptserver would _not_ need to understand the > semantics of every (any) name type. I don't want people to have to upgrade > their ptserver to understand a new name type before they can deploy an > experimental fileserver that supports that name type. The only things that > should need to understand the semantics of authentication names are the > authentication mechanism itself and the tools used by administrators to > manipulate aliases. Server code outside the mechanism, including the > ptserver, should not need to understand aliases. > > As it stands, the onus to convert is on implementations of authentication > mechanisms using GSS-krb5. Would it make people happier if we were to > eliminate the Kerberos V5 name type and require Kerberos V5 names to always > be represented as GSS export tokens? That would place the onus of > conversion on things (rxkad, not mech-independent server code) that accept > raw Kerberos V5 authentication.
I can't speak for the objector. I believe that doing so would be entirely reasonable. -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
