--On Monday, January 04, 2010 09:10:15 PM +0000 Simon Wilkinson
<[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
