[725] in Kerberos
some comments on Kerberos
daemon@TELECOM.MIT.EDU (Clifford Neuman)
Tue May 16 23:38:46 1989
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
To: NESSETT%ccc.mfecc.llnl.gov@.MIT.EDU
Cc: KERBEROS@ATHENA.MIT.EDU
In-Reply-To: NESSETT@CCC.MFECC.LLNL.GOV's message of Tue, 9 May 89 18:13:45 PDT <890509181345.2660012a@CCC.MFECC.LLNL.GOV>
I found your comments interesting. I will attempt to answer a few of
them here. Some of my comments duplicate those of others, and for
that I apologize. Anyway,
o Kerberos keeps its encryption keys in application process space.
If you don't trust the workstation, application space is no less
secure than kernel space. The only solution requires that the user's
key never leave a trusted system, and this can only be accomplished
using an approach such as having a smartcard do all the encryption and
decryption, as well as having it maintain the list of session keys
associated with each ticket. The smartcard is the trusted system in
this case, and it is trusted because it is always in the user's
possession.
Don Alvarez points out that even with a smartcard, there is still the
vulnerability of a system making unsolicited requests on behalf of a
logged in user. The smartcard would happily provide the authenticators.
As you can see, there is no absolute solution. One can simply get
closer and closer to absolute security with greater and greater effort.
o Kerberos (as described in the Winter '88 USENIX paper) seals the
client's IP address within ticket's and authenticators, yet these
addresses cannot be guaranteed correct.
The IP address is included to make it slightly more difficult to use
credentials stolen from a workstation. It is recognized that it only
makes it difficult, not impossible. It is only when credentials are
stolen through some mechanisms external to Kerberos that an attacker
would have such credentials anyway.
Replays are prevented through separate mechanism. As was already
pointed out, the Kerberos protocol requires that the end service keep
a list of the timestamps from those authenticators accepted within the
acceptable timeframe. Unfortunately, this did not seem to get
implemented.
o The security properties of Kerberos rest to a large extent on the
timestamp and lifetime information carried by tickets and
authenticators. Since this information must be compared by servers
against the value of some clock, its security properties also rests on
the mechanism by which clocks are kept synchronized.
Clocks must be synchronized using a mechanism that is itself
authenticated. Although such a timeservice has not been implemented,
it can be authenticated using Kerberos since it is the timeservice
that must be authenticated, and not the user. The timseserver can
ignore time skew on requests for the time. The client must specify
that mutual authentication is requested. This results in a response
coming back authenticated by including of the workstation's (old)
timestamp + 1 encrypted in the session key. The actual response
itself should also be encrypted in that key.
o One major advantage of central authentication (which is the basic
service that Kerberos offers) is the ability to revoke someone's access
to distributed system resources quickly and atomically (i.e., by
means of a single operation).
We specifically decided that this was not a requirement for Kerberos.
In order to make the revoking of access have an immediate effect would
require that the authentication server (AS) be involved with every
service access. This would either be accomplished by having the end
service check with AS each time, or by making the ticket obtained by
the user valid for only a very short period of time.
o While it is strenuously asserted that Kerberos only supports an
authentication service, the mechanisms by which this service is
provided strongly favors one type of authorization, namely, the use
of access control lists. Authenticating a user's identity or
identity.instance to individual servers for the purpose of access
control (as distinct from accountability purposes) is of little value
unless authorization is also based on identity. This introduces a
transitivity problem (acknowledged in the USENIX paper) whereby
servers accessing the resources of other servers on behalf of clients
must pose as those clients. But this action violates the principle of
least privilege, since servers posing as clients gain potential access to
all of the client's resources, not just to those necessary to carry out
their function.
This is a very interesting comment. Your point that Kerberos favors
an access control list approach to authorization is quite accurate.
The transitivity problem you mention is part of the proxy problem
(which is being considered in the protocol revision).
The way you phrased the problem got me to thinking, and I came up with
an interesting way to solve it. I will discuss that in my next
message (as a new proposal).
Anyway, I hope that these comments sufficiently answered those
comments that I chose to address.
~ Cliff
