Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!dla
From: dla@athena.mit.edu (Don Alvarez)
Newsgroups: comp.protocols.kerberos
Subject: Re: Davis/Swick discussion
Message-ID: <10224@bloom-beacon.MIT.EDU>
Date: 31 Mar 89 18:16:05 GMT
References: <8903292250.AA09858@decwrl.dec.com>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: dla@athena.mit.edu (Don Alvarez)
Organization: Massachusetts Institute of Technology
Lines: 57

In article <8903292250.AA09858@decwrl.dec.com> 
miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller) writes:

>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 [so the neccesary info
>is available].

This is a potentially very dangerous beleif.  Given the fundamental
assumption of an insecure network of untrusted machines an the possibility
of attackers with root privilegdges on a subset of machines you can not
trust any communications above the host-host level.

When you log in to a machine, you typically think of yourself as authenticating
yourself to the machine.  With kerberos, you do something additional: you make
it possible for the machine to request services and send messages in your name.
If you don't log in, the workstation can't do anything in your name, but
if you do log in, the only way that you can trust what the machine does in
your name is to trust the operating system.  Your key is stored in memory,
and if you can ask the machine to get it for you, then if I massage it with
my root priviledges I can get it too.

>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.

This doesn't help either.  Somehow, your machine has to be able to get at
the ticket, either by reading it from memory or by querying the smart card
for the current instance of the ticket.  If it is possible for the OS to get
at the ticket in your name, then it is possible for me to massage the OS into
getting the ticket for me (assuming I'm root, which you have to assume based
on historical observations).  Asking the user to manually type in the key
doesn't help either, 'cause anybody with enough smarts to know when the machine
should ask for the key will be running to many processes to bother typing in
the key every two seconds.  

Kerberos is great, but it has its limitations, and one of those is that you
have to be able to trust the software on the end machines.  That is a very
important assumption which I have not seen explicitly addressed by any
official documentation.  It is particularly important in the context of
public clusters of workstations.

Several people have mentioned the idea of instructing all workstations to
take their boot blocks from a kerberos-style-authenticated read-only file
server.

That would at least give you a trusted kernel, on which you could base your
OS trust features, but I'm not aware of anyone actively implementing such a
system.


>Steve.

...Don Alvarez, boomer@space.mit.edu