From ipsec-request@ans.net Sat Apr 1 00:56:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28293 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 20:02:58 -0500 Received: by interlock.ans.net id AA28377 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 19:57:14 -0500 Message-Id: <199504010057.AA28377@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 19:57:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 19:57:14 -0500 From: Brad Wilson Subject: Re: Mission-Critical To: Bill.Simpson@um.cc.umich.edu (William Allen Simpson) Date: Fri, 31 Mar 1995 19:56:59 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <199503312324.AA32903@interlock.ans.net> from "William Allen Simpson" at Mar 31, 95 10:41:02 pm X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 521 These words were uttered by William Allen Simpson ... : And isn't that the same DoD which funded the developement of IP? Are : you saying they don't actually use it? Perhaps this government official was confusing Internet with internet (note capitalization, the distinction made by Comer and others). -- Brad Wilson Internet: wilson@cps.cmich.edu Voice: +1 810 625-2473 Sr. Software Engineer Crucial Software Data: +1 810 620-9803 "Don't believe everything you hear or anything you say" From ipsec-request@ans.net Fri Mar 31 15:13:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28412 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 20:19:36 -0500 Received: by interlock.ans.net id AA18045 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 20:13:34 -0500 Message-Id: <199504010113.AA18045@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 20:13:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 20:13:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 20:13:34 -0500 Date: Fri, 31 Mar 1995 20:13:28 +0500 From: Theodore Ts'o To: Danny.Nessett@eng.sun.com Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net, jis@MIT.EDU In-Reply-To: Dan Nessett's message of Fri, 31 Mar 1995 15:26:35 -0800, <199503312326.PAA04369@elrond.Eng.Sun.COM> Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 2824 Date: Fri, 31 Mar 1995 15:26:35 -0800 From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) X-Sun-Charset: US-ASCII P.S. Ted says this is easy, so perhaps he can consider this as a challenge :-). OK, here's a back of the envelope design, completely off the cuff. I'm sure there will be some issues which will need some more thought, but it's a beginning. I'll assume a BSD Socket's style interface, as it's what I'm most familiar with. o How will the SPI and security context information be passed from both connecting and accepting processes to the IP implementation? There are two cases. The first if you need to set need to set the security context information to be used for a new TCP connection, or for UDP packets. In this case, you simply use a new ioctl or setsocketopt to set new security context information, which will override the host-specified default. This would be done before the accept() or listen() call. The structure that would be passed to the socket might look something like this: struct seccon_info { uint32 SPI; int transform; /* Security transform, indexed by integer */ int len; /* Length of security transform specific data */ char data[]; /* Security transform specific data */ }; This structure intentially looks much like a "struct sockaddr"; for a specific security transform, there might a more specific structure which replaces the data field with some substrcture, much like "struct sockaddr_in". The second case is if you want to change the security context used with an existing TCP connection. This is much harder, because of the syncronization issues. The way I'd suggest handling this is to add the new security context information (using the above structure). At this point, the implementation will accept packets with either the old or the new SPI (although it will only send packets using the old SPI). The application will is responsible for confirming that the new security context is established at both sides. Once this has happened, the application uses another ioctl or setsockopt to revoke the old security context. o How might this information be derived from the key management protocol? Any choice here can be used, Photuris, Kerberos, etc. The key is derived from the key management protocol; the only other information that is needed is for the kernel to allocate a unique SPI. This can be done by having the kernel allocate and fill in the SPI field of the structure, and the application would then pass the SPI to the other side, which would specify it in the structure. Anyway, that's the basic idea --- there are obviously a lot of details that needs to be fleshed out. But you just wanted a proof concept that it was in fact possible; hopefully this is what you were looking for. - Ted From ipsec-request@ans.net Sat Apr 1 02:06:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14661 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 21:12:36 -0500 Received: by interlock.ans.net id AA22333 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 21:06:51 -0500 Message-Id: <199504010206.AA22333@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 31 Mar 1995 21:06:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 31 Mar 1995 21:06:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 21:06:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 21:06:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 21:06:51 -0500 Date: Fri, 31 Mar 1995 18:06:00 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: tytso@MIT.EDU Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net, jis@MIT.EDU X-Sun-Charset: US-ASCII Ted, Your message : > OK, here's a back of the envelope design, completely off the cuff. ... > But you just wanted a proof concept that > it was in fact possible; hopefully this is what you were looking for. didn't really provide enough information. For example : o You only covered two of the four issues, o You didn't specify how the information about keying material, algorithms, etc. are extracted from the key distribution opaque data and transformed into a form acceptible to the IP implementation. I think I was looking for something a bit more than a back of the envelope discusion and a bit less than an internet draft. I don't care what the data structures look like, only how the information is processed. However, I think you have no obligation at this point to proceed, based on an off-the-cuff remark you made in an email message. On the other hand, someone should have thought the problem through sufficiently so that implementors are convinced it can be done. It is precisely because I don't think anyone has done this yet that I am concerned that per-user keying is a mandatory requirment. Dan From ipsec-request@ans.net Fri Mar 31 16:58:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15952 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 22:04:34 -0500 Received: by interlock.ans.net id AA26253 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 21:58:53 -0500 Message-Id: <199504010258.AA26253@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 21:58:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 21:58:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 21:58:53 -0500 Date: Fri, 31 Mar 1995 21:58:47 +0500 From: Theodore Ts'o To: Danny.Nessett@eng.sun.com Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net, jis@MIT.EDU In-Reply-To: Dan Nessett's message of Fri, 31 Mar 1995 18:06:00 -0800, <199504010206.SAA04523@elrond.Eng.Sun.COM> Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1485 Date: Fri, 31 Mar 1995 18:06:00 -0800 From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) X-Sun-Charset: US-ASCII o You only covered two of the four issues, The others I thought were obvious from the discussion of the first two. I specifically covered some of what was necessary to handle an incoming packet in the previous sections. o You didn't specify how the information about keying material, algorithms, etc. are extracted from the key distribution opaque data and transformed into a form acceptible to the IP implementation. Again, I thought that was so obvious that it didn't need much explanation. In the case of Kerberos, you get a DES session key out of the authentication. That's what you use. If you want to make a subsession key, to avoid the problems of reuseing the session key across multiple connections, that's fine. Just don't make the mistake the Kerberos V4 telnet encryption specification made of ignoring key parity when you generate the subsession key. In the case of GSSAPI, there is no way through the GSSAPI to get at the keying of the security association. But once you have a security association up, one side can generate a random key, and send across to the other using gss_seal. This all can be done. It is not rocket science. If you think it is hard, then say why you think it's hard, instead of complaining that I've walked through every little tiny detail, as if this were an intro C.S. class. - Ted From ipsec-request@ans.net Sat Apr 1 14:31:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21426 (5.65c/IDA-1.4.4 for ); Sat, 1 Apr 1995 09:44:04 -0500 Received: by interlock.ans.net id AA39169 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 1 Apr 1995 09:34:14 -0500 Message-Id: <199504011434.AA39169@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 1 Apr 1995 09:34:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 1 Apr 1995 09:34:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 1 Apr 1995 09:34:14 -0500 To: Theodore Ts'o Cc: bound@zk3.dec.com, perry@imsi.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Fri, 31 Mar 95 17:29:07 +0500." <9503312229.AA28718@dcl.MIT.EDU> Date: Sat, 01 Apr 95 09:31:39 -0500 From: bound@zk3.dec.com X-Mts: smtp Ted, >You seem to be the only one argueing for making DES optional.... Yes I am the only vocal one. I assure you if this is not changed I will not be only objection in a last call. Am I championing this change. Yes. If I am the only individual who works for a vendor who takes issue with this I will be surprised. If I loose this debate at the IESG level then at least its recorded and I did my best to correct what I believe is a major mistake for the industry. But we have a lot to do with key mgmt and tightning up the specs and I will not discuss this anymore on the mail list OK. I think my position is clear, whether I am the only one or not is irrelevant. Community consensus should not be the activity of the most active mail participants and I believe fortuneately that is not the case. /jim From ipsec-request@ans.net Sat Apr 1 14:56:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21306 (5.65c/IDA-1.4.4 for ); Sat, 1 Apr 1995 10:05:59 -0500 Received: by interlock.ans.net id AA16877 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 1 Apr 1995 09:58:34 -0500 Message-Id: <199504011458.AA16877@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 1 Apr 1995 09:58:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 1 Apr 1995 09:58:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 1 Apr 1995 09:58:34 -0500 To: Theodore Ts'o Cc: Danny.Nessett@eng.sun.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net, jis@MIT.EDU Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) In-Reply-To: Your message of "Fri, 31 Mar 95 20:13:28 +0500." <199504010113.AA18045@interlock.ans.net> Date: Sat, 01 Apr 95 09:56:15 -0500 From: bound@zk3.dec.com X-Mts: smtp o How will the SPI and security context information be passed from both connecting and accepting processes to the IP implementation? >There are two cases. The first if you need to set need to set the >security context information to be used for a new TCP connection, or for >UDP packets. In this case, you simply use a new ioctl or setsocketopt >to set new security context information, which will override the >host-specified default. This would be done before the accept() or >listen() call. The structure that would be passed to the socket might >look something like this: We also must make sure that if the default is to not use security per the user but does want to now use if for a specific application that it is possible without altering the default to not use security by this user. There is also the case that the sender has provided security to a listen or accept and the user has decided to not use security for that application. In this case the default is use security but an application has decided to not use security. This also involves rejection or acceptance of the IPSP payload at the internetwork layer too, which brings us to policy and the various combinantions of MAY or MAY NOT USE security in an implementation. >The second case is if you want to change the security context used with >an existing TCP connection. This is much harder, because of the >syncronization issues. The way I'd suggest handling this is to add the >new security context information (using the above structure). At this >point, the implementation will accept packets with either the old or the >new SPI (although it will only send packets using the old SPI). The >application will is responsible for confirming that the new security >context is established at both sides. Once this has happened, the >application uses another ioctl or setsockopt to revoke the old security >context. I am not clear on what you "define" as the context to be changed above? So I will wait to respond. o How might this information be derived from the key management protocol? Any choice here can be used, Photuris, Kerberos, etc. >The key is derived from the key management protocol; the only other >information that is needed is for the kernel to allocate a unique SPI. >This can be done by having the kernel allocate and fill in the SPI field >of the structure, and the application would then pass the SPI to the >other side, which would specify it in the structure. Why do you believe this needs to be done in the kernel? It costs to cross that kernel boundary. >Anyway, that's the basic idea --- there are obviously a lot of details >that needs to be fleshed out. But you just wanted a proof concept that >it was in fact possible; hopefully this is what you were looking for. I think we need a bit more than this but it starts the discussion. thanks /jim From ipsec-request@ans.net Sun Apr 2 21:10:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20715 (5.65c/IDA-1.4.4 for ); Sun, 2 Apr 1995 21:10:50 -0400 Received: by interlock.ans.net id AA02200 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 2 Apr 1995 21:01:03 -0400 Message-Id: <199504030101.AA02200@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 2 Apr 1995 21:01:03 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 2 Apr 1995 21:01:03 -0400 From: Masataka Ohta Subject: Re: key-ed MD5 again To: ho@cs.arizona.edu (Hilarie Orman) Date: Mon, 3 Apr 95 9:59:13 JST Cc: IPSEC@ans.net In-Reply-To: <199503300238.AA13855@interlock.ans.net>; from "Hilarie Orman" at Mar 29, 95 7:38 pm X-Mailer: ELM [version 2.3 PL11] > It's easy to check that F(N) does approach 0 for large N, but extremely > slowly. In fact, > > F(N) ~= 2 / (N + log terms). > > In the case at hand, suppose the VeryLongText above is 1 MB. This is > 15,625 blocks of 64bytes; if we feed those to MD5 one block at a time, > the expected size of the range is diminished by a factor of 15625/2, > or about 8000. In other words, we've lost 13 bits of the original 128 > bits in the initial state of MD5. If VeryLongText is 1 GB, the same > calculation shows we'll lose 23 bits. It should also be noted that calculation of MD5 of long messages take a longer time, even if the differences between messages lies only in the initial 64bytes. So, to explore the accidental match in 120bit MD5 space of 1MB message takes 15,625/(sqrt(8,000)) more times than exploring the 128 bit space for 64bit message. That is, the initial part of longer messages is safer than that of short messages, I think. Is it well known, or do I misunderstand something? Masataka Ohta From ipsec-request@ans.net Mon Apr 3 01:53:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17680 (5.65c/IDA-1.4.4 for ); Sun, 2 Apr 1995 21:59:30 -0400 Received: by interlock.ans.net id AA05064 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 2 Apr 1995 21:55:19 -0400 Message-Id: <199504030155.AA05064@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 2 Apr 1995 21:55:19 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 2 Apr 1995 21:55:19 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 2 Apr 1995 21:55:19 -0400 X-Sender: hinden@servo.ipsilon.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 2 Apr 1995 17:53:31 -0800 To: ipng@sunroof.eng.sun.com From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) new Photuris draft available for ftp Cc: ipsec@ans.net Robert, At 6:42 AM 3/31/95, Robert Elz wrote: >Drafts that don't make it to the I-D directories before the IETF >should (must) be totally out of bounds for discussions in the WG >meetings, they're for next time. While I would agree that we should all try to get our drafts out as early as possible, I would leave it up to the working group chair(s) to decide if a particular draft should be discussed at a working group session. Sometimes, a new draft is an incremental update to a previous one. Other times a late draft might be very important for what a working group is doing. Having a blanket bureaucratic rule is probably not the best approach. Bob From ipsec-request@ans.net Sun Apr 2 19:14:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14798 (5.65c/IDA-1.4.4 for ); Mon, 3 Apr 1995 00:20:26 -0400 Received: by interlock.ans.net id AA02911 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Apr 1995 00:14:12 -0400 Message-Id: <199504030414.AA02911@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 3 Apr 1995 00:14:12 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Apr 1995 00:14:12 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Apr 1995 00:14:12 -0400 Date: Mon, 3 Apr 1995 00:14:01 +0500 From: Theodore Ts'o To: bound@zk3.dec.com Cc: Theodore Ts'o , Danny.Nessett@eng.sun.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net, jis@MIT.EDU In-Reply-To: bound@zk3.dec.com's message of Sat, 01 Apr 95 09:56:15 -0500, <9504011456.AA17797@xirtlu.zk3.dec.com> Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1518 Date: Sat, 01 Apr 95 09:56:15 -0500 From: bound@zk3.dec.com We also must make sure that if the default is to not use security per the user but does want to now use if for a specific application that it is possible without altering the default to not use security by this user. This is an application issue. My assumption here is that the application will do its own negotiations to the determine what authentication/key management scheme (X.509, Kerberos, GSSAPI), etc. to obtain a user-level authentication and an a session key. How this happense precisely is a application issue and thus out of scope of IPSEC. But once the application has negotiated a key, we simply need a way to allocate an SPI and set that key into the kernels, on both ends of the connection. I am not clear on what you "define" as the context to be changed above? So I will wait to respond. Well, things are simple if all you need to do is to specify a particular SPI (and associated security association information) with a TCP connection when that TCP connection is created. You just simply need to set an appropriate socket option before the accept() and listen() calls. Things are a bit more difficult if you want to change the SPI which should be used with a TCP connection after the TCP connection is already established. That was the second case which I was talking about. The "context" I was talking about is the SPI and the associated encryption information associated with that SPI. - Ted From ipsec-request@ans.net Mon Apr 3 11:51:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24922 (5.65c/IDA-1.4.4 for ); Mon, 3 Apr 1995 07:56:19 -0400 Received: by interlock.ans.net id AA09911 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Apr 1995 07:53:19 -0400 Message-Id: <199504031153.AA09911@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Apr 1995 07:53:19 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Apr 1995 07:53:19 -0400 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) new Photuris draft available for ftp In-Reply-To: Your message of "Sun, 02 Apr 1995 17:53:31 PST." Date: Mon, 03 Apr 1995 21:51:25 +1000 From: Robert Elz Date: Sun, 2 Apr 1995 17:53:31 -0800 From: hinden@ipsilon.com (Bob Hinden) Message-ID: Having a blanket bureaucratic rule is probably not the best approach. I agree with that largely. But I'm afraid that if you do away with a bureaucratic rule that way, you also need to do away with the rule that expects people to have read the drafts before attending the meetings (and expecting to contribute). That means read any drafts - personally I don't have time to read everything as its published, I try to catch up on the latest drafts just before the IETF's so I have an idea what most are about. But if I'm not sure they're going to be the latest, as somethig new is going to appear (or might appear) the day before the IETF, then I'm not going to read any of them probably. Too much risk of wasting time. kre From ipsec-request@ans.net Mon Apr 3 12:59:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27399 (5.65c/IDA-1.4.4 for ); Mon, 3 Apr 1995 09:30:46 -0400 Received: by interlock.ans.net id AA12544 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Apr 1995 09:25:54 -0400 Message-Id: <199504031325.AA12544@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 3 Apr 1995 09:25:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 3 Apr 1995 09:25:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 3 Apr 1995 09:25:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Apr 1995 09:25:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Apr 1995 09:25:54 -0400 X-Mailer: exmh version 1.5.3 12/28/94 To: bound@zk3.dec.com Cc: Theodore Ts'o , perry@imsi.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Sat, 01 Apr 1995 09:31:39 EST." <199504011434.AA39169@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 03 Apr 1995 08:59:26 -0400 From: " " > Ted, > > >You seem to be the only one argueing for making DES optional.... > > Yes I am the only vocal one. Well, I have to add my voice too. We need a standard which would allow us to have an exportable product which would be standard complying. I hate the export restrictions and I think they should be removed, but I don't think the IETF standrads should just ignore them and `punish' us further for living under them. It is demaging enough to US firms that we'll have to offer the weaker-security version... Don't harm us further by trying to exclude such implementations from standard. A compromise: the standard could allow for an `authentication only' implementation. In this way we would not mislead anybody to trust weak encryption. Auth only is a valueable protocol. Best, Amir p.s. I suspect Jim is right and there are many who share this position - i.e. we need exportable version but hate to admit it since it's so crazy... From ipsec-request@ans.net Mon Apr 3 15:32:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24990 (5.65c/IDA-1.4.4 for ); Mon, 3 Apr 1995 11:36:56 -0400 Received: by interlock.ans.net id AA36915 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Apr 1995 11:30:54 -0400 Message-Id: <199504031530.AA36915@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 3 Apr 1995 11:30:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 3 Apr 1995 11:30:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Apr 1995 11:30:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Apr 1995 11:30:54 -0400 From: "Marcus J. Ranum" Subject: Re: IPv6 Security Last Call Initial Questions To: amir@watson.ibm.com Date: Mon, 3 Apr 1995 11:32:56 -0400 (EDT) Cc: bound@zk3.dec.com, tytso@MIT.EDU, perry@imsi.com, ipsec@ans.net In-Reply-To: <199504031325.AA12544@interlock.ans.net> from "ipsec-request@ans.net" at Apr 3, 95 08:59:26 am Organization: Trusted Information Systems, Inc. Glenwood, MD Phone: 301-854-6889 Coredump: Infocalypse Now!!! Content-Type: text Content-Length: 4499 >I suspect Jim is right and there are many who share this position - i.e. >we need exportable version but hate to admit it since it's so crazy... It's my belief that if the working group wants to attempt to standardize on something exportable, you may as well pack up right now. This is based on a combination of practical and paranoid concerns that normally I'd be reluctant to discuss for fear of seeming like a whacko. :) But export control is an issue that doth make whackos of us all, it would appear. 1) Exportable crypto is breakable crypto. That is in the definition of the term "exportable" under the way NSA is currently managing the situation. 2) Exportable crypto is not a "make them all happy" situation and is US-centric. Other governments may well feel that ANY crypto is not exportable, or even useable. Even if the NSA is satisfied, do the vendors propose to also satisfy the French, and the Chinese, and Pakistan, and other governments that have very restrictive laws pertaining to crypto? If the feeling of the vendors, as expressed by Jim Bound from Digital is that the vendors must make governments happy and have products that will make governments happy, their only reasonable recourse is to leave crypto out of their products. 3) Standards fragementation: IP encryption based on exportable encryption will result in a standard that very quickly becomes de facto ignored and which will become at least DES-based or possibly IDEA or something that will *really* PO the intelligence community. I suspect that the response to this risk will be that they will request onerous restrictions and proofs that the algorithm is tied to the implementation, as a condition for export. Remember that export control covers not only algorithms but complete systems. The vendors will find themselves in the situation of having to not only implement weak products, but they'll have to jump through hoops to prove to law enforcement and intelligence that their product cannot POSSIBLY be modified to include strong encryption. Good luck doing that. The net effect is that a standard incorporating only exportable crypto will be quickly shafted. The intelligence community will know this [The PGP experience is one they still remember] and will be disinclined to approve anything at all. 4) If you can't lick, 'em, delay them. This is where I get paranoid. :) When you want deploy crypto, even exportable toy crypto, there are a number of hoops you have to jump through. I'm not sure that it's possible to get blanket permission to include any given algorithm in a broad class of products. The question hidden in this is whether or not the sheer bureaucracy of getting permission to use even exportable crypto will continue to exert a cooling effect on the technology. It gets worse for a vendor that has a vested interest (i.e.: an implementation they want to sell) in getting approval for a given exportable algorithm. Once you have built it into your product and you've bought into the system, you're now subject to whatever infinite foot-dragging and justification can be thought up. In my somewhat paranoid thinking, exportable crypto is a subtle poison that ensures vendor buy-in. It's ridiculous, really -- it is *FAR* cheaper to simply buy good encryption products from overseas, than to play the exportable crypto game. It is my paranoid belief that NSA is making more open noises about exportable crypto as a way of luring the cattle into feeding from their trough. 5) Exportable crypto will not make NSA happy enough to let it be used as a global network protection system anyhow. Examination of recent trends indicates that intelligence/law enforcement understands the problems of scale posed by even low-quality crypto. The wiretap bill was the leading edge of the wedge. I suspect that if the intelligence community is faced with seeing huge amounts of encrypted data going in and out, they will balk. It'd be difficult for them to sort the wheat from the chaff and since right now they feel they hold all the cards there's no reason for them to be nice about it. In short, it's my belief, based on observation of the past actions of the intelligence community and law enforcement, that they're not going to let even low-level encryption become widely deployed. Treating with them in any way gives them a degree of control over the situation that renders it impossible to act effectively. mjr. From ipsec-request@ans.net Mon Apr 3 08:31:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22131 (5.65c/IDA-1.4.4 for ); Mon, 3 Apr 1995 12:37:18 -0400 Received: by interlock.ans.net id AA39798 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Apr 1995 12:31:57 -0400 Message-Id: <199504031631.AA39798@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Apr 1995 12:31:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Apr 1995 12:31:57 -0400 Date: Mon, 3 Apr 95 12:31:53 EDT From: hugo@watson.ibm.com To: ipsec@ans.net Cc: jis@mit.edu, galvin@tis.com, atkinson@itd.nrl.navy.mil, perry@imsi.com, ho@cs.arizona.edu, burt@RSA.COM, matt@RSA.COM, mihir@watson.ibm.com Subject: Proposals for key-ed MD5 I am sending here a note including suggestions for the definition of the key-ed MD5 function as a message authentication function (in particular, as the required function in the AH protocol). I apologize for not sending this in time for everybody to read it before Danvers but the analysis work has taken a considerable amount of time, and I did not want to send partial information. Hugo PS: Let me add one piece of information to the note below. All these schemes (including others that were proposed and we do not recommend) are breakable in time and space in the order of 2^64 by mounting a *chosen message attack* in which the adversary queries the key-ed function on (about) 2^64 chosen messages. This attack is unrealistic since it requires a huge number of messages (one will change keys much faster than that) and, moreover, these messages must be chosen by the adversary. This is very different than the well-known "birthday" attack on pure MD5 (i.e., without key) which also takes 2^64 time (to find collisions) but can be mounted independently of any secret information. The above attacks are not particular for MD5 but apply to any hash function (e.g., SHA) with the exception that the complexity is 2^(n/2) where n is the output length of the function (i.e., it will take 2^80 in SHA). However, going to a longer output just because of this attack is not needed since, as said, it is unrealistic already for 128. ----------------------------------------------------------------------------- To: IP Security Working Group From: Mihir Bellare and Hugo Krawczyk (IBM Research) Burt Kaliski and Matt Robshaw (RSA Laboratories) Re: Keyed-MD5 In the last days we have had discussions on the issue of how the keyed MD5 function should be defined for use as a message authentication function. We agreed on one function that is backed by the analysis carried out in both labs. However, this function (described below as option (I)) uses two different 128 bit keys and then may objected by some people. Therefore, we are suggesting two additional schemes. Here are terse descriptions of the three schemes. Explanations and justifications follow. DESCRIPTIONS: I) Double-keyed MD5: The function is MD5(K1|MD5(K2|text)). Here K1,K2 are two separate keys, each 128 bits, so that the total key length is 256 bits. An implementation suggestion (which shouldn't be part of the definition of the function) is to derive the two keys from some single 128 bit key K in such a way that K1 cannot be derived from K2, or K2 from K1. (For example, K1=MD5(K,A) and K2=MD5(K,B) for fixed distinct constants A,B.) This implementation suggestion means one can work with a 128 bit key K). II) Prepend-Pad-Append: The function is MD5(K|1|0^{383}|text|K) where K is a 128 bit key. That is, first pad the key to a 512 bit block; then append the text; then append the key (unpadded); now apply MD5 to the whole thing. (This is essentially the "familiar" MD5(K|text|K) but with the first key padded to 512 bits; this "small" change may turn out to be significant when more attacks on MD5 are discovered). III) Single key version of I: The function is MD5(K|MD5(K|text)) where K is 128 bits. That is, set K1=K2 in double keyed MD5. DISCUSSION: These suggestions are based on examination of MD5 and also on theoretical work of Bellare, Canetti and Krawczyk. A rough idea of the theoretical basis for the first function is as follows. We proved that if the compression function of MD5 behaves pseudo-randomly then scheme I is (provably) secure. The scheme is also provably secure under the assumption that MD5 is collision free and that one iteration of MD5 is a good MAC function. (The precise assumptions are more involved but very close to the above). The clear disadvantage of this scheme is the key length of 256 bits. Schemes II and III can be seen as different ways of trying to set the two keys of the first scheme to be equal. One advantage of (II) over the plain MD5(K|text|K) is that more than one iteration of MD5 takes place even in case text is very short. Moreover there is an implementation option of pre-computing MD5(K|1|0^383) and using the result as input to the ABCD registers of MD5; in this way the computation due to the prepended key is done only once per key. Scheme III) is least preferable because of the danger that the outer MD5 application reveals information about the key K. But nothing is known against it. From ipsec-request@ans.net Mon Apr 3 16:59:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25981 (5.65c/IDA-1.4.4 for ); Mon, 3 Apr 1995 13:04:05 -0400 Received: by interlock.ans.net id AA38672 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Apr 1995 12:59:18 -0400 Message-Id: <199504031659.AA38672@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 3 Apr 1995 12:59:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 3 Apr 1995 12:59:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 3 Apr 1995 12:59:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Apr 1995 12:59:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Apr 1995 12:59:18 -0400 X-Mailer: exmh version 1.5.3 12/28/94 To: "Marcus J. Ranum" Cc: amir@watson.ibm.com, bound@zk3.dec.com, tytso@MIT.EDU, perry@imsi.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Mon, 03 Apr 1995 11:32:56 EDT." <199504031530.AA36915@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 03 Apr 1995 12:59:12 -0400 From: " " > >I suspect Jim is right and there are many who share this position - i.e. > >we need exportable version but hate to admit it since it's so crazy... > 1) Exportable crypto is breakable crypto. Small but critical correction: exportable _encryption_ is breakable. And, I don't want us to standardize anything breakable. BUT we can have strong exportable _authentication_ (this already exists in products!). My suggestion: standard complying should require only strong authentication; encryption (strong or silly) should be only an option. Namely, ESP should not be a requirement (for IPSP in IPv4 or for IPv6). If one does implement ESP, I agree that strong encryption would be required. Best, Amir From ipsec-request@ans.net Mon Apr 3 18:21:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16887 (5.65c/IDA-1.4.4 for ); Mon, 3 Apr 1995 16:28:12 -0400 Received: by interlock.ans.net id AA59919 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Apr 1995 16:25:07 -0400 Message-Id: <199504032025.AA59919@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 3 Apr 1995 16:25:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 3 Apr 1995 16:25:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 3 Apr 1995 16:25:07 -0400 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Apr 1995 16:25:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Apr 1995 16:25:07 -0400 Date: 3 Apr 95 13:21:00 -0500 To: amir@watson.ibm.com Cc: ipsec@ans.net Subject: Manditory DES was - Re[2]: IPv6 Security Last >> >I suspect Jim is right and there are many who share this position - i.e. >> >we need exportable version but hate to admit it since it's so crazy... > >> 1) Exportable crypto is breakable crypto. > >Small but critical correction: exportable _encryption_ is breakable. No, not all exportable encryption is easily breakable. It is true that strong cryptography is difficult to field internationally. Our working group should recommend the best security solutions possible. >My suggestion: standard complying should require only strong authentication; >encryption (strong or silly) should be only an option. Namely, ESP should not >be a requirement (for IPSP in IPv4 or for IPv6). > >If one does implement ESP, I agree that strong encryption would be required. > >Best, Amir Implementations that do not fully conform to a specification can always document where they are non-conformant (e.g. complies to specification except for rot8 in place of DES-CBC). At a minimum the specification must create products that clearly identify their capabilites (a truth in advertising goal). Documenting a small set of manditory features and limiting options helps meet these goals. Exceptions are more likely to be clearly documented then additonal optional features. DES should be manditory. Paul From ipsec-request@ans.net Mon Apr 3 11:07:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22340 (5.65c/IDA-1.4.4 for ); Mon, 3 Apr 1995 21:17:34 -0400 Received: by interlock.ans.net id AA43413 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Apr 1995 21:12:55 -0400 Message-Id: <199504040112.AA43413@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Apr 1995 21:12:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Apr 1995 21:12:55 -0400 From: efb@suned1.Nswses.Navy.Mil (Everett F Batey SysAdm) Subject: Re: IPv6 Security Last Call Initial Questions To: amir@watson.ibm.com Date: Mon, 3 Apr 95 18:07:39 PDT Cc: bound@zk3.dec.com, tytso@MIT.EDU, perry@imsi.com, ipsec@ans.net In-Reply-To: <199504031325.AA12544@interlock.ans.net>; from "ipsec-request@ans.net" at Apr 3, 95 8:59 am Reply-To: efb@suned1.Nswses.Navy.Mil ( Everett F Batey II ) X-Orgztn: PHD NSWC (NSWSES) 4A05 Port Hueneme, CA 93043 - Opinions: Only Mine X-Phones: 805.982.7180, DSN 551, VoiceMail 805.340.6471, DPage: 655.2017 X-Mailer: ELM [version 2.3 PL11] Amir, Maybe this is not the place we will cure this problem .. I imagine that taking the economic argument to the folks who pass te laws is the most likely place to fix the problem .. from the IETF Briefing at InterOp_95 is was pretty clear that there is unamimous support for the goal of one encryption methodoly for all domestic and exports .. least so said the show of hands. Doubt if we will change the view here among our selves. I DO NOT SPEAK FOR ANY BUT ME .. /Ev/ -- + efb@suned1.nswses.Navy.MIL efb@gcpacix.cotdazr.org efb@uvsi.jpl.nasa.gov + + efb@nosc.mil efb@oxnardsd.org [EFB15] WA6CRE Gold Coast Sun Users + + The Genie is Out of the Bottle! :-) CANT Put it Back, Nor even Nuke It + + Opinions, MINE, NOT Uncle_s | WWW b-news innd postmaster XNTP3 DNS GNU + From ipsec-request@ans.net Tue Apr 4 01:24:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21609 (5.65c/IDA-1.4.4 for ); Mon, 3 Apr 1995 21:22:50 -0400 Received: by interlock.ans.net id AA31221 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Apr 1995 21:21:14 -0400 Message-Id: <199504040121.AA31221@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Apr 1995 21:21:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Apr 1995 21:21:14 -0400 Date: Mon, 3 Apr 1995 18:24:00 -0700 From: Phil Karn To: hugo@watson.ibm.com Cc: IPSEC@ans.net In-Reply-To: <199503292112.NAA21767@qualcomm.com> (hugo@watson.ibm.com) Subject: Re: fast re-keying Hugo, >The use of MD5 for deriving the keys is fine with me (as usual this should >be replaceable by any other "pseudorandom" function, e.g. DES-MAC-CBC). Yeah, but is the additional complexity worth it? Seems to me that since both the hash output and (part of) the input are secret, the strength of the hash here is not as important as it might be elsewhere. Remember also that we're trying to come up with an interoperable baseline, which means making some choices and sticking with them. >Since you are going through an interactive process to refresh the key (as >you explain below) then there is no reason to impose this special role to >the SAID (aka SPI these days). We better have no assumption on the SAID >(not even that it does not repeat through the life of a DH key; this should be >completely free for the implementation to decide). >The right way that I see to implement the fast re-key is to exchange >nonces between the parties and use them as arguments to MD5 for the derivation >of the keys. These nonces ensure the freshness and authenticity of the >exchanged key. The protocol remains simple and very cheap (as explained below). In effect, I am using randomly-chosen SAIDs as nonces. Random SAIDs are a good idea for other reasons. For one, they make it harder for an "off path" attacker to guess what SAIDs might be valid at a particular destination. Second, and perhaps of more immediate importance, randomly chosen SAIDs are an effective way to deal with the collisions that would otherwise occur when one system in a security association crashes, reboots and attempts to reuse a SAID that the other side still thinks is valid. I quickly ran into this in my prototype and decided that randomizing the SAIDs was a more general and elegant solution to the problem than coming up with an ad-hoc scheme to handle collisions. After all, although I opposed the 32-bit SAID as being unnecessarily large, now that we have it I might as well take advantage of it. I can explain all this in more detail after I arrive in Danvers tomorrow night. >Not only it gives the freshness referred to above, it also saves a lot of >bandwidth. Just sending the g^x,g^y as dummy values as you suggest seems >to me unjustfiably wasteful (1000bits each and if you're sending also If I were really worried about bandwidth in the protocol (which I'm not), I'd start elsewhere. E.g., the cookies don't really need to be 128 bits each, I used that size only because that's the size of MD5's output. I could probably knock them down to 64 bits each, which would save 128 bits in every Photuris packet but the original cookie request, which would save 64 bits. Besides, sending the DH exponentials every time is a simple way to let the other end see if they've changed without having to create yet another ad-hoc mechanism to do so. >to me unjustfiably wasteful (1000bits each and if you're sending also >g and p it will come to 3000 bits that are essentially unused). I'm not sending g and p anymore. I have a table of predefined g's and p's that currently includes exactly one pair: a 1024-bit p that is a strong prime, and a g that is a primitive root for that particular p. It's my understanding that you can't do any better than this at thwarting the discrete log problem for this size field, and generating equivalently good moduli takes a half hour of CPU time, so why bother with unnecessary generality? (I will have a facility to index a few other predefined g/p pairs of different sizes for those with a different performance/security tradeoff point.) >The need for cookies here is not clear to me. In particular, fast re-key >does not need to require cookies since only fast to compute and verify >functions are used. But again, I see this as a secondary detail. Every Photuris function that involves a modular exponentiation (i.e., most of them) requires a cookie to guard against off-path swamping attacks. To summarize my design philosophy for Photuris: a small and general purpose message set is more interesting to me than one that is overly optimized with lots of ad-hoc messages to save bits on the wire, because bits on the wire are just not that important here. Photuris packets will remain relatively rare in contrast to data packets even when frequent rekeying is done, so they're not worth a lot of optimization. What effort I can expend on optimization I'd rather invest in speeding up the modular exponentation and symmetric encryption functions and in implementing per-packet data compression. Phil From ipsec-request@ans.net Mon Apr 3 17:24:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21285 (5.65c/IDA-1.4.4 for ); Tue, 4 Apr 1995 03:32:22 -0400 Received: by interlock.ans.net id AA22836 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 4 Apr 1995 03:24:49 -0400 Message-Id: <199504040724.AA22836@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 4 Apr 1995 03:24:49 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 4 Apr 1995 03:24:49 -0400 Date: Tue, 4 Apr 95 00:24:37 PDT From: rogaway@cs.ucdavis.edu (Phil Rogaway) To: ipsec@ans.net Subject: IPSEC (comments on Internet Drafts) Some comments (about 10 pages) on the Internet Drafts: 1. draft-ietf-ipsec-auth-00.txt 2. draft-ietf-ipsec-esp-00.txt 3. draft-ietf-ipsec-arch-00.txt 4. draft-ietf-ipsec-esp-des-cbc-03.txt 5. draft-ietf-ipsec-ah-md5-02.txt I hope this input is reflected in the discussion in Danvers; I am unable to attend. Regards, Phil Comments P. Rogaway rogaway-00.txt UC Davis April 3, 1995 Problems with Proposed IP Cryptography STATUS OF THIS MEMO This document provides criticism on a set of related Internet Drafts. Distribution of this memo is unlimited. ABSTRACT Several recent Internet Drafts make high-level architectural choices and specify low-level cryptographic mechanisms for Internet Protocol (IP) version 4 (IPv4) and IP version 6 (IPv6) security [A-arch, A- ah-arch, A-esp-arch, MS-ah-mech, MKS-esp-mech]. Here I critique cryptographic aspects of this work. 0. INTRODUCTION This memo addresses five recent Internet Drafts: [A-arch, A-ah-arch, A-esp-arch, MS-ah-mech, MKS-esp-mech]. These documents describe the architecture and an initial set of mechanisms in support of message privacy and authenticity in IPv4 and IPv6. The purpose of this note is to help clear up a few cryptographic misunderstandings which seem to be embodied in above documents. It also aims to elucidate some architectural choices which the author deems to be questionable. This memo has some overlap with an e-mail note sent to Ran Atkinson (March 10, 1995) and the IPng mailing list (March 14, 1995). Four authors and two IETF Working Groups have been involved in producing the above referenced Internet Drafts. Nonetheless, I prefer to address this body of work as a unit. In this note I name the above five Internet Drafts the "March-95 IPSEC Drafts." Many of my criticisms go beyond specifics of the March-95 IPSEC Drafts. The reader knowledgable of a broader set of Internet protocols and security matters should draw the the necessary inferences on his own. The organization of this document is simple. Each of the Sections 1-9 address a single technical area in which the March-95 Internet Drafts seems (to me) to get something wrong. I wrap up with some Rogaway [Page 1] rogaway-00.txt IP Cryptography April 3, 1995 conclusions in Section 10. 1. AUTHENTICITY = INTEGRITY The March-95 IPSEC Drafts follow long-standing tradition in implying that there are meaningful and distinct notions of (cryptographic) message authentication and (cryptographic) message integrity. This isn't true -- at least not in the symmetric key trust model and the active-adversary scenario which the design of Internet security assumes. Let me briefly explain why (cryptographic) message authenticity coincides with (cryptographic) message integrity. After all, these two goals sound very different when described in simple English [A- arch, pp. 2-3]. First: what is AUTHENTICITY? Intuitively, you achieve this goal when you send a message to a recipient if the only messages which an adversary can get the recipient to accept as valid are those which did in fact originate with you. To arrive at a realistic and versatile notion of this we usually assume that the adversary can mount a chosen-message attack: she can get authenticated messages of her choice and from these she must produce some NEW message which the recipient will deem authentic. While there are weaker notions of authentication possible, this one is usually regarded as the minimal desirable goal. It was first formalized by Goldwasser, Micali and Rivest [GMR]. Now what, in contrast, is INTEGRITY? It is is often assumed to mean something weaker than what is sketched above. (Integrity is described in [A-arch, p.3] as "the property of ensuring that data is transmitted from source to destination without undetected alternation.") But unless we completely change the adversarial model (e.g., now the adversary just introduces "random noise") the formalization for integrity COINCIDES with that of authenticity. In other words, there is no known (mathematically meaningful) definition for (cryptographic) message integrity except for the same definition used for authenticity. Now all of the above would just be pedantic niggling were it not for the fact that the encryption-provides-integrity belief has concrete implications throughout the March-95 IPSEC Drafts. Two of these are detailed in the next two sections. I thus begin with the following recommendation: RECOMMENDATION 1: Remove all mention of (message) "integrity" and speak only in terms of (message) authenticity. Rogaway [Page 2] rogaway-00.txt IP Cryptography April 3, 1995 In the remainder of this note I'll use the word "authenticity", "integrity", or "authenticity/integrity" interchangeably: these mean the [GMR]-notion sketched above. 2. ENCRYPTION DOES NOT GUARANTEE INTEGRITY Now that we've gone over authenticity/integrity, the next thing to get straight is the orthogonality of this notion to that of privacy. A mechanism which achieves privacy --even perfectly-- need not achieve authenticity/integrity (in any sense at all). Intuitively, you achieve PRIVACY when you send a message if an adversary learns nothing about the plaintext from seeing the ciphertext, except for the length of the plaintext. If the adversary already has prior information about the plaintext, she shouldn't learn anything new about the plaintext by virtue of seeing the ciphertext. This condition must hold regardless of the distribution on messages from which the plaintext is drawn, and regardless of the messages which the adversary may have requested the encryptions of. There are stronger notions of encryption possible, but this one ("semantic security") is usually regarded as the weakest desirable goal. It was first formalized by Goldwasser and Micali [GM]. A (secure) encryption scheme is any mechanism that achieves privacy. A (secure) message authentication scheme is any mechanism that achieves authenticity. In practice, encryption schemes never achieve authenticity. For example, the "ideal" encryption scheme --a one time pad-- does not achieve authenticity. Nor does DES-CBC encryption. For example, it is trivial, given the DES-CBC encryptions of a set of known messages, to assemble the DES-CBC encryptions of an enormous number of known, new messages. As a matter of simplicity, extensibility, and taste, ANY (semantically secure) encryption mechanism should achieve the security goals of the Encapsulated Security Payload (ESP) mechanism. Privacy and authenticity are orthogonal goals and this orthogonality should be reflected in the architecture. RECOMMENDATION 2: Make privacy the sole goal of the ESP. Make the architecture document clearly state that authenticity/integrity is not generally provided by an ESP mechanism. Advise users that most situations which require privacy also require authenticity, and the way to get both privacy and authenticity is to use both the ESP and the AH. Many earlier systems have gotten this all wrong. For example, trying to provide one mechanism for authenticity and one for privacy + Rogaway [Page 3] rogaway-00.txt IP Cryptography April 3, 1995 authenticity (and no mechanism for privacy alone) makes the resulting system less versatile and dramatically decreases the chance that the protocol designers will get the protocols right. 3. IT IS WORTHLESS TO ENCRYPT KNOWN HEADERS As a final consequence of the encryption-provides-integrity error, the March-95 IPSEC Drafts recommend encrypting routing headers "even if the same data is in the unencrypted part of the IP datagram" [A- arch, p. 4]. The drafts maintain that "if this rule is not strictly adhered to, then the system will be vulnerable to various kinds of routing attacks" [A-arch, p. 5]. But in light of what has been said already, it should be clear that encrypting these headers does not (generally) overcome these attacks; to do that one must authenticate the datagram, not (just) encrypt it. As a general principle, since ALL that an ESP mechanism ought guarantee is privacy, it is NEVER useful to encrypt known text. Doing so increases the size of packets and the computational complexity of making them, while it provides no security benefit. RECOMMENDATION 3: Modify the architecture to forbid or deprecate the encryption of known headers. 4. DON'T ENCRYPT MESSAGE AUTHENTICATION CODES In the symmetric setting message authenticity/integrity is best achieved by a "Message Authentication Code" (MAC). A MAC is a short string computed on the message, the key, and possibly random bits or computational state of the signer. The receiver of a message which bears a MAC applies a Boolean-valued verification algorithm on the key, the message, and the MAC. As an example, the [MS-ah-mech] mechanism is a MAC. The most common MAC is the "DES-CBC-MAC," defined in standards ANSI X9.9 and ISO 9797. Though it may sound odd, it is an open question if encrypting a MAC results in a secure MAC. That is, we do not know that encrypting a MAC does not defeat the authenticity which the MAC is supposed to provide. As a consequence of this state of affairs, it is much more transparently correct to MAC an enciphered string than to encipher a MACed one. The March-95 IPSEC Drafts allows both possibilities. This seems unwise. RECOMMENDATION 4: Mandate that, when an ESP and an AH are both used, the scope of the authentication includes the encrypted packet (and not vice versa). Rogaway [Page 4] rogaway-00.txt IP Cryptography April 3, 1995 5. DEFINE TRANSFORMS GENERICALLY The March-95 IPSEC Drafts define their two transforms [MS-ah-mech, MKS-esp-mech] in a manner intertwined with the use of these transforms [A-ah-arch, A-esp-arch]. That is, the transform definitions assume language and context as provided by the higher- level documents. This is unnecessary and problematic. Encryption and authentication mechanisms are used in contexts much wider than the scope of these particular IPSEC Drafts. To make mechanisms generally useful (in particular, useful across IETF work efforts) cryptographic transforms must be defined "generically." A model for how to do this is [Rivest]. In fact, part of the popularity of MD5 derives from a clean statement of a generally- useful algorithm (conveniently packaged up with use-unrestricted code). Thus [MS-ah-mech] should describe a generic message authentication code, useful anywhere one wants message authentication. And [MKS- esp-mech] should describe a generic encryption mechanism, useful anywhere one wants symmetric encryption. RECOMMENDATION 5: Describe cryptographic transforms completely independently of their intended usage. Any "parent" document (the user of a transform) is responsible for specifying how to to use an arbitrary transform (of the proper signature) to carry out its business. It is easy to dismiss the above recommendation as "organizational." But this is an organizational issue with concrete implications. First, the difficulty of obtaining quality review of any proposed cryptographic transform is very different depending on whether or not one draws a clear abstraction boundary at transform. For example, while several colleagues would be willing to review the definitions of a clearly-defined MAC or encryption function, very few skilled colleagues are willing to wade through specialized language and notions which are fundamentally irrelevant. Second, a failure to draw a proper abstraction boundary breeds the "corrupting" of the transform to include dependencies on inappropriate information. For example, the use of the "Data Type" field in [MKS-esp-mech] should not appear at this level, since this has nothing to do with the secure encipherment of a string. Finally, a failure to draw a proper abstraction boundary at the transform makes the resulting mechanism of rather limited use, as described above. Rogaway [Page 5] rogaway-00.txt IP Cryptography April 3, 1995 6. MANDATE HARDWARE-EFFICIENT *AND* SOFTWARE EFFICIENT TRANSFORMS In specifying transforms [MS-ah-mech] and [MKS-esp-mech] the March-95 IPSEC Drafts embody a peculiar asymmetry: one transform [MKS-esp- mech] was designed to be hardware-efficient, while the other mechanism [MS-ah-mech] was intended to be software-efficient. Having a hardware-efficient privacy mechanism and a software-efficient authenticity mechanism is a way to suit no one's needs well. In deciding on mechanisms one must start from the set of requirements. One clear requirement ought to be the ability to obtain message privacy and authenticity services without unnecessary performance impact whether those services are implemented in special-purpose hardware or a general-purpose processor. Let us call this the "cross-platform efficiency goal." Unfortunately, it is impossible to achieve the cross-platform efficiency goal using one privacy mechanism and one authenticity mechanism. The reason is that a cryptographic mechanism which is designed to do well in software will be vastly more efficient in software than a software-implementation of a cryptographic mechanism designed to do well in hardware. Similarly, a cryptographic mechanism which is designed to do well in hardware will be vastly more efficient in hardware than a hardware-implementation of a cryptographic mechanism designed to do well in software. As an example, a software-optimized cipher named "SEAL" (Software Encryption ALgorithm) encrypts in about 20 instructions per (32-bit) word [RC] -- well over an order of magnitude faster than any software implementation of the (hardware-efficient) DES algorithm. On the other hand, appropriate use of DES lets you encrypt at the 1-10 GBit/second speeds of emerging high-speed networks -- not something to try with SEAL. The conclusion is that if we are going to usefully support privacy and authenticity in environments which might or might not have special-purpose hardware, than we should require privacy and authenticity mechanisms which are hardware-efficient as well as privacy and authenticity mechanisms which are software-efficient. RECOMMENDATION 6: There should be (at least) four required cryptographic transforms: a hardware-efficient encryption algorithm; a software-efficient encryption algorithm; a hardware- efficient MAC; and a a software-efficient MAC. Security architecture always involves tradeoffs. Here I am saying that a failure to meet the cross-platform efficiency goal is an unacceptable tradeoff for the slight simplification of having two required mechanisms instead of four. Rogaway [Page 6] rogaway-00.txt IP Cryptography April 3, 1995 Some might argue that two additional encryption transforms should be specified: an exportable software-efficient mechanism and and an exportable hardware-efficient mechanism (thus making 6 specified transforms). I won't voice an opinion on this (political) question, but let me say that it is desirable that, from the start, implementations support multiple encryption transforms. Without this, mechanism-negotiation (which is crucially important) will end up absent or wrong. 7. USE 128-BIT KEYS A second requirement that mechanisms should meet is not to be susceptible to simple key-exhaustion attacks (when the keys are selected from a suitably large space). Key distribution mechanisms should not distribute 64-bit keys. Doing that limits IP security's evolution path. Use of 128-bit keys does not imply incompatibility with algorithms that use 64-bit keys. Where older mechanisms exist with which one wishes to maintain compatibility (DES-CBC encryption) the 128-bit algorithm can be constructed so that particular 128-bit keys induce a transformation which coincides with that of a standard mechanism operating on a 64-bit key. RECOMMENDATION 7: The required encryption and authentication mechanisms should use 128-bit keys. (Of course defining an algorithm in terms of a 128-bit key does not imply that the key resides in its operational form as a 128-bit quantity; it is often convenient to represent the key by a larger structure.) 8. THE MAC MECHANISM The MAC currently specified in [MS-ah-mech] is MAC_a(x) = MD5(MD5(x).a). The MAC specified in the previous version of this document (and still specified in [A-ah-arch] was MAC_a(x) = MD5(a.x.a). While the old suggestion was better than the new one, neither is good. I claim that no similar MD5-mode of operation will make a good choice, either. My reasons: [1] TOO SLOW. The MD5 algorithm takes a few tens of instructions per word, and nothing can be done about that. [2] NO FOUNDATIONS: The correctness of MAC_a(x) = MD5(a.x.a) is unrelated to the assumed collision intractable of MD5. The correctness of MAC_a(x) = MD5(MD5(x).a) requires collision intractability of MD5 but does not appear to imply it. Rogaway [Page 7] rogaway-00.txt IP Cryptography April 3, 1995 Analogous statements seem to hold when one assumes other (unre- lated) cryptographic assumptions about MD5. Thus for neither method do standard or well-understood beliefs about the proper- ties of our cryptographic primitives imply the correctness of the the message authentication code built on top of them. [3] NO MANIFEST PARALLELISM: If you can compute MD5 in x bits per second using one MD5 chip then with two MD5 chips you can com- pute MD5 in ... x bits per second. That is, extra hardware just doesn't help. This concern is not very relevant if one also supports (as suggested) a good, hardware-efficient MAC. But if one is specifying only one authentication mechanism, this would be a problem. What is the alternative to a mechanism like MD5(a.x.a) ? Objection [2] can be answered by switching, for example, to MAC_a(x) = DES- CBC-MAC_a(MD5(x)); this construction is provably-good under the assumption that DES is a secure block cipher and MD5 is collision- intractable [BR]. An alternative provably-secure solution (under a different assumption) was recently offered by Bellare, Canetti and Krawczyk [BCK]; it uses MD5 alone as the underlying cryptographic primitive. Unfortunately, both of these alternatives (and ones like them) do nothing to address the efficiency problem [1]; it remains the case that one is spending some 50 or so instructions per (32-bit) word of message [Touch]. An alternative approach for making a fast and high-confidence MAC lies in what is called "Wegman-Carter authentication" [WC]. Using known results, an efficient "almost-universal-2" hash family gives rise to an efficient MAC. Describing such MACs is out of the scope of this note, but recent work of my own [Rogaway] suggests that MACs constructed in this manner will be about 2-4 times faster than MD5. I expect to have a concrete scheme specified in the coming months. RECOMMENDATION 8: Achieve software-efficient message authentica- tion using a Wegman-Carter MAC based on a carefully-designed almost-universal-2 family of hash functions. If for some (political?) reason one insists on basing a MAC on a collision-intractable hash function, then there is no reason why the collision-intractable hash function should not be used in a manner which enjoys some provable-security claim. 9. THE ENCRYPTION MECHANISM The DES-CBC transform of [MKS-esp-mech] suffers from a completely different set of problems than the MD5 MAC mechanisms. I take the Rogaway [Page 8] rogaway-00.txt IP Cryptography April 3, 1995 DES-CBC transform to be the proposed method for hardware-efficient encryption, and so it would be inappropriate for me to criticize its software performance. On the other hand, the issue of key size which has plagued DES since its inception only gets worse (e.g., see [Weiner]) -- so much so that, at this point, it may be irresponsible for any NEW proposal to specify DES in a mode of operation which is susceptible to 2**56 complexity key-exhaustion. Fortunately, this problem is easily remedied: one changes the mode of usage of the same cipher. As sketched in Section 7, I recommend that one achieve hardware-efficient encryption using DES in a mode of operation which employs a 128-bit key used in a manner which coin- cides with DES-CBC on a 64-bit key whenever the 128-bit key is appropriately selected. There are many such possibilities. For example, instead of cipher block chaining DES one could cipher block chain the block cipher F_ab(x)= E_a(D_b(E_a(x)))), where E=DES and D=DES^{-1}. When the key ab is of the form aa, the method coincides with DES-CBC_a. RECOMMENDATION 9: The hardware-efficient encryption mechanism should be a 128-bit upwardly-compatible version of DES-CBC. There are further problems with particulars of the [MKS-esp-mech] proposal. Unlike the MAC proposal [MS-ah-mech], the encryption pro- posal is more a "template" for a mechanism than a particular mechan- ism, since it attempts to avoid pinning down even the length of the Initialization Vector (IV). This is unnecessarily complex and will cause people to mis-implement the choice of IV. RECOMMENDATION 10: Each transform should fully specify one partic- ular function (though this function may be probabilistic or state- ful). For example, if one has a mechanism like DES-CBC, one must specify how the initialization vector is to be selected. The reason for this recommendation is experience that indicates that if a transform is not completely specified, implementors will not know how to finish the "missing pieces" in a way that is cryptograph- ically correct. As an example, it is not true that CBC encryption can use an arbitrary nonce initialization vector: it is essential that the IV be unpredictable by the adversary. (To see this, suppose the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryp- tion of 0x0000000000000000 followed by an encryption of 0x0000000000000001 is recognizably distinct from a (first) encryption of 0x0000000000000000 followed by an encryption of 0x0000000000000000. Clearly this violates violates the notion of a secure encryption sketched in Section 2.) Rogaway [Page 9] rogaway-00.txt IP Cryptography April 3, 1995 10. CONCLUSIONS The March-95 IPSEC Drafts have several significant flaws. Some of these seem to be misunderstandings about the correct use of crypto- graphic primitives; other problems are more architectural in nature. In any case, it seems clear that this body of work needs a lot more thought and maturation. I worry about the process by which cryptographic mechanisms emerge and get standardized. A committee can not do good cryptographic design. Reading [Schneier] does not qualify one to do cryptographic design. A set of requirements should be understood and then propo- sals should be sought (from the few relevant people) responsive to those requirements. Let me end by returning (by way of example) to the change we saw dur- ing the last iteration of the MAC mechanism [MS-ah-mech]. Recall that it went from MAC_a(x) = MD5(a.x.a) to MAC_a(x) = MD5(MD5(x).a). It is easy to fall into the trap of arguing in the margins: here one would pick the mechanism he likes more (for me: the old one), and then try to argue why. But this is just silliness. The fact is, the change fixes none of the issues mentioned in Section 8 (in fact, it makes issue [2] worse); neither mechanism is on track. So how did we go from the one old mechanism to the new, and why? The document, at least, provide no clue. It makes one wonder: are we on a path which will lead to meaningful and scientific standards -- or are people just guessing? 11. REFERENCES [A-ah-arch] R. Atkinson, "IP Authentication Header." draft-ietf- ipsec-auth-00.txt, 23 March 1995. [A-esp-arch] R. Atkinson, "IP Encapsulating Security Payload (ESP)." draft-ietf-ipsec-esp-00.txt, 23 March 1995. [A-arch] R. Atkinson, "Security Architecture for the Internet Pro- tocol." draft-ietf-ipsec-arch-00.txt, 23 March 1995. [BCK] M. Bellare, R. Canetti and H. Krawczyk (unpublished). Personal communication through Mihir Bellare (February 1995). [BR] M. Bellare and P. Rogaway, "Entity Authentication and Key Distribution." Proceedings of CRYPTO '93 (1993). Rogaway [Page 10] rogaway-00.txt IP Cryptography April 3, 1995 [GM] S. Goldwasser and S. Micali, "Probabilistic Encryption." J. of Computer and System Sciences, 28, pp 270-299, April 1984. [GMR] S. Goldwasser, S. Micali and R. Rivest, "A digital signa- ture scheme secure against adaptive chosen-message attacks," SIAM Journal of Computing, 17(2), pp. 281-308, April 1988. [MKS-enc-mech] P. Metzger, P. Karn and W. Simpson. "The ESP DES-CBC Transform." draft-ietf-ipsec-esp-des-cbc-03.txt. [MS-auth] P. Metzger and W. Simpson, "IP Authentication using Keyed MD5." draft-ietf-ipsec-ah-md5-02.txt, March 1995. [Rivest] R. Rivest, "The MD5 Message-Digest Algorithm," RFC-1321, DDN Network Information Center, April 1992. [Rogaway] P. Rogaway, "Bucket Hashing and its Application to Fast Message Authentication." Manuscript. February 1995. [RC] P. Rogaway and D. Coppersmith, "A software-optimized encryption algorithm." Fast Software Encryption, Cam- bridge Security Workshop, 1993 Proceedings, R.~Anderson, ed., pp. 56-63. Lecture Notes in Computer Science, vol. 809, Springer-Verlag (1994). [Schneier] B. Schneier, "Applied Cryptography." John Wiley & Sons, 1994. [Touch] J. Touch, "Performance Analysis of MD5." Manuscript (1995). [Weiner] M. Weiner, "Efficient DES Key Search." Manuscript (1993). [WC] M. Wegman and L. Carter, "New Hash Functions and their use in Authentication and Set Equality." J. of Computer and System Sciences, 22, 265-279 (1981). 12. AUTHOR'S ADDRESS Phillip Rogaway Department of Computer Science Engineering II Building University of California Rogaway [Page 11] rogaway-00.txt IP Cryptography April 3, 1995 Davis, California 95616 (916) 752-7583 rogaway@cs.ucdavis.edu Rogaway [Page 12] From ipsec-request@ans.net Tue Apr 4 15:29:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22483 (5.65c/IDA-1.4.4 for ); Tue, 4 Apr 1995 19:33:28 -0400 Received: by interlock.ans.net id AA21970 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 4 Apr 1995 19:29:57 -0400 Message-Id: <199504042329.AA21970@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 4 Apr 1995 19:29:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 4 Apr 1995 19:29:57 -0400 Date: Tue, 4 Apr 95 19:29:54 EDT From: hugo@watson.ibm.com To: karn@qualcomm.com Cc: IPSEC@ans.net Subject: fast re-keying Ref: Your note of Mon, 3 Apr 1995 18:24:00 -0700 (attached) Phil, > In effect, I am using randomly-chosen SAIDs as nonces. Random SAIDs > are a good idea for other reasons. For one, they make it harder for an > "off path" attacker to guess what SAIDs might be valid at a particular > destination. I disagree with your approach here. Especially disguising SPI's as nonces (or nonces as SPI's?) This WG decided that SPI's are free for the implementation to choose. If in your implementation you find useful to choose them random, fine with me. But do not impose that on me (e.g., I may choose to have 16 bits that are a fast index to a table and only 16 bits to prevent collisions of the type you mention). As for using the SPI's as nonces, in addition to putting the randomness constraint on them, there at least two other problems. 1) They are shorter than usually recommended for nonces (64 bits the typical recommended length). 32 bits create collisions after 2^16 uses. In most cases you won't get to that, but still 65500 is not such a huge number. 2) (more important for me) One should avoid (if possible) the use of an element defined in one way for a completely different goal. Especially, if the later has essential implications for security. This unnatural and hidden binding is likely to create problems. Now, if you have something great to gain from this binding then it is worth considering it. There is nothing here. Clearly not space where you're willing to spend 1000 bits where 64 will do. I do not see what other reason. Simplicity is not the case, this binding projects simplicity to the surface but actually complicates by creating unnecessary dependencies between the SPIs and nonce functions. Notice that my suggestion to use the field of DH public parts as nonces (but only with 64 bits instead of 1024) is not the kind of hidden binding mentioned above. Indeed, the DH-parts are already used in your design as nonces for the freshness of signatures (I do the same in my Photuris variant). (And even here things may be dangerous if two parties repeat their public parts). As for the issue of space, OK so you do not care much about it. One thing is to try to optimize each bit, another is to waste unnecessarily (that's the way I see the repeated sending of g^x,etc) On the need for cookies during fast re-key: > Every Photuris function that involves a modular exponentiation (i.e., > most of them) requires a cookie to guard against off-path swamping attacks. I agree, but fast re-keying does *not* involve exponentiation. > To summarize my design philosophy for Photuris: a small and general > purpose message set is more interesting to me than one that is overly > optimized with lots of ad-hoc messages to save bits on the wire, I agree here, too. That's the way I see the "Photuris variant" I propose. Adding important functionality to Photuris without paying with additional protocols or fancy messages. > What effort I can expend on optimization I'd rather invest in speeding up > the modular exponentation and symmetric encryption functions and in > implementing per-packet data compression. That's fine but orthogonal to all the issues discussed here (except if you talk about how to invest your own time). > I can explain all this in more detail after I arrive in Danvers > tomorrow night. I'll be glad to do that (on Wed or Thu). Hugo From ipsec-request@ans.net Wed Apr 5 00:37:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28245 (5.65c/IDA-1.4.4 for ); Tue, 4 Apr 1995 20:46:58 -0400 Received: by interlock.ans.net id AA32158 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 4 Apr 1995 20:41:49 -0400 Message-Id: <199504050041.AA32158@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 4 Apr 1995 20:41:49 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 4 Apr 1995 20:41:49 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 4 Apr 1995 20:41:49 -0400 To: efb@suned1.Nswses.Navy.Mil ( Everett F Batey II ) Cc: amir@watson.ibm.com, bound@zk3.dec.com, tytso@MIT.EDU, perry@imsi.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Mon, 03 Apr 95 18:07:39 PDT." <9504040107.AA01255@suned1.Nswses.Navy.Mil> Date: Tue, 04 Apr 95 20:37:04 -0400 From: bound@zk3.dec.com X-Mts: smtp >Maybe this is not the place we will cure this problem .. I imagine >that taking the economic argument to the folks who pass te laws is the >most likely place to fix the problem .. from the IETF Briefing at >InterOp_95 is was pretty clear that there is unamimous support for the >goal of one encryption methodoly for all domestic and exports .. least >so said the show of hands. >Doubt if we will change the view here among our selves. >I DO NOT SPEAK FOR ANY BUT ME .. /Ev/ I heard about Interop_95. I also have seen a grass roots movement since last night at the IETF when Dan Nessett and I were finally able to bring this up in an IPng Forum as it was still on the IPng list for last call. Its now on IPSEC. WHich was not clear to all until last night. We were able to present our arguments without being interupted and the issues of REQUIRING vendors to conform to standards that cannot be exported. Several users and now other vendors do understand the issue because we were able to state our case. So I assure all again I am not the only one here with this objection. I only hope this grass roots effort is exponential. This will be put together in a last call objection to the IESG. I don't see any point of discussing it anymore on the list other work is too important. The onus is on those of us who believe that MUST any encryption by any standards org that will force vendors who want to be IPv6 compliant to not be able to export a product is just WRONG. The case will be stated OK. A product can be IPv4 compliant and not implement security. This is how IPv6 should be too. The market sector that needs, wants, desires, and requires security for IPv4 or IPv6 will put out RFP's requiring IPSP with a stated encryption algorithm to make their market sector interoperable. If a vendor cannot provide that security then they cannot bid on that particular venture. Its very simple the market will do the right and needed thing. The IETF just needs to give them a standard not mandate it in an IPv6 network kernel protocol implementation. As a 'user' stated in the IETF. If I want to purchase systems from U.S. Vendors in Europe, and I specify that they must be IPv6 compliant, and then they cannot be IPv6 compliant because they cannot export their product which requires ESP DES to be IPv6 compliant, that is wrong. What we need in the spec is an 'if clause before the MUST do encryption was a suggestion from another vendor (not Dan or I). About all I can say. But there is a real grass roots movement and I am going to keep pushing it with several other members as of right now. I don't think the issue has been thoroughly discussed or all the problems put on the table. This is not fair to the vendor community who in fact have helped build and support what is the Internet and TCP/IP today. Look around how many proponents of MUST encryption are system vendors who ship International products. How many are system integrators, ONE country only vendors, or Academics who do not build products or live and die by the hard rules of business in an International environment. The IETF wants to be an International Standards Organization. Well rule #1 is you don't put MUST standards on the community that is going to build those standards and provide them in an International market, that they cannot implement and claim a conformant product. This to me is just common sense. Users will have security at Interop_95 that is interoperable without putting a MUST encryption to be IPv6 compliant. Note: now I do not believe any encryption should be specified as a MUST, strong or weak. And now I think DES is weak and IDEA is strong fyi. p.s. There is no issue with MUST authentication if that has become confused. /jim From ipsec-request@ans.net Wed Apr 5 00:49:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12664 (5.65c/IDA-1.4.4 for ); Tue, 4 Apr 1995 20:50:32 -0400 Received: by interlock.ans.net id AA45293 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 4 Apr 1995 20:47:16 -0400 Message-Id: <199504050047.AA45293@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 4 Apr 1995 20:47:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 4 Apr 1995 20:47:16 -0400 Date: Tue, 4 Apr 1995 17:49:59 -0700 From: Phil Karn To: hugo@watson.ibm.com Cc: IPSEC@ans.net In-Reply-To: <199504042329.QAA12076@qualcomm.com> (hugo@watson.ibm.com) Subject: Re: fast re-keying There's another very good reason to randomize SPIs that I haven't mentioned yet. I've created an ICMP message that reports problems like "unknown SPI" "authentication failed", etc. My current implementation blows away the specified SPI when it gets one of these ICMP messages. You've got to have a feature like this in any real implementation for the same reason we have TCP resets. Now this definitely opens up a new class of denial of service attacks. If SPIs are chosen in a predictable way, remote denial-of-service attacks are pretty clearly easy. But if you pick your SPIs randomly, this becomes a lot harder. Seems like a good precaution to me. And once your SPIs are random, you might as well use them as nonces. I'm not particularly worried about collisions since I update my DH exponentials every 1000 seconds or so anyway. Phil From ipsec-request@ans.net Wed Apr 5 10:40:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04254 (5.65c/IDA-1.4.4 for ); Wed, 5 Apr 1995 06:57:27 -0400 Received: by interlock.ans.net id AA42947 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 5 Apr 1995 06:50:43 -0400 Message-Id: <199504051050.AA42947@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 5 Apr 1995 06:50:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 5 Apr 1995 06:50:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 5 Apr 1995 06:50:43 -0400 To: Phil Karn Cc: hugo@watson.ibm.com, IPSEC@ans.net, bound@zk3.dec.com Subject: Re: fast re-keying In-Reply-To: Your message of "Tue, 04 Apr 95 17:49:59 PDT." <199504050047.AA45293@interlock.ans.net> Date: Wed, 05 Apr 95 06:40:52 -0400 From: bound@zk3.dec.com X-Mts: smtp Phil, >There's another very good reason to randomize SPIs that I haven't >mentioned yet. I've created an ICMP message that reports problems like >"unknown SPI" "authentication failed", etc. My current implementation >blows away the specified SPI when it gets one of these ICMP messages. >You've got to have a feature like this in any real implementation for the >same reason we have TCP resets. There is another potential ICMP message we need. "I have not turned on Security or I am not USING Security at this node". I think it should just be a new ICMP code and carry none of the security related data. This will be very useful to sys admins of security gateways too. This could also be done with an application message but would cost more to process as when I see the AH or ESP header in ip or ip6 layer I can just reject it there if I am not using security for this node. /jim From ipsec-request@ans.net Wed Apr 5 16:54:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16792 (5.65c/IDA-1.4.4 for ); Wed, 5 Apr 1995 12:59:25 -0400 Received: by interlock.ans.net id AA09977 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 5 Apr 1995 12:54:55 -0400 Message-Id: <199504051654.AA09977@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 5 Apr 1995 12:54:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 5 Apr 1995 12:54:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 5 Apr 1995 12:54:55 -0400 Date: Wed, 5 Apr 1995 12:54:26 -0400 From: "Theodore Ts'o" To: bound@zk3.dec.com Cc: efb@suned1.Nswses.Navy.Mil, amir@watson.ibm.com, bound@zk3.dec.com, perry@imsi.com, ipsec@ans.net In-Reply-To: <9504050037.AA01875@xirtlu.zk3.dec.com> (bound@zk3.dec.com) Subject: Re: IPv6 Security Last Call Initial Questions Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 >I also have seen a grass roots movement.... I still remain unconvinced whether it's "grass roots", or "astroturf". :-) I've always been amused when vendors try to make the case that their concerns, as opposed to their custmers, should be considered "grass roots". One additional comment concerning this whole export nonsense. Keep in mind that if we make it optional, we will have to live with the resulting lack of interoperability and lack of security for decades. There are rumors that at least within the United States, the rules for DES may be significantly eased in the next year. (Specifically, that products with DES might in the fuuture automatically have Commerce Jurisdiction.) I, personally, will be very, very surprised if the U.S. export regulations do not get significantly reformed in the next 3-5 years. It would be extremely ironic if we made a decision which had negative impacts for decades, especially if the country-specific, legal excuses for doing this vanish shortly after we make said decision. - Ted P.S. There do exist countries for which crypto export is not an issue. DEC could simply set up a programming shop there, thus draining more jobs from the United States. If enough of this happens, maybe the U.S. will reconsider its current irrational laws even faster than what I expect. From ipsec-request@ans.net Wed Apr 5 17:55:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22424 (5.65c/IDA-1.4.4 for ); Wed, 5 Apr 1995 13:59:58 -0400 Received: by interlock.ans.net id AA17001 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 5 Apr 1995 13:56:02 -0400 Message-Id: <199504051756.AA17001@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 5 Apr 1995 13:56:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 5 Apr 1995 13:56:02 -0400 Date: Wed, 5 Apr 1995 10:55:58 -0700 From: Phil Karn To: bound@zk3.dec.com Cc: hugo@watson.ibm.com, IPSEC@ans.net, bound@zk3.dec.com In-Reply-To: <9504051040.AA08420@xirtlu.zk3.dec.com> (bound@zk3.dec.com) Subject: Re: fast re-keying >"I have not turned on Security or I am not USING Security at this node". How about an ICMP Protocol Unreachable message? This has the definite advantage of already being implemented both for the encapsulation protocol and for the UDP port used for key management... Phil From ipsec-request@ans.net Thu Apr 6 02:55:35 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15479 (5.65c/IDA-1.4.4 for ); Wed, 5 Apr 1995 23:11:19 -0400 Received: by interlock.ans.net id AA37049 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 5 Apr 1995 23:01:26 -0400 Message-Id: <199504060301.AA37049@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 5 Apr 1995 23:01:26 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 5 Apr 1995 23:01:26 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 5 Apr 1995 23:01:26 -0400 To: Phil Karn Cc: bound@zk3.dec.com, hugo@watson.ibm.com, IPSEC@ans.net Subject: Re: fast re-keying In-Reply-To: Your message of "Wed, 05 Apr 95 10:55:58 PDT." <199504051755.KAA06358@servo.qualcomm.com> Date: Wed, 05 Apr 95 22:55:35 -0400 From: bound@zk3.dec.com X-Mts: smtp Phil, >>"I have not turned on Security or I am not USING Security at this node". >How about an ICMP Protocol Unreachable message? This has the definite >advantage of already being implemented both for the encapsulation >protocol and for the UDP port used for key management... Yes this would be better. A question. The way this could work in an IPv6 BSD implementation is that when parsing the IPv6 header and I see an ESP or AUTH Next Payload type I will know at that point I need to send an ICMP unreachable message. If the UDP data is encrypted or the plain text is authenticated I don't want have to decipher it to get the UDP port. I would rather not invoke any of the security routines or pass to the transport layer as I can know at the ip6_input routine I am not using security for this user, unless an application has overridden that with the API or socket option for a particular socket (which right now I guess is implementation defined with no standard yet). Can we have a well known port to send the ICMP Unreachable to regardless of the key management used? Or will they all use different ports do you think? Will this work for in-band keying too? thanks /jim From ipsec-request@ans.net Thu Apr 6 04:37:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17704 (5.65c/IDA-1.4.4 for ); Thu, 6 Apr 1995 00:52:04 -0400 Received: by interlock.ans.net id AA31209 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 6 Apr 1995 00:42:25 -0400 Message-Id: <199504060442.AA31209@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 6 Apr 1995 00:42:25 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 6 Apr 1995 00:42:25 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 6 Apr 1995 00:42:25 -0400 To: "Theodore Ts'o" Cc: bound@zk3.dec.com, efb@suned1.Nswses.Navy.Mil, amir@watson.ibm.com, perry@imsi.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Wed, 05 Apr 95 12:54:26 EDT." <199504051654.MAA00120@rsx-11.mit.edu> Date: Thu, 06 Apr 95 00:37:01 -0400 From: bound@zk3.dec.com X-Mts: smtp Ted, >>I also have seen a grass roots movement.... >I still remain unconvinced whether it's "grass roots", or "astroturf". :-) Now be nice remember that flame mail you accused me and others of? Its real Ted and I also presented my ideas to Paul Lambert tonight and no one or me is saying that strategically in the IETF we should not specify confidentiality security. We must do this to have a secure Internet. The question on the table is how do we do this tactically? >I've always been amused when vendors try to make the case that their >concerns, as opposed to their custmers, should be considered "grass roots". I would like an apology as you have just accused me of not understanding my customers concerns in a public forum. Please apologize. You cannot make these kind of suggestive accusations its counter-productive and defamation to my character as an IETF individual and as an employee of my company. You are out of line above and we do not need that kind of mail on such an important topic in this mailing list. Grass roots above means that many in the community have expressed that my explanation and discovery process of the issues are in fact worth thinking about. I am championing this 'thought process' and I have done it in other standards forums, in a large corporation, and I know how to bring an issue to the table for discussion even when it may be getting slammed dunked by a group of activists. Yes I am doing this not for Digital, not for Sun, not for XYZ, but because I believe the entire discussion has not taken place and is not done. It also needs wider community discussion in the IETF not just in this working group. But being experienced in such a process I realize some will attack me and even go to the extreme of offending me. Until this is over if this happens too much an individual may find themselves sitting in a court room explaining to a judge why they felt they had the right to defame or abuse the rights of Jim Bound as an individual in a public forum. And I have a set of family and many friends connected to the legal profession who will do this for me for free for the right reasons. So please don't push it if your in the U.S. anywhere. I will note that my colleagues in 99% of the cases in Europe and Pacrim have not done anything like this and we ought to wonder about that in the U.S. and consider why they are able to keep this professional at all times via email. I am representing me Jim Bound. But I also think my position benefits the many customers I do know and many vendors I know as colleagues in the IETF who are also present as individuals. I want to be able to build both AUTH and ESP for the market as an engineer as part of IPv6 and for the Internet in general. But I also want my work to be IPv6 conformant world wide and this will turn me on as an engineer to know that the IPv6 stack and environment I will build will be used in the U.S.A., Russia, Singapore, Switzerland, or Brazil. This means my "code" and the someday product will help the Internet be better because of IPv6 and the added Security for the Internet. To do this in the most expedient fashion would be to REQUIRE AUTH which will give all IPv6 users integrity out of the box. And then specify that if a user wants confidentiality STD XXX MUST be used. The reason we have to do this in such a manner is because the reality is that none of 'the' vendors can build a conforming IPv6 implmentation that will meet the export/import restrictions within some countries in the Americas, Europe, and Asia. Let the consumer determine and specify that encryption is a must do in the product not the IETF as a thought to this working group and a discussion point OK. The IETF will have done its job with the above. >One additional comment concerning this whole export nonsense. Keep in Its not nonsense its reality Ted. I think laws against any firearms or many vices are nonsense too, but I have to abide by them whether I like them or not, so I abide by them and vote at every opportunity I get and influence change wherever I can. But at the end of the day in a court I can't break the law no matter how silly it is in my view of the world and not get punished. So I be cool and hope for change. Also the law in many international countries is that you cannot export/import encryption either its not just a U.S.A. issue. >mind that if we make it optional, we will have to live with the >resulting lack of interoperability and lack of security for decades. No the scenario above will work. And authentication is available as I stated out of the box. And if we state the ESP standard well enough and implement the work in this working group and get it as a STD the market will require it and the vendors and the market will work out how to make it happen. We in the IETF will have done our job. >There are rumors that at least within the United States, the rules for >DES may be significantly eased in the next year. (Specifically, that >products with DES might in the fuuture automatically have Commerce >Jurisdiction.) I, personally, will be very, very surprised if the >U.S. export regulations do not get significantly reformed in the next >3-5 years. The IETF work and International community cannot do business and we should not determine our tactical strategy for encrption based on rumors. But if the laws change then we can update our standards. >It would be extremely ironic if we made a decision which had negative >impacts for decades, especially if the country-specific, legal excuses >for doing this vanish shortly after we make said decision. But today we do have a legal problem. And by specifying it now in the standards will cause an implementation conformance problem. If we give the market the standard to require for IPv6 to have interoperable implementations with confidentiality then as a standards organization we have done our job. Customers simply write their RFP in this manner: Network Section: 1. Client and Server end systems MUST conform to IETF IPv6 Base Protocol Specification, System Discovery, DNSINDv6, DHCPv6, ICMPv6, etc. etc.. etc.. and Security (AUTHENTICATION). 2. Client and Server end systems MUST conform to the IETF IPv6 Confidentiality RFC ####. Done. Everything you stated you want and others is accomplished. >P.S. There do exist countries for which crypto export is not an issue. >DEC could simply set up a programming shop there, thus draining more >jobs from the United States. If enough of this happens, maybe the >U.S. will reconsider its current irrational laws even faster than what I >expect. Please do not just pick on Digital (and fyi its not DEC please) my position would be the same as a small business person building customized host server kernels for embedded systems. I have already on the IPng Directorate taken positions that were completely contrary to my companies best interest when it was in the interest of the Internet community to proceed correctly technically. I have done this often in the IPv6 WG too. Anyone in the IETF who 'really' knows me for the past two years have even seen me and my colleagues who also work for Digtial fight for different technical positions on technology matters. So this does not apply to me - Jim Bound. Its not called a programming shop it would be called an engineering porting center most likely. Also what will change the laws is not this but real political pressure and here is how it could proceed for the U.S. and with minor tweeks other countries that have a democracy of some form: 1. Vendor pressure through their lobbyists. 2. Small firms can contact the Small Business Associations and their congressman and senators. 3. The IETF ISOC relationship needs to take this on as a job and connect with ISO, IEEE, and JTC1 to push back on the FTC. 4. Use the G7 Summits to put pressure on the U.S. and all countries that have export/import restrictions on computer cryptography. * also right now is a good time because of the present congress * The ECMA via the IETF connecting with them can affect the European issues with G7 too. All of us as individuals calling or writing to our congressman and senators that this is bogus. I have done this already back when IPv6 was an issue between SIPP, CATNIP, and TUBA and we saw the IPv6 encryption coming on the IPng Directorate in a letter where I was complaining about a bunch of stuff per firearms. I will do it again just for this export issue this weekend. I suggest all in the U.S. who really care write letters too. At the end of the day I will support what the IETF community decides to any who confide in me or think my consultation in fact is important that all must do what the IETF has decided including MUST ESP DES if we can't fix that wording. I have no clue what will happen per the export issue other than I think some kind of wording will be invented to ship products abroad by most vendors I am sure. In fact by not leaving it to the consumer could cause the objective to not happen because its assumed and not stated. Similar in result to the prohibition era in the U.S. in the 1920s (aka the roaring 20s). /jim From ipsec-request@ans.net Thu Apr 6 13:25:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21668 (5.65c/IDA-1.4.4 for ); Thu, 6 Apr 1995 09:34:40 -0400 Received: by interlock.ans.net id AA15344 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 6 Apr 1995 09:24:08 -0400 Message-Id: <199504061324.AA15344@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 6 Apr 1995 09:24:08 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 6 Apr 1995 09:24:08 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 6 Apr 1995 09:24:08 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 6 Apr 1995 09:24:08 -0400 From: "Marcus J. Ranum" Subject: Re: IPv6 Security Last Call Initial Questions To: bound@zk3.dec.com Date: Thu, 6 Apr 1995 09:25:03 -0400 (EDT) Cc: tytso@MIT.EDU, efb@suned1.Nswses.Navy.Mil, amir@watson.ibm.com, perry@imsi.com, ipsec@ans.net In-Reply-To: <199504060442.AA31209@interlock.ans.net> from "bound@zk3.dec.com" at Apr 6, 95 00:37:01 am Organization: Trusted Information Systems, Inc. Glenwood, MD Phone: 301-854-6889 Coredump: Infocalypse Now!!! Content-Type: text Content-Length: 1537 Jim Bound writes: >Its real Ted and I also presented my ideas to Paul Lambert tonight and >no one or me is saying that strategically in the IETF we should not >specify confidentiality security. We must do this to have a secure >Internet. The question on the table is how do we do this tactically? "We had to shitcan security in order to save it"?? All that's happening here is that IETF is showing it has slowly evolved to the point where it, like other standards bodies, has become useless and entrenched, hopelessly fragmented by the desire for representation in advance of technology and vendor interest instead of improving the state of the art. It's too bad IETF didn't manage to learn from the PEM versus PGP debacle -- if the vendors have their way, it'll be the same thing all over again. mjr. ---- PS [...] >But being experienced in such a process I realize some will attack me >and even go to the extreme of offending me. Until this is over if this >happens too much an individual may find themselves sitting in a court room >explaining to a judge why they felt they had the right to defame or >abuse the rights of Jim Bound as an individual in a public forum. And I >have a set of family and many friends connected to the legal profession >who will do this for me for free for the right reasons. So please don't >push it if your in the U.S. anywhere. I think this kind of stuff is out of line and if you have a personal problem with someone on the list keep it personal rather than cluttering the airwaves. From ipsec-request@ans.net Thu Apr 6 15:14:17 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27414 (5.65c/IDA-1.4.4 for ); Thu, 6 Apr 1995 11:27:35 -0400 Received: by interlock.ans.net id AA20190 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 6 Apr 1995 11:21:37 -0400 Message-Id: <199504061521.AA20190@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 6 Apr 1995 11:21:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 6 Apr 1995 11:21:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 6 Apr 1995 11:21:37 -0400 To: "Marcus J. Ranum" Cc: bound@zk3.dec.com, tytso@MIT.EDU, efb@suned1.Nswses.Navy.Mil, amir@watson.ibm.com, perry@imsi.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Thu, 06 Apr 95 09:25:03 EDT." <7333.9504061325@illuminati> Date: Thu, 06 Apr 95 11:14:17 -0400 From: bound@zk3.dec.com X-Mts: smtp Marcus, > All that's happening here is that IETF is showing it has >slowly evolved to the point where it, like other standards bodies, >has become useless and entrenched, hopelessly fragmented by the >desire for representation in advance of technology and vendor >interest instead of improving the state of the art. Its not as it appears on this mail really. At all the meetings at least for IPv6 we have done real technical work and I can state for a fact the work being implemented by a few of us right now for IPv6 is good and evolved and will not get bogged down in politics. Seucurity has some legal issues as we build the words. And in IPv6 we are improving the state of the art and have already several times broken vendor interest for the sake of correct technology evolution. There are a lot of people coming to the IETF now though which I think is slowing down consensus. That could be an issue. > It's too bad IETF didn't manage to learn from the PEM >versus PGP debacle -- if the vendors have their way, it'll be >the same thing all over again. Wasn't one of the lessons mandating PEM did not work? > I think this kind of stuff is out of line and if you have a >personal problem with someone on the list keep it personal rather than >cluttering the airwaves. I agree. Just wanted to make my position clear. Sorry to all. /jim From ipsec-request@ans.net Thu Apr 6 15:48:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15607 (5.65c/IDA-1.4.4 for ); Thu, 6 Apr 1995 12:06:38 -0400 Received: by interlock.ans.net id AA11226 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 6 Apr 1995 11:46:04 -0400 Message-Id: <199504061546.AA11226@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 6 Apr 1995 11:46:04 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 6 Apr 1995 11:46:04 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 6 Apr 1995 11:46:04 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 6 Apr 1995 11:46:04 -0400 From: "Marcus J. Ranum" Subject: Re: IPv6 Security Last Call Initial Questions To: bound@zk3.dec.com Date: Thu, 6 Apr 1995 11:48:43 -0400 (EDT) Cc: ipsec@ans.net In-Reply-To: <9504061514.AA11430@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Apr 6, 95 11:14:17 am Organization: Trusted Information Systems, Inc. Glenwood, MD Phone: 301-854-6889 Coredump: Infocalypse Now!!! Content-Type: text Content-Length: 1885 I've been having some offline communication with Jim Bound and one of the things that's come out is that I don't think I was sufficiently clear about some of the problems regarding export control issues. Not speaking in an official capacity for TIS, it's still OK for me to observe that TIS has had a lot of involvement in export control issues. :) The other day I mentioned in my "paranoid" comments the possibility that law enforcement and intelligence may not want to see IPV6 deployed with even weak encryption for confidentiality. The other shoe is that if IPV6 has hooks in it for encryption - EVEN IF THE ENCRYPTION IS LEFT OUT - it falls under ITAR regulations for some interpretations of ITAR. The intelligence community in the past has taken a dim view of products that embody weak crypto but have "hooks" for strong crypto. I see no reason to believe they'll feel any differently about IPV6. They're not idiots and even if it only includes ROT-13 as the confidentiality algorithm, some interpretations of ITAR cover it. Getting a clear answer on these matters from the bureau of politico-military affairs at State Dept has sometimes been difficult. Generally, in the past, my understanding is that export permission needs to be requested for each implementation or each case of export. I suspect that blanket export ok for IPV6 with any confidentiality built into it at all is going to be a protracted battle. Someone with experience in export control regulations should start fighting it ASAP to get a feeling for what you're up against. I'm a bit of a paranoid but from here it looks like one of the major weapons in the export controllers arsenal is bureaucracy. If you play it their way, you have to jump through their hoops. Anyone who has done hoop-jumping for the intelligence community will tell you it's good exercise because there are a lot of hoops. mjr. From ipsec-request@ans.net Fri Apr 7 11:32:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25080 (5.65c/IDA-1.4.4 for ); Fri, 7 Apr 1995 11:32:02 -0400 Received: by interlock.ans.net id AA10268 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 7 Apr 1995 11:24:19 -0400 Message-Id: <199504071524.AA10268@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 7 Apr 1995 11:24:19 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 7 Apr 1995 11:24:19 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 7 Apr 1995 11:24:19 -0400 Date: Fri, 07 Apr 95 08:00:22 From: "Housley, Russ" Encoding: 722 Text To: ipsec@ans.net, hugo@watson.ibm.com Cc: jis@mit.edu, galvin@tis.com, burt@RSA.COM, matt@RSA.COM, mihir@watson.ibm.com Subject: Re: Proposals for key-ed MD5 Hugo: ... One advantage of (II) over the plain MD5(K|text|K) is that more than one iteration of MD5 takes place even in case text is very short. Moreover there is an implementation option of pre-computing MD5(K|1|0^383) and using the result as input to the ABCD registers of MD5; in this way the computation due to the prepended key is done only once per key. I like this. The precomputation is attractive, and one MD5 operation can be used to compute the integrity check value. In periperial hardware implementations, like PCMCIA cards, it is better to have one command do the whole thing. It simply avoids I/O through the relatively slow card interface. Russ From ipsec-request@ans.net Fri Apr 7 17:14:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04255 (5.65c/IDA-1.4.4 for ); Fri, 7 Apr 1995 17:14:55 -0400 Received: by interlock.ans.net id AA38178 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 7 Apr 1995 17:10:53 -0400 Message-Id: <199504072110.AA38178@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Fri, 7 Apr 1995 17:10:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 7 Apr 1995 17:10:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 7 Apr 1995 17:10:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 7 Apr 1995 17:10:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 7 Apr 1995 17:10:53 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 7 Apr 1995 17:10:53 -0400 To: ipsec From: Mark H Linehan/Watson/IBM Research Date: 7 Apr 95 17:10:05 Subject: Comments on latest IPSP drafts Mime-Version: 1.0 Content-Type: Text/Plain (I've been lurking on this list for the last year, but haven't had time to contribute until now. I hope to be more active in the future. I also hope these comments don't duplicate discussions at this week's IETF, which I was not able to attend.) These are comments on the 5 IPSP drafts that were posted a couple of weeks ago. I've reviewed and commented on these as a whole. - I suggest that there should be a discussion of the impact of IP fragmentation. In particular: (a) performance is affected since IP packets that already equal the MTU size will overflow with the addition of the AH or ESP data; (b) I think there should be an implementation note that the sender of an IPSP packet should make sure to put it through the fragmentation process, and the destination of an IPSP packet must reassemble it before processing the AH header or ESP payload. - The definition of "authentication" and "integrity" on page 1 of the architecture draft implies that the former is a superset of the latter. This is inconsistent with the usual terminology, which treats these as distinct concepts. - The architecture draft, and some of the others, refer to a number of terms that are neither defined in section 1.1 nor are common usage in the IP world. These should be explained and/or the discussion of them should be dropped. Examples are "security label" in section 1.2 of the architecture draft, "red/black separation" in sections 4.1 and 4.2 of the ESP draft, and "security level" and "multi-level security" in section 1.4 of the architecture draft. - Compartmented mode workstations, multi-level security, and security labels have not been discussed on this list as requirements for IPSP. I suggest that the discussion of these be moved from the earlier sections of the architecture paper to section 5, as with section 5.5 "Use in Compartmented or Multi-Level Networks." - Section 1.2 of the architecture draft repeats many of the same phrases in the discussion of AH versus ESP. Better to abstract out and make definitions of concepts such as "security gateway". - Page 12 of the architecture document and various other places require user-oriented keying. It's not at all clear what that means for (a) systems that don't have userids (e.g. Windows); (b) services that operate on behalf of multiple users (e.g. nfsd); (c) systems that forward data between interfaces. I think (c) is supposed to be excluded by the words "... traffic originating at that system," but those words are not repeated in the several places that require user-oriented keying. At the least, I think there should be some text discussing these issues. In general, the network layer does not logically have access to user-related information, and some implementations may find it difficult or impossible to fulfill this requirement. I suggest that IPSP should not (a) force implementations to violate the usual separation between network layers by requiring the IP layer to know the relationship between packets and users; and (b) should not rule out implementations that simply can't meet this requirement. - There has been some discussion that ICMP messages will be returned by destinations in some situations. These should be outlined in the architecture document. What about denial-of-service attacks? - Page 8 of the AH draft discusses an issue with ICMP. I find this paragraph confusing. If a system returns an ICMP packet, then it could authenticate (or encrypt) the ICMP packet itself. There should be no problem with the size of the ICMP packet itself. Of course the included copy of the original rejected packet may be truncated, making it impossible to authenticate or decrypt the rejected packet. I think that's what the paragraph is saying, but it's not very clear. Also, this paragraph really belongs in the architecture document. - There has been a lot of discussion about whether the DES-CBC transport should be required. I respectfully submit that there is a set of organizations and individuals who MUST (in a much more significant sense of "MUST") obey U.S. (and other nation's) laws and who will require an engineering solution to provide exportable encryption. Either this engineering group can provide that solution or someone will have to define an IPSECbis and an IPv6bis. The risk is fragmentation of standards. Since the set of people affected by the export laws is large, I argue that this working group should address the issue. - Regarding traffic analysis (section 3.4 of the architecture draft, and elsewhere): the ESP is helpful when used between two gateways. Someone snooping the traffic between the gateways can track the traffic pattern but can't see the source and destination addresses and ports of the packets that flow between hosts behind the gateways. Inject some additional fake traffic, and traffic analysis becomes much harder. - Some of the detail in section 4 of the AH document is superfluous and should be left to the individual transforms. In particular, the paragraphs that start with "If a block-oriented..." and "When a keyed ..." contains text that might not match some specific transforms. In fact, the description of the MD5 transform doesn't match that in the actual MD5 document. - The double-application of MD5 described in section 2 of the MD5 draft has a significant performance penalty. This is ironic given the discussion of performance in the immediately-preceding section. - Section 3.1 of the ESP draft says "... If no security association has been established, the value of this field shall be 0x00000000." When and why would this ever happen? In other contexts, these drafts claim that SPI zero is an error and should never be used. - Both the AH and ESP drafts have sections discussing security labels. I think these belong in section 5 of the architecture document. Similar with the text concerning multilevel security near the end of sections 4.1 and 4.2 of ESP. Also the discussion of security labels near the end of section 4 of the ESP draft. - Logging requirements are inconsistent among the documents. For example, sections 4.1 and 4.2 of ESP say that logging is a MUST in certain cases, but section 4 of the AH draft says SHOULD in similar cases. I suggest that logging is an implementation decision and/or configuration choice and hence should be described as SHOULD. - There's a stray reference to "Appendix A" near the end of the introductory part of section 3 of the ESP draft. - The paragraph starting "If the authentication process..." in section 4.3 of the ESP draft is confusing, at least to me. Please clarify. - Regarding the position of the Pad Length and Data Type fields in the DES-CBC draft: (a) why aren't these defined in the ESP draft since they are common to all transforms? Particularly the data type field since the tunnel/transport mode choice is itself defined as an attribute of ESP not of the DES-CBC transform. (Don't say that it would have screwed up the ESP header alignment; that's a poor reason to violate architectural clarity.) (b) Putting these at the end exacerbates the problem of truncated returned packets in ICMP messages. If these were near the beginning, you could decrypt whatever part of the returned packets you get. With the data type and pad length at the end, they'll be truncated first - and they are needed for the reverse transform. - What is the data type field value for transport mode? Sorry for the length of this note; I hope the compensation is thoroughness. From ipsec-request@ans.net Fri Apr 7 06:57:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28166 (5.65c/IDA-1.4.4 for ); Fri, 7 Apr 1995 18:03:19 -0400 Received: by interlock.ans.net id AA42356 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 7 Apr 1995 17:58:55 -0400 Message-Id: <199504072158.AA42356@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 7 Apr 1995 17:58:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 7 Apr 1995 17:58:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 7 Apr 1995 17:58:55 -0400 Date: Fri, 07 Apr 95 14:57:07 PST From: "burt" To: ipsec@ans.net, hugo@watson.ibm.com, "Housley, Russ" Cc: jis@mit.edu, galvin@tis.com, matt@RSA.COM, mihir@watson.ibm.com Subject: Re[2]: Proposals for key-ed MD5 Some notes on Russ's observation: There's no reason that hardware couldn't have MD5(K|MD5(K|text)) or whatever is chosen for keyed-hashing as a primitive, so it's still possible to do everything with one command. Also, the key K may be stored in the peripheral device, so some special handling will be required --- the MD5 primitive would not be enough, instead and MD5(stored key,.) primitive would be needed. However, it's nice to reduce the total number of primitives in a system, so reusing the same MD5 command for hashing as for keyed-hashing has its advantages. -- Burt ______________________________ Reply Separator _________________________________ Subject: Re: Proposals for key-ed MD5 Author: ,"Housley, Russ" at INTERNET Date: 4/7/95 8:00 AM Received: by ccmail from RSA.COM From housley@spyrus.com X-Envelope-From: housley@spyrus.com Received: from uucp13.netcom.com by RSA.COM with SMTP id AA22499; Fri, 7 Apr 95 08:20:35 PDT Received: by netcomsv.netcom.com with UUCP (8.6.9/SMI-4.1) id IAA03536; Fri, 7 Apr 1995 08:02:53 -0700 Received: from cc:Mail by spysouth.spyrus.com id AA797266822 Fri, 07 Apr 95 08:00:22 Date: Fri, 07 Apr 95 08:00:22 From: "Housley, Russ" Encoding: 722 Text Message-Id: <9503077972.AA797266822@spysouth.spyrus.com> To: ipsec@ans.net, hugo@watson.ibm.com Cc: jis@mit.edu, galvin@tis.com, burt@RSA.COM, matt@RSA.COM, mihir@watson.ibm.com Subject: Re: Proposals for key-ed MD5 Hugo: ... One advantage of (II) over the plain MD5(K|text|K) is that more than one iteration of MD5 takes place even in case text is very short. Moreover there is an implementation option of pre-computing MD5(K|1|0^383) and using the result as input to the ABCD registers of MD5; in this way the computation due to the prepended key is done only once per key. I like this. The precomputation is attractive, and one MD5 operation can be used to compute the integrity check value. In periperial hardware implementations, like PCMCIA cards, it is better to have one command do the whole thing. It simply avoids I/O through the relatively slow card interface. Russ From ipsec-request@ans.net Fri Apr 7 22:06:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05478 (5.65c/IDA-1.4.4 for ); Fri, 7 Apr 1995 18:08:46 -0400 Received: by interlock.ans.net id AA17504 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 7 Apr 1995 18:07:11 -0400 Message-Id: <199504072207.AA17504@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 7 Apr 1995 18:07:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 7 Apr 1995 18:07:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 7 Apr 1995 18:07:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 7 Apr 1995 18:07:11 -0400 To: Mark H Linehan/Watson/IBM Research Cc: ipsec Subject: Re: Comments on latest IPSP drafts In-Reply-To: Your message of "07 Apr 1995 17:10:05." <199504072110.AA38178@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 07 Apr 1995 18:06:49 -0400 From: "Perry E. Metzger" I thought I'd explain a bit from the drafts here, although I don't want to open up a big discussion of any of these topics... Mark H Linehan/Watson/IBM Research says: > - Page 12 of the architecture document and various other places require > user-oriented keying. It's not at all clear what that means New language was proposed in Danvers that has eliminated most of the objections other people have made to this section. > - Regarding the position of the Pad Length and Data Type fields in > the DES-CBC draft: (a) why aren't these defined in the ESP draft > since they are common to all transforms? Because they aren't common. The location of the type field *will* change from transform to transform, and padding is not needed for all ciphers -- DES in CFB or stream ciphers need no padding. > (b) Putting these at the end exacerbates the problem of truncated > returned packets in ICMP messages. If these were near the > beginning, you could decrypt whatever part of > the returned packets you get. Not with all ciphers, and besides that, the important part is the SPI which will be returned. If you don't put the fields at the end you pay a huge packet bloat penalty if you want to aign the fields, which is why we do things the way we do. Since we are optimized for the common case and we have enough information in the non-common case I think things are just fine. Perry From ipsec-request@ans.net Fri Apr 7 13:49:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25026 (5.65c/IDA-1.4.4 for ); Fri, 7 Apr 1995 18:53:27 -0400 Received: by interlock.ans.net id AA11291 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 7 Apr 1995 18:49:40 -0400 Message-Id: <199504072249.AA11291@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 7 Apr 1995 18:49:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 7 Apr 1995 18:49:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 7 Apr 1995 18:49:40 -0400 Date: Fri, 7 Apr 1995 18:49:36 +0500 From: Theodore Ts'o To: Mark H Linehan/Watson/IBM Research Cc: ipsec In-Reply-To: linehan@watson.ibm.com's message of 7 Apr 95 17:10:05, <199504072110.AA38178@interlock.ans.net> Subject: Re: Comments on latest IPSP drafts Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1780 From: Mark H Linehan/Watson/IBM Research Date: 7 Apr 95 17:10:05 - There has been a lot of discussion about whether the DES-CBC transport should be required. I respectfully submit that there is a set of organizations and individuals who MUST (in a much more significant sense of "MUST") obey U.S. (and other nation's) laws and who will require an engineering solution to provide exportable encryption. This is a common fallacy. There is no requirement that vendors MUST provide exportable encryption. Vendors can simply not export their products outside the U.S., or provide an alternative product which simply does not provide encryption at all. This topic was discussed at the Security Area Advisory Group at the most recent IETF meeting, and the consensus of the SAAG (by a strong majority) was that the standard should require encryption, and strong encryption at that (recognizing that some vendors may decide to only provide IPv6, a.b.e. --- "all but encryption") but that this since this was the technically correct thing to do, we shouldn't back down. The area director that asked the group for their opinion about what what our recommendation should be if the IESG pushed back on requiring strong encryption ---- should we mandate encryption, but specify a weak encryption algorithm, or make encryption optional, but if you do implement encryption, you must do strong encryption? The overwhelming sense of the group was that given those two choices, it was better to make encryption optional, but make DES mandatory if you do implement encryption, instead of making encryption mandatory, and but specifying a crippled encryption system, since that would only give users a false sense of security. - Ted From ipsec-request@ans.net Sat Apr 8 02:27:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24066 (5.65c/IDA-1.4.4 for ); Fri, 7 Apr 1995 22:34:53 -0400 Received: by interlock.ans.net id AA34205 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 7 Apr 1995 22:28:15 -0400 Message-Id: <199504080228.AA34205@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 7 Apr 1995 22:28:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 7 Apr 1995 22:28:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 7 Apr 1995 22:28:15 -0400 From: Steve Bellovin To: ipsec@ans.net Subject: problems with ESP with host-pair keying Date: Fri, 07 Apr 1995 22:27:36 -0400 Sender: smb@research.att.com As discussed at the IETF meeting, the proposed ESP protocol is insecure if a single key is used for all connections between a given pair of hosts and the attacker has access to that pair. The flaw can be exploited to read any encrypted data, and possibly to insert data into encrypted sessions. The flaw results from the nature of cipher block chaining (CBC), the block cipher mode most natural for use with IP, and the one specified (with DES) as the base standard. Briefly, if a block is damaged in transmission, on decryption it and the following block will be garbled by the decryption process, but all subsequent blocks will be decrypted correctly. (For more details on this, see just about any cryptography book. Davies and Price's ``Security for Computer Networks'' gives a particularly good treatment of this issue.) The attack works by cutting and pasting cipher blocks. The attacker sends a UDP packet to the other machine, and picks up that packet with a monitoring machine. All of the encrypted portion except for the UDP header (and anything leading up to it) is discarded. When another encrypted packet is sent between the same pair of machines, the encrypted portion is glued onto the encrypted UDP header and reinjected onto the net. The receiving kernel will decrypt it -- it's using the same key -- and as long as no integrity check was specified, the packet will be passed up to user level. A necessary and sufficient fix is to change ESP to mandate integrity- checking with all vulnerable encryption modes. Using per-user keying or per-connection keying will help, but it is not in general sufficient, since system services such as NFS remain vulnerable. I hope to have some concrete recommendations for a change within the next few days. My slides are at ftp://ftp.research.att.com/dist/smb/hostpair.encrypt.ps --Steve Bellovin From ipsec-request@ans.net Sat Apr 8 09:24:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15705 (5.65c/IDA-1.4.4 for ); Sat, 8 Apr 1995 13:31:25 -0400 Received: by interlock.ans.net id AA34159 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 8 Apr 1995 13:24:35 -0400 Message-Id: <199504081724.AA34159@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 8 Apr 1995 13:24:35 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 8 Apr 1995 13:24:35 -0400 Date: Sat, 8 Apr 95 13:24:32 EDT From: hugo@watson.ibm.com To: IPSEC@ans.net Cc: smb@research.att.com, ROGAWAY@CS.UCDAVIS.EDU Subject: comments on drafts (re: Bellovin, Rogaway) This note is to be considered as part of the "last call comments" on the security drafts. The recent note by Steve Bellovin on attacks on ESP are a good example of the fallacy behind the notion that encryption functions provide for integrity/authenticity/authentication of information. This fallacy is actually supported by the wording in some of the drafts under consideration. I hope that with the changes that Steve will propose, part of these issues will be solved. Still it is necessary to "clean" the architecture document (draft-ietf-ipsec-arch-00.txt) from any wording suggesting the above false implication. For details on these issues (and others) I recommend reading the comments sent to this list by Phil Rogaway on 4/4 (subject: IPSEC (comments on Internet drafts) ) In particular, I recommend reflecting in the current drafts what Rogaway calls Recommendation 1, 2 and 3 (all related to the above issue). I believe that Steve's recommendation of mandating message authentication also in ESP will, in particular, resolve recommendation 2. Other recommendations of Phil require serious consideration (although some of them, e.g. use of triple-DES as default, were already considered and rejected by this WG; and others, e.g. recomendation 8, are too premature to be adopted now). In addition to the above, I particularly recommend following recommendations 5 and 10, that deal with the way in which basic crypto transforms should be specified in documents. Hugo From ipsec-request@ans.net Sun Apr 9 19:36:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27547 (5.65c/IDA-1.4.4 for ); Sun, 9 Apr 1995 15:40:19 -0400 Received: by interlock.ans.net id AA26602 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 9 Apr 1995 15:36:27 -0400 Message-Id: <199504091936.AA26602@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 9 Apr 1995 15:36:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 9 Apr 1995 15:36:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 9 Apr 1995 15:36:27 -0400 To: ipsec Subject: Re: Comments on latest IPSP drafts In-Reply-To: Your message of "07 Apr 1995 17:10:05." <199504072110.AA38178@interlock.ans.net> Date: Sun, 09 Apr 1995 15:36:20 -0400 From: "Donald E. Eastlake 3rd" I haven't been commenting hardly at all so I won't be suprised if my comments at this late date don't have much effect. Still, I thought I'd toss them in. (Mark: hope you don't mind if I use parts of your message as a framework) From: Mark H Linehan/Watson/IBM Research To: ipsec }... } }- I suggest that there should be a discussion of the impact of IP }fragmentation. In particular: (a) performance is affected since IP packets }that already equal the MTU size will overflow with the addition of the AH or }ESP data; (b) I think there should be an implementation note that the sender of }an IPSP packet should make sure to put it through the fragmentation process, }and the destination of an IPSP packet must reassemble it before processing the }AH header or ESP payload. I actually think that any mature encryption standard has to include compression. It's one of the clear superiorities of PGP over PEM. But I recognize that most people consider it some sort of patent quirmire. Still, I hope the next generation of transformations include compression. }- The definition of "authentication" and "integrity" on page 1 of the }architecture draft implies that the former is a superset of the latter. This }is inconsistent with the usual terminology, which treats these as distinct }concepts. But isn't the usual terminology wrong in this regard? How can you determine that a message is authentic if you can't tell that it has been changed (don't have integrity)? }... } }- Page 12 of the architecture document and various other places require }user-oriented keying. It's not at all clear what that means for (a) systems }that don't have userids (e.g. Windows); (b) services that operate on behalf of }multiple users (e.g. nfsd); (c) systems that forward data between interfaces. }I think (c) is supposed to be excluded by the words "... traffic originating at }that system," but those words are not repeated in the several places that }require user-oriented keying. At the least, I think there should be some text }discussing these issues. } }In general, the network layer does not logically have access to user-related }information, and some implementations may find it difficult or impossible to }fulfill this requirement. I suggest that IPSP should not (a) force }implementations to violate the usual separation between network layers by }requiring the IP layer to know the relationship between packets and users; and }(b) should not rule out implementations that simply can't meet this requirement. Maybe the wording need to be cleared up and maybe there are dedicated systems where this doesn't apply but the ability to use different keys on different conversations is essential. In general, the IETF concentrates on the bits on the wire while giving freedom for different arrangements within "operating systems" and the like. "Levels" a la OSI may be a useful model in some cases but they should be an aid to design, not a straight jacket. Some conversations, like NTP or routing, may be host level and servered apropriately by host level keys. But IPSEC will not have done its job if it can't stop the endless stream of end to end interactive application level security protocols (telnet, ftp, etc., etc.). (Note: this remark does not apply for store and forward services such as Mail, DNS, and HTTP which can not be adequately served by a simple "connection" oriented security protocol.) It should be possible on multi-user systems for the keying to authenticate different users and processes, even if this is just done in some cases by letting an application do the work itself. Seems to me that a "Windows" system should have separate keys for different services it might offer so that if host A had several logical connections up with Windows machine B, one for ftp, one for a telnet session, one for news transfer, etc., they would be separately keyed. Really, as long as a system is set up so there can be different keys, they most of the complexity here is at the session keying level, not in the packet formats. }... } }- There has been a lot of discussion about whether the DES-CBC transport should }be required. I respectfully submit that there is a set of organizations and }individuals who MUST (in a much more significant sense of "MUST") obey U.S. }(and other nation's) laws and who will require an engineering solution to }provide exportable encryption. Either this engineering group can provide that }solution or someone will have to define an IPSECbis and an IPv6bis. The risk }is fragmentation of standards. Since the set of people affected by the export }laws is large, I argue that this working group should address the issue. There are also lots of people that need to communicate securely within the United States and lots of people outside the United States unaffected by the US export laws who need to communicate securely. If someone want to define an insecure procotol that is freely exportable from the US, they certainly can but I would recommend that anyone who wants to communicate securly not use such an insecure protocol. It would certainly be a bad idea for the IETF to endorse such an insecure protocol as providing people with security. In fact, my understanding of the current situtaion is that, while individual export approval is required, it is easy to get permission to export DES-CBC confidentiality from the US to any US company including any US subsidiary abroad unless it is in one of a few countries that are specially restricated. People who want security need to use strong algorithms. I can't see why adopting a strong algorithm would cause anyone any difficult in secure communications. If they need the protocol implemented some place to which it can not be exported from the US, they will be trivially able to get it from elsewhere. All levels of the IETF has considered this problem and the strong consensus in the IPng working group, the IESG, the IETF plenary, etc., etc., has consistently been that the IETF standard should require strong security. }... Donald From ipsec-request@ans.net Mon Apr 10 16:34:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22857 (5.65c/IDA-1.4.4 for ); Mon, 10 Apr 1995 13:01:08 -0400 Received: by interlock.ans.net id AA28289 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 10 Apr 1995 12:34:48 -0400 Message-Id: <199504101634.AA28289@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 10 Apr 1995 12:34:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 10 Apr 1995 12:34:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 10 Apr 1995 12:34:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 10 Apr 1995 12:34:48 -0400 X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Apr 1995 12:34:27 -0400 To: "Donald E. Eastlake 3rd" , ipsec From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: Comments on latest IPSP drafts At 03:36 PM 4/9/95 -0400, Donald E. Eastlake 3rd wrote: > >I haven't been commenting hardly at all so I won't be suprised if my >comments at this late date don't have much effect. Still, I thought >I'd toss them in. (Mark: hope you don't mind if I use parts of your >message as a framework) > >From: Mark H Linehan/Watson/IBM Research > >To: ipsec > >}... >} >}- I suggest that there should be a discussion of the impact of IP >}fragmentation. In particular: (a) performance is affected since IP packets >}that already equal the MTU size will overflow with the addition of the AH or >}ESP data; (b) I think there should be an implementation note that the sender of >}an IPSP packet should make sure to put it through the fragmentation process, >}and the destination of an IPSP packet must reassemble it before processing the >}AH header or ESP payload. > >I actually think that any mature encryption standard has to include >compression. It's one of the clear superiorities of PGP over PEM. But >I recognize that most people consider it some sort of patent quirmire. >Still, I hope the next generation of transformations include compression. I think that minimally some reference to this is needed in the ESP documents. Even the AH can cause problems with fragmentation, but my real concern is ESP. Afterall, once encrypted == not compressable, right? So some reference is needed to this and perhaps a way to negotiate a compression scheme is needed in Photuris I(another parameter?). Also as a minimum, wasn't there some work done in the PPPwg for compression of PPP packers? Cannot that be lifted bodily into ESP? Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Mon Apr 10 19:24:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23003 (5.65c/IDA-1.4.4 for ); Mon, 10 Apr 1995 15:46:11 -0400 Received: by interlock.ans.net id AA29044 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 10 Apr 1995 15:24:46 -0400 Message-Id: <199504101924.AA29044@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 10 Apr 1995 15:24:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 10 Apr 1995 15:24:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 10 Apr 1995 15:24:46 -0400 Date: Mon, 10 Apr 1995 12:24:40 -0700 From: Hilarie Orman To: linehan@watson.ibm.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199504072110.AA38178@interlock.ans.net> Subject: Re: Comments on latest IPSP drafts >I suggest that there should be a discussion of the impact of IP >fragmentation. In particular: (a) performance is affected since IP packets >that already equal the MTU size will overflow with the addition of the AH or >ESP data; (b) I think there should be an implementation note that the sender of >an IPSP packet should make sure to put it through the fragmentation process, >and the destination of an IPSP packet must reassemble it before processing the >AH header or ESP payload. In our prototyping of an IP security layer, we approached this by having the sender's query for the MTU be intercepted by the security layer, which subtracts the header lengths from the actual network MTU. The sender thus learns how much payload is available. The implementation of security as a layer makes the frag/reassembly constraint natural and obvious. From ipsec-request@ans.net Mon Apr 10 05:54:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15628 (5.65c/IDA-1.4.4 for ); Mon, 10 Apr 1995 16:32:45 -0400 Received: by interlock.ans.net id AA16611 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 10 Apr 1995 15:54:39 -0400 Message-Id: <199504101954.AA16611@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 10 Apr 1995 15:54:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 10 Apr 1995 15:54:39 -0400 Date: Mon, 10 Apr 95 12:54:34 PDT From: rogaway@cs.ucdavis.edu (Phil Rogaway) To: smb@research.att.com Subject: Bellovin's attack Cc: ipsec@ans.net Hi, Steve, 1. PROBLEM I've read your note and the foils you made available. Your attack is good. If I understand, the following typifies the problem you've found: - $M_i^a$ is machine $i$ with secret key $a$; - $U_i$ is user $i$; - $E$ is the adversary. E | a \|/ a M_1 -----------------> M_2 / \ / \ E = U_1 U_2 E = U_3 U_4 Now obviously if $E$ breaks open the boundary of host $M_1$ or $M_2$, then there is nothing we can do; $E$ has $a$. So the goal is that, if $M_1$ and $M_2$ have NOT been compromised, then the privacy (for ESP) and authenticity (for AH) should NOT be compromised (by $E$) in communications between $U_2$ and $U_4$. Now even the "ideal" encryption (a one-time pad $a$) effectively gives $E$ an encryption/decryption oracle, $E_a(.), D_a(.)$. Thus your attack does NOT represent a problem with the encryption mechanism; it's a problem with the way it's (proposed to be) used. Now you might try to deny $E$ access to an $(E_a(.), D_a(.))$-oracle -- e.g., you could say that the ciphertext produced by $U_i$ for $U_j$ is _______________________ / \|/ E'_aa' (x) = E_a(x) . MAC_a'(U_i. U_j + ). But such a thing doesn't work: the adversary still has her encryption oracle (and therefore a decryption oracle for perfectly-good encryption mechanisms). Inherently, if $M_i$ encrypts all $M_1 -> $M_2$ traffic with a the same key, there will be no reason to believe that $E$ can not recover plaintext $U_2 -> U_4$ traffic. 2. SOLUTION: Proper key-separation $M_k$ should NOT be using the same key to to protect the communications between distinct $(U_i, U_j)$'s. Instead, for host-pair keying, you have a SINGLE host-pair SESSION key $a$ between hosts $M_1$ and $M_2$; but then the OPERATIONAL key used for communication from $U_i$ to $U_j$ should be a KEY VARIANT $h(U_1,U_2)$ -- not the session key $a$. Actually, to ensure proper mechanism independence, the operational key for transform $T$ used for communication from $U_1$ to $U_2$ should be key variant $h(T,U_1,U_2)$. Here, $T$ is a registered identifier associated to the transform (and also including parameter values for the transform); and $h$ is something like a cryptographic hash function (e.g., MD5). The key distribution mechanism should not worry about its users, and the transforms should not worry about theirs. This simplify is accomplished with key separation. Regards, Phil Rogaway From ipsec-request@ans.net Mon Apr 10 21:03:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17320 (5.65c/IDA-1.4.4 for ); Mon, 10 Apr 1995 17:22:55 -0400 Received: by interlock.ans.net id AA35329 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 10 Apr 1995 17:09:18 -0400 Message-Id: <199504102109.AA35329@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 10 Apr 1995 17:09:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 10 Apr 1995 17:09:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 10 Apr 1995 17:09:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 10 Apr 1995 17:09:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 10 Apr 1995 17:09:18 -0400 Date: Mon, 10 Apr 1995 14:03:08 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: rogaway@cs.ucdavis.edu Subject: Re: Bellovin's attack Cc: ipsec@ans.net, smb@research.att.com X-Sun-Charset: US-ASCII Phil, Your suggested solution to Steve's attack, i.e., > > 2. SOLUTION: Proper key-separation > > $M_k$ should NOT be using the same key to to protect the communications > between distinct $(U_i, U_j)$'s. Instead, for host-pair keying, you have a > SINGLE host-pair SESSION key $a$ between hosts $M_1$ and $M_2$; but then > the OPERATIONAL key used for communication from $U_i$ to $U_j$ should be > a KEY VARIANT $h(U_1,U_2)$ -- not the session key $a$. > > Actually, to ensure proper mechanism independence, the operational > key for transform $T$ used for communication from $U_1$ to $U_2$ should be > key variant $h(T,U_1,U_2)$. Here, $T$ is a registered identifier associated to > the transform (and also including parameter values for the transform); and > $h$ is something like a cryptographic hash function (e.g., MD5). The key > distribution mechanism should not worry about its users, and the transforms should > not worry about theirs. This simplify is accomplished with key separation. does not work in certain operational configurations. For example, if an application, such as NFS, effectively multiplexes user traffic to file systems over a single "session", separate session keys per user isn't possible. Another example of this occurs when an encrypting security gateway is used to front-end private LANs so that their inter-LAN traffic may be encrypted as it travels over the internet. The fix that Steve suggests, i.e., require that encrypted data is always integrity checked, prevents his attack and also solves the operational problems described above. Regards, Dan From ipsec-request@ans.net Mon Apr 10 23:49:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17756 (5.65c/IDA-1.4.4 for ); Mon, 10 Apr 1995 21:54:43 -0400 Received: by interlock.ans.net id AA35765 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 10 Apr 1995 21:51:54 -0400 Message-Id: <199504110151.AA35765@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 10 Apr 1995 21:51:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 10 Apr 1995 21:51:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 10 Apr 1995 21:51:54 -0400 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 10 Apr 1995 21:51:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 10 Apr 1995 21:51:54 -0400 Date: 10 Apr 95 18:49:00 -0500 To: ipsec@ans.net Cc: ipsec@ans.net Subject: IPSEC Comments Attached are my comments on the 5 IPSEC documents draft-ietf-ipsec-arch-00.txt draft-ietf-ipsec-esp-00.txt draft-ietf-ipsec-esp-des-cbc-03.txt draft-ietf-ipsec-auth-00.txt draft-ietf-ipsec-ah-md5-02.txt Regards, Paul A. Lambert -------------------------------- Comments on the March 1995 IPSEC Last Call The following are comments on the March 1995 last call documents in the IPSEC working group: draft-ietf-ipsec-arch-00.txt draft-ietf-ipsec-esp-00.txt draft-ietf-ipsec-esp-des-cbc-03.txt draft-ietf-ipsec-auth-00.txt draft-ietf-ipsec-ah-md5-02.txt Notes on Comment Types: Major Technical - indicates that the documented flaw MUST be fixed prior to advancing the specification. Minor Technical - indicates that the documented flaw SHOULD be fixed prior to advancing the specification. Major Editorial - indicates that the editorial recommendations MUST be made prior to advancing the specification Minor Editorial - editorial suggestions that SHOULD be incorporated. -------------------------------------------- Comment Type: Major Editorial Location: all Comments: The draft specification have redefined the Security Association Identifier (SAID) field to be a "Security Parameter Index" field. There is considerable existing architectural work in others standards activities defining the SAID and its usage. The documents would benefit from an alignment with this work. Recommendation: Change all occurrences of SPI to SAID. Use SAID definition from IEEE 802.10. -------------------------------------------- Comment Type: Major Technical Location: draft-ietf-ipsec-esp-00.txt section 3.1 Comments: The reserved ranges of the SPI/SAID field are defined as: > The set of SPI values in the range 0x00000001 though 0x000000FF > are reserved to the Internet Assigned Numbers Authority (IANA) for > future use. Reserved values have been proposed for several purposes including some for multicast mechanisms. A larger range should be provided for reserved/experimental usage. Recommendation: Only the SPI/SAID values between 0x00000100 and 0x07FFFFFF should be allowed for pair-wise SAID assignment. All others (should be reserved for now. Replace text with: The Security Association Identifier (SAID) field is a 32 bit value identifying the security association for the datagram. The SAID value of 0x00000000 is used to indicate that no SAID is available for the source and destination. SAID Value SAID Usage ---------------------------------------------------- 0x00000000 Used to indicate no SAID assigned to destination. 0x00000001 to 0x000000FF Reserved for future use. 0x00000100 to 0x07FFFFFF Selected by implementations to identify a unique Security Association. 0x08000000 to 0xFFFFFFFF Reserved for future use. The reserved SAID values are assigned by the Internet Assigned Numbers Authority (IANA). A reserved SAID value will not normally be assigned by IANA unless the use of that particular assigned SPI value is openly specified in an RFC. -------------------------------------------- Comment Type: Major Technical Location: draft-ietf-ipsec-esp-00.txt section 3.1 Comments: The use of the zero SAID is not adequately defined. More detail on it's usage should be provided, or the mechanism should be removed. When the SAID is zero, what does the rest of the packet look like? What is the processing that accompanies this packet. When is a zero SAID sent (versus a ICMP message). Recommendation: Define the zero SAID to be experimental for use as a no SA indicator. Add usage text or remove mechanisms after interoperability testing. -------------------------------------------- Comment Type: Major Technical Location: draft-ietf-ipsec-arch-00.txt draft-ietf-ipsec-esp-00.txt Comments: The ESP/IPSP specification do not adequately document the way the protocol must examine all traffic passing through the network layer. This "packet filtering" functionality is essential to a "strict" security policy that limits non-protected communications. Recommendation: Include a description of the filtering functionality in ESP/IPSP and/or the architecture document. A possible figure for this description is: +------+ +-----+ +-----+ +-----+ +------+ +-----+ +-----+ +-----+ |Telnet| | FTP | | TFTP| ... | ... | |Telnet| | FTP | | TFTP| ... | ... | +------+ +-----+ +-----+ +-----+ +------+ +-----+ +-----+ +-----+ | | | | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | TCP | | UDP | ... | ... | | TCP | | UDP | ... | ... | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | +--------------------------+----+ - - - - | - - - - | - - - - | + | IP Security Protocol | [f] [f] [f] | +-------------------------------+ - - - - | - - - - | - - - - | + | | | | +---------------------------------------------------------------------+ | Internet Protocol | +---------------------------------------------------------------------+ | +-----------------------------------------------------------------+ | Local Network Protocol | +-----------------------------------------------------------------+ -------------------------------------------- Comment Type: Major Editorial Location: draft-ietf-ipsec-esp-00.txt draft-ietf-ipsec-esp-des-cbc-03.txt Comments: The splitting of the mandated transforms from the "esp" specification makes the documents more difficult to read. The base protocol specification should include the mandated transform(s) and serve as the template for future optional transform specifications. Recommendation: Merge transforms documented in "draft-ietf-ipsec-esp-des-cbc- 03.txt" into appendix of "draft-ietf-ipsec-esp-00.txt". -------------------------------------------- Comment Type: Major Technical Location: draft-ietf-ipsec-esp-00.txt draft-ietf-ipsec-esp-des-cbc-03.txt Comments: The current mandated ipsec-esp security transform only provides confidentiality services. This transform is subject to possible threats based on the replay, reflection, or modification of packets. The "mandatory transform" should include integrity services. Recommendation: In the merged ESP/IPSP specification include a mandatory transformation that provides both confidentiality and integrity services. As a suggestion, this transformation should be based on DES-CBC with either a ones complement (Fletcher) checksum or use of MD5. -------------------------------------------- Comment Type: Major Editorial Location: draft-ietf-ipsec-esp-00.txt draft-ietf-ipsec-esp-des-cbc-03.txt Comments: The working group has had the goal of providing a simple encapsulation mechanisms that supports various algorithms and security services. The goals had been to document baselines for security transforms to support confidentiality, integrity, and confidentiality with integrity. Recommendation: In the merged ESP/IPSP specification three transformations should be described: DES-CBC, Keyed-MD5 (or other integrity only), and DES- CBCwith Integrity. At a minimum, the DES-CBCwith Integrity should be mandated as a MUST implement (given the current IETF direction for security in IPv6). -------------------------------------------- Comment Type: Major Editorial Location: draft-ietf-ipsec-arch-00.txt section 6 Comments: Unnecessary editorial Recommendation: Remove last three paragraphs. Replace with: Protection from traffic analysis is outside the scope of this specification. -------------------------------------------- Comment Type: Minor Editorial Location: draft-ietf-ipsec-arch-00.txt (section 1.1 par. 1) Comments: Should reference ISO 7498/2 Recommendation: add ISO 7498/2 to references -------------------------------------------- From ipsec-request@ans.net Tue Apr 11 10:32:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17380 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 06:35:36 -0400 Received: by interlock.ans.net id AA37261 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 06:32:22 -0400 Message-Id: <199504111032.AA37261@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 11 Apr 1995 06:32:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 06:32:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 06:32:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 06:32:22 -0400 X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Apr 1995 06:32:03 -0400 To: Hilarie Orman , linehan@watson.ibm.com From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: Comments on latest IPSP drafts Cc: ipsec@ans.net At 12:24 PM 4/10/95 -0700, Hilarie Orman wrote: >>I suggest that there should be a discussion of the impact of IP >>fragmentation. In particular: (a) performance is affected since IP packets >>that already equal the MTU size will overflow with the addition of the AH or >>ESP data; (b) I think there should be an implementation note that the sender of >>an IPSP packet should make sure to put it through the fragmentation process, >>and the destination of an IPSP packet must reassemble it before processing the >>AH header or ESP payload. > >In our prototyping of an IP security layer, we approached this by >having the sender's query for the MTU be intercepted by the security >layer, which subtracts the header lengths from the actual network MTU. >The sender thus learns how much payload is available. The >implementation of security as a layer makes the frag/reassembly >constraint natural and obvious. But this does not help a user of a PPP dialup link that was getting 24Kb throughput from a V.32bis modem and now is getting 14Kb. That is a REAL degredation of throughput, much worst than what we have been talking about for Ethernet based users. And remember, there is also ISDN compression... Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Tue Apr 11 15:55:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12663 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 12:02:42 -0400 Received: by interlock.ans.net id AA37871 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 11:55:58 -0400 Message-Id: <199504111555.AA37871@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 11:55:58 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 11:55:58 -0400 Date: Tue, 11 Apr 1995 11:55:52 -0400 From: ups@tree.com (Stephan Uphoff) To: ipsec@ans.net Subject: Problems with ICMPs X-Sun-Charset: US-ASCII I am starting on a public domain implementation of the Ah and ESP Protocol for Unix System V Systems (Solaris 2.X) . Because I can not change the IP layer, I will position the security layer between the ip layer and the network devices (dlpi). This will force my implementation to act like a encrypting firewall as described in ipsec-arch section 5.1 . What should be done by a encrypting firewall when it receives an ICMP datagram like "source quench" or "message to long" from a router in respones to an encrypted datagram? I am at the moment not concerned about security issues arrising from ICMPs but on how to handle them transparent in a normal way. All information that can be read from a ICMP datagram is the destination address, the source address and the SAID of the IP packet that caused the ICMP. This does nor provide enough information for the firewall to generate a normal ICMP datagram to pass it to the source of the offending datagram. The only solution I see is that the encrypting firewall stores all datagrams (at least the IP header and the first 64 bytes) it encrypts for a limited time ( 2 * TTL ?) and tries to match incomming ICMPs with the stored datagrams. If a match is found the ICMP datagram is modified and passed on. Modification of the ICMP "message to long" should include adjusting the "Next-Hop-MTU field" to allow "Path MTU Discovery" to work. This solution would handle ICMP transparent to the existing IP definition. But I think even considering some optimizations for protocols like TCP it is to expensive. It will also work for simple firewall configurations only. I believe the same problem exists even when putting the security layer between the protocols TCP,UDP and the IP layer. Is there an easier solution to the problem? Or even better - did I miss something and there is no problem ? Stephan From ipsec-request@ans.net Tue Apr 11 15:31:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17216 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 12:30:49 -0400 Received: by interlock.ans.net id AA41410 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 12:24:49 -0400 Message-Id: <199504111624.AA41410@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 12:24:49 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 12:24:49 -0400 Date: Tue, 11 Apr 1995 11:31:57 -0400 From: rubin@mgoblue.bellcore.com (Aviel D Rubin) To: ipsec@ans.net Subject: Re: Bellovin's attack and others like it I think that just because there might be a solution to the specific attack suggested by Steve doesn't mean that this solution is general enough for all attacks, as pointed out by Dan Nessett. Thus, I agree that requiring an integrity check on all encrypted data is a must. On another note, I think it is vital to include all types of key management schemes for IPSEC. For example, if I already have an installed Kerberos base in my organization, and I want to use it for key management for IP, there should be nothing in the standard keeping me from doing this. Now, I have a totally different question. At the IETF in Danvers, I asked many people that are implementing key management, how do you do key management over IP when your policy indicates that all IP traffic must be encrypted? The answer I got from everyone is that you somehow mark the key management packets so that they are allowed. Doesn't that violate the independence of the layers in the network? If I can mark packets as regular IP or key management IP, where do I do this marking? In the kernel? Nobody I talked to has actually implemented key management, encapsulation and a policy. Shouldn't there be something in the standard that mandates or recommends how to achieve all three? Avi Rubin ********************************************************************* Aviel D. Rubin Email: rubin@faline.bellcore.com Bellcore (MRE-2M354) ftp://thumper.bellcore.com/pub/rubin/rubin.html 445 South St. Morristown, NJ 07960 Voice: +1 201 829 4105 USA FAX: +1 201 829 2645 From ipsec-request@ans.net Tue Apr 11 13:02:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23436 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 13:02:14 -0400 Received: by interlock.ans.net id AA38422 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 12:59:15 -0400 Message-Id: <199504111659.AA38422@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Tue, 11 Apr 1995 12:59:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 11 Apr 1995 12:59:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 11 Apr 1995 12:59:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 12:59:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 12:59:15 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 12:59:15 -0400 To: ipsec Cc: "Donald E. Eastlake 3rd" From: Mark H Linehan/Watson/IBM Research Date: 11 Apr 95 12:58:15 Subject: Re: Comments on latest IPSP drafts Mime-Version: 1.0 Content-Type: Text/Plain Donald Eastlake commented ("|") on some of my original comments ("}"). I'd like to respond: } }- I suggest that there should be a discussion of the impact of IP }fragmentation. In particular: (a) performance is affected since IP packets }that already equal the MTU size will overflow with the addition of the AH or }ESP data; (b) I think there should be an implementation note that the sender of }an IPSP packet should make sure to put it through the fragmentation process, }and the destination of an IPSP packet must reassemble it before processing the }AH header or ESP payload. | I actually think that any mature encryption standard has to include | compression. It's one of the clear superiorities of PGP over PEM. | But | I recognize that most people consider it some sort of patent quirmire. | Still, I hope the next generation of transformations include | compression. I agree that there needs to be an IP compression function. It could be incorporated into an ESP transform, but it makes more sense as another payload type. That way we could specify compression functions independently of encryption functions and could easily compose combinations of the two. }- The definition of "authentication" and "integrity" on page 1 of the }architecture draft implies that the former is a superset of the latter. This }is inconsistent with the usual terminology, which treats these as distinct }concepts. | But isn't the usual terminology wrong in this regard? How can you | determine that a message is authentic if you can't tell that it has | been changed (don't have integrity)? I've re-read Phil Rogaway's comments on this point and I think I agree with him. }... } }- Page 12 of the architecture document and various other places require }user-oriented keying. It's not at all clear what that means for (a) systems }that don't have userids (e.g. Windows); (b) services that operate on behalf of }multiple users (e.g. nfsd); (c) systems that forward data between interfaces. }I think (c) is supposed to be excluded by the words "... traffic originating at }that system," but those words are not repeated in the several places that }require user-oriented keying. At the least, I think there should be some text }discussing these issues. } }In general, the network layer does not logically have access to user-related }information, and some implementations may find it difficult or impossible to }fulfill this requirement. I suggest that IPSP should not (a) force }implementations to violate the usual separation between network layers by }requiring the IP layer to know the relationship between packets and users; and }(b) should not rule out implementations that simply can't meet this requirement. | Maybe the wording need to be cleared up and maybe there are | dedicated | systems where this doesn't apply but the ability to use different keys | on different conversations is essential. In general, the IETF | concentrates on the bits on the wire while giving freedom for | different arrangements within "operating systems" and the like. | "Levels" a la OSI may be a useful model in some cases but they | should | be an aid to design, not a straight jacket. Some conversations, like | NTP or routing, may be host level and servered apropriately by host | level keys. But IPSEC will not have done its job if it can't stop the | endless stream of end to end interactive application level security | protocols (telnet, ftp, etc., etc.). (Note: this remark does not | apply for store and forward services such as Mail, DNS, and HTTP | which | can not be adequately served by a simple "connection" oriented | security protocol.) It should be possible on multi-user systems for | the keying to authenticate different users and processes, even if this | is just done in some cases by letting an application do the work | itself. | Seems to me that a "Windows" system should have separate keys for | different services it might offer so that if host A had several | logical connections up with Windows machine B, one for ftp, one | for a | telnet session, one for news transfer, etc., they would be separately | keyed. | Really, as long as a system is set up so there can be different keys, | they most of the complexity here is at the session keying level, not | in the packet formats. I suggest that this is what the drafts should say. Not "user-oriented keying" but "multiple SPI's (and hence multiple keys) between pairs of hosts". The question of whether the keys are user-oriented should be left to implementations and possibly to the key management protocol. }... } }- There has been a lot of discussion about whether the DES-CBC transport should }be required. I respectfully submit that there is a set of organizations and }individuals who MUST (in a much more significant sense of "MUST") obey U.S. }(and other nation's) laws and who will require an engineering solution to }provide exportable encryption. Either this engineering group can provide that }solution or someone will have to define an IPSECbis and an IPv6bis. The risk }is fragmentation of standards. Since the set of people affected by the export }laws is large, I argue that this working group should address the issue. | There are also lots of people that need to communicate securely | within | the United States and lots of people outside the United States | unaffected by the US export laws who need to communicate | securely. If | someone want to define an insecure procotol that is freely exportable | from the US, they certainly can but I would recommend that anyone | who | wants to communicate securly not use such an insecure protocol. I believe in "truth in advertising": as long as a vendor (or a standards body) makes clear the weaknesses in any particular product or standard, then the people paying for the product or using the standard can make their own decision. In the real world, security is not binary. There is no such thing as a "secure system" versus an "insecure system." There are just degrees of security. Let me give a real-world analogy: if I buy a lock for my bicycle, I can buy one that can be broken with a pair of pliers. Or I can buy one that takes a cutting torch to break it. But there is no lock that can't be broken for sufficient money and time. Now the market needs both types of locks, since no one will spend $100 for a lock for a $100 bicycle, but someone who paid $3000 for a bicycle might well spend $100 for a lock. You might argue that ESP cannot be broken given the appropriate choice of encryption algorithm. This may be true, but that just diverts any attacks to other aspects of the protocol or the implementations. Just like an attacker faced with a really good bicycle lock will switch his attention to the chain used with the lock. I dislike the export rules as much as you, and I sure hope that (and will work to see that) they change sooner rather than later. But meanwhile, there is a real market for exportable IP security implementations. Either the IETF can standardize it, or it can see other parties do so. In the latter case, IETF is not fulfilling its proper role, in my opinion. | It | would certainly be a bad idea for the IETF to endorse such an | insecure | protocol as providing people with security. In fact, my understanding | of the current situtaion is that, while individual export approval is | required, it is easy to get permission to export DES-CBC | confidentiality from the US to any US company including any US | subsidiary abroad unless it is in one of a few countries that are | specially restricated. I've gone through the process of getting an export license. From my experience, I believe that the export rules are not actually published by the government. And they don't apply to non-US companies. And they apply differently for banking versus non-banking companies. And they apply differently for different countries, even non-embargoed countries. All in all, they are a significant barrier to commercial exploitation of IPSEC. | People who want security need to use strong algorithms. I can't see | why adopting a strong algorithm would cause anyone any difficult in | secure communications. If they need the protocol implemented | some | place to which it can not be exported from the US, they will be | trivially able to get it from elsewhere. People want different degrees of security depending upon what it costs (in performance as well as vendor price) and what they need to protect. U.S. vendors cannot sell products to international companies on the basis that "we'll sell you the complete package in North America, but you're on your own overseas." That's a complete non-starter. | All levels of the IETF has considered this problem and the strong | consensus in the IPng working group, the IESG, the IETF plenary, | etc., | etc., has consistently been that the IETF standard should require | strong security. I really wish I could agree with the IETF community on this point. I see the arguments being made here. I just don't think they are realistic in the real world. From ipsec-request@ans.net Tue Apr 11 17:03:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24034 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 13:08:19 -0400 Received: by interlock.ans.net id AA35230 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 13:05:36 -0400 Message-Id: <199504111705.AA35230@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 11 Apr 1995 13:05:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 13:05:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 13:05:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 13:05:36 -0400 To: rubin@mgoblue.bellcore.com (Aviel D Rubin) Cc: ipsec@ans.net Subject: Re: Bellovin's attack and others like it In-Reply-To: Your message of "Tue, 11 Apr 1995 11:31:57 EDT." <199504111624.AA41410@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 11 Apr 1995 13:03:03 -0400 From: "Perry E. Metzger" Aviel D Rubin says: > Now, I have a totally different question. At the IETF in > Danvers, I asked many people that are implementing key > management, how do you do key management over IP when your > policy indicates that all IP traffic must be encrypted? > The answer I got from everyone is that you somehow mark > the key management packets so that they are allowed. Doesn't > that violate the independence of the layers in the network? In my implementation, which permits per socket keying, the layers already have enhanced communication on such matters -- this is NOT the same as violating layering. .pm From ipsec-request@ans.net Tue Apr 11 19:09:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24832 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 15:28:47 -0400 Received: by interlock.ans.net id AA17458 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 15:10:02 -0400 Message-Id: <199504111910.AA17458@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 15:10:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 15:10:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 15:10:02 -0400 Date: Tue, 11 Apr 1995 12:09:54 -0700 From: Hilarie Orman To: rubin@mgoblue.bellcore.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199504111624.AA41410@interlock.ans.net> Subject: Re: Bellovin's attack and others like it We put two layers side-by-side over the basic packet delivery services. One layer is for non-key traffic, the other layer consists of only the key management protocol. I favor this arrangement over schemes that use UDP for key management, because I believe it yields a cleaner separation of software functionality and is easier to analyze. From ipsec-request@ans.net Tue Apr 11 15:40:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24271 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 15:40:37 -0400 Received: by interlock.ans.net id AA47980 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 15:34:07 -0400 Message-Id: <199504111934.AA47980@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Tue, 11 Apr 1995 15:34:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 11 Apr 1995 15:34:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 11 Apr 1995 15:34:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 15:34:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 15:34:07 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 15:34:07 -0400 To: Hilarie Orman Cc: ipsec From: Mark H Linehan/Watson/IBM Research Date: 11 Apr 95 15:04:41 Subject: Re: Comments on latest IPSP drafts Mime-Version: 1.0 Content-Type: Text/Plain > Hilarie Orman said: > In our prototyping of an IP security layer, we approached this by > having the sender's query for the MTU be intercepted by the > security > layer, which subtracts the header lengths from the actual network MTU. > The sender thus learns how much payload is available. This is a good idea and should be mentioned in the draft. Of course it doesn't help for applications that don't query for the MTU size.... > The > implementation of security as a layer makes the frag/reassembly > constraint natural and obvious. The "security as a layer" concept is also not discussed in the draft. It seems to me that IPSEC is more than just another layer if an implementation includes packet filtering and forwarding as well as IPSEC processing. From ipsec-request@ans.net Tue Apr 11 20:52:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21037 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 16:08:17 -0400 Received: by interlock.ans.net id AA18367 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 15:59:57 -0400 Message-Id: <199504111959.AA18367@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 11 Apr 1995 15:59:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 11 Apr 1995 15:59:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 15:59:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 15:59:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 15:59:57 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) X-Mailer: exmh version 1.5.3 12/28/94 To: rubin@mgoblue.bellcore.com (Aviel D Rubin) Cc: ipsec@ans.net Subject: Re: Bellovin's attack and others like it In-Reply-To: (Your message of Tue, 11 Apr 95 11:31:57 D.) <199504111624.AA41410@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Apr 95 15:52:58 -0500 Avi, I don't know how other implementations do it. In our (IBM) implemenation, we don't mark a packet. Rather, we use a policy which exempts messages sent by key mgmt engines from encryption/authentication. These messages can be identified by a reserved UDP port number. In this sense, there is no special mark on a key mgmt message. If the message is delivered to the correct port on the receiving end, then the process listening on the port should be able to handle the message. If the message is not delivered to the right port, then the key mgmt protocol must be able to handle this situtaion. This is like a eavesdropping attack. Regards, Pau-Chen > > Now, I have a totally different question. At the IETF in > Danvers, I asked many people that are implementing key > management, how do you do key management over IP when your > policy indicates that all IP traffic must be encrypted? > The answer I got from everyone is that you somehow mark > the key management packets so that they are allowed. Doesn't > that violate the independence of the layers in the network? > If I can mark packets as regular IP or key management IP, > where do I do this marking? In the kernel? Nobody I talked > to has actually implemented key management, encapsulation > and a policy. Shouldn't there be something in the standard > that mandates or recommends how to achieve all three? > > Avi Rubin > > ********************************************************************* > Aviel D. Rubin Email: rubin@faline.bellcore.com > Bellcore (MRE-2M354) ftp://thumper.bellcore.com/pub/rubin/rubin.html > 445 South St. > Morristown, NJ 07960 Voice: +1 201 829 4105 > USA FAX: +1 201 829 2645 From ipsec-request@ans.net Tue Apr 11 20:20:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23839 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 16:26:40 -0400 Received: by interlock.ans.net id AA09432 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 16:21:01 -0400 Message-Id: <199504112021.AA09432@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 16:21:01 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 16:21:01 -0400 To: ipsec@ans.net Subject: Re: Bellovin's attack and others like it In-Reply-To: Your message of Tue, 11 Apr 1995 12:09:54 -0700. <199504111910.AA17458@interlock.ans.net> Date: Tue, 11 Apr 1995 16:20:55 -0400 From: "Avi Rubin" It look like there are two approaches out there, using a UDP port for key management, or having separate layers for key mgmt vs. data packets. I'd like to see a constructive discussion of the tradeoffs using each technique from Pau-Chen, Hilarie and others. Then, I think that some recommendation, or at least suggestions should go into the key management documents. Avi *********************************************************************** Aviel D. Rubin Email: rubin@faline.bellcore.com Bellcore (MRE-2M354) ftp://thumper.bellcore.com/pub/rubin/rubin.html 445 South St. Morristown, NJ 07960 Voice: +1 201 829 4105 USA FAX: +1 201 829 5889 From ipsec-request@ans.net Tue Apr 11 20:47:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14610 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 16:52:12 -0400 Received: by interlock.ans.net id AA25192 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 16:48:14 -0400 Message-Id: <199504112048.AA25192@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 11 Apr 1995 16:48:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 16:48:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 16:48:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 16:48:14 -0400 To: "Avi Rubin" Cc: ipsec@ans.net Subject: Re: Bellovin's attack and others like it In-Reply-To: Your message of "Tue, 11 Apr 1995 16:20:55 EDT." <199504112021.AA09432@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 11 Apr 1995 16:47:56 -0400 From: "Perry E. Metzger" "Avi Rubin" says: > It look like there are two approaches out there, using a UDP > port for key management, or having separate layers for key mgmt > vs. data packets. > > I'd like to see a constructive discussion of the tradeoffs using > each technique from Pau-Chen, Hilarie and others. I'd say that there isn't much of a good reason not to use a UDP port. I've heard arguments to the effect that this somehow causes layer mixing but my design doesn't seem to suffer when things are done this way. Perry From ipsec-request@ans.net Tue Apr 11 21:48:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14618 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 16:54:08 -0400 Received: by interlock.ans.net id AA10634 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 16:51:03 -0400 Message-Id: <199504112051.AA10634@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 11 Apr 1995 16:51:03 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 11 Apr 1995 16:51:03 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 16:51:03 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 16:51:03 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 16:51:03 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) X-Mailer: exmh version 1.5.3 12/28/94 To: Hilarie Orman Cc: rubin@mgoblue.bellcore.com, ipsec@ans.net Subject: Re: Bellovin's attack and others like it In-Reply-To: (Your message of Tue, 11 Apr 95 12:09:54 MST.) <199504111910.AA17458@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Apr 95 16:48:42 -0500 Hilarie, when you say "two layers", do you mean a new transport layer protocol (other than TCP, UDP, ICMP, ...) ? Regards, Pau-Chen > We put two layers side-by-side over the basic packet delivery > services. One layer is for non-key traffic, the other layer consists > of only the key management protocol. > > I favor this arrangement over schemes that use UDP for key management, > because I believe it yields a cleaner separation of software functionality > and is easier to analyze. From ipsec-request@ans.net Tue Apr 11 22:19:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24960 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 17:29:19 -0400 Received: by interlock.ans.net id AA05913 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 17:21:44 -0400 Message-Id: <199504112121.AA05913@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 11 Apr 1995 17:21:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 11 Apr 1995 17:21:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 17:21:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 17:21:44 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 17:21:44 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) X-Mailer: exmh version 1.5.3 12/28/94 To: perry@imsi.com Cc: "Avi Rubin" , ipsec@ans.net, pau@watson.ibm.com Subject: Re: Bellovin's attack and others like it In-Reply-To: (Your message of Tue, 11 Apr 95 16:47:56 D.) <199504112048.AA25192@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Apr 95 17:19:22 -0500 Perry, we have similar experience. I think if decison-making is done at IP layer, then most likely there will be some layer mixing (i.e., IP looks at the transport layer.). Our code uses UDP and it does not cause any difficulty. I think this little layer mixing is a common practice on firewall/packet-filter already. Using a new transport procotol may be conceptually cleaner and make IPSP policy simpler (no need for exemptions), though. If we put key mgmt engine is the user space, then my feeling is that there is no big difference in coding effort/complexity between the two approaches. Regards, Pau-Chen > > "Avi Rubin" says: > > It look like there are two approaches out there, using a UDP > > port for key management, or having separate layers for key mgmt > > vs. data packets. > > > > I'd like to see a constructive discussion of the tradeoffs using > > each technique from Pau-Chen, Hilarie and others. > > I'd say that there isn't much of a good reason not to use a UDP > port. I've heard arguments to the effect that this somehow causes > layer mixing but my design doesn't seem to suffer when things are done > this way. > > Perry From ipsec-request@ans.net Tue Apr 11 22:51:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29659 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 18:43:18 -0400 Received: by interlock.ans.net id AA22035 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 18:39:40 -0400 Message-Id: <199504112239.AA22035@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 11 Apr 1995 18:39:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 18:39:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 18:39:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 18:39:40 -0400 Date: Tue, 11 Apr 1995 15:51:18 -0700 From: ashar@osmosys.incog.com (Ashar Aziz) To: smb@research.att.com, rogaway@cs.ucdavis.edu Subject: Re: Bellovin's attack Cc: ipsec@ans.net X-Sun-Charset: US-ASCII I think this problem needs a bit more discussion before we can decide that mandating integrity checks with ESP is the right solution. I believe that Phil Rogaway is correct that there is no reason to believe that adding MACs will solve the problem in general. Consider the following modified attack against UDP based apps. LA sends UDP traffic to a UDP port (say Pb) that LB is listening on. Attacker records all encrypted UDP traffic. For this attack, the traffic may also be authenticated using MACs. After LB's listener on Pb goes away, and prior to host session key renegotiation, attacker binds to the same port (Pb), which she can do since the earlier UDP receiver has gone away. Now attacker can simply play back the recorded encrypted/authenticated UDP traffic, and start receiving that in the clear on Pb. Adding MACs to encrypted traffic does not protect against this class of attacks on UDP traffic, because the traffic was never modified. This attack is harder to mount against TCP apps, because of the TCP state machine. But this attack is bad enough if, e.g., it was a UDP based app used for secure conferencing (audio/video). I'll also observe that this attack does not require attaining any special privilege on the machine (e.g. root access), or knowledge of the per host key. I believe that this scenario merits consideration, before we decide to mandate integrity checking with encryption. Regards, Ashar. From ipsec-request@ans.net Tue Apr 11 22:53:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09602 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 18:56:08 -0400 Received: by interlock.ans.net id AA10431 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 18:53:45 -0400 Message-Id: <199504112253.AA10431@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 18:53:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 18:53:45 -0400 Date: Tue, 11 Apr 1995 18:53:36 -0400 From: rubin@faline.bellcore.com (Aviel D Rubin) To: ho@cs.arizona.edu, pau@watson.ibm.com Subject: Combining key mgmt & ESP (was Re: Bellovin's attack and ...) Cc: ipsec@ans.net, rubin@mgoblue.bellcore.com I was wondering the same thing. Can you elaborate on your implementation of this? From pau@watson.ibm.com Tue Apr 11 16:56:05 1995 Delivery-Date: Tue, 11 Apr 95 16:56:06 -0400 Received: from mgoblue.bellcore.com (mgoblue.bellcore.com [128.96.59.79]) by faline.bellcore.com (8.6.9/8.6.10) with ESMTP id QAA20140 for ; Tue, 11 Apr 1995 16:56:05 -0400 Received: from flash.bellcore.com (flash.bellcore.com [128.96.32.20]) by mgoblue.bellcore.com (8.6.9/8.6.9) with ESMTP id QAA06807 for ; Tue, 11 Apr 1995 16:56:03 -0400 Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by flash.bellcore.com (8.6.9/8.6.9) with SMTP id QAA29093 for ; Tue, 11 Apr 1995 16:56:02 -0400 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4119; Tue, 11 Apr 95 16:51:01 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 2263; Tue, 11 Apr 1995 16:51:01 EDT Received: from ixextra2.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Tue, 11 Apr 95 16:51:00 EDT Received: by ixextra2.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA19937; Tue, 11 Apr 1995 16:48:43 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) Message-Id: <9504112048.AA19937@ixextra2.watson.ibm.com> X-Mailer: exmh version 1.5.3 12/28/94 To: Hilarie Orman Cc: rubin@mgoblue.bellcore.com, ipsec@ans.net Subject: Re: Bellovin's attack and others like it In-Reply-To: (Your message of Tue, 11 Apr 95 12:09:54 MST.) <199504111910.AA17458@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Apr 95 16:48:42 -0500 Status: RO Hilarie, when you say "two layers", do you mean a new transport layer protocol (other than TCP, UDP, ICMP, ...) ? Regards, Pau-Chen > We put two layers side-by-side over the basic packet delivery > services. One layer is for non-key traffic, the other layer consists > of only the key management protocol. > > I favor this arrangement over schemes that use UDP for key management, > because I believe it yields a cleaner separation of software functionality > and is easier to analyze. From ipsec-request@ans.net Tue Apr 11 23:12:35 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24940 (5.65c/IDA-1.4.4 for ); Tue, 11 Apr 1995 19:19:54 -0400 Received: by interlock.ans.net id AA38621 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 11 Apr 1995 19:13:45 -0400 Message-Id: <199504112313.AA38621@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 11 Apr 1995 19:13:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 11 Apr 1995 19:13:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 11 Apr 1995 19:13:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 11 Apr 1995 19:13:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 11 Apr 1995 19:13:45 -0400 Date: Tue, 11 Apr 1995 16:12:35 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: smb@research.att.com, rogaway@cs.ucdavis.edu, ashar@osmosys.incog.com Subject: Re: Bellovin's attack Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Ashar, I think the attack you suggest is different from, but in a sense subsumes Steve's attack. What we are rediscovering is the somewhat fundamental idea that multiplexed resources (in the case you cite, ports) must be properly managed so that no information can leak from one principal to another due to a failure in the underlying system. This is the same property that must exist when disk space is shared between users, both concurrently and serially. In your example, the information residue is keying material attached to a serially reused resource (i.e., ports). The problem is identifying what is the appropriate set of actors to be kept separate and how to multiplex the resource, i.e., the crypto-channel, so that separation is obtained. I must admit I was confused by Phil's assertion that it made no difference whether the information is MACed for Steve's attack to work. The example you give clarifies this for me. Thanks. Regards, Dan From ipsec-request@ans.net Wed Apr 12 09:18:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24696 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 13:27:44 -0400 Received: by interlock.ans.net id AA36659 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 13:21:36 -0400 Message-Id: <199504121721.AA36659@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 13:21:36 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 13:21:36 -0400 Date: Wed, 12 Apr 95 13:18:29 EDT From: hugo@watson.ibm.com To: IPSEC@ans.net, KARN@QUALCOMM.COM Cc: PAULV@BNR.CA, WHITFIELD.DIFFIE@eng.sun.com, ASHAR@OSMOSYS.INCOG.COM Subject: Photuris.01: signature message I plan to send several notes commenting on Photuris draft version 01 (draft-karn-photuris-01.txt). Some of the comments were already discussed with Phil and we reached agreement on part of them. There are many other comments that we did not have time to discuss. In any case, I believe the issues need to be presented to the whole WG. This first note concentrates on the signature message (page 23 of the draft), whose description seems to me open to different interpretations, and basically all these interpretations are susceptible to security vulnerabilities of some kind. There are several general points that I want to make based on the comments in this note. I put them here just for the exhausted reader that will never get to the end. (1) Design of cryptographic protocols is a very tricky thing. (I know this is a well-known fact; however, I argue, we tend to underestimate the meaning of this fact.) (2) It is very easy to loose the security of a well studied protocol with seemingly "minor changes". In particular, the security of such protocols lives or dies by the "minor details". (3) It is a must to have all these protocols scrutinized as much as possible by cryptographers and security experts before adoption. (4) Wherever the protocol allows for generic transforms (which is highly desirable for generality/upgradability/compatibility/anyotherity) the security must be analyzed relative to the generic properties of these transforms and not based on additional properties of particular transforms. [It is very easy to make the mistake of specifying a generic transform while, in fact, one has in mind a very particular one: that's dangerous!] (5) Eventually, the drafts describing the key management mechanisms should be accompanied by text (or separate drafts) explaining the rationale behind these mechanisms, and clear implementation notes on the essentiality of some "details". After the long comments on what is wrong about the current specifications I also point out to some possible corrections. Now to the comments. Terminology: I use g^x to denote I's Public-Value, and g^y for R's Public-Value (I and R stand for Initiator and Responder, respectively). The draft specifies (pages 23/24) that: 1) the signature is computed over the DH key SK (derived from g^xy), g^x and g^y. 2) *optionally*, the local party's identity can also be signed 3) "the SIGNATURE_MESSAGE ... is required to be authenticated or encrypted" Although, the draft does not explain the design choices, I believe that the signing of SK as well as (2) and (3) above are specified to defeat a special kind of attacks described in: [STS] Whitfield Diffie, Paul C van Oorshot, Michael J Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Publishers, 1992. (this is the paper on which Photuris design is based and I join Phil in recommending its reading to anybody interested in design of key management protocols). This attack consists of the adversary, E, intercepting and changing messages between I and R such that, after the run of the protocol, I believes he exchanged a key SK with R, but R believes he exchanged the same SK with E. Although E does not know SK, it is shown in [STS] how such an attack can be very harmful to I (and good for E). Roughly, any piece of information authenticated by I using that shared key SK is understood by R as authenticated by E. The example given in the paper consists of R being a bank, and deposits done by I being credited to E. Since the issues dealt with in this note are quite involved and there are several options supported by the draft's protocol, I will start, for simplicity, with a specific case. Namely, showing that if one does not include the identity of the local party in the signed information, and does not encrypt or authenticate the signature, then the protocol is vulnerable to the above attack. (Later, I discuss the addition of either encryption or authentication). For concreteness, let's assume that the signature in use (S-transform) consists of RSA to sign, and MD5 to hash the information before applying RSA. The attacker E will intercept I's signature RSA_I(MD5(SK,g^y,g^x)), will compute from it MD5(SK,g^y,g^x) using the inverse (verification) function of RSA, and will sign that same string using her own private key, namely, RSA_E(MD5(SK,g^y,g^x)). Notice that for this process E does not need to know SK! If I (the Initiator, not Hugo) would have included the identity inside the MD5 calculation this (straightforward) attack does not work. (Since E does not know how to replace this identity by her own inside the MD5). Notice that at a first glance putting the identity inside the signature solves the problem, but this is not accurate in general. Indeed, assume the following. Before signing apply MD5 to the long information: namely MD5(SK,g^x,g^y). Concatenate this result to the identity, and then sign (i.e., apply RSA to) the concatenated information (I am assuming an identifier of no more than, say, 896=1024-128 bits). In this case the above vulnerability stays, even if in a strict sense one has signed the identity. What helps solving the problem is not just signing the identity but putting the identity inside the MD5 calculation. But who said this is enough? Moreover, Photuris does not require any specific signature transform, therefore the security needs to be analyzed on the basis of a generic transform and not on particular choices (e.g. RSA+MD5). If a generic transform is not enough to achieve a given requirement, then the necessary complementary mechanisms must be explicitely required in the draft specification. From all this we learn that signing the shared key SK has not helped, to avoid the STS attack (the only reason, I guess, to introduce it there). However, there is an even more "fundamental" objections to signing a secret key. Digital signatures are not designed to provide for secrecy, therefore, *signing secret information* is a fundamental mistake. Clearly, one could sign information derived from that key but not the key itself. In this case, one has to make sure that the derived information does not leak information on the secret. For example, one can envision good collision-intractable hash functions that leak information on their arguments. Again, these issues are of indisputable importance when working with generic transforms. *Encrypting the signature*: the draft proposes as an option the encryption of the signature-message (although it is not specified, I guess it means encryption using SK). In this case some of the problems mentioned above are seemingly solved. For example, information leaked on SK by the signature is now protected (although encrypting a key under the same key cannot be claimed, in general, to be secure). Also, E cannot as easily as before derive the value of the internal MD5 computation. Moreover, if one uses encryption of the signature (under SK), then the whole issue of signing SK can be avoided. Still, I do not recommend the encrypted signature solution (which basically becomes the basic STS protocol). The reasons are: (1) I do not want to mandate symmetric encryption in the key management protocol; and, most importantly, (2) encryption is not the right function to use in order to "prove possession" of a key. Let me be more explicit about (2). STS uses encryption under SK (where SK=g^xy) to "prove possession" of SK. However, encryption is not the appropriate function to do that. The reason is that encryption is usually "tamperable" (e.g., if I know "text" and your encryption is a stream cipher then I can change E_SK(text) to E_SK(text') for any text' of my choice without knowing SK at all). Is that applicable to STS/Photuris? One can argue that it is not because E does not know the value of SIG_I(g^x,g^y); however, assume an attacker E that has stolen I's private key. Clearly, such an attacker will be able to carry the above attack. Is that a problem? On one hand, one can say that if E knows I's key she can do whatever I (the initiator) can do and then this particular attack is not interesting. However, notice that E is achieving something that the sole knowledge of I's private key cannot achieve: namely, convincing E that she knows SK. In some scenarios, and the bank example from [STS] can be such a scenario, E will be able to mislead I and R in ways that the sole possession of I's private key would not have permitted. In other words, a good protocol needs to minimize the negative effects of an exposed key (the whole idea of using Diffie-Hellman or perfect forward secrecy is exactly that). I argue that the protocol should not show the above vulnerability. A solution is to replace encryption by a MAC function (which is already suggested in [STS] as an option). (Encryption should remain as an *option* for the sole purpose of anonymity). *MACing the signature*: Photuris.01 has also authentication of the signature message as an option. I could not find in the specification the field in the message that carries the MAC (e.g., the result of key-ed MD5 applied to the message), but I assume it was just omitted by mistake in the description. If one MACs the signature, and also signs SK, then the comments above about weaknesses of signing a secret key still apply. However, as in the case of encryption, if one does authenticate the signature using SK then why also sign SK? If one does not sign SK then the protocol becomes essentially STS with MAC instead of encryption. From all the variants considered above this is the only one that looks sound. However, this should be taken with care, I personally do not feel completely comfortable with my understanding of this variant. Actually, I can even point out to some delicate issues with it. If one MACs using SK, then the adversary gets a pair (known-text, MAC_SK(known-text)). Does this help the attacker to learn something about SK? First, it gives this pair of known plaintext, ciphertext which is otherwise unavailable, and even more seriously, a generic MAC function does not guarantee any specific protection of the key (for example, it may leak several bits of the key, or some other information, and still be unforgeable as a MAC). Does this last problem has a solution. Yes: from g^xy derive two keys, one for the MAC of signature, the second the actual SK to be shared by the parties for subsequent communication. If the two keys are derived such that knowledge of one does not reveal information on the other then the above problem is solved. Such two keys can be derived by an appropriate use of a pseudorandom function. [I can further elaborate on this in a future note] There is also another solution to all the problems with the signature message pointed out in this note (and others not mentioned here): just do not use signatures. This is what Photuris Plus (a.k.a. Photuris variant) does. However, let me be clear on this, all the points made at the top of this note (points 1-5) apply to Photuris Plus as well. I guess you had enough for one note. Hugo From ipsec-request@ans.net Wed Apr 12 09:37:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21044 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 13:45:20 -0400 Received: by interlock.ans.net id AA28923 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 13:37:56 -0400 Message-Id: <199504121737.AA28923@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 13:37:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 13:37:56 -0400 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 13:37:56 -0400 Date: Wed, 12 Apr 95 13:37:49 EDT To: ipsec@ans.net Subject: Port numbers Does the use of port numbers to distinguish key-management messages from data messages work if the underlying transport mechanism is ATM? What is the right mechanism there? I tend to prefer solutions based on tagging the messages as to type, rather than counting on the available of secondary channels... Ron Rivest From ipsec-request@ans.net Wed Apr 12 14:30:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14730 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 14:30:48 -0400 Received: by interlock.ans.net id AA25137 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 14:22:28 -0400 Message-Id: <199504121822.AA25137@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Wed, 12 Apr 1995 14:22:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 12 Apr 1995 14:22:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 14:22:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 14:22:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 14:22:28 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 14:22:28 -0400 To: ipsec From: Mark H Linehan/Watson/IBM Research Date: 12 Apr 95 14:22:10 Subject: Re: Bellovin's and Ahar's attacks Mime-Version: 1.0 Content-Type: Text/Plain Let's take Ashar's scenario a step further. Assume that two parties LA and LB are communicating via UDP on machines that are behind firewalls. That is, IPSEC and ESP are used to provide a secure tunnel between two firewalls. LA and LB are operating on machines that are "behind" these firewalls at the two ends of the tunnel. Assume that an attacker can record the traffic in the tunnel and can also login as a user on LA's or LB's machine. Then, after LA and LB have gone away, the attacker can replay the recorded traffic and have one of the firewalls decrypt the traffic and deliver it to the LA or LB machine where the attacker has taken over the destination port. I suggest that they only solution for this situation is frequent re-keying in the firewalls. Using different keys for different UDP source/destination address & port pairings doesn't help with this attack because the scenario is that a given address & port are taken over by the attacker. The only option is a time-based re-keying strategy. We will certainly need to discuss how often to re-key. When the transport protocol is TCP, the network layer could notice when a TCP session is closed. If it re-keyed at that point, then a replay attack would be fruitless. Re-keying could also be triggered by receiving an ICMP port-unreachable message. But I think we have to rely on time-based re-keying for UDP. This argues for a cheap and fast re-keying mechanism, so that we can afford to do it quite often. If we follow Bellovin's suggestion that AH be required when ESP is used, then we guarantee that IP packets are delivered to the correct destination. I suggest that once we've done that, per-session (or per-user) keys are not required as long as we re-key frequently. The re-keying defeats Rogoway's attack as effectively as per-session keying. For example, if we have a single key between two hosts but change the key every time a TCP session closes then subsequent users of the same ports can't use Ashar's attack. Having a separate key per session implies a much larger SA table than having a key per host. I think we'd do better to re-key a single host key fairly often. From ipsec-request@ans.net Wed Apr 12 18:21:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16780 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 14:30:48 -0400 Received: by interlock.ans.net id AA26396 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 14:21:52 -0400 Message-Id: <199504121821.AA26396@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 14:21:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 14:21:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 14:21:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 14:21:52 -0400 To: rivest@theory.lcs.mit.edu (Ron Rivest) Cc: ipsec@ans.net Subject: Re: Port numbers In-Reply-To: Your message of "Wed, 12 Apr 1995 13:37:49 EDT." <199504121737.AA28923@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 12 Apr 1995 14:21:41 -0400 From: "Perry E. Metzger" Ron Rivest says: > Does the use of port numbers to distinguish key-management messages from > data messages work if the underlying transport mechanism is ATM? Why shouldn't it? IP is there to insulate you from worrying about such things. Perry From ipsec-request@ans.net Wed Apr 12 18:52:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20034 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 15:06:16 -0400 Received: by interlock.ans.net id AA45104 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 14:53:55 -0400 Message-Id: <199504121853.AA45104@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 12 Apr 1995 14:53:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 14:53:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 14:53:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 14:53:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 14:53:55 -0400 Date: Wed, 12 Apr 1995 11:52:43 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipsec@ans.net, linehan@watson.ibm.com Subject: Re: Bellovin's and Ahar's attacks X-Sun-Charset: US-ASCII Mark, I am somewhat uncomfortable with your proposition : > I > suggest that once we've done that, per-session (or per-user) keys are not > required as long as we re-key frequently. The re-keying defeats Rogoway's > attack as effectively as per-session keying. It assumes that an intruder cannot quickly capture and replay traffic. If he is doing this manually, then this is probably a safe assumption. However, in high value applications, there is no reason to believe an intruder will not spend the resources to write a program that detects a potentially valuable stream of target traffic, coordinates with an end system program and replay's it according to Phil's and Ashar's suggestion. For example, transaction systems (of the kind used to execute stock market trades) would be a perfect target for such an attack. Each transaction is an independent action, may quickly use a port and then make it available for use by other programs and might provide an intruder with potentially valuable information (buy/sell signals). Dan From ipsec-request@ans.net Wed Apr 12 20:05:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06763 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 15:13:01 -0400 Received: by interlock.ans.net id AA47418 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 15:08:05 -0400 Message-Id: <199504121908.AA47418@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 12 Apr 1995 15:08:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 15:08:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 15:08:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 15:08:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 15:08:05 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) X-Mailer: exmh version 1.5.3 12/28/94 To: rivest@theory.lcs.mit.edu Cc: ipsec@ans.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Apr 95 15:05:42 -0500 Ron, I don't know how ATM works. But IP is designed to be put on top of network hardware (in this case : ATM) to hide the details of the network and provides a unified abstract view. So if we use TCP/IP/UDP on ATM, there will still be IP addresses and UDP port numbers. Regards, Pau-Chen - ----------------------------- Note follows ------------------------------ From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 13:37:56 -0400 Date: Wed, 12 Apr 95 13:37:49 EDT To: ipsec@ans.net Subject: Port numbers Does the use of port numbers to distinguish key-management messages from data messages work if the underlying transport mechanism is ATM? What is the right mechanism there? I tend to prefer solutions based on tagging the messages as to type, rather than counting on the available of secondary channels... Ron Rivest ------- End of Forwarded Message From ipsec-request@ans.net Wed Apr 12 11:28:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21149 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 15:39:29 -0400 Received: by interlock.ans.net id AA06717 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 15:34:34 -0400 Message-Id: <199504121934.AA06717@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 15:34:34 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 15:34:34 -0400 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipsec@ans.net, linehan@watson.ibm.com Subject: Re: Bellovin's and Ahar's attacks Date: Wed, 12 Apr 95 15:28:42 EDT > I am somewhat uncomfortable with your proposition : > > > I > > suggest that once we've done that, per-session (or per-user) keys are not > > required as long as we re-key frequently. The re-keying defeats Rogoway's > > attack as effectively as per-session keying. > > It assumes that an intruder cannot quickly capture and replay traffic. If he > is doing this manually, then this is probably a safe assumption. However, in > high value applications, there is no reason to believe an intruder will not > spend the resources to write a program that detects a potentially valuable > stream of target traffic, coordinates with an end system program and > replay's it according to Phil's and Ashar's suggestion. A lot depends on our assumptions. For TCP, it's probably feasible, so long as rekeying occurs more frequently than the TIMEWAIT period. For UDP, there's no mandatory dead time in the protocol. I strongly suspect that we absolutely must use very rapid key changes, though -- per user (though with AH+ESP for some services), per packet (a la SKIP), or per socket. Nothing less seems to guard adequately against both replay attacks and the CBC cut-and-paste attack that I outlined. From ipsec-request@ans.net Wed Apr 12 19:49:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06686 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 15:56:16 -0400 Received: by interlock.ans.net id AA35901 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 15:50:40 -0400 Message-Id: <199504121950.AA35901@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 12 Apr 1995 15:50:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 15:50:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 15:50:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 15:50:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 15:50:40 -0400 Date: Wed, 12 Apr 1995 12:49:12 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: smb@research.att.com Subject: Re: Bellovin's and Ahar's attacks Cc: ipsec@ans.net, linehan@watson.ibm.com, ashar@jurassic.eng.sun.com X-Sun-Charset: US-ASCII > > A lot depends on our assumptions. For TCP, it's probably feasible, so > long as rekeying occurs more frequently than the TIMEWAIT period. For > UDP, there's no mandatory dead time in the protocol. I strongly suspect > that we absolutely must use very rapid key changes, though -- per user > (though with AH+ESP for some services), per packet (a la SKIP), or per > socket. Nothing less seems to guard adequately against both replay attacks > and the CBC cut-and-paste attack that I outlined. > I agree that rapid rekeying is a good idea. However, it isn't sufficient for all cases. By the way, the replay attack Ashar suggests relies on the ability of an intruder running on a machine discovering which port to use to receive the replayed traffic. Since ESP hides this information in the encrypted part, the intruder must use indirect methods to discover this. Dan From ipsec-request@ans.net Wed Apr 12 21:20:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05412 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 16:33:39 -0400 Received: by interlock.ans.net id AA37091 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 16:23:47 -0400 Message-Id: <199504122023.AA37091@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 12 Apr 1995 16:23:47 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 16:23:47 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 16:23:47 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 16:23:47 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 16:23:47 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) X-Mailer: exmh version 1.5.3 12/28/94 To: smb@research.att.com, ipsec@ans.net Subject: Re: Bellovin's and Ahar's attacks In-Reply-To: (Your message of Wed, 12 Apr 95 15:28:42 EDT.) <199504121934.AA06717@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Apr 95 16:20:55 -0500 Steve, I have a question. This question is based on the assumption that a conversation (whether through TCP or UDP) should be equally protected on both directions. For TCP, I think the assumption implies there must be a specific key (or a pair of keys) for each connection. This means this key becomes part of the connection state. I discussed this with Perry during last IETF. I think I know how to do it. What I don't understand is how to do the same thing for UDP, or any state-less protocol. How does a receiver knows which key to use when sending a response to a received message if the receiver is talking to multiple parties through the same port ? Regards, Pau-Chen > > I am somewhat uncomfortable with your proposition : > > > > > I > > > suggest that once we've done that, per-session (or per-user) keys are not > > > required as long as we re-key frequently. The re-keying defeats Rogoway's > > > attack as effectively as per-session keying. > > > > It assumes that an intruder cannot quickly capture and replay traffic. If he > > is doing this manually, then this is probably a safe assumption. However, in > > high value applications, there is no reason to believe an intruder will not > > spend the resources to write a program that detects a potentially valuable > > stream of target traffic, coordinates with an end system program and > > replay's it according to Phil's and Ashar's suggestion. > > A lot depends on our assumptions. For TCP, it's probably feasible, so > long as rekeying occurs more frequently than the TIMEWAIT period. For > UDP, there's no mandatory dead time in the protocol. I strongly suspect > that we absolutely must use very rapid key changes, though -- per user > (though with AH+ESP for some services), per packet (a la SKIP), or per > socket. Nothing less seems to guard adequately against both replay attacks > and the CBC cut-and-paste attack that I outlined. From ipsec-request@ans.net Wed Apr 12 20:52:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14755 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 17:09:06 -0400 Received: by interlock.ans.net id AA40072 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 17:04:16 -0400 Message-Id: <199504122104.AA40072@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 17:04:16 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 17:04:16 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipsec@ans.net Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-karn-photuris-01.txt Date: Wed, 12 Apr 95 16:52:52 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Photuris Session Key Management Protocol Author(s) : P. Karn, W. Simpson Filename : draft-karn-photuris-01.txt Pages : 31 Date : 04/11/1995 Photuris [1] is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP) in a point-to-point mode. Photuris is still in the early design stages and has not yet been completely specified. It is hoped that this draft will stimulate discussion about the merits of the design philosophy. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-karn-photuris-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-karn-photuris-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-karn-photuris-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19950411104434.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-karn-photuris-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-karn-photuris-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950411104434.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Wed Apr 12 21:06:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24772 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 17:10:07 -0400 Received: by interlock.ans.net id AA45814 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 17:06:52 -0400 Message-Id: <199504122106.AA45814@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 17:06:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 17:06:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 17:06:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 17:06:52 -0400 To: pau@watson.ibm.com (Pau-Chen Cheng) Cc: ipsec@ans.net Subject: Re: Bellovin's and Ahar's attacks In-Reply-To: Your message of "Wed, 12 Apr 1995 16:20:55 CDT." <199504122023.AA37091@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 12 Apr 1995 17:06:44 -0400 From: "Perry E. Metzger" Pau-Chen Cheng says: > What I don't understand is how to do the same thing for UDP, or any > state-less protocol. How does a receiver knows which key to use when > sending a response to a received message if the receiver is talking to > multiple parties through the same port ? I know several ways to do it, but I'm not sure yet what the "right thing" is. I've been punting on it until I get a chance to play with them. My notion at the moment is to possibly extend the sendmsg and rcvmsg calls somehow -- I already have userland dealing with SAs a small bit -- but I find this very ugly although it will work. I'm holding off, as I said, until I get more of a chance to explore this in detail. I'm not a believer in defining APIs in the absense of experience with them. Perry From ipsec-request@ans.net Wed Apr 12 12:15:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05386 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 17:34:39 -0400 Received: by interlock.ans.net id AA09890 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 17:15:10 -0400 Message-Id: <199504122115.AA09890@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 17:15:10 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 17:15:10 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 17:15:10 -0400 Date: Wed, 12 Apr 1995 17:15:01 +0500 From: Theodore Ts'o To: smb@research.att.com Cc: Danny.Nessett@eng.sun.com, ipsec@ans.net, linehan@watson.ibm.com In-Reply-To: smb@research.att.com's message of Wed, 12 Apr 95 15:28:42 EDT, <199504121934.AA06717@interlock.ans.net> Subject: Re: Bellovin's and Ahar's attacks Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 902 From: smb@research.att.com Date: Wed, 12 Apr 95 15:28:42 EDT I strongly suspect that we absolutely must use very rapid key changes, though -- per user (though with AH+ESP for some services), per packet (a la SKIP), or per socket. Nothing less seems to guard adequately against both replay attacks and the CBC cut-and-paste attack that I outlined. What would happen if we required that every single encrypted packet be also integrity protected? Wouldn't that mean that the cut and paste attack would fail, since the kernel would see that the integrity check failed, and thus refuse to pass the decrypted data back up to the user? To prevent the UDP attack of another user binding to the same UDP socket and playing back the exact same packet, we'd also need per-user keying. But it seems to me that protecting against these attacks is doable. What am I missing? - Ted From ipsec-request@ans.net Wed Apr 12 17:35:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15644 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 17:35:06 -0400 Received: by interlock.ans.net id AA39443 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 17:22:22 -0400 Message-Id: <199504122122.AA39443@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Wed, 12 Apr 1995 17:22:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 12 Apr 1995 17:22:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 17:22:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 17:22:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 17:22:22 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 17:22:22 -0400 To: Dan Nessett Cc: ipsec From: Mark H Linehan/Watson/IBM Research Date: 12 Apr 95 17:21:13 Subject: Re: Bellovin's and Ahar's attacks Mime-Version: 1.0 Content-Type: Text/Plain Danny, regarding the issue you raise: > However, in > high value applications, there is no reason to believe an intruder will not > spend the resources to write a program that detects a potentially valuable > stream of target traffic, coordinates with an end system program and > replay's it according to Phil's and Ashar's suggestion. For example, transaction > systems (of the kind used to execute stock market trades) would be a perfect > target for such an attack. Each transaction is an independent action, may > quickly use a port and then make it available for use by other programs and > might provide an intruder with potentially valuable information (buy/sell > signals). If we use Steve Bellovin's suggestion that ESP require AH, then the destination system will always deliver current traffic to the appropriate port. So the only issue is Ashar's attack, where the attacker (quickly) reopens the same port, replays the encrypted packets, and thus gains access to the cleartext. I have several suggestions: 1. If the IPSEC processing is happening within the destination system, then it should rekey every time a socket is closed. This ensures that any subsequent user of the same port will get a different key. 2. If the IPSEC processing is happening in a firewall, then it could notice whenever a TCP connection is closed and could rekey at that time. That ensures that any subsequent TCP session will use another key. 3. If the IPSEC processing is happening in a firewall, and the application uses UDP then there is no possibility of either per-session keying or of re-keying at some appropriate time. The firewall just doesn't have the necessary information. Unless maybe we could get the end systems to send some kind of indication (like an ICMP packet) that rekeying should happen. But this requires changing end-systems - which dilutes the value of the firewall scheme. From ipsec-request@ans.net Wed Apr 12 23:20:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07969 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 18:28:01 -0400 Received: by interlock.ans.net id AA11372 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 18:23:11 -0400 Message-Id: <199504122223.AA11372@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 12 Apr 1995 18:23:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 18:23:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 18:23:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 18:23:11 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 18:23:11 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) X-Mailer: exmh version 1.5.3 12/28/94 To: ipsec@ans.net Subject: Re: Bellovin's and Ahar's attacks In-Reply-To: (Your message of 12 Apr 95 17:21:13 GMT.) <199504122122.AA39443@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Apr 95 18:20:47 -0500 I have a thought. The reason that Ashar's attack on UDP can succeed is that an UDP packet has infinite life time. If we can restrict the life time to a short period, then the attacks and possible damages can be confined, though not completely eliminated. Assuming the following : 1. Every system can keep its time down to the precision of a second. 2. Every system's clock tick at about the same rate, down to the precision of a second. If the assumptions hold, then what can be done is : 1. When exahanging keys (including re-keying), each system send its current time to the other. 2. Upon receiving the other's time, a t-delta is computed between the local time and the other's time. This t-delta is then associated with the other's SPI. 3. When sending a UDP message, including in the AH a time stamp which is equal to "current local time + t-delta". This value is an estimate of the other's time. 4. When receiving a UDP message, examine the time stamp, discard any message that is too old (e.g., more than twice the network latency). Regards, Pau-Chen From ipsec-request@ans.net Wed Apr 12 22:43:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12635 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 18:35:51 -0400 Received: by interlock.ans.net id AA24311 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 18:32:21 -0400 Message-Id: <199504122232.AA24311@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 18:32:21 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 18:32:21 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 18:32:21 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 18:32:21 -0400 Date: Wed, 12 Apr 1995 15:43:59 -0700 From: ashar@osmosys.incog.com (Ashar Aziz) To: smb@research.att.com, tytso@MIT.EDU Subject: Re: Bellovin's and Ashar's attacks Cc: Danny.Nessett@eng.sun.com, ipsec@ans.net, linehan@watson.ibm.com X-Sun-Charset: US-ASCII > What would happen if we required that every single encrypted packet be > also integrity protected? Wouldn't that mean that the cut and paste > attack would fail, since the kernel would see that the integrity check > failed, and thus refuse to pass the decrypted data back up to the user? Requiring integrity protection on every packet will defeat cut-and-paste style attacks. But there are also alternative counter-measures which may be more efficient. Depending on the implementation/cipher, per packet re-keying may be much more efficient than integrity protecting every packet. For example, if the session key is used to encrypt a packet key, which is then used to encrypt the packet, then this only entails the computational overhead of encrypting 8-16 bytes per packet. This can be vastly more efficient than computing an integrity check over the entire packet. The packet key would come in-band. The space demands of this scheme are comparable to the packet space that would be required to carry the MAC (8-16 bytes). The implementation scenarios where this might be problematic is if there is crypto-hardware where key setup may take a while. Also, this is problematic if the cipher has a naturally long key-setup overhead. This isn't the case for a software implementation of DES-CBC. I am mentioning this so this can be considered as one alternative (and not to start a religous debate on in-band vs. out-of-band). Regards, Ashar. From ipsec-request@ans.net Wed Apr 12 14:34:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24696 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 18:39:55 -0400 Received: by interlock.ans.net id AA36155 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 18:36:10 -0400 Message-Id: <199504122236.AA36155@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 18:36:10 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 18:36:10 -0400 To: ashar@osmosys.incog.com (Ashar Aziz) Cc: tytso@MIT.EDU, Danny.Nessett@eng.sun.com, ipsec@ans.net, linehan@watson.ibm.com Subject: Re: Bellovin's and Ashar's attacks Date: Wed, 12 Apr 95 18:34:53 EDT The implementation scenarios where this might be problematic is if there is crypto-hardware where key setup may take a while. Also, this is problematic if the cipher has a naturally long key-setup overhead. This isn't the case for a software implementation of DES-CBC. Actually, DES key setup in hardware is fast; at least one high-speed implementation (the Digital gigabit/second chip) can do it at line speed or better. Caching large numbers of keys is more problematic for many hardware implementations. From ipsec-request@ans.net Wed Apr 12 22:43:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21724 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 18:47:52 -0400 Received: by interlock.ans.net id AA36605 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 18:45:46 -0400 Message-Id: <199504122245.AA36605@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 12 Apr 1995 18:45:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 18:45:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 18:45:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 18:45:46 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 18:45:46 -0400 Date: Wed, 12 Apr 1995 15:43:29 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: smb@research.att.com, tytso@MIT.EDU, ashar@osmosys.incog.com Subject: Re: Bellovin's and Ashar's attacks Cc: ipsec@ans.net, linehan@watson.ibm.com X-Sun-Charset: US-ASCII Ashar, While it is theoretically true that : > The implementation scenarios where this might be problematic > is if there is crypto-hardware where key setup may take > a while. Also, this is problematic if the cipher has > a naturally long key-setup overhead. This isn't the case > for a software implementation of DES-CBC. > I don't think this is going to be a factor in practice. Since encryption is taking place at the IP layer, there can be no expectation that rekeying will not occur on each packet. IP packets can be coming from all over the place and will produce a jumble. Any ESP implementation will have to deal with frequent rekeying, although some operational environments may not require it, e.g., where a machine is encrypting traffic to only one other machine. Dan From ipsec-request@ans.net Wed Apr 12 14:54:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24634 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 18:58:02 -0400 Received: by interlock.ans.net id AA05479 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 18:55:17 -0400 Message-Id: <199504122255.AA05479@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 18:55:17 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 18:55:17 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 18:55:17 -0400 To: pau@watson.ibm.com (Pau-Chen Cheng) Cc: ipsec@ans.net Subject: Re: Bellovin's and Ahar's attacks In-Reply-To: Your message of "Wed, 12 Apr 1995 18:20:47 CDT." <199504122223.AA11372@interlock.ans.net> Date: Wed, 12 Apr 1995 18:54:57 EDT From: Derek Atkins > 4. When receiving a UDP message, examine the time stamp, discard any message > that is too old (e.g., more than twice the network latency). How can you make an arbitrary decision like this? What happens if there is a network burp on the nice fiber I use, and my packet gets routed across a satellite link instead? Are you proposing that my packet be ignored because it took an alternate route? I thought that alternate routing was one of the features of TCP/IP, and you're proposing we throw that away? I would hope not. Perhaps instead of using network latency, you use some other measure to time out a packet. You could use some arbitrary time measurement like 5 minutes, or you could use some other method. But just using the network latency, which can be very dynamic over congested or long-distance paths, is probably a sub-optimal solution. -derek Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) Home page: http://www.mit.edu:8001/people/warlord/home_page.html warlord@MIT.EDU PP-ASEL N1NWH PGP key available From ipsec-request@ans.net Thu Apr 13 00:04:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08151 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 20:16:28 -0400 Received: by interlock.ans.net id AA19997 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 20:05:29 -0400 Message-Id: <199504130005.AA19997@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 12 Apr 1995 20:05:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 12 Apr 1995 20:05:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 20:05:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 20:05:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 20:05:29 -0400 Date: Wed, 12 Apr 1995 17:04:31 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: linehan@watson.ibm.com Subject: Re: Bellovin's and Ahar's attacks Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Mark, I don't quite understand your suggestion : > 1. If the IPSEC processing is happening within the destination system, > then it should rekey every time a socket is closed. This ensures that > any subsequent user of the same port will get a different key. IPSEC processing will happen both on the source and destination systems. The destination can't rekey unilaterally, since the source would still be using the old key. So there has to be synchronization between the source and destination when rekeying occurs. Its been known for a long time that TCP connections could support rekeying when they open a connection. However, UDP doesn't support the notion of a connection, so rekeying UDP end-points requires some external synchronization. Dan From ipsec-request@ans.net Thu Apr 13 00:36:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14750 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 20:41:44 -0400 Received: by interlock.ans.net id AA30345 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 20:36:50 -0400 Message-Id: <199504130036.AA30345@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 12 Apr 1995 20:36:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 20:36:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 20:36:50 -0400 Date: Wed, 12 Apr 1995 17:36:40 -0700 From: Hilarie Orman To: Danny.Nessett@eng.sun.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199504130005.AA19997@interlock.ans.net> Subject: Re: Bellovin's and Ahar's attacks > IPSEC processing will happen both on the source and destination systems. The > destination can't rekey unilaterally, since the source would still be using > the old key. > ... However, > UDP doesn't support the notion of a connection, so rekeying UDP end-points > requires some external synchronization. If this is done in conjunction with socket close, a non-graceful operation for a connectionless protocol, it seems OK. In that case, the destination can rekey unilaterally, because UDP does not support the notion of a connection. The source just loses. If it is unhappy, it can use TCP. From ipsec-request@ans.net Wed Apr 12 16:52:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24659 (5.65c/IDA-1.4.4 for ); Wed, 12 Apr 1995 21:06:02 -0400 Received: by interlock.ans.net id AA46403 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 12 Apr 1995 20:59:36 -0400 Message-Id: <199504130059.AA46403@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 12 Apr 1995 20:59:36 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 12 Apr 1995 20:59:36 -0400 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: linehan@watson.ibm.com, ipsec@ans.net Subject: Re: Bellovin's and Ahar's attacks Date: Wed, 12 Apr 95 20:52:42 EDT IPSEC processing will happen both on the source and destination systems. The destination can't rekey unilaterally, since the source would still be using the old key. So there has to be synchronization between the source and destination when rekeying occurs. Its been known for a long time that TCP connections could support rekeying when they open a connection. However, UDP doesn't support the notion of a connection, so rekeying UDP end-points requires some external synchronization. I suspect that it will take a bit of experimentation to determine what's really the best course. However, if one end of the UDP association has terminated, its socket is unbound, and hence the key tied to it is released. If a new user allocates that port number, a different key (and SPI) will be allocated. A packet from its former peer, encrypted with the old key, will be bounced via (authenticated?) ICMP. This doesn't work for router-based encryptors; however, I've concluded that we need to refine our model there. Rather, we need to make explicit our assumptions. By *definition*, the net behind a router-based encryptor is trusted, and is at (more or less) the same security level. We must still contend with the problem of an internal net that is physically secure, and hence proof against internal eavesdroppers, while still finding a defense against corrupt insiders who reinject encrypted packets on the outside net. It's important not to confuse the replay attack with my CBC cut-and-paste attack. The latter is comparatively easy to counter, either by per-packet rekeying (which SKIP could do architecturally, albeit at some cost), per- user or per-connection keying, or mandatory integrity checks. The former can't be countered by SKIP or by integrity checks, though per-connection or per-user keying would work. For a router-based encryptor, though, replays seem to be preventable only by keeping track of old packets, and rekeying whenever the cache is full. From ipsec-request@ans.net Thu Apr 13 11:06:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04170 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 07:31:54 -0400 Received: by interlock.ans.net id AA20751 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 07:12:06 -0400 Message-Id: <199504131112.AA20751@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 07:12:06 -0400 From: Ran Atkinson Date: Thu, 13 Apr 1995 07:06:13 -0400 In-Reply-To: pau@watson.ibm.com (Pau-Chen Cheng) "Re: Bellovin's and Ahar's attacks" (Apr 12, 18:20) References: <199504122223.AA11372@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Pau-Chen Cheng Subject: Re: Bellovin's and Ahar's attacks Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil The assumptions about the ability of systems to maintain time are not reasonable in the Internet. Hence, the rest of your note is not terribly meaningful. Please let us try to keep the discussion focused on The Internet and not make any assumptions unless we can show that those assumptions really are reasonable in the deployed Internet. Thanks, Ran From ipsec-request@ans.net Thu Apr 13 11:13:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28751 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 07:33:23 -0400 Received: by interlock.ans.net id AA02859 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 07:17:55 -0400 Message-Id: <199504131117.AA02859@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 07:17:55 -0400 From: Ran Atkinson Date: Thu, 13 Apr 1995 07:13:01 -0400 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: Bellovin's and Ashar's attacks" (Apr 12, 15:43) References: <199504122245.AA36605@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett Subject: Re: Bellovin's and Ashar's attacks Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil On Apr 12, 15:43, Dan Nessett wrote: % Since encryption is taking place at the IP layer, there can be no % expectation that rekeying will not occur on each packet. IP packets % can be coming from all over the place and will produce a jumble. Any % ESP implementation will have to deal with frequent rekeying, although % some operational environments may not require it, e.g., where a % machine is encrypting traffic to only one other machine. Hmm. Actually, ESP is _both_ an IP encryptor and also a transport-layer encryptor, depending on how a particular session is setup. It is important for everyone to keep this in mind. The working group name is somewhat misleading by accident because folks think it is restricted to the IP-layer. No such restriction exists in either AH or ESP. As an aside, one of the things I've not been good about making clear in my notes is that my interest in user-oriented keying has much to do with the use of ESP as a transport-layer encryptor. Now back to editing... Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Apr 13 12:34:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16655 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 08:41:03 -0400 Received: by interlock.ans.net id AA12650 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 08:35:33 -0400 Message-Id: <199504131235.AA12650@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 08:35:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 08:35:33 -0400 From: bmanning@ISI.EDU Posted-Date: Thu, 13 Apr 1995 05:34:07 -0700 (PDT) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 08:35:33 -0400 Subject: Re: Bellovin's and Ashar's attacks To: smb@research.att.com Date: Thu, 13 Apr 1995 05:34:07 -0700 (PDT) Cc: ashar@osmosys.incog.com, tytso@MIT.EDU, Danny.Nessett@eng.sun.com, ipsec@ans.net, linehan@watson.ibm.com In-Reply-To: <199504122236.AA36155@interlock.ans.net> from "smb@research.att.com" at Apr 12, 95 06:34:53 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 347 > Actually, DES key setup in hardware is fast; at least one high-speed > implementation (the Digital gigabit/second chip) can do it at line speed > or better. Caching large numbers of keys is more problematic for many > hardware implementations. > And line speed here is defined as.... (Will it work at speed on our 600Mbps Lan?) -- --bill From ipsec-request@ans.net Thu Apr 13 09:06:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12728 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 09:06:39 -0400 Received: by interlock.ans.net id AA13919 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 08:59:51 -0400 Message-Id: <199504131259.AA13919@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 08:59:51 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 08:59:51 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 08:59:51 -0400 Date: Thu, 13 Apr 95 05:45:40 From: "Housley, Russ" Encoding: 885 Text To: linehan@watson.ibm.com, Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipsec@ans.net Subject: Re[2]: Bellovin's and Ahar's attacks Dan: >> 1. If the IPSEC processing is happening within the destination system, >> then it should rekey every time a socket is closed. This ensures that >> any subsequent user of the same port will get a different key. > > IPSEC processing will happen both on the source and destination systems. > The destination can't rekey unilaterally, since the source would still be > using the old key. So there has to be synchronization between the source > and destination when rekeying occurs. Its been known for a long time that > TCP connections could support rekeying when they open a connection. > However, UDP doesn't support the notion of a connection, so rekeying UDP > end-points requires some external synchronization. This is why IEEE 802.10c includes the DELETE-SA service. One system can tell the other that it is finished with the key.... Russ From ipsec-request@ans.net Thu Apr 13 13:18:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24632 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 09:29:46 -0400 Received: by interlock.ans.net id AA28581 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 09:23:29 -0400 Message-Id: <199504131323.AA28581@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 09:23:29 -0400 From: Ran Atkinson Date: Thu, 13 Apr 1995 09:18:24 -0400 In-Reply-To: "Housley, Russ" "Re[2]: Bellovin's and Ahar's attacks" (Apr 13, 5:45) References: <199504131259.AA13919@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: "Housley, Russ" Subject: Security Association Mgmt Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Russ, I agree. IMHO, the ability to support the capabilities such as DELETE-SA are something we do need. I'm thinking that if the NSA draft evolves in an appropriate manner, it might well address/solve those kinds of issues. However, I think the folks at NSA need to fill out more of their draft before this will become clear. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Apr 13 15:06:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22848 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 10:18:56 -0400 Received: by interlock.ans.net id AA24215 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 10:10:33 -0400 Message-Id: <199504131410.AA24215@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 13 Apr 1995 10:10:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 10:10:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 10:10:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 10:10:33 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 10:10:33 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) X-Mailer: exmh version 1.5.3 12/28/94 To: Derek Atkins Cc: ipsec@ans.net Subject: Re: Bellovin's and Ahar's attacks In-Reply-To: (Your message of Wed, 12 Apr 95 18:54:57 EDT.) <9504122255.AA11682@josquin.media.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Apr 95 10:06:43 -0500 > > 4. When receiving a UDP message, examine the time stamp, discard any message > > that is too old (e.g., more than twice the network latency). ^^^^ Derek, it is only meant to be an example. And I agree with you. Using some other measure like the minimum time a port number will be held is a better way. Regards, Pau-Chen > > How can you make an arbitrary decision like this? What happens if > there is a network burp on the nice fiber I use, and my packet gets > routed across a satellite link instead? Are you proposing that my > packet be ignored because it took an alternate route? > > I thought that alternate routing was one of the features of TCP/IP, > and you're proposing we throw that away? I would hope not. > > Perhaps instead of using network latency, you use some other measure > to time out a packet. You could use some arbitrary time measurement > like 5 minutes, or you could use some other method. But just using > the network latency, which can be very dynamic over congested or > long-distance paths, is probably a sub-optimal solution. > > -derek > > Derek Atkins, SB '93 MIT EE, G MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > Home page: http://www.mit.edu:8001/people/warlord/home_page.html > warlord@MIT.EDU PP-ASEL N1NWH PGP key available From ipsec-request@ans.net Thu Apr 13 15:18:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21651 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 10:28:50 -0400 Received: by interlock.ans.net id AA48043 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 10:21:20 -0400 Message-Id: <199504131421.AA48043@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 13 Apr 1995 10:21:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 10:21:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 10:21:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 10:21:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 10:21:20 -0400 From: pau@watson.ibm.com (Pau-Chen Cheng) X-Mailer: exmh version 1.5.3 12/28/94 To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net Subject: Re: Bellovin's and Ahar's attacks In-Reply-To: (Your message of Thu, 13 Apr 95 07:06:13 D.) <9504130706.ZM4230@bodhi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Apr 95 10:18:55 -0500 > The assumptions about the ability of systems to maintain time > are not reasonable in the Internet. > ...... > Ran Ran, I respectfully disagree with you on this point. My understanding is that any TCP/IP implementation needs a time-out-retransmission mechanism. Photuris also needs one. IMHO, this implies a clock is needed. Please note that my outline DOES NOT require synchronized clock. It only assumes clocks advance at about the same rate; i.e, if my clock's reading is increased by 1 second, the other clocks' readings will also be increased by 1 second within ~1 second's real time. If this assumption is wrong, I would appreciate if somebody can educate me or give me a pointer to related literatures. Thanks in advance. Regards, Pau-Chen From ipsec-request@ans.net Thu Apr 13 14:55:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14791 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 11:02:27 -0400 Received: by interlock.ans.net id AA39843 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 10:56:32 -0400 Message-Id: <199504131456.AA39843@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 13 Apr 1995 10:56:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 10:56:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 10:56:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 10:56:32 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 10:56:32 -0400 Date: Thu, 13 Apr 1995 07:55:31 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: atkinson@itd.nrl.navy.mil Subject: Re: Bellovin's and Ashar's attacks Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Ran, Your clarification that : > As an aside, one of the things I've not been good about making clear > in my notes is that my interest in user-oriented keying has much to do > with the use of ESP as a transport-layer encryptor. raises a question in my mind. I'm not sure how an ESP protected packet can be demultiplexed by the IP layer, so it can be routed to the appropriate transport layer code, without first decrypting it. According to the I-D, the ESP header contains no information that would allow this. Is there an implicit assumption that the ESP "header" is actually the payload of an upper layer protocol field? Dan From ipsec-request@ans.net Thu Apr 13 07:39:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05519 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 11:52:54 -0400 Received: by interlock.ans.net id AA06065 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 11:45:27 -0400 Message-Id: <199504131545.AA06065@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 11:45:27 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 11:45:27 -0400 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipsec@ans.net, linehan@watson.ibm.com, ashar@jurassic.eng.sun.com Subject: Re: Bellovin's and Ahar's attacks Date: Thu, 13 Apr 95 11:39:25 EDT I agree that rapid rekeying is a good idea. However, it isn't sufficient for all cases. By the way, the replay attack Ashar suggests relies on the ability of n intruder running on a machine discovering which port to use to receive the replayed traffic. Since ESP hides this information in the encrypted part, the intruder must use indirect methods to discover this. Or commands like ``lsof'', ``netstat'', and the like. Allowing the intruder to be on the same machine is a very high hurdle to surmount. From ipsec-request@ans.net Thu Apr 13 11:53:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24215 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 11:53:08 -0400 Received: by interlock.ans.net id AA39373 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 11:46:57 -0400 Message-Id: <199504131546.AA39373@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Thu, 13 Apr 1995 11:46:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 13 Apr 1995 11:46:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 11:46:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 11:46:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 11:46:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 11:46:57 -0400 To: Dan Nessett Cc: ipsec From: Mark H Linehan/Watson/IBM Research Date: 13 Apr 95 11:46:18 Subject: Re: Bellovin's and Ahar's attacks Mime-Version: 1.0 Content-Type: Text/Plain Danny said: >IPSEC processing will happen both on the source and destination >systems. The >destination can't rekey unilaterally, since the source would still be >using >the old key. So there has to be synchronization between the source >and >destination when rekeying occurs. The destination "owns" the SPI and security association, so it certainly can initiate a new key-management exchange to tell the source to start using a new SPI and new key. However, there is a definite problem here. The destination has to allow for the fact that the source will continue to use the old SPI for some time. During that time, the destination has to be willing to accept data under the old SPI since the alternative is to stop communication for awhile. This opens a period during which Ashar's replay attack would succeed. Not good. We can minimize but not close this hole by careful engineering of the re-key protocol. For example, we can require that the source respond to the re-key and that the destination delete the old SPI when it gets the response or after a timeout, whichever is sooner. Then the replay attack can only last as long as the timeout and then only if the attacker somehow intercepts the re-key response. We could also get fancy and have the key management protocol keep a running estimate of the round-trip time and set the timeout accordingly. > Its been known for a long time that >TCP connections could support rekeying when they open a >connection. However, >UDP doesn't support the notion of a connection, so rekeying UDP >end-points >requires some external synchronization. IPSEC re-keying is NOT an extension to the TCP or UDP protocol; it is external to both of those protocols. I propose that it could be triggered by the fact that a socket is closed, not that it be part of TCP or UDP. From ipsec-request@ans.net Thu Apr 13 12:13:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29559 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 12:13:30 -0400 Received: by interlock.ans.net id AA32124 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 12:06:57 -0400 Message-Id: <199504131606.AA32124@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Thu, 13 Apr 1995 12:06:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 13 Apr 1995 12:06:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 12:06:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 12:06:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 12:06:57 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 12:06:57 -0400 To: Ran Atkinson Cc: Dan Nessett , ipsec From: Mark H Linehan/Watson/IBM Research Date: 13 Apr 95 12:06:21 Subject: Re: Bellovin's and Ashar's attacks Mime-Version: 1.0 Content-Type: Text/Plain Ran said: >Hmm. Actually, ESP is _both_ an IP encryptor and also a >transport-layer encryptor, depending on how a particular session is >setup. It is important for everyone to keep this in mind. The >working group name is somewhat misleading by accident because >folks >think it is restricted to the IP-layer. No such restriction exists >in either AH or ESP. >As an aside, one of the things I've not been good about making clear >in my notes is that my interest in user-oriented keying has much to do >with the use of ESP as a transport-layer encryptor. I've been meaning to question this idea of encrypting only the transport data. It seems pretty innocuous until it leads us to issues such as user-oriented keying. I'm concerned that this is a case of "creeping featurism" and that it is making the IPSEC objectives too large and too complex. Remember the continuing demand from many quarters to get IPSEC finished and how there's been real difficulty over time concluding on specific solutions. Remember also that the most effective security mechanisms typically are the ones that are the simplest and most effectively focussed. Both the name and most of the work in IPSEC has been addressed to network-layer security. I respectfully suggest that if there's a real demand for transport-layer security services, then there should be TCP security and UDP security working groups assigned to consider modifying those protocols. From ipsec-request@ans.net Thu Apr 13 16:22:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04127 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 12:36:53 -0400 Received: by interlock.ans.net id AA39348 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 12:27:43 -0400 Message-Id: <199504131627.AA39348@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 12:27:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 12:27:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 12:27:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 12:27:43 -0400 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipsec@ans.net Subject: Re: Bellovin's and Ashar's attacks In-Reply-To: Your message of "Thu, 13 Apr 1995 07:55:31 PDT." <199504131456.AA39843@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 13 Apr 1995 12:22:16 -0400 From: "Perry E. Metzger" Dan Nessett says: > Your clarification that : > > > As an aside, one of the things I've not been good about making clear > > in my notes is that my interest in user-oriented keying has much to do > > with the use of ESP as a transport-layer encryptor. > > raises a question in my mind. I'm not sure how an ESP protected > packet can be demultiplexed by the IP layer, so it can be routed to > the appropriate transport layer code, without first decrypting > it. It can't. You decrypt it first and then pass it along with information to the transport that indicates what the transform that had been used for the encapsulation was before you unencapsulated the packet. Perry From ipsec-request@ans.net Thu Apr 13 16:35:05 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09538 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 12:42:39 -0400 Received: by interlock.ans.net id AA22148 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 12:36:50 -0400 Message-Id: <199504131636.AA22148@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 13 Apr 1995 12:36:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 12:36:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 12:36:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 12:36:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 12:36:50 -0400 Date: Thu, 13 Apr 1995 09:35:05 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: perry@imsi.com Subject: Re: Bellovin's and Ashar's attacks Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Perry, In response to my question : > > I'm not sure how an ESP protected > > packet can be demultiplexed by the IP layer, so it can be routed to > > the appropriate transport layer code, without first decrypting > > it. you observe : > It can't. You decrypt it first and then pass it along with information > to the transport that indicates what the transform that had been used > for the encapsulation was before you unencapsulated the packet. This seems to confirm my original point that the IP layer will have to continually rekey in order to process arriving packets. One implementation strategy that could improve performance would be to devise (or use, if one already exists) a software version of DES that accepts an expanded key schedule as well as a traditional 64/56 bit key. Does anyone know if there are hardware version of DES that either accept key schedules or allow more than one to be cached within a chip? Dan From ipsec-request@ans.net Thu Apr 13 16:48:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24280 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 13:00:35 -0400 Received: by interlock.ans.net id AA37965 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 12:53:54 -0400 Message-Id: <199504131653.AA37965@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 12:53:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 12:53:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 12:53:54 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 12:53:54 -0400 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipsec@ans.net Subject: Re: Bellovin's and Ashar's attacks In-Reply-To: Your message of "Thu, 13 Apr 1995 09:35:05 PDT." <199504131635.JAA04240@elrond.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 13 Apr 1995 12:48:27 -0400 From: "Perry E. Metzger" Dan Nessett says: > > It can't. You decrypt it first and then pass it along with information > > to the transport that indicates what the transform that had been used > > for the encapsulation was before you unencapsulated the packet. > > This seems to confirm my original point that the IP layer will have to > continually rekey in order to process arriving packets. In my implementation, I have a key schedule associated with every SA structure, so I'm "rekeying" in the sense of using different keys for every packet, but you have to do this no matter what even in host to host keying. .pm From ipsec-request@ans.net Thu Apr 13 17:40:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09647 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 13:48:41 -0400 Received: by interlock.ans.net id AA37546 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 13:42:13 -0400 Message-Id: <199504131742.AA37546@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 13 Apr 1995 13:42:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 13:42:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 13:42:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 13:42:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 13:42:13 -0400 Date: Thu, 13 Apr 1995 10:40:59 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: linehan@watson.ibm.com Subject: Re: Bellovin's and Ahar's attacks Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Mark, I'm not sure I agree with your assertion that : > The destination "owns" the SPI and security association, so it certainly can > initiate a new key-management exchange to tell the source to start using a new > SPI and new key. In most models I have seen, the source contacts the destination through a key management protocol (either directly or using a support daemon on its machine) to establish an SPI. Once that is completed, there may be no way (short of something like the DELETE-SA in-band message that Russ Housley mentioned, which is used in IEEE 802.10c) for the destination to tell the source to start using a new SPI and key. Use of a DELETE-SA like message (using ICMP?) hasn't been discussed until very recently. If that is what you are proposing, then it needs to be discussed in some detail. Dan From ipsec-request@ans.net Thu Apr 13 09:50:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09692 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 13:55:04 -0400 Received: by interlock.ans.net id AA14011 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 13:52:25 -0400 Message-Id: <199504131752.AA14011@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 13:52:25 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 13:52:25 -0400 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: perry@imsi.com, ipsec@ans.net Subject: Re: Bellovin's and Ashar's attacks Date: Thu, 13 Apr 95 13:50:36 EDT One implementation strategy that could improve performance would be to devise (or use, if one already exists) a software version of DES that accepts an expanded key schedule as well as a traditional 64/56 bit key. Kerberos does this. Does anyone know if there are hardware version of DES that either accept key schedules or allow more than one to be cached within a chip? The AT&T DES chip of a few years ago (no longer made) could store four DES keys on chip. Caching probably isn't worth it; it's a lot of data to move around, doing so is at the least comparable to building the key schedule -- and that's quite fast in hardware. From ipsec-request@ans.net Thu Apr 13 18:05:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24733 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 14:10:08 -0400 Received: by interlock.ans.net id AA27414 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 14:06:50 -0400 Message-Id: <199504131806.AA27414@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 13 Apr 1995 14:06:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 14:06:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 14:06:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 14:06:50 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 14:06:50 -0400 Date: Thu, 13 Apr 1995 11:05:43 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: smb@research.att.com Subject: Re: Bellovin's and Ashar's attacks Cc: perry@imsi.com, ipsec@ans.net X-Sun-Charset: US-ASCII Steve, > Caching probably isn't worth it; it's a lot > of data to move around, doing so is at the least comparable to > building the key schedule -- and that's quite fast in hardware. > Sorry, my message wasn't clear on here. What I meant was caching key schedules within the chip itself, which is what I guess the AT&T chip did. With chip densities increasing dramatically, I don't think it is unreasonable to cache a very large number of key schedules on chip. Dan From ipsec-request@ans.net Thu Apr 13 11:00:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04112 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 15:04:45 -0400 Received: by interlock.ans.net id AA42934 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 15:01:18 -0400 Message-Id: <199504131901.AA42934@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 15:01:18 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 15:01:18 -0400 To: Mark H Linehan/Watson/IBM Research Cc: Ran Atkinson , Dan Nessett , ipsec Subject: Re: Bellovin's and Ashar's attacks Date: Thu, 13 Apr 95 15:00:49 EDT I've been meaning to question this idea of encrypting only the transport data. It seems pretty innocuous until it leads us to issues such as user-oriented keying. I'm concerned that this is a case of "creeping featurism" and that it is making the IPSEC objectives too large and too complex. ... Remember also that the most effective security mechanisms typically are the ones that are the simplest and most effectively focussed. You may be right -- but remember that the attacks we've been talking about for the last few days are hardest to deal with if one sticks strictly to network layer concepts. Ashar's attack -- a simple replay -- is difficult to counter because the the legitimate user and the enemy can occupy the same end point at different times. That is, it's perfectly reasonable to demand that a higher-level service or protocol be immune to replays -- but in this case, there are *two* services occupying the endpoint serially. Matt Blaze suggests that a sliding sequence number, a la the original swIPe protocol, is the best solution to the replay attacks. The original objection to the sequence numbering in swIPe -- and I concurred with the objectors -- was that either TCP or UDP-based services had to deal with replays anyway, so there was no point to replicating the mechanism. The model now is different, and we may wish to reopen that discussion. From ipsec-request@ans.net Thu Apr 13 19:33:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12672 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 15:38:11 -0400 Received: by interlock.ans.net id AA11856 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 15:33:42 -0400 Message-Id: <199504131933.AA11856@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 15:33:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 15:33:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 15:33:42 -0400 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: smb@research.att.com, perry@imsi.com, ipsec@ans.net Subject: Re: Bellovin's and Ashar's attacks In-Reply-To: Danny.Nessett's message of Thu, 13 Apr 1995 11:05:43 -0700. <199504131806.AA27414@interlock.ans.net> Date: Thu, 13 Apr 1995 15:33:36 -0400 From: Bill Sommerfeld Sorry, my message wasn't clear on here. What I meant was caching key schedul es within the chip itself, which is what I guess the AT&T chip did. With chip densities increasing dramatically, I don't think it is unreasonable to cache a very large number of key schedules on chip. I wondered about this, and took a look at the key schedule expansion algorithm. I'm not a EE or VLSI designer, but as best I can tell.. DES key schedule expansion in hardware *isn't slow*. It can be implemented in hardware with a pair of 28-bit circular shift registers and 48 wires, generating one subkey per clock cycle. The only complication is that you occasionally need to "double-shift" the registers. You can do this in parallel with the encryption, producing the subkeys only as they're needed. Software implementations of DES typically expand the 64-bit key into 16 or 32 64-bit words, because bitwise permutations are expensive in software. But they're really cheap in hardware.. - Bill From ipsec-request@ans.net Thu Apr 13 10:45:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04329 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 15:47:36 -0400 Received: by interlock.ans.net id AA46903 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 15:45:17 -0400 Message-Id: <199504131945.AA46903@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 15:45:17 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 15:45:17 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 15:45:17 -0400 Date: Thu, 13 Apr 1995 15:45:00 +0500 From: Theodore Ts'o To: smb@research.att.com Cc: Danny.Nessett@eng.sun.com, perry@imsi.com, ipsec@ans.net In-Reply-To: smb@research.att.com's message of Thu, 13 Apr 95 13:50:36 EDT, <199504131752.AA14011@interlock.ans.net> Subject: Re: Bellovin's and Ashar's attacks Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1002 From: smb@research.att.com Date: Thu, 13 Apr 95 13:50:36 EDT One implementation strategy that could improve performance would be to devise (or use, if one already exists) a software version of DES that accepts an expanded key schedule as well as a traditional 64/56 bit key. Kerberos does this. Well, actually it's more accurate to say that the DES implementation which was shipped with Kerberos V4 (originally written by Steve Miller) allows for this. Most of the DES implementations floating around seem to use the same API --- especially the ones available from anonymous FTP from funet.fi.net. (I can't imagine why..... ) It makes sense though. In software the key scheduling does take a non-negligible amount of time, so it makes sense to have one routine for expanding the key into a key schedule, and then have all of your other DES routines take the key schedule as an argument. I'd rather suspect that nearly all DES implementations did this. - Ted From ipsec-request@ans.net Thu Apr 13 21:07:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15608 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 16:13:22 -0400 Received: by interlock.ans.net id AA46576 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 16:07:09 -0400 Message-Id: <199504132007.AA46576@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 13 Apr 1995 16:07:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 16:07:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 16:07:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 16:07:09 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 16:07:09 -0400 From: uri@watson.ibm.com Subject: Re: Bellovin's and Ahar's attacks To: warlord@MIT.EDU (Derek Atkins) Date: Thu, 13 Apr 1995 16:07:02 -0500 (EDT) Cc: pau@watson.ibm.com, ipsec@ans.net In-Reply-To: <199504122255.AA05479@interlock.ans.net> from "Derek Atkins" at Apr 12, 95 06:54:57 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 454 Derek Atkins says: > Perhaps instead of using network latency, you use some other measure > to time out a packet. I can't help but notice, that it seems like IP shouldn't really be secure from the Steve's attack at all. Maybe being host-to- host secure is good enough for Secure IP, and Socket Layer Security could take care of mutually agressive users [on the same host]? -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Thu Apr 13 12:29:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05565 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 16:42:27 -0400 Received: by interlock.ans.net id AA30641 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 16:37:14 -0400 Message-Id: <199504132037.AA30641@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 16:37:14 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 16:37:14 -0400 To: uri@watson.ibm.com Cc: warlord@MIT.EDU (Derek Atkins), pau@watson.ibm.com, ipsec@ans.net Subject: Re: Bellovin's and Ahar's attacks Date: Thu, 13 Apr 95 16:29:12 EDT Derek Atkins says: > Perhaps instead of using network latency, you use some other measure > to time out a packet. I can't help but notice, that it seems like IP shouldn't really be secure from the Steve's attack at all. Maybe being host-to- host secure is good enough for Secure IP, and Socket Layer Security could take care of mutually agressive users [on the same host]? I'm not sure that that's feasible with most of today's operating systems. From ipsec-request@ans.net Thu Apr 13 23:15:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14622 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 19:06:16 -0400 Received: by interlock.ans.net id AA27006 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 19:03:24 -0400 Message-Id: <199504132303.AA27006@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 19:03:24 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 19:03:24 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 19:03:24 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 19:03:24 -0400 Date: Thu, 13 Apr 1995 16:15:07 -0700 From: ashar@osmosys.incog.com (Ashar Aziz) To: smb@research.att.com Subject: Re: Bellovin's and Ashar's attacks Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From: smb@research.att.com > Matt Blaze suggests that a sliding sequence number, a la the original > swIPe protocol, is the best solution to the replay attacks. The > original objection to the sequence numbering in swIPe -- and I > concurred with the objectors -- was that either TCP or UDP-based > services had to deal with replays anyway, so there was no point to > replicating the mechanism. The model now is different, and we may wish > to reopen that discussion. I tend to favor this approach as well. We need to discuss how the sequence # will be used; as I recall swIPe used it as an IV, which wasn't universally accepted. Alternative mechanisms might be to use the sequence # to derive the traffic key somehow, if one wasn't computing a MAC over the sequence # plus packet. Other suggestions? Also we need to discuss fine-grain (per packet) or more coarse-grain sequencing (my last I-D discusses one way of achieving the latter). Regards, Ashar. From ipsec-request@ans.net Fri Apr 14 00:36:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07280 (5.65c/IDA-1.4.4 for ); Thu, 13 Apr 1995 20:40:51 -0400 Received: by interlock.ans.net id AA12149 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 13 Apr 1995 20:37:37 -0400 Message-Id: <199504140037.AA12149@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 13 Apr 1995 20:37:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 13 Apr 1995 20:37:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 13 Apr 1995 20:37:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 13 Apr 1995 20:37:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 13 Apr 1995 20:37:37 -0400 Date: Thu, 13 Apr 1995 17:36:21 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: tytso@MIT.EDU, smb@research.att.com Subject: Re: Bellovin's and Ahar's attacks Cc: ipsec@ans.net, linehan@watson.ibm.com X-Sun-Charset: US-ASCII Ted, I have not responded immediately to your message, since I knew a proper reply would take some time and I needed to get some other things done. However, I think I can now respond to your question. Specifically, you suggest : > To prevent the UDP attack of another user binding to the same UDP socket > and playing back the exact same packet, we'd also need per-user keying. And then you ask : > But it seems to me that protecting against these attacks is doable. > What am I missing? > My concern with per-user keying has stemmed from my inability to see how it will work in practice. Let me take more than the usual space to suggest where I see problems. Consider the admind daemon that is used in Solaris for system administration. This is the server that answers admintool requests. It is used for many purposes, but the one of interest in this discussion is managing user accounts. Specifically, you can install new users or modify their account information, including their passwords. While not true now, I think we can agree that when modifying a password entry in a table or database, the hashed passwd should not be transmitted in the clear. Doing so allows an intruder to execute a dictionary attack by simply sniffing the admind traffic. Consequently, there is at least one requirement that admind support encrypted traffic. Since IPSP supports encryption, it would be advantageous to use its services in support of admind. However, admind is fired up by inetd. So, it is inetd that listens waiting for requests. inetd registers admind's RPC program number with rpcbind, and services admintool requests. When one arrives, it forks admind to handle it. There is also a provision for keeping up admind for a few minutes after a request for better efficiency. Finally, admind uses UDP. So, how can admind use IP encryption services? Here are a few questions that have been bothering me : o How is inetd contacted by the key management software? Normally, inetd is sitting in a select call, waiting for activity on one of its file descriptors. Does there have to be a fd for communications with the key management software? If so, assuming that admind isn't the only inetd forked app that wants to use encryption, how does the key management software communicate with inetd and tell it which fd to "instrument" with a user's key? o How does the key management software know whether admind is already running? Of course, it can do a ps and look for its name, but how will it know what name to look for and how can it be sure that between the time it gets and processes the ps information, admind isn't started by inetd? How will admind be programmed so that it can talk with the key management software in the same way that inetd does? Recall that one reason for inetd is to simplify the daemons it forks. o Good cryptographic practice requires periodically changing keys based on how long they have been in existence as well as how much data they have encrypted. How will the key management software acquire these statistics? If it needs to expire a key that is currently "attached to" a port, how will the process that owns the port be contacted and instructed to exchange the key for another? How will the key management software know which processes to contact (after all, more than one process could be using a per-user key)? o What system chooses the user whose key will be used? There are two cases. If the client is the one that wants encrypted traffic, it will initiate the key management exchange. What user does it select? If it uses the uid of the process (limiting ourselves to Unix systems for the moment), how is that mapped into a user-identifier that the destination understands? If the server is the one requiring encrypted traffic, it will initiate the key management exchange. What user identifier will it use to identify the per-user key? This is just the beginning. I am fairly confident that once answers to these questions are developed, they will generate other questions. I really feel nervous about standardizing something that has no publically available worked example. Ran has promised to provide us with code that does per-user keying. Hopefully, this will happen fairly soon so that confidence can be built that this objective is achievable. Dan From ipsec-request@ans.net Fri Apr 14 08:51:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21582 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 08:51:46 -0400 Received: by interlock.ans.net id AA16411 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 08:48:48 -0400 Message-Id: <199504141248.AA16411@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 14 Apr 1995 08:48:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 08:48:48 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 08:48:48 -0400 Date: Fri, 14 Apr 95 05:33:17 From: "Housley, Russ" Encoding: 883 Text To: linehan@watson.ibm.com, smb@research.att.com Cc: rja@bodhi.cs.nrl.navy.mil, Danny.Nessett@eng.sun.com, ipsec@ans.net Subject: Re: Bellovin's and Ashar's attacks The attacks we've been talking about for the last few days are unrealistic. As pointed out by Steve Bellovin, a simple replay is difficult to counter because the the legitimate user and the attacker can occupy the same end point at different times. I think the situation is worse that indicated by Steve. If the attacker has access to a machine behind the firewall, then that attacker can simply listen to the plaintext traffic as it is sent from that host to the firewall. There is not reason to mount a complex replay attach -- just listen. I do not want to add a huge amount of complexity to protect against an attacker who can read the traffic before it even gets protected. If we want to protect data from other users of the same host, then the encryption better be applied before it is tranmitted at all. In other words, not firewall crypto. Russ From ipsec-request@ans.net Fri Apr 14 09:42:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14658 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 09:42:58 -0400 Received: by interlock.ans.net id AA46568 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 09:37:00 -0400 Message-Id: <199504141337.AA46568@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Fri, 14 Apr 1995 09:37:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 14 Apr 1995 09:37:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 14 Apr 1995 09:37:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 14 Apr 1995 09:37:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 09:37:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 09:37:00 -0400 To: Ashar Aziz Cc: smb , ipsec From: Mark H Linehan/Watson/IBM Research Date: 14 Apr 95 9:36:22 Subject: Re: Bellovin's and Ashar's attacks Mime-Version: 1.0 Content-Type: Text/Plain > From: smb@research.att.com > Matt Blaze suggests that a sliding sequence number, a la the original > swIPe protocol, is the best solution to the replay attacks. I agree that this seems like a better fix for Ashar's replay attacks than depending upon re-keying. If we follow Steve's suggestion that ESP require AH then we could put the sequence number in either the ESP or the authentication header. Putting it in the AH would have the advantage of also protecting AH against a replay attack. This makes some sense to me since Ashar's replay attack is really a takeover of the identify of the destination of some traffic. I think that we should specify that the sequence number for any given SPI starts randomly rather than at some fixed number like zero. In the case where an AH flows in the clear, it denies someone who taps part of the traffic any idea how many packets there have been since the SPI was created. In the case where an AH is encrypted within an ESP, it gives a little more randomness to the traffic pattern. Not a substitute for a formal IV, but a cheap way to get some more unpredictability into the clear text. From ipsec-request@ans.net Fri Apr 14 05:48:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14759 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 09:49:39 -0400 Received: by interlock.ans.net id AA04336 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 09:47:41 -0400 Message-Id: <199504141347.AA04336@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 09:47:41 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 09:47:41 -0400 Date: Fri, 14 Apr 95 09:48:25 EDT From: Robert Glenn To: ipsec@ans.net Subject: Who is developing? Has anyone generated a list of individuals or companies that are currently developing IPv4 & IPv6 implemenations (prototype or otherwise) of the AH, ESP, and KMP specifications? If so, could I get a copy of this list? If not, I'd be more than happy to generate one if the developers would send me a snipet of information that included Name of developer, hardware & software platform, summary of prototypes under development (ie., which stack, which specs, etc), and any other information you might want to include. Rob G. glenn@snad.ncsl.nist.gov From ipsec-request@ans.net Fri Apr 14 09:58:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09697 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 09:58:37 -0400 Received: by interlock.ans.net id AA13968 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 09:55:42 -0400 Message-Id: <199504141355.AA13968@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Fri, 14 Apr 1995 09:55:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 14 Apr 1995 09:55:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 14 Apr 1995 09:55:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 14 Apr 1995 09:55:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 09:55:42 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 09:55:42 -0400 To: "Housley Russ" Cc: smb , rja , "Danny.Nessett" , ipsec From: Mark H Linehan/Watson/IBM Research Date: 14 Apr 95 9:55:07 Subject: Re: Bellovin's and Ashar's attacks Mime-Version: 1.0 Content-Type: Text/Plain Russ makes the good point that: >If the attacker has access to a machine behind the firewall, then >that attacker can simply listen to the plaintext traffic as it is sent from >that host to the firewall. There is not reason to mount a complex >replay >attach -- just listen. I do not want to add a huge amount of complexity >to >protect against an attacker who can read the traffic before it even gets >protected. If we want to protect data from other users of the same >host, >then the encryption better be applied before it is tranmitted at all. In >other words, not firewall crypto. I'd like to extend this argument by an analogy: just as IPSEC between firewalls cannot protect against reading the clear-text traffic on the networks inside the firewalls, IPSEC between hosts cannot protect against reading the clear-text traffic within the hosts. Encryption applied at the network layer cannot protect against user1 spying on the traffic on user2's socket within the same host. Similarly, just as IPSEC between firewalls cannot completely protect against replay attacks done by hosts, IPSEC between hosts cannot completely protect against replay attacks mounted by users of those hosts. My argument here is against user-oriented keying. I argue that if it's important to authenticate or provide privacy of user1's data versus user2, the only way to really ensure it is at some layer higher than the network layer. Exactly because the network layer is a common resource shared by multiple users. From ipsec-request@ans.net Fri Apr 14 14:08:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05597 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 10:18:05 -0400 Received: by interlock.ans.net id AA25129 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 10:13:58 -0400 Message-Id: <199504141413.AA25129@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 10:13:58 -0400 From: Ran Atkinson Date: Fri, 14 Apr 1995 10:08:58 -0400 In-Reply-To: Mark H Linehan/Watson/IBM Research "Re: Bellovin's and Ashar's attacks" (Apr 14, 9:55) References: <9504141355.AA0731@watlny03.watson.ibm.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Mark H Linehan/Watson/IBM Research Subject: Re: Bellovin's and Ashar's attacks Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Mark, ESP is also a transport-layer encryptor, not just an IP-layer encryptor (read the draft). Your argument fails. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Apr 14 06:49:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07202 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 12:02:55 -0400 Received: by interlock.ans.net id AA38462 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 11:49:27 -0400 Message-Id: <199504141549.AA38462@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 14 Apr 1995 11:49:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 11:49:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 11:49:27 -0400 Date: Fri, 14 Apr 1995 11:49:16 +0500 From: Theodore Ts'o To: "Housley, Russ" Cc: linehan@watson.ibm.com, smb@research.att.com, rja@bodhi.cs.nrl.navy.mil, Danny.Nessett@eng.sun.com, ipsec@ans.net In-Reply-To: Housley, Russ's message of Fri, 14 Apr 95 05:33:17 , <199504141248.AA16411@interlock.ans.net> Subject: Re: Bellovin's and Ashar's attacks Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 790 Warning! Danger, Will Robinson! I detect a similar problem to what plagued the PEM working group ---- that is, people are talking past one another because different people have different ideas about what the protocol is supposed to accomplished. Russ brought up the concept of "firewall crypto", saying that it's a bad idea. Given that I believe firewalls in general are a bad idea, and that (IMO) IPSEC was supposed to significantly reduce the need for firewalls, I agree --- but I don't think anyone else was thinking about doing firewall crypto in recent discussions, either. So where did the idea of "firewall crypto" come from? We may need to take a step back and make sure we're all working from the same set of assumptions, as I'm not so sure that we are anymore. - Ted From ipsec-request@ans.net Fri Apr 14 16:11:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06666 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 12:27:49 -0400 Received: by interlock.ans.net id AA09958 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 12:13:14 -0400 Message-Id: <199504141613.AA09958@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 14 Apr 1995 12:13:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 14 Apr 1995 12:13:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 14 Apr 1995 12:13:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 12:13:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 12:13:14 -0400 Date: Fri, 14 Apr 1995 09:11:56 -0700 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: housley@spyrus.com, tytso@MIT.EDU Subject: Re: Bellovin's and Ashar's attacks Cc: linehan@watson.ibm.com, smb@research.att.com, rja@bodhi.cs.nrl.navy.mil, ipsec@ans.net X-Sun-Charset: US-ASCII Ted, Your suggestion that : > We may need to take a step back > and make sure we're all working from the same set of assumptions, as I'm > not so sure that we are anymore. is a good one. I suggest the following experiment in distributed collaborative work. Let's try to come up with a list of requirements/goals for IPSEC that we all can agree on. I will start the list (see below). Others can add requirements, propose that two or more requirements are subsumed in a more general requirement or object to requirements (and then post the modified list with them removed - however, I propose that removing a requirement should be supported by a well formed argument). If this experiment works, we should all see various versions of the list being posted and then finally converging to a common set. There are so many ways the experiment can fail that I will not enumerate them. IPSEC Requirements List ----------------------- o The IPSEC protocols should support both IPv4 and IPv6. o The IPSEC protocols should prevent an intruder with access to resources within a network from changing data sent between a source and destination that use these protocols without these changes being detected. o The IPSEC protocols should prevent an intruder with access to resources within a network from observing data sent between a source and destination that use these protocosl, if such data is protected from disclosure. o The IPSEC protocols should be useable between two firewalls. However, they provide no protection against attacks mounted from networks or hosts located on the trusted side of either firewall. o The IPSEC protocols should be useable between two machines. They should counter attacks by intruders with access to both the intervening network and as users of either machine. However, they will provide no protection against intruders that successfully compromise either machine. Dan From ipsec-request@ans.net Fri Apr 14 17:38:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21144 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 12:43:38 -0400 Received: by interlock.ans.net id AA39990 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 12:38:56 -0400 Message-Id: <199504141638.AA39990@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 14 Apr 1995 12:38:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 14 Apr 1995 12:38:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 14 Apr 1995 12:38:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 12:38:56 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 12:38:56 -0400 From: uri@watson.ibm.com Subject: Re: Bellovin's and Ashar's attacks To: Danny.Nessett@eng.sun.com (Dan Nessett) Date: Fri, 14 Apr 1995 12:38:23 -0500 (EDT) Cc: ipsec@ans.net In-Reply-To: <199504141613.AA09958@interlock.ans.net> from "Dan Nessett" at Apr 14, 95 09:11:56 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 804 Dan Nessett says: > is a good one. I suggest the following experiment in distributed collaborative > work. Let's try to come up with a list of requirements/goals for > IPSEC that we all can agree on. Good idea. I agree with all the goals you mentioned except the last one: > o The IPSEC protocols should be useable between two machines. They should > counter attacks by intruders with access to both the intervening > network and as users of either machine. However, they will provide > no protection against intruders that successfully compromise either > machine. I believe it's too much overhead and architechtural "uncleanness" to achieve this goal, which in my view belongs to the upper layers... -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Fri Apr 14 10:06:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21747 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 14:13:07 -0400 Received: by interlock.ans.net id AA13043 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 14:09:10 -0400 Message-Id: <199504141809.AA13043@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 14:09:10 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 14:09:10 -0400 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: tytso@MIT.EDU, ipsec@ans.net, linehan@watson.ibm.com Subject: Re: Bellovin's and Ahar's attacks Date: Fri, 14 Apr 95 14:06:28 EDT My concern with per-user keying has stemmed from my inability to see how it will work in practice. Let me take more than the usual space to suggest where I see problems. Consider the admind daemon that is used in Solaris for system administration. This is the server that answers admintool requests. It is used for many purposes, but the one of interest in this discussion is managing user accounts. Specifically, you can install new users or modify their account information, including their passwords. While not true now, I think we can agree that when modifying a password entry in a table or database, the hashed passwd should not be transmitted in the clear. I may or may not answer in more detail later, and if I do it won't be till next week; I have some seders to go to. For now, I'll say that the answer to your question is really a naming issue: how are the client and server named. My first cut at an answer is that clients have more or less arbitrary names not tied to an IP address or DNS host name (except for host-to-host services such as NFS), though the certificates probably live in the DNS tree via the same administrative structure. Servers are named by pairs -- the client knows the name of the destination, and wants to assure itself that it's talking to the right party. In your example, the client would ask for the certificate for something like kadmind@your.host.name. (No, I'm not recommending that syntax; I'm just looking for something that clearly and unambiguously denotes a service on a machine.) From ipsec-request@ans.net Fri Apr 14 10:27:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29593 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 14:32:18 -0400 Received: by interlock.ans.net id AA20282 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 14:29:27 -0400 Message-Id: <199504141829.AA20282@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 14:29:27 -0400 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 14:29:27 -0400 To: "Housley, Russ" Cc: linehan@watson.ibm.com, rja@bodhi.cs.nrl.navy.mil, Danny.Nessett@eng.sun.com, ipsec@ans.net Subject: Re: Bellovin's and Ashar's attacks Date: Fri, 14 Apr 95 14:27:04 EDT The attacks we've been talking about for the last few days are unrealistic. As pointed out by Steve Bellovin, a simple replay is difficult to counter because the the legitimate user and the attacker can occupy the same end point at different times. I think the situation is worse that indicated by Steve. If the attacker has access to a machine behind the firewall, then that attacker can simply listen to the plaintext traffic as it is sent from that host to the firewall. There is not reason to mount a complex replay attach -- just listen. I do not want to add a huge amount of complexity to protect against an attacker who can read the traffic before it even gets protected. If we want to protect data from other users of the same host, then the encryption better be applied before it is tranmitted at all. In other words, not firewall crypto. Router crypto can be used in several different ways; depending on your assumptions, different attacks may be possible. Consider, for example, an Internet service provider who offers shell acounts. (There are many such.) They may have a cluster of machines with a single high-end crypto box -- indeed, users may be assigned to an arbitrary box at login time. In this case, though, the users have no access to the physical cable plant -- but they can park themselves on arbitrary ports. Looked at more generically, the attacks we've been discussing involve two different shared resources: the host (for my CBC cut-and-paste attack, and the cable/router complex. If your enemies are only on the local machine, as above, the wiring isn't at issue. If your enemies are only outside the crypto box -- which is the case for many departmental LANs -- then router-based crypto is perfectly acceptable, and the risks we've been exploring here don't apply. (This case -- which I regard as common -- is why I use the term ``router-based crypto'' instead of ``firewall''. My departmental LAN is, as I've said before, a single multiprocessor machine with a funny backplane. (In deference to those who've switched to other physical media, I'll delete my usual description of ``long skinny yellow backplane.)) If your wiring is exposed, you have to move the crypto back to the host. From ipsec-request@ans.net Fri Apr 14 14:48:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06667 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 14:48:21 -0400 Received: by interlock.ans.net id AA49818 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 14:45:45 -0400 Message-Id: <199504141845.AA49818@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Fri, 14 Apr 1995 14:45:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 14 Apr 1995 14:45:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 14 Apr 1995 14:45:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 14 Apr 1995 14:45:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 14:45:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 14:45:45 -0400 To: Ran Atkinson Cc: ipsec From: Mark H Linehan/Watson/IBM Research Date: 14 Apr 95 14:45:26 Subject: Re: Bellovin's and Ashar's attacks Mime-Version: 1.0 Content-Type: Text/Plain Ran, ESP is also a transport-layer encryptor, not just an IP-layer encryptor (read the draft). Your argument fails. I'm not sure which argument you are referring to, since I've made several recently. Could you clarify? Are you contemplating implementing transport-mode ESP within the transport-layer (UDP or TCP or ICMP) code itself? From ipsec-request@ans.net Fri Apr 14 19:06:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21243 (5.65c/IDA-1.4.4 for ); Fri, 14 Apr 1995 15:12:29 -0400 Received: by interlock.ans.net id AA42041 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 14 Apr 1995 15:09:52 -0400 Message-Id: <199504141909.AA42041@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 14 Apr 1995 15:09:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 14 Apr 1995 15:09:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 14 Apr 1995 15:09:52 -0400 From: Steve Bellovin To: ipsec@ans.net Subject: analysis thus far Date: Fri, 14 Apr 1995 15:06:57 -0400 Sender: smb@research.att.com Warning -- wide (about 160 columns) message follows... I decided to make a chart of the different attacks and different defenses. There are four different attack scenarios listed: CBC cut-and-paste and replay, for both host-based and router-based cryptography. What jumps out from the chart is that no single defense proposed thus far is a complete solution, though a combination of sequence numbers with integrity checks comes closest. (It can fail against an active attack: the enemy can delete the last few packets, create a new socket using that port, and reinject the packets, so long as they arrive before the sequence window has expired.) It's also apparent that router-based crypto is very hard to defend against any of these attacks, especially the replay. I'm tentatively inclined to stop hardening our mechanisms against that case, and instead decree that router-based crypto is useful if and only if (a) everyone on the inside is trustable (but see below), or (b) it's being used as firewall crypto to superencrypt already-protected traffic when using the public Internet as a link in a virtual private net. The remaining case that troubles me is the host-to-router case, where I, on my host, am doing the right things, but I'm talking to you on your account on bletch.com (foo.com and foobar.com are real!). Can you read my traffic? Probably, given the stuff we've been discussing. But that's also the case if you're doing any of myriad other things wrong, or if you've been hacked, so it's probably not worth worrying about here. It might, though, be worth including a flag in the certificate indicating the granularity of protection. The chart is below; I'm quite willing to add new rows or columns, or to change entries as needed, or to reformat it to use tbl or LaTeX tables... ----- Host-based Host-based Router-based Router-based CBC cut-and-paste Replay CBC cut-and-paste Replay ----------------- ----------------- ----------------- ----------------- User-pair keying safe safe hard to implement hard to implement Connection keying safe safe hard to implement hard to implement Per-packet rekey safe no defense safe no defense (SKIP-style) Sequence numbers no protection against some protection against no protection against some protection against w/host-pair keying active attack unless active attack; late packets active attack unless active attack; late packets integrity used also; may be decipherable integrity used also; may be decipherable safe if integrity used safe if integrity used Integrity checks safe no protection safe no protection Notes: ``safe'' means that the mechanism appears to defeat the attack. ``no protection'' means that the attack still works. ``hard to implement'' means that there are conceptual problems or that other necessary pieces have not yet been defined, such as host-to-router messages. From ipsec-request@ans.net Mon Apr 17 08:51:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24850 (5.65c/IDA-1.4.4 for ); Mon, 17 Apr 1995 08:51:26 -0400 Received: by interlock.ans.net id AA04887 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 17 Apr 1995 08:47:05 -0400 Message-Id: <199504171247.AA04887@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 17 Apr 1995 08:47:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 17 Apr 1995 08:47:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 17 Apr 1995 08:47:05 -0400 Date: Mon, 17 Apr 95 05:29:29 From: "Housley, Russ" Encoding: 2993 Text To: smb@research.att.com Cc: ipsec@ans.net Subject: Re: Bellovin's and Ashar's attacks The attacks we've been talking about for the last few days are unrealistic. As pointed out by Steve Bellovin, a simple replay is difficult to counter because the the legitimate user and the attacker can occupy the same end point at different times. I think the situation is worse that indicated by Steve. If the attacker has access to a machine behind the firewall, then that attacker can simply listen to the plaintext traffic as it is sent from that host to the firewall. There is not reason to mount a complex replay attach -- just listen. I do not want to add a huge amount of complexity to protect against an attacker who can read the traffic before it even gets protected. If we want to protect data from other users of the same host, then the encryption better be applied before it is tranmitted at all. In other words, not firewall crypto. Router crypto can be used in several different ways; depending on your assumptions, different attacks may be possible. Consider, for example, an Internet service provider who offers shell acounts. (There are many such.) They may have a cluster of machines with a single high-end crypto box -- indeed, users may be assigned to an arbitrary box at login time. In this case, though, the users have no access to the physical cable plant -- but they can park themselves on arbitrary ports. They can also run arbitrary programs, including sniffers. Looked at more generically, the attacks we've been discussing involve two different shared resources: the host (for my CBC cut-and-paste attack, and the cable/router complex. If your enemies are only on the local machine, as above, the wiring isn't at issue. If your enemies are only outside the crypto box -- which is the case for many departmental LANs -- then router-based crypto is perfectly acceptable, and the risks we've been exploring here don't apply. (This case -- which I regard as common -- is why I use the term ``router-based crypto'' instead of ``firewall''. My departmental LAN is, as I've said before, a single multiprocessor machine with a funny backplane. (In deference to those who've switched to other physical media, I'll delete my usual description of ``long skinny yellow backplane.)) If your wiring is exposed, you have to move the crypto back to the host. In the case of the shared host, we need to ensure that the protocol conveys information necessary to prevent leakage when the enemies serially reuse the same resource, a port in the recent examples. discading the key when the port is closed sounds great. Better yet, Discard the key and tell the other key management daemon that you did it. In the shared comms case, I have a real hard time. If your enemy is sharing the comms between you and your crypto, then you shouldn't bther with the crypto at all. Russ From ipsec-request@ans.net Mon Apr 17 12:29:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12849 (5.65c/IDA-1.4.4 for ); Mon, 17 Apr 1995 12:29:45 -0400 Received: by interlock.ans.net id AA36387 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 17 Apr 1995 12:26:23 -0400 Message-Id: <199504171626.AA36387@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-6); Mon, 17 Apr 1995 12:26:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 17 Apr 1995 12:26:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 17 Apr 1995 12:26:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 17 Apr 1995 12:26:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 17 Apr 1995 12:26:23 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 17 Apr 1995 12:26:23 -0400 To: Steve Bellovin Cc: ipsec From: Mark H Linehan/Watson/IBM Research Date: 17 Apr 95 11:30:34 Subject: Re: analysis thus far Mime-Version: 1.0 Content-Type: Text/Plain Steve's table makes a pretty good argument for using sequence numbers w/host-pair keying and integrity checks. I agree with his statement about router-based crypto. From ipsec-request@ans.net Mon Apr 17 18:00:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16656 (5.65c/IDA-1.4.4 for ); Mon, 17 Apr 1995 13:51:58 -0400 Received: by interlock.ans.net id AA38043 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 17 Apr 1995 13:48:40 -0400 Message-Id: <199504171748.AA38043@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 17 Apr 1995 13:48:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 17 Apr 1995 13:48:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 17 Apr 1995 13:48:40 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 17 Apr 1995 13:48:40 -0400 Date: Mon, 17 Apr 1995 11:00:15 -0700 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net, smb@research.att.com Subject: Re: analysis thus far X-Sun-Charset: US-ASCII Steve, Thanks for providing the table. It looks like a useful way of comparing the various options. I have on or two suggestions to add to the table. On the column side, there should be two extra columns showing the additional overhead of the solution, both in terms of packet and CPU overhead. On the row side (the counter-measures), I would like to add another option, which for lack of a better word I'll call "sequenced packet re-key". Essentially, the ESP packet contains a sliding sequence #, in addition to the information it currently contains. Each packet is encrypted in a key (call it Kp) derived from the current session key (call it Ks) and the sequence # ("n") as follows. Kp = h(Ks, n), where h is a pseudo-random function (e.g. MD5) This means that each packet is encrypted in a unique key, and it is also sequenced. The only packet space overhead that this entails is that of the sequence # (say 32 bits). Also, this naturally sequences the packets. The additional CPU overhead that this entails is that of computing the hash function over (Ks + n). By proper padding to MD5 block size, the hash of Ks can be pre-computed. This means that at run time, only a hash over the sequence # needs to be computed. By contrast, for integrity with sequencing, one needs to compute a hash over the entire packet plus sequence number, as well as carry the MAC and the sequence # in every packet. The sequenced packet re-key option does as well as the "integrity + sequence #" option in terms of defending against both the CBC cut-and-paste and replay attacks, at less cost in packet space, and far less computational cost. (The usual caveat of key-setup times applies). Of course, if the service needs AH functionality, then the integrity plus sequence # is the natural answer. Just something else to consider. Regards, Ashar. From ipsec-request@ans.net Mon Apr 17 18:09:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09686 (5.65c/IDA-1.4.4 for ); Mon, 17 Apr 1995 14:11:53 -0400 Received: by interlock.ans.net id AA41509 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 17 Apr 1995 14:09:43 -0400 Message-Id: <199504171809.AA41509@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 17 Apr 1995 14:09:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 17 Apr 1995 14:09:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 17 Apr 1995 14:09:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 17 Apr 1995 14:09:43 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 17 Apr 1995 14:09:43 -0400 X-Mailer: exmh version 1.5.3 12/28/94 To: "Housley, Russ" Cc: smb@research.att.com, ipsec@ans.net Subject: Re: Bellovin's and Ashar's attacks In-Reply-To: Your message of "Mon, 17 Apr 1995 05:29:29." <199504171247.AA04887@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Apr 1995 14:09:22 -0400 From: " " Russ says: > > In the case of the shared host, we need to ensure that the protocol > conveys information necessary to prevent leakage when the enemies > serially reuse the same resource, a port in the recent examples. > discading the key when the port is closed sounds great. Better yet, > Discard the key and tell the other key management daemon that you did > it. This is fine when the host is running IP-SEC. The problem persists if the host is unmodified and IP-SEC is done at a firewall/encrypting router. In this case, the firewall would not know that the port was closed. The only solutions so far are fast re-key and counters; both are, as pointed out on the list, imperfect as they still allow an attacker to re-play packets within the timeout period (both methods must allow time-out period of at least the maximal allowable round trip delay). For manual attackers this may be OK, but, as was pointed out, one could run a program that constantly looks for closed ports and immediately tries to replay traffic. This attack is possible, but if fast re-keying is used, it is very difficult if not unrealistic, and the gain is limited (just the last few packets before the latest key-change). Furthermore, the attack is very `noisy' i.e. could often be detected, which makes it a poor cracking method. Note that the attack is more difficult if the two endpoints maintain just one security association to all traffic, i.e. end to end based keying. In this case the attacker would not know which packets to replay (which belong to the correct port). Also, faster re-keying could be supported. I'm not sure that the counters would buy us much more than just plain fast re-key. Maybe fast re-key is enough. Unless somebody has a good argument, I prefer we keep the ESP document simple and minimally modified. > > In the shared comms case, I have a real hard time. If your enemy is > sharing the comms between you and your crypto, then you shouldn't bther > with the crypto at all. That's true for _real time_ attacker. But the system should be secure against a _midnight_attack_ where the attacker gains access only much after the communication took place. Fast re-key would definitely solve this problem. Best, Amir From ipsec-request@ans.net Mon Apr 17 17:08:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09713 (5.65c/IDA-1.4.4 for ); Mon, 17 Apr 1995 17:08:24 -0400 Received: by interlock.ans.net id AA50101 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 17 Apr 1995 17:04:39 -0400 Message-Id: <199504172104.AA50101@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 17 Apr 1995 17:04:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 17 Apr 1995 17:04:39 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 17 Apr 1995 17:04:39 -0400 Date: Mon, 17 Apr 95 13:52:21 From: "Housley, Russ" Encoding: 1754 Text To: " " Cc: smb@research.att.com, ipsec@ans.net Subject: Re: Bellovin's and Ashar's attacks Amir: >> In the case of the shared host, we need to ensure that the protocol >> conveys information necessary to prevent leakage when the enemies >> serially reuse the same resource, a port in the recent examples. >> discading the key when the port is closed sounds great. Better yet, >> Discard the key and tell the other key management daemon that you did >> it. > > This is fine when the host is running IP-SEC. The problem persists if > the host is unmodified and IP-SEC is done at a firewall/encrypting > router. In this case, the firewall would not know that the port was > closed. > > The only solutions so far are fast re-key and counters; both are, as > pointed out on the list, imperfect as they still allow an attacker to > re-play packets within the timeout period (both methods must allow > time-out period of at least the maximal allowable round trip delay). For > manual attackers this may be OK, but, as was pointed out, one could run a > program that constantly looks for closed ports and immediately tries to > replay traffic. You are discussing a case with shared comms and a shared host here. I understand the attack. I just do not think that it is an attack that we should worry about. If the IPSEC is implemented in a firewall/encrypting router, then the commuications is vulnerable to interception on the network between the unmodified host and the firewall/encrypting router. I do not think that we should spend a lot of time and energy trying to prevent a socket reuse attack when the sniffer attack is not prevented. Either you trust the communications environment between the host and the firewall/encrypting router. If you don't trust it, then put IPSEC at the host. Russ From ipsec-request@ans.net Tue Apr 18 06:34:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09659 (5.65c/IDA-1.4.4 for ); Tue, 18 Apr 1995 11:45:41 -0400 Received: by interlock.ans.net id AA37673 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 18 Apr 1995 11:39:59 -0400 Message-Id: <199504181539.AA37673@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 18 Apr 1995 11:39:59 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 18 Apr 1995 11:39:59 -0400 Date: Tue, 18 Apr 95 10:34:29 EDT From: jwlowe@VNET.IBM.COM To: ipsec@ans.net Subject: IBM US Patent #5,148,479 In my note to you dated December 5, 1994, I advised that IBM had decided to dedicate the subject patent to the public to facilitate adoption of the Internet Key Management Protocol contribution IBM had offered to the IETF.It has been determined subsequently that dedication of the patent has many implications that are beyond the Internet Protocol, and IBM wishes to take a different approach that will have an equal effect on Internet's constituents. Also, the IBM contribution is now included within the "Photuris" proposal, so the grant of rights will be with respect to Photuris and any derivative that includes the IBM contribution. IBM hereby covenants that it will not assert its US Patent 5,148,479 or its non-US counterparts against any party that implements Photuris or any derivative that includes IBM's IKMP contribution, and operates in compliance with Photuris or such derivative, when Photuris or such derivative is employed in connection with any Internet Protocol. This grant of rights will terminate with respect to any party that asserts a patent it owns, directly or indirectly, against IBM for IBM's implementation of and operation in compliance with, such Protocol. The termination will occur as of the date the patent is asserted against IBM. A written confirmation of this grant, and/or a license under any other IBM patent under IBM's then-current terms, conditions and royalty rates, can beobtained by sending a request to me at: IBM Corporation/ 500Columbus Avenue/ Thornwood, New York 10594. cc: jeffrey, amir. fred, jerry, porter, dick, gerry. allan jeffrey, gerry, porter From ipsec-request@ans.net Wed Apr 19 21:32:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12773 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 16:57:14 -0400 Received: by interlock.ans.net id AA09275 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 19 Apr 1995 16:50:13 -0400 Message-Id: <199504192050.AA09275@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 19 Apr 1995 16:50:13 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 19 Apr 1995 16:50:13 -0400 Date: Wed, 19 Apr 95 21:32:15 GMT From: "William Allen Simpson" To: jwlowe@VNET.IBM.COM Cc: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 > In my note to you dated December 5, 1994, I advised that IBM had decided > to dedicate the subject patent to the public to facilitate adoption of > the Internet Key Management Protocol contribution IBM had offered to the > IETF.It has been determined subsequently that dedication of the patent > has many implications that are beyond the Internet Protocol, and IBM > wishes to take a different approach that will have an equal effect on > Internet's constituents. Also, the IBM contribution is now included > within the "Photuris" proposal, so the grant of rights will be with > respect to Photuris and any derivative that includes the IBM > contribution. This license language is obnoxious and unacceptable. Please identify the part of Photuris to which you believe the patent applies, so that we may remove it. Thank you. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Apr 19 22:11:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12544 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 17:17:32 -0400 Received: by interlock.ans.net id AA16221 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 19 Apr 1995 17:11:29 -0400 Message-Id: <199504192111.AA16221@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 19 Apr 1995 17:11:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 19 Apr 1995 17:11:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 19 Apr 1995 17:11:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 19 Apr 1995 17:11:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 19 Apr 1995 17:11:29 -0400 From: uri@watson.ibm.com Subject: Re: IBM US Patent #5,148,479 To: Bill.Simpson@um.cc.umich.edu (William Allen Simpson) Date: Wed, 19 Apr 1995 17:11:24 -0500 (EDT) Cc: ipsec@ans.net In-Reply-To: <199504192050.AA09275@interlock.ans.net> from "William Allen Simpson" at Apr 19, 95 09:32:15 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 358 William Allen Simpson says: > This license language is obnoxious and unacceptable. Bill, the most obnoxious and unacceptable thing or somebody I've ever seen (or heard). If you have something specific to say about the license, do that. And/or learn some manners - won't hurt. -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Wed Apr 19 21:36:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28143 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 17:43:34 -0400 Received: by interlock.ans.net id AA38702 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 19 Apr 1995 17:39:21 -0400 Message-Id: <199504192139.AA38702@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 19 Apr 1995 17:39:21 -0400 From: Ran Atkinson Date: Wed, 19 Apr 1995 17:36:14 -0400 In-Reply-To: uri@watson.ibm.com "Re: IBM US Patent #5,148,479" (Apr 19, 17:11) References: <199504192111.AA16221@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Speaking as an individual, I wish IBM would follow the lead of Sun Microsystems and simply put their patent into the Public Domain. Those would be reasonable terms for everyone and we could get on with our work without further legal distractions. Quite seriously yours, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Apr 19 22:11:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21697 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 18:17:39 -0400 Received: by interlock.ans.net id AA24303 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 19 Apr 1995 18:11:14 -0400 Message-Id: <199504192211.AA24303@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 19 Apr 1995 18:11:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 19 Apr 1995 18:11:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 19 Apr 1995 18:11:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 19 Apr 1995 18:11:14 -0400 To: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Wed, 19 Apr 1995 17:36:14 EDT." <199504192139.AA38702@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 19 Apr 1995 18:11:01 -0400 From: "Perry E. Metzger" Ran Atkinson says: > Speaking as an individual, I wish IBM would follow the lead of Sun > Microsystems and simply put their patent into the Public Domain. > > Those would be reasonable terms for everyone and we could get on > with our work without further legal distractions. I've already managed to request a copy for my company of the IBM document assuring that they will not invoke their patent rights (largely because I plan on early implementation and don't want to have to think about the situation) but quite frankly I agree -- I don't see why they don't just follow Sun's lead. The IBM attorney invoked some sort of mysterious difficulty with the situation, but dedicating patents to the public domain is quite a routine matter so I don't see any legal obstacle there. Perry From ipsec-request@ans.net Wed Apr 19 22:35:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21679 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 18:40:41 -0400 Received: by interlock.ans.net id AA43579 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 19 Apr 1995 18:35:26 -0400 Message-Id: <199504192235.AA43579@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 19 Apr 1995 18:35:26 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 19 Apr 1995 18:35:26 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 19 Apr 1995 18:35:26 -0400 Date: Wed, 19 Apr 1995 15:35:20 -0700 From: Hilarie Orman To: perry@imsi.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199504192211.AA24303@interlock.ans.net> Subject: Re: IBM US Patent #5,148,479 Did Sun really follow through on their announced intentions with respect to their patent? From ipsec-request@ans.net Wed Apr 19 22:39:11 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25313 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 18:44:04 -0400 Received: by interlock.ans.net id AA42899 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 19 Apr 1995 18:39:18 -0400 Message-Id: <199504192239.AA42899@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 19 Apr 1995 18:39:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 19 Apr 1995 18:39:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 19 Apr 1995 18:39:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 19 Apr 1995 18:39:18 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 19 Apr 1995 18:39:18 -0400 X-Mailer: exmh version 1.5.3 12/28/94 To: "William Allen Simpson" Cc: jwlowe@VNET.IBM.COM, ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Wed, 19 Apr 1995 21:32:15 GMT." <199504192050.AA09275@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Apr 1995 18:39:11 -0400 From: " " Bill, you say in your usual style: > This license language is obnoxious and unacceptable. Please identify > the part of Photuris to which you believe the patent applies, so that > we may remove it. Thank you. Defining the exact parts of Photuris to which the patent may apply, and in which way, and arguing about it, would be a truely time consuming and wasteful process. Furthermore, I _think_ it is not required of us by IETF process. In any case, changing technical proposals should be done on the basis of important and clear objections, with consensus. I suggest an alternative. Our belief is that the license is reasonable and fair. If there is some offending language, please identify it and explain. If your objections are sound, we may be able to fix. Best, Amir From ipsec-request@ans.net Wed Apr 19 23:07:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22025 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 19:10:29 -0400 Received: by interlock.ans.net id AA17418 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 19 Apr 1995 19:08:02 -0400 Message-Id: <199504192308.AA17418@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 19 Apr 1995 19:08:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 19 Apr 1995 19:08:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 19 Apr 1995 19:08:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 19 Apr 1995 19:08:02 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 19 Apr 1995 19:08:02 -0400 X-Mailer: exmh version 1.5.3 12/28/94 To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Wed, 19 Apr 1995 18:11:01 EDT." <199504192211.AA24303@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Apr 1995 19:07:47 -0400 From: " " Perry says, > I've already managed to request a copy for my company of the IBM > document assuring that they will not invoke their patent rights Great. Please tell me if this document would have any problem. The patent should be free to you if your company would not claim its own patents against IBM with respect to our implementations of IKMP. (So far the only possible exceptions I'm aware of are RSA and maybe Sun). > (largely because I plan on early implementation and don't want to have > to think about the situation) To remind you and all, IBM does not require license for any experimental implementations (see another note from John). > but quite frankly I agree -- I don't see > why they don't just follow Sun's lead. Well, leaving the issue of whether they should do it or not, on which I was specifically asked not to comment, at least I can explain WHY they don't just dedicate the patent, or at least the reason they give to me. This patent (not like Sun's, if I understood right) was not written as a result of our IPsec activity and has nothing to do with IP. Therefore, it applies in some other scenarios (and to several IBM products as well as other companies products). While IBM is willing to give free use for IKMP, it does not want to give up its rights in other places. Best, Amir From ipsec-request@ans.net Thu Apr 20 01:28:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06669 (5.65c/IDA-1.4.4 for ); Wed, 19 Apr 1995 21:31:07 -0400 Received: by interlock.ans.net id AA26934 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 19 Apr 1995 21:28:20 -0400 Message-Id: <199504200128.AA26934@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 19 Apr 1995 21:28:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 19 Apr 1995 21:28:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 19 Apr 1995 21:28:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 19 Apr 1995 21:28:20 -0400 To: " " Cc: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Wed, 19 Apr 1995 19:07:47 EDT." <9504192307.AA23011@gimili.watson.ibm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 19 Apr 1995 21:28:09 -0400 From: "Perry E. Metzger" " " says: > Perry says, > > > I've already managed to request a copy for my company of the IBM > > document assuring that they will not invoke their patent rights > > Great. Please tell me if this document would have any problem. I'll find out soon, but the real problem I see is that it adds unnecessary and silly paperwork into the process. For instance, if my work gets maintained by a third party, do they then need to get a copy of your document? Lets say that Joe Random Hacker sends me bugfixes -- did he need to have a license? Overall, its an unpleasant nuissance. I've requested a copy largely so that I can get it over with. > The patent should be free to you if your company would not claim its > own patents against IBM with respect to our implementations of > IKMP. (So far the only possible exceptions I'm aware of are RSA and > maybe Sun). Actually, I think thats entirely reasonable, but I'd have prefered for you guys to simply have made a public enough declaration on the matter and to have eliminated this buisiness of giving people individual documents at all. (Perhaps you could have given people official copies of the declaration if they wanted it, but thats another story.) Perry From ipsec-request@ans.net Thu Apr 20 13:05:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28831 (5.65c/IDA-1.4.4 for ); Thu, 20 Apr 1995 09:15:43 -0400 Received: by interlock.ans.net id AA08508 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 20 Apr 1995 09:09:47 -0400 Message-Id: <199504201309.AA08508@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 20 Apr 1995 09:09:47 -0400 From: Ran Atkinson Date: Thu, 20 Apr 1995 09:05:20 -0400 In-Reply-To: " " "Re: IBM US Patent #5,148,479" (Apr 19, 18:39) References: <199504192239.AA42899@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Subject: Re: IBM US Patent #5,148,479 Cc: jwlowe@VNET.IBM.COM, ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Amir, If you all claim that work done by others in this WG infringes in some manner on some patent claim of yours, then you ARE obligated to describe which part of that other work you believe infringes on which claim of which specific patent. The repeated actions of certain IBM employees with regard to patents has in fact been obstructive of the WG progress. I had hoped that there was a real change of heart and that IBM was trying to be constructive. Here is a chance for you all to demonstrate good faith efforts to help make progress rather than block progress. The WG chairs both consider the current IBM language to be onerous. We propose that IBM place the patent(s) in question in the Public Domain as Sun Microsystems has done with its patent regarding SKIP. Ran atkinson@itd.nrl.navy.mil Co-Chair, IP Security WG From ipsec-request@ans.net Thu Apr 20 10:10:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24872 (5.65c/IDA-1.4.4 for ); Thu, 20 Apr 1995 14:28:51 -0400 Received: by interlock.ans.net id AA13143 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 20 Apr 1995 14:23:14 -0400 Message-Id: <199504201823.AA13143@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 20 Apr 1995 14:23:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 20 Apr 1995 14:23:14 -0400 Date: Thu, 20 Apr 95 14:10:15 EDT From: jwlowe@VNET.IBM.COM To: ipsec@ans.net Subject: IBM US Patent #5,148,479 My note of yesterday was a grant by IBM of a covenant not to sue implementers of Photuris for any infringement of the '479 patent. It was not a promise to grant such a covenant. The offer of a confirmatory license was an option IBM made available to any party that wishes to have a written license; it was not a requirement for receipt of the covenant. The only obligation of a party is to refrain from asserting a patent against IBM for any IBM implementation of any IP that includes Photuris. From ipsec-request@ans.net Thu Apr 20 10:37:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28195 (5.65c/IDA-1.4.4 for ); Thu, 20 Apr 1995 15:14:29 -0400 Received: by interlock.ans.net id AA12050 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 20 Apr 1995 14:59:47 -0400 Message-Id: <199504201859.AA12050@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 20 Apr 1995 14:59:47 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 20 Apr 1995 14:59:47 -0400 Date: Thu, 20 Apr 95 14:37:15 EDT From: hugo@watson.ibm.com To: IPSEC@ans.net Cc: jwlowe@vnet.ibm.com, jis@mit.edu, perry@imsi.com Subject: IBM US Patent #5,148,479 Ref: Note from CIRCJWL AT RHQVM07 (attached) John Lowe from IBM has just posted a note explaining that there is *no requirement* for any implementer of the IP key managment protocol to get a written statement from IBM about the free use of the above patent in this protocol. Unfortunately, to non-lawyers, like most of us are, the language of these notes is somewhat confusing and may appear more complicated than it really is. Here I append a letter I sent to John (indented with > ) and his answers (capital letters). The more "human oriented" language of this letter can (hopefully) clarify the issue (and get all of us back to work). Hugo PS: Perry, notice that the situation is exactly as you "wished" it to be in the last paragraph of your (attched) note. > Date: 20 April 1995, 12:16:57 EDT > From: HUGO at YKTVMV > To: CIRCJWL at RHQVM07 > cc: AMIR at YKTVMH > > Re: IBM US Patent #5,148,479 > Ref: Note from "Perry E. Metzger" (attached) > > John, attached is a note to IPSEC by Perry Metzger. > If I understand correctly your posting to IPSEC, then > there is no paperwork *required* for anybody that wants to implement > the standard. It is up to individuals or companies to get > a written confirmation of the license from IBM, > but that is *not* a pre-requisite or requirement. Is that correct? THAT IS CORRECT. THE CONFIRMATORY LICENSE IS OPTIONAL; THE GRANT WAS MADE IN THE POSTING AND PARTIES HAVE IT EVEN IF THEY DO NOT REQUEST CONFIRMATION. > > Also, would it be fair to say that for any individual, company or organization, > that is *not* claiming (now or in the future) any patent rights on the key > management standard for Internet, the free license is automatically granted > by your posting (without any further action by them) ? SEE ABOVE ANSWER. > > Hugo > > ----------------------------- Note follows ------------------------------ > > To: " " > Cc: ipsec@ans.net > Subject: Re: IBM US Patent #5,148,479 > In-Reply-To: Your message of "Wed, 19 Apr 1995 19:07:47 EDT." > <9504192307.AA23011@gimili.watson.ibm.com> > Reply-To: perry@imsi.com > X-Reposting-Policy: redistribute only with permission > Date: Wed, 19 Apr 1995 21:28:09 -0400 > From: "Perry E. Metzger" > > > " " says: > > Perry says, > > > > > I've already managed to request a copy for my company of the IBM > > > document assuring that they will not invoke their patent rights > > > > Great. Please tell me if this document would have any problem. > > I'll find out soon, but the real problem I see is that it adds > unnecessary and silly paperwork into the process. For instance, if my > work gets maintained by a third party, do they then need to get a copy > of your document? Lets say that Joe Random Hacker sends me bugfixes -- > did he need to have a license? Overall, its an unpleasant > nuissance. I've requested a copy largely so that I can get it over > with. > > > The patent should be free to you if your company would not claim its > > own patents against IBM with respect to our implementations of > > IKMP. (So far the only possible exceptions I'm aware of are RSA and > > maybe Sun). > > Actually, I think thats entirely reasonable, but I'd have prefered for > you guys to simply have made a public enough declaration on the matter > and to have eliminated this buisiness of giving people individual > documents at all. (Perhaps you could have given people official copies > of the declaration if they wanted it, but thats another story.) > > Perry > >Subj: NO SUBJECT From ipsec-request@ans.net Thu Apr 20 19:37:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25192 (5.65c/IDA-1.4.4 for ); Thu, 20 Apr 1995 15:43:04 -0400 Received: by interlock.ans.net id AA53472 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 20 Apr 1995 15:37:31 -0400 Message-Id: <199504201937.AA53472@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 20 Apr 1995 15:37:31 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 20 Apr 1995 15:37:31 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 20 Apr 1995 15:37:31 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 20 Apr 1995 15:37:31 -0400 To: jwlowe@VNET.IBM.COM Cc: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Thu, 20 Apr 1995 14:10:15 EDT." <199504201823.AA13143@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 20 Apr 1995 15:37:20 -0400 From: "Perry E. Metzger" jwlowe@VNET.IBM.COM says: > My note of yesterday was a grant by IBM of a covenant not to sue > implementers of Photuris for any infringement of the '479 patent. It was > not a promise to grant such a covenant. Would IBM be willing to publish an RFC with the text of the covenant? That might settle lots of nerves. Perry From ipsec-request@ans.net Thu Apr 20 12:56:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25160 (5.65c/IDA-1.4.4 for ); Thu, 20 Apr 1995 17:38:12 -0400 Received: by interlock.ans.net id AA15000 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 20 Apr 1995 17:28:52 -0400 Message-Id: <199504202128.AA15000@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 20 Apr 1995 17:28:52 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 20 Apr 1995 17:28:52 -0400 Date: Thu, 20 Apr 95 16:56:55 EDT From: jwlowe@VNET.IBM.COM To: ipsec@ans.net Subject: IBM US Patent #5,148,479 In response to Perry Metzger's note, the text of the IBM covenant not to sueis in my notice. If ITEF has a formal mechanism by which such a grant is documented, IBM would be willing to engage in that bit of bureauracy, if you think an RFC (whatever that is) will calm people's fears. There really is nothing more to say in this matter, but we are willing to say more if that will answer questions of IETF members. From ipsec-request@ans.net Thu Apr 20 22:17:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17452 (5.65c/IDA-1.4.4 for ); Thu, 20 Apr 1995 18:22:54 -0400 Received: by interlock.ans.net id AA31291 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 20 Apr 1995 18:17:58 -0400 Message-Id: <199504202217.AA31291@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 20 Apr 1995 18:17:58 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 20 Apr 1995 18:17:58 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 20 Apr 1995 18:17:58 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 20 Apr 1995 18:17:58 -0400 To: jwlowe@VNET.IBM.COM Cc: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Thu, 20 Apr 1995 16:56:55 EDT." <199504202128.AA15000@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 20 Apr 1995 18:17:43 -0400 From: "Perry E. Metzger" jwlowe@VNET.IBM.COM says: > In response to Perry Metzger's note, the text of the IBM covenant not to > sueis in my notice. If ITEF has a formal mechanism by which such a > grant is documented, IBM would be willing to engage in that bit of > bureauracy, if you think an RFC (whatever that is) will calm people's > fears. An RFC is an internet archival document. All internet standards are published as RFCs, as are many other documents archived by the internet community. There is no formal proceedure, but its very easy for you guys to publish an RFC. All you do is send the text of your document by EMail to John Postel, the RFC editor, and he publishes it. This would be a sufficiently public declaration that it would probably make a number of people calmer. I'll point out that this isn't unprecedented -- other organizations have produced similar RFCs in the past. Perry From ipsec-request@ans.net Fri Apr 21 12:21:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29588 (5.65c/IDA-1.4.4 for ); Fri, 21 Apr 1995 08:31:33 -0400 Received: by interlock.ans.net id AA13268 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 21 Apr 1995 08:21:29 -0400 Message-Id: <199504211221.AA13268@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 21 Apr 1995 08:21:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 21 Apr 1995 08:21:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 21 Apr 1995 08:21:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 21 Apr 1995 08:21:29 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 21 Apr 1995 08:21:29 -0400 X-Mailer: exmh version 1.5.3 12/28/94 To: atkinson@itd.nrl.navy.mil Cc: amir@watson.ibm.com, jwlowe@VNET.IBM.COM, ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Thu, 20 Apr 1995 09:05:20 EDT." <9504200905.ZM1601@bodhi.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Apr 1995 08:21:21 -0400 From: " " Ran and all, > Amir, > > If you all claim that work done by others in this WG infringes > in some manner on some patent claim of yours, then you ARE obligated > to describe which part of that other work you believe infringes on > which claim of which specific patent. I have some concern with a certain Sun patent, specifically 5,371,794, issued at Dec 6 94 (filed nov 2 93) by Diffie and Aziz. I'm not sure that this patent does not cover aspects of Skip and Photuris. But I'm also not sure that it does - I need to study this (I just came across it very recently). I think Hugo also asked Ashar about it (if not, then we planned to, and I apologize to Ashar for doing it this way). In my text I just wanted to be frank and not to hide that single additional company (in addition to RSA) who may have some direct interest (I'm not sure if IBM has a cross-license with Sun). As the note by John says in lawyerish, if you don't sue us (for a key management for IP), we don't sue you. > > The repeated actions of certain IBM employees with regard to patents > has in fact been obstructive of the WG progress. This WG? I have some reservations about some actions in some other WGs, but I'm not aware of anything here. I'll really appreciate elaboration (could be off list). I"ll try to correct. > I had hoped that > there was a real change of heart and that IBM was trying to be > constructive. Here is a chance for you all to demonstrate good > faith efforts to help make progress rather than block progress. We try. Please understand our difficulties too. > The WG chairs both consider the current IBM language to be onerous. > We propose that IBM place the patent(s) in question in the Public > Domain as Sun Microsystems has done with its patent regarding SKIP. Of course this is a simpler solution (if indeed it is implemented properly). In particular, I would like to be able to get a written declaration of this `placing of patent in public domain' by Sun (like we offer an official written statement of our conditions). I can give it to my lawyers as a token of appreciation :-) John may consider this request, but I'm sure the request would be more convincing if you can explain WHAT is onerous. It may be fixable or it may convince IBM to dedicate to the public. Perry made an excellent point - we should not force companies to get the official letter if they don't feel OK with an e-mail declaration. I hope John will be able to fix this as I think this was our intent. Please identify any more problems. Best, Amir From ipsec-request@ans.net Fri Apr 21 12:37:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04339 (5.65c/IDA-1.4.4 for ); Fri, 21 Apr 1995 08:48:15 -0400 Received: by interlock.ans.net id AA48219 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 21 Apr 1995 08:38:04 -0400 Message-Id: <199504211238.AA48219@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 21 Apr 1995 08:38:04 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 21 Apr 1995 08:38:04 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 21 Apr 1995 08:38:04 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 21 Apr 1995 08:38:04 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 21 Apr 1995 08:38:04 -0400 X-Mailer: exmh version 1.5.3 12/28/94 Cc: atkinson@itd.nrl.navy.mil, amir@watson.ibm.com, jwlowe@VNET.IBM.COM, ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 - correction In-Reply-To: Your message of "Fri, 21 Apr 1995 08:21:21 EDT." <9504211221.AA32797@gimili.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Apr 1995 08:37:57 -0400 From: " " Ran, a correction, and apology. I responded to your note as follows: > > The repeated actions of certain IBM employees with regard to patents > > has in fact been obstructive of the WG progress. > > This WG? I have some reservations about some actions in some other WGs, but > I'm not aware of anything here. I'll really appreciate elaboration (could be > off list). I"ll try to correct. Now I think I realize that you may mean the fact that at the very beginning of our work in the WG (and IETF in general), we did not discuss the patent issue until our presentation. This was a mistake which I'm sorry for (and already apologized for), it resulted with unfamilarity with the IETF process, and anyway the delay was very short. Let's move on. Best, Amir > > From ipsec-request@ans.net Fri Apr 21 18:14:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21099 (5.65c/IDA-1.4.4 for ); Fri, 21 Apr 1995 14:10:33 -0400 Received: by interlock.ans.net id AA49602 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 21 Apr 1995 14:03:05 -0400 Message-Id: <199504211803.AA49602@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 21 Apr 1995 14:03:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 21 Apr 1995 14:03:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 21 Apr 1995 14:03:05 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 21 Apr 1995 14:03:05 -0400 Date: Fri, 21 Apr 1995 11:14:25 -0700 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: Free SKIP software available Folks, As promised, the SKIP IP layer encryption/key management software is now freely available from: http://skip.incog.com This package provides IP layer encryption which is completely transparent to applications. This is the same software that was demonstrated at the San Jose IETF meeting. The software features: - Automated certificate exchange. - Multi-threaded kernel implementation for parallel bulk data encryption/decryption on a multi-processor. - Dynamic loading into Solaris kernel. - Transparent management of IP fragmentation/reassembly issues - Configurable key-encryption and traffic encryption algorithms (currently DES and RC2 for key encryption and DES-CBC, RC2-CBC and RC4 for traffic encryption). - GUI admin tool for configuring algorithm and key-mgmt policies. The Web page is hopefully self-explantory. I apologize for not making source immediately available, but there are two reasons for this. The current software is written for STREAMS/Solaris and uses BSAFE 2.1, the commercial public key package from RSADSI. Once the software has been ported to BSD style mbufs and RSAREF, which is the next thing we plan on doing, the source code will also be made freely available. In addition, there is a trial CA service for experimenting with the software. In the future, the CA software will also be made freely available, so that people may set up and manage their own CA hierarchies. All comments and requests for more information on this software should be sent to: freeskip@incog.com and not to the ipsec mailing list. Please feel free to forward this message as appropriate. Please note that this software is controlled by US export control laws. The software must not be acquired or transported in violation of these US laws, or applicable laws of other countries. Enjoy, Ashar, Martin, Tom, Hemma... From ipsec-request@ans.net Fri Apr 21 23:23:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15808 (5.65c/IDA-1.4.4 for ); Fri, 21 Apr 1995 20:35:35 -0400 Received: by interlock.ans.net id AA47218 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 21 Apr 1995 19:37:37 -0400 Message-Id: <199504212337.AA47218@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 21 Apr 1995 19:37:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 21 Apr 1995 19:37:37 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 21 Apr 1995 19:37:37 -0400 To: ipsec@ans.net Subject: IPv6 Implementors Mail List and IPv6 Testing Date: Fri, 21 Apr 95 19:23:46 -0400 From: bound@zk3.dec.com X-Mts: smtp This message will go to ipng, dns, dhc, addrconf, ipsec, and sdrp mail lists. I will be setting up an IPv6 Implementors mail alias to provide a place to discuss: 1. Minimal Testing of IPv6 specifications (Level 1) 2. Extended Testing of IPv6 specifications (Level 2) 3. IPv6 Testing Scenarios 4. IPv6 Test Scripts In addition we will try to get implementors to chip in and work as a team on a set of test scripts for both Level 1 and Level 2 testing. And testing scenarios. One good test scenario is the Dan McDonald Dentist Office problem as an example. I just about have an outline and text complete that can be enhanced on the mail list once I get it set up regarding the above so we won't start from scratch. I will work with Bob Hinden on how we define an address space and if we can get a SIXBONE set up on the Internet. But in the interim we can use tunneling as INRIA and Digital have been doing already. There is a TCP/IP EXPO scheduled in San Jose Aug 8-12. I am trying to get an IPv6 show subnet so those that are ready can come and at least do Level 1 Testing. Please send your email address to bound@zk3.dec.com and I will add you to the list. Also, users please participate, I think we need real life scenarios that those of us could miss sitting in the code and specs very closely (e.g. myopic technical tunnel vision). thanks /jim From ipsec-request@ans.net Mon Apr 24 17:07:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22360 (5.65c/IDA-1.4.4 for ); Tue, 25 Apr 1995 06:25:22 -0400 Received: by interlock.ans.net id AA09928 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 25 Apr 1995 06:17:14 -0400 Message-Id: <199504251017.AA09928@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 25 Apr 1995 06:17:14 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 25 Apr 1995 06:17:14 -0400 Date: Mon, 24 Apr 95 17:07:54 GMT From: "William Allen Simpson" To: jwlowe@VNET.IBM.COM Cc: ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 > From: "Perry E. Metzger" > This would be a > sufficiently public declaration that it would probably make a number > of people calmer. I'll point out that this isn't unprecedented -- > other organizations have produced similar RFCs in the past. > No, Perry, I respectfully disagree. The proper procedure listed in RFC-1602 is that the memo be sent to the Secretariate. A RFC is a Request For Comments, and contains technical IP (Internet Protocol, not Intellectual Property) information. Since IBM has not identified any portion of Photuris to which this patent allegedly applies, the filing of the declaration will have no meaningful effect -- but I encourage it anyway, just so we have an archival copy. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Tue Apr 25 12:20:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24642 (5.65c/IDA-1.4.4 for ); Tue, 25 Apr 1995 08:26:59 -0400 Received: by interlock.ans.net id AA23556 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 25 Apr 1995 08:20:38 -0400 Message-Id: <199504251220.AA23556@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 25 Apr 1995 08:20:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 25 Apr 1995 08:20:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 25 Apr 1995 08:20:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 25 Apr 1995 08:20:38 -0400 To: "William Allen Simpson" Cc: jwlowe@VNET.IBM.COM, ipsec@ans.net Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Mon, 24 Apr 1995 17:07:54 GMT." <199504251017.AA09928@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 25 Apr 1995 08:20:12 -0400 From: "Perry E. Metzger" "William Allen Simpson" says: > > From: "Perry E. Metzger" > > This would be a > > sufficiently public declaration that it would probably make a number > > of people calmer. I'll point out that this isn't unprecedented -- > > other organizations have produced similar RFCs in the past. > > > No, Perry, I respectfully disagree. The proper procedure listed in > RFC-1602 is that the memo be sent to the Secretariat. I was unaware that there was a fixed proceedure -- RFC-1602 isn't my strong point. I suggest that whatever the set proceedure is, that it be followed. Perry From ipsec-request@ans.net Tue Apr 25 12:20:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24647 (5.65c/IDA-1.4.4 for ); Tue, 25 Apr 1995 08:27:16 -0400 Received: by interlock.ans.net id AA41480 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 25 Apr 1995 08:20:38 -0400 Message-Id: <199504251220.AA41480@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 25 Apr 1995 08:20:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 25 Apr 1995 08:20:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 25 Apr 1995 08:20:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 25 Apr 1995 08:20:38 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 25 Apr 1995 08:20:38 -0400 X-Mailer: exmh version 1.5.3 12/28/94 To: "William Allen Simpson" Cc: jwlowe@VNET.IBM.COM, ipsec@ans.net, jis@mit.edu Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Mon, 24 Apr 1995 17:07:54 GMT." <9504251136.AA41127@gimili.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Apr 1995 08:20:29 -0400 From: " " Bill Simpson says: > > From: "Perry E. Metzger" > > This would be a > > sufficiently public declaration that it would probably make a number > > of people calmer. I'll point out that this isn't unprecedented -- > > other organizations have produced similar RFCs in the past. > > > No, Perry, I respectfully disagree. The proper procedure listed in > RFC-1602 is that the memo be sent to the Secretariate. > > A RFC is a Request For Comments, and contains technical IP (Internet > Protocol, not Intellectual Property) information. I agree. However, since Perry raised this request, we try to consult Jeff Schiller to see if an RFC is really necessary/useful/appropriate in addition to our note to the list and the letter. (I know that John planned to send a letter, I'm not sure if he already sent it.) I am happy to see that you are now satisfied with the letter as posted. I always believe that difficulties could be worked out if both parties are cooperative and communicating in a rational way. Sometimes one party suffices. Best, Amir Amir Herzberg Manager, Network Security Group, IBM T. J. Watson Research Center Fax 914-784-6205 From ipsec-request@ans.net Tue Apr 25 13:30:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08010 (5.65c/IDA-1.4.4 for ); Tue, 25 Apr 1995 09:33:33 -0400 Received: by interlock.ans.net id AA24744 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 25 Apr 1995 09:27:04 -0400 Message-Id: <199504251327.AA24744@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 25 Apr 1995 09:27:04 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 25 Apr 1995 09:27:04 -0400 Date: Tue, 25 Apr 1995 09:30:12 -0400 (EDT) From: Scott Bradner To: amir@watson.ibm.com, Bill.Simpson@um.cc.umich.edu Subject: Re: IBM US Patent #5,148,479 Cc: ipsec@ans.net, jis@mit.edu, jwlowe@VNET.IBM.COM RFCs contain rather more than just protocol specs, see the recient one which is a copy of the ISOC/SUN agreement on SUN RPC Scott From ipsec-request@ans.net Tue Apr 25 13:58:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08118 (5.65c/IDA-1.4.4 for ); Tue, 25 Apr 1995 10:08:09 -0400 Received: by interlock.ans.net id AA20140 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 25 Apr 1995 09:59:00 -0400 Message-Id: <199504251359.AA20140@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 25 Apr 1995 09:59:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 25 Apr 1995 09:59:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 25 Apr 1995 09:59:00 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 25 Apr 1995 09:59:00 -0400 To: Scott Bradner Cc: amir@watson.ibm.com, Bill.Simpson@um.cc.umich.edu, ipsec@ans.net, jis@mit.edu, jwlowe@VNET.IBM.COM Subject: Re: IBM US Patent #5,148,479 In-Reply-To: Your message of "Tue, 25 Apr 1995 09:30:12 EDT." <199504251327.AA24744@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 25 Apr 1995 09:58:30 -0400 From: "Perry E. Metzger" Scott Bradner says: > RFCs contain rather more than just protocol specs, see the recient > one which is a copy of the ISOC/SUN agreement on SUN RPC See also RFC1170 by PKP concerning public key patents. However, I suppose Jeff Schiller ought to be handling this from here... .pm From ipsec-request@ans.net Wed Apr 26 15:22:17 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20096 (5.65c/IDA-1.4.4 for ); Wed, 26 Apr 1995 12:29:48 -0400 Received: by interlock.ans.net id AA60456 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 26 Apr 1995 12:19:04 -0400 Message-Id: <199504261619.AA60456@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 26 Apr 1995 12:19:04 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 26 Apr 1995 12:19:04 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-esp-des-cbc-04.txt Date: Wed, 26 Apr 95 11:22:17 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Protocol Security Protocol Working Group of the IETF. Title : The ESP DES-CBC Transform Author(s) : P. Metzger, P. Karn, W. Simpson Filename : draft-ietf-ipsec-esp-des-cbc-04.txt Pages : 9 Date : 04/25/1995 This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-des-cbc-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-cbc-04.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) cd mirrors/internet-drafts o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-des-cbc-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19950425101108.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-des-cbc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-des-cbc-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950425101108.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Wed Apr 26 15:21:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12930 (5.65c/IDA-1.4.4 for ); Wed, 26 Apr 1995 12:29:49 -0400 Received: by interlock.ans.net id AA20515 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 26 Apr 1995 12:19:01 -0400 Message-Id: <199504261619.AA20515@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 26 Apr 1995 12:19:01 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 26 Apr 1995 12:19:01 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-ah-md5-03.txt Date: Wed, 26 Apr 95 11:21:40 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Protocol Security Protocol Working Group of the IETF. Title : IP Authentication using Keyed MD5 Author(s) : P. Metzger, W. Simpson Filename : draft-ietf-ipsec-ah-md5-03.txt Pages : 4 Date : 04/25/1995 This document describes the use of keyed MD5 with the IP Authentication Header. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ah-md5-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-md5-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) cd mirrors/internet-drafts o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-md5-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19950425103034.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-md5-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-md5-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950425103034.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Thu Apr 27 21:28:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09597 (5.65c/IDA-1.4.4 for ); Thu, 27 Apr 1995 18:31:53 -0400 Received: by interlock.ans.net id AA30656 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 27 Apr 1995 18:20:49 -0400 Message-Id: <199504272220.AA30656@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 27 Apr 1995 18:20:49 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 27 Apr 1995 18:20:49 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-esp-01.txt Date: Thu, 27 Apr 95 17:28:04 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Protocol Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : R. Atkinson Filename : draft-ietf-ipsec-esp-01.txt Pages : 12 Date : 04/26/1995 This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. In some circumstances it can also provide authentication to IP datagrams. The mechanism works with both IPv4 and IPv6. This document also describes the mandatory DES CBC encryption transform for use with ESP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) cd mirrors/internet-drafts o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19950426134706.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950426134706.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Thu Apr 27 21:27:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21122 (5.65c/IDA-1.4.4 for ); Thu, 27 Apr 1995 18:32:42 -0400 Received: by interlock.ans.net id AA12475 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 27 Apr 1995 18:20:45 -0400 Message-Id: <199504272220.AA12475@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 27 Apr 1995 18:20:45 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 27 Apr 1995 18:20:45 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-arch-01.txt Date: Thu, 27 Apr 95 17:27:58 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Protocol Security Protocol Working Group of the IETF. Title : Security Architecture for the Internet Protocol Author(s) : R. Atkinson Filename : draft-ietf-ipsec-arch-01.txt Pages : 21 Date : 04/26/1995 This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. This document also describes key management requirements for systems implementing those security mechanisms. This document is not an overall Security Architecture for the Internet and is instead focused on IP-layer security. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-arch-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) cd mirrors/internet-drafts o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-arch-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19950426132720.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950426132720.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Thu Apr 27 21:28:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21127 (5.65c/IDA-1.4.4 for ); Thu, 27 Apr 1995 18:32:46 -0400 Received: by interlock.ans.net id AA54213 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 27 Apr 1995 18:20:55 -0400 Message-Id: <199504272220.AA54213@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 27 Apr 1995 18:20:55 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 27 Apr 1995 18:20:55 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-auth-01.txt Date: Thu, 27 Apr 95 17:28:12 -0400 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Protocol Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : R. Atkinson Filename : draft-ietf-ipsec-auth-01.txt Pages : 11 Date : 04/26/1995 This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. An Authentication Header (AH) is normally inserted after the main IP header and before the other information being authenticated. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-auth-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-auth-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) cd mirrors/internet-drafts o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19950426141659.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950426141659.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Fri Apr 28 07:49:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09681 (5.65c/IDA-1.4.4 for ); Fri, 28 Apr 1995 07:49:00 -0400 Received: by interlock.ans.net id AA65959 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 28 Apr 1995 07:40:20 -0400 Message-Id: <199504281140.AA65959@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 28 Apr 1995 07:40:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 28 Apr 1995 07:40:20 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 28 Apr 1995 07:40:20 -0400 From: x.gosselin.rea0803@oasis.icl.co.uk Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 28 Apr 1995 07:40:20 -0400 Date: Fri, 28 Apr 95 11:01:45 BST Reply-To: x.gosselin.rea0803@oasis.icl.co.uk Subject: Internet Securiy Interoperability: Final year project To: ipsec@ans.net To: ipng@sunroof.eng.sun.com I'm a computing student, and in October I'll start my final year. I start collecting information for my project. On of my lecturer told me "check what already exist before rushing everywhere", so I follow his advise : This study will identify the variables which affect secure interworking in the Internet environment, and develop a model for achieving interoperability at different layers in the Internet Protocol Suite. I will work on IPv4 and on the emerging work on Internet key management (IPv6), Domain Name Service Security, network management security and initiatives for common authentication in the application layer. * Does anynome know if a similar project is in progress somewhere or has already been done ? * Some recommendations ? * Some ideas ? * Some advises ? I don't want copy the work of someone else but I'd like studying what already exist and what people thinks about that, to develop my own model by taking considerations of everyone. Thanks for your help Xavier Gosselin From ipsec-request@ans.net Fri Apr 28 10:59:35 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28239 (5.65c/IDA-1.4.4 for ); Fri, 28 Apr 1995 15:16:24 -0400 Received: by interlock.ans.net id AA31911 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 28 Apr 1995 15:03:09 -0400 Message-Id: <199504281903.AA31911@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 28 Apr 1995 15:03:09 -0400 To: ipsec@ans.net Subject: IPsec WG Progress Report Content-Length: 761 Date: Fri, 28 Apr 95 14:59:35 EDT From: Ran Atkinson Sender: rja@bodhi.cs.nrl.navy.mil IPsec WG Folks, Paul and I have been talking and reviewing the inputs from the WG Last Call period for the 5 Internet Drafts that went to last call prior to Danvers. Minor editorial changes have been made to those drafts in response to those inputs. The chairs believe there is rough consensus within the WG that those 5 drafts should move forward to Proposed Standard with the minor edits that have been made. Accordingly, we have formally notified Jeff Schiller (IETF Security Area Director) of this outcome and the next steps are up to the IESG. Those not familiar with the IETF process might want to consult RFC-1602 for more information on what is next. Yours, Paul Lambert Randall Atkinson From ipsec-request@ans.net Fri Apr 28 10:05:35 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12905 (5.65c/IDA-1.4.4 for ); Fri, 28 Apr 1995 20:10:46 -0400 Received: by interlock.ans.net id AA64261 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 28 Apr 1995 20:05:41 -0400 Message-Id: <199504290005.AA64261@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 28 Apr 1995 20:05:41 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 28 Apr 1995 20:05:41 -0400 Date: Fri, 28 Apr 95 17:05:35 PDT From: rogaway@cs.ucdavis.edu (Phil Rogaway) To: ipsec@ans.net Subject: An objection to moving forward with the existing drafts Dear Colleagues, I respectfully disagree that any of the current Internet Security Drafts should move forward to Proposed Standards. These drafts contain significant problems and misunderstandings. I have enumerated some of these; please see my note "Problems with Proposed IP Cryptography", April 3 posting to ipsec@ans.net. The end-of-April revisions remain non-responsive to my criticisms. I don't think it is right for these drafts to move forward while such major problems go unanswered. I doubt Ran is right that there is a "rough consensus" for promoting these into RFCs. In any case, I believe that such a consensus would necessarily exclude cryptographers. I suggest that counter-proposals (not revisions) are needed for each of these documents. I have redone the draft of the CBC privacy transform (the easiest one in the set). You will get a notice announcing availability once I figure out the process for making this an Internet Draft. Sincerely, Phil Rogaway