From ipsec-request@ans.net Tue Apr 12 12:34:12 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15779 (5.65c/IDA-1.4.4 for ); Tue, 12 Apr 1994 08:39:06 -0400 Received: by interlock.ans.net id AA21087 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 12 Apr 1994 08:33:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 12 Apr 1994 08:33:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 12 Apr 1994 08:33:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 12 Apr 1994 08:33:46 -0400 Date: Tue, 12 Apr 1994 08:34:12 -0400 (EDT) From: glenn@osi.ncsl.nist.gov (Robert Glenn) Subject: Re: IPng and security To: big-Internet@munnari.oz.au Cc: ipsec@ans.net, tuba@lanl.gov, glenn@osi.ncsl.nist.gov Message-Id: <9404121234.AA01433@osi.ncsl.nist.gov> Content-Transfer-Encoding: 7BIT There has been some recent discussion suggesting that the TUBA WG has taken a passive view on IPng security concerns. For example, at the SAAG meeting it was initially assumed that TUBA was going to use ISO NLSP to provide security services. As pointed out in "TUBA as IPng: A White Paper", we've been actively participating in the IPSEC WG to contribute to the development of an IPv4 security protocol that would/could also be used to provide the same security services for CLNP, figuring that a common security protocol could only benefit the transition from IPv4 to IPng. Due to the approaching July "decision point" and the lack of closure in the IPSEC WG, I've drafted a security protocol for TUBA based on the requirements and work that has already been accomplished by IPSEC. The initial premise used to devise this protocol was to keep it as simple as possible and only address those security concerns that, 1) could be effectively addressed by a network layer security protocol, and 2) provided protection for the areas that require security the most. By following this approach, a secure encapsulation protocol for CLNP and IPv4 to provide confidentiality and integrity has been drafted. As soon as the draft is finished it will be posted as an I-D. From ipsec-request@ans.net Thu Apr 14 17:51:56 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16354 (5.65c/IDA-1.4.4 for ); Thu, 14 Apr 1994 13:48:57 -0400 Received: by interlock.ans.net id AA14576 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 14 Apr 1994 13:44:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 14 Apr 1994 13:44:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 14 Apr 1994 13:44:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 14 Apr 1994 13:44:08 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9404141251.ZM7770@hughes.network.com> Date: Thu, 14 Apr 1994 12:51:56 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: ipsec@ans.net 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 From dans@ans.net Mon Apr 25 18:15:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12979 (5.65c/IDA-1.4.4 for ); Mon, 25 Apr 1994 14:24:52 -0400 Received: by interlock.ans.net id AA04299 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 25 Apr 1994 14:18:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 25 Apr 1994 14:18:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 25 Apr 1994 14:18:54 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 25 Apr 1994 14:18:54 -0400 From: Dan Simoes Message-Id: <199404251815.AA64080@foo.ans.net> Subject: Forwarded mail To: ipsec@ans.net Date: Mon, 25 Apr 1994 14:15:42 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 19504 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 From ipsec-request@ans.net Mon Apr 25 19:12:07 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01616 (5.65c/IDA-1.4.4 for ); Mon, 25 Apr 1994 15:08:12 -0400 Received: by interlock.ans.net id AA15651 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 25 Apr 1994 15:05:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 25 Apr 1994 15:05:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 25 Apr 1994 15:05:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 25 Apr 1994 15:05:40 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9404251412.ZM2053@hughes.network.com> Date: Mon, 25 Apr 1994 14:12:07 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: ipsec@ans.net Subject: Tunnel Establishment Protocol II 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: --- End of forwarded mail from hughes@hughes.network.com (James P. Hughes) -- jim