--On Tuesday, August 24, 2010 10:38:52 PM -0400 Derrick Brashear
<[email protected]> wrote:
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.
So, I'm not sure why you're being coy about who that person is, since the
text you quoted is from a message Simon sent to this mailing list a couple
of months ago. Anyway, I'm sure he'll speak up.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
