ESP Unix encrypted session protocol software

Folks,

I'm releasing, for experimental use, source code for a preliminary
version of my simple Unix->Unix encrypted terminal session manager,
ESP.  Basically, ESP provides a pseudo-terminal interface to a local
shell session that you can use to establish an encrypted terminal
session with a another, remote machine.  (See the README file below
for usage examples).  Once the bugs are shaken out, ESP will become
part of my CFS package, which will eventually grow into a larger
suite of free, practical tools for secure internetworked computing.
At the present time, I'm just releasing a "pre-release" to small
groups, including interested folks on the cypherpunks list.

I've tested ESP under BSDI and SunOS 4.x; you'll also need RSAREF 2.0
(from rsa.com) to compile it.  You're on your own for other platforms.
This release is NOT production software; it is by no means "ready for
prime time".  It's slow (reduces bandwidth by 50% and takes 45 seconds
to start up).  The user interface needs a bit of work, and you really
have to know what's going on to make effective use of it.  Future
versions of ESP will use a more efficient encoding and will add
features like a "palmtop" mode that allows secure remote entry of
things like passwords from dumb terminals with the encryption done on
a disconnected palmtop machine.  I hope to eventually have a PC
terminal client as well.  This version, however, only supports
Unix->Unix terminal sessions.

Because of export restrictions (and a large cabal of paranoid, rabid
lawyers watching my every move), I'm not able to send ESP out of the
US or Canada or make it available by anonymous ftp.  Sorry.  If you
want a copy of the ESP-beta sources, send an Email message to
cfs@research.att.com (NOT mab@research.att.com) telling me the
following:
	- that you're in the US or Canada, and
	- that you're a US or Canadian citizen or legal permanent
	  resident, and
	- that you've read and understand the license and export
	  conditions in the README file below.

Remember, you also need to get RSAREF 2.0 to build ESP.

-matt


========================= ESP README ==============================
This is Version 0.5c (BETA) of ESP, the Encrypted Session Protocol.

 * The author of this software is Matt Blaze.
 *              Copyright (c) 1995 by AT&T.
 * Permission to use, copy, and modify this software without fee
 * is hereby granted, provided that this entire notice is included in
 * all copies of any software which is or includes a copy or
 * modification of this software and in all copies of the supporting
 * documentation for such software.
 *
 * This software is subject to United States export controls.
 *
 * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED
 * WARRANTY.  IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY
 * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY
 * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.

ESP is an encrypted session protocol layer for managing remote
encrypted sessions.  It does 1024 bit DH key exchange (from RSAREF)
and 3-des in 8bit cfb mode for the traffic encryption.  See the
man page (esp.1 in this distribution).

To compile ESP you'll need the RSAREF 2.0 library, available for free
for non-commercial use in the US and Canada from RSA Laboratories
(anonymous ftp to rsa.com for details).

Once you have RSAREF working, this distribution should compile without
problems under SunOS 4.x and BSDI; you're on your own with other platforms.

The best way to explain esp is with an example.  Here's
an encrypted session from alice to bob:

	alice$ esp
	ESP v0.5 - encrypted session protocol layer
	    by Matt Blaze, AT&T Bell Labs, January 1995
	Randomizing (takes about 45 secs)......................done
	local layer ready (run 'esp -s' on remote)
	alice$ rsh bob
	bob$ ./esp -s                                          
	ESP v0.5 - encrypted session protocol layer
	    by Matt Blaze, AT&T Bell Labs, January 1995
	Randomizing (takes about 45 secs)......................done
	remote server ready
	Starting remote side of 1024 bit key exchange.
	~~L
	Starting local key exchange.
	entering ENCRYPTED mode; type ctrl-^ to escape
	bob$
	...
	[encrypted session from alice to bob]
	...
	bob$ exit
	Press <enter> to return CLEARTEXT mode:
	bob$ exit
	alice$ 

You can also use ESP to provide an encrypted login session;
simply create a user "esp" with "esp -s -e login" as the login
shell.  (Getting this to work properly will require some tweaking
on your local system). Run esp -l on the local machine and from
there log in to the esp account on the remote machine.  Such a
configuration encrypts the real account name and password over
the network:

	alice$ esp                                  
	ESP v0.5 - encrypted session protocol layer
	    by Matt Blaze, AT&T Bell Labs, January 1995
	Randomizing (takes about 45 secs)......................done
	local layer ready (run 'esp -s' on remote)
	alice$ telnet bob
	Trying 123.45.67.12...
	Connected to bob
	Escape character is '^]'.

	bob login: esp
	ESP v0.5 - encrypted session protocol layer
	    by Matt Blaze, AT&T Bell Labs, January 1995
	Randomizing (takes about 45 secs)......................done
	remote server ready
	Starting remote side of 1024 bit key exchange.
	~~L
	Starting local key exchange.
	entering ENCRYPTED mode; type ctrl-^ to escape
	login: mab
	Password:
	bob$
	...

It's primitive and slow, but seems to work.  Comments, bug fixes,
ports to new platforms and complaints are welcome.

Matt Blaze
mab@research.att.com
(for esp or cfs questions, use cfs@research.att.com).

