[AFS3-std] Re: Revised PTS authentication name mapping draft, call for review

[Derrick Brashear]

On Tue, Aug 24, 2010 at 3:33 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
> --On Tuesday, August 24, 2010 02:10:34 PM -0400 Jeffrey Altman
> <jaltman@your-file-system.com> wrote:
>
>> I support this change. =A0It is after all the PTS servers responsibility
>> to understand whether two names refer to the same PTS ID. =A0If 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 o=
f
> sync. =A0Of course, it is possible to achieve this by requiring the ptser=
ver
> to pick a canonical internal representation and map both forms onto it an=
d
> back. =A0However, 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 tw=
o
> 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 exist=
s".
>
> In addition, one of the goals I had in mind during previous discussions o=
n
> this functionality was that the ptserver would _not_ need to understand t=
he
> semantics of every (any) name type. =A0I don't want people to have to upg=
rade
> their ptserver to understand a new name type before they can deploy an
> experimental fileserver that supports that name type. =A0The 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. =A0Server 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. =A0Would it make people happier if we were to
> eliminate the Kerberos V5 name type and require Kerberos V5 names to alwa=
ys
> be represented as GSS export tokens? =A0That would place the onus of
> conversion on things (rxkad, not mech-independent server code) that accep=
t
> raw Kerberos V5 authentication.

I can't speak for the objector. I believe that doing so would be
entirely reasonable.


--=20
Derrick