[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Forwarded mail
I believe this was destined for ipsec, not ipsec-request...
| Dan |
---
Forwarded message:
> From hughes%hughes.network.com@ans.net Mon Apr 25 13:58:53 1994
> From: hughes@hughes.network.com (James P. Hughes)
> Message-Id: <9404251310.ZM1633@hughes.network.com>
> Date: Mon, 25 Apr 1994 13:10:51 -0500
> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail)
> To: ipsec-request@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 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:
>
>
--
Dan Simoes dans@ans.net
Associate Programmer (914) 789-5378
Advanced Network & Services Elmsford, NY