Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!decwrl!labrea!shelby!NSS.CS.UCL.AC.UK!jhs%computer-lab.cambridge.ac.uk
From: jhs%computer-lab.cambridge.ac.uk@NSS.CS.UCL.AC.UK (Jerome H Saltzer)
Newsgroups: comp.protocols.kerberos
Subject: Davis/Swick discussion
Message-ID: <8903311702.AA10414@uk.ac.cam.cl.fylde>
Date: 31 Mar 89 17:02:05 GMT
References: <8903292250.AA09858@decwrl.dec.com>
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 42

Steve Miller says,

> I take issue with the statement by Don Davis and Ralph Swick that
> 
> "Currently, Kerberos supports only user-to-secure-host authentication."
> 
> This is incorrect.  Kerberos supports principal-to-principal (e.g.
> user-to-user) authentication.

I think that, with proper interpretation, both statements are right!
Or, to be more careful, both statements are slightly abbreviated
versions of the same correct statement; they just have been
abbreviated with different concerns in mind.

I claim that the correct, fully qualified, statement is more like
this:  Kerberos supports principal-to-principal authentication where
both principals have the ability to retain a secret key and produce it
at the necessary times.  The collection of implemented utilities
currently supports holding and producing the necessary secret keys for
exactly two cases:

     1.  A private user, presenting a secret password at login time,
and
     2.  A service operating on a secure host, using a private
         file to hold the secret key.

On that basis, one can use Kerberos to authenticate a private user to
a service running on a secure host (which Don and Ralph abbreviated as
"user-to-secure-host authentication".  I wouldn't interpret that to
mean logging in to the host, but rather to mean depending on the
securedness of the host for service key presentation.)  One can also
use the current Kerberos to authenticate a service on a secure host to
another service on (the same or) another secure host.  Using it for
any other application (e.g., user-to-user, user-to-nth-level-service,
or to service on unsecured host) is possible within the protocol, but
would require some kind of extension, if only to the procedures for
presenting the secret key.  And that kind of extension is the essence
of the changes proposed by Don and Ralph.  It is also the kind of
extension Steve suggests in using a smart-card to eliminate the need
for a secure host.

					Jerry