[260] in Kerberos
Re: an_to_ln
daemon@TELECOM.MIT.EDU (Stan Zanarotti)
Fri Nov 20 15:04:15 1987
From: srz@MELANGE.LCS.MIT.EDU (Stan Zanarotti)
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
I think part of the reason we've been having this discussion is that
Kerberos is not really complete. Only the authentication head has
been completed. Authorization is a much harder problem, but one which
we have to deal with at the present time.
Theoretically, once Kerberos provides authentication, each service can
decide what access should be given to that principal. In practice, we
want to come up with common mechanisms or tools that services can use
to make authorization decisions. Currently, I believe that discuss,
rlogin and RVD have access control lists. POP, RFS, and NFS do not.
The people who 'kerberized' these applications did not want to put in
the time to add access control lists, and the administration
associated with them. If tools were around that made this easy, then
the authorization would be there.
> 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.
I find it easier to think about this as a simple access control
problem. Instead of asking the question: "What Athena principal does
this map to before I map external names to internal names?", I ask the
question: "Does stan@lcs have access to perform the requested
operation?". For networked file systems, the requested operation is
setting up the uid mapping. Presumably, there would be an ACL for
each uid on the server; if you present tickets for a principal on the
ACL, you would be allowed to map to that uid.
To prevent a denial of service attack such as Ken described, the
client program would have to request what uid to map to, instead of
having the server decide.
> 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.
Since the access control question can be solved by having every
service do its own access checking, I would agree that it's not a
fundamental gap with the Kerberos design. Just a major inconvenience.
If you consider the actions of the kerberos library as part of its
design, then there is a design gap that should be fixed. If I
can get LCS tickets on an Athena machine, I should be able to use LCS
services with those tickets. Right now, the library uses
/etc/krb.conf to determine the current realm, which hardwires the
machine to a given realm. If the library were changed to remember the
realm in the ticket file, then inter-realm operations would be more
useful. That way, Jeff would not have to customize /etc/krb.conf
every time he logs into a workstation to use the TELECOM realm.
-stan
