From: John Deters <jad@dsddhc.com>
Date: Tue, 7 Oct 1997 23:36:21 +0800
To: Eric Blossom <aba@dcs.ex.ac.uk
Subject: Re: Secure phone
In-Reply-To: <199710060125.CAA03034@server.test.net>
Message-ID: <3.0.3.32.19971007102724.00a499c0@labg30>
MIME-Version: 1.0
Content-Type: text/plain



At 12:05 PM 10/6/97 -0700, Eric Blossom wrote:
>None of this is designed to provide authentication of the end point.
>It is designed to ensure that you've got a private channel to the end
>point. 

Therefore, man-in-the-middle can be more precisely described as an
unauthenticated end-point problem.  Therefore, without authentication,
there is no defense (yet) against MITM attacks.

One of the previous threads got me thinking:  the original thought was
something on the order of "make it so complex it takes so long to compute
that we know there was an MITM."  Obviously, Mallory can be given enough
resources to defeat a computationally bound challenge.  However, could
there be a way to use a trusted third party (Trent) to validate such a scheme?

Lets say that Trent is a trusted third party that operates a Digital
Notary, and will sign and datestamp any packet.  Can we use the old "one
oracle always lies, one oracle always tells the truth" riddle to pass a
request through Bob (or in the MITM case, Mallory) to Trent, who always
tells the truth?

(The riddle works like this:  You enter a room with two doors.  In front of
each sits an oracle.  A sign says that, "One oracle always lies, one always
tells the truth; behind one exit is a hungry tiger, and behind the other is
freedom.  You are allowed to ask the oracles any questions you wish."

The answer is: ask one of the oracles "which door would the OTHER oracle
say contains the tiger?", then you pick the OPPOSITE door to make your
getaway.  The idea is that you use the truth of one to include the lie of
the other to ensure your safety, without attempting to discover the
irrelevant fact of which oracle lies.)

Can we somehow use this to force a MITM to tip his hand?  Can we ask the
other end "make this request of Trent, and send me the response?"  Any
request Alice makes of Bob will instead be made by Mallory on Bob's behalf,
so it has to be for something either non-duplicatable or externally
verifiable.

Perhaps Alice and Bob can both ask Trent to do something externally
verifiable.  They could both ask Trent to lock up for a ten-second period
of time.  I know the MITM could use Trent for the conversation with Alice,
and Terrance for the conversation with Bob, but if Trent is somehow agreed
to or implied by the protocol, it might work.  But, of course, nobody would
want to sit around waiting for their 10 seconds of holding.  And if you had
to wait, it would give time for Mallory to spoof the waits.  

What if both sides asked Trent to display a list of all "registered"
conversations that were taking place at a particular point in time?  Trent
could list that between 9:48:01 and 9:48:06 there were 20 conversations
being authenticated.  Among them are:  Alice PK 1234 was talking to Bob PK
1111 and also a Bob PK 5678 was talking to an Alice PK 2222.

Of course, this guarantees externally auditable traffic analysis.  But if
we're trying to assure that an unauthenticated Bob can talk securely to an
unauthenticated Alice, it might be an acceptable tradeoff.

All this assumes that the MITM can't get between Alice and Trent.  If an
authenticated public key is used for Trent, then Alice is OK as long as
Mallory isn't Trent's operator!

Obviously, the easy solution is to use authenticated public keys all
around.  Replace Trent in the above with Trusted Public Key Server, and
authentication is guaranteed.  

John
--
J. Deters "Don't think of Windows programs as spaghetti code.  Think
          of them as 'Long sticky pasta objects in OLE sauce'."
+--------------------------------------------------------------------+
| NET:   mailto:jad@dsddhc.com (work)   mailto:jad@pclink.com (home) |
| PSTN:  1 612 375 3116 (work)          1 612 894 8507 (home)        |
| ICBM:  44^58'36"N by 93^16'27"W Elev. ~=290m (work)                |
| For my public key, send mail with the exact subject line of:       |
| Subject: get pgp key                                               |
+--------------------------------------------------------------------+