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

[Jeffrey Hutzelman]

--On Thursday, August 26, 2010 12:55:59 PM -0400 Derrick Brashear=20
<shadow@gmail.com> wrote:

> On Thu, Aug 26, 2010 at 12:48 PM, Jeffrey Hutzelman <jhutz@cmu.edu> =
wrote:
>> What I offer as an alternative is that mechanism-specific knowledge =
about
>> the format of raw-krb5 be confined to the implementations of those rx
>> security classes which use it; namely, rxkad and rxk5. =C2=A0These will
>> already require changes to support what I hope will end up being a
>> common, class-independent API to allow server application code to obtain
>> the client's authentication name, to be used in place of
>> rxkad_GetServerInfo. At least rxkad will already require code changes to
>> report a krb5 principal name as a single string, rather than performing
>> the lossy krb5-to-krb4 name conversion it does today. =C2=A0All I =
propose is
>> that instead of merely returning a string, it return an opaque name in
>> the same form as would be used by gss-krb5.
>>
>
> Then this begs the question: how do you support a mixed environment of
> old (current) and new (revised) rxkad fileservers without creating
> additional confusion due to names being represented differently?

Old rxkad fileservers convert krb5 names to a krb4 "name" and "instance"=20
according to a semi-obscure set of hardcoded rules in rxkad, join them with =

'.' (unless the instance is null), then append '@' and the downcased realm=20
(unless it is a "local" realm).  The resulting string is passed to=20
PR_NameToID, and what _that_ does is not currently specified.

Note that I'm not proposing changing rxkad's existing interface, which=20
returns a separate name, instance, and cell.  I'm only proposing changing=20
the form of the binary authname blob that would be returned when the _new_=20
interface is used.

-- Jeff