--On Tuesday, January 05, 2010 08:26:39 AM +0000 Simon Wilkinson
<[email protected]> wrote:
On 5 Jan 2010, at 02:28, Russ Allbery wrote:
I might be missing some context here, but that makes me very
nervous. I
think it's extremely likely that we're going to have sites who want
to use
an X.509 mechanism for authentication that is not mediated by
Kerberos.
rxgk will support doing x509 as a GSSAPI mechanism using (at least) the
GGF's GSI, in the same way as OpenSSH does. As other GSSAPI based X509
mechanisms become available, we'll support those too.
My worry was that Derrick's draft essentially says that you can only use
a single canonical format for a name, and that it's the client's
responsibility to determine that canonical name before talking to the
prdb. I believe that this is problematic, as it requires that all clients
know about all of the authentication mechanisms supported within a cell,
and the correspondence between those mechanisms. It means that it's
possible that the behaviour of prdb entries will vary depending on which
piece of software created them.
Except, as I explained, it doesn't requires that _clients_ know anything.
All it knows is that entities which use vice ID's for authoriation (i.e.
only the ptserver and fileservers) know how to process the names produced
by the authentication mechanisms they accept. This is already true of many
GSS-API applications, and in our case, it's much simpler than usual,
because unless the mechanism is exactly Kerberos, the operation is as
simple as calling gss_export_name() and using the resulting token -- in
other words, we do exactly what the design of the GSS-API wants us to do.
BTW, note that it's not even the fileserver per se that needs to understand
this. An application (any application) accepting rxgk tokens need only
copy the auth name from the rxgk token exactly as is. Authentication name
types used in this interface and by rxgk are the same for exactly that
reason (unless yinz went and broke rxgk). So only servers which implement
rxgk token establishment need concern themselves with any mapping. That's
a far cry from "every client". It doesn't include _any_ client.
Note that if/when we support any mechanisms involving X.509, we're likely
going to end up wanting to support policies other than exact match of a
GSS-API export token. I have some ideas how to deal with this, at least in
enough detail to understand their implications on this design, but lack
time to write about the topic this morning.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
