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

[Jeffrey Hutzelman]

--On Tuesday, August 24, 2010 02:10:34 PM -0400 Jeffrey Altman 
<jaltman@your-file-system.com> 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