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

Simon Wilkinson simon@sxw.org.uk
Thu, 26 Aug 2010 16:14:31 +0100


On 25 Aug 2010, at 03:38, Derrick Brashear wrote:

> On Tue, Aug 24, 2010 at 3:33 PM, Jeffrey Hutzelman <jhutz@cmu.edu> =
wrote:
>>=20
>>=20
>> since in practice Kerberos V5 is the _only_ mechanism currently =
supported

I believe that at approximately the point that OpenAFS deploys =
authentication name mapping, we'll also be supporting X509 and SCRAM in =
addition to Kerberos. I suspect we'll see a requirement for supporting =
Moonshot names pretty soon too, providing that gets off the ground. Any =
solution that assumes that we're primarily dealing with Kerberos v5 =
names is inherently flawed, in my book.

>> 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.
>=20
> I can't speak for the objector. I believe that doing so would be
> entirely reasonable.

I am not convinced. It sounds to me like you are moving the onus for =
conversion from the ptserver to requiring every fileserver (or every =
client) to perform the conversion steps when using rxk5 or rxkad =
identities. It seems so much cleaner to keep this knowledge in one place =
- and the ptserver is the obvious location for this to exist.

Cheers,

Simon