DISTRIBUTION NOTE
This protocol will not be distributed via anonymous ftp. If
interested, contact xkernel-bugs@cs.arizona.edu about obtaining this
protocol.
SPECIFICATION
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 
),
which will then provide the key to encryption modules
(CRYPT, pagepagerefCRYPT).
After negotiating the key, DHKX becomes transparent (passing messages
unchanged in either direction), so that it may be composed inside a
chain of protocols.
SYNOPSIS
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.
REALM
DHKX is in the ASYNC realm.
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.
CONTROL OPERATIONS
DHKX does not have any of its own control operations. All control
operations are passed unchanged to the lower protocol or session.
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:
--------------------------------- @; 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; ---------------------------------
Example of a keys file, keysdhkxtest:
--------------------------------- 4 0-8 10 0xc00c4582 0807060504030201 0xc00c4587 080706050403d213 0xc00c456e 0103040506070802 0xc00c4574 3141592653589793 0xc00c4554 2718281828459045 0xc00c4589 9876543210fedcba ---------------------------------
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.
AUTHOR
Richard Schroeppel