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

[Jeffrey Hutzelman]

--On Monday, January 04, 2010 09:10:15 PM +0000 Simon Wilkinson 
<simon@sxw.org.uk> wrote:

> The major issue is with section 11.4, Authentication Name Type rewriting.
> I really don't like the idea of requiring clients to rewrite particular
> GSSAPI names before making calls. I think there are a number of issues
> with this design
>    *) It builds in specific Kerberos 5 knowledge to generic GSSAPI
> clients. It is my hope that rxgk clients will be able to be completely
> generic, so their mechanism support can be changed by altering the GSSAPI
> libraries at link time. I would really rather not embed any mechanism
> specific knowledge into these clients

Yes, it requires specific Kerberos 5 knowledge.  This is a special case, 
designed to allow the same auth name to match clients using rxgk-GSS-krb5, 
rxkad, and rxk5.  The theory here is that authentication name types should 
depend on the underlying authentication technology but _not_ on the Rx 
security class used.  This requires special casing whenever we have a 
technology which can be used either via GSS-API or directly.  Fortunately, 
we expect Kerberos to be the only one of these.

>    *) It isn't particularly extensible, because we have no change control
> over GSSAPI. What happens if (unlikely) a Kerberos 4 GSSAPI mechanism is
> standardised?

Unlikely, and growing more so by the moment.  But if it happened, we'd have 
to decide whether it's more important for GSS-krb4 to match existing krb4 
auth names in the PRDB, or for nothing to have to know about the 
correspondence.

> What happens if we add an explicit X509 mechanism?

Don't do that.


> Before
> you know it there's a huge tangled web of mappings that every client has
> to be aware of

>    *) Client based knowledge is hugely difficult to upgrade. If this
> mapping must be performed, then doing it on the servers hugely simplifies
> the task of maintaining it.

The only entities which _need_ to understand auth types are those which 
call PR_AuthNameToID; that is, fileservers and others which accept 
authenticated connections and then ask the ptserver to map the client's 
auth name to a vice ID.  And _those_ need only understand auth types which 
they actually support.

The administrative clients which establish and manipulate auth names might 
wish to know something about them, so as to provide a friendly interface 
for manipulating them.  But, that's not terribly relevant here, as it'd be 
true with or without mappings.

No AFS clients need to know about or understand auth name types.

>    *) It adds specific mappings to a very rare situation. The likelihood
> of sites running both Kerberos v5 and GSSAPI authentication mechanisms
> concurrently is very small.

All of our current authentication mechanisms are based on Kerberos v5.
The expectation is that _every_ site will go through this transition.

-- Jeff