--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.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
