[259] in Kerberos
re: an_to_ln
daemon@TELECOM.MIT.EDU (Jerome H. Saltzer)
Wed Nov 18 14:39:12 1987
To: srz@MELANGE.LCS.MIT.EDU (Stan Zanarotti)
Cc: Saltzer@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: srz@melange.LCS.MIT.EDU (Stan Zanarotti)'s message of Tue, 17 Nov 87 15:38:04 EST
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> One capability that I want to have is NFS, POP, and rlogin access from
> my LCS account over to my Athena account. This is an access decision
> that I make. If this had to be done by a system administrator, I
> could whine at Jeff to get this done, but it would be better if I
> could set this up myself from my Athena account.
I think that is pure proxy; some services support user-designated
proxies and some don't. If you originally authenticate yourself as
srz@lcs I don't think that the Athena Kerberos server has any
business giving out tickets that say you are srz@athena; it should
give tickets for Athena services but the ticket should still identify
you as srz@lcs and the service should decide whether or not it wants
to allow usage by that principal, and also whether or not to map it
to the same thing that it would map srz@athena. Similarly, if your
LCS ticket comes through saying "stan@lcs" the service gets to decide
that it wants to map that name to "srz@athena" before proceeding.
> What Jeff wants is for POP and NFS access still work with root tickets
> as well as normal tickets. That is, ("jis", "root") tickets would be
> able to read the mailbox for "jis", just as well as ("jis", ""). This
> too is a many-to-one mapping, and therefore has to be covered by
> mapping #2. The external identity jis.root@ATHENA.MIT.EDU maps to
> the external identity jis@ATHENA.MIT.EDU. If this mapping was always
> done before the access control list check, then the root instances would be
> useless; they would simply be washed away by this mapping.
Shouldn't that class of "mapping" should be handled by an access
control list that implements wild cards? For the case indicated, the
access list might say "jis.*@athena.mit.edu"
> One final observation about goal #1: The current interrealm
> mechanisms in Kerberos are woefully inadequate. If we start promoting
> Kerberos as the solution to inter-realm access control, we've got to
> come up with better inter-realm support. Currently I am one of the
> few people suffering from this; Jeff gave up on the TELECOM realm.
I think everyone agrees that there are a lot of loose ends in this
area. The trick is to separate the fundamental issues out from the
current kit bag of shortcuts and implementation hacks. In
particular, when the present implementation runs into problems, the
question each time is whether it is because of a fundamental gap in
the Kerberos design or is it because some service (or Kerberos
itself) hasn't gotten around to implementing a nominally required
feature.
Jerry
