Path: utzoo!attcan!uunet!seismo!sundc!pitstop!male!sun-barr!apple!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!shelby!JUNE.CS.WASHINGTON.EDU!bcn
From: bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman)
Newsgroups: comp.protocols.kerberos
Subject: some comments on Kerberos
Message-ID: <8905170335.AA04894@june.cs.washington.edu>
Date: 17 May 89 03:35:58 GMT
References: <890509181345.2660012a@CCC.MFECC.LLNL.GOV>
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 92

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