--On Thursday, August 26, 2010 12:55:59 PM -0400 Derrick Brashear
<[email protected]> wrote:
On Thu, Aug 26, 2010 at 12:48 PM, Jeffrey Hutzelman <[email protected]> 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. These 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. All 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"
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
(unless it is a "local" realm). The resulting string is passed to
PR_NameToID, and what _that_ does is not currently specified.
Note that I'm not proposing changing rxkad's existing interface, which
returns a separate name, instance, and cell. I'm only proposing changing
the form of the binary authname blob that would be returned when the _new_
interface is used.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
