From ipsec-request@ans.net Mon May 9 08:16:32 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13271 (5.65c/IDA-1.4.4 for ); Mon, 9 May 1994 04:20:47 -0400 Received: by interlock.ans.net id AA09927 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 9 May 1994 04:16:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 9 May 1994 04:16:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 9 May 1994 04:16:40 -0400 Date: Mon, 9 May 94 10:16:32 +0200 From: karol@tele.pw.edu.pl (Karol Gorski) Message-Id: <9405090816.AA28724@leszpt.tele.pw.edu.pl> To: ipsec@ans.net Subject: Subscription request Hi, Could you add my name to this mailing list, please. Thanks in advance, Karol Gorski Institute of Telecommunications, Warsaw, Poland. email: karol@tele.pw.edu.pl From ipsec-request@ans.net Mon May 9 07:49:27 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01746 (5.65c/IDA-1.4.4 for ); Mon, 9 May 1994 07:49:27 -0400 Received: by interlock.ans.net id AA02941 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 9 May 1994 07:46:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 9 May 1994 07:46:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 9 May 1994 07:46:43 -0400 From: Peter Lipp Message-Id: <199405091151.AA21568@fiaikss04.tu-graz.ac.at> Subject: help To: ipsec@ans.net Date: Mon, 9 May 94 13:51:53 MET DST X-Mailer: ELM [version 2.3 PL11] From ipsec-request@ans.net Mon May 9 07:16:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16163 (5.65c/IDA-1.4.4 for ); Mon, 9 May 1994 11:34:35 -0400 Received: by interlock.ans.net id AA16665 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 9 May 1994 11:25:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 9 May 1994 11:25:41 -0400 Date: Mon, 9 May 94 11:16 EDT From: TCJones@DOCKMASTER.NCSC.MIL Subject: SUBSCRIBE To: ipsec@ans.net Message-Id: <940509151613.137652@DOCKMASTER.NCSC.MIL> SUBSCRIBE TCJ From ipsec-request@ans.net Mon May 16 13:07:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16420 (5.65c/IDA-1.4.4 for ); Mon, 16 May 1994 09:30:49 -0400 Received: by interlock.ans.net id AA22339 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 16 May 1994 09:16:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 16 May 1994 09:16:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 16 May 1994 09:16:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 16 May 1994 09:16:23 -0400 Message-Id: <9405161307.AA05101@skidrow.lkg.dec.com> To: hughes@hughes.network.com (James P. Hughes) Cc: ipsec@ans.net Subject: Re: Tunnel Establishment Protocol II In-Reply-To: Your message of "Mon, 25 Apr 94 14:12:07 CDT." <9404251412.ZM2053@hughes.network.com> Date: Mon, 16 May 94 09:07:41 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp 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 From ipsec-request@ans.net Mon May 16 19:17:40 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13228 (5.65c/IDA-1.4.4 for ); Mon, 16 May 1994 15:20:13 -0400 Received: by interlock.ans.net id AA09505 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 16 May 1994 15:10:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 16 May 1994 15:10:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 16 May 1994 15:10:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 16 May 1994 15:10:26 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9405161417.ZM3202@hughes.network.com> Date: Mon, 16 May 1994 14:17:40 -0500 In-Reply-To: "Donald E. Eastlake 3rd (Beast)" "Re: Tunnel Establishment Protocol II" (May 16, 9:07am) References: <9405161307.AA05101@skidrow.lkg.dec.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Donald E. Eastlake 3rd (Beast)" , hughes@hughes.network.com (James P. Hughes) Subject: Re: Tunnel Establishment Protocol II Cc: ipsec@ans.net, Ken.Hardwick@nsco.network.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On May 16, 9:07am, Donald E. Eastlake 3rd (Beast) wrote: > >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. In talking to the people in charge, they had a suggestion that the work in this group could be accomplished with 2 documents. One for the key setup and one for the tunnel itself. I was going forward on the key setup half. Hopefully, someone will come forward for the tunnel part. > 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. I wanted to know that this was a valuable effort so as not to be wasting our collective time. > 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. Agreed. > 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., More then one tunnel is indeed needed. > >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. > > 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.. I will continue to address this threat. > You are going to have to provide for and document a capability for at > least adding additional alternative security algorithms later for > everything. OK. > 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. OK. > 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. Yes, although I consider that an implementation issue. A not to the wise would be best. > >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? Good statement. > 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. Ditto. > >The protocol is comprised of two messages. > > Using just two messages is good. > >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. The problem I am trying to address is the case where there are multiple gateways (routers) to the same destination. In this case, if a router fails, traffic will just cease. Without the keepalives, the tunnel can not migrate to another router. > >"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. If an attacker wants the tunnel to stay up longer (because he cracked the key) he can just toss any tunnel teardown messages. Is this a problem? > >"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. OK. > >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? I will add more about keeping a tunnel alive while the next tunnel is being negotiated. What you said -is- what I intended. > Anyway, those are some comments off the top of my head. > > Hope you find them useful. Yes, I do, and I will continue. I will also try to put these into a standard IETF form. > Donald jim From ipsec-request@ans.net Tue May 17 07:16:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06339 (5.65c/IDA-1.4.4 for ); Tue, 17 May 1994 07:16:53 -0400 Received: by interlock.ans.net id AA13099 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 May 1994 07:05:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 May 1994 07:05:56 -0400 Message-Id: <199405171105.AA13095@interlock.ans.net> Date: 17 May 94 11:59:00 WET From: "Tim Dean" Subject: IPSEC meeting and NLSP To: "ipsec" I'm having some difficulty discovering any details about the forthcoming IPSEC meeting, which I would like to attend. I've just about gathered that it's in Toronto on 25th to 29th July, but that's about it. Could someone point me towards whom or what I should do to get further info. Do I need to send clearances, etc... We here at the Defence Research Agency in the UK have just completed a proof-of-concept implementation of ISO's `Network Layer Security Protocol' (NLSP) and are currently looking at the feasibility of adapting it for a TCP/IP environment. Is anyone else out there doing anything similar who could offer insights into difficulties/issues involved? Any help on either of the above much appreciated! Tim Dean Rm L110, DRA-Malvern Open Distributed Systems St Andrew's Road Software Engineering and CIS Technology Dept Malvern, Worcestershire Defence Research Agency WR14 3PS United Kingdom Tel: +44-684-894239 Fax: +44-684-896113 E-mail: Dean@hydra.dra.hmg.gb From ipsec-request@ans.net Tue May 17 12:34:11 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18278 (5.65c/IDA-1.4.4 for ); Tue, 17 May 1994 08:45:55 -0400 Received: by interlock.ans.net id AA12969 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 May 1994 08:38:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 May 1994 08:38:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 May 1994 08:38:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 May 1994 08:38:23 -0400 Message-Id: <9405171234.AA12329@skidrow.lkg.dec.com> To: "Tim Dean" Cc: "ipsec" Subject: Re: IPSEC meeting and NLSP In-Reply-To: Your message of "17 May 94 11:59:00 +0700." <199405171105.AA13095@interlock.ans.net> Date: Tue, 17 May 94 08:34:11 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Check in any of the IETF shadow directories such as ds.internic.net:/ietf and look for files beginning with the arabic digit 0. That should give you most of the available information on upcoming IETF meetings. While I'm sure that the ipsec Working Group would welcome input and is more or less aimint at the network level, it has pretty well rejected any close following of ISO such as using Type-Length-Value encoding or assinine one (ANS.1). Donald From: "Tim Dean" To: "ipsec" > >I'm having some difficulty discovering any details about the >forthcoming IPSEC meeting, which I would like to attend. I've just about >gathered that it's in Toronto on 25th to 29th July, but that's about it. Could >someone point me towards whom or what I should do to get further info. Do I need >to send clearances, etc... > >We here at the Defence Research Agency in the UK have just completed a >proof-of-concept implementation of ISO's `Network Layer Security Protocol' (NLSP) >and are currently looking at the feasibility of adapting it for a TCP/IP >environment. Is anyone else out there doing anything similar who could offer >insights into difficulties/issues involved? > >Any help on either of the above much appreciated! > >Tim Dean > Rm L110, DRA-Malvern >Open Distributed Systems St Andrew's Road >Software Engineering and CIS Technology Dept Malvern, Worcestershire >Defence Research Agency WR14 3PS >United Kingdom Tel: +44-684-894239 > Fax: +44-684-896113 > E-mail: Dean@hydra.dra.hmg.gb From ipsec-request@ans.net Tue May 17 05:50:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15855 (5.65c/IDA-1.4.4 for ); Tue, 17 May 1994 10:00:03 -0400 Received: by interlock.ans.net id AA17825 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 May 1994 09:50:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 May 1994 09:50:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 May 1994 09:50:04 -0400 Date: Tue, 17 May 94 09:50:00 EDT From: Robert Glenn Message-Id: <9405171350.AA25588@osi.ncsl.nist.gov> To: ipsec@ans.net Subject: I-NLSP for TUBA Cc: glenn@osi.ncsl.nist.gov Originally, the TUBA WG intended to work within the IPSEC WG for its lower layer security requirements. Because of perceived dead-lines, and various other reasons, it was decided shortly after the Seattle meeting, that TUBA would need it's own security protocol. Leveraging off of the knowledge learned from participating in the IPSEC WG, I have re-written I-NLSP in support of TUBA. "I-NLSP for TUBA" is a major revision with a new simple, fixed-length packet format that provides security for both CLNP and IPv4. I would appreciate comments on the new I-D. It should be of interest to this group, particularly because it provides a security solution for IPv4. It was announced yesterday on the ietf-announce list and resides on your favorite I-D ftp site. I've included the announcement with this message. Thanks, Rob G. ----- Begin Included Message ----- From tuba-request@noc-gw.lanl.gov Mon May 16 13:48:38 1994 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US@noc-gw.lanl.gov Cc: tuba@Lanl.GOV From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-tuba-inlsp-00.txt Date: Mon, 16 May 94 13:44:14 -0400 Sender: cclark@CNRI.Reston.VA.US Content-Length: 3162 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP/UDP Over CLNP-Addressed Networks Working Group of the IETF. Title : Integrated Network Layer Security Protocol For TUBA Author(s) : K. Robert Glenn Filename : draft-ietf-tuba-inlsp-00.txt Pages : 25 Date : 05/13/1994 This Internet Draft specifies a protocol that may be used by End Systems (ESs) and Intermediate Systems (ISs) in order to provide security services in support of TUBA. The TUBA deployment and transition plan relies on a dual-stack (i.e., CLNP and IPv4) approach to evolving the Internet to IPng. Thus, to provide secure operation in an TUBA environment this Internet Draft defines a simple Integrated Network Layer Security Protocol (I-NLSP) that provides confidentiality and integrity services for both CLNP and IPv4. TUBA systems supporting I-NLSP will be capable of secure operations with: (1) other TUBA/I-NLSP systems using either CLNP or IP, and or (2) existing IPv4 operating behind TUBA/I-NLSP capable secure ISs. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-tuba-inlsp-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-tuba-inlsp-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940513155324.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-tuba-inlsp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tuba-inlsp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940513155324.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ----- End Included Message ----- From ipsec-request@ans.net Tue May 17 17:54:25 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06359 (5.65c/IDA-1.4.4 for ); Tue, 17 May 1994 14:10:17 -0400 Received: by interlock.ans.net id AA24994 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 May 1994 13:58:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 May 1994 13:58:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 May 1994 13:58:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 May 1994 13:58:44 -0400 Message-Id: <9405171754.AA14780@skidrow.lkg.dec.com> To: IP Secrity WG Subject: Re: My current thoughts on IPSEC In-Reply-To: Your message of "Thu, 31 Mar 94 10:25:36 EST." <9403311025.ZM8017@bodhi.itd.nrl.navy.mil> Date: Tue, 17 May 94 13:54:25 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Ran Atkinson In-Reply-To: "Donald E. Eastlake 3rd (Beast)" "My current thoughts on IPSEC" (Mar 31, 6:25) References: <9403311125.AA01325@skidrow.lkg.dec.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 23feb94) To: "Donald E. Eastlake 3rd (Beast)" Sender: atkinson@bodhi.itd.nrl.navy.mil >Don, (Ran, thanks for permission to include your personal mail to me in this response to the list) >When we looked into encapsulating security packet formats for SIPP, we >found that the flag bits and such like didn't really need to be >explicit or defined on a per packet basis. Instead, the >presence/absence of options for all packets of a particular session >can be implied by the SAID value in the same manner that the SAID >value already implies an algorithm/mode/key. I am not recommending >putting any meaning into the bits present in any SAID; I think the >SAID always should be a completely opaque identifier. Also, it might >be useful to indicate that the SAID might be directional (e.g. A-->B >uses SAID 1 and B-->A uses SAID 5) because this eliminates the need >for direction bits. I understand the simplicity of encoding everything in the SAID but there are capabilities you just can't get that way. There are a number of reasons for clear header information. For accounting / filtering purposes, you want to know if encryption is being used so you can look deeper into the packet when its not. Thus you need a clear encrypted/non-encrypted bit. (Of course having separate authentication and encryption encapsulation also solves this.) You could incorporate this into the SAID and have just an informational bit but I wouldn't bet it would be properly implemented unless you spec that the clear bit actually *controls* whether encryption is used or not. My protocol tries to handle isolated datagrams and broadcast/multicast as well as the negotiated point to point tunnel type thing and I think it useful to distinguish between these outside the SAID field. This is logically necessary if you have datagram SAIDs globally pre-defined by standards actions, multicast SAIDs relative to the sender, and negotiated unicast SAIDs disjoint from both other cases, as I have. In the higher level implementations, my proposal provides for options in either the clear or encrypted headers or both. For some types of global SAIDs (ie, datagram without set up), the encryption keying information is determined from a destination identity that is different-from/finer-grained than an IP address. The destination host needs to be able to see this destination identity in order to be able to decrypt (or pass it on to the right party who can decrypt) the encyrpted header. Therefore provisions for this optional type of destination identity must be made in the clear header. There are also provisions for security labeling via options in the clear header (authenticated but not encrypted) and well as the encyrpted header or both. Because many packets will not have any options (and lower level implementation need not provide for them other than to return an error), there is a clear header options-present bit so you don't waste any bytes when there are no options. I also included an optional time stamp so you need a bit to say if it is present or not. This bit and time stamp could have been in the clear or encyrpted header. They need to be authenticated but there is no need to encyrpt the time stamp. If present, its just the "current" time. I don't think I have any direction bits right now. >Did I miss the "crypto-synch" optional field in my quick scan of the >packet format ? If there isn't one, it needs to be added to ensure >algorithm-independence. SP3 called it a PAD field just before the >encrypted data; NLSP admitted that the field was for crypto-synch but >kept it in the same location. I disagree. I believe that cryto "synch" "pad" "ivp" etc. fields are all logically part of the cyrpto algorithm. Why explicitly label such fields when some low level algorithms need them and some don't? It just makes everything look more complicated and makes things you seem to think of as outside the crypto algorithm dependent on the crypto algorithm. In my mind, an encryption algorithm, for example, takes in data and a key and outputs data such that the corresponding decyrption algorithm with the corresponding decryption key recovers the original data. It should be of no concern to IPSP whether the encrypted data actually starts with a crypto-synch or whether the pre-encryption data had to be padded or if that padding was at the start or end of the data. >Based on discussions with various members of the community and also on >the output of the IAB Security Workshop, I'd like to suggest that we >consider decoupling the "authentication tail" into a separate >mechanism that can either stand-alone or be used with the >encapsulating security header. There is no technical merit in such a >split, but there is substantial commercial/user value in having an >exportable authentication-only mechanism. The only reason that SIPP >has two headers (Authentication Header & Encapsulating Security >Payload) is to ensure that we can universally implement and deploy at >least authentication-only in the Internet. I am not completely decided on the merits of this; however, I believe the export argument is specious. If you have a compile time switch to turn off the confidentiality code and export binaries with only authentication, there is no problem. >I like the effort to ensure that the mechanism is easily implemented >in software. That is important to having widespread deployment and >use. Thanks. I tried to take into account the lessons the Phil Karn has learned from implementation thus far. >Ran >atkinson@itd.nrl.navy.mil Donald From ipsec-request@ans.net Tue May 17 05:12:29 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13762 (5.65c/IDA-1.4.4 for ); Tue, 17 May 1994 15:31:12 -0400 Received: by interlock.ans.net id AA16359 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 May 1994 15:20:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 May 1994 15:20:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 May 1994 15:20:08 -0400 From: efb@suned1.Nswses.Navy.Mil (Everett F Batey) Date: Tue, 17 May 94 12:12:29 PDT Message-Id: <9405171912.AA17301@slced1> To: ipsec@ans.net Subject: Re: Quiet in the list (was:Tunnel Establishment Protocol II) Cc: hughes@hughes.network.com, dee@skidrow.lkg.dec.com This list has the most wordy postings of any I get .. try this if you want to communicate .. Exec Summy 10 lines .... Meaty objct 1 <= 25 lines ... Etc not to exceed 75-100 lines .. rest of it should be on a web server .. for all to cruise as needed .. comments might quote a lot less text .. I get 500 to 2500 email a day .. the long ones I trash on a bad day .. We trustable networks .. VR /ev/ From ipsec-request@ans.net Tue May 17 19:52:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04242 (5.65c/IDA-1.4.4 for ); Tue, 17 May 1994 16:08:11 -0400 Received: by interlock.ans.net id AA06212 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 17 May 1994 15:57:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 17 May 1994 15:57:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 May 1994 15:57:49 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 May 1994 15:57:49 -0400 Message-Id: <9405171952.AA15910@skidrow.lkg.dec.com> To: ipsec@ans.net Subject: Re: Quiet in the list (was:Tunnel Establishment Protocol II) In-Reply-To: Your message of "Tue, 17 May 94 12:12:29 PDT." <9405171912.AA17301@slced1> Date: Tue, 17 May 94 15:52:42 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I'm sorry, I don't believe that the meat of new IP security proposals can always be usefully discussed within your size limits. There are many people still at the end of uucp links that can't get to web servers. You are, of course, free to read or not read whatever you want and be on whatever email lists you want. Donald From: efb@suned1.Nswses.Navy.Mil (Everett F Batey) To: ipsec@ans.net Cc: hughes@hughes.network.com, dee > >This list has the most wordy postings of any I get .. try this if you want >to communicate .. > >Exec Summy 10 lines .... > >Meaty objct 1 <= 25 lines ... > >Etc not to exceed 75-100 lines .. rest of it should be on a web server .. for >all to cruise as needed .. comments might quote a lot less text .. > >I get 500 to 2500 email a day .. the long ones I trash on a bad day .. > >We trustable networks .. VR /ev/ From ipsec-request@ans.net Thu May 19 22:06:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14046 (5.65c/IDA-1.4.4 for ); Thu, 19 May 1994 15:23:44 -0400 Received: by interlock.ans.net id AA25012 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 19 May 1994 15:07:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 19 May 1994 15:07:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 19 May 1994 15:07:03 -0400 Date: Thu, 19 May 1994 22:06:00 +0000 (O) From: ERI Subject: Threats model for TCP/IP To: ipsec@ans.net Message-Id: <01HCJEWIEXIA000U4W@FRCU.EUN.EG> X-Vms-To: IN%"ipsec@ans.net" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Dear sir, I am Eng. Waleed Hosny From Egypt. I prepare for getting the Master degree in Computers Networking. My research point handles the security applied on the TCP/IP stack at the routing level. i.e. for the IP packets routing security. I am now in the stage of collecting the information. As I think I must know first what are the Threats that can attack the TCP/IP stack,in the whole stack as a general and at the network layer as a special case. My question is can I find the online documents that explain the Threats model. Would you please if you know FTP sites or repositories for these documents, I will be thankful. I am waiting for your reply Waleed Hosny eri@frcu.eun.eg 112 Pyramids St. Giza - Egypt 202 3830728 From ipsec-request@ans.net Fri May 20 00:59:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14093 (5.65c/IDA-1.4.4 for ); Fri, 20 May 1994 00:59:10 -0400 Received: by interlock.ans.net id AA15129 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 20 May 1994 00:50:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 20 May 1994 00:50:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 20 May 1994 00:50:00 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 20 May 1994 00:50:00 -0400 Date: Thu, 19 May 94 21:24:10 From: "Housley, Russ" Encoding: 1299 Text Message-Id: <9404197694.AA769407850@uu0892.spyrus.com> To: dee@skidrow.lkg.dec.com, ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: Re[2]: My current thoughts on IPSEC Donald and Ran: > ... Also, it might >be useful to indicate that the SAID might be > directional (e.g. A-->B >uses SAID 1 and B-->A uses SAID 5) > because this eliminates the need >for direction bits. The direction of the datagram is not authenticated in this approach. When the same key is used to protect traffic from A to B and from B to A, then a mechanism is needed to ensure that an attacker does not simply swap the from and to addresses. The SAID suggestion does not provide sufficient protection. With this approach, the attacker simply swaps the addresses and changes the SAID. After watching one datagram in each direction, the attacher will have all of the information necessary to "reflect" the traffic back to the originator. There must be some indication of direction which is cryptographically protected with the datagram. > I also included an optional time stamp so you need a bit to say > if it is present or not. This bit and time stamp could have been > in the clear or encyrpted header. They need to be authenticated > but there is no need to encyrpt the time stamp. If present, its > just the "current" time. How is the timestamp used? I do not see how these are authenticated? What security service do they provide? Russ From ipsec-request@ans.net Fri May 20 12:27:10 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18748 (5.65c/IDA-1.4.4 for ); Fri, 20 May 1994 08:37:20 -0400 Received: by interlock.ans.net id AA06368 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 20 May 1994 08:31:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 20 May 1994 08:31:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 20 May 1994 08:31:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 20 May 1994 08:31:15 -0400 Message-Id: <9405201227.AA08294@skidrow.lkg.dec.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: Re[2]: My current thoughts on IPSEC In-Reply-To: Your message of "Thu, 19 May 94 21:24:10." <9404197694.AA769407850@uu0892.spyrus.com> Date: Fri, 20 May 94 08:27:10 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Russ, From: "Housley, Russ" Encoding: 1299 Text To: dee, ipsec@ans.net, atkinson@itd.nrl.navy.mil > >Donald and Ran: > >> ... Also, it might >be useful to indicate that the SAID might be >> directional (e.g. A-->B >uses SAID 1 and B-->A uses SAID 5) >> because this eliminates the need >for direction bits. > >The direction of the datagram is not authenticated in this approach. >When the same key is used to protect traffic from A to B and from B to >A, then a mechanism is needed to ensure that an attacker does not simply >swap the from and to addresses. The SAID suggestion does not provide >sufficient protection. With this approach, the attacker simply swaps >the addresses and changes the SAID. After watching one datagram in each >direction, the attacher will have all of the information necessary to >"reflect" the traffic back to the originator. I think the simplest answer is not to use the same key for both directions. >There must be some indication of direction which is cryptographically >protected with the datagram. > > >> I also included an optional time stamp so you need a bit to say >> if it is present or not. This bit and time stamp could have been >> in the clear or encyrpted header. They need to be authenticated >> but there is no need to encyrpt the time stamp. If present, its >> just the "current" time. > >How is the timestamp used? I do not see how these are authenticated? What >security service do they provide? In my PIPS proposal, the time stamp, along with the black flags, is included in the calculation of the authentication tale. If present it is supposed to be set to the current time by the sender so the receiver can reject old messages. Receivers are not required to implement it and can ignore time stamps. When designing my packet layout, I tried to make fixed length fields, like the time and true source and destination addresses, optional fields whose presence is indicated by an option bit in the one byte each of black and red flags, and put variable length things like certificates or labels or OIDs for algorithms as self delimiting items in the variable length options structures. >Russ Thanks for your comments, Donald From ipsec-request@ans.net Fri May 20 00:19:00 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15835 (5.65c/IDA-1.4.4 for ); Fri, 20 May 1994 11:25:59 -0400 Received: by interlock.ans.net id AA12989 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 20 May 1994 11:20:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 20 May 1994 11:20:37 -0400 Message-Id: Date: Fri, 20 May 94 07:19 PDT From: jpp@jpplap.markv.com (Jay Prime Positive) To: hughes@hughes.network.com Cc: ipsec@ans.net In-Reply-To: <9405161417.ZM3202@hughes.network.com> Subject: Re: Tunnel Establishment Protocol II X-Signed: PGP-Detached-2-3, iQBXAgUBLdzG69C3U5sdKpFdAQE6hQIMC+8da1xg22mLjR2pLrPqS8Y71gwpBKa5 2kx6Kegww0I1vKBGFdbuwN0xlimvh3KjNFN9sg1lJCyI8zSR9VFlKGPw Let me apear _very_ foolish, and lost. What exactly is a 'tunnel protocol,' how do it and the 'key setup protocol,' relate to the bigger problem of ipsecurity? Is a tunnel protocol something like slip? Or is it a higher level protocol? j' From ipsec-request@ans.net Fri May 20 15:43:52 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12869 (5.65c/IDA-1.4.4 for ); Fri, 20 May 1994 11:43:27 -0400 Received: by interlock.ans.net id AA24978 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 20 May 1994 11:36:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 20 May 1994 11:36:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 20 May 1994 11:36:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 20 May 1994 11:36:45 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9405201043.ZM4373@hughes.network.com> Date: Fri, 20 May 1994 10:43:52 -0500 In-Reply-To: "Donald E. Eastlake 3rd (Beast)" "Re: Re[2]: My current thoughts on IPSEC" (May 20, 8:27am) References: <9405201227.AA08294@skidrow.lkg.dec.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Donald E. Eastlake 3rd (Beast)" , "Housley, Russ" Subject: Re: Re[2]: My current thoughts on IPSEC Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 > I think the simplest answer is not to use the same key for both > directions. This is possible even if a single key negotiation is used. I.e, when the Diffie Hellman "negotiation" is complete, there is at least 512 bilts of common random data at both ends. This is more than enough for 2 symetric keys of almost any algorithm I know of. jim From ipsec-request@ans.net Fri May 20 16:23:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15747 (5.65c/IDA-1.4.4 for ); Fri, 20 May 1994 12:34:27 -0400 Received: by interlock.ans.net id AA23843 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 20 May 1994 12:27:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 20 May 1994 12:27:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 20 May 1994 12:27:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 20 May 1994 12:27:59 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 20 May 1994 12:27:59 -0400 Message-Id: <9405201623.AA06984@snark.imsi.com> To: hughes@hughes.network.com (James P. Hughes) Cc: "Donald E. Eastlake 3rd (Beast)" , "Housley, Russ" , ipsec@ans.net Subject: Re: Re[2]: My current thoughts on IPSEC In-Reply-To: Your message of "Fri, 20 May 1994 10:43:52 CDT." <9405201043.ZM4373@hughes.network.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 20 May 1994 12:23:42 -0400 From: "Perry E. Metzger" James P. Hughes says: > > > I think the simplest answer is not to use the same key for both > > directions. > > This is possible even if a single key negotiation is used. > > I.e, when the Diffie Hellman "negotiation" is complete, there is at least 512 > bilts of common random data at both ends. This is more than enough for 2 > symetric keys of almost any algorithm I know of. In systems such as swIPe, the real headers of the packets are stored in the fully encrypted payload, and in any case all the TCP and similar higher layers know how to deal with duplicated and missing packets since they were built without any guarantees that the IP layer would not do such things. Replaying a packet in the opposite direction won't work, and replaying a packet to a machine won't work. I hope everyone on this group has read the swIPe draft. Perry From ipsec-request@ans.net Fri May 20 16:49:41 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04321 (5.65c/IDA-1.4.4 for ); Fri, 20 May 1994 12:57:05 -0400 Received: by interlock.ans.net id AA08191 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 20 May 1994 12:50:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Fri, 20 May 1994 12:50:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 20 May 1994 12:50:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 20 May 1994 12:50:56 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 20 May 1994 12:50:56 -0400 Message-Id: <9405201649.AA27884@tis.com> To: hughes@hughes.network.com (James P. Hughes) Cc: "Donald E. Eastlake 3rd (Beast)" , "Housley, Russ" , ipsec@ans.net Subject: Re: Re[2]: My current thoughts on IPSEC In-Reply-To: Your message of "Fri, 20 May 94 10:43:52 CDT." <9405201043.ZM4373@hughes.network.com> Date: Fri, 20 May 94 12:49:41 -0400 From: Stephen D Crocker And what rule do you propose for each side to use to choose distinct subsets of the bits? Maybe the side with the larger number in the D-H exchange takes the higher order bits and the other takes the lower order bits? > From: hughes@hughes.network.com (James P. Hughes) > To: "Donald E. Eastlake 3rd (Beast)" , > "Housley, Russ" > cc: ipsec@ans.net > Date: Fri, 20 May 1994 10:43:52 -0500 > Subject: Re: Re[2]: My current thoughts on IPSEC > > > > I think the simplest answer is not to use the same key for both > > directions. > > This is possible even if a single key negotiation is used. > > I.e, when the Diffie Hellman "negotiation" is complete, there is at least 512 > bilts of common random data at both ends. This is more than enough for 2 > symetric keys of almost any algorithm I know of. > > jim > > From ipsec-request@ans.net Fri May 20 17:21:08 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13774 (5.65c/IDA-1.4.4 for ); Fri, 20 May 1994 13:28:28 -0400 Received: by interlock.ans.net id AA09846 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 20 May 1994 13:24:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 20 May 1994 13:24:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 20 May 1994 13:24:10 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 20 May 1994 13:24:10 -0400 Message-Id: <9405201721.AA11783@skidrow.lkg.dec.com> To: Stephen D Crocker Cc: ipsec@ans.net Subject: Re: Re[2]: My current thoughts on IPSEC In-Reply-To: Your message of "Fri, 20 May 94 12:49:41 EDT." <9405201649.AA27884@tis.com> Date: Fri, 20 May 94 13:21:08 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp You are assuming that things are symmetric. In my conception, there is an initiator and a responder so its easy to resolve such questions. Donald From: Stephen D Crocker To: hughes@hughes.network.com (James P. Hughes) Cc: "Donald E. Eastlake 3rd (Beast)" , "Housley, Russ" , ipsec@ans.net In-Reply-To: Your message of "Fri, 20 May 94 10:43:52 CDT." <9405201043.ZM4373@hughes.network.com> >And what rule do you propose for each side to use to choose distinct >subsets of the bits? Maybe the side with the larger number in the D-H >exchange takes the higher order bits and the other takes the lower >order bits? > >> From: hughes@hughes.network.com (James P. Hughes) >> To: "Donald E. Eastlake 3rd (Beast)" , >> "Housley, Russ" >> cc: ipsec@ans.net >> Date: Fri, 20 May 1994 10:43:52 -0500 >> Subject: Re: Re[2]: My current thoughts on IPSEC >> >> >> > I think the simplest answer is not to use the same key for both >> > directions. >> >> This is possible even if a single key negotiation is used. >> >> I.e, when the Diffie Hellman "negotiation" is complete, there is at least 512 >> bilts of common random data at both ends. This is more than enough for 2 >> symetric keys of almost any algorithm I know of. >> >> jim From ipsec-request@ans.net Fri May 20 09:59:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16309 (5.65c/IDA-1.4.4 for ); Fri, 20 May 1994 14:08:41 -0400 Received: by interlock.ans.net id AA19337 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 20 May 1994 14:00:47 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 20 May 1994 14:00:47 -0400 Message-Id: <199405201800.AA15749@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 20 May 1994 14:00:47 -0400 Date: Fri, 20 May 94 13:59:46 EDT From: amir@watson.ibm.com To: ipsec@ans.net Subject: Re: Two keys to differentiate directions Donald, >> I think the simplest answer is not to use the same key for both >> directions. This would work but it is a wasteful solution. A much simpler and more efficient solution is to have a clear direction indicator, this is also simpler to reason about, and is a standard and well known technique. In particular you could use the sender/recipient in the authenticated information (although it is enough, for this purpose, to use only one bit e.g. do I have the lower or higher address). best, Amir Herzberg From ipsec-request@ans.net Sat May 21 03:14:48 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15787 (5.65c/IDA-1.4.4 for ); Mon, 23 May 1994 05:07:11 -0400 Received: by interlock.ans.net id AA13816 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 23 May 1994 04:44:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 23 May 1994 04:44:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 23 May 1994 04:44:55 -0400 Date: Sat, 21 May 1994 03:14:48 +0000 (O) From: ERI Subject: Kerberos & PEM To: ipsec@ans.net Message-Id: <01HCL3YVRE4Y000124@FRCU.EUN.EG> X-Vms-To: IN%"ipsec@ans.net" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Dear sir, Would you please help me by sending the RFCs numbers that handles the following topics: 1- RFCs pertaining to Kerberos 2- RFCs about PEM If there is a new RFC will be issued. How can I know ? I knew that a RFC about firewells will issue within one month. Is it issued or not ? if issued what is the number? Thank you Waleed Hosny ERI@FRCU.EUN.EG 112 Pyramids St. Giza - Egypt 202 3830728 From ipsec-request@ans.net Mon May 23 12:08:14 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05084 (5.65c/IDA-1.4.4 for ); Mon, 23 May 1994 08:22:29 -0400 Received: by interlock.ans.net id AA20245 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 23 May 1994 08:12:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 23 May 1994 08:12:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 23 May 1994 08:12:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 23 May 1994 08:12:03 -0400 Message-Id: <9405231208.AA28809@skidrow.lkg.dec.com> To: ERI Cc: ipsec@ans.net Subject: Re: Kerberos & PEM In-Reply-To: Your message of "Sat, 21 May 94 03:14:48 -0000." <01HCL3YVRE4Y000124@FRCU.EUN.EG> Date: Mon, 23 May 94 08:08:14 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp See below for information on retrieving RFCs. In the same directory as the RFCs themselves is a file called rfc-index.txt that has the numbers and titles for all the rfcs. You can search through this for kerberos or Privacy Enhanced Mail or firewalls or whatever. To get RFC announcements, you should get on the ietf-announce mailing list. Send a request to get on to ietf-announce-request@cnri.reston.va.us. Donald From: ERI To: ipsec@ans.net X-Vms-To: IN%"ipsec@ans.net" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > > > > > >Dear sir, >Would you please help me by sending the RFCs numbers that handles the >following topics: > >1- RFCs pertaining to Kerberos >2- RFCs about PEM > >If there is a new RFC will be issued. How can I know ? >I knew that a RFC about firewells will issue within one month. Is it issued >or not ? if issued what is the number? > >Thank you > >Waleed Hosny >ERI@FRCU.EUN.EG >112 Pyramids St. Giza - Egypt >202 3830728 *------------------------------- REQUEST #1 ---------------------------------* help: ways_to_get_rfcs *------------------------------- RFC-INFO RESPONSE #1 -----------------------* Where and how to get new RFCs ============================= RFCs may be obtained via EMAIL or FTP from many RFC Repositories. The Primary Repositories will have the RFC available when it is first announced, as will many Secondary Repositories. Some Secondary Repositories may take a few days to make available the most recent RFCs. Primary Repositories: RFCs can be obtained via FTP from DS.INTERNIC.NET, FTP.NISC.SRI.COM, NIS.NSF.NET, NISC.JVNC.NET, VENERA.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK, FTP.CONCERT.NET, or FTP.SESQUI.NET. 1. DS.INTERNIC.NET - InterNIC Directory and Database Services RFC's may be obtained from DS.INTERNIC.NET via FTP, WAIS, and electronic mail. Through FTP, RFC's are stored as rfc/rfcnnnn.txt or rfc/rfcnnnn.ps where 'nnnn' is the RFC number. Login as "anonymous" and provide your e-mail address as the password. Through WAIS, you may use either your local WAIS client or telnet to DS.INTERNIC.NET and login as "wais" (no password required) to access a WAIS client. Help information and a tutorial for using WAIS are available online. The WAIS database to search is "rfcs". Directory and Database Services also provides a mail server interface. Send a mail message to mailserv@ds.internic.net and include any of the following commands in the message body: document-by-name rfcnnnn where 'nnnn' is the RFC number The text version is sent. file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. and 'yyy' is 'txt' or 'ps'. help to get information on how to use the mailserver. The InterNIC Directory and Database Services Collection of Resource Listings, Internet Documents such as RFCs, FYIs, STDs, and Internet Drafts, and Publically Accessible Databases are also now available via Gopher. All our collections are waisindexed and can be searched from the Gopher menu. To access the InterNIC Gopher Servers, please connect to "internic.net" port 70. contact: admin@ds.internic.net 2. NIS.NSF.NET To obtain RFCs from NIS.NSF.NET via FTP, login with username "anonymous" and password "guest"; then connect to the directory of RFCs with cd /internet/documents/rfc. The file name is of the form rfcnnnn.txt (where "nnnn" refers to the RFC number). For sites without FTP capability, electronic mail query is available from NIS.NSF.NET. Address the request to NIS-INFO@NIS.NSF.NET and leave the subject field of the message blank. The first text line of the message must be "send rfcnnnn.txt" with nnnn the RFC number. contact: rfc-mgr@merit.edu 3. NISC.JVNC.NET RFCs can also be obtained via FTP from NISC.JVNC.NET, with the pathname rfc/RFCnnnn.TXT.v (where "nnnn" refers to the number of the RFC and "v" refers to the version number of the RFC). JvNCnet also provides a mail service for those sites which cannot use FTP. Address the request to SENDRFC@JVNC.NET and in the subject field of the message indicate the RFC number, as in "Subject: RFCnnnn" where nnnn is the RFC number. Please note that RFCs whose number are less than 1000 need not place a "0". (For example, RFC932 is fine.) No text in the body of the message is needed. contact: Becker@NISC.JVNC.NET 4. VENERA.ISI.EDU RFCs can be obtained via FTP from VENERA.ISI.EDU, with the pathname in-notes/rfcnnnn.txt (where "nnnn" refers to the number of the RFC). Login with FTP username "anonymous" and password "guest". RFCs can also be obtained via electronic mail from VENERA.ISI.EDU by using the RFC-INFO service. Address the request to "rfc-info@isi.edu" with a message body of: Retrieve: RFC Doc-ID: RFCnnnn (Where "nnnn" refers to the number of the RFC (always use 4 digits - the DOC-ID of RFC-822 is "RFC0822")). The RFC-INFO@ISI.EDU server provides other ways of selecting RFCs based on keywords and such; for more information send a message to "rfc-info@isi.edu" with the message body "help: help". contact: RFC-Manager@ISI.EDU 5. WUARCHIVE.WUSTL.EDU RFCs can also be obtained via FTP from WUARCHIVE.WUSTL.EDU, with the pathname info/rfc/rfcnnnn.txt.Z (where "nnnn" refers to the number of the RFC and "Z" indicates that the document is in compressed form). At WUARCHIVE.WUSTL.EDU the RFCs are in an "archive" file system and various archives can be mounted as part of an NFS file system. Please contact Chris Myers (chris@wugate.wustl.edu) if you want to mount this file system in your NFS. contact: chris@wugate.wustl.edu 6. SRC.DOC.IC.AC.UK RFCs can be obtained via FTP from SRC.DOC.IC.AC.UK with the pathname rfc/rfcnnnn.txt.Z or rfc/rfcnnnn.ps.Z (where "nnnn" refers to the number of the RFC). Login with FTP username "anonymous" and password "your-email-address". To obtain the RFC Index, use the pathname rfc/rfc-index.txt.Z. (The trailing .Z indicates that the document is in compressed form.) SRC.DOC.IC.AC.UK also provides an automatic mail service for those sites in the UK which cannot use FTP. Address the request to info-server@doc.ic.ac.uk with a Subject: line of "wanted" and a message body of: request sources topic path rfc/rfcnnnn.txt.Z request end (Where "nnnn" refers to the number of the RFC.) Multiple requests may be included in the same message by giving multiple "topic path" commands on separate lines. To request the RFC Index, the command should read: topic path rfc/rfc-index.txt.Z The archive is also available using NIFTP and the ISO FTAM system. contact: ukuug-soft@doc.ic.ac.uk 7. FTP.CONCERT.NET To obtain RFCs from FTP.CONCERT.NET via FTP, login with username "anonymous" and your internet e-mail address as password. The RFCs can be found in the directory /rfc, with file names of the form: rfcNNNN.txt or rfcNNNN.ps where NNNN refers to the RFC number. This repository is also accessible via WAIS and the Internet Gopher. contact: rfc-mgr@concert.net 8. FTP.SESQUI.NET RFCs can be obtained via FTP from FTP.SESQUI.NET, with the pathname pub/rfc/rfcnnnn.xxx (where "nnnn" refers to the number of the RFC and xxx indicates the document form, txt for ASCII and ps for Postscript). At FTP.SESQUI.NET the RFCs are in an "archive" file system and various archives can be mounted as part of an NFS file system. Please contact RFC-maintainer (rfc-maint@sesqui.net) if you want to mount this file system in your NFS. contact: rfc-maint@sesqui.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Secondary Repositories: Sweden ------ Host: sunic.sunet.se Directory: rfc Host: chalmers.se Directory: rfc Germany ------- Site: University of Dortmund Host: walhalla.informatik.uni-dortmund.de Directory: pub/documentation/rfc Notes: RFCs in compressed format France ------ Site: Institut National de la Recherche en Informatique et Automatique (INRIA) Address: info-server@inria.fr Notes: RFCs are available via email to the above address. Info Server manager is Mireille Yamajako (yamajako@inria.fr). Netherlands ----------- Site: EUnet Host: mcsun.eu.net Directory: rfc Notes: RFCs in compressed format. Finland ------- Site: FUNET Host: funet.fi Directory: rfc Notes: RFCs in compressed format. Also provides email access by sending mail to archive-server@funet.fi. Norway ------ Host: ugle.unit.no Directory: pub/rfc Denmark ------- Site: University of Copenhagen Host: ftp.diku.dk (freja.diku.dk) Directory: rfc Australia and Pacific Rim ------------------------- Site: munnari Contact: Robert Elz Host: munnari.oz.au Directory: rfc rfc's in compressed format rfcNNNN.Z postscript rfc's rfcNNNN.ps.Z United States ------------- Site: cerfnet Contact: help@cerf.net Host: nic.cerf.net Directory: netinfo/rfc Site: NASA NAIC Contact: rfc-updates@naic.nasa.gov Host: naic.nasa.gov Directory: files/rfc Site: NIC.DDN.MIL (DOD users only) Contact: NIC@nic.ddn.mil Host: NIC.DDN.MIL Directory: rfc/rfcnnnn.txt Note: DOD users only may obtain RFC's via FTP from NIC.DDN.MIL. Internet users should NOT use this source due to inadequate connectivity. Site: uunet Contact: James Revell Host: ftp.uu.net Directory: inet/rfc UUNET Archive ------------- UUNET archive, which includes the RFC's, various IETF documents, and other information regarding the internet, is available to the public via anonymous ftp (to ftp.uu.net) and anonymous uucp, and will be available via an anonymous kermit server soon. Get the file /archive/inet/ls-lR.Z for a listing of these documents. Any site in the US running UUCP may call +1 900 GOT SRCS and use the login "uucp". There is no password. The phone company will bill you at $0.50 per minute for the call. The 900 number only works from within the US. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Requests for special distribution of RFCs should be addressed to either the author of the RFC in question, to NIC@INTERNIC.NET. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Requests to be added to or deleted from the RFC distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Changes to this file "rfc-retrieval.txt" should be sent to RFC-MANAGER@ISI.EDU. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ipsec-request@ans.net Mon May 23 09:09:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12283 (5.65c/IDA-1.4.4 for ); Mon, 23 May 1994 13:18:11 -0400 Received: by interlock.ans.net id AA09551 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 23 May 1994 13:10:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 23 May 1994 13:10:52 -0400 Return-Path: shirey@mitre.org Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 23 May 1994 13:10:52 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 23 May 1994 13:10:52 -0400 Date: Mon, 23 May 94 13:09:43 EDT Message-Id: <9405231709.AA18938@smiley.mitre.org.sit> X-Sender: shirey@128.29.140.20 (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ERI , ipsec@ans.net From: shirey@mitre.org (Robert W. Shirey) Subject: Re: Kerberos & PEM Please get your own RFCs. Where and how to get new RFCs ============================= RFCs may be obtained via EMAIL or FTP from many RFC Repositories. The Primary Repositories will have the RFC available when it is first announced, as will many Secondary Repositories. Some Secondary Repositories may take a few days to make available the most recent RFCs. Primary Repositories: RFCs can be obtained via FTP from DS.INTERNIC.NET, NIS.NSF.NET, NISC.JVNC.NET, VENERA.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK, FTP.CONCERT.NET, or FTP.SESQUI.NET. 1. DS.INTERNIC.NET - InterNIC Directory and Database Services RFC's may be obtained from DS.INTERNIC.NET via FTP, WAIS, and electronic mail. Through FTP, RFC's are stored as rfc/rfcnnnn.txt or rfc/rfcnnnn.ps where 'nnnn' is the RFC number. Login as "anonymous" and provide your e-mail address as the password. Through WAIS, you may use either your local WAIS client or telnet to DS.INTERNIC.NET and login as "wais" (no password required) to access a WAIS client. Help information and a tutorial for using WAIS are available online. The WAIS database to search is "rfcs". Directory and Database Services also provides a mail server interface. Send a mail message to mailserv@ds.internic.net and include any of the following commands in the message body: document-by-name rfcnnnn where 'nnnn' is the RFC number The text version is sent. file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. and 'yyy' is 'txt' or 'ps'. help to get information on how to use the mailserver. The InterNIC Directory and Database Services Collection of Resource Listings, Internet Documents such as RFCs, FYIs, STDs, and Internet Drafts, and Publically Accessible Databases are also now available via Gopher. All our collections are waisindexed and can be searched from the Gopher menu. To access the InterNIC Gopher Servers, please connect to "internic.net" port 70. contact: admin@ds.internic.net 2. NIS.NSF.NET To obtain RFCs from NIS.NSF.NET via FTP, login with username "anonymous" and password "guest"; then connect to the directory of RFCs with cd /internet/documents/rfc. The file name is of the form rfcnnnn.txt (where "nnnn" refers to the RFC number). For sites without FTP capability, electronic mail query is available from NIS.NSF.NET. Address the request to NIS-INFO@NIS.NSF.NET and leave the subject field of the message blank. The first text line of the message must be "send rfcnnnn.txt" with nnnn the RFC number. contact: rfc-mgr@merit.edu 3. NISC.JVNC.NET RFCs can also be obtained via FTP from NISC.JVNC.NET, with the pathname rfc/RFCnnnn.TXT.v (where "nnnn" refers to the number of the RFC and "v" refers to the version number of the RFC). JvNCnet also provides a mail service for those sites which cannot use FTP. Address the request to SENDRFC@JVNC.NET and in the subject field of the message indicate the RFC number, as in "Subject: RFCnnnn" where nnnn is the RFC number. Please note that RFCs whose number are less than 1000 need not place a "0". (For example, RFC932 is fine.) No text in the body of the message is needed. contact: Becker@NISC.JVNC.NET 4. VENERA.ISI.EDU RFCs can be obtained via FTP from VENERA.ISI.EDU, with the pathname in-notes/rfcnnnn.txt (where "nnnn" refers to the number of the RFC). Login with FTP username "anonymous" and password "guest". RFCs can also be obtained via electronic mail from VENERA.ISI.EDU by using the RFC-INFO service. Address the request to "rfc-info@isi.edu" with a message body of: Retrieve: RFC Doc-ID: RFCnnnn (Where "nnnn" refers to the number of the RFC (always use 4 digits - the DOC-ID of RFC-822 is "RFC0822")). The RFC-INFO@ISI.EDU server provides other ways of selecting RFCs based on keywords and such; for more information send a message to "rfc-info@isi.edu" with the message body "help: help". contact: RFC-Manager@ISI.EDU 5. WUARCHIVE.WUSTL.EDU RFCs can also be obtained via FTP from WUARCHIVE.WUSTL.EDU, with the pathname info/rfc/rfcnnnn.txt.Z (where "nnnn" refers to the number of the RFC and "Z" indicates that the document is in compressed form). At WUARCHIVE.WUSTL.EDU the RFCs are in an "archive" file system and various archives can be mounted as part of an NFS file system. Please contact Chris Myers (chris@wugate.wustl.edu) if you want to mount this file system in your NFS. contact: chris@wugate.wustl.edu 6. SRC.DOC.IC.AC.UK RFCs can be obtained via FTP from SRC.DOC.IC.AC.UK with the pathname rfc/rfcnnnn.txt.Z or rfc/rfcnnnn.ps.Z (where "nnnn" refers to the number of the RFC). Login with FTP username "anonymous" and password "your-email-address". To obtain the RFC Index, use the pathname rfc/rfc-index.txt.Z. (The trailing .Z indicates that the document is in compressed form.) SRC.DOC.IC.AC.UK also provides an automatic mail service for those sites in the UK which cannot use FTP. Address the request to info-server@doc.ic.ac.uk with a Subject: line of "wanted" and a message body of: request sources topic path rfc/rfcnnnn.txt.Z request end (Where "nnnn" refers to the number of the RFC.) Multiple requests may be included in the same message by giving multiple "topic path" commands on separate lines. To request the RFC Index, the command should read: topic path rfc/rfc-index.txt.Z The archive is also available using NIFTP and the ISO FTAM system. contact: ukuug-soft@doc.ic.ac.uk 7. FTP.CONCERT.NET To obtain RFCs from FTP.CONCERT.NET via FTP, login with username "anonymous" and your internet e-mail address as password. The RFCs can be found in the directory /rfc, with file names of the form: rfcNNNN.txt or rfcNNNN.ps where NNNN refers to the RFC number. This repository is also accessible via WAIS and the Internet Gopher. contact: rfc-mgr@concert.net 8. FTP.SESQUI.NET RFCs can be obtained via FTP from FTP.SESQUI.NET, with the pathname pub/rfc/rfcnnnn.xxx (where "nnnn" refers to the number of the RFC and xxx indicates the document form, txt for ASCII and ps for Postscript). At FTP.SESQUI.NET the RFCs are in an "archive" file system and various archives can be mounted as part of an NFS file system. Please contact RFC-maintainer (rfc-maint@sesqui.net) if you want to mount this file system in your NFS. contact: rfc-maint@sesqui.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Secondary Repositories: Sweden ------ Host: sunic.sunet.se Directory: rfc Host: chalmers.se Directory: rfc Germany ------- Site: EUnet Germany Host: ftp.Germany.EU.net Directory: pub/documents/rfc France ------ Site: Institut National de la Recherche en Informatique et Automatique (INRIA) Address: info-server@inria.fr Notes: RFCs are available via email to the above address. Info Server manager is Mireille Yamajako (yamajako@inria.fr). Netherlands ----------- Site: EUnet Host: mcsun.eu.net Directory: rfc Notes: RFCs in compressed format. Finland ------- Site: FUNET Host: funet.fi Directory: rfc Notes: RFCs in compressed format. Also provides email access by sending mail to archive-server@funet.fi. Norway ------ Host: ugle.unit.no Directory: pub/rfc Denmark ------- Site: University of Copenhagen Host: ftp.denet.dk Directory: rfc Australia and Pacific Rim ------------------------- Site: munnari Contact: Robert Elz Host: munnari.oz.au Directory: rfc rfc's in compressed format rfcNNNN.Z postscript rfc's rfcNNNN.ps.Z United States ------------- Site: cerfnet Contact: help@cerf.net Host: nic.cerf.net Directory: netinfo/rfc Site: NASA NAIC Contact: rfc-updates@naic.nasa.gov Host: naic.nasa.gov Directory: files/rfc Site: NIC.DDN.MIL (DOD users only) Contact: NIC@nic.ddn.mil Host: NIC.DDN.MIL Directory: rfc/rfcnnnn.txt Note: DOD users only may obtain RFC's via FTP from NIC.DDN.MIL. Internet users should NOT use this source due to inadequate connectivity. Site: uunet Contact: James Revell Host: ftp.uu.net Directory: inet/rfc UUNET Archive ------------- UUNET archive, which includes the RFC's, various IETF documents, and other information regarding the internet, is available to the public via anonymous ftp (to ftp.uu.net) and anonymous uucp, and will be available via an anonymous kermit server soon. Get the file /archive/inet/ls-lR.Z for a listing of these documents. Any site in the US running UUCP may call +1 900 GOT SRCS and use the login "uucp". There is no password. The phone company will bill you at $0.50 per minute for the call. The 900 number only works from within the US. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Requests for special distribution of RFCs should be addressed to either the author of the RFC in question, to NIC@INTERNIC.NET. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Requests to be added to or deleted from the RFC distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Changes to this file "rfc-retrieval.txt" should be sent to RFC-MANAGER@ISI.EDU. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ipsec-request@ans.net Mon May 23 09:09:43 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12939 (5.65c/IDA-1.4.4 for ); Mon, 23 May 1994 13:38:57 -0400 Received: by interlock.ans.net id AA23834 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 23 May 1994 13:30:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 23 May 1994 13:30:57 -0400 Return-Path: shirey@mitre.org Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 23 May 1994 13:30:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 23 May 1994 13:30:57 -0400 Date: Mon, 23 May 94 13:09:43 EDT Message-Id: <9405231709.AA18938@smiley.mitre.org.sit> X-Sender: shirey@128.29.140.20 (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ERI , ipsec@ans.net From: shirey@mitre.org (Robert W. Shirey) Subject: Re: Kerberos & PEM Please get your own RFCs. Where and how to get new RFCs ============================= RFCs may be obtained via EMAIL or FTP from many RFC Repositories. The Primary Repositories will have the RFC available when it is first announced, as will many Secondary Repositories. Some Secondary Repositories may take a few days to make available the most recent RFCs. Primary Repositories: RFCs can be obtained via FTP from DS.INTERNIC.NET, NIS.NSF.NET, NISC.JVNC.NET, VENERA.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK, FTP.CONCERT.NET, or FTP.SESQUI.NET. 1. DS.INTERNIC.NET - InterNIC Directory and Database Services RFC's may be obtained from DS.INTERNIC.NET via FTP, WAIS, and electronic mail. Through FTP, RFC's are stored as rfc/rfcnnnn.txt or rfc/rfcnnnn.ps where 'nnnn' is the RFC number. Login as "anonymous" and provide your e-mail address as the password. Through WAIS, you may use either your local WAIS client or telnet to DS.INTERNIC.NET and login as "wais" (no password required) to access a WAIS client. Help information and a tutorial for using WAIS are available online. The WAIS database to search is "rfcs". Directory and Database Services also provides a mail server interface. Send a mail message to mailserv@ds.internic.net and include any of the following commands in the message body: document-by-name rfcnnnn where 'nnnn' is the RFC number The text version is sent. file /ftp/rfc/rfcnnnn.yyy where 'nnnn' is the RFC number. and 'yyy' is 'txt' or 'ps'. help to get information on how to use the mailserver. The InterNIC Directory and Database Services Collection of Resource Listings, Internet Documents such as RFCs, FYIs, STDs, and Internet Drafts, and Publically Accessible Databases are also now available via Gopher. All our collections are waisindexed and can be searched from the Gopher menu. To access the InterNIC Gopher Servers, please connect to "internic.net" port 70. contact: admin@ds.internic.net 2. NIS.NSF.NET To obtain RFCs from NIS.NSF.NET via FTP, login with username "anonymous" and password "guest"; then connect to the directory of RFCs with cd /internet/documents/rfc. The file name is of the form rfcnnnn.txt (where "nnnn" refers to the RFC number). For sites without FTP capability, electronic mail query is available from NIS.NSF.NET. Address the request to NIS-INFO@NIS.NSF.NET and leave the subject field of the message blank. The first text line of the message must be "send rfcnnnn.txt" with nnnn the RFC number. contact: rfc-mgr@merit.edu 3. NISC.JVNC.NET RFCs can also be obtained via FTP from NISC.JVNC.NET, with the pathname rfc/RFCnnnn.TXT.v (where "nnnn" refers to the number of the RFC and "v" refers to the version number of the RFC). JvNCnet also provides a mail service for those sites which cannot use FTP. Address the request to SENDRFC@JVNC.NET and in the subject field of the message indicate the RFC number, as in "Subject: RFCnnnn" where nnnn is the RFC number. Please note that RFCs whose number are less than 1000 need not place a "0". (For example, RFC932 is fine.) No text in the body of the message is needed. contact: Becker@NISC.JVNC.NET 4. VENERA.ISI.EDU RFCs can be obtained via FTP from VENERA.ISI.EDU, with the pathname in-notes/rfcnnnn.txt (where "nnnn" refers to the number of the RFC). Login with FTP username "anonymous" and password "guest". RFCs can also be obtained via electronic mail from VENERA.ISI.EDU by using the RFC-INFO service. Address the request to "rfc-info@isi.edu" with a message body of: Retrieve: RFC Doc-ID: RFCnnnn (Where "nnnn" refers to the number of the RFC (always use 4 digits - the DOC-ID of RFC-822 is "RFC0822")). The RFC-INFO@ISI.EDU server provides other ways of selecting RFCs based on keywords and such; for more information send a message to "rfc-info@isi.edu" with the message body "help: help". contact: RFC-Manager@ISI.EDU 5. WUARCHIVE.WUSTL.EDU RFCs can also be obtained via FTP from WUARCHIVE.WUSTL.EDU, with the pathname info/rfc/rfcnnnn.txt.Z (where "nnnn" refers to the number of the RFC and "Z" indicates that the document is in compressed form). At WUARCHIVE.WUSTL.EDU the RFCs are in an "archive" file system and various archives can be mounted as part of an NFS file system. Please contact Chris Myers (chris@wugate.wustl.edu) if you want to mount this file system in your NFS. contact: chris@wugate.wustl.edu 6. SRC.DOC.IC.AC.UK RFCs can be obtained via FTP from SRC.DOC.IC.AC.UK with the pathname rfc/rfcnnnn.txt.Z or rfc/rfcnnnn.ps.Z (where "nnnn" refers to the number of the RFC). Login with FTP username "anonymous" and password "your-email-address". To obtain the RFC Index, use the pathname rfc/rfc-index.txt.Z. (The trailing .Z indicates that the document is in compressed form.) SRC.DOC.IC.AC.UK also provides an automatic mail service for those sites in the UK which cannot use FTP. Address the request to info-server@doc.ic.ac.uk with a Subject: line of "wanted" and a message body of: request sources topic path rfc/rfcnnnn.txt.Z request end (Where "nnnn" refers to the number of the RFC.) Multiple requests may be included in the same message by giving multiple "topic path" commands on separate lines. To request the RFC Index, the command should read: topic path rfc/rfc-index.txt.Z The archive is also available using NIFTP and the ISO FTAM system. contact: ukuug-soft@doc.ic.ac.uk 7. FTP.CONCERT.NET To obtain RFCs from FTP.CONCERT.NET via FTP, login with username "anonymous" and your internet e-mail address as password. The RFCs can be found in the directory /rfc, with file names of the form: rfcNNNN.txt or rfcNNNN.ps where NNNN refers to the RFC number. This repository is also accessible via WAIS and the Internet Gopher. contact: rfc-mgr@concert.net 8. FTP.SESQUI.NET RFCs can be obtained via FTP from FTP.SESQUI.NET, with the pathname pub/rfc/rfcnnnn.xxx (where "nnnn" refers to the number of the RFC and xxx indicates the document form, txt for ASCII and ps for Postscript). At FTP.SESQUI.NET the RFCs are in an "archive" file system and various archives can be mounted as part of an NFS file system. Please contact RFC-maintainer (rfc-maint@sesqui.net) if you want to mount this file system in your NFS. contact: rfc-maint@sesqui.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Secondary Repositories: Sweden ------ Host: sunic.sunet.se Directory: rfc Host: chalmers.se Directory: rfc Germany ------- Site: EUnet Germany Host: ftp.Germany.EU.net Directory: pub/documents/rfc France ------ Site: Institut National de la Recherche en Informatique et Automatique (INRIA) Address: info-server@inria.fr Notes: RFCs are available via email to the above address. Info Server manager is Mireille Yamajako (yamajako@inria.fr). Netherlands ----------- Site: EUnet Host: mcsun.eu.net Directory: rfc Notes: RFCs in compressed format. Finland ------- Site: FUNET Host: funet.fi Directory: rfc Notes: RFCs in compressed format. Also provides email access by sending mail to archive-server@funet.fi. Norway ------ Host: ugle.unit.no Directory: pub/rfc Denmark ------- Site: University of Copenhagen Host: ftp.denet.dk Directory: rfc Australia and Pacific Rim ------------------------- Site: munnari Contact: Robert Elz Host: munnari.oz.au Directory: rfc rfc's in compressed format rfcNNNN.Z postscript rfc's rfcNNNN.ps.Z United States ------------- Site: cerfnet Contact: help@cerf.net Host: nic.cerf.net Directory: netinfo/rfc Site: NASA NAIC Contact: rfc-updates@naic.nasa.gov Host: naic.nasa.gov Directory: files/rfc Site: NIC.DDN.MIL (DOD users only) Contact: NIC@nic.ddn.mil Host: NIC.DDN.MIL Directory: rfc/rfcnnnn.txt Note: DOD users only may obtain RFC's via FTP from NIC.DDN.MIL. Internet users should NOT use this source due to inadequate connectivity. Site: uunet Contact: James Revell Host: ftp.uu.net Directory: inet/rfc UUNET Archive ------------- UUNET archive, which includes the RFC's, various IETF documents, and other information regarding the internet, is available to the public via anonymous ftp (to ftp.uu.net) and anonymous uucp, and will be available via an anonymous kermit server soon. Get the file /archive/inet/ls-lR.Z for a listing of these documents. Any site in the US running UUCP may call +1 900 GOT SRCS and use the login "uucp". There is no password. The phone company will bill you at $0.50 per minute for the call. The 900 number only works from within the US. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Requests for special distribution of RFCs should be addressed to either the author of the RFC in question, to NIC@INTERNIC.NET. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Requests to be added to or deleted from the RFC distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Changes to this file "rfc-retrieval.txt" should be sent to RFC-MANAGER@ISI.EDU. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ipsec-request@ans.net Wed May 25 17:06:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18444 (5.65c/IDA-1.4.4 for ); Wed, 25 May 1994 17:06:04 -0400 Received: by interlock.ans.net id AA12637 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 25 May 1994 16:51:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 25 May 1994 16:51:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 25 May 1994 16:51:38 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 25 May 1994 16:51:38 -0400 Date: Wed, 25 May 94 13:14:25 From: "Housley, Russ" Encoding: 1230 Text Message-Id: <9404257698.AA769896865@uu0892.spyrus.com> To: hughes@hughes.network.com (James P. Hughes), Stephen D Crocker Cc: dee@skidrow.lkg.dec.com, ipsec@ans.net Subject: Re[4]: My current thoughts on IPSEC In the SDNS Key Managment Protocol, the initiator of the key management exchange is 0 and the responder in 1. Any consistent approach will work. > Subject: Re: Re[2]: My current thoughts on IPSEC >Author: Stephen D Crocker at internet >Date: 5/20/94 12:49 PM > > >And what rule do you propose for each side to use to choose distinct >subsets of the bits? Maybe the side with the larger number in the >D-H exchange takes the higher order bits and the other takes the >lower order bits? > >> From: hughes@hughes.network.com (James P. Hughes) >> To: "Donald E. Eastlake 3rd (Beast)" , >> "Housley, Russ" >> cc: ipsec@ans.net >> Date: Fri, 20 May 1994 10:43:52 -0500 >> Subject: Re: Re[2]: My current thoughts on IPSEC >> >> > I think the simplest answer is not to use the same key for both >> > directions. >> >> This is possible even if a single key negotiation is used. >> >> I.e, when the Diffie Hellman "negotiation" is complete, there is at least 512 >> bilts of common random data at both ends. This is more than enough for 2 >> symetric keys of almost any algorithm I know of. >> >> jim >> From ipsec-request@ans.net Thu May 26 09:41:36 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14298 (5.65c/IDA-1.4.4 for ); Thu, 26 May 1994 14:04:26 -0400 Received: by interlock.ans.net id AA17362 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 26 May 1994 13:41:51 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 26 May 1994 13:41:51 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 26 May 1994 13:41:51 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 26 May 1994 13:41:51 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 26 May 1994 13:41:51 -0400 Date: Thu, 26 May 94 13:41:36 EDT From: perry@imsi.com (Perry E. Metzger) Message-Id: <9405261741.AA13159@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 26 May 1994 13:41:51 -0400 To: ipsec@ans.net Subject: it just occured to me... Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission I just realized that the swIPe Internet Draft hasn't been released yet to the internet drafts directories thanks to an oversight by its authors. I thought I ought to post it for those who haven't seen it. The file and a postscript version of a talk on swIPe are also available in ftp://research.att.com/dist/mab By the way, I am told that a swIPe implementation for Berkeley descended systems, complete with very crude key management, is going to be released to the public within a week or two. ---------------------------------------------------------------------- The swIPe IP Security Protocol John Ioannidis INTERNET DRAFT (Columbia University) Expires June 3, 1994 Matt Blaze (AT&T Bell Labs) December 3rd, 1993 The swIPe IP Security Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id- abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This document describes swIPe, a network-layer security protocol for the IP protocol suite. swIPe provides confidentiality, integrity, and authentication of network traffic, and can be used to provide both end-to-end and intermediate-hop security. swIPe is concerned only with security mechanisms; policy and key management are handled outside the protocol. 1. Introduction Security of network resources has been viewed traditionally as a trade-off between security and convenience. The lack of a network-layer security protocol suitable for use in large, administratively heterogeneous internetworks, has given rise to ad hoc security efforts, such as mailbridges, filtering routers, firewalls, application-level gateways, etc. The fundamental problem with these efforts is that, in enforcing security, they cripple the connectivity that makes internetworking attractive in the first place. Ioannidis & Blaze [Page 1] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 In order that the Internet continue to grow in size and features, its users must be confident that it is safe to connect without hiding behind impenetrable draconian barriers. The existing internetworking protocols, including IP, are deficient in three areas: * Lack of source authentication. * Lack of data integrity. * Lack of data confidentiality. The lack of these features in the network requires relying on higher-layer protocol features (e.g., TCP port numbers), or lower-layer features (e.g., which network interface a packet arrived from) to perform security functions (such as access control). In most cases, `firewalls' simply create an impenetrable barrier, thus making it cumbersome, or even impossible, for users inside the firewall to take advantage of network services in the global Internet. Network security being critically important to the continued growth of the Internet, it is necessary to solve these problems while maintaining connectivity. Cryptographic protection of network traffic can solve all three problems. However, we still lack full understanding of the problems of heterogeneous security policies and of cryptographic key management in large scale networks. Therefore, it is important to separate policy considerations and key management from the actual mechanisms in any security protocol. swIPe is a network-layer security protocol that provides the mechanisms to solve the three problems listed above. It works by augmenting each packet with a cryptographically-strong authenticator and/or encrypting the data to be sent. swIPe is simple to define, implement and use in existing and future networks and operating systems. It provides all the necessary security mechanisms and is easy to interface to loosely coupled policy and key management facilities that are outside the swIPe protocol itself. In addition, is tied to any specialized underlying protocol features or cryptographic algorithms, and can therefore be readily adapted to new protocols and new crypto systems. Because swIPe operates at the network layer, it can be used to implement a variety of security configurations. It can operate at the same granularity level as the network and therefore can provide security between any entities identified at the network layer (e.g., host-to-host security, host-to-network, individual links, etc.). Depending on the capabilities of the host environment, finer Ioannidis & Blaze [Page 2] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 granularity is possible as well, such as security between individual processes running on different hosts. The precise security configuration of a network (which links, hosts, connections between processes in hosts, etc. are protected) depends on the policy configuration of each network entity. That is, a host may determine which outgoing packets are protected, a router may determine which packets to pass or reject, and so on. For example, a trusted internal network need not run swIPe at all, but may still securely connect to external networks by running swIPe on its routers. It is important to note that the existence of a security protocol is not sufficient; host and site security policies must be chosen judiciously, and often in combination with higher-level security mechanisms to yield the desired effects. As an example, providing a secure link between a workstation and its file server does not protect file data once they are on the server itself. Similarly, trusting the identity of a particular host is not the same as trusting the integrity of the data and services provided by that host. Although it was designed to be readily adaptable to any connectionless network protocol, swIPe as described in this document is specific to IP. 2. Protocol Description swIPe works by encapsulating each IP datagram to be secured inside a swIPe packet. A swIPe packet is an IP packet of protocol type IPPROTO_SWIPE (temporarily, protocol 94, or IPPROTO_IPIP, is being used). A swIPe packet starts with a header, which contains identifying data and authentication information; the header is followed by the original IP datagram, which in turn is followed by any padding required by the security processing. Depending on the negotiated policy, the sensitive part of the swIPe packet (the authentication information and the original IP datagram) may be encrypted. In this document, we refer to the original IP datagram as the `inner packet', and the entire swIPe datagram as the `outer' packet. The components of a swIPe packet are shown in the following diagram. +-----+-----------+-----+----------------------+---------+ |IPhdr| swIPe hdr |IPhdr| payload | padding | +-----+-----------+-----+----------------------+---------+ ^_______ inner packet _______^ ^__________________ outer (swIPe) packet ________________^ Ioannidis & Blaze [Page 3] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 The inner IP header and the payload are transferred intact with respect to the swIPe endpoints. That is, the Time To Live field, original source and destination addresses, and other such fields in the inner IP header are not modified. It may be desirable (in a future version of the protocol) to `compress' the inner IP header, that is, replace it with enough information to reconstruct it from the outer header. This `compression', however, must be invisible at the swIPe endpoints. The format of a swIPe packet 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 .- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s H | Packet type | Header length | Policy identifier | w e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I a | Packet sequence number | P d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e e / / r \ Authenticator (optional, variable length) \ `- / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ \ / Original (inner) packet / \ \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ Padding (optional) \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the swIPe header are: Packet type (8 bits) 0 Plain encapsulation; Header length should be 1 and the Policy identifier should be 1. 1 Packet is authenticated but not encrypted. 2 Packet is encrypted; the encryption algorithm may provide some authentication (e.g., DES CBC residue). 3 Packet is both authenticated and encrypted 4-15 Unused. Ioannidis & Blaze [Page 4] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 16-63 Control packet. Reserved, undefined by the protocol, interpreted by policy and key management engines. 64-255 Reserved; must never be used. Header length (8 bits) The length of the swIPe header in 32-bit words. The minimum value is 1. Policy Identifier (16 bits) A token, negotiated at key- or policy-setup time, used by the recipient of the packet to choose the proper policy. Similar to a SAID. Packet sequence number (32 bits) This field protects against replay attacks and may also be used for synchronization by a stream cipher. It is unique within the context of an endpoint pair (common source/destination address and Policy identifier). It is incremented by one with every packet sent, and initialized whenever the hosts re-negotiate keys and/or policies. The hosts MUST renegotiate crypto variables before the packet sequence number wraps around. A host MUST NOT accept duplicate packets; this may be achieved by only accepting packets which increment the sequence number, or maintaining a small window of acceptable packet numbers. Authentication data (variable length, multiple of 32 bits) An authenticator, computed over the entire swIPe packet (minus the outer IP header), but before any confidentiality processing is performed. When the authenticator is computed, the authentication data field is zeroed. Encapsulated packet (variable length) The actual packet being secured. Padding (variable length) Some security algorithms (such as DES) require padding to bring the length of the data to an integral multiple of the block size. The padding is added after the authentication data have been computed. A swIPe system consists of three conceptual entities; the protocol engine, the key management engine, and the policy engine. The swIPe protocol described in this document comprises the protocol engine. We describe the swIPe processing without specifying the precise semantics of either the policy or key management engines, since these Ioannidis & Blaze [Page 5] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 are not part of the protocol itself. It is useful, however, to consider the interaction between protocol and key management and policy in terms of a simple upcall interface: whenever the swIPe processing engine needs to determine which keys and what policy to use in processing a datagram, it calls the appropriate processing engine. Needless to say, an implementation may optimize the actual mechanisms or blur the boundaries between protocol processing and policy. The policy engine is responsible for determining the precise kind of processing required of outgoing datagrams, and acceptance policy for incoming datagrams. The key management engine establishes the cryptographic variables used by the protocol. Both the policy and the key management engines may also communicate with their respective peers on remote endpoints for negotiation of policy and keys, as required. Outgoing datagrams are processed by swIPe as follows: based on information from the inner packet itself (IP source and destination address, IP protocol, other transport-layer parameters), as well as information from local system control structures such as protocol control blocks, a decision is made whether to send the packet and, if so, whether to apply swIPe processing to it. If swIPe processing is required, the authentication and encryption algorithms, the keys to use, and the destination of the outer packet are determined by consulting the policy and key management engines. Once the parameters have been determined, the swIPe packet is constructed. The swIPe header is prepended to the (inner) IP datagram. The sequence number is copied into the packet and incremented. If authentication is to be performed, the authenticator field (of the appropriate length) is zeroed, and the authentication algorithm is applied to the authentication information part of the header (i.e., the swIPe header minus the first 32 bits) and the original IP datagram. The checksum resulting from the application of the authentication algorithm is copied into the authenticator field. If authentication is not performed, then the authenticator field is not present. Next, if encryption is (also) specified, the appropriate algorithm and crypto variable are selected and applied to the same parts of the datagram as the authentication. The algorithm may require padding, which is appended to the packet after encryption has been performed. The resulting datagram is then transmitted to its destination (which may not be the same as that of inner packet). Input processing proceeds in roughly the opposite fashion. swIPe datagrams that arrive are decrypted and authenticated based on information contained in their swIPe header. Namely, the source, destination, and Policy Identifier of the outher packet are examined and the crypto variables and algorithms used to decrypt, verify, and Ioannidis & Blaze [Page 6] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 reconstruct the original packet. The resulting datagrams, plus any non-swIPe datagrams that arrive directly are checked against the local policy configuration to determine whether they should be accepted or not. Accepted packets are processed in the ordinary manner (delivered to the corresponding higher-layer protocol if they were destined for the receiving host, or further routed if not). 3. Discussion The security provided by swIPe depends upon the strength of the underlying cryptographic algorithms, the security of secret key information, and the characteristics of the protocol itself. Since swIPe can be used with a wide range of crypto systems, we focus on the impact of the protocol features on the resulting security. Source authenticity of the inner packet is protected by including the entire inner packet (and hence its source and destination IP addresses) in the computation of the authenticator. The implicit assumption is that the authentication function is a cryptographically strong one-way authenticator (such as key-seeded MD5), and that only the legitimate hosts have access to the authentication key. Similarly, data integrity is protected by the same checksum mechanism; replays are thwarted by the presence of the sequence number field. An adversary not possessing the authentication key cannot generate the authenticator for fraudulent packets; furthermore, since only packets that increase the sequence number are accepted (or packets within the acceptable window), replay attacks are not feasible either. Data confidentiality is provided by encrypting the entire swIPe packet. Confidentiality is not limited to the actual data being transmitted in the inner packet, but also extends to the source and destination addreses, protocol characteristics (such as TCP port number), and so on. Note that since the addresses of the inner packet are not necessarily the same as those of the outer packet, it is not possible for an adversary to determine the actual endpoints of communication without resorting to global traffic analysis. There are many ways to configure systems running swIPe, and many types of security policies that can be implemented with it. For a discussion of applications of swIPe and its implementation under Unix, the reader is referred to "The Architecture and Implementation of Network-Layer Security Under Unix", by John Ioannidis and Matt Blaze, which appeared in the proceedings of the 4th USENIX Security Symposium, Santa Clara, CA, October 1993. Ioannidis & Blaze [Page 7] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 Authors' Addresses John Ioannidis Computer Science Department Columbia University 500 W. 120th Street New York, NY 10027 ji@cs.columbia.edu +1.212.939.7000 Matt Blaze AT&T Bell Laboratories 101 Crawfords Corner Road Holmdel, New Jersey 07733 mab@research.att.com +1.908.949.8069