[720] in Kerberos
some comments on Kerberos
daemon@TELECOM.MIT.EDU (Jerome H Saltzer)
Wed May 10 10:12:36 1989
From: Jerome H Saltzer <jhs%computer-lab.cambridge.ac.uk@NSFNET-RELAY.AC.UK>
To: NESSETT%ccc.mfecc.llnl.gov@NSFNET-RELAY.AC.UK
Cc: KERBEROS@ATHENA.MIT.EDU,
In-Reply-To: NESSETT@gov.llnl.mfecc.ccc's message of Tue, 9 May 89 18:13:45 PDT <890509181345.2660012a@CCC.MFECC.LLNL.GOV>
On the whole, the comments made by Nessett are quite interesting,
especially to deciding to what range of problems Kerberos might be
applicable.
There are a few things in Nessett's analysis and critique that should
be discussed before accepting the criticisms as valid, though.
> o Kerberos keeps its encryption keys in application process space.
I don't think that is a criticism of Kerberos itself as much as a
criticism of the way in which Kerberos is implemented in UNIX systems.
The protocol does not specify where keys should be kept, and in a
system specially designed for security one might well provide hardware
or software-in-the-supervisor storage mechanisms for the keys and for
temporary storage to hold the password. Addition of such mechanisms
to UNIX would not require changes in the basic design of Kerberos. (But
the changes to UNIX would be extensive enough as to risk considerable
debate, which is why the current Kerberos implementation didn't try.)
> 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. . . . this affords no
> protection against message replay. . . .The window of opportunity
> for replay is on the order of minutes, well within the capacity of
> programs written by an intruder to capture such information and replay
> it.
I think this criticism arises from a misunderstanding of the Kerberos
design that may in turn arise from the somewhat simplified description
that appeared in the USENIX paper. The inclusion of the IP address in
a ticket is not intended to have any bearing on replay protection,
even though it does have the effect of increasing slightly the work
factor in creating a replay attack against a service that chooses not
to protect itself against replay. The fundamental protection against
replay resides in the expiration of authenticators. Any service
concerned about replay should keep a list of authenticators it has
accepted until they expire. The expiration times are very short
exactly so that that list can be short. When a service keeps such a
list, there is no window of replay vulnerability.
> 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.
This concern is definitely true, and it causes me to be somewhat
worried about recent moves from the traditional eyeball-and-timex
method of setting system clocks to the fancier network
time-synchronization protocols. The eyeball-and-timex method at least
provides a known level of security on which Kerberos can build.
However, I think that the securing of the time-synchronization
protocol is a matter best thought of as orthogonal to the
authentication protocol; the Kerberos system should specify that a
secure time-synchronization method be used rather than specify the
method itself.
> 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). At first sight, one might believe this
> possible with Kerberos by invalidating a user's long-term key in the
> Kerberos database. However, there is an attack against this strategy.
> If an intruder can isolate one of the slave Kerberos servers (perhaps
> by congesting an appropriate part of the network), thereby
> preventing the arrival of update messages, he can continue to
> operate even when his key has been invalidated in the master
> database.
Quick invalidation of user authentication was not one of the design
criteria of Kerberos, and its lack is a valid criticism in some
application situations. Since tickets can have a fairly long lifetime
(8 hours is the default in the current implementation) there is a much
simpler attack than isolating a slave Kerberos server--just acquire a
set of tickets for interesting services, and then continue to operate
for up to eight hours after the administrator pulls you from the
database.
> . . . 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.
This concern seems to be based on some assumptions about the range of
transitive authorization mechanisms that can be based on identity. A
service A when working for client B can present its credentials to
service C in at least the following several ways--
- this is service A asking for service C
- this is service A operating on behalf of client B asking for service C
- this is client B asking for service C
The present design of Kerberos does not provide for any form of
transitive credentials-passing (that lack is the transitivity problem
mentioned in the paper) so the proper criticism is probably about that
lack, rather than on speculation on how it might be filled wrongly.
> o There are occasions when it is desirable for administrators to shut
> down remote access to servers of given class (e.g., remote logon),
> while allowing remote access to other servers (e.g., E-mail). . . .
> The realm mechanism supported by Kerberos is not well-suited to this
> requirement. . . . I have seen no mechanism described for doing this.
> ;In addition, a secure administration protocol is necessary to direct
> the involved servers to take the appropriate action. I have seen
> no description of such a protocol in the Kerberos literature.
The requirement you describe here is not an authentication
requirement, but an authorization requirement. Since Kerberos
does not claim to provide authorization control, it is not surprising
that it does not meet this requirement.
> o Kerberos is designed to work in an environment in which all
> administrative domains use the same communications protocol (e.g.,
> TCP/IP).
Actually, there is nothing about the Kerberos design that requires it
use TCP or that requires that all interoperating realms use the same
protocol. The current implementation happens to be TCP, but there is
no design barrier to producing a DECNET, SNA, or ISO version, and
there is nothing to keep a realm from accepting connections via any
protocol that it implements. One might be concerned that perhaps
noone may ever get around to implementing other versions, but that is
not a design problem.
> In addition, all servers of all realms must support the Kerberos
> protocol in order to interoperate.
Perhaps you could more carefully specify this concern, because as it
is currently stated, it appears to be dramatically overdrawn.
Interoperation of any client with a server requires that the
particular pair agree on the protocol to be used, and if the server
demands Kerberos mediation, then the client had better be prepared to
provide Kerberos credentials. If the server doesn't, then the client
need not provide them. Both arrangements can coexist simultaneously,
and a client can use Kerberos mediation with a server that itself
obtains further services without Kerberos mediation. There are a lot
of interoperability concerns in the world, but I can't figure out
which one you think is made especially difficult to deal with by the
use of Kerberos.
Jerry Saltzer
