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

[Jeffrey Hutzelman]

--On Tuesday, August 24, 2010 10:38:52 PM -0400 Derrick Brashear=20
<shadow@gmail.com> wrote:

> 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. =C2=A0It is after all the PTS servers =
responsibility
>>> to understand whether two names refer to the same PTS ID. =C2=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
>> of sync. =C2=A0Of 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. =C2=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 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. =C2=A0I 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.
>> =C2=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. =C2=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. =C2=A0Would 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? =C2=A0That 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=20
text you quoted is from a message Simon sent to this mailing list a couple=20
of months ago.  Anyway, I'm sure he'll speak up.

-- Jeff