> Because of export restrictions (and a large cabal of paranoid, rabid
> lawyers watching my every move), I'm not able to send ESP out of the
> US or Canada or make it available by anonymous ftp.  Sorry.

Can you make the protocol specs available?

--apb (Alan Barrett)

On Mon, 30 Jan 1995, Matt Blaze wrote:

> ESP is an encrypted session protocol layer for managing remote
> encrypted sessions.  It does 1024 bit DH key exchange (from RSAREF)
> and 3-des in 8bit cfb mode for the traffic encryption.

I'm curious what Matt and others think about the possibility of the DH key
exchange being spoofed by an interloper in this application. 

-Thomas

>On Mon, 30 Jan 1995, Matt Blaze wrote:
>
>> ESP is an encrypted session protocol layer for managing remote
>> encrypted sessions.  It does 1024 bit DH key exchange (from RSAREF)
>> and 3-des in 8bit cfb mode for the traffic encryption.
>
>I'm curious what Matt and others think about the possibility of the DH key
>exchange being spoofed by an interloper in this application. 
>
>-Thomas
>

Well, cryptographically speaking, it's trivial for an active attack and
probably infeasible for a passive attack.  But you knew that...

So there are two questions - first, what's the threat model for TCP/IP,
and second, what are the alternatives?

I'm not sure about the threat model.  Spoofing attacks on TCP sessions
are not exactly easy - there's a lot to do to pull it off - but not
out of the question either (as demonstrated by the recent NYT articles
and CERT advisories).  Probably the easiest way to receive packets intended
for another host is to convince the routing tables between you and your
victim to route to you instead of the real host.  I'm not aware of this
every being done ON PURPOSE, but it's not out of the question, either.

As for the alternatives, I think the picture is pretty bleak, to tell
the truth.  The cryptographically sound way to prevent spoofing is
with authentication of the agreed key.  But for the remote host to
authenticate itself, it has to have a secret signature key.  Where to
store it?  A typical machine, especially a multi-user, unattended server
simply has no safe place to store keys.  And if you had a trusted secure key
store on the remote host, you wouldn't really need to use Diffie-Hellman
to establish the session key in the first place, since you could just
store each user's pre-established session key in advance.

At the extreme, fixing this is a Hard Problem.  In practice for establishing
a reasonably secure session, it all depends on how much you worry about a
full-blown (two way) spoofing attack against IP.

-matt
session ke

On Mon, 30 Jan 1995, Matt Blaze wrote:

> And if you had a trusted secure key
> store on the remote host, you wouldn't really need to use Diffie-Hellman
> to establish the session key in the first place, since you could just
> store each user's pre-established session key in advance.

Right - using DH exchange is probably appropriate in situations where
there is no pre-established credentials for the party on the other
machine.  Inter-domain authentication while possible in theory is not
often carried out to any great extent in reality.  Companies don't trust
each other, or at least are not concerned by this lack of security for
inter-domain communications. 

-Thomas

Thomas Grant Edwards says:
> Right - using DH exchange is probably appropriate in situations where
> there is no pre-established credentials for the party on the other
> machine.

D-H also provides perfect forward secrecy, which is a reason to use it
even if there is already an established set of credentials.

.pm

> > Right - using DH exchange is probably appropriate in situations where
> > there is no pre-established credentials for the party on the other
> > machine.
> 
> D-H also provides perfect forward secrecy, which is a reason to use it
> even if there is already an established set of credentials.

How about public-key signing the D-H exchange?  Public key to eliminate[*]
the man-in-the-middle attack, and D-H for forward secrecy.

* Almost eliminate.  A sufficiently powerful man in the middle could 
  conceivably subvert the public keys.

--apb (Alan Barrett)

From: Matt Blaze <mab@research.att.com>

   [this = storing secrets]
   At the extreme, fixing this is a Hard Problem.  In practice for establishing
   a reasonably secure session, it all depends on how much you worry about a
   full-blown (two way) spoofing attack against IP.

I know Matt realizes, but let me repeat for the rest of the list.

Just because plain old Diffie Hellman is subject to active attack
doesn't mean it's useless.  Some protection is better than no
protection at all.  It's still worthwhile implementing some security
to make an opponent's task harder than to implement no security.

And just because some people find this level of security inadequate
does not mean that everyone else does.

Eric

On Tue, 31 Jan 1995, Eric Hughes wrote:

> Just because plain old Diffie Hellman is subject to active attack
> doesn't mean it's useless.  Some protection is better than no
> protection at all.  It's still worthwhile implementing some security
> to make an opponent's task harder than to implement no security.

I'm curious though if there is some way to reduce the risk or at least 
increase the detectability of active DH spoofing.   I am thinking of the 
use of a trusted adjudicator who could receive information from both the 
original participants and check to see if the two keys matched.

Does anyone see a good solution to this problem?

-Thomas

From: Thomas Grant Edwards <tedwards@src.umd.edu>

   I am thinking of the 
   use of a trusted adjudicator who could receive information from both the 
   original participants and check to see if the two keys matched.

How do you authenticate the adjudicator?

You'll have to communicate with the adjudicator and verify one of
their signatures.  You can just as easily exchange signed DH
parameters directly with the other party and verify the signature of
your correspondent.

This is another one of those problems where potential solutions often
just lead to infinite regress.

Eric