Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!apple!bionet!agate!saturn!riedl@purdue.edu
From: riedl@purdue.edu (John T Riedl)
Newsgroups: comp.os.research
Subject: Re: Non-secure workstations (long) (Was: The NeXT Problem)
Message-ID: <5235@saturn.ucsc.edu>
Date: 23 Oct 88 16:44:55 GMT
Sender: usenet@saturn.ucsc.edu
Organization: Department of Computer Science, Purdue University
Lines: 71
Approved: comp-os-research@jupiter.ucsc.edu


In article  <5198@saturn.ucsc.edu> fouts@lemming. (Marty Fouts) writes:
>but I don't have a reference handy.  However, in a truely hostile
>environment the underlying assumption of hostility makes the idea of
>trusting *some* machines seem rather silly.  What systems like
>Kerberos do (besides giving their users a false sense of security) is
>change the problem from faking one user to faking both the user and
>the authentication system.
>...
>Marty

Marty, I think you need to do some more background reading.  The
concept of "trust" in a hostile environment must include a method for
validating the identity of the trusted host.  I don't know enough
about current research in the area to say that there are no
difficulties with known solutions, but your arguments that the problem
*cannot* be solved are based on some basic misunderstandings.  "Using
Encryption for Authentication in Large Networks of Computers", by
Needham and Schroeder (CACM 12/78) discusses precisely this problem
(e.g.  authentication in an environment in which a hostile party may
seek to represent even a "trusted" server).  They give both
conventional and public-key algorithms for solving the problem.
Here's how their conventional algorithm works:

Background: "A" wants to establish a secure conversation with "B".  A
and B have secret keys, KA and KB respectively, known only to
themselves and their authentication server (called AS).  I'll
represent an encrypted message with {part1, part2, ...}^key.

1) A->AS: A, B, IA
where IA is an integer that is different for each request from A.

Hostile parties may attempt to pretend to be the authentication
server after seeing this message.  The reply from AS foils these
attempts by requiring the use of A's key - known only to A and AS.

2) AS->A: {IA, B, CK, {CK, A}^KB}^KA

CK is a conversation key for A and B to use in communicating.  It is
different for each conversation.  Only AS could create this message
because it requires both KA and KB.  Note that the part of the message
encrypted with KB is useless to A.  It will be used in the next
message to prove to B that AS authenticates A as the source.  Both IA
and B must appear in message 2.  IA prevents recording of AS messages,
and B prevents corruption of the original plaintext message from A to
AS.

3) A->B: {CK, A}^KB

Only B can discover CK.  B knows that AS authenticates A as the
source.  B may be worried that this conversation is a replay, so he
now asks A for proof that it is not:

4) B->A: {IB}^CK

5) A->B: {IB-1}^CK

IB is an integer that B has not used for this purpose before.  If an
intruder is replaying messages, he'll be unable to produce message 5.

-------
If you have further reservations about this approach, I recommend that
you read the paper.  It is well-written and easy to understand.  If
you find a reference that discusses problems with this approach in
detail, please post it.

John

-- 
John Riedl
{ucbvax,decvax,hplabs}!purdue!riedl  -or-  riedl@cs.purdue.edu