[258] in Kerberos
re: an_to_ln
daemon@TELECOM.MIT.EDU (Stan Zanarotti)
Tue Nov 17 15:39:36 1987
From: srz@MELANGE.LCS.MIT.EDU (Stan Zanarotti)
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
>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.
Let me see if I can figure this through, so that I can understand
exactly what you're proposing.
Situation #1:
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.
Since this is a many-to-one mapping, it would have to be covered by
mapping #2. The external identity srz@LCS.MIT.EDU would have to be
mapped to the external identity srz@ATHENA.MIT.EDU. Presumably, when
the LCS client machine contacts Athena's kerberos server, it presents
tickets authenticating me as srz@LCS.MIT.EDU. The kerberos server
would give me back tickets authenticating me as srz@ATHENA.MIT.EDU.
I can present these tickets to charon, which will allow me to access
my files.
This scheme's advantage is that it takes care of the entire realm at
once. By updating one database (the one on the kerberos server(s)), I
can allow srz@LCS.MIT.EDU proxy for srz@ATHENA.MIT.EDU, for all
services. I do not have to set up separate access control lists for
the mail services, the NFS service, etc. The disadvantages are that
there is no granularity of access control (it's all or nothing), there
is still a denial of service attack, it involves changing the Kerberos
protocol (I'm getting back different tickets than I'm asking for) and
adding another database that the kerberos server has to maintain.
Situation #2:
Athena has the concept of "root" instances, which are Kerberos
instances that are more privileged than the normal (user, "")
instances. Services with access control lists (like rlogin), will
sometimes have root instances listed, but not the normal instances.
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.
So I'm not sure how we can accomplish both goals simulateneously if we
restrict ourselves to the two types of mappings above. And if we're
giving up on any of these goals, I would like to know now.
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.
-stan
