[257] in Kerberos
re: an_to_ln
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Sat Nov 14 11:05:00 1987
To: srz@MELANGE.LCS.MIT.EDU (Stan Zanarotti)
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: srz@melange.LCS.MIT.EDU (Stan Zanarotti)'s message of Fri, 13 Nov 87 16:00:59 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
I think some of this discussion is barking up the wrong tree.
There are two mapping concepts here that are best kept orthogonal.
1. Mapping from an external identity to internal identity. This
mapping should be one-to-one, should almost never change, and should
be as obvious as possible.
2. Allowing several identities to map together, to accomplish some
kind of proxy login or access control goal. This mapping should be
done either by mapping external identities to external identities, or
by mapping internal identities to internal identities.
The mapping from authentication name (Kerberos principal identifier)
to local name (the ID you have on some time-sharing system) is
something that a non-standard world forces on us, but it isn't the
right place to introduce user-settable arbitrary rebindings. The
ideal external-to-internal mapping would be the identity mapping,
because any other mapping violates the principle of minimum surprise,
an especially important principle for protection mechanisms. That
is, protection mechanisms that have non-obvious properties are
protection mechanisms that well-intentioned users have a good chance
of setting up wrong, using incorrectly, or not auditing properly.
Unfortunately, there isn't much prospect of instantly changing UNIX
to use Kerberos principal identifiers in full, or of assuming that
every local system within a Kerberos realm will change its
identifiers for users to match everyone else's names for those same
users. So some mapping is required.
I think that one balances those two pressures by:
1. Using a mapping as close to identity as possible, wherever
possible. The algorithmic mapping we use at Athena for instance-less
names is a good example.
2. Where it can't be an identity, set it up once and for all and
leave it, so that once people learn a mapping for a particular system
they don't find it changing from day to day. This consideration
argues against any discussion about what tickets you need to present
to change the mapping. Wiring it into a table that only a system
administrator can get at is actually a good idea in this case.
Since the requirements for mapping are very site-dependent, it is
possible that the Kerberos master sources need to offer a few
optional versions of the an_to_ln() function, together with a good
explanation of the tradeoffs.
And any hint of function along the line of "I want to be able to
allow that user to log in to this system as me" ought to be handled
by an orthogonal mechanism, explicitly managed as a proxy system,
with appropriate logging and safeguards.
Jerry
