Xref: utzoo comp.protocols.tcp-ip:16589 alt.security:2685
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!cs.uoregon.edu!milton!uw-beaver!june.cs.washington.edu!bcn
From: bcn@cs.washington.edu (Clifford Neuman)
Newsgroups: comp.protocols.tcp-ip,alt.security
Subject: Re: Authentication & Internet Protocol Suite
Message-ID: <1991Jun18.211641.4075@beaver.cs.washington.edu>
Date: 18 Jun 91 21:16:41 GMT
Sender: news@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington, Seattle
Lines: 46
Originator: bcn@june.cs.washington.edu


  From: oberman@ptavv.llnl.gov
  Subject: Re: Authentication & Internet Protocol Suite
  Date: 18 Jun 91 20:10:44 GMT

  The real problem is that Kerberos requires at least one trusted system
  to hold ALL keys (the KDC). 

The trusted system need only hold the keys for local clients and
servers (called a realm).  If the server is compromised, this isolates
the damage to the principals registered in that realm.

  The problem arises when you want to do Kerberos authentication across
  the Internet. [This] is a problem in that you must maintain a table 
  containing the access information for every other realm you plan
  on dealing with.

In version 5, realms can be organized hierarchically.  Thus, you can
often get by maintaining entries for only immediate ancestors and
descendants in the tree.

  Also, the security between realms can only be trusted as much as you
  can trust the security of the remote KDCs and the information you use
  to allow their access to your realm.

But this is true for any system, even public key based systems.  You
are trusting the certification authority for the remote realm to
accurately identify the principal you are communicating with.

  The real answer is a public key based authentication system such as
  the Digital Equipment "Sphinx" system and the forthcoming DSSA system.
  The problem of cheap keys may be well on its way to resolution with
  the BB&N key meter, analogous with a posstage meter, for issuing keys.

The problems that you cite for Kerberos also exist for public-key
based systems.  If the key of the certification authority is
compromised, an attacker can impersonate anyone in the "realm" of that
authority.  Some public key based systems take the certification authority
offline in an attempt to make it more secure.  Once taken offline,
however, the credentials issued by the certification authority have to
be very long lived.  This presents a problem for revocation.
Revocation is dealt with by maintaining revocation lists on online
authentication servers, but these servers then become vulnerable to
attack.

	~ Cliff