[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tunnel Establishment Protocol II
Hi:
The silence on this list has been deafening. I expect that few are willing to
come forward and risk sounding foolish. Well, I need your comments and
questions so that we can start a dialog and get things rolling.
I have updates this based on one private (within my company) email and a few
thoughts that I have had on my own since the original message was posted.
I would suggest that this become an RFC for the IPSEC encapsulation, but I
want input from the group.
Speak up! :^)
One questions I do have is:
Is the "pounding on the tunnel creation task" a real important threat? Removing
this eliminates one RSA decryption as well as eliminating any data hiding
during key negotiation.
Changes from previous version.
The malicious user can only cause a single RSA decryption if there is no
current tunnel.
Differing RSA modulus has been allowed.
Negotiation of Diffie Hellman n and g allowed. Suggested n and g will be part
of the spec. Actual values TBD.
Minimum time of day synchronization detailed.
Still TBD, the actual tunnel parameters to be negotiated.
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 as well
as reliably negotiate a session key.
A 2 message authentication/session key negotiation was chosen because the
complexities of multiple messages and large state machines.
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" (a active attacker) 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 the proper "once" which was
transmitted during the last negotiation. 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. This vulnerability can be limited by queueing only the oldest
packet per requestor IP address if the tunnel renegotiation task is busy.
In addition, intervening nodes which know the senders public key can validate
the packets.
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 probably be known to be compromised and never
used again. What we are trying to protect is all previous messages passed
before the rubber hose is applied even if though private key is compromised.
Licenses.
The developer is warned that both RSA and Diffie-Hellman licenses may be
needed to create a compliant implementation. This document does not imply that
these licences or any other licences necessary to implement this have been
waved.
Export.
Both Diffie-Hellman and RSA are export restricted and export licences must be
obtained. This document does not imply that these restrictions have been
eased. Check your government requirements.
Further information TBD.
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 and outside RSA).
Sending traffic on the new tunnel or sending a Tunnel alive message will
complete the negotiation.
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.
.
. Time out.
.
Tunnel alive ---------------------------------------->
<-----------------------------------------
Tunnel alive ack
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 | |RSA1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Tunnel Lifetime | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +
| Tunnel request and parameters (TBD) (? words) | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |RSA2
| Random Padding (? words) | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + |
| Known Value 2 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
| MD5 residue (2 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 Midnight, 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, and needs to be synchronized to
plus or minus 30 minutes of correct. (The destination should also be plus or
minus 30 minutes, thus the total allowable delta between the two is one hour.)
The microseconds can be an increment. (A normal BSD gettimeofday() call should
be sufficient.)
"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). When a 512 bit public key (the smallest recommended
value) 416 bits or 52 bytes would be available for tunnel parameters. Details
TBD.
"Reply identifier" is the value expected in the reply. This is a random number
that will be used once. This is in an area that is encrypted by the receivers
public key so that an eavesdropper can not determine which number will be user
in the reply, and thus send many packets with this number, thus clogging up
the destination.
"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. If both
sides are using the same modulus, then the start and end of the packets are
both offset by 2 words. If the modulus differ, then the largest one is used to
calculate the padding. Both RSAs will be anchored at the *. The calculation
with the shorter modulus is allowed to fall short of the +.
"Known Value 2" is a value used to determine the authenticity of the packet.
This is encrypted by the senders private key and thus could only be sent by
the indicated sender. The MD5 would also solve this problem, but the
identifier is faster.
RSA is used for 2 purposes. The first (from inner to outer) is to obscure the
reply identifier and tunnel parameters. The second is to sign the message.
These are offset within the packet so that an identifier will appear when the
packet first unsealed with the senders public key.
MD5 is used to sign include the g, n and X in the signature. This also
guarantees that the proper keys were.
The Diffie Hellman modulus length (in bytes) is then followed by the 3 values,
g, n, and X=(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
indicates that it is from the correct requestor. If the request id is 0,
and the tunnel is still operational (as of last tunnel alive request),
then toss the packet. (The request 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. If there is a time
of day from the other side (from a previous tunnel negotiation) check that
this time is 1) has a larger value and 2) validate that the time of day is
within one hour of being correct. If there is no known time of day for
this source (i.e. no tunnel since my last master clear) just do the within
an hour check.
2. The outside RSA protection is encrypted by the requesters public key.
The
Known Value 2 is checked to ensure it is the proper value. This
authenticates the sender, (but not the integrity of the packet).
3. The inside RSA protected data is decrypted by the receivers private
key.
4. 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.
6. Tunnel parameters are determined to be acceptable and finalized for the
reply packet.
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.
8. Set up the tunnel. (Leave the previous tunnel operational.)
The responder then sends the reply packet. (All fields are in the same
positions as the request, thus the reply can be accomplished in the same
buffer).
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 re-sent 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 new SAID
tunnel. This can either be a packet or a Tunnel Alive message.
The contents of the tunnel reply is (the same as the original packet format
with certain fields updated):
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 (Y=g^y mod n) (16 through 64 words) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | *
| Reply identifier | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Tunnel Lifetime | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +
| Tunnel request and parameters (TBD) (? words) | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |
| Random Padding (? words) | | |RSA2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + |
| Known Value 2 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
| MD5 residue (2 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 Value 2" is the same value used in the original message.
"Tunnel Lifetime" is the negotiated value. This value may be as 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 in the same manner as the request with the usage of
public and private keys reversed.
The Diffie Hellman modulus length (in bytes) is then followed by the g, n and
(g^y)mod n. (y is the secret value.) This is resent in the return packet in
case the destination did not like the first set of values. The reject will
contain a new set of suggested n and g. The source can use these values as a
hint for what to use. The source should not use the same x for any
renegotiation.
When the packet is received the following steps are performed.
1. The source, destination and reply identifier are validated to be
correct.
2. The RSA protected data is encrypted by the responders private key and
Expected Value 2 checked.
3. The inner RSA data is decrypted by the receivers private key.
4. Verify MD5 is correct. The packet has now been validated.
5. Calculate the value Y^x mod n. A number of these bits are used as the
session key.
6. Process the tunnel parameters and set up the tunnel.
The authenticated key exchange is now complete. The new SAID may be used.
Recommended values.
Minimum public keys of 512 bits. Public key modulus must be a multiple of 32
bits.
n and g are a minimum of 512 bits and recommended values are:
n=
g=
Sample negotiation.
Requestors public key:
Requestors private Key:
Responders public key:
Responders private key:
Example tunnel request packet:
Example tunnel reply packet:
Resulting Key and SAID:
--- End of forwarded mail from hughes@hughes.network.com (James P. Hughes)
--
jim