Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!saturn!jbs@fenchurch.MIT.EDU
From: jbs@fenchurch.MIT.EDU (Jeff Siegal)
Newsgroups: comp.os.research
Subject: Re: Non-secure workstations (long) (Was: The NeXT Problem)
Message-ID: <5225@saturn.ucsc.edu>
Date: 22 Oct 88 18:07:30 GMT
Sender: usenet@saturn.ucsc.edu
Organization: MIT EE/CS Computer Facilities, Cambridge, MA
Lines: 29
Approved: comp-os-research@jupiter.ucsc.edu


In article <5198@saturn.ucsc.edu> fouts@lemming. (Marty Fouts) writes:
>The problem with using even a trusted authentication server is
>that before I believe that you are the authentication server, you have
>to prove you are the authentication server in the presence of the
>possibility that someone else will pretend to be the authentication
>server, or attempt to cause me to believe you are not.

Unless I misunderstand your objection, it is addressed by Kerberos and
similar systems.  Kerberos authenticates the authentication server
(AS).  When you request a Ticket-Granting Ticket (TGT), it arrives
encrypted with your password.  Only the AS (or you) could perform this
encryption; this establishes the authenticity of the AS.  Only you (or
the AS) can decrypt the TGT; this establishes your identity.

Potential weaknesses:

1. Replays.  If a hostile agent wants to impersonate the AS, it can
record an encrypted TGT and replay it to you the next time you ask for
one.  In theory, not hard to protect against.  In practice, not hard
to protect against with a reasonable degree of confidence.

2. The cryptosystem.  If a hostile agent can decrypt the TGT, it can
impersonate you until the TGT expires (currently 8 hours for
Kerberos).  If it can derive the key, it can impersonate you forever
(since the key is your password).  In the current implementation of
Kerberos, the cryptosystem is a replaceable module.  In practice, DES
is currently used.

Jeff Siegal