[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[[email protected]: Encrypting tunnel negotiation protocol]
This came across the ipsec list.
Apologies to those who have already seen it.
Eric Blossom
----------------------------------------------------------------
Return-Path: <[email protected]>
From: [email protected] (James P. Hughes)
Date: Thu, 14 Apr 1994 12:51:56 -0500
X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail)
To: [email protected]
Subject: Encrypting tunnel negotiation protocol
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
This is a discussion that I promised to start at the last IETF.
This is a long email, so I will ask for any comments here at the start.
Thanks
jim
-------------------
Introduction.
This note is to start a discussion regarding key negotiation for encrypting
tunnels. There are several specific attacks and authentication capabilities
that will be addressed.
The tunnel establishment protocol must negotiate several parameters and well
as reliably negotiate a session key.
A 2 message authentication/session key negotiation was chosen because of the
complexities of multiple messages.
Authentication will be accomplished with RSA. Getting certified public keys
will be beyond this document. It is expected that they will be distributed via
"secure sneaker-net", via secure DNS or X.509 certification services. An
example of a secure sneaker-net is where the public keys are gathered together
on a disk and then distributed to potential partners. During this phase the
disk mst be guarded to ensure that "Mallet" can get at the disk and replace
the keys. After the keys are loaded into the partners, they must be protected
form unauthorized external writes and/or erasures.
Attacks addressed will be "denial of service because of message playback",
"man in the middle", and "rubber hose" attacks.
Denial of service
It is expected that processing tunnel establishment messages will be an
processor expensive task, and this protocol is intended to minimize the
processing required to determine if a tunnel establishment packet is not an
old packet or a malicious packet created to "clog up" the tunnel establishment
task.
If the tunnel is established, a tunnel request will be ignored unless the
request has the proper identifier. If there is an active tunnel, then there
will be an active tunnel negotiation request identifier. A malicious user can
not interrupt an exiting tunnel without this "once". Once a request is
received, that request identifier is (probably) not used again.
When a tunnel is not established, there is not an existing tunnel negotiation
request identifier, and a malicious user can create a packet that passes the
initial checks. All a malicious user can cause is a one block of RSA
decryption, one block of RSA encryption and a MD5 calculation. This
vulnerability can be limited by queueing only the oldest packet per requestor
IP address if the tunnel renegotiation task is busy.
If the malicious user sends in old packets, the increasing time of day check
will be enough to catch them. if the user modifies the time of day, then the
RSA and MD5 checks will catch that.
In either case, the malicious user can not interrupt existing tunnels and if
the tunnel request processing is a background, low priority task, throughput
will not be adversely effected.
Other attacks.
Man in the middle is addressed with (unspecified) trusted public key
distribution mechanism.
Rubber hose attack is where the private key is extracted through (possible
painful means) and all previous messages passed can then be decrypted. The
more common method of using this would be to "steal" the host or router and
then use in circuit emulators or the like to extract the public key. After an
attack like this the key would be compromised and never used again. What this
is trying to protect is all previous messages passed before the rubber hose is
applied even if the private key is compromised.
The key establishment protocol
The protocol is comprised of two messages.
Requestor Responder
Tunnel Request ----------------------------->
<---------------------------------- Tunnel Reply
If there is not a reply from the first packet, the source will resend the
packet with a new time of day (and recomputed MD5).
Sending traffic on the new tunnel or sending a Tunnel alive message will
complete the negotiating.
Tunnel keep alive messages are sent and acknowledged at a predetermined
regular basis. Both sides send the requests and both sides send the Ackd.
These messages are passed within the tunnel and are encrypted by that process.
The format of the tunnel alive messages are in the tunnel document.
The contents of the tunnel request is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Requestor IP address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Responder IP address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Request Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Time of Day (2 words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Diffie-Hellman modulus Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| g (16 through 64 words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MD5
| Modulus (16 through 64 words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Diffie-Hellman (X=g^x mod n) (16 through 64 words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +
| Reply identifier | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Tunnel request and parameters (TBD) (? words) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Tunnel Lifetime | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + RSA
| MD5 residue (2 words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Padding (Random data) (? words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
"Request Identifier" is the value from the last tunnel negotiation that
identifies this packet as the correct tunnel renegotiation packet. If there is
not a current tunnel in effect then this is 0.
"Time of day" is the unix format time of day, that is, the high word contains
the number of seconds since January 1, 1970 GMT, and the second word contains
the number of microseconds elapsed during the current second. The clock needs
to be monotonically increasing, but does not need to be synchronized. The
microseconds can be an increment.
"Tunnel request parameter" contains information which is used in the
negotiation of the tunnel. This includes tunnel ID (SAID), encryption type(s),
compression type(s). Details TBD.
"Reply identifier" is the value expected in the reply. This is a random number.
"Tunnel Lifetime" is the expected time for the tunnel to live. This value,
added to the local time of day creates both the expected time of day to be
used in the next request as well as allowing the Responder to calculate the
time after which it is to expect that negotiation to occur. Tunnel
renegotiation can occur sooner if the tunnel keep alive messages show that the
tunnel has collapsed.
"Random Padding" is used to pad out the block to the RSA modulus.
RSA is used to double encrypt this with the requestors private key and the
responders public key. The double protection will obscure from any potential
eavesdroppers the exact encryption methods, compression options as well as
renegotiation times and reply identifier.
The Diffie Hellman modulus length (in bytes) is then followed by the 3 values,
g, n, and (g^x)mod n. (x is the secret value to be used to calculate the key
later.) The length can be from 512 to 2k bits.
When the packet is received the following steps are performed.
1. The IP address, request ID are validated to ensure that the packet is from
the correct requestor. If the requestor id is 0, and the tunnel is still
operational (as of last tunnel alive request), then toss the packet. (The
requestor id should be 0 only if the tunnel is not operational.) If the
request is 0 and the tunnel is not operational, the time of day is checked to
ensure it is increasing.
3. The RSA protected data is decrypted by the responders private key and then
encrypted by the requesters public key.
2. MD5 hash of the entire packet is calculated and determined to be correct.
The originator and this packet has been authenticated.
5. The time of day is saved as being correct.
7. Create the random number y and calculate the value X^y mod n. A number of
these bits are used as the session key.
The responder then creates a reply packet.
Once the packet is sent, the responder should be ready to accept packets using
the new SAID. (Packets using the existing SAID can continue to be sent.)
The reply should be resent after time-out until a packet is received on the
tunnel.
The responder can not use the SAID until a packet is received on the tunnel.
The contents of the tunnel reply is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Requestor IP address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Responder IP address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Reply identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Time if Day (2 words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Diffie-Hellman modulus Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MD5
| Diffie-Hellman (Y=g^y mod n) (16 through 64 words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +
| Next Request identifier | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Tunnel request and parameters (TBD) (? words) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSA
| Tunnel Lifetime | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
| MD5 residue (2 words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Padding (Random data) (? words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
Where "Time of day" is the time received in the request. (Actually, this is
not used, but it is easier to leave the space there.)
"Tunnel request parameter" contains results of the negotiation. This includes
tunnel ID, encryption type(s), compression type(s). Details TBD.
"Fixed Pattern" A value to ensure that the RSA decryption was successful.
"Tunnel Lifetime" is the value received in the request or smaller.
"Random Padding" is used to pad out the block to the RSA modulus.
RSA is used to double encrypt this with the responders private key and the
requestors public key.
The Diffie Hellman modulus length (in bytes) is then followed by the (g^y)mod
n. (y is the secret value.)
When the packet is received the following steps are performed.
1. The source, destination and time are validated to be correct.
2. MD5 is calculated over the packet.
3. The RSA protected data is decrypted by the requestors private key and then
encrypted by the responders private key.
4. The fixed pattern is checked. The packet has now been validated.
5. Verify MD5(2) is correct.
5. Calculate the value Y^x mod n. A number of these bits are used as the
session key.
The new SAID can now be used.
--
jim