% $RCSfile: dhkx.tex,v $
%
% $Revision: 1.1 $
% $Date: 1995/07/28 21:16:13 $
%

\protspec{DHKX}{DHKX (Diffie-Hellman Key Exchange Protocol)}
\index{dhkx}
\label{DHKX}

\input cryptDist

\topic{SPECIFICATION}

\noindent
THIS IS EXPERIMENTAL CODE; see ``Restrictions'' below.
DHKX negotiates a 56-bit DES key with its peer on a remote system.
The key is entered into a key manager protocol (KM, page~\pageref{KM}),
which will then provide the key to encryption modules
(CRYPT, page\~pageref{CRYPT}).
After negotiating the key, DHKX becomes transparent (passing messages
unchanged in either direction), so that it may be composed inside a
chain of protocols.

\topic{SYNOPSIS}

\noindent
When a DHKX session is opened, it opens the protocol below, and
performs a GETPARTICIPANTS operation to learn the fully resolved
addresses of the participants.  The participants are used to open
sending and receiving key manager (KM) sessions.  The DHKX protocol
then sends an OFFER message to the remote system.  If an appropriate
reply is received within ten seconds, a key is computed and entered
into both key manager sessions.  The protocol then enters the
transparent state.  If CRYPT and KM protocols are configured in the
protocol graph, they will use the negotiated key to encrypt and
decrypt subsequent messages on the channel.

When the DHKX protocol on the remote machine receives the offer
message, it opens two key manager sessions and the protocol above
itself.  Then DHKX computes and sends a reply, and computes the
session key and enters it into the sending and receiving key manager
sessions.  Finally, DHKX becomes transparent.

The advantage of the Diffie-Hellman method is that the negotiated
key never appears explicitly on the channel, so an eavesdropper will
have difficulty determining the negotiated key.

\topic{REALM}

DHKX is in the ASYNC realm.


\topic{PARTICIPANTS}

DHKX passes participants to the lower protocols without manipulating
them.  It uses the participants to open key manager sessions to enter
the keys for encryption and decryption.

\topic{CONTROL OPERATIONS}

DHKX does not have any of its own control operations.  All control
operations are passed unchanged to the lower protocol or session.

\topic{CONFIGURATION}

DHKX expects to be configured on top of a transport protocol and a
key manager. The transport protocol must preserve packet boundaries
(i.e. DHKX will not work on top of TCP).
DHKX requires a minimum packet size of 136 bytes to negotiate a key.
The most convenient way to use the DHKX protocol is to put the encryption
protocol somewhere above DHKX in the protocol graph.  If the encryption
protocol is below DHKX, then it must not interfere with the DHKX offer
and reply messages.
DHKX and the encryption protocol must be configured above the same
instance of KM.  The key magager must have an initial key for each
communicating host, obtained from a keys file.  These keys are never
used, but are overwritten by the DHKX protocol.

Example of a graph.comp file:
\begin{verbatim}
---------------------------------
@;
name=simeth/0;
name=eth protocols=simeth/0;
name=arp protocols=eth;
name=vnet protocols=eth,arp;
name=ip protocols=vnet;
name=km/dhkxtest;
name=dhkx protocols=ip,km/dhkxtest;
name=crypt protocols=dhkx,km/dhkxtest;
name=udp protocols=crypt;
name=udpcrypttest protocols=udp;
@;
prottbl = ../../../etc/prottbl.nonstd;
---------------------------------
\end{verbatim}

Example of a keys file, keysdhkxtest:
\begin{verbatim}
---------------------------------
4 0-8 10
0xc00c4582  0807060504030201  
0xc00c4587  080706050403d213
0xc00c456e  0103040506070802
0xc00c4574  3141592653589793
0xc00c4554  2718281828459045
0xc00c4589  9876543210fedcba
---------------------------------
\end{verbatim}

\topic{RESTRICTIONS}

THIS VERSION OF DHKX IS EXPERIMENTAL.
The Diffie-Hellman method requires a source of random numbers for
generating the offer and reply messages.  Ideally, a hardware
random number generator should be used.  We have experimented with
a subroutine, xkrandom, to provide the random numbers, but the code
is presently turned off.  In its place, fixed, compiled-in ``random''
values are used by the sender and receiver.
THE SAME KEY WILL BE NEGOTIATED EVERY TIME THE PROTOCOL IS USED.
This behavior masks another restriction due to the present key manager,
which uses key-per-host rather than key-per-host-pair.  If two DHKX
sessions are opened to differing destinations, the sending key for
the second session will overwrite the sending key for the first session.

This version of DHKX provides no protection against the ``man in the
middle'' attack, where there is an interposer in the communication path.

\topic{AUTHOR}

\noindent Richard Schroeppel