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

[Jeffrey Hutzelman]

--On Tuesday, January 05, 2010 08:26:39 AM +0000 Simon Wilkinson 
<simon@sxw.org.uk> 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