[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tunnel Establishment Protocol II


I'm really not sure why there is so little activity on this group.  I
suppose by not commenting before, I am partially responsible for this
silence.  It's also partly that they are a limited number of
interested people with limited time and lots of other claims on their
time...

From:  hughes@hughes.network.com (James P. Hughes)
X-Mailer:  Z-Mail (3.1.0 22feb94 MediaMail)
To:  ipsec@ans.net
Cc:  atkinson@itd.nrl.navy.mil
Content-Type:  text/plain; charset=us-ascii
Mime-Version:  1.0
>
>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 don't mind appearing foolish, it's just that I don't have the time
to comment on everything I would like to comment on.

>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.

?  This doesn't talk at all about IP encapsulation.  It seems to be
only an incomplete session key negotiation protocol.  Based on my
experience in dnssec, you can rest assured that pushing to really make
it a standards track RFC will cause lots of big guns to blast you at
least for suggesting the use of RSA due to patent issues, failing to
provide for multiple algorithms, and probably lots of other things.

Procedurally, I believe any standards track RFC is *required* to be up
as an Internet Draft for at least two weeks before the RFC comes out
and this is a good idea for Informational, Experimental, etc. RFCs
also.  So you should get the specs and reformat as an Internet Draft.

Also, of course, you need rough consensus to go to Proposed Standard
(the first standars track rung) and assuming this from the silence
that has occured so far would be a big mistake.

>		Speak up! :^)

Some overall comments: This reads to me like a pretty rough incomplete
spec that addresses way too narrow a part of the problem.  It seems to
believe in only a single tunnel between any pair of IP addresses and
fails to adequately address multicast, multi-homed hosts, tunnels
between subnets or a host and a subnet as distinguished from between
two hosts, cases where a host crashes and reboots rapidly (this point
may be covered by but it's not at all clear (I suggest adding a state
diagram)), cases where you want multiple tunnels between singly homed
hosts (yes, I know the arguments that it is logically unnecessary to
have more than one such tunnel but the fact remains that many people
consider it a requirement in the muilti-level secure world), etc.,
etc.,

>One questions I do have is:
>
>Is the "pounding on the tunnel creation task" a real important threat? Removin
g
>this eliminates one RSA decryption as well as eliminating any data hiding
>during key negotiation.

Sure it's a threat.  Everything you can imangine the adversary doing
is a threat.  I'm not sure just how common a threat it will be
though..

>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.

You are going to have to provide for and document a capability for at
least adding additional alternative security algorithms later for
everything.

>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.

See my remarks above.  You are going to have to allow multiple tunnels
between a pair of IP addresses.  If someone can sniff the wire and
fire lots of old packets at you, they can probably deny service by
just flooding it with crap or cutting the wire.  You should be secure
against replay, etc., within the security policy you are enforcing,
but I wouldn't worry that much about this punding threat as such.

>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.

I assume the point of mentioning this threat is that with randomly
derived Diffie-Hellman session keys that are destroyed after the
session, later compromise of either end (or both ends) does not reveal
a way to decrypt the traffic sent.  Yet you don't say so.

>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.

The more you start talking about licensing the more or a morass you
get into and the more lawyers you need drafting and reviewing your
paper.  I suggest you say the minimum you feel good with like: "Some
of the algorithms used in this protocol are coverd by patents in some
countries." or perhaps saying nothing.  If this becomes an RFC, why
have it mucked up with patent stuff which will expire in not that many
years?

>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.

Somewhat the same as licensing.  You have the choice of a weak
algorithm or one exportable from the US.  Since there are plenty of
smart people in other countried who can implement crypto, you should
obviously go with strong algorithms as they are no bar to global
interoperability.

>Further information TBD.
>
>The key establishment protocol
>
>The protocol is comprised of two messages.

Using just two messages is good.

>        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.

Traditionally, IETF protocols are timing independent and don't use
keep alives.  I don't see that they are needed here.  Instead you
should have a tunnel tear down message.

>. 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.

I don't see any point in all this tunnel lifetime stuff.  Just send a
tear down message when you want the tunnel to go away.

>"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 +.

Although it would not make much difference in this case, RSA is more
secure when padded at the top rather than at the bottom. In fact, you
probably want to use something very much like PKCS#1 (Public Key
Cryptographic Standard No. 1).  You can get this by anonymous ftp from
rsa.com.

>"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 synchronousness of your tunnel re-negotiation seems like a
problem.  It seems better to set up a new tunnel and then, after a
reasonable timeout for straggler packers, to close the old one.  Have
you really considered what happens for all the cases of miss ordered /
lost / duplicated data and control packets?  What if the data being
sent through the tunnel is pseudo-real time like voice?

> 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

Anyway, those are some comments off the top of my head.

Hope you find them useful.

Donald