Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!shelby!DECWRL.DEC.COM!miller%erlang.DEC
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
Newsgroups: comp.protocols.kerberos
Subject: Re: Davis/Swick discussion
Message-ID: <8903292250.AA09858@decwrl.dec.com>
Date: 30 Mar 89 01:40:00 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 25

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. This is clearly demonstrated by observing that the protocols
always specify source and destination principal, that hosts may store multiple
server (destination principal) keys, and that one must 
re-authenticate to communicate (via Kerberos) with additional principals
residing at the same host. In other words, it is not like logging in to
a local system, where you are normally performing user-host authentication,
and once successfully done, have been authenticated for *All* the services
local to the host. The current Kerberos implementation uses the host as
a secure repository of the set of server keys, however this is not
a requirement.  For example, a host receiving a Kerberos mediated
request could present the encrypted ticket on the display (or an RS232 port),
where it would then be input to a smart card which would decrypt the
ticket using the *principal's* key.

My issue is with their description.  Based on reading a previous draft,
I do believe that they are trying to address a legitimate problem, that is,
avoiding storing long-lived server master keys on hosts. I do not have
any comments yet on the current version.

Steve.