On 25 Aug 2010, at 03:38, Derrick Brashear wrote: > On Tue, Aug 24, 2010 at 3:33 PM, Jeffrey Hutzelman <[email protected]> wrote: >> >> >> 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. > > 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
