From ipsec-request@ans.net Wed Mar 1 00:07:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06852 (5.65c/IDA-1.4.4 for ); Tue, 28 Feb 1995 20:44:48 -0500 Received: by interlock.ans.net id AA18630 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 28 Feb 1995 20:32:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 28 Feb 1995 20:32:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 28 Feb 1995 20:32:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Feb 1995 20:32:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Feb 1995 20:32:47 -0500 Date: Tue, 28 Feb 1995 16:07:47 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9503010007.AA02845@miraj.> To: ipsec@ans.net Subject: Re: the silly bit X-Sun-Charset: US-ASCII > From: "William Allen Simpson" > > Finally, we have eliminated _many_ possible key management schemes: > > - All key management schemes where the SAID is assigned by the Source > are eliminated. Only Destination assigned SAIDs are used. This is a > requirement for multicast. > > - All key management schemes which do not provide perfect forward > secrecy are eliminated. > > - All key management schemes which are vulnerable to denial of service > attack are eliminated. Bill, The context of this discussion is independence of IPSP from key-management. Are you saying, e.g. that Kerberos cannot be used with IPSP because it doesn't provide perfect forward secrecy? Ashar. From ipsec-request@ans.net Tue Feb 28 16:41:35 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15705 (5.65c/IDA-1.4.4 for ); Tue, 28 Feb 1995 21:53:58 -0500 Received: by interlock.ans.net id AA24357 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 28 Feb 1995 21:41:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 28 Feb 1995 21:41:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Feb 1995 21:41:43 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Feb 1995 21:41:43 -0500 Date: Tue, 28 Feb 1995 21:41:35 +0500 From: Theodore Ts'o Message-Id: <9503010241.AA26687@dcl.MIT.EDU> To: ipsec@ans.net In-Reply-To: William Allen Simpson's message of Tue, 28 Feb 95 21:33:26 GMT, <4061.bsimpson@morningstar.com> Subject: Re: the silly bit Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1104 Quite frankly, I'm a little bit puzzled by this whole discussion --- what's the point of designating a bit which means "this SAID is structured", when the structure of the SAID isn't being standardizied? What are implementations supposed to do differently when they detect that this bit is set? Or is what's *really* going on is this bit is saying "this SAID is for SKIP", and what we're *really* doing is reserving one bit for the exclusive use of SKIP? That seems unacceptable to me. If you need to do in-line key management, why can't that be done by defining some new, optional transforms that include extra fields which are especially designed for in-line key management, instead of trying to kludge it into the SAID? Then, the SAID is used as it's originally intended to be used --- as an index into a connection table which will indicate how the rest of the packet needs to be processed --- including any possible in-line key management, if necessary. I'm not convinced that, as proposed, the reserved bit will actually do any good (besides wasting one half of the SAID space). - Ted From ipsec-request@ans.net Wed Mar 1 04:50:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05095 (5.65c/IDA-1.4.4 for ); Wed, 1 Mar 1995 00:07:20 -0500 Received: by interlock.ans.net id AA50016 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 28 Feb 1995 23:55:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 28 Feb 1995 23:55:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 28 Feb 1995 23:55:56 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 28 Feb 1995 23:55:56 -0500 Message-Id: <9503010450.AA22626@xirtlu.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Tue, 28 Feb 95 17:18:54 EST." <9502282218.AA09757@snark.imsi.com> Date: Tue, 28 Feb 95 23:50:26 -0500 From: bound@zk3.dec.com X-Mts: smtp I would now like to support Bill Simpsons suggestion this be moved to IPv6 because this is now a key mgmt issue and not just IPv6 SEC. /jim From ipsec-request@ans.net Wed Mar 1 09:11:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17538 (5.65c/IDA-1.4.4 for ); Wed, 1 Mar 1995 05:10:42 -0500 Received: by interlock.ans.net id AA32632 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Mar 1995 04:58:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Mar 1995 04:58:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Mar 1995 04:58:02 -0500 Date: Wed, 1 Mar 95 09:11:36 GMT From: "William Allen Simpson" Message-Id: <4069.bsimpson@morningstar.com> To: ipsec@ans.net Subject: the use of Kerberos > From: ashar@osmosys.incog.com (Ashar Aziz) > Are you saying, e.g. that Kerberos cannot be > used with IPSP because it doesn't provide perfect forward > secrecy? > There is no proposal for using Kerberos for IPSP key management. One of the (many) reasons is the lack of perfect forward secrecy. Kerberos is, however, under serious consideration for providing KDC signatures used as a service by key management in establishing and authenticating session keys. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 1 11:55:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17460 (5.65c/IDA-1.4.4 for ); Wed, 1 Mar 1995 07:06:04 -0500 Received: by interlock.ans.net id AA11643 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Mar 1995 06:55:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 1 Mar 1995 06:55:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Mar 1995 06:55:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Mar 1995 06:55:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Mar 1995 06:55:30 -0500 Message-Id: <9503011210.AA28403@clncrdv1.is.chrysler.com> 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: Wed, 01 Mar 1995 06:55:07 -0500 To: "William Allen Simpson" , ipsec@ans.net From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: WG last call for IPv4 DES and 3DES At 06:38 PM 2/24/95 GMT, William Allen Simpson wrote: >Since we have had no new suggestions for IPv4 ESP, it is time to move on >to the required DES transform. > >Second, that 3DES be required instead of DES. DES can always be >generated using 3DES, and 3DES is more usable for the long term, >noting that DES is already attacked with modest resources. Can 3DES be done in software on a 386 notebook and keep up with a 28.8 comm line? I assume that modem compression will now be usless as the IP datagram was compressed before encryption. Hey, I got to re-read the spec. Where does it say what compression to use before encryption and how to avoid patents???? Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Wed Mar 1 11:58:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14953 (5.65c/IDA-1.4.4 for ); Wed, 1 Mar 1995 07:12:55 -0500 Received: by interlock.ans.net id AA49295 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Mar 1995 06:59:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 1 Mar 1995 06:59:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Mar 1995 06:59:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Mar 1995 06:59:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Mar 1995 06:59:02 -0500 Message-Id: <9503011214.AA28416@clncrdv1.is.chrysler.com> 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: Wed, 01 Mar 1995 06:58:37 -0500 To: Danny.Nessett@eng.sun.com (Dan Nessett), ipng@sunroof.eng.sun.com, ipsec@ans.net From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: Proposed Standard or no? At 02:31 PM 2/24/95 -0800, Dan Nessett wrote: >Folks, > >I originally sent my email on in-band signalling of keying material to both >the IPSEC and IPv6 mailing lists, since the issues are identical to each. > >Right now we have the following people who think in-band signalling should be >allowed : > >IPSEC WG >-------- > >hugo@watson.ibm.com >rgm3@is.chrysler.com >nessett@eng.sun.com >markson@osmosys.incog.com >ashar@osmosys.incog.com > Hold it there. I said work it out. Is there a reason not to support the proposed change to SAIDs to allow in-band signaling. I am not a security expert. I am a security user. I expect you people to hash this out reasonably fast (one week max) and get on the the spec... Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Wed Mar 1 14:29:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14422 (5.65c/IDA-1.4.4 for ); Wed, 1 Mar 1995 09:41:50 -0500 Received: by interlock.ans.net id AA44747 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Mar 1995 09:30:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 1 Mar 1995 09:30:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Mar 1995 09:30:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Mar 1995 09:30:20 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Mar 1995 09:30:20 -0500 Message-Id: <9503011429.AA10566@snark.imsi.com> To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Proposed Standard or no? In-Reply-To: Your message of "Tue, 28 Feb 1995 15:26:18 PST." <9502282326.AA02831@miraj.> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 01 Mar 1995 09:29:41 -0500 From: "Perry E. Metzger" Ashar Aziz says: > > From: "Perry E. Metzger" > > You can't ignore it. If the machine owner can say "gee, I'd like to > > use SKIP" then the kernel has to have the hooks, doesn't it? > > No, it doesn't. Show me code that deals with this without kernel hooks or the use of something like BPF. I just plain do not believe you -- period. I've been working on implementation and I do not see how the packets can be directed without the use of code. If you have an implementation that doesn't require kernel hacks, lets see it. .pm From ipsec-request@ans.net Wed Mar 1 15:41:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16942 (5.65c/IDA-1.4.4 for ); Wed, 1 Mar 1995 10:53:47 -0500 Received: by interlock.ans.net id AA27660 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Mar 1995 10:42:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 1 Mar 1995 10:42:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 1 Mar 1995 10:42:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Mar 1995 10:42:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Mar 1995 10:42:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Mar 1995 10:42:12 -0500 Date: Wed, 1 Mar 1995 07:41:49 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) Message-Id: <199503011541.HAA01306@elrond.Eng.Sun.COM> To: ipsec@ans.net, tytso@MIT.EDU, ipng@sunroof.eng.sun.com Subject: Re: the silly bit X-Sun-Charset: US-ASCII Ted, Your comment : > Or is what's *really* going on is this bit is saying "this SAID is for > SKIP", and what we're *really* doing is reserving one bit for the > exclusive use of SKIP? That seems unacceptable to me. is, I think, not quite fair. While SKIP is the only in-band keying protocol being actively proposed for IPSEC and IPv6, other examples have been given of protocols that use in-band keying, viz., DEC's. One of the litanies we constantly here about IETF work is that it should be based on actual implementation experience. SKIP is implemented and working in the field. The people working on SKIP are not trying to force others to use in-band keying in general or SKIP in particular. They are saying they would like a way to do in-band keying in both IPv4 and IPv6 in a standard way. This is a reasonable request. > If you need to do in-line key management, why can't that be done by > defining some new, optional transforms that include extra fields which > are especially designed for in-line key management, instead of trying to > kludge it into the SAID? Then, the SAID is used as it's originally > intended to be used --- as an index into a connection table which will > indicate how the rest of the packet needs to be processed --- including > any possible in-line key management, if necessary. When a packet arrives, the only field that is available for indicating that the header contains in-band information, at least with the ESP proposed format, is the SAID or the synchronization field. Since the synchronization field format is dependent on the SAID, this forces designers who want to do in-band keying to use something about the SAID field to indicate this. There is no pre-existing SAID value that the receiver will have cached to determine that the header specifies in-band keying. The SAID value will be allocated after the packet is processed. > I'm not convinced that, as proposed, the reserved bit will actually do > any good (besides wasting one half of the SAID space). I agree with you about taking up a bit in the SAID. I think a special SAID value should be used to indicate that the next field(s) carry additional information about the key management protocol. Since there are already SAID values "reserved for future work," one of these can be chosen. e.g., the SAID value consisting of all ones. Dan From ipsec-request@ans.net Wed Mar 1 17:43:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14513 (5.65c/IDA-1.4.4 for ); Wed, 1 Mar 1995 17:22:38 -0500 Received: by interlock.ans.net id AA47915 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Mar 1995 17:09:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Mar 1995 17:09:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Mar 1995 17:09:23 -0500 Date: Wed, 1 Mar 95 17:43:09 GMT From: "William Allen Simpson" Message-Id: <4079.bsimpson@morningstar.com> To: ipsec@ans.net Cc: ipng@sunroof.eng.sun.com Subject: Re: the silly bit This thread was not on IPng, and I firmly object to you bothering them with it. I, for one, will not be replying to this thread on any list in the future. > From: Danny.Nessett@eng.sun.com (Dan Nessett) > implementation experience. SKIP is implemented and working in the field. > This is, as I've mentioned before, utter bullshit. SKIP is supposedly a "key management proposal". Please show us the key management, particularly the deployed X.509 certificate database. SKIP uses completely different certificates from the (non-deployed) PEM. Deployment of SKIP is not likely to be any faster than PEM. > There is no pre-existing SAID value that the receiver will have cached > to determine that the header specifies in-band keying. The SAID value will > be allocated after the packet is processed. > Sender assigned SAID values are not allowed in IP Security. All SAID values are assigned per Destination. This is a requirement. SKIP as currently written does not meet our requirements. > I agree with you about taking up a bit in the SAID. I think a special SAID > value should be used to indicate that the next field(s) carry additional > information about the key management protocol. Since there are already > SAID values "reserved for future work," one of these can be chosen. e.g., > the SAID value consisting of all ones. > I suggested this in the first message in this thread. In order to receive this value, you will need to write a security transform draft. You have not supplied the draft. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 1 22:50:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15170 (5.65c/IDA-1.4.4 for ); Wed, 1 Mar 1995 18:07:59 -0500 Received: by interlock.ans.net id AA10080 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Mar 1995 17:55:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 1 Mar 1995 17:55:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 1 Mar 1995 17:55:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Mar 1995 17:55:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Mar 1995 17:55:16 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Mar 1995 17:55:16 -0500 Date: Wed, 1 Mar 1995 14:50:29 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) Message-Id: <199503012250.OAA01901@elrond.Eng.Sun.COM> To: tytso@MIT.EDU Subject: an aside Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Ted, I apologize if sending my response to both the ipsec and ipng mailing lists was inappropriate. On second thought, I probably should have at least included your original message along with my comments when I responded. However, let me briefly explain why I chose to do what I did. Many of the issues that have arisen on the ipsec mailing list are being discussed on the ipng mailing list in the context of I-Ds submitted by Ran Atkinson. Reading these I-Ds, the similarities with those written by Bill and Perry, at least in philosophy, are quite clear. They are not identical, but are very close. Splitting the discussion of the common issues raised by these I-Ds over two mailing lists will only result in slower convergence, since those common issues that are finally settled in one community will still require agreement in the other community. While it is certainly possible that these communities will elect to adopt different approaches, this would not be to the benefit of internetworking as a whole. Broadening the discussion of the common issues to a wider audience allows insights by those on one mailing list to be shared with those on the other. As long as we are all really trying to come up with the best approach, I can't see why anyone would object to this. Maybe I am missing something and if so, I am open to correction. Regards, Dan From ipsec-request@ans.net Wed Mar 1 22:31:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15099 (5.65c/IDA-1.4.4 for ); Wed, 1 Mar 1995 20:15:47 -0500 Received: by interlock.ans.net id AA44864 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 1 Mar 1995 20:02:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 1 Mar 1995 20:02:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 1 Mar 1995 20:02:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 1 Mar 1995 20:02:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 1 Mar 1995 20:02:37 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 1 Mar 1995 20:02:37 -0500 Date: Wed, 1 Mar 1995 14:31:44 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) Message-Id: <199503012231.OAA01893@elrond.Eng.Sun.COM> To: ipsec@ans.net, ipng@sunroof.eng.sun.com Subject: Re: (IPng) Re: the silly bit X-Sun-Charset: US-ASCII > From bsimpson@morningstar.com Wed Mar 1 14:11:59 1995 > To: ipsec@ans.net > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng) Re: the silly bit > > This thread was not on IPng, and I firmly object to you bothering them > with it. I, for one, will not be replying to this thread on any list in > the future. Since Bill will not be responding to this thread, allow me to explain to others why I sent this to the IPng list. Anyone who has read both the I-Ds submitted by Ran to IPng and the I-Ds written by Bill and Perry for IPsec will note the high degree of similarity. Both specify SAIDs in a way that prevents in-band signalling of keying material. This issue (and many others) are common to both efforts. While I believe IPv6 need not follow the direction being set by IPsec, including both communities in a discussion of common issues, I think, is prudent. It widens the base of expertise, allowing more insight to be gained by the participants. While I can get as irritated as anyone about certain issues, I think it is best to attempt to remain objective and courteous in email exchanges, rather than using them as a blunt instrument. If I have bothered anyone other than Bill, Perry or Ran by posting my discussions of the in-band signalling issues to both the ipsec and ipng mailing lists, please let me know. I am not trying to irritate people. Dan From ipsec-request@ans.net Thu Mar 2 14:50:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15312 (5.65c/IDA-1.4.4 for ); Thu, 2 Mar 1995 10:31:33 -0500 Received: by interlock.ans.net id AA48206 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 2 Mar 1995 09:54:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 2 Mar 1995 09:54:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 2 Mar 1995 09:54:33 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 2 Mar 1995 09:54:33 -0500 Message-Id: <199503021450.JAA00171@smb.research.att.com> From: Steve Bellovin To: ipsec@ans.net, ipng@sunroof.eng.sun.com Subject: problems with SKIP Date: Thu, 02 Mar 1995 09:50:02 -0500 Sender: smb@research.att.com There appear to be some serious problems with the current SKIP draft. Some of these seem to apply to the DEC scheme as well. First, the stream cipher mode doesn't work well, and in particular is not very general. The draft says that MI ``is simply the count of bytes that have already been encrypted in key Kp'', and is 64 bits long. But using a counter only works if packets are in order; arbitrary stream ciphers cannot be cranked backwards, though clearly some can (such as DES in OFB mode). If the new counter is much higher than the last one received, the receiving host may have to turn the crank forward very far. This can lead to denial of service attacks; an attacker can flood the recipient with many bogus packets with wildly different byte counts. While there are some stream ciphers for which neither of these objections apply -- say, encrypting a byte counter with a block cipher to produce an XOR stream -- in the general case the idea appears to be unworkable. SKIP's in-band key negotiation makes it difficult to revoke a compromised certificate. A host may have a cached copy of the old certificate and to use when computing the long-term key Kij. But such packets will be rejected by the recipient, since they won't decrypt properly. Nor will either party know why, unless the receiving machine sends a special bounce message any time decryption fails, if that happens between the revocation time and the normal expiration time of the certificate (and that period could be several years, per the draft). Note the possibility here for a denial of service attack on the the certificate directory: after a revocation, the attacker sends lots of messages with forged source addresses to some target. This causes the bounce messages, which in turn would cause the nominal senders of the packets (who had received the bounce messages) to query the directory server for a current certificate. It isn't clear how one side can force the use of different session keys for each connection between a given pair of hosts. While it can choose different session keys itself, there is no way for it to tell the other side to do so. A number of attacks are possible under these circumstances, especially if a stream cipher is used. The most serious problem, though, is that SKIP makes it very difficult to reject a compromised session key. Suppose that an I have somehow obtained some session key, along with the encryption of it using the long-term key Kij. This isn't impossible, as I may have years to work on it. I can now send fraudulent packets, using the address and Kij encryption from an original packet. Since Kij will remain constant for a very long time, and since by definition the receiving host has no input into the key generation process, it has no way of detecting the forgery. Granted, the attacker has no way of seeing the output from the target host, as it will have its own session key, but as we've seen in the last few weeks, one can quite easily launch certain attacks without ever seeing any output. I can think of a few ways to try to patch SKIP to get around this, such as encrypting the current time with Kij, but the real problem is much deeper: in an avowedly ``stateless'' scheme, the receiving host has no part in the key generation, and hence can't forbid old or bad keys. This problem appears to affect the DEC scheme as well, though it may be repairable there. With the DEC scheme (does it have a name?), the key-encrypting key is private to the receiving host, and thus can be changed at any time. If the generated session keys all expire at the same time, and the KEK is changed at the same instant, old session keys will fail. I would expect a bit of churn for a few seconds on either side of the changeover time, but that might be acceptable. There are other minor problems with SKIP (cleartext algorithm identifiers, a bit to indicate compression, etc., but the problems I've outlined above seem to me to be very serious, and arguably fatal. --Steve Bellovin From ipsec-request@ans.net Thu Mar 2 20:06:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12644 (5.65c/IDA-1.4.4 for ); Thu, 2 Mar 1995 15:42:14 -0500 Received: by interlock.ans.net id AA23100 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 2 Mar 1995 15:09:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 2 Mar 1995 15:09:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 2 Mar 1995 15:09:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 2 Mar 1995 15:09:11 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 2 Mar 1995 15:09:11 -0500 Date: Thu, 2 Mar 1995 12:06:04 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9503022006.AA03658@miraj.> To: ipsec@ans.net, ipng@sunroof.eng.sun.com Subject: Re: (IPng) problems with SKIP X-Sun-Charset: US-ASCII >From: Steve Bellovin Steve, Thanks for the comments. I will respond to some of your other points later, but I'll address these first. (Incidentally, I am responding to ipng as well, but this discussion might be more appropriate for ipsec, since this doesn't relate to encapsulation formats). >First, the stream cipher mode doesn't work well, and in particular >is not very general. The draft says that MI ``is simply the count >of bytes that have already been encrypted in key Kp'', and is 64 >bits long. But using a counter only works if packets are in order; >arbitrary stream ciphers cannot be cranked backwards, though clearly >some can (such as DES in OFB mode). If the new counter is much >higher than the last one received, the receiving host may have to >turn the crank forward very far. This can lead to denial of service >attacks; an attacker can flood the recipient with many bogus packets >with wildly different byte counts. While there are some stream >ciphers for which neither of these objections apply -- say, encrypting >a byte counter with a block cipher to produce an XOR stream -- in >the general case the idea appears to be unworkable. You are correct about the possibility of denial-of-service (d-o-s) attacks on stream ciphers with byte counters. Our implementation at the moment does some things to prevent this sort of attack. In particular it keeps track of current offsets, and has a notion of what reasonable offset differences can be, even given out-of-order arrival of packets. This doesn't completely eliminate all possible d-o-s but can help, in that wildly different counter values are ignored. However, this really isn't a SKIP issue per se. The issue is generic to how one does stream ciphers at the IP layer. The same issues would apply to any other key-mgmt scheme that would use a stream cipher of the RC4 variety. Also, this doesn't mean that because of the possibility of d-o-s attacks, one shouldn't use this mode of operation, because there may be environments where confidentiality and performance are greater considerations than d-o-s. All environments don't suffer from the same threat possibilities. > The most serious problem, though, is that SKIP makes it very > difficult to reject a compromised session key. Suppose that an I > have somehow obtained some session key, along with the encryption > of it using the long-term key Kij. This isn't impossible, as I > may have years to work on it. I can now send fraudulent packets, > using the address and Kij encryption from an original packet. > Since Kij will remain constant for a very long time, and since by > definition the receiving host has no input into the key generation > process, it has no way of detecting the forgery. Granted, the > attacker has no way of seeing the output from the target host, as > it will have its own session key, but as we've seen in the last > few weeks, one can quite easily launch certain attacks without ever > seeing any output. The issue you raise, (essentially a known key attack) has been raised in the past on ipsec by Hugo. At the last IETF meeting, I presented a zero-message way of updating the SKIP master key (Kij) that eliminates this attack. Essentially the master key becomes a function of a counter (that is communicated in the packet) that only runs forward. (This modification was also discussed on the ipsec list soon after the IETF meeting, under the subject zero-message master key update.) If a session key is ever compromised, (but the master key is not) it cannot be replayed because the attacker will not know the encryption of Kp under the current Kij. The IETF presentation slides explained how the counter can be implemented as a function of time units since the more recent of I or J's certificate. Since the counter never runs backwards, it isn't possible to reuse past compromised keys. With this modification, there are no known-key attacks on SKIP that I am aware of. Incidentally, the type of attack you cite (known key attack), applies to Photuris as well. Compromise of a session's secret DH exponent allows the party that connected to later impersonate the party whose session exponent was compromised. I have described this in the past, although there hasn't yet been agreement on the correct way to fix this. The SKIP draft hasn't yet been updated to reflect the master key update mechanism that I described above, and I am working on updating the draft. > This problem appears to affect the DEC scheme as well, though it > may be repairable there. With the DEC scheme (does it have a > name?), the key-encrypting key is private to the receiving host, > and thus can be changed at any time. If the generated session keys > all expire at the same time, and the KEK is changed at the same > instant, old session keys will fail. I would expect a bit of churn > for a few seconds on either side of the changeover time, but that > might be acceptable. I believe that this situation is not applicable to the DEC scheme, because keys are not established by sending them encrypted in the per node master key. A key-negotiation protocol is employed to establish the session key, so if the key-negotiation protocol doesn't suffer from key playback weaknesses, neither will the DEC scheme. (Charlie Kaufmann can correct me if am wrong). Regards, Ashar. From ipsec-request@ans.net Thu Mar 2 20:52:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12638 (5.65c/IDA-1.4.4 for ); Thu, 2 Mar 1995 16:25:43 -0500 Received: by interlock.ans.net id AA55538 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 2 Mar 1995 15:55:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 2 Mar 1995 15:55:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 2 Mar 1995 15:55:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 2 Mar 1995 15:55:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 2 Mar 1995 15:55:24 -0500 Date: Thu, 2 Mar 1995 12:52:44 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) Message-Id: <9503022052.AA03762@miraj.> To: ipsec@ans.net, ipng@sunroof.eng.sun.com Subject: Re: problems with SKIP X-Sun-Charset: US-ASCII > From: Steve Bellovin > SKIP's in-band key negotiation makes it difficult to revoke a > compromised certificate. A host may have a cached copy of the old > certificate and to use when computing the long-term key Kij. But > such packets will be rejected by the recipient, since they won't > decrypt properly. Nor will either party know why, unless the > receiving machine sends a special bounce message any time decryption > fails, if that happens between the revocation time and the normal > expiration time of the certificate (and that period could be several > years, per the draft). Steve, CRL distribution is supposed to be much more frequent than certificate validity periods. If your CRL has expired, (and the CRL format that is specified in SKIP I-D is the same type as in RFC 1422, where there is a "next-issue-date" field") then, possibly under policy control, you stop operation. One doesn't wait for the expiry date of the certificate if the CRL directory has been suppressed through denial-of-service. If one doesn't have an up-to-date CRL, then the certificate cannot be considered to be any good. This is precisely why there is a "next-issue-date" in the RFC 1422 CRL format. Once a new CRL is issued, all cached certificates are purged from any local cache (including cached Kijs). Note that far more serious attacks than denial-of-service are possible if a certificate has been compromised and CRLs are suppressed, including outright impersonation. > It isn't clear how one side can force the use of different session > keys for each connection between a given pair of hosts. While it > can choose different session keys itself, there is no way for it > to tell the other side to do so. A number of attacks are possible > under these circumstances, especially if a stream cipher is used. The fact that each source of encrypted traffic should use different traffic keys is an important part of SKIP. SKIP accomplishes this not just for the case of a pairwise connection, (the easy part) but also for the far trickier case of multicast traffic. This is accomplished by each source of traffic (for both unicast and multicast IP) to randomly generate its own traffic key encrypted in either Kij for the case of unicast IP or the Group Interchange Key (GIK) for the case of multicast IP. So, e.g., in case of a TCP connection, each side automatically uses different keys for each direction of encrypted traffic, allowing the use of any kind of stream cipher and eliminating the possibility of key-stream reuse scenarios. Regards, Ashar. From ipsec-request@ans.net Thu Mar 2 12:18:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17567 (5.65c/IDA-1.4.4 for ); Thu, 2 Mar 1995 17:52:34 -0500 Received: by interlock.ans.net id AA41705 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 2 Mar 1995 17:18:35 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 2 Mar 1995 17:18:35 -0500 Message-Id: <199503022218.AA30690@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 2 Mar 1995 17:18:35 -0500 Date: Thu, 2 Mar 95 17:18:27 EST From: hugo@watson.ibm.com To: IPSEC@ans.net, karn@qualcomm.com Subject: A Photuris variant This is a long note. However, I encourage anybody interested in key management for IP to read it. (Especially those who are going to comment on it ;-) It presents a variation on Photuris which enjoys, in my opinion, some advantages over the basic Photuris proposal, while keeping the full functionality and basic goals of Photuris. (Familiarity with Photuris, draft-karn-photuris-00.txt, is assumed). Please send comments (no need to send directly to me if you also send them to the list). Phil, needless to say, your comments are a "must". Hugo I start with a brief description and then go into commenting on the design properties and comparison with basic Photuris. A more detailed description of the protocol appears at the end of the note (I am just affraid that by putting it at the beginning it will discourage people from reading it). BRIEF DESCRIPTION: ***************** For consistency with Photuris terminology, I use I and R to denote the parties (initiator and responder). As in Photuris, there are 6 messages exchanged between parties (in implementation, can be collapsed to 5 by piggybacking). They correspond to 3 "phases" (with two messages each phase): Cookies, Share and Diffie-Hellman. The cookies phase is identical to the cookies exchange of Photuris. Then, in the Share phase, the parties exchange a key K0 by each of them sending to the other a half-key (denoted K1 and K2, resp.) each encrypted under the other's party public key. After this phase they share a secret key K0=K1 xor K2. The public key encryption of K1 sent from I to R is used also to encrypt I's identity (thus, providing *anonymity*). In the third phase, the parties perform a Diffie-Hellman exchange, where the DH parts (g^x and g^y) are authenticated using a SYMETRIC message authentication (or integrity check) function using the just exchanged key K0 (keyed-MD5, for example, is such a message authentication function). The output of the DH exchange is denoted K = g^(xy) mod p. The public-key operation (in the Share phase) can be done using any public key cryptosystem. For performance considerations we assume RSA which is the less expensive one (in our comparison with Photuris, we also assume that Photuris does RSA for signatures; again this is not a requirement but it's the most efficient implementation). PROPERTIES OF THE SCHEME: ************************ Security: ******** The scheme accomodates different levels of security and provides for clear trade-offs security/performance. Very importantly, it gives the *option* of two basic security levels: * full perfect forward secrecy provided by DH: an eavesdropper will not learn the exchanged key (K) even if eventually (e.g., much after K is no longer in use) it finds the private keys of both I and R (the only ways to learn the key are to steal the key itself, to actively impersonate one of the parties during the exchange or to break the DH scheme). * partial forward secrecy: if the DH exchange is omitted, then the exchanged key (K0) is secure for as long as at least one of the private keys of the parties is not exposed. (I.e., K0 is immune to the discovery of one party's private key). In both cases: * an adversary willing to impersonate a party during a key exchange must know that party's private key. The above first option is provided by Photuris. The second is not. As for the third property, it exist in Photuris if the signature is performed on-line and with some freshness parameter; it is not provided if the signature is done off-line. Against impersonation the scheme is as secure as Photuris with on-line signatures and has the same performance cost. The relative drawback of our variant is that it does not include an off-line signature option as in plain Photuris. However, the off-line signature allows for replay and/or impersonation based on stolen state information only which in some cases may represent a "security hole" and then not desirable. For constrained machines/applications the partial forward secrecy option that we provide gives a clear trade-off security-performance (it saves two DH exponentiations to each party!). A discussion of scenarios where partial forward secrecy may be acceptable is discussed below. Performance: *********** The overall communication required by the scheme is identical to Photuris, the total computation of the full scheme is also the same (one RSA (long) exponentiation, two DH exponentiations). However, * while Photuris allows for off-line performance of the RSA operation (a signature in Photuris) here this operation (a decryption) is done on-line only (with the resultant added security; see above). * while Photuris requires in any case the performance of the (two) Diffie-Hellman exponentiations, the present variant supports ALSO key exchange without these exponentiations. Note: A detailed performance comparison should also include the cost of RSA exponentiations vs DH exponentiations. The former are significantly cheaper than the later via the Chinese Reminder Theorem; on the other hand, going to short exponents in DH, as proposed by Photuris put the complexities closer to each other (my opinion is that the short exponent, which is a security "shortcut", should not be mandated but exist as an option for the user/implementation both in plain Photuris and the present variant). The default scheme and the options ********************************** Shouldn't the full protocol including Diffie-Hellman be the default option? YES! It gives better security and should be performed whenever possible. On the other hand, a cheaper, still significantly secure OPTION is desirable for whoever wants to use it. Who may want to use partial forward secrecy? We note that PGP, PEM and other systems provide keys that are breakable by compromising ONLY ONE private key, and many people seem to be satisfied with that. The shared K0 is even better than that: it requires the breaking of THE TWO private keys to find the key K0. Following is an example where partial forward secrecy may be acceptable. Assume a pair of nodes that exchange a key for use with IPv4/6 AH only (i.e., authentication but not confidentiality). Do they need Perfect Forward Secrecy? Not strictly, since the key is used only for authentication of information and not for secrecy. Therefore, a future compromise of this key (when no longer in use) is useless for the adversary. That is, the main attractiveness of DH for long term protection of keys used for secrecy is irreleveant here. This is a fundamental difference between secrecy and authentication scenarios (in the former a key may be useful to the adversary even long after the key has expired). (This is not to say that DH has no advantages even in the above authentication scenario. Notice that an adversary that *already* knows I's and R's private keys at the time of exchange can learn K0 by eavesdropping the Share phase. If DH phase is also performed then to learn K the adversary needs to participate actively in that phase). An additional example for use of partial forward secrecy is when encryption is used but with weak (for perfromance or export) algorithms. In that case a long-term protection via DH is useless since the adversary can break the encryption directly from the ciphertext (and some knowledge of the plaintext). In this case, the best defense is to refresh keys as often as possible to increase the adversary's work factor. And then a more efficient key exchange is very valuable. In addition, if one considers its own private keys well protected and/or refreshed frequently (e.g., once a month) then partial forward secrecy may be a reasonable option. Compatibility with other key sharing models ******************************************* Another important advantage of our proposed variant is the way it naturally accomodates different security models. For example, with a Key Distribution Center model a la Kerberos, two parties get a common key from the center. Then they can use our protocol by ignoring the share phase (they'll use as K0 the key provided by the center) and going directly to the DH phase (where K0 is used for authentication only via a (fast) symetric algorithm). Notice that by doing this, a corrupted server (the KDC) will not learn anything which is protected via the shared DH key K (except if it actively impersonates the parties during the DH exchange). This gives Kerberos-based key-sharing AND perfect forward secrecy. Similarly, if two parties got K0 manually installed they can use it in the above mode. Other ways for parties to share keys are conceivable. In the SKIP proposal parties share keys via public DH parts. The use of that technique can be combined with our protocol by letting this shared key be K0, and then proceed with our protocol without the share phase (and still get perfect forward secrecy). And so on, and so on. The signature-less property *************************** The proposed variant does not use digital signatures. We claim this as an advantage. Digital signatures provide non-repudiation; a great property when needed and a bad one when forced. For example, it can be used to prove (by your interlocutor or third party) that you have been communicating with somebody. Indeed, if for authentication purposes you sign a string containing the identity of the party you are communicating with (this may have good security reasons, e.g., against replay, etc.) , this information can be later used to prove you talked to that party. In a sense this is a worst privacy violation than not preserving anonymity. Anonymity is usually protected against an eavesdropper in the network, but this eavesdropper cannot necesarily prove that you talked to somebody. Using your signature he can. Protocols that use signature can (and should) be designed carefully not to force a user to provide non-repudable information. However, this is one of the aspects that can be easily overlooked in a design (or modifications to it in the future). It is also a delicate issue to deal with, e.g., if you sign (among other things) a nonce sent by the other party, that nonce could have been produced as the hash of the identity of that person, etc. Another problem of signatures, related to anonymity, is that if you want to protect anonymity you must encrypt the signatures. Otherwise, by simple signature verification (using your public key) your identity can be tested. The bottom line is: if we can do it w/o digital signature then better. We can. Transparent design for (improved) Anonymity ******************************************* Photuris has introduced the requirement of keeping anonymity of the parties (e.g., for mobile users). Photuris achieves that property but at a certain cost. First it requires the delay of signatures (for DH authentication) until after the completion of the DH exchange. Second it requires the encryption of these signatures using the exchanged DH key. Even if the later does not have a big computational cost, the addition of a symetric encryption algorithm to the key exchange phase is otherwise unnecesary. Our solution provides for the anonymity requirement as in Photuris, but achieves it in a completely transparent way. It only requires the inclusion of the initiator's identity inside the encryption message where the half-key K1 is sent. In cases where anonymity is not required then this identity is just omitted from the encryption parameters. Moreover, this solution improves anonymity since it protects it even against an active attacker. Photuris only protects it against eavesdroppers. (Photuris relies on a non-authenticated DH exchange for anonymity). A DETAILED DESCRIPTION ********************** Here I present a more detiled description of this variant. It is not a complete one (e.g., it does not specify the exact way information is to structured before applying a PK encryption operation). These details are left for future description. The flows (or messages) of the protocol are as follows. For consistency with Photuris terminology, I use I and R to denote the parties (initiator and responder). As in Photuris, there are 6 messages exchanged between parties (in implementation, can be collapsed to 5 by peggy-backing). They correspond to 3 "phases" (with two messages each phase): Cookies, Share and Diffie-Hellman. I denote them C1, C2, S1, S2, DH1, DH2. 1) Cookies ******* C1 and C2 are EXACTLY Photuris cookies exchange (against clogging). 2) Share ***** S1 and S2 are intended to exchange a key K0 between I and R (before Diffie-Hellman). It goes: S1 (I --> R) : cookies, ENC_R(Id(I), K1) where: * cookies: are I's and R's cookies as exchanged in C1 and C2 (same as in Photuris) * ENC_R(...) denotes encryption under R's public key of the information inside the parentheses. * Id(I) denotes the identity of I (hidden in the encryption for anonymity). * K1 is a random key chosen by I (its length and purpose will be discussed below). S2 (R --> I) : cookies, ENC_I(K2) where: * cookies: are I's and R's cookies as exchanged in C1 and C2 (same as in Photuris) * ENC_I(...) denotes encryption under I's public key of the information inside the parentheses. * K2 is a random key chosen by R (its length and purpose will be discussed below). (see below for details on the way parameters to the encryption function are encoded before encryption). The parties, I and R, set K0=K1 XOR K2. (Other combinations of K1, K2 into K0 are possible, e.g. K0=MD5(K1,K2), these details are omitted here). 3) Diffie-Hellman ************** DH1, DH2 are Diffie-Hellman exchanges: correspond to DH_REQUEST and DH_RESPONSE in Photuris DH1 (I --> R) : cookies, g^x , MAC_K0(g^x) where: * g^x is the DH part sent by I (i.e., g^x mod p; the values of g and p may also be sent as part of the message if the values are not fixed or known in advance). * MAC_K0 means a message authentication code (or integrity check function) using the key K0 and applied to the information sent in the message. MAC_K0 can be keyed-MD5 (with K0 as the key), DES CBC-MAC, etc. DH2 (R --> I) : cookies, g^y , MAC_K0(g^y) where: * g^y is the DH part sent by R (i.e., g^y mod p; the values of g and p may also be sent as part of the message if the values are not fixed or known in advance). * MAC_K0 means a message authentication code (or integrity check function) using the key K0 and applied to the information sent in the message. MAC_K0 can be keyed-MD5 (with K0 as the key), DES CBC-MAC, etc. The parties now share a Diffie-Hellman key: K = g^(xy) (mod p) The details of g,p and computation of x, y and exponentiations are all the same as in Photuris. Also, the use of timers for retransmission, erasure of old pairs (x,g^x) and so on are the same as in Photuris. A more compact implementation of the protocol that merges the Share and DH phases is as follows. It has the advantage of one less message and allows carrying out the computation of g^(xy) while waiting for the other party's response. (Cookies are omitted). I-->R: g^x, ENC_R(Id(I), K1) R-->I: g^y, ENC_R(K2), MAC_K0(g^y) I-->R: MAC_K0(g^x) From ipsec-request@ans.net Fri Mar 3 12:48:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16121 (5.65c/IDA-1.4.4 for ); Fri, 3 Mar 1995 09:30:29 -0500 Received: by interlock.ans.net id AA32540 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 3 Mar 1995 09:08:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 3 Mar 1995 09:08:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 3 Mar 1995 09:08:22 -0500 Date: Fri, 3 Mar 95 12:48:50 GMT From: "William Allen Simpson" Message-Id: <4107.bsimpson@morningstar.com> To: IPSEC@ans.net Subject: Re: A Photuris variant I find it amusing that the same folks who beat on Photuris for possible compromise of a mere signature (with a time frame of only minutes) propose weakening the key structure to allow compromise of the traffic (with a time frame of forever)! Perfect Forward Secrecy of the traffic is _the_ important security requirement. And then, there is "anonymity". Not as the rest of us use the term, which means protection from identification by third parties, but instead, protection from identification by EACH OTHER. This is _not_ a requirement. And the variant won't allow precomputation, so it is slower to setup. A fine new feature.... Why would anyone want to go to the trouble of sending protected data, using techniques that don't protect the data very well, to a party they can't positively identify? Sounds like Communist Plot to me.... Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Mar 3 14:17:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08235 (5.65c/IDA-1.4.4 for ); Fri, 3 Mar 1995 19:33:30 -0500 Received: by interlock.ans.net id AA29281 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 3 Mar 1995 19:17:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 3 Mar 1995 19:17:24 -0500 Message-Id: <199503040017.AA53341@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 3 Mar 1995 19:17:24 -0500 Date: Fri, 3 Mar 95 19:17:20 EST From: hugo@watson.ibm.com To: bsimpson@morningstar.com Cc: IPSEC@ans.net Subject: A Photuris variant Ref: Your note of Fri, 3 Mar 95 12:48:50 GMT (attached) Bill, I am really trying to be polite here. As I said in my note, if you comment on the proposal at least read it first (and try to understand). And if it is just for the sake of attacking me, well, you could find better reasons. What about, say, my last name: so horrible to spell and just one vowel! Isn't that an even better reason for agression? Hugo ----------------------------- Note follows ------------------------------ Received: from interlock.ans.net by watson.ibm.com (IBM VM SMTP V2R3) with TCP; Fri, 03 Mar 95 09:37:41 EST Received: by interlock.ans.net id AA32540 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 3 Mar 1995 09:08:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 3 Mar 1995 09:08:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 3 Mar 1995 09:08:22 -0500 Date: Fri, 3 Mar 95 12:48:50 GMT From: "William Allen Simpson" Message-Id: <4107.bsimpson@morningstar.com> To: IPSEC@ans.net Subject: Re: A Photuris variant I find it amusing that the same folks who beat on Photuris for possible compromise of a mere signature (with a time frame of only minutes) propose weakening the key structure to allow compromise of the traffic (with a time frame of forever)! Perfect Forward Secrecy of the traffic is _the_ important security requirement. And then, there is "anonymity". Not as the rest of us use the term, which means protection from identification by third parties, but instead, protection from identification by EACH OTHER. This is _not_ a requirement. And the variant won't allow precomputation, so it is slower to setup. A fine new feature.... Why would anyone want to go to the trouble of sending protected data, using techniques that don't protect the data very well, to a party they can't positively identify? Sounds like Communist Plot to me.... Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sat Mar 4 08:05:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16372 (5.65c/IDA-1.4.4 for ); Sat, 4 Mar 1995 04:01:18 -0500 Received: by interlock.ans.net id AA45214 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 4 Mar 1995 03:30:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 4 Mar 1995 03:30:23 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 4 Mar 1995 03:30:23 -0500 Date: Sat, 4 Mar 95 08:05:26 GMT From: "William Allen Simpson" Message-Id: <4119.bsimpson@morningstar.com> To: IPSEC@ans.net Subject: Re: A Photuris variant > From: hugo@watson.ibm.com > As I said in my note, if you comment on the proposal > at least read it first (and try to understand). > Now, how was I able to have the analysis of the proposal without reading the proposal? FYI, I read it from beginning to end, thank you very much. Perhaps I am so completely witless that I cannot understand your writing. Or, maybe I actually _DO_ understand more than you think. Or, maybe it's your writing.... > And if it is just for the sake of attacking me, well, you > could find better reasons. What about, say, my last name: > so horrible to spell and just one vowel! > Isn't that an even better reason for agression? > Watson? I suppose personal attacks from you are all that we can expect. Maybe, someday, you'll actually answer the important questions, like: Why would anyone want to go to the trouble of sending protected data, using techniques that don't protect the data very well, to a party they can't positively identify? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sat Mar 4 14:35:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15272 (5.65c/IDA-1.4.4 for ); Sat, 4 Mar 1995 20:07:26 -0500 Received: by interlock.ans.net id AA17443 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sat, 4 Mar 1995 19:35:59 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 4 Mar 1995 19:35:59 -0500 Message-Id: <199503050035.AA17439@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 4 Mar 1995 19:35:59 -0500 Date: Sat, 4 Mar 95 19:35:55 EST From: hugo@watson.ibm.com To: bsimpson@morningstar.com, IPSEC@ans.net Subject: A Photuris variant Ref: Your note of Sat, 4 Mar 95 08:05:26 GMT OK Bill. I will answer to your specific concerns. I find it amusing that the same folks who beat on Photuris for possible compromise of a mere signature (with a time frame of only minutes) Who are the folkS? My note was sent by one person. As for Photuris signature, when done off-line and without expiration (as proposed in the original draft) it indeed creates an opportunity for the attacker to steal ONE signature and use it "FOREVER" (i.e, for the duration of the public/private key pair). What is the "frame of minutes" you refer to? propose weakening the key structure to allow compromise of the traffic (with a time frame of forever)! The idea is to let the user or implementation to choose the right tradeoff between computation and security without exposing it to hidden vulnerabilities. Perfect Forward Secrecy of the traffic is _the_ important security requirement. Here we agree. PFS is an important requirement for the protocol to provide. Both plain Photuris and the variant I propose provide it! However, can you explain to me, as an author of the IPv4-AH draft, how perfect forward SECRECY works with NO SECRECY as is the case of parties using only AH (and there will be such parties, e.g., when retrieving publicly available information that has no confidentiality but requires integrity protection)? Don't you think that some of these parties may prefer to save the four DH exponentiations (two each) and still get great security? The variant provides that (optionally, of course!). And then, there is "anonymity". Not as the rest of us use the term, which means protection from identification by third parties, but instead, protection from identification by EACH OTHER. Read the note again (including the detailed description). I use anonymity exactly as "the rest of us". There is no protection from each other. When I encrypt my name under your public key, I am protecting my name from third parties not from you. You decrypt it and find my name. This is _not_ a requirement. Indeed, not a requirement and not a feature of the scheme. It just does not make sense in our scenario to keep anonymity from your communication partner (since he needs to know your public key). You just misunderstood the scheme (or I explained it wrong). On the other hand, I was raising the issue of misuse of the protocol by your interlocutor in case you *sign* the fact that you are talking to him/her. That is one of the advantages of not using signatures. For example, nobody will be able to blackmail you saying that he/she can prove you were talking to him/her. This kind of privacy protection makes a lot of sense, but it does not imply or require that you keep your identity secret from the guy you're talking to. Just do not provide a signed certificate that you did talk to him/her. And the variant won't allow precomputation, so it is slower to setup. A fine new feature.... The variant does allow for precomputation. You can precompute g^x exactly as before. As for precomputation of signatures, that is a trade-off existing in plain Photuris that represents a security weakness. Most importantly, precomputation is NOT a requirement. The requirement, or desirable feature, is to provide clear computation/ secuirty trade-offs. This is very cleanly provided by the variant. Why would anyone want to go to the trouble of sending protected data, using techniques that don't protect the data very well, to a party they can't positively identify? I hope this problem with anonymity is now clear. As for not protecting data very well, my proposal protects data as good as Photuris does. I did not hear any complain like this of you on plain Photuris. I believe the flexibility this variant introduces, just provides "best value in town" for computation/secuirty trade-off for whoever wants it. (It even supports a "Kerberos with PFS" option, remember you said Kerberos does not provide PFS... well, now you have it. Read my original note). Sounds like Communist Plot to me.... Whatever that means I hope it sounds better to you now. Bill.Simpson@um.cc.umich.edu Hugo From ipsec-request@ans.net Sun Mar 5 12:03:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15028 (5.65c/IDA-1.4.4 for ); Sun, 5 Mar 1995 09:00:22 -0500 Received: by interlock.ans.net id AA40875 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Sun, 5 Mar 1995 08:29:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 5 Mar 1995 08:29:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 5 Mar 1995 08:29:12 -0500 Date: Sun, 5 Mar 95 12:03:19 GMT From: "William Allen Simpson" Message-Id: <4123.bsimpson@morningstar.com> To: IPSEC@ans.net Subject: Re: A Photuris variant > From: hugo@watson.ibm.com > As for Photuris signature, when done off-line and without expiration > (as proposed in the original draft) it indeed creates an opportunity > for the attacker to steal ONE signature and use it "FOREVER" (i.e, > for the duration of the public/private key pair). What is the "frame > of minutes" you refer to? > Off-line? By hand? The Photuris draft has precomputation, but it is very likely to be done on-line. Despite the lack of a clear reference to a particular key database, Photuris has _ALWAYS_ expected (at least in my recollection) to use signatures with expirations. Indeed, the initial implementations use Kerberos tickets and Eastlake-Kaufman DNS Signatures. The Photuris capability of using multiple databases is one of its deployment strengths. No waiting for X.509. > propose weakening the key structure to allow compromise of the traffic > (with a time frame of forever)! > > The idea is to let the user or implementation to choose the right > tradeoff between computation and security without exposing it > to hidden vulnerabilities. > Weakening. A predictable future vulnerability may not be "hidden" from security analysts, but it _is_ hidden from users. > However, can you explain to me, as an author of the IPv4-AH draft, > how perfect forward SECRECY works with NO SECRECY as is the case > of parties using only AH (and there will be such parties, e.g., > when retrieving publicly available information that has no > confidentiality but requires integrity protection)? > Of course. That's obvious. > Don't you think that some of these parties may prefer to save > the four DH exponentiations (two each) and still get great > security? The variant provides that (optionally, of course!). > Can't imagine why. Would require user configuration on a connection by connection basis. Unlikely at best. At worst, a vendor will make that the default, because it's "faster". And, in Photuris, it won't actually _be_ faster, when precomputation is used. > On the other hand, I was raising the issue of misuse of the protocol by > your interlocutor in case you *sign* the fact that you are talking > to him/her. > That is one of the advantages of not using signatures. For example, > nobody will be able to blackmail you saying that he/she can prove > you were talking to him/her. This kind of privacy protection makes > a lot of sense, but it does not imply or require that you keep your > identity secret from the guy you're talking to. Just do not provide > a signed certificate that you did talk to him/her. > (sigh) Blackmail? Loaded words don't help here. The signature is essential to identification, as used in the usual terminology. If the "name" is not a cryptologically signed certificate, it is only a string of meaningless characters of no proven worth. > And the variant won't allow precomputation, so it is slower to setup. A > fine new feature.... > > The variant does allow for precomputation. You can precompute g^x exactly > as before. As for precomputation of signatures, that is a trade-off > existing in plain Photuris that represents a security weakness. > I disagree. Let us stick to practical threats, not theoretical ephemeral ones. If your machine has been compromised, you will need new signatures anyway. > Most importantly, precomputation is NOT a requirement. > The requirement, or desirable feature, is to provide clear computation/ > secuirty trade-offs. This is very cleanly provided by the variant. > Actually, I believe that precomputation _IS_ a requirement for realistic deployment in existing hardware. Again, practical. > Why would anyone want to go to the trouble of sending protected data, > using techniques that don't protect the data very well, to a party they > can't positively identify? > > I hope this problem with anonymity is now clear. Yes, it is clear that you do not use the term "positively identify" in the same fashion as the rest of us. > As for not protecting data very well, my proposal protects data > as good as Photuris does. > No, you do not in fact protect the data as well as Photuris. Weakness is weakness, even if it is "optional". My question boils down to "why would anyone go to the trouble". If you say that nobody who knows what they are doing will use it, then why define it? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Mar 6 18:59:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17177 (5.65c/IDA-1.4.4 for ); Mon, 6 Mar 1995 14:23:06 -0500 Received: by interlock.ans.net id AA19280 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Mar 1995 13:52:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Mar 1995 13:52:28 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Mar 1995 13:52:28 -0500 Message-Id: Date: 6 Mar 1995 13:59:21 -0500 From: "FreedmanJ" Return-Receipt-To: "FreedmanJ" Subject: FW: Agenda To: "ipsec" X-Mailer: Mail*Link SMTP-MS 3.0.2 Unknown Microsoft mail form. Approximate representation follows. To: ipsec From: FreedmanJ on Mon, Mar 6, 1995 1:59 PM Subject: FW: Agenda In order to convince my management that I should go to the IETF it would help if I had more information about meetings of IPSEC (in the latest draft agenda it doesn't show up). Anybody have a version of the agenda with IPSEC or information about when/how many meetings for IPSEC there will be? Jerry Freedman,Jr From ipsec-request@ans.net Mon Mar 6 10:07:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14696 (5.65c/IDA-1.4.4 for ); Mon, 6 Mar 1995 15:32:23 -0500 Received: by interlock.ans.net id AA19070 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Mar 1995 15:07:25 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Mar 1995 15:07:25 -0500 Message-Id: <199503062007.AA49274@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Mar 1995 15:07:25 -0500 Date: Mon, 6 Mar 95 15:07:22 EST From: hugo@watson.ibm.com To: bsimpson@morningstar.com, IPSEC@ans.net Subject: A Photuris variant Ref: Your note of Sun, 5 Mar 95 12:03:19 GMT (attached) Bill, A clarification: I use the term "off-line signatures", to refer to Photuris signatures that are pre-computed (independent of a key exchange with a particular party). Is it clear now? Besides * you confuse the possible use of expiration time in the signature of g^x with expiration time for public-keys (two completely unrelated things) * you talk about the advantage of (plain) Photuris supporting different PK databases (and no waiting for X.509) when there is no difference in that sense with the variant I propose. * I do not understand the meaning of: > Weakening. A predictable future vulnerability may not be "hidden" from > security analysts, but it _is_ hidden from users. * The danger of stealing (temporary) keys is not a theoretical threat. It is an actual practical one. * You still don't get the issue of anonymity and the way I solve it. Read my notes again. In particular: > Yes, it is clear that you do not use the term "positively identify" in > the same fashion as the rest of us. ???????????? * Pre-computation is NOT a requirement. The practical requirement is to accomodate ALSO solutions that tune the security (in a well-defined and understood way) for improved performance. You can achieve that via pre-computation or other ways as well. * Finally, > My question boils down to "why would anyone go to the trouble". If you > say that nobody who knows what they are doing will use it, then why > define it? I was NOT saying that nobody will do it. I gave several examples where it is reasonable to do it. And people (in general) are reasonable. Hugo From ipsec-request@ans.net Mon Mar 6 22:33:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18611 (5.65c/IDA-1.4.4 for ); Mon, 6 Mar 1995 22:33:49 -0500 Received: by interlock.ans.net id AA41602 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Mar 1995 20:09:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Mar 1995 20:09:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Mar 1995 20:09:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Mar 1995 20:09:58 -0500 Date: Mon, 06 Mar 95 16:15:22 From: "Housley, Russ" Encoding: 1318 Text Message-Id: <9502067945.AA794535322@spysouth.spyrus.com> To: burt@rsa.com Cc: jis@mit.edu, ipsec@ans.net Subject: MD5 for Authentication Burt: Bill Simpson said the following: The {key,text,key} hash is the wrong way to go for MD5. Because of the way that MD5 is designed, MD5 dilutes the effect of the key over multiple blocks. (I remember Jim Hughes pointed this out, too.) According to reports from the PSRG meeting (two weeks ago), Kalisky says we should first hash the text without a key, then hash the {hash,key}. This gives the key greater strength in the final hash. If he had been designing MD5 for keying, he would have added the key in at each step of the block hashing. (I got this from Schiller over the phone, so any mistake in reporting is entirely mine, as this is a third hand report.) Burt, in our discussions on this topic, you raised this alternative. I pointed out that this requires two hash operations instead of one, so this will be slower on crypto implementations that are in peripherals like PCMCIA cards. An that point, you did not say that one approach was stronger than another. Has recent research shown one approach to be significantly stronger than the other? If so, please explain why MD5(key,data,key) is weaker than MD5(MD5(data),key). Also, I am curious if the same analysis would apply to SHA-1? Russ From ipsec-request@ans.net Mon Mar 6 22:33:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22709 (5.65c/IDA-1.4.4 for ); Mon, 6 Mar 1995 22:33:50 -0500 Received: by interlock.ans.net id AA34553 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Mar 1995 20:02:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Mar 1995 20:02:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Mar 1995 20:02:58 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Mar 1995 20:02:58 -0500 Date: Mon, 06 Mar 95 16:15:10 From: "Housley, Russ" Encoding: 1089 Text Message-Id: <9502067945.AA794535310@spysouth.spyrus.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual cir Perry: >As soon as you have structured SAIDs, you have to start throwing lots >of complexity into your kernel -- the kernel must not just have hooks >for key negotiation but has to keep tables of key negotiation types >and be an active participant in the key negotiation process. We are >going to have to start having IANA handing out SAID ranges and the >like. Furthermore, we've just conflated the layers -- something >people keep accusing me of doing. I haven't even plotted out all the >complexities yet. It certainly causes me to have to toss out user >level key management stuff, which I don't like. Multicast Security Associations (SAs) cannot be managed in the same way as peer-to-peer SAs. Given this, the SAID should have some structure to easily separate the multicast SAs from the peer-to-peer ones. Once you accept some structure it is not a big deal to accept another "silly bit." Then, an implementation does not need to know every in-band identifier that is assigned. It only needs to know about the ones that it supports. Russ From ipsec-request@ans.net Tue Mar 7 01:58:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19055 (5.65c/IDA-1.4.4 for ); Mon, 6 Mar 1995 22:52:12 -0500 Received: by interlock.ans.net id AA27895 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Mar 1995 21:08:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 6 Mar 1995 21:08:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Mar 1995 21:08:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Mar 1995 21:08:09 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Mar 1995 21:08:09 -0500 Message-Id: <9503070158.AA20050@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual cir In-Reply-To: Your message of "Mon, 06 Mar 1995 16:15:10." <9502067945.AA794535310@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 06 Mar 1995 20:58:47 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > Multicast Security Associations (SAs) cannot be managed in the same way as > peer-to-peer SAs. Given this, the SAID should have some structure to > easily separate the multicast SAs from the peer-to-peer ones. That is hardly obvious, and conflicts with the mechanisms described in the drafts. As clearly described in the drafts, SAIDs are assigned at the pleasure of the entity controlling the destination address. The us of "entity controlling" rather than "destination host" was deliberate -- it was there because of multicast. I, for one, see absolutely no reason that multicast SAs need to be separated from normal SAs and my architecture for my implementation has no need for such a separation -- an IPSP packet coming in is just the same regardless of whether it was multicast or not, the crypto algorithms are the same, etc. Only the key management system has to be different, and as I've noted, in my system, once an SA is established by a user level key management daemon the kernel no longer has any care of where that SA came from. This is a very natural fallout from the clean separation of functionality that was proposed in the original IP security architecture. Perry From ipsec-request@ans.net Tue Mar 7 02:24:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20099 (5.65c/IDA-1.4.4 for ); Mon, 6 Mar 1995 22:53:16 -0500 Received: by interlock.ans.net id AA15022 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Mar 1995 21:22:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Mar 1995 21:22:31 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Mar 1995 21:22:31 -0500 Date: Mon, 6 Mar 1995 18:24:49 -0800 From: Phil Karn Message-Id: <199503070224.SAA24169@servo.qualcomm.com> To: atkinson@itd.nrl.navy.mil Cc: Danny.Nessett@eng.sun.com, ipsec@ans.net In-Reply-To: <9502221329.ZM6722@bodhi> (message from Ran Atkinson on Wed, 22 Feb 1995 13:29:41 -0500) Subject: Re: WG last call for IPv4 AH and ESP > For that particular case (intermediate router sending an ICMP >message and desiring to authenticate the ICMP message back to the >sender), if a Security Association does not exist the router >could sign it using its private key that is associated with its >Eastlake-Kaufman signed public key available from the DNS and >an RSA signature. This scales as well as the DNS and hence >as well as the Internet as a whole. I hate to keep harping on the same theme, but this is vulnerable to denial-of-service attacks based on the CPU time it takes to verify a public key signature. I could pose as a router and flood hosts around the net with bogus ICMP messages. The fact that the signatures won't verify is immaterial if my goal is just to get a lot of hosts to waste a lot of CPU time. How many router-generated ICMP messages are all that critical anyway? Years ago when we did Requirements for Internet Hosts we deprecated the practice of abruptly resetting TCP connections when ICMP Host Unreachables come in. I can't think of too much that I would want to do automatically in response to an ICMP message. Certainly nothing drastic and permanent like resetting a connection. The most I'd do is to log the message for possible debugging or analysis. About the only exception is ICMP source quench, which I might respond to by temporarily throttling a TCP window. This presents some opportunities to degrade quality of network service, but nothing really serious. Phil From ipsec-request@ans.net Mon Mar 6 22:54:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20105 (5.65c/IDA-1.4.4 for ); Mon, 6 Mar 1995 22:54:03 -0500 Received: by interlock.ans.net id AA15180 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Mar 1995 21:59:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Mar 1995 21:59:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Mar 1995 21:59:51 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Mar 1995 21:59:51 -0500 Date: Mon, 06 Mar 95 16:15:10 From: "Housley, Russ" Encoding: 1089 Text Message-Id: <9502067945.AA794535310@spysouth.spyrus.com> To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual cir Perry: >As soon as you have structured SAIDs, you have to start throwing lots >of complexity into your kernel -- the kernel must not just have hooks >for key negotiation but has to keep tables of key negotiation types >and be an active participant in the key negotiation process. We are >going to have to start having IANA handing out SAID ranges and the >like. Furthermore, we've just conflated the layers -- something >people keep accusing me of doing. I haven't even plotted out all the >complexities yet. It certainly causes me to have to toss out user >level key management stuff, which I don't like. Multicast Security Associations (SAs) cannot be managed in the same way as peer-to-peer SAs. Given this, the SAID should have some structure to easily separate the multicast SAs from the peer-to-peer ones. Once you accept some structure it is not a big deal to accept another "silly bit." Then, an implementation does not need to know every in-band identifier that is assigned. It only needs to know about the ones that it supports. Russ From ipsec-request@ans.net Mon Mar 6 22:55:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18590 (5.65c/IDA-1.4.4 for ); Mon, 6 Mar 1995 22:55:25 -0500 Received: by interlock.ans.net id AA55733 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Mar 1995 22:29:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Mar 1995 22:29:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Mar 1995 22:29:48 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Mar 1995 22:29:48 -0500 Date: Mon, 06 Mar 95 16:15:22 From: "Housley, Russ" Encoding: 1318 Text Message-Id: <9502067945.AA794535322@spysouth.spyrus.com> To: burt@rsa.com Cc: jis@mit.edu, ipsec@ans.net Subject: MD5 for Authentication Burt: Bill Simpson said the following: The {key,text,key} hash is the wrong way to go for MD5. Because of the way that MD5 is designed, MD5 dilutes the effect of the key over multiple blocks. (I remember Jim Hughes pointed this out, too.) According to reports from the PSRG meeting (two weeks ago), Kalisky says we should first hash the text without a key, then hash the {hash,key}. This gives the key greater strength in the final hash. If he had been designing MD5 for keying, he would have added the key in at each step of the block hashing. (I got this from Schiller over the phone, so any mistake in reporting is entirely mine, as this is a third hand report.) Burt, in our discussions on this topic, you raised this alternative. I pointed out that this requires two hash operations instead of one, so this will be slower on crypto implementations that are in peripherals like PCMCIA cards. An that point, you did not say that one approach was stronger than another. Has recent research shown one approach to be significantly stronger than the other? If so, please explain why MD5(key,data,key) is weaker than MD5(MD5(data),key). Also, I am curious if the same analysis would apply to SHA-1? Russ From ipsec-request@ans.net Tue Mar 7 01:58:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20440 (5.65c/IDA-1.4.4 for ); Mon, 6 Mar 1995 23:14:21 -0500 Received: by interlock.ans.net id AA45846 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Mar 1995 22:54:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Mon, 6 Mar 1995 22:54:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Mon, 6 Mar 1995 22:54:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Mar 1995 22:54:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Mar 1995 22:54:06 -0500 Message-Id: <9503070158.AA20050@snark.imsi.com> To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual cir In-Reply-To: Your message of "Mon, 06 Mar 1995 16:15:10." <9502067945.AA794535310@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 06 Mar 1995 20:58:47 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > Multicast Security Associations (SAs) cannot be managed in the same way as > peer-to-peer SAs. Given this, the SAID should have some structure to > easily separate the multicast SAs from the peer-to-peer ones. That is hardly obvious, and conflicts with the mechanisms described in the drafts. As clearly described in the drafts, SAIDs are assigned at the pleasure of the entity controlling the destination address. The us of "entity controlling" rather than "destination host" was deliberate -- it was there because of multicast. I, for one, see absolutely no reason that multicast SAs need to be separated from normal SAs and my architecture for my implementation has no need for such a separation -- an IPSP packet coming in is just the same regardless of whether it was multicast or not, the crypto algorithms are the same, etc. Only the key management system has to be different, and as I've noted, in my system, once an SA is established by a user level key management daemon the kernel no longer has any care of where that SA came from. This is a very natural fallout from the clean separation of functionality that was proposed in the original IP security architecture. Perry From ipsec-request@ans.net Tue Mar 7 02:24:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19173 (5.65c/IDA-1.4.4 for ); Mon, 6 Mar 1995 23:15:14 -0500 Received: by interlock.ans.net id AA15135 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Mon, 6 Mar 1995 22:55:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 6 Mar 1995 22:55:26 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Mar 1995 22:55:26 -0500 Date: Mon, 6 Mar 1995 18:24:49 -0800 From: Phil Karn Message-Id: <199503070224.SAA24169@servo.qualcomm.com> To: atkinson@itd.nrl.navy.mil Cc: Danny.Nessett@eng.sun.com, ipsec@ans.net In-Reply-To: <9502221329.ZM6722@bodhi> (message from Ran Atkinson on Wed, 22 Feb 1995 13:29:41 -0500) Subject: Re: WG last call for IPv4 AH and ESP > For that particular case (intermediate router sending an ICMP >message and desiring to authenticate the ICMP message back to the >sender), if a Security Association does not exist the router >could sign it using its private key that is associated with its >Eastlake-Kaufman signed public key available from the DNS and >an RSA signature. This scales as well as the DNS and hence >as well as the Internet as a whole. I hate to keep harping on the same theme, but this is vulnerable to denial-of-service attacks based on the CPU time it takes to verify a public key signature. I could pose as a router and flood hosts around the net with bogus ICMP messages. The fact that the signatures won't verify is immaterial if my goal is just to get a lot of hosts to waste a lot of CPU time. How many router-generated ICMP messages are all that critical anyway? Years ago when we did Requirements for Internet Hosts we deprecated the practice of abruptly resetting TCP connections when ICMP Host Unreachables come in. I can't think of too much that I would want to do automatically in response to an ICMP message. Certainly nothing drastic and permanent like resetting a connection. The most I'd do is to log the message for possible debugging or analysis. About the only exception is ICMP source quench, which I might respond to by temporarily throttling a TCP window. This presents some opportunities to degrade quality of network service, but nothing really serious. Phil From ipsec-request@ans.net Tue Mar 7 07:43:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05060 (5.65c/IDA-1.4.4 for ); Tue, 7 Mar 1995 03:57:42 -0500 Received: by interlock.ans.net id AA11630 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 7 Mar 1995 03:53:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 7 Mar 1995 03:53:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 7 Mar 1995 03:53:24 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Mar 1995 03:53:24 -0500 From: stefan@gandalf.artwise.de (Stefan Heiligensetzer) To: ipsec@ans.net Subject: unsubscribe Reply-To: stefan@artwise.de Date: Tue, 7 Mar 95 07:43:30 GMT Message-Id: <9503070743.1E5E24@melkor.artwise.de> X-Mailer: SelectMAIL 1.2 please take me off the mailing list thx Stefan ________________________________________________________________ Stefan Heiligensetzer Zeppelinstr.7 Tel. xx49 731 97443-21 Artwise GmbH 89231 Neu-Ulm Fax. xx49 731 97443-83 Software Solutions Germany email: stefan@artwise.de From iladmin@ans.net Tue Mar 7 15:42:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28176 (5.65c/IDA-1.4.4 for ); Tue, 7 Mar 1995 10:47:49 -0500 Received: by interlock.ans.net id AA23827 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Mar 1995 10:43:09 -0500 Message-Id: <199503071543.AA23827@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 7 Mar 1995 10:43:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 7 Mar 1995 10:43:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Mar 1995 10:43:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Mar 1995 10:43:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Mar 1995 10:43:09 -0500 Date: Tue, 7 Mar 1995 07:42:30 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: atkinson@itd.nrl.navy.mil, karn@qualcomm.com Subject: Re: WG last call for IPv4 AH and ESP Cc: Danny.Nessett@eng.sun.com, ipsec@ans.net X-Sun-Charset: US-ASCII Phil, I substantively agree with your statement : > About the only exception is ICMP source quench, which I might respond > to by temporarily throttling a TCP window. This presents some > opportunities to degrade quality of network service, but nothing > really serious. but there is one other example of an ICMP message from a router that might degrade quality of network service, specifically, "packet too big". I talked with Erik Nordmark here at Sun and we concluded that ICMP messages from intermediate routers probably need not be authenticated, except when degradation of service is a high priority of the network customers. Of course, authentication of ICMP messages from first hop routers and destination hosts is another issue. Dan From ipsec-request@ans.net Tue Mar 7 18:21:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29174 (5.65c/IDA-1.4.4 for ); Tue, 7 Mar 1995 13:33:43 -0500 Received: by interlock.ans.net id AA21100 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Mar 1995 13:27:52 -0500 Message-Id: <199503071827.AA21100@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 7 Mar 1995 13:27:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 7 Mar 1995 13:27:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Mar 1995 13:27:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Mar 1995 13:27:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Mar 1995 13:27:52 -0500 Date: Tue, 7 Mar 1995 10:21:50 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Proposed message on perfect forward security X-Sun-Charset: US-ASCII These mailing lists have witnessed a significant amount of commentary on the usefulness of certain key management protocols. One argument that has arisen several times is that some proposed protocols do not provide "perfect forward security." This property is the inabilitiy of an intruder who has recorded past traffic between a sender and receiver to decrypt that traffic if and when the long-term keying material of one or both correspondents is compromised. While perfect forward security is a useful property and even may be required for some applications, it is not always necessary and can introduce certain inefficiencies that adversely affect application performance. For example, perfect forward security may be necessary in an application that deals with information of long-time value, such as certain intelligence traffic, privileged client/attorney communications, and even commuications that may provide embarassment well after they have taken place (e.g., the now widely publicized telephone conversation between the Prince of Wales and his girlfriend). On the other hand, many other applications have no strong requirement for perfect forward security. Examples of these fall generally into that class of communications that are in some sense "tactical." For example, communications between a commander an his forward units probably have no need for perfect forward security. The directions he gives will become apparent to the enemy well before they can use any captured keys they might obtain to decrypt these. Other examples are communications to meet someone at a public place, blind auction bids in which all bids are later revealed in order to assure the participants of fairness, and large stock exchange purchases/sales by corporate officers of their own company's stock, for which the law requires public disclosure. Consequently, to require all key management protocols to provide perfect forward security simply because it is a useful property in some circumstances is unreasonable. The argument supporting this view is similar one that might be made about wearing SCUBA gear. If you intend to dive deeply in the ocean outside of a vessel, then wearing SCUBA gear is a necessity. Since it is such a strong requirement in this situation, we should always wear SCUBA gear, i.e., when we go shopping, are driving our cars or are playing tennis. ;-) For this reason I believe arguing against a key management protocol because it fails to provide perfect forward security would only be appropriate if that were the only protocol being proposed. In the case of IPv6, this is not true and so, I believe the argument is specious. Given the limited amount of experience we have in internet-wide deployed key management protocols, I don't believe this is the time to preclude key management options, especially based on questionable arguments. It is precisely for this reason that we should not exclude various key management protocols so that we may gain experience in this imperfectly understood area. In regards to in-band keying, two companies, Sun and DEC have devised key management protocols that use it, which provides a prima facie case for allowing its optional use in IPv4 and IPv6. Dan From ipsec-request@ans.net Tue Mar 7 18:42:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18509 (5.65c/IDA-1.4.4 for ); Tue, 7 Mar 1995 13:55:12 -0500 Received: by interlock.ans.net id AA29002 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Mar 1995 13:50:48 -0500 Message-Id: <199503071850.AA29002@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 7 Mar 1995 13:50:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Mar 1995 13:50:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Mar 1995 13:50:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Mar 1995 13:50:48 -0500 To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 07 Mar 1995 10:21:50 PST." <199503071821.KAA01274@elrond.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 07 Mar 1995 13:42:36 -0500 From: "Perry E. Metzger" Dan Nessett says: [Stuff that I'm going to ignore on IPng and am going to reply to on ipsec] Dan: This stuff really belongs on ipsec and only on ipsec. It does NOT belong on IPng. I understand that you are a SKIP partisan and like to take every possible opportunity to promote SKIP, but crossposting thinly veiled messages to IPng which has nothing to do with these discussions is increasingly alienating me and others who are mildly sympathetic. I would suggest that you restrict your commentary to the ipsec list -- it doesn't do your friends any good to alienate people this way. Perry From ipsec-request@ans.net Tue Mar 7 19:07:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27995 (5.65c/IDA-1.4.4 for ); Tue, 7 Mar 1995 14:13:08 -0500 Received: by interlock.ans.net id AA21346 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Mar 1995 14:10:23 -0500 Message-Id: <199503071910.AA21346@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 7 Mar 1995 14:10:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Mar 1995 14:10:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Mar 1995 14:10:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Mar 1995 14:10:23 -0500 Date: Tue, 7 Mar 1995 11:07:41 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: Diffie's comments on Photuris X-Sun-Charset: US-ASCII I requested Whitfield Diffie to briefly comment on a Diffie-Hellman scheme that only performs signatures on the sender's exponentials, as appears in the current draft of Photuris. Here is his response. Ashar. ----- Begin Included Message ----- From daemon@ns Tue Mar 7 08:54 PST 1995 To: ashar@icgmail.Eng.Sun.COM (Ashar Aziz) From: whitfield.diffie@Eng.Sun.COM Date: Tue, 7 Mar 1995 at 08h44 Subject: Signing only your own public component It seems to me that there are some serious drawbacks to an authenticated key exchange in which you sign only your own public component and not the one you receive. If an intruder can get your signature on a public component for which he knows the secret component, he can impersonate you. This means you have to audit the implications of each use of signature to be sure you don't create a path to this end. It has the same unaesthetic quality as DSS in creating a secret whose intended use is ephemeral, but whose compromise has long term consequences. If for whatever reason, the secret component is compromised, the recipient acquires the power to impersonate. There is an architecture with many attractive features that this would make hazardous --- doing the Diffie-Hellman part in a workstation and only having the signature done by a smart card. Whit ----- End Included Message ----- From iladmin@ans.net Tue Mar 7 18:08:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21462 (5.65c/IDA-1.4.4 for ); Tue, 7 Mar 1995 18:08:59 -0500 Received: by interlock.ans.net id AA10760 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Mar 1995 18:06:11 -0500 Message-Id: <199503072306.AA10760@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Mar 1995 18:06:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Mar 1995 18:06:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Mar 1995 18:06:11 -0500 Date: Tue, 07 Mar 95 14:46:01 From: "Housley, Russ" Encoding: 963 Text To: perry@imsi.com Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual ... Perry: >> Multicast Security Associations (SAs) cannot be managed in the same way as >> peer-to-peer SAs. Given this, the SAID should have some structure to >> easily separate the multicast SAs from the peer-to-peer ones. > >That is hardly obvious, and conflicts with the mechanisms described in >the drafts. > >As clearly described in the drafts, SAIDs are assigned at the pleasure >of the entity controlling the destination address. The us of "entity >controlling" rather than "destination host" was deliberate -- it was >there because of multicast. I agree that the SAID must me assigned by the entity controlling the destination address. In fact, this is exactly my point. Key management will do something different to establish a security association for two IPSP peers than to establish a multicast security association. The IPSP processing may well be identical once those security associations are in place. Russ From iladmin@ans.net Tue Mar 7 23:13:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04891 (5.65c/IDA-1.4.4 for ); Tue, 7 Mar 1995 18:16:35 -0500 Received: by interlock.ans.net id AA10955 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 7 Mar 1995 18:15:30 -0500 Message-Id: <199503072315.AA10955@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 7 Mar 1995 18:15:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 7 Mar 1995 18:15:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 7 Mar 1995 18:15:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 7 Mar 1995 18:15:30 -0500 To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual ... In-Reply-To: Your message of "Tue, 07 Mar 1995 14:46:01." <9502077946.AA794616361@spysouth.spyrus.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 07 Mar 1995 18:13:24 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > >As clearly described in the drafts, SAIDs are assigned at the pleasure > >of the entity controlling the destination address. The us of "entity > >controlling" rather than "destination host" was deliberate -- it was > >there because of multicast. > > I agree that the SAID must me assigned by the entity controlling the > destination address. In fact, this is exactly my point. Key management > will do something different to establish a security association for two > IPSP peers than to establish a multicast security association. > > The IPSP processing may well be identical once those security associations > are in place. If you agree with that, then you are necessarily supporting the point that structured SAIDs are not needed for multicast. .pm From iladmin@ans.net Wed Mar 8 13:33:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18674 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 08:57:34 -0500 Received: by interlock.ans.net id AA39636 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 08:36:41 -0500 Message-Id: <199503081336.AA39636@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 08:36:41 -0500 To: perry@imsi.com Cc: "Housley, Russ" , ipsec@ans.net, solo@BBN.COM Subject: Re: (IPng) out-of-band key management is like virtual ... In-Reply-To: Your message of Tue, 07 Mar 95 18:13:24 -0500. <199503072315.AA10955@interlock.ans.net> Date: Wed, 08 Mar 95 08:33:56 -0500 From: solo@BBN.COM Perry (et al.), In the discussions of SAID "structure" there are a couple of cases which I haven't been able to reconcile. I agree that in general, SAIDs are assigned by the destination for unicast traffic. This doesn't seem to always translate to multicast traffic. The secured PDU being sent to a multicast group contains a single SAID. Further, the membership in a such a group may be dynamic over time. Consequently, it seems that in some cases, I (a recipient) will join a secure multicast group and be TOLD the SAID. This is no longer a destination assigned SAID (it is also unclear whether at group establishment the SAID is "negotiated" among all parties or assigned by the group "master"). In such a case, absent any structure to the SAID, it is possible that it will collide with an SAID I have assigned. I thought it was this case that argued for some bit (either "originator assigned" or "multicast group") in the SAID. Without such a designator, how do you expect to handle these cases? Dave > Date: Tue, 07 Mar 95 18:13:24 EST > From: "Perry E. Metzger" > Subject: Re: (IPng) out-of-band key management is like virtual ... > > In-Reply-To: Your message of "Tue, 07 Mar 1995 14:46:01." > <9502077946.AA794616361@spysouth.spyrus.com> > "Housley, Russ" says: > > >As clearly described in the drafts, SAIDs are assigned at the pleasure > > >of the entity controlling the destination address. The us of "entity > > >controlling" rather than "destination host" was deliberate -- it was > > >there because of multicast. > > > > I agree that the SAID must me assigned by the entity controlling the > > destination address. In fact, this is exactly my point. Key management > > will do something different to establish a security association for two > > IPSP peers than to establish a multicast security association. > > > > The IPSP processing may well be identical once those security associations > > are in place. > > If you agree with that, then you are necessarily supporting the point > that structured SAIDs are not needed for multicast. > > .pm From iladmin@ans.net Wed Mar 8 14:00:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14934 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 09:29:12 -0500 Received: by interlock.ans.net id AA32074 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 09:06:48 -0500 Message-Id: <199503081406.AA32074@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 09:06:48 -0500 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net, solo@BBN.COM Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits In-Reply-To: Your message of Mon, 27 Feb 95 09:17:38 -0500. <9501277939.AA793905458@spysouth.spyrus.com> Date: Wed, 08 Mar 95 09:00:54 -0500 From: solo@BBN.COM I, too, believe that the solutions we offer should be capable of accomodating both in-band and out-of-band KM (or key distribution). As with other topics, it seems that there are three options (probably more, but so it goes) for doing this: negotiation that includes IPSP format; structured SAIDs that connote IPSP format and semantics; and multiple protocol IDs. Essentially, the second option is a way to extend the protocol ID space without consuming additional IP next protocol numbers. I believe Russ's suggestion below has merit; but if we can't reach agreement on adding such structure to the SAID field, then I would suggest we consider adopting two protocol IDs, one for the fixed format structure Bill and Perry have espoused and one with comparable syntax but with the SAID based extensible option Russ describes. This argument seems to reduce to the efficiency of where "protocol" demultiplexing takes place. I believe it is critical that we leave Danvers with stable documented proposals (and agreement :-)). Dave > Date: Mon, 27 Feb 95 09:17:38 EST > From: "Housley, Russ" > Subject: (IPng) Re: out-of-band key management is like virtual circuits > > Hi Dan. > > In IEEE 802.10, when we were developing the Secure Data Exchange (SDE) > Protocol, this same "in-line" key issue surfaced. It was resolved in a > manner that has not been considered by the IETF. The solution has pros and > cons, but I think that it should be considered before a decision is made. > > SDE has a 32-bit SAID that is followed by an optional field, called the > Management Defined Field (MDF). DEC pushed very hard for this field > because they wanted the SAID to identifiy a Master Key that would be used > to decrypt the contents of the MDF. The MDF carried the key or keys to > decrypt and/or check the integrity of the payload. > > SKIP is the same idea. SKIP sderives the Master Key using D-H key > agreement instead of out-of-band master key distribution. > > This alternative would permit the approach advocated by DEC, and it would > accompdate the SKIP approach. > > Using a bit in the SAID to indicate the presence/absence of the MDF (or > whatever we call it for IPSP) would avoid the need for a key management > protocol to negotiate the attributes for the security association. Perhaps > a reserved SAID would indicate that the key management technique used by > SKIP should be used to generate the key to decrypt the MDF. > > I just do not see why we cannot architect an IP layer security protocol > that permits both types of key management. > > More food for thought.... > > Russ > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > Unsubscribe: unsubscribe ipng (as message body, not subject) > Direct all administrative requests to majordomo@sunroof.eng.sun.com From iladmin@ans.net Wed Mar 8 15:28:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21851 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 10:43:21 -0500 Received: by interlock.ans.net id AA38789 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 10:31:09 -0500 Message-Id: <199503081531.AA38789@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 10:31:09 -0500 From: Ran Atkinson Date: Wed, 8 Mar 1995 10:28:33 -0500 References: <199503081336.AA39636@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: multicasting & SAIDs Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil [The subject line was edited to be more accurate. :-] Folks, The SAID is _never_ a unique identifier BY ITSELF. It is _always_ interpreted _in the context of the Destination Address_, so there is no possibility of conflict. All systems must use the PAIR of (SAID + Destination Address) to determine the appropriate Security Association and all systems must ALWAYS use this method. By the way, this scheme works really nicely with Patricia Trees such as are implemented in BSD's radix.c code. So, let me try to illustrate by using one of the recently posted examples. Assume some system with a single physical interface having interface address A. Now assume that this same system is a receiver for multicast group M (i.e. M will be the Destination Address for multicast packets to that group). Now if the system has assigned a unicast Security Association having an SAID with value N and the multicast group is using a different Security Association having a SAID with value N. The system gets an incoming packet and that packet has SAID with value N, there is still no conflict or uncertainty of any kind because _in all cases_ the system uses the PAIR of SAID and Destination Address to locate the Security Association. The Destination Addr for unicast packets in this example will be A and the Destination Addr for multicast packets in this example will be M. In IPv4 land, M will be a Class D address and A cannot be a Class D address so there is no potential for conflict. In IPv6 land, there are no "classes" (A, B, C, D, or E) but there is a unique prefix for all multicast addresses so there is still no potential for conflict. If someone still thinks there is a potential for conflict, please be detailed in providing a counter-example so that we can try to identify/resolve this matter. Thank you, Ran atkinson@itd.nrl.navy.mil From iladmin@ans.net Wed Mar 8 15:47:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06864 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 10:57:49 -0500 Received: by interlock.ans.net id AA33801 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 10:53:11 -0500 Message-Id: <199503081553.AA33801@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Mar 1995 10:53:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 10:53:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 10:53:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 10:53:11 -0500 To: solo@BBN.COM Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual ... In-Reply-To: Your message of "Wed, 08 Mar 1995 08:33:56 EST." <199503081336.IAA20919@wintermute.imsi.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 08 Mar 1995 10:47:13 -0500 From: "Perry E. Metzger" solo@BBN.COM says: > The secured PDU being sent to a multicast group contains a single > SAID. Further, the membership in a such a group may be dynamic over > time. Consequently, it seems that in some cases, I (a recipient) > will join a secure multicast group and be TOLD the SAID. This is no > longer a destination assigned SAID (it is also unclear whether at > group establishment the SAID is "negotiated" among all parties or > assigned by the group "master"). In the document it is clearly stated that the SAID is assigned at the pleasure of the entity controlling the destination address, and not necessarily the hosts that use that destination address. The proposed multicast key management protocols that have been discussed thus far seem to deal with this just fine -- without needing structured SAIDs. > I thought it was this case that argued for > some bit (either "originator assigned" or "multicast group") in the > SAID. I fail to see how such a bit would in practice alter the way that IPSP deals with packets, so I fail to see what its purpose would be. SAIDs are negotiated OUT OF BAND. Once they are assigned and set up in a kernel processing is the same regardless of where they came from. In a reasonable implementation, SAIDs are destination address dependent so that even if you don't control the destination address (i.e. you are in a multicast group) provided someone controls the assignment of SAIDs for that destination you are fine and no conflicts will arise. Perry From iladmin@ans.net Wed Mar 8 06:02:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27098 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 11:16:44 -0500 Received: by interlock.ans.net id AA45978 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 11:11:34 -0500 Message-Id: <199503081611.AA45978@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 11:11:34 -0500 Date: Wed, 8 Mar 95 11:02:42 EST From: Charles Lynn To: solo@BBN.COM Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual ... Folks, > Without such a designator, how do you expect to handle these > cases? Maybe what would be useful would be to allot part of the SAID space for "not assigned by the destination system" (but not implying any particular "structure"). I think this would make assignment easier. Whether or not such an allocation is made, an implementation should be able to solve the collision problem by making the key, instead of simply . Then multicast address(es) and locally assigned unicast address(es) could have the same 32-bit SAID without "collision". One might also want some wildcard address that would match any of the system's unicast addresses (but not any multicast address); a question for the security experts. Charlie From iladmin@ans.net Wed Mar 8 15:25:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20767 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 11:23:16 -0500 Received: by interlock.ans.net id AA36924 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 11:19:10 -0500 Message-Id: <199503081619.AA36924@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 11:19:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 11:19:10 -0500 Date: Wed, 8 Mar 95 15:25:44 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Multicast SAID > From: solo@BBN.COM > In the discussions of SAID "structure" there are a couple of cases > which I haven't been able to reconcile. I agree that in general, > SAIDs are assigned by the destination for unicast traffic. > This > doesn't seem to always translate to multicast traffic. > In such a case, absent any structure to the > SAID, it is possible that it will collide with an SAID I have > assigned. I thought it was this case that argued for some bit (either > "originator assigned" or "multicast group") in the SAID. > In this case, the "bit" is actually the whole Destination field. You already know whether the Destination is a multicast address. I don't see how it could possibly conflict. If you have joined the multicast group properly, you will know the SAID (or SAIDs) for that group. If you just assign SAIDs willy nilly, why of course you will have a conflict! Did you actually read ESP? A session between two nodes will normally have two SAID values (one in each direction). The nodes use the combination of SAID and IP Destination to distinguish the correct association. By having the Destination select the SAID value, conflicts are avoided between manually configured and automatically configured Security Associations (when using a key management protocol). A given Destination is not necessarily in control of the negotiation process. In the case of multicast groups, a single node or cooperating subset of the multicast group may work on behalf of the entire group to set up a Security Association. Bill.Simpson@um.cc.umich.edu From iladmin@ans.net Wed Mar 8 16:53:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26981 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 11:57:49 -0500 Received: by interlock.ans.net id AA23824 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 11:55:21 -0500 Message-Id: <199503081655.AA23824@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Mar 1995 11:55:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 11:55:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 11:55:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 11:55:21 -0500 To: Charles Lynn Cc: ipsec@ans.net Subject: Re: (IPng) out-of-band key management is like virtual ... In-Reply-To: Your message of "Wed, 08 Mar 1995 11:02:42 EST." <199503081611.AA45978@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 08 Mar 1995 11:53:03 -0500 From: "Perry E. Metzger" Charles Lynn says: > > Without such a designator, how do you expect to handle these > > cases? > > Maybe what would be useful would be to allot part of the SAID space > for "not assigned by the destination system" (but not implying any > particular "structure"). I think this would make assignment easier. Pardon my pissy mood, but maybe some of you could read the drafts, for crying out loud? This is NOT an issue. There is no need for solutions since this is NOT a problem. There is a single entity that hands out SAIDs that are if need be, keyed by destination address -- whether that is a single host or some authority acting on behalf of a multicast group is immaterial. > Whether or not such an allocation is made, an implementation should be > able to solve the collision problem by making address> the key, instead of simply . This was already implicit in the scheme in the draft. Perry From iladmin@ans.net Wed Mar 8 18:01:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04991 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 13:04:34 -0500 Received: by interlock.ans.net id AA28611 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 13:01:36 -0500 Message-Id: <199503081801.AA28611@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 8 Mar 1995 13:01:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Mar 1995 13:01:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 13:01:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 13:01:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 13:01:36 -0500 Date: Wed, 8 Mar 1995 10:01:01 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: user-to-user vs. host-to-host keying X-Sun-Charset: US-ASCII One of the issues that is debated about keying requirments for IPv4 and IPv6 is how to thwart cryptoanalytic threats. The IPv6 security I-Ds specify that user-to-user keying must be supported to meet these (I couldn't find this called out in the IPSEC drafts of Metzger and Simpson, but I thought this issue is of sufficiently wide-spread interest that I am also posting this message to the IPSEC mailing list). I asked Burt Kaliski to comment on how much text is needed by the best techniques published in the open literature to cryptoanalyze DES. Here is his response. === From burt@RSA.COM Wed Mar 8 09:45:29 1995 To: Danny.Nessett@Eng Subject: Quantity of plaintext/ciphertext required for DES crypto Dan -- It is somewhat counterintuitive that the known plaintext attack requires less data than the chosen plaintext attack, and a little surprising, but not contradictory, since every known plaintext attack is a chosen plaintext attack as well. I think 2^32 is a better bound than 2^43, at least for certain modes of DES. For instance, after 2^32 blocks in CBC mode, you expect to see two identical ciphertext blocks, say c[i] and c[j]; the difference between their predecessors will match the difference between the corresponding plaintext blocks, i.e., p[i] xor p[j] = c[i-1] xor c[j-1] Information thus starts to leak after 2^32 blocks (square root of the message space). I would recommend 2^32 blocks as the limit for the lifetime of a key, and that takes care of the 2^43/2^47 attacks as well. Feel free to summarize or repost my comments. -- Burt ======= This suggests that another way to meet the cryptoanalytic threat to host-to-host keying is to change the session key well before 2^32 plaintexts have been encrypted. Consequently, I think that requiring IPv6 security implementations to support user-to-user keying is too limiting. They can adequately meet this threat by judicious session key management. Dan From iladmin@ans.net Wed Mar 8 18:37:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27021 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 13:51:10 -0500 Received: by interlock.ans.net id AA39539 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 13:49:15 -0500 Message-Id: <199503081849.AA39539@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 13:49:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 13:49:15 -0500 Date: Wed, 8 Mar 95 18:37:04 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: SAIDs I could swear you'd read the drafts. How could you have missed something this obvious!?! > From: Charles Lynn > Whether or not such an allocation is made, an implementation should be > able to solve the collision problem by making address> the key, instead of simply . ESP Page 2 The nodes use the combination of SAID and IP Destination to distinguish the correct association. AH Page 2 The nodes use the combination of SAID and IP Destination to distinguish the correct association. Bill.Simpson@um.cc.umich.edu From iladmin@ans.net Wed Mar 8 18:01:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17391 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 14:02:38 -0500 Message-Id: <199503081902.AA17391@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Wed, 8 Mar 1995 13:58:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 8 Mar 1995 13:58:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Mar 1995 13:58:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 13:58:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 13:58:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 13:58:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 8 Mar 1995 13:58:07 -0500 Date: Wed, 8 Mar 1995 10:01:01 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: user-to-user vs. host-to-host keying X-Sun-Charset: US-ASCII One of the issues that is debated about keying requirments for IPv4 and IPv6 is how to thwart cryptoanalytic threats. The IPv6 security I-Ds specify that user-to-user keying must be supported to meet these (I couldn't find this called out in the IPSEC drafts of Metzger and Simpson, but I thought this issue is of sufficiently wide-spread interest that I am also posting this message to the IPSEC mailing list). I asked Burt Kaliski to comment on how much text is needed by the best techniques published in the open literature to cryptoanalyze DES. Here is his response. === From burt@RSA.COM Wed Mar 8 09:45:29 1995 To: Danny.Nessett@Eng Subject: Quantity of plaintext/ciphertext required for DES crypto Dan -- It is somewhat counterintuitive that the known plaintext attack requires less data than the chosen plaintext attack, and a little surprising, but not contradictory, since every known plaintext attack is a chosen plaintext attack as well. I think 2^32 is a better bound than 2^43, at least for certain modes of DES. For instance, after 2^32 blocks in CBC mode, you expect to see two identical ciphertext blocks, say c[i] and c[j]; the difference between their predecessors will match the difference between the corresponding plaintext blocks, i.e., p[i] xor p[j] = c[i-1] xor c[j-1] Information thus starts to leak after 2^32 blocks (square root of the message space). I would recommend 2^32 blocks as the limit for the lifetime of a key, and that takes care of the 2^43/2^47 attacks as well. Feel free to summarize or repost my comments. -- Burt ======= This suggests that another way to meet the cryptoanalytic threat to host-to-host keying is to change the session key well before 2^32 plaintexts have been encrypted. Consequently, I think that requiring IPv6 security implementations to support user-to-user keying is too limiting. They can adequately meet this threat by judicious session key management. Dan From ipsec-request@ans.net Wed Mar 8 19:00:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17396 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 14:03:06 -0500 Received: by interlock.ans.net id AA04753 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 14:01:58 -0500 Message-Id: <199503081901.AA04753@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 14:01:58 -0500 From: Ran Atkinson Date: Wed, 8 Mar 1995 14:00:25 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "user-to-user vs. host-to-host keying" (Mar 8, 10:01) References: <199503081801.AA28611@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett , ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: user-to-user vs. host-to-host keying Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Dan, Your analysis was limited to DES. The specifications are algorithm-independent and NEED to support other algorithms such as RCx, IDEA, etc. The need for user-to-user keying remains clear. Handwaving about "judicious key management" is not a meaningful answer even for DES. Did you miss Jeff Schiller's comments on this at the Open IPng Directorate meeting in San Jose ? I can't do justice to his remarks but think they were well put. Ran atkinson@itd.nrl.navy.mil From iladmin@ans.net Wed Mar 8 18:37:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15172 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 14:29:00 -0500 Message-Id: <199503081929.AA15172@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Wed, 8 Mar 1995 14:23:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 14:23:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 14:23:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 8 Mar 1995 14:23:55 -0500 Date: Wed, 8 Mar 95 18:37:04 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: SAIDs I could swear you'd read the drafts. How could you have missed something this obvious!?! > From: Charles Lynn > Whether or not such an allocation is made, an implementation should be > able to solve the collision problem by making address> the key, instead of simply . ESP Page 2 The nodes use the combination of SAID and IP Destination to distinguish the correct association. AH Page 2 The nodes use the combination of SAID and IP Destination to distinguish the correct association. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 8 18:59:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17205 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 14:49:53 -0500 Received: by interlock.ans.net id AA23183 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 14:47:39 -0500 Message-Id: <199503081947.AA23183@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 14:47:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 14:47:39 -0500 Date: Wed, 8 Mar 95 18:59:58 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: user-to-user vs. host-to-host keying > From: Danny.Nessett@eng.sun.com (Dan Nessett) > This suggests that another way to meet the cryptoanalytic threat to host-to-host > keying is to change the session key well before 2^32 plaintexts have been > encrypted. Consequently, I think that requiring IPv6 security implementations > to support user-to-user keying is too limiting. They can adequately meet > this threat by judicious session key management. > Seems reasonable to me, but has nothing to do with user-user as opposed to host-host keying. All DES keys should be changed before 2^32 blocks. Big deal. I can't imagine any TCP session not doing that, on a user-user basis. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 8 04:00:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06668 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 15:09:33 -0500 Received: by interlock.ans.net id AA17498 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 15:01:40 -0500 Message-Id: <199503082001.AA17498@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 15:01:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 15:01:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 15:01:40 -0500 Date: Wed, 08 Mar 95 12:00:32 PST From: "burt" To: "William Allen Simpson" Cc: ipsec@ans.net, Matt_at_rsapo@snail.rsa.com Subject: Re[2]: WG last call for IPv4 MD5 The reason I recommended MD5(MD5(text),key) is that MD5(text) is something well understood; including the key requires additional analysis. MD5(text) is also input to digital signatures, so this gives a common mechanism for several applications. MD5(hash,key) is likely to involve only one application of MD5's compression function, and so should be easier to analyze than MD5(text,key). I agree that there's not much difference given the comments about folding you mention. But for other algorithms there may be a significant difference. It would be good to design in such a way that one can replace MD5 with another hash function, without worrying about unstated properties (e.g., must fold in a certain way). Or, at least to state the properties. We're working on some text for an RFC that Jim Galvin is drafting, which will address these concerns. -- Burt ______________________________ Reply Separator _________________________________ Subject: Re: WG last call for IPv4 MD5 Author: "William Allen Simpson" at INTERNET Date: 2/27/95 7:44 PM > Date: Mon, 27 Feb 1995 13:31:09 -0500 > From: "Perry E. Metzger" > Other than that, no objections; if the commentary is true I'm not > about to argue with Kaliski, although frankly having glanced at it I'm > not sure why MD5(MD5(text),key) would be stronger than MD5(text+key) > given MD5's way of folding in new text into a hash. It would be nice > to get some comments straight from the horse's mouth, as it > were. Anyone remember Burt Kaliski's email address? > Please copy ipsec@ans.net Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 8 20:01:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17169 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 15:09:54 -0500 Received: by interlock.ans.net id AA29320 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 15:02:49 -0500 Message-Id: <199503082002.AA29320@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 8 Mar 1995 15:02:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Mar 1995 15:02:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 15:02:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 15:02:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 15:02:49 -0500 Date: Wed, 8 Mar 1995 12:01:29 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipsec@ans.net, bsimpson@morningstar.com Subject: Re: user-to-user vs. host-to-host keying X-Sun-Charset: US-ASCII Bill, Your observation : > Seems reasonable to me, but has nothing to do with user-user as opposed > to host-host keying. All DES keys should be changed before 2^32 blocks. > Big deal. I can't imagine any TCP session not doing that, on a > user-user basis. > I believe misses the point of the original message. The concrete justification for user-to-user keying is that one user might be able to cryptoanalyze the traffic encrypted by a common host-to-host key, thereby obtaining the plaintext from another user's communication. If reasonable session key managment techniques are used, this is not a viable threat. Consequently, the justification for mandatory support of user-to-user keying evaporates. Dan From ipsec-request@ans.net Wed Mar 8 19:18:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04140 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 15:12:43 -0500 Received: by interlock.ans.net id AA29110 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 15:05:08 -0500 Message-Id: <199503082005.AA29110@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 8 Mar 1995 15:05:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Mar 1995 15:05:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 15:05:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 15:05:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 15:05:08 -0500 Date: Wed, 8 Mar 1995 11:18:28 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipng@sunroof.eng.sun.com, ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: Re: user-to-user vs. host-to-host keying X-Sun-Charset: US-ASCII > From rja@bodhi.itd.nrl.navy.mil Wed Mar 8 11:02:39 1995 > To: Dan Nessett , ipng@sunroof.Eng.Sun.COM, ipsec@ans.net > Subject: Re: user-to-user vs. host-to-host keying > Mime-Version: 1.0 > > Dan, > > Your analysis was limited to DES. The specifications are > algorithm-independent and NEED to support other algorithms > such as RCx, IDEA, etc. The need for user-to-user keying > remains clear. Handwaving about "judicious key management" > is not a meaningful answer even for DES. > > Did you miss Jeff Schiller's comments on this at the Open IPng > Directorate meeting in San Jose ? I can't do justice to his > remarks but think they were well put. > > Ran > atkinson@itd.nrl.navy.mil > > Ran, Yes I did miss Jeff's remarks. However, I wouldn't characterize my suggestion of "judicious key management" as handwaving. According to your architecture I-D, DES-CBC is the default encryption algorithm for the global Internet, so I believe the analysis I presented is pertinent for the default case. If another algorithm is being used, then a similar analysis would apply in order to discover the maximum amount of plaintext that should be encrypted by one key. Note that this value should also be known when user-to-user keying is employed, for the same cryptoanalytic threat exists in that case as well. That is, the user-to-user session key should be changed when a significant amount of plaintext has been encrypted with it. I am not saying that user-to-user keying shouldn't be allowed to thwart the threat you mention. I am saying it isn't the only way to combat this threat and therefore IPv6 implmentations should not be required to support it. Dan From ipsec-request@ans.net Wed Mar 8 10:06:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20029 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 15:14:36 -0500 Received: by interlock.ans.net id AA30500 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 15:07:33 -0500 Message-Id: <199503082007.AA30500@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 15:07:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 15:07:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 15:07:33 -0500 Date: Wed, 8 Mar 1995 15:06:50 +0500 From: Theodore Ts'o To: solo@BBN.COM Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net, solo@BBN.COM In-Reply-To: solo@BBN.COM's message of Wed, 08 Mar 95 09:00:54 -0500, <199503081406.AA32074@interlock.ans.net> Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 2226 Cc: ipsec@ans.net, solo@BBN.COM Date: Wed, 08 Mar 95 09:00:54 -0500 I, too, believe that the solutions we offer should be capable of accomodating both in-band and out-of-band KM (or key distribution). As with other topics, it seems that there are three options (probably more, but so it goes) for doing this: negotiation that includes IPSP format; structured SAIDs that connote IPSP format and semantics; and multiple protocol IDs. Essentially, the second option is a way to extend the protocol ID space without consuming additional IP next protocol numbers. I believe Russ's suggestion below has merit; but if we can't reach agreement on adding such structure to the SAID field, then I would suggest we consider adopting two protocol IDs, one for the fixed format structure Bill and Perry have espoused and one with comparable syntax but with the SAID based extensible option Russ describes. This argument seems to reduce to the efficiency of where "protocol" demultiplexing takes place. There is a forth option --- which is to reserve a single SAID to mean "we're initiating a new connection, and we're going to do the in-band keying thing". The first part of the packet payload would then contain information describing the type of the in-band keying, and any in-band keying specific data. I believe this is far superior than cedeing a large chunk of the SAID space --- it's more flexible. In addition, the whole concept of a "structured SAID" is a real perversion of the original meaning of a Secure Association ID. A structured SAID isn't really an ID. It's stealing 50% of the SAID space, and using a bit to indicate that the rest of the SAID is an escape for a particular in-band keying system. But it's extremely wasteful of the SAID space, and insufficiently flexible. After all, we only get to define the structure of the "structure SAID" once; and if we get it wrong, then that's it; we're stuck. This is why I still maintain that a "structured SAID" is really all about stealing one half of the SAID space for SKIP. There's no guarantee that no matter what scheme you use, that it will be good enough for the next in-band keying system. - Ted From ipsec-request@ans.net Wed Mar 8 20:29:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23302 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 15:33:50 -0500 Received: by interlock.ans.net id AA27510 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 15:30:40 -0500 Message-Id: <199503082030.AA27510@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 8 Mar 1995 15:30:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Mar 1995 15:30:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 15:30:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 15:30:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 15:30:40 -0500 Date: Wed, 8 Mar 1995 12:29:42 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: tytso@MIT.EDU Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net, solo@BBN.COM X-Sun-Charset: US-ASCII Ted, I agree with you that : > There is a forth option --- which is to reserve a single SAID to mean > "we're initiating a new connection, and we're going to do the in-band > keying thing". The first part of the packet payload would then contain > information describing the type of the in-band keying, and any in-band > keying specific data. > > I believe this is far superior than cedeing a large chunk of the SAID > space --- it's more flexible. In addition, the whole concept of a > "structured SAID" is a real perversion of the original meaning of a > Secure Association ID. A structured SAID isn't really an ID. It's > stealing 50% of the SAID space, and using a bit to indicate that the > rest of the SAID is an escape for a particular in-band keying system. > But it's extremely wasteful of the SAID space, and insufficiently > flexible. After all, we only get to define the structure of the > "structure SAID" once; and if we get it wrong, then that's it; we're > stuck. In fact Ashar Aziz and I have been working on a proposal along these lines for IPv6, which I am planning on sending out this afternoon. However, when you say > This is why I still maintain that a "structured SAID" is really all > about stealing one half of the SAID space for SKIP. I must disagree. SKIP is just one possible in-band keying method. At least one other exists, that designed by DEC. So I would say that using a bit in the SAID for in-band keying is not the most judicious use of the SAID identifier space. Dan From ipsec-request@ans.net Wed Mar 8 20:36:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27058 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 15:39:33 -0500 Received: by interlock.ans.net id AA17493 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 15:37:37 -0500 Message-Id: <199503082037.AA17493@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 15:37:37 -0500 From: Ran Atkinson Date: Wed, 8 Mar 1995 15:36:42 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: user-to-user vs. host-to-host keying" (Mar 8, 12:01) References: <199503082002.AA29320@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett Subject: Re: user-to-user vs. host-to-host keying Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Dan You confuse my "illustrative examples" for "sole justifications" very consistently. My text includes a fair number of illustrative examples. It does not include voluminous justifications for every item that has been discussed either on the IPng list or the IPsec list or at past IETF meetings in order to remain readably short. There are a number of reasons for user-to-user keying to be mandatory to implement. One remains the desire to reduce risk of chosen plaintext attacks. The only key management _mandated_ by IPv6 is manual key distribution. Because development of a scalable key management protocol is outside the charter of the IPng working group and no such standards-track RFC exists now, this is all that can be mandated at this time. Phil Karn and others are working hard on developing such a scalable key management protocol and I am optimistic that the Internet will have one in the future, but we do not have one now. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Mar 8 20:47:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15138 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 15:49:46 -0500 Received: by interlock.ans.net id AA32543 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 15:47:48 -0500 Message-Id: <199503082047.AA32543@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 15:47:48 -0500 From: Ran Atkinson Date: Wed, 8 Mar 1995 15:47:27 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: (IPng) Re: out-of-band key management is like virtual circuits" (Mar 8, 12:29) References: <199503082030.AA27510@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett , tytso@MIT.EDU Subject: Re: (IPng) Re: out-of-band key management Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Folks, I find it REALLY fascinating that Dan Nessett and Ashar Aziz now agree that they in fact don't need a Structured SAID and that they can get along fine with having a single SAID dedicated to mean that "what comes next is a special in-band thingy". I note that this capability is -- and has for many months -- been in the IPv6 specs. There is an entire block of reserved SAIDs for IANA to allocate as IANA sees fit. No changes to the specs are needed for this as the hook was ALREADY present in the IPv6/IPv4 security specs. Ted T'so suggested the single magic SAID to mean "next comes an in-band thingy" over a week ago. Bill Simpson pointed it out at least that far back, though in his usual inimitable style. :-) Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Mar 8 20:56:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27515 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 15:59:02 -0500 Received: by interlock.ans.net id AA32235 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 15:56:59 -0500 Message-Id: <199503082056.AA32235@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 8 Mar 1995 15:56:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Mar 1995 15:56:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 15:56:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 15:56:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 15:56:59 -0500 Date: Wed, 8 Mar 1995 12:56:19 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: atkinson@itd.nrl.navy.mil Subject: Re: user-to-user vs. host-to-host keying Cc: ipsec@ans.net, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Ran, I am copying your original message to me to ipng, since my response below specifically addresses issues in the IPng security drafts. I am not sure why you sent your message only to ipsec. You write : > From rja@bodhi.itd.nrl.navy.mil Wed Mar 8 12:38:00 1995 > To: Dan Nessett > Subject: Re: user-to-user vs. host-to-host keying > Cc: ipsec@ans.net > Mime-Version: 1.0 > > Dan > > You confuse my "illustrative examples" for "sole justifications" > very consistently. My text includes a fair number of illustrative > examples. It does not include voluminous justifications for every > item that has been discussed either on the IPng list or the IPsec > list or at past IETF meetings in order to remain readably short. > > There are a number of reasons for user-to-user keying to be mandatory > to implement. One remains the desire to reduce risk of chosen > plaintext attacks. The only key management _mandated_ by IPv6 > is manual key distribution. Because development of a scalable > key management protocol is outside the charter of the IPng working > group and no such standards-track RFC exists now, this is all that > can be mandated at this time. Phil Karn and others are working hard > on developing such a scalable key management protocol and I am > optimistic that the Internet will have one in the future, but we > do not have one now. > > Regards, > > Ran > atkinson@itd.nrl.navy.mil > > When you argue that : > The only key management _mandated_ by IPv6 is manual key distribution. you mislead. Allow me to quote from the current IPv6 security architecture draft (page 7): "4.3 Automated Key Distribution Widespread deployment and use of IPv6 security will require an Internet-standard scalable key management protocol ... ... Hence, support for user-to-user keying must be present in all IPv6 implementations, as is described in the "IPv6 Key Management Requirements" section below." This is a requirement that all IPv6 implementations support user-to-user keying. This is what I am objecting to. User-to-user keying should not be required of conformant IPv6 implementations. It is unnecessary to deal with the threats you call out. You suggest in your message that there may be other reasons for using user-to-user keying. If so, I think these should be given in the I-Ds, since the ones you do give are to weak to justify the mandatory requirement. Dan From ipsec-request@ans.net Wed Mar 8 21:01:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16357 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 16:05:27 -0500 Received: by interlock.ans.net id AA14988 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 16:03:07 -0500 Message-Id: <199503082103.AA14988@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 16:03:07 -0500 From: Ran Atkinson Date: Wed, 8 Mar 1995 16:01:01 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: user-to-user vs. host-to-host keying" (Mar 8, 12:56) References: <199503082056.MAA02359@elrond.Eng.Sun.COM> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett , atkinson@itd.nrl.navy.mil Subject: Re: user-to-user vs. host-to-host keying Cc: ipsec@ans.net, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Dan, I did a "reply-all" to your note. My response went wherever your original note went. As far as I'm concerned, this can be discussed wherever. Ran From ipsec-request@ans.net Wed Mar 8 21:14:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18563 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 16:20:49 -0500 Received: by interlock.ans.net id AA34810 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 16:15:58 -0500 Message-Id: <199503082115.AA34810@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 16:15:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 16:15:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 16:15:58 -0500 Date: Wed, 8 Mar 1995 14:14:26 -0700 From: Hilarie Orman To: burt@RSA.COM (Burt Kaliski) Cc: Matt_at_rsapo@snail.rsa.com, ipsec@ans.net In-Reply-To: Yourmessage <199503082001.AA17498@interlock.ans.net> Subject: Re: Re[2]: WG last call for IPv4 MD5 What exactly is the concern about MD5(key+text)? From ipsec-request@ans.net Wed Mar 8 21:43:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18094 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 16:50:15 -0500 Received: by interlock.ans.net id AA34639 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 16:46:42 -0500 Message-Id: <199503082146.AA34639@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 16:46:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 16:46:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 16:46:42 -0500 Date: Wed, 8 Mar 1995 14:43:33 -0700 From: Hilarie Orman To: Danny.Nessett@eng.sun.com Cc: atkinson@itd.nrl.navy.mil, ipng@sunroof.eng.sun.com, ipsec@ans.net In-Reply-To: Yourmessage <199503082056.AA32235@interlock.ans.net> Subject: Re: user-to-user vs. host-to-host keying > You suggest in your message that there may be other reasons for using > user-to-user keying. If so, I think these should be given in the I-Ds, > since the ones you do give are to weak to justify the mandatory requirement. I'd like to say that I concur with this request. We are in the process of prototyping this code (for ipv4), and it is difficult to motivate the design without a better understanding of the requirements of the use environment (more than "some people really want this"). From ipsec-request@ans.net Wed Mar 8 22:32:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16293 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 17:35:31 -0500 Received: by interlock.ans.net id AA21525 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 17:32:19 -0500 Message-Id: <199503082232.AA21525@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 17:32:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 17:32:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 17:32:19 -0500 Date: Wed, 8 Mar 1995 15:32:06 -0700 From: Hilarie Orman To: ipsec@ans.net Cc: burt@rsa.com In-Reply-To: Yourmessage <199503082146.AA34639@interlock.ans.net> Subject: Re: user-to-user vs. host-to-host keying My last question was stated wrong ... my question is, why was MD5(key,text,key) dropped as a the recommended method? From ipsec-request@ans.net Wed Mar 8 23:58:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22317 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 19:03:37 -0500 Received: by interlock.ans.net id AA25539 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 19:01:23 -0500 Message-Id: <199503090001.AA25539@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Mar 1995 19:01:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 19:01:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 19:01:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 19:01:23 -0500 Date: Wed, 8 Mar 1995 15:58:37 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management X-Sun-Charset: US-ASCII > From: Ran Atkinson > > I find it REALLY fascinating that Dan Nessett and Ashar Aziz now > agree that they in fact don't need a Structured SAID and that they > can get along fine with having a single SAID dedicated to mean > that "what comes next is a special in-band thingy". > > I note that this capability is -- and has for many months -- > been in the IPv6 specs. There is an entire block of reserved > SAIDs for IANA to allocate as IANA sees fit. No changes to the > specs are needed for this as the hook was ALREADY present in > the IPv6/IPv4 security specs. Ran, Does this mean that you agree that the following text should be taken out from Section 4 of the "IPv6 Security Architecture" document? "IPv6 is not intended to support so-called "in-band" key management, where the key management data is carried in a distinct IPv6 header. Instead it will primarily use so-called "out-of-band" key management, where the key management data will be carried by an upper layer protocol such as UDP or TCP on some specific port number." Regards, Ashar. From ipsec-request@ans.net Thu Mar 9 03:39:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17201 (5.65c/IDA-1.4.4 for ); Wed, 8 Mar 1995 22:48:35 -0500 Received: by interlock.ans.net id AA05388 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 8 Mar 1995 22:41:24 -0500 Message-Id: <199503090341.AA05388@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 8 Mar 1995 22:41:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 8 Mar 1995 22:41:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 8 Mar 1995 22:41:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 8 Mar 1995 22:41:24 -0500 To: ashar@osmosys.incog.com (Ashar Aziz) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management In-Reply-To: Your message of "Wed, 08 Mar 1995 15:58:37 PST." <199503090001.AA25539@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 08 Mar 1995 22:39:52 -0500 From: "Perry E. Metzger" Ashar Aziz says: > > Ran, > > Does this mean that you agree that the following text should be > taken out from Section 4 of the "IPv6 Security Architecture" document? > > "IPv6 is not intended to support so-called "in-band" key > management, where the key management data is carried in a > distinct IPv6 header. Instead it will primarily use so-called > "out-of-band" key management, where the key management data will > be carried by an upper layer protocol such as UDP or TCP on some > specific port number." I oppose the removal of the language. IPv6 and IPSP are NOT intended for "in-band" key management. The fact that you can get them to do it against the intentions of the designers does not change the intent and purpose of the original design. You have to live with that. Perry From ipsec-request@ans.net Thu Mar 9 05:57:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25777 (5.65c/IDA-1.4.4 for ); Thu, 9 Mar 1995 00:59:20 -0500 Received: by interlock.ans.net id AA36356 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Mar 1995 00:57:53 -0500 Message-Id: <199503090557.AA36356@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 9 Mar 1995 00:57:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 9 Mar 1995 00:57:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Mar 1995 00:57:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Mar 1995 00:57:53 -0500 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: Thu, 09 Mar 1995 00:57:31 -0500 To: ipsec@ans.net From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Where are we now? On Feb 28th, Cynthia Clark said: >In response to a number of requests from the IETF, and due to the >number of tasks the Secretariat needs to accomplish the week before the >Danvers IETF meeting, Internet-Drafts received after Friday, March >24, will not be announced nor made available in the internet-drafts >directories. This does not give the debating parties here much time to get their drafts out. Perhaps each side should prepare their own version and then we can see if we can reconcile them? Please? I need this stuff badly. As to the Dan Nessett's discussion on perfect forward security, I expect that I may need IPSP on 4,000 field units by year's end. I only want one configuration and one key management protocol. Some of these will meet the requirement Dan explained for perfect forward security, ERGO they all need it. Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Thu Mar 9 12:05:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20397 (5.65c/IDA-1.4.4 for ); Thu, 9 Mar 1995 07:15:00 -0500 Received: by interlock.ans.net id AA10512 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Mar 1995 07:09:11 -0500 Message-Id: <199503091209.AA10512@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Mar 1995 07:09:11 -0500 From: Ran Atkinson Date: Thu, 9 Mar 1995 07:05:49 -0500 In-Reply-To: ashar@osmosys.incog.com (Ashar Aziz) "Re: (IPng) Re: out-of-band key management" (Mar 8, 15:58) References: <199503090001.AA25539@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: out-of-band key management Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Ashar, "not intended to support..." is different from "is intended to prohibit...". There is rough consensus in the IPsec WG, which is the ONLY IETF WG chartered to work on key mgmt, that the primary standards-track key mgmt protocol will and should be a hybrid Diffie-Hellman scheme (such as Photuris). There is nothing resembling consensus in favour of SKIP-style in-band key mgmt as a mandatory-to-implement standards-track approach. My text as it stands is ENTIRELY consistent with the consensus direction in key mgmt. I do not plan any changes to the text you cited at this time. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Mar 9 12:45:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15294 (5.65c/IDA-1.4.4 for ); Thu, 9 Mar 1995 07:57:22 -0500 Received: by interlock.ans.net id AA17807 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Mar 1995 07:51:47 -0500 Message-Id: <199503091251.AA17807@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 9 Mar 1995 07:51:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Mar 1995 07:51:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Mar 1995 07:51:47 -0500 To: perry@imsi.com Cc: ashar@osmosys.incog.com (Ashar Aziz), ipng@sunroof.eng.sun.com, ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Re: out-of-band key management In-Reply-To: Your message of "Wed, 08 Mar 95 22:39:52 EST." <199503090341.AA05388@interlock.ans.net> Date: Thu, 09 Mar 95 07:45:19 -0500 From: bound@zk3.dec.com X-Mts: smtp >Ashar Aziz says: >> >> Ran, >> >> Does this mean that you agree that the following text should be >> taken out from Section 4 of the "IPv6 Security Architecture" document? >> >> "IPv6 is not intended to support so-called "in-band" key >> management, where the key management data is carried in a >> distinct IPv6 header. Instead it will primarily use so-called >> "out-of-band" key management, where the key management data will >> be carried by an upper layer protocol such as UDP or TCP on some >> specific port number." >I oppose the removal of the language. IPv6 and IPSP are NOT intended >for "in-band" key management. The fact that you can get them to do it >against the intentions of the designers does not change the intent and >purpose of the original design. You have to live with that. I think if in-band key management can be used it should be stated so in the spec as any other option would be. /jim From ipsec-request@ans.net Thu Mar 9 17:12:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21867 (5.65c/IDA-1.4.4 for ); Thu, 9 Mar 1995 12:18:44 -0500 Received: by interlock.ans.net id AA20769 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Mar 1995 12:15:46 -0500 Message-Id: <199503091715.AA20769@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 9 Mar 1995 12:15:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 9 Mar 1995 12:15:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 9 Mar 1995 12:15:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Mar 1995 12:15:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Mar 1995 12:15:46 -0500 Date: Thu, 9 Mar 1995 09:12:41 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: sob@newdev.harvard.edu Subject: Clarification Cc: ashar@jurassic.eng.sun.com, ipng@sunroof.eng.sun.com, ipsec@ans.net X-Sun-Charset: US-ASCII Scott, I wonder if you might clear up two points of administration. I and Ashar Aziz have been discussing the use of in-band keying in IPv6 using the IPv6 discussion list. These discussions relate to the 3 security I-Ds that Ran Atkinson is editing. Ran has recently emailed out a reply to us stating, " There is rough consensus in the IPsec WG, which is the ONLY IETF WG chartered to work on key mgmt, ... " In regards to this, I have 2 questions : 1. Are the drafts that Ran is editing for IPv6 the responsibility of the IPng or IPsec WG? 2. After Danvers, will these drafts be transfered to IPsec as part of the IPng area break up? Regards, Dan From ipsec-request@ans.net Thu Mar 9 17:51:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06680 (5.65c/IDA-1.4.4 for ); Thu, 9 Mar 1995 12:53:48 -0500 Received: by interlock.ans.net id AA16720 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Mar 1995 12:51:59 -0500 Message-Id: <199503091751.AA16720@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 9 Mar 1995 12:51:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Mar 1995 12:51:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Mar 1995 12:51:59 -0500 Date: Thu, 9 Mar 1995 10:51:19 -0700 From: Hilarie Orman To: ipsec@ans.net Subject: Re: multicasting & SAIDs Is anyone concerned about defining the use of digital signatues for sender authentication in multicast and IPv4 broadcast? From ipsec-request@ans.net Thu Mar 9 21:16:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20465 (5.65c/IDA-1.4.4 for ); Thu, 9 Mar 1995 16:16:27 -0500 Received: by interlock.ans.net id AA52890 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Mar 1995 16:13:52 -0500 Message-Id: <199503092113.AA52890@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Mar 1995 16:13:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Mar 1995 16:13:52 -0500 Date: Thu, 9 Mar 1995 16:16:34 -0500 (EST) From: Scott Bradner To: Danny.Nessett@eng.sun.com, sob@newdev.harvard.edu Subject: Re: Clarification Cc: ashar@jurassic.eng.sun.com, ipng@sunroof.eng.sun.com, ipsec@ans.net Dan, I've checked this out with Ran, the Security AD, and the Internet ADs they, and I, all agree that the finalization of the security documents will be a responsibility of the IPSEC WG after the IPng area folds. Scott From ipsec-request@ans.net Tue Mar 7 20:02:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28137 (5.65c/IDA-1.4.4 for ); Thu, 9 Mar 1995 23:49:53 -0500 Received: by interlock.ans.net id AA22824 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 9 Mar 1995 23:48:27 -0500 Message-Id: <199503100448.AA22824@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 9 Mar 1995 23:48:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 9 Mar 1995 23:48:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 9 Mar 1995 23:48:27 -0500 To: ipng@sunroof.eng.sun.com, ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 07 Mar 95 13:42:36 EST." <199503071850.AA29002@interlock.ans.net> Date: Tue, 07 Mar 95 15:02:53 -0500 From: bound@zk3.dec.com X-Mts: smtp The latest specs on IPv6 security now clearly state that in-band cannot be used for IPv6. Seeing how Dan and others are promoting in-band security as a technology we may want in the future, and that the ipng mail list will be asked to do a last call prior to IPv6 Security going to proposed standard, why I think it was very informative and kindly to see Dan's mail on the IPng list. But I also hope that any discussion re: in-band vs out-band be done on IPSEC mail list not both. I will also add that ESP requires DES. Could we select an encryption algorithm that has no export restrictions any where in the world. Also for companies doing development internationally where engineers on teams are located in different geographical locations it makes it tough on software planning. For example I would not be able to give one of my engineering colleagues DES code from the U.S., if they were working in the Ural Mountains doing the IPv6 ESP Security work on my project. This kind of bugs me. Another one for IPSEC I think. thanks Dan, /jim From ipsec-request@ans.net Fri Mar 10 13:59:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18527 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 09:09:20 -0500 Received: by interlock.ans.net id AA19184 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 09:02:18 -0500 Message-Id: <199503101402.AA19184@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 09:02:18 -0500 From: Ran Atkinson Date: Fri, 10 Mar 1995 08:59:58 -0500 References: <199503100448.AA22824@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Folks, 1) The IPv6 specs do NOT "clearly state that in-band cannot be used for IPv6". The IPv6 specs merely state that the IPv6 security specs were "not intended for use with in-band" key management. In-band clearly works as has been described by Ted T'so and others. Even the in-band advocates believe that it will using the technique that Ted has described. Within an IETF spec, things that are not explicitly prohibited using "MUST NOT" language are permitted. There is no language that I am aware of that says one "MUST NOT" use in-band key management or even says one "SHOULD NOT" use in-band key management. There is a difference between what the designer intended and what is possible and permitted. 2) With regard to the export issues, I can provide some data, but I don't have any legal answers (I'm not a lawyer :-) : I am not an expert on laws in any country, but I have been told repeatedly by folks in France that French law prohibits all USE of all encryption algorithms even by French citizens within France (except under special circumstances where the user has prior permission from the French government). I mention France only to provide a specific example. There are probably other countries at least this restrictive in their laws and regulations. This not withstanding, it is widely known that certain anonymous ftp sites in Finland make DES and other encryption algorithm source code freely available with no technical restrictions on access from outside Finland. I do not know if Finnish law regulates exports or not, but in practice those systems will de facto permit downloading to anyplace on the net. It is my understanding that someone from TIS actually demonstrated this fact to the US Congress during hearings sometime in the past several years (Steve Crocker probably knows the details on this). At least one major router vendor (i.e. Network Systems) now has DES encryption of IP traffic as a commercially available option. They use a hybrid Diffie-Hellman key mgmt technique. This to me indicates that they believe they have a business case to sell such an option. Other businesses might well decide they do not have such a business case. 3) I have some data on DES hardware that some might find interesting and so I'll pass it along for information. This is not and must not be misconstrued as an endorsement of any vendors product : Digital Equipment Corporation made a demonstration to the IPsec working group at the Columbus IETF meeting of fast DES encryption hardware that they were designing/manufacturing in Israel and then exporting to various countries (including the US). If I understood the DEC people correctly, one reason for selecting Israel was that it was less restrictive than the US about exports of DES hardware. I do not recall exactly how fast the DEC DES chip is, but I think it was over 100 Mbps. By the way, the US firm "VLSI Technology" reportedly also has a commercially available DES chip that will process hundreds of megabits per second. I have not actually seen or used such a chip, so this might be vaporware. There might also be other vendors of similar products that I am not aware of at this time. I do not endorse any particular vendors product. I am just trying to note that fast DES encryption appears commercially implementable. I would be interested to hear about any MD5 or SHA hardware that is/will-be commercially available. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Mar 10 15:36:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22857 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 10:47:24 -0500 Received: by interlock.ans.net id AA35464 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 10:37:57 -0500 Message-Id: <199503101537.AA35464@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 10:37:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 10:37:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 10:37:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 10:37:57 -0500 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipsec@ans.net, bsimpson@morningstar.com Subject: Re: user-to-user vs. host-to-host keying In-Reply-To: Your message of "Wed, 08 Mar 1995 12:01:29 PST." <199503082002.AA29320@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Mar 1995 10:36:31 -0500 From: "Perry E. Metzger" Dan Nessett says: > I believe misses the point of the original message. The concrete > justification for user-to-user keying is that one user might be able > to cryptoanalyze the traffic encrypted by a common host-to-host key, > thereby obtaining the plaintext from another user's > communication. If reasonable session key managment techniques are > used, this is not a viable threat. Consequently, the justification > for mandatory support of user-to-user keying evaporates. Dan; No they don't. There are large numbers of reasons for wanting per socket keying. The IETF works on consensus, and you can be damn well sure I'm not going to be part of a consensus -- ever -- for a system that doesn't permit per-socket keying. I'm obdurate on this point. Ultimately, Dan, what you are trying to do is push SKIP. I would suggest that rather than attack the concept of per-user keying you be honest and say "I don't think SKIP can support per-user keying and since I'm a SKIP proponent I have to find ways to justify why we can live without having it". It would be far more honest. Your recent trend of posting abstract broadsides that make no mention of SKIP and your underlying motivations feels rather, well, distasteful. I feel people should be honest and say what their biases are out front. At the moment, my bias is towards something that looks far more like Photuris. I see SKIP as a cute bunch of cryptographic hacks done by clever cryptographers. It doesn't strike me as having any real advantages, however, and it does strike me as having many disadvantages. 1) It is tied intimately to a single cryptographic trick. If anyone ever finds a way around that trick, SKIP is dead. Other protocols, like Photuris, are ultimately tied more to the idea of exchanging keys than particular key exchange protocols. This might not be obvious to people with more cryptography experience than engineering experience because they will see both proposals as being tied intimately to things like the discrete log problem. However, this isn't really the case -- Photuris like protocols can be altered. SKIP is a one trick horse. 2) It ultimately has no performance benefits no matter what Ashar and Dan vigorously assert. 3) It claims to be "sessionless" but this is in the end meaningless semantic play -- it keeps at least as much state around as any other proposal. 4) It doesn't support per user keying. 5) It can't really support perfect forward secrecy. 6) The proposal uses X.509 certificates, which in and of themselves are a problem, but they aren't even conventional X.509 certificates and depends on a non-existent key management infrastructure. Photuris and company can use Eastlake-Kaufman style key infrastructure without much trouble. 7) It doesn't match up well with the layered security architecture that we were following from the start. There are more -- Steve Bellovin has noted a large number of problems -- but these are things that just come to mind off the top of my head. Doubtless Danny will be posting complete (in his opinion) refutations of all my points -- without mentioning SKIP by name, for whatever reason. Doubtless Ashar will disagree vigorously with me as well. However, at this point, my mind is very solidly trending away from SKIP unless very strong evidence in another direction shows up. To me, the worst part of SKIP is that it really does feel like Yet Another Very Clever Cryptographic Hack, of the sort that fill the Crypto and Eurocrypt proceedings. These clever hacks certainly get papers published, and I can see why professional mathematical cryptographers have a fondness for them for that reason, but they rarely have pragmatic engineering potential, and I'm not sure that we should be elevating a hack to the status of a standard. Overall, I'm not sure that SKIP is going to have much success in winning my support unless I see substantially more evidence in favor of it than I have seen thus far. Perry From ipsec-request@ans.net Fri Mar 10 15:56:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28129 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 11:12:36 -0500 Received: by interlock.ans.net id AA13303 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 10:58:22 -0500 Message-Id: <199503101558.AA13303@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 10:58:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 10:58:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 10:58:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 10:58:22 -0500 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 07 Mar 1995 15:02:53 EST." <9503072002.AA28302@xirtlu.zk3.dec.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Mar 1995 10:56:54 -0500 From: "Perry E. Metzger" bound@zk3.dec.com says: > I will also add that ESP requires DES. Could we select an encryption > algorithm that has no export restrictions any where in the world. Sure. Use ROT13. There is *no* cryptographic algorithm with is of any use that is acceptable to all governments on earth. I oppose the evisceration of critical internet technologies to appease the short-sighted paranoiacs working for some governments. (Did you know that Pakistan just banned the use of cellphones because their secret police find they are too much of a pain to trace?) I say that we simply behave like engineers and design the best system we can, and leave it to the governments to cripple their own countries by making it impossible for their citizenry to join the internet, or by leaving their citizens open to massive fraud and invasion of privacy. I will not lend my support to a consensus for anything less than the best system I know how to design, and I suspect that others feel the same way. Perry From ipsec-request@ans.net Fri Mar 10 16:27:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18637 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 11:52:44 -0500 Received: by interlock.ans.net id AA27559 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 11:29:27 -0500 Message-Id: <199503101629.AA27559@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 11:29:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 11:29:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 11:29:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 11:29:27 -0500 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware In-Reply-To: Your message of "Fri, 10 Mar 1995 07:48:16 PST." <199503101548.HAA03485@elrond.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Mar 1995 11:27:47 -0500 From: "Perry E. Metzger" Dan Nessett says: > Ran, > > Given your agreement that IPv6 can be used to support in-band keying, what > is your objection to removing the paragraph that states it is "not intended" > to do so? The designers want it to be clear what their intent was. I, for one, object to any proposal to eliminate information on that intent from the documents. Perry From ipsec-request@ans.net Fri Mar 10 15:48:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21489 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 11:55:07 -0500 Received: by interlock.ans.net id AA48038 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 11:39:50 -0500 Message-Id: <199503101639.AA48038@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 10 Mar 1995 11:39:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 11:39:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 11:39:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 11:39:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 11:39:50 -0500 Date: Fri, 10 Mar 1995 07:48:16 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipng@sunroof.eng.sun.com, ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware X-Sun-Charset: US-ASCII > From rja@bodhi.itd.nrl.navy.mil Fri Mar 10 06:22:03 1995 > To: ipng@sunroof.Eng.Sun.COM, ipsec@ans.net > Subject: Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware > Mime-Version: 1.0 > > Folks, > > 1) The IPv6 specs do NOT "clearly state that in-band cannot be used > for IPv6". > > The IPv6 specs merely state that the IPv6 security specs were "not > intended for use with in-band" key management. In-band clearly works > as has been described by Ted T'so and others. Even the in-band > advocates believe that it will using the technique that Ted has > described. Within an IETF spec, things that are not explicitly > prohibited using "MUST NOT" language are permitted. There is no > language that I am aware of that says one "MUST NOT" use in-band key > management or even says one "SHOULD NOT" use in-band key management. > There is a difference between what the designer intended and what > is possible and permitted. Ran, Given your agreement that IPv6 can be used to support in-band keying, what is your objection to removing the paragraph that states it is "not intended" to do so? Dan From ipsec-request@ans.net Fri Mar 10 06:46:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06902 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 12:13:47 -0500 Received: by interlock.ans.net id AA32015 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 11:46:42 -0500 Message-Id: <199503101646.AA32015@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 11:46:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 11:46:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 11:46:42 -0500 Date: Fri, 10 Mar 1995 11:46:22 +0500 From: Theodore Ts'o To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net, bound@zk3.dec.com In-Reply-To: bound@zk3.dec.com's message of Tue, 07 Mar 95 15:02:53 -0500, <199503100448.AA22824@interlock.ans.net> Subject: Re: (IPng) Proposed message on perfect forward security Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1149 Date: Tue, 07 Mar 95 15:02:53 -0500 From: bound@zk3.dec.com I will also add that ESP requires DES. Could we select an encryption algorithm that has no export restrictions any where in the world. No --- there's no such thing. Well, maybe ROT-13 counts, but technically you still need an export license for it. (Pathetically weak systems like DES with 40 bit keys fall in the same category as ROT-13, for all intents and purposes). This issue has been talked to death many times before, in many different forums. In all such forums that I recall within the IETF, the consensus that has always been reached is that we should design the best system we can, regardless of export issues --- and if certain world governments want to restrict the ability of their companies to compete in the global marketplace, that's those government's business. If we want to avoid export hassles altogether, the only way to do that is to punt on encryption altogether --- and I think we've all agreed that protecting data confidentialty is a good thing. Do we really have to open this for discussion yet again? I really hope not.... - Ted From ipsec-request@ans.net Fri Mar 10 16:55:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20059 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 12:20:55 -0500 Received: by interlock.ans.net id AA44785 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 11:56:56 -0500 Message-Id: <199503101656.AA44785@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 10 Mar 1995 11:56:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 11:56:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 11:56:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 11:56:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 11:56:56 -0500 Date: Fri, 10 Mar 1995 08:55:08 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipsec@ans.net Subject: Modifications to the ESP I-D (long) X-Sun-Charset: US-ASCII Folks, I have been advised by one of the IPng area co-directors that the security work for IPv6 will move to the IPsec WG after Danvers. Since there may be decisions at Danvers made by the IPsec WG that may affect IPv6 security, I thought I would re-post three mailings I made to IPng (but not to IPsec) that suggest substantive chantges to the current IPng security I-Ds. Regards, Dan Nessett ----- Begin Included Message ----- From nessett@jurassic Wed Mar 8 16:01:36 1995 To: ipng@sunroof Subject: (IPng) Modifications to the ESP I-D (long) I propose the following changes to the current version of the IPv6 Encapsulating Security Payload I-D [draft-ietf-ipngwg-esp-0a.txt]. I acknowledge that the exact phrasing of the change is a matter for the editor to decide. I provide suggested wording only to make clear the substantive changes I am suggesting. In addition, I am open to other proposals, such as the one suggested by Russ Housley, that would allow the use of in-band keying with IPv6. I am sending this out now so that we have at least one concrete proposal to discuss in Danvers. page 4, para. 2, section 3.1 - change to read : A 32-bit pseudo-random value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x00000000. If in-band keying is employed, this field shall be 0x00000001. The set of SAID values in the range 0x00000002 through 0x000000FF are reserved for future use. A security association is normally one-way. An authenticated communications session between two hosts will normally have two SAIDs in use (one in each direction). Reason for this change - To indicate in-band keying requires an SAID that is not a legal pre-established value. I chose the value 1 arbitrarily and would be open to some other value that is now reserved. page 4, para. 4, section 3.1 - change to read : Senders to a multicast group may share a common SAID for all communications if all communications are authenticated using the same security configuration parameters (e.g. algorithm, key, security classification level, etc.). In this case, the receiver only knows that the message came from a host knowing the security association data for the group and cannot authenticate which member of the group sent the datagram. Multicast groups may also use a separate SAID for each sender. In any event, the combination of Destination Address, optional fields within the synchronization data and the SAID is used to determine the correct security association data. If each sender is keyed separately and asymmetric algorithms are used, data origin authentication is also a provided service. Reason for this change - The presence of the optional in-band keying fields within the synchronization data would be additional information necessary to determine the correct security association data. page 5, para. 5, section 3.1 - change to read : Each SAID value, optional fields within the synchronization data and the destination address imply the key(s) used to encrypt and decrypt the encrypted portion of the ESP payload, the sensitivity level (e.g. Secret, Unclassified) of the user data in the ESP payload, the encryption algorithm being used, the block size (if any) of the encryption algorithm, the authentication algorithm being used (if separate from the encryption algorithm), the block size (if any) of the authentication algorithm, and the presence/absence and size of a cryptographic synchronisation or initialisation vector field at the start of the encrypted portion of the ESP (if no such field is present, then the size is of course zero). Reason for this change - same as those given in the previous callout. page 5, para. 5, section 3.1 - change to read : The sending host uses the sending userid and destination host to select an appropriate Security Association (and hence SAID value). The receiving host uses the combination of SAID value, optional fields within the synchronization data, and originating address to distinguish the correct association. Reason for this change - same as those givin in the previous two callouts. Also, the last sentence is removed since it is redundant. page 5, para. 6, section 3.1 - change to read : This field is present only for algorithms which require a cryptographic synchronisation field for each packet and for carrying in-band keying information, if present. The value of this field is arbitrary. The length of this field is variable, though for any given algorithm it has a particular known length. It is considered to be plaintext in this document, though most users will not be able to make sense of its contents. Its presence or absence are constant for all secure datagrams of any given SAID value. The ESP specification includes this field so that the payload specification will be independent of the cryptographic algorithm that is being used by the communicating systems. If present, the field contains cryptographic synchronisation data, such as a DES Initialisation Vector, for whichever algorithm is in use [ISO92b] or it contains in-band keying data. An ESP implementation will normally use the Security Association Identifier value for the payload being processed to determine whether this field is present and to determine the field's size and use if present. Reason for this change - The text indicates that the synchronization data may carry in-band keying data. page 5, after para. 6, section 3.1 - add the following text : When the SAID value indicates in-band keying, the synchronization data field carries Key Management method specific information, In that case the format of the Encapsulating Security Payload is as follows : +--------------+---------------+----------------+--------------+ | Security Association Identifier (=0x00...1) | +--------------+---------------+----------------+--------------+ |Key Management| Key Management Info | | ID | | +--------------+-----------------+----------------+------------+ | Key Management Info (variable length) | +--------------+---------------+----------------+--------------+ | Encrypted Data | +--------------+---------------+----------------+--------------+ The key management ID specifies the format of the remaining data in the Encapsulating Security Payload. Key management IDs are allocated by the Internet Assigned Numbers Authority (IANA). The remaining information in the synchronization data is formated according to rules specific to the indicated Key Management protocol. Each Key Management protocol is defined in a separate RFC. Reason for the change - This additional format information is necessary to support in-band keying within the ESP. It allows the specification of new in-band key management protocols as they are developed by only specifying a Key Management ID and leaving the format of the remaining information to be specified in a separate RFC. page 7, para. 2, section 4.1 - change to read : The receiver strips off the cleartext IPv6 header and cleartext optional IPv6 payloads (if any) and discards them. It then uses the combination of Destination Address, optional information within the synchronization data and SAID value to obtain the correct decryption key to use for this packet. Then, it decrypts the ESP using the session key that has been established for this traffic. Reason for this change - The presence of the optional in-band keying fields within the synchronization data would be additional information necessary to determine the correct decryption key. page 8, para. 2, section 4.2 - change to read : The receiver processes the cleartext IPv6 header and cleartext optional IPv6 headers (if any) and temporarily stores pertinent information (e.g. source and destination addresses, Flow ID, Routing Header). It then decrypts the ESP using the session key that has been established for this traffic, using the combination of the destination address, optional information within the synchronzation data and the packet's Security Association Identifier (SAID) to locate the correct key. Reasons for this change - same as those given in the previous callout. page 10, para. 4, section 7 - change to read : If user-to-user keying is not in use, then the algorithm in use should not be vulnerable to any kind of Chosen Plaintext attack. A Chosen Plaintext attack on DES is described in [BS93]. Use of user-to-user keying is one way to preclude any sort of Chosen Plaintext attack and to generally make cryptanalysis more difficult. Another is to change the session key with sufficient frequency that deprives the cryptoanalyst of enough plaintext/ ciphertext pairs to carry out an effective attack. Reasons for this change - Since user-to-user keying is only one way to address problems arising from cryptoanalytic attacks, alternative methods should be mentioned. Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ----- End Included Message ----- From ipsec-request@ans.net Fri Mar 10 16:54:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23388 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 12:20:56 -0500 Received: by interlock.ans.net id AA42475 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 11:56:44 -0500 Message-Id: <199503101656.AA42475@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 10 Mar 1995 11:56:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 11:56:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 11:56:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 11:56:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 11:56:44 -0500 Date: Fri, 10 Mar 1995 08:54:40 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipsec@ans.net Subject: (IPng) Suggested modifications to the AH I-D (long) X-Sun-Charset: US-ASCII Folks, I have been advised by one of the IPng area co-directors that the security work for IPv6 will move to the IPsec WG after Danvers. Since there may be decisions at Danvers made by the IPsec WG that may affect IPv6 security, I thought I would re-post three mailings I made to IPng (but not to IPsec) that suggest substantive chantges to the current IPng security I-Ds. Regards, Dan Nessett ----- Begin Included Message ----- From nessett@jurassic Wed Mar 8 16:01:40 1995 To: ipng@sunroof Subject: (IPng) Suggested modifications to the AH I-D (long) I propose the following changes to the current version of the IPv6 Authentication Header I-D [draft-ietf-ipngwg-sec-00.txt]. I acknowledge that the exact phrasing of the change is a matter for the editor to decide. I provide suggested wording only to make clear the substantive changes I am suggesting. In addition, I am open to other proposals, such as the one suggested by Russ Housley, that would allow the use of in-band keying with IPv6. I am sending this out now so that we have at least one concrete proposal to discuss in Danvers. page 3, 1st para., section 2 - modify to read - 'Key management is an important part of the IPv6 security architecture. IPv6 tries to decouple the key management mechanisms from the security protocol mechanisms. The only coupling between the key management protocol and the security protocol is with the Security Association Identifier (SAID) and with optional fields within the authentication data, which are described in more detail below. This decoupling permits several different key management mechanisms to be used. More importantly, it permits the key management protocol to be changed or corrected without unduly impacting the security protocol implementations.' Reasons for this change - to support in-band keying, the coupling between the security protocol and the key management protocol could also depend on data carried by the packet in the authentication field. page 4, para. 1, section titled "Security Association Identifier (SAID) - modify to read: A 32-bit pseudo-random value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x00000000. If in-band keying is employed, this field shall be 0x00000001. The set of SAID values in the range 0x00000002 through 0x000000FF are reserved for future use. A security association is normally one-way. An authenticated communications session between two hosts will normally have two SAIDs in use (one in each direction). The combination of SAID value, optional fields within the authentication data, and destination address uniquely identifies the security association. The destination address may, of course, be a multicast group address. Reason for this change - To indicate in-band keying requires an SAID that is not a legal pre-established value. I chose the value 1 arbitrarily and would be open to some other value that is now reserved. page 6, para. 1, section 4 - modify the first sentence to read : When not carrying in-band data, the authentication data is usually calculated using a message digest algorithm (e.g. MD5) either encrypting that message digest or keying the message digest directly. Reason for this change - the conditional at the beginning of the sentence clarifies that the authentication data field may carry additional key management specific information. page 7, after para. 6, section 4 - insert the following text. 'When the SAID value indicates in-band keying, the format of the authentication header is as follows : +--------------+-----------------+----------------+------------+ | Next Payload | Length | RESERVED | +--------------+-----------------+----------------+------------+ | Security Association Identifier (=0x00...1) | +--------------+---------------+----------------+--------------+ |Key Management| Key Management Info | | ID | | +--------------+-----------------+----------------+------------+ | Key Management Info (variable length) | +--------------+---------------+----------------+--------------+ The key management ID specifies the format of the remaining data in the Authentication Header. Key management IDs are allocated by the Internet Assigned Numbers Authority (IANA). The remaining information in the authentication data field is formated according to rules specific to the indicated Key Management protocol. Each Key Management protocol is defined in a separate RFC.' Reason for the change - This additional format information is necessary to support in-band keying within the AH. It allows the specification of new in-band key management protocols as they are developed by only specifying a Key Management ID and leaving the format of the remaining information to be specified in a separate RFC. page 7, para. 1, section 5 - modify to read Implementations that claim conformance or compliance with this specification MUST fully implement the option described here, and MUST support the use of keyed MD5 as described in Appendix A of this document. Either host-to-host manual key distribution or user- to-user manual key distribution MAY be used with this option. Support for other authentication algorithms is not mandatory to comply or conform with this specification. Implementors should consult the most recent version of the IAB Official Standards document for further guidance on the status of this document. Reason for the change - Requiring all implementations to support user-to-user key distribution is onerous and unnecessary. Threats against encrypted communications based on widely know cryptanalytic techniques, such as differential or linear cryptanalysis can be thwarted by judicious rekeying of the communications key variables. User-to-user key distribution is another way to achieve protection in this regard, but is difficult to implement for some key management schemes. Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ----- End Included Message ----- From ipsec-request@ans.net Fri Mar 10 16:54:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22629 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 12:21:13 -0500 Received: by interlock.ans.net id AA10982 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 11:56:35 -0500 Message-Id: <199503101656.AA10982@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 10 Mar 1995 11:56:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 11:56:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 11:56:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 11:56:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 11:56:35 -0500 Date: Fri, 10 Mar 1995 08:54:22 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipsec@ans.net Subject: Proposed modifications to IPv6 Security Architecture I-D (long) X-Sun-Charset: US-ASCII Folks, I have been advised by one of the IPng area co-directors that the security work for IPv6 will move to the IPsec WG after Danvers. Since there may be decisions at Danvers made by the IPsec WG that may affect IPv6 security, I thought I would re-post three mailings I made to IPng (but not to IPsec) that suggest substantive chantges to the current IPng security I-Ds. Regards, Dan Nessett ----- Begin Included Message ----- From nessett@jurassic Wed Mar 8 16:01:45 1995 To: ipng@sunroof Subject: (IPng) Proposed modifications to IPv6 Security Architecture I-D (long) I propose the following changes to the current version of the IPv6 Security Architecture I-D [draft-ietf-ipngwg-sec-00.txt]. At those places where text is to be changed (as opposed to being simply deleted), I provide a suggested wording. Of course, the exact phrasing of the change is a matter for the editor to decide. I provide suggested wording only to make clear the substantive changes I am suggesting. Page 6, first para., section 4 - delete the text "IPv6 is not intended to support so-called "in-band" key management, where the key management data is carried in a distinct IPv6 header. Instead it will primarily use so-called "out-of-band" key management, where the key management data will be carried by an upper layer protocol such as UDP or TCP on some specific port number. This permits clear decoupling of the key management mechanism from the other security mechanisms, and thereby permits one to substitute new and improved key management methods without having to modify the implementations of the other security mechanisms. This is clearly wise given the long history of subtle flaws in published key management protocols. [NS78, NS81] What follows in this section is a brief discussion of a few alternative approaches to key management." Reasons for this change - There is no significant justification for prohibiting the use of in-band key management. This text was added after debate began on whether in-band key management should be allowed and before any resolution of that question. page 6-7, para. 2, section 4.3 - modify the text : 'When host-to-host keying is used and mutually suspicious users exist, it is possible for user A to determine the host-to-host key via well known methods, such as a Chosen Plaintext attack. Once user A has improperly obtained the key in use, user A can then either read user B's encrypted traffic or forge traffic from user B. When user-to-user keying is used, this kind of attack from one user onto another user's traffic is not possible. Hence, support for user-to-user keying must be present in all IPv6 implementations, as is described in the "IPv6 Key Management Requirements" section below.' to read 'When host-to-host keying is used and mutually suspicious users exist, it is theoretcially possible for user A to determine the host-to-host key via well known methods, such as a Known or Chosen Plaintext attack. These methods require a very large amount of plaintext/ciphertext pairs, the best method known in the public literature requiring 2^43 such data pairs. Conservatively, one may not feel comfortable using the same key to encrypt more than around 2^32 plaintexts. If user A has improperly obtained the key in use, user A can then either read user B's encrypted traffic or forge traffic from user B. This threat may be thwarted by either changing the encrypting key well before the required amount of text has been encrypted or by using user-to-user keying. Hence, support for user-to-user keying may be present in an IPv6 implementation, as is described in the "IPv6 Key Management Requirements" section below.' Reasons for this change - User-to-user keying may be useful in some situations, but given the state-of-the-art in cryptanalysis, more efficient and convenient methods exist for addressing the rationale for it given in the existing I-D. Rekeying the communications key well before the amount of ciphertext generated approaches the necessary volume is an attractive alternative. Requiring IPv6 implementations to support user-to-user keying is onerous and unnecessary. page 8, 2nd para., section 4.5 - - modify the text : 'All IPv6 implementations MUST support manual key management. All IPv6 implementations SHOULD support an Internet standard key management protocol once the latter is defined. All IPv6 implementations MUST permit the configuration and use of user-to-user keying for traffic originating at that system and MAY additionally permit the configuration of host-to-host keying for traffic originating at that system as an added feature to make manual key distribution easier and give the system administrator more flexibility.' to read 'All IPv6 implementations MUST support manual key management. All IPv6 implementations SHOULD support an Internet standard key management protocol once the latter is defined. All IPv6 implementations MAY permit the configuration and use of user-to-user keying for traffic originating at that system and MAY additionally permit the configuration of host-to-host keying for traffic originating at that system as an added feature to make manual key distribution easier and give the system administrator more flexibility.' Reasons for this change - see reasons given above. Regards, Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ----- End Included Message ----- From ipsec-request@ans.net Fri Mar 10 17:23:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27133 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 12:58:15 -0500 Received: by interlock.ans.net id AA47805 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 12:45:27 -0500 Message-Id: <199503101745.AA47805@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 12:45:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 12:45:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 12:45:27 -0500 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Fri, 10 Mar 95 10:56:54 EST." <9503101556.AA26675@snark.imsi.com> Date: Fri, 10 Mar 95 12:23:44 -0500 From: bound@zk3.dec.com X-Mts: smtp Perry, bound@zk3.dec.com says: > I will also add that ESP requires DES. Could we select an encryption > algorithm that has no export restrictions any where in the world. >I oppose the evisceration of critical internet technologies to appease >the short-sighted paranoiacs working for some governments. (Did you >know that Pakistan just banned the use of cellphones because their >secret police find they are too much of a pain to trace?) I am not a paranoiac and object to your tone again. It was a question dude. Lighten up. Ran answered it just fine. >I say that we simply behave like engineers and design the best system >we can, and leave it to the governments to cripple their own countries >by making it impossible for their citizenry to join the internet, or >by leaving their citizens open to massive fraud and invasion of >privacy. I will not lend my support to a consensus for anything less >than the best system I know how to design, and I suspect that others >feel the same way. I see no consensus that you keep saying with phrases like "I suspect that others feel the same way". I do see one hand clapping. Nothing you can say will convince me of not wanting the option of in-band keying in the spec. Because I believe it should be a technology option I as an engineer may build in my products, for the explicit reasons Dan has described consistently. In addition I agree with Dan that the present wording that in-band is not recommended is wrong. I with Dan and others will object at last call to that wording in the document if it is to go to proposed standards before Danvers MA. Done!, and as far as I am concerned there is no consensus to support your views technically on any of the security subjects discussed in this rather extensive mail exchange. You have a view and others have a different view. Your not winning the debate your just sending a lot of mail. /jim From ipsec-request@ans.net Fri Mar 10 17:28:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19718 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 12:58:38 -0500 Received: by interlock.ans.net id AA21703 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 12:46:30 -0500 Message-Id: <199503101746.AA21703@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 12:46:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 12:46:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 12:46:30 -0500 To: perry@imsi.com Cc: Danny.Nessett@eng.sun.com (Dan Nessett), ipng@sunroof.eng.sun.com, ipsec@ans.net, atkinson@itd.nrl.navy.mil, bound@zk3.dec.com Subject: Re: (IPng) in-band key mgmt, IPV6, export issues, DES hardware In-Reply-To: Your message of "Fri, 10 Mar 95 11:27:47 EST." <199503101629.AA27559@interlock.ans.net> Date: Fri, 10 Mar 95 12:28:56 -0500 From: bound@zk3.dec.com X-Mts: smtp >Dan Nessett says: >> Ran, >> >> Given your agreement that IPv6 can be used to support in-band keying, what >> is your objection to removing the paragraph that states it is "not intended" >> to do so? > >The designers want it to be clear what their intent was. I, for one, >object to any proposal to eliminate information on that intent from >the documents. > >Perry Perry, Would you give Ran a chance to respond to Dan's mail and be a little courteous. Maybe we can reach a compromise and move forward. Your input is beginning to make me think your being emotional and not logical as an engineer. /jim From ipsec-request@ans.net Fri Mar 10 18:12:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27918 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 13:21:22 -0500 Received: by interlock.ans.net id AA49973 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 13:12:23 -0500 Message-Id: <199503101812.AA49973@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 13:12:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 13:12:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 13:12:23 -0500 From: hsw@columbia.sparta.com (Howard Weiss) Subject: Only 1 IPSEC Session at Danvers? To: ipsec@ans.net Date: Fri, 10 Mar 1995 13:12:09 -0500 (EST) Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 172 I just checked the Danvers tentative agenda as posted via the IETF web page - I could only find in instance of an IPSEC meeting (on Thurs AM). Is 2.5 hours enough? Howie From ipsec-request@ans.net Fri Mar 10 22:04:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27966 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 17:14:06 -0500 Received: by interlock.ans.net id AA10887 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 17:04:40 -0500 Message-Id: <199503102204.AA10887@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 10 Mar 1995 17:04:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 17:04:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 17:04:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 17:04:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 17:04:40 -0500 X-Mailer: exmh version 1.5.3 12/28/94 To: bound@zk3.dec.com, ipsec@ans.net Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Fri, 10 Mar 1995 12:23:44 EST." <199503101745.AA47805@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Mar 1995 17:04:33 -0500 From: " " Jim says: > I see no consensus that you keep saying with phrases like "I suspect > that others feel the same way". I do see one hand clapping. Agreed. Not even a `rough' one... :-) > > Nothing you can say will convince me of not wanting the option of > in-band keying in the spec. Because I believe it should be a technology > option I as an engineer may build in my products, for the explicit reasons > Dan has described consistently. Also agreed. Let me clarify: I agree with most of Perry's reservations about SKIP and in-line keying. But, I don't agree with his conclusion. SKIP and in-line keying give some unique advantages to certain valid scenarios. Therefore, it would be good to include them as options of our key management and encapsulation standards. Of course they should not be the only mode or even the default, furthermore I'll agree to eliminate them if we had a good reason (i.e. a big cost in efficiency, security, or complexity). This is what we plan to do in the next release of our proposal (see Hugo's recent note). We need to move ahead; we have to ship a product in a few months and we have many customers waiting (not very patiently, though). Come on, let's get agreement and interoperable implementations! Let's try to work TOGETHER and drive toward consensus. Best, Amir Herzberg From ipsec-request@ans.net Fri Mar 10 22:43:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28029 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 17:52:22 -0500 Received: by interlock.ans.net id AA42809 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 17:48:31 -0500 Message-Id: <199503102248.AA42809@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 17:48:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 17:48:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 17:48:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 17:48:31 -0500 To: " " Cc: bound@zk3.dec.com, ipsec@ans.net Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Fri, 10 Mar 1995 17:04:33 EST." <199503102204.AA10887@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 10 Mar 1995 17:43:30 -0500 From: "Perry E. Metzger" Amir says: > > Jim says: > > I see no consensus that you keep saying with phrases like "I suspect > > that others feel the same way". I do see one hand clapping. > > Agreed. Not even a `rough' one... :-) Sigh. Please go back and re-read. Jim was quoting me writing about building the best system we can and letting the lawyers fight with governments. It had nothing to do with SKIP. How Jim turned the message into a SKIP message is beyond me. I wasn't discussing SKIP. Perry From ipsec-request@ans.net Fri Mar 10 23:45:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21950 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 18:57:35 -0500 Received: by interlock.ans.net id AA18751 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 18:54:33 -0500 Message-Id: <199503102354.AA18751@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 18:54:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 18:54:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 18:54:33 -0500 To: perry@imsi.com Cc: " " , bound@zk3.dec.com, ipsec@ans.net Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Fri, 10 Mar 95 17:43:30 EST." <9503102243.AA27547@snark.imsi.com> Date: Fri, 10 Mar 95 18:45:57 -0500 From: bound@zk3.dec.com X-Mts: smtp Perry, >Amir says: >> >> Jim says: >> > I see no consensus that you keep saying with phrases like "I suspect >> > that others feel the same way". I do see one hand clapping. >> >> Agreed. Not even a `rough' one... :-) >Sigh. >Please go back and re-read. Jim was quoting me writing about building >the best system we can and letting the lawyers fight with >governments. It had nothing to do with SKIP. How Jim turned the >message into a SKIP message is beyond me. I wasn't discussing SKIP. No Amir and I are in synch. I was stating that YOU do not have consensus regarding in-band keying not being an option for IPv6 security in this or any working group. You need to re-read the mail. I have never mentioned SKIP in any of my mail. I simply believe in-band keying is a valid option. SKIP clearly will be something we will look at too as I don't trust your input at this time and we will make our own technical determination. I do trust Dan though. So my issue is only in-band keying be an option. I agree with Amir we need to get to consensus. We do not have it yet. On in-band keying. /jim From ipsec-request@ans.net Fri Mar 10 22:53:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28121 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 19:01:41 -0500 Received: by interlock.ans.net id AA09861 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 18:58:45 -0500 Message-Id: <199503102358.AA09861@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 10 Mar 1995 18:58:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 18:58:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 18:58:45 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 18:58:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 18:58:45 -0500 Date: 10 Mar 95 16:53:00 -0600 To: hsw@columbia.sparta.com, ipsec@ans.net Subject: Re: Only 1 IPSEC Session at Danvers? Howie, The one session may not be enough if we have more volunteers for well focused presentations on key management (hint, hint :-) Anyone that would like to have time on the IPSEC agenda should give me a call. as always As always, presentations that help us towards our objectives on the IPSEC work items are solicited. An additional IPSEC session will be added (given availability) if necessary. Regards, Paul A. Lambert Motorola, Inc. M/S AZ49-R1209 Internet: Paul_Lambert@email.mot.com 8220 E. Roosevelt Rd. Phone: +1-602-441-3646 Scottsdale, Az. Fax: +1-602-441-8864 85257 USA ------ Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 172 I just checked the Danvers tentative agenda as posted via the IETF web page - I could only find in instance of an IPSEC meeting (on Thurs AM). Is 2.5 hours enough? Howie From ipsec-request@ans.net Sat Mar 11 01:55:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20224 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 22:21:13 -0500 Received: by interlock.ans.net id AA30078 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 22:15:27 -0500 Message-Id: <199503110315.AA30078@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 22:15:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 22:15:27 -0500 Date: Sat, 11 Mar 95 01:55:53 GMT From: "William Allen Simpson" To: ipsec@ans.net Cc: ipng@sunroof.eng.sun.com Subject: The best > From: bound@zk3.dec.com > >I say that we simply behave like engineers and design the best system > >we can, and leave it to the governments to cripple their own countries > >by making it impossible for their citizenry to join the internet, or > >by leaving their citizens open to massive fraud and invasion of > >privacy. I will not lend my support to a consensus for anything less > >than the best system I know how to design, and I suspect that others > >feel the same way. > > I see no consensus that you keep saying with phrases like "I suspect > that others feel the same way". I do see one hand clapping. > OK, Jim, here's agreement with Perry. I feel the same way. I didn't realise that any more than one person needed to say it. Oh, and I saw a message from Ted Ts'o saying the same. Multiple hands clapping. > I with Dan and others will object at last call to that wording in the > document if it is to go to proposed standards before Danvers MA. Done!, > and as far as I am concerned there is no consensus to support your views > technically on any of the security subjects discussed in this rather > extensive mail exchange. You have a view and others have a different > view. Your not winning the debate your just sending a lot of mail. > Perry is more attentive to replying to email than I am, particularly when I'm writing code, so he has a tendency to be the frontrunner. But you can rest assured, Mr Bound, that textual diarrhea is not one of Perry's problems. It is certain "opponents" that have spammed multiple lists, not Perry. The IPv6 Security formats have been completed for some time. They do not include key management. He and I and other have asked that IPv4 technical discourse, such as key management, continue on the IPSec list. Seems to me to be the pot calling the kettle black. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sat Mar 11 03:26:11 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16139 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 22:28:16 -0500 Received: by interlock.ans.net id AA06875 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 22:23:39 -0500 Message-Id: <199503110323.AA06875@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 22:23:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 22:23:39 -0500 Date: Fri, 10 Mar 1995 19:26:11 -0800 From: Phil Karn To: hugo@watson.ibm.com Cc: IPSEC@ans.net In-Reply-To: <199502221726.JAA03646@qualcomm.com> (hugo@watson.ibm.com) Subject: Re: comments on Photuris Hugo, >> Suppose I add a rule to Photuris that says you should use an existing >> SAID whenever possible to encrypt the exchanges that create a new >> SAID. Would this give you some of the same sort of protection against >> partial compromises that you get with explicit key refreshment? >If I understand correctly, what you mean is basically having two >(simultaneous) ways to authenticate a key exchange. One is using Actually, I wasn't thinking about authentication so much as I was looking for a cheap way to harden the protocol against passive eavesdropping. This is still by far the easiest attack to mount on a large scale -- just ask NSA. Yes, an active attacker can still come along and pretend to be a correspondent who has lost state, but this is not only a lot harder to do, it greatly increases the chance of being detected. Phil From ipsec-request@ans.net Sat Mar 11 04:02:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18636 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 23:04:14 -0500 Received: by interlock.ans.net id AA41015 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 22:58:25 -0500 Message-Id: <199503110358.AA41015@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 10 Mar 1995 22:58:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 22:58:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 22:58:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 22:58:25 -0500 From: "Marcus J. Ranum" Subject: Re: The besty To: Bill.Simpson@um.cc.umich.edu (William Allen Simpson) Date: Fri, 10 Mar 1995 23:02:30 -0500 (EST) Cc: ipsec@ans.net, ipng@sunroof.eng.sun.com In-Reply-To: <199503110315.AA30078@interlock.ans.net> from "William Allen Simpson" at Mar 11, 95 01:55:53 am Organization: Trusted Information Systems, Inc. Glenwood, MD Phone: 301-854-6889 Coredump: Infocalypse Now!!! Content-Type: text Content-Length: 1098 >> I see no consensus that you keep saying with phrases like "I suspect >> that others feel the same way". I do see one hand clapping. >> >OK, Jim, here's agreement with Perry. I feel the same way. I didn't >realise that any more than one person needed to say it. Ditto. I suppose I'll stand and be counted, too. BTW - unless I'm mistaken, Perry's main topic-of-rant was the notion of using exportable crypto instead of something like DES. Crypto policy being what it is, *ANY* encryption support for IP that is worth having will not be exportable. We need to accept that, and publish a relevant standard so that independent non-US iplementations can be developed without having to export code. mjr. [PS - Jim, if you're truly approaching this from the perspective of a vendor, why wait for the ossified standards process to complete its interminable gyrations? The only way to make things work is to ignore the standards community until it catches up, and make sure your products can be easily cut over to standards track IF and WHEN a relevant standard arises. Sign me "standards cynic"] From ipsec-request@ans.net Sat Mar 11 04:47:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26947 (5.65c/IDA-1.4.4 for ); Fri, 10 Mar 1995 23:56:06 -0500 Received: by interlock.ans.net id AA03892 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 10 Mar 1995 23:52:52 -0500 Message-Id: <199503110452.AA03892@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 10 Mar 1995 23:52:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 10 Mar 1995 23:52:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 10 Mar 1995 23:52:52 -0500 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) The best In-Reply-To: Your message of "Sat, 11 Mar 95 01:55:53 GMT." <4236.Bill.Simpson@um.cc.umich.edu> Date: Fri, 10 Mar 95 23:47:32 -0500 From: bound@zk3.dec.com X-Mts: smtp >> From: bound@zk3.dec.com >> >I say that we simply behave like engineers and design the best system >> >we can, and leave it to the governments to cripple their own countries >> >by making it impossible for their citizenry to join the internet, or >> >by leaving their citizens open to massive fraud and invasion of >> >privacy. I will not lend my support to a consensus for anything less >> >than the best system I know how to design, and I suspect that others >> >feel the same way. >> >> I see no consensus that you keep saying with phrases like "I suspect >> that others feel the same way". I do see one hand clapping. > >OK, Jim, here's agreement with Perry. I feel the same way. I didn't >realise that any more than one person needed to say it. I think consensus has to be more than 3 people in a working group. >> I with Dan and others will object at last call to that wording in the >> document if it is to go to proposed standards before Danvers MA. Done!, >> and as far as I am concerned there is no consensus to support your views >> technically on any of the security subjects discussed in this rather >> extensive mail exchange. You have a view and others have a different >> view. Your not winning the debate your just sending a lot of mail. > >Perry is more attentive to replying to email than I am, particularly >when I'm writing code, so he has a tendency to be the frontrunner. >But you can rest assured, Mr Bound, that textual diarrhea is not one of >Perry's problems. It is certain "opponents" that have spammed multiple >lists, not Perry. Oh I don't agree and I have the mail archives from this discourse. >The IPv6 Security formats have been completed for some time. They do >not include key management. No and no one "at this point" is arguing they should per the discussion on the mail list. The debate now is the wording around in-band key management. >He and I and other have asked that IPv4 technical discourse, such as key >management, continue on the IPSec list. I think we that are concerned are now on IPsec and I am just responding. to the To: and cc: lines. >Seems to me to be the pot calling the kettle black. Not really on this one Bill. Face it, the wording as is about key management is enough to raise a very big issue to the IESG and I intend to do so if it comes across my mail inbox for last call. The only reason I am responding now is because you and Perry have been responding to me. I will be glad to get out of the loop because my mind is made up, unless I see a change in wording. It will be for the IESG to decide and not the working group I guess. /jim From ipsec-request@ans.net Sat Mar 11 05:21:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22373 (5.65c/IDA-1.4.4 for ); Sat, 11 Mar 1995 00:29:21 -0500 Received: by interlock.ans.net id AA11126 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 11 Mar 1995 00:26:35 -0500 Message-Id: <199503110526.AA11126@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 11 Mar 1995 00:26:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 11 Mar 1995 00:26:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 11 Mar 1995 00:26:35 -0500 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) Re: The besty In-Reply-To: Your message of "Fri, 10 Mar 95 23:02:30 EST." <16660.9503110402@illuminati> Date: Sat, 11 Mar 95 00:21:31 -0500 From: bound@zk3.dec.com X-Mts: smtp >>> I see no consensus that you keep saying with phrases like "I suspect >>> that others feel the same way". I do see one hand clapping. >>> >>OK, Jim, here's agreement with Perry. I feel the same way. I didn't >>realise that any more than one person needed to say it. > Ditto. I suppose I'll stand and be counted, too. > BTW - unless I'm mistaken, Perry's main topic-of-rant was >the notion of using exportable crypto instead of something like >DES. Crypto policy being what it is, *ANY* encryption support for >IP that is worth having will not be exportable. We need to accept >that, and publish a relevant standard so that independent non-US >iplementations can be developed without having to export code. I think your mistaken. The issue of exportable crypto has reached closure, your screwed everywhere and it all has restrictions. This is done, finished, and freakin figured out a day ago. I think we do have consensus on this that we are all screwed. The open issue, and unfortuneately we have some strong personalities who cannot agree (me included), is that the IPv6 security spec should remove the words that are negative towards in-band key management. This is the top issue at this point where we are bumping heads. >mjr. >[PS - Jim, if you're truly approaching this from the perspective >of a vendor, why wait for the ossified standards process to complete >its interminable gyrations? The only way to make things work is >to ignore the standards community until it catches up, and make >sure your products can be easily cut over to standards track IF >and WHEN a relevant standard arises. Sign me "standards cynic"] I am here as an individual paid for by my company who is a vendor. Who only asks me that while I am here to make sure I and others can acutually implement the standards. I never speak for my company and I don't think others do either. In fact Ran's draft at the bottom has a complete disclosure that NRL is not responsible for that draft. Lots of us do this and I put a lot of my own personal time into the IETF too, trust me as even the ones I am disagreeing with presently do to. I think its a sick kind of challenge maybe. But assuming I agreed with your comment. I would want to have my customers read Ran's draft and not see that in-band security is bad or to use Dan Nessetts paradigm of wearing Scuba Gear to the grocery store is something all my customers should do. I would like to maybe build a product that does not have perfect forwarding security, which is only necessary for the most in-secure environments and people. The other issue thats at hand is the IETF in their infinite wisdom has decided to make implementing security in a vendors host kernel MANDATORY even if customers (read the market) don't want to use it. Sounds like regulation to me. I am for less standards (no regulation) and more options that use the word MAY unless its an absolute core interoperability requirement like the network layer protocol or how one discovers other nodes on a network. I do not consider security to be in this category at all. So your preaching to the choir except vendors are required to implement standards or they cannot compete in the Open Systems Market. I would like to see a security standard (if we really must have one) that lets the market decide how to implement the key management for security. Now I do listen and can be influenced. For example I was going to object to Ran's draft because he did not mention key management in depth. Now I will accept this as proposed if he will leave ALL key management OPEN as an option. So if I wanted to be a capitalist die hard I could actually do what you have suggested and build and then push SKIP or Photarius or _STAY_OUT_OF_MY_COMPUTER_OR_I_WILL_PULL_YOUR_EYES_OUT type security. I think this all stems from a need to be safe which IMHO is impossible and a dumb way to exist. But I understand it as its natural for most. So lets build a core thought police interface for the Internet. But let the market hire the enforcers not the IETF network layer security standard, we can search the market and then standardize later on what enforcers for key management we need. Or as you suggest let the market put enforcers on top of the IPv6 security spec and if everyone uses it like NFS, DECnet, SNA, or UNIX then it will just become defacto. No Scuba Gear everywhere please. I don't like the color choices for the gear anyway because sharks think your a seal and eat you. /jim From ipsec-request@ans.net Sat Mar 11 05:31:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20853 (5.65c/IDA-1.4.4 for ); Sat, 11 Mar 1995 00:31:17 -0500 Received: by interlock.ans.net id AA21131 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 11 Mar 1995 00:28:46 -0500 Message-Id: <199503110528.AA21131@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 11 Mar 1995 00:28:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 11 Mar 1995 00:28:46 -0500 Date: Fri, 10 Mar 1995 21:31:16 -0800 From: Phil Karn To: rgm3@is.chrysler.com Cc: bsimpson@morningstar.com, ipsec@ans.net In-Reply-To: <9503011210.AA28403@clncrdv1.is.chrysler.com> (rgm3@is.chrysler.com) Subject: Re: WG last call for IPv4 DES and 3DES >Can 3DES be done in software on a 386 notebook and keep up with a 28.8 comm >line? I assume that modem compression will now be usless as the IP datagram I have single-DES running at 4.4 megabits/sec on a 66 MHz 486. (Hand-tuned assembler, protected mode, lots of 32-bit operations). I haven't done 3DES yet, but it should be somewhat better than the 1/3 speed you'd expect since you can eliminate the inner IP and IP-1 operations that take up a noticeable fraction of a single DES operation. So even after you allow for triple encryption and the slower CPU, yes, your 386 notebook *should* handle 28.8 just fine. Phil From ipsec-request@ans.net Fri Mar 10 20:24:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23008 (5.65c/IDA-1.4.4 for ); Sat, 11 Mar 1995 01:35:54 -0500 Received: by interlock.ans.net id AA18067 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 11 Mar 1995 01:24:50 -0500 Message-Id: <199503110624.AA18067@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sat, 11 Mar 1995 01:24:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 11 Mar 1995 01:24:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 11 Mar 1995 01:24:50 -0500 Date: Sat, 11 Mar 1995 01:24:44 +0500 From: Theodore Ts'o To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net In-Reply-To: bound@zk3.dec.com's message of Sat, 11 Mar 95 00:21:31 -0500, <199503110526.AA11126@interlock.ans.net> Subject: A plea for peace.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 610 Jim, You're flaming. Not that you're the only one who's been doing it lately, on both of these lists. But, could we, please, have just a tad bit more civility on these lists, and focus on the task at hand, without slipping into invective? There have been people on both sides of nearly all of the past couple of discussions (you and Perry and Bill, and others) who have been guilty of this. Even a little bit of effort would make this working group list much more pleasant to read, and make it much more plesant to particpate in this working group. Thanks.... (a very frustrated) - Ted From ipsec-request@ans.net Sat Mar 11 17:11:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22722 (5.65c/IDA-1.4.4 for ); Sat, 11 Mar 1995 18:29:00 -0500 Received: by interlock.ans.net id AA36514 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 11 Mar 1995 18:26:43 -0500 Message-Id: <199503112326.AA36514@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 11 Mar 1995 18:26:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 11 Mar 1995 18:26:43 -0500 Date: Sat, 11 Mar 95 17:11:16 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: End of WG Last Call for AH+MD5 and ESP+DES+3DES Three weeks ago, I issued a "WG Last Call" on AH and ESP. Two weeks ago, I issued a "WG Last Call" on MD5 and DES/3DES. The time has elapsed, and many valuable comments were received. The drafts themselves were combined, and a number of wording issues were resolved. Since the WG Chair has disappeared for the duration of the Last Call, and thus far refused to acknowledge these as WG effort, it is my intent to make a final update of these today, and send them to the RFC-Editor on Monday as Experimental. I will also send SHA as Informational, since there are no implementations, and the immediate value of SHA is less evident. Thank you for your kind assistance. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Sun Mar 12 13:50:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28048 (5.65c/IDA-1.4.4 for ); Sun, 12 Mar 1995 09:00:52 -0500 Received: by interlock.ans.net id AA02220 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 12 Mar 1995 08:53:51 -0500 Message-Id: <199503121353.AA02220@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Sun, 12 Mar 1995 08:53:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 12 Mar 1995 08:53:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 12 Mar 1995 08:53:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 12 Mar 1995 08:53:51 -0500 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) Re: The besty In-Reply-To: Your message of "Sat, 11 Mar 1995 00:21:31 EST." <9503110521.AA29009@xirtlu.zk3.dec.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Sun, 12 Mar 1995 08:50:23 -0500 From: "Perry E. Metzger" bound@zk3.dec.com says: > > BTW - unless I'm mistaken, Perry's main topic-of-rant was > >the notion of using exportable crypto instead of something like > >DES. Crypto policy being what it is, *ANY* encryption support for > >IP that is worth having will not be exportable. We need to accept > >that, and publish a relevant standard so that independent non-US > >iplementations can be developed without having to export code. > > I think your mistaken. No, I think, Jim, that YOU are mistaken. Marcus knew precisely what I had said. I was talking about your request that we find a crypto system other than DES that is acceptable to "all governments". You took my reply to that message and proceeded to rant about SKIP and in-band keying. Perhaps *you* wanted to talk about that, but your desire to discuss a topic has little impact on what topic I was writing about. This is the third and last time I'll tell you this. Perry From ipsec-request@ans.net Sun Mar 12 21:20:17 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21050 (5.65c/IDA-1.4.4 for ); Sun, 12 Mar 1995 16:23:43 -0500 Received: by interlock.ans.net id AA33063 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 12 Mar 1995 16:20:42 -0500 Message-Id: <199503122120.AA33063@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Sun, 12 Mar 1995 16:20:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Sun, 12 Mar 1995 16:20:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 12 Mar 1995 16:20:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 12 Mar 1995 16:20:42 -0500 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: Sun, 12 Mar 1995 16:20:17 -0500 To: ipng@sunroof.eng.sun.com, perry@imsi.com From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: (IPng) Re: out-of-band key management is like virtual circuits Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net At 02:58 PM 2/26/95 -0800, ipng@sunroof.Eng.Sun.COM wrote: >We have several firewalls in-house as well. However, these firewalls >with application-layer relays have never been used to establish >entire virtual enterprises over a public net like the Internet. They >typically give you a handful of Internet services, and connectivity >through them is not as seamless as on a private net. I don't believe >that to date, very large scale virtual enterprises have been built >using the kind of firewall you are referring to (though I am open >to correction). I may have heard wrong but a company bigger than us, a little up the road has used ANS's SiteLock to do just that... But then maybe SiteLock is a different kind of system than what Perry is talking about? Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Mon Mar 13 04:21:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20132 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 09:26:35 -0500 Received: by interlock.ans.net id AA35650 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 09:21:59 -0500 Message-Id: <199503131421.AA35650@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Mar 1995 09:21:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 09:21:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 09:21:59 -0500 Date: Mon, 13 Mar 95 09:21:12 EST X-Sender: shirey@smiley.mitre.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: shirey@mitre.org (Robert W. Shirey) Subject: Principle Statement on Patents and Exports Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net FYI. Adapted from draft-irtf-psrg-secarch-sect1-00.txt 3.5 Use of the Best Available Technology Internet standards should always employ the best available technology to provide high-quality security. National restrictions and patents sometimes make it hard to follow this principle, but a technology should not be avoided in an attempt to satisfy some countries in which the technology is restricted or patent rights are asserted. The rules differ too much among countries, and the rules keep changing. Any attempt to make Internet standards satisfy the rules of any particular set of governments would unnecessarily and unfairly restrict development and use of Internet technology in other countries. For example, the use of cryptography in Internet standards should not be limited just because of national restrictions on export, import, or use of cryptography. Existing restrictions differ greatly between countries [Chan94a, Chan94b, Hoff93, Info94]. Some countries control domestic use of cryptography, and some do not. Some regulate communication of enciphered data across their borders. Some control export of encryption equipment, and some control import. For example, the U.S. places few restrictions on domestic use. But the U.S. restricts export of cryptography designed only to provide integrity and authentication services, and stringently restricts export of cryptography that can be used for confidentiality service. In the short term, Internet standards can minimize the effect of existing restrictions by using cryptography in a focused way. For example, if authentication and integrity service suffice to meet security needs in some protocol, then confidentiality service should not be included gratuitously. In the long term, the effect of international trade controls should fade. There is no inherent reason why protocol implementations must originate in a single country and be exported to other countries. Protocols and cryptography are being independently implemented today in many countries. Also, the strong trend to electronic commerce throughout the world may cause international standardization and subsequent relaxation of technology restrictions. Similarly, many cryptographic algorithms, especially asymmetric algorithms, are patented, but Internet protocols should not avoid using a technology only because patent rights have been asserted in some countries. The situation with cryptographic patents is similar to that with trade controls. That is, not all algorithms are patented in all countries; parallel, independent implementations in different countries are both possible and customary in the Internet; and patents eventually expire. Thus, use of patented technology in Internet standards should not be precluded so long as the licensing conditions are reasonable and non-discriminatory, as specified in [RFC1602]. Still, Internet protocols should avoid using patented technology whenever there is an appropriate substitute technology that is unrestricted. Internet standards should also avoid encryption algorithms and other technologies that are commercially proprietary, governmentally sensitive, militarily restricted (i.e., "classified"), or otherwise prevented from being publicly disclosed. Such conditions preclude open peer review that is fundamental to Internet standards development and high-quality security. --------- [Chan94a] J. P. Chandler, D. C. Arrington, D. R. Berkelhammer, W. L. Gill, Identification and Analysis of Foreign Laws and Regulations Pertaining to the Use of Commercial Encryption Products for Voice and Data Communications, National Intellectual Property Law Institute and The George Washington University, Washington, D.C., for U.S. National Institute of Standards and Technology, January 1994. [Chan94b] -----, Review and Analysis of U.S. Laws, Regulations, and Case Laws Pertaining to the Use of Commercial Encryption Products for Voice and Data Communications, -----, January 1994. [Hoff93] L. J. Hoffman, Faraz A. Ali, Steven L. Heckler, Ann Huybrechts, Cryptography: Policy and Technology Trends, The George Washington University, Washington, DC, for U.S. National Institute of Standards and Technology, 5 December 1993. [Hoff93] L. J. Hoffman, Faraz A. Ali, Steven L. Heckler, Ann Huybrechts, Cryptography: Policy and Technology Trends, The George Washington University, Washington, DC, for U.S. National Institute of Standards and Technology, 5 December 1993. [Info94] "Encryption's International Labyrinth", Infosecurity News, January/February 1994, pp. 26-30. Regards, -Rob- Robert W. Shirey SHIREY@MITRE.ORG tel 703.883.7210, sec 703.883.5749, fax 703.883.1397 Info. Security Div., The MITRE Corp., Mail Stop Z231 7525 Colshire Drive, McLean, Virginia 22102-3481 USA From ipsec-request@ans.net Mon Mar 13 16:02:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19961 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 11:14:47 -0500 Received: by interlock.ans.net id AA16846 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 11:07:24 -0500 Message-Id: <199503131607.AA16846@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Mar 1995 11:07:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 11:07:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 11:07:24 -0500 To: Theodore Ts'o Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: A plea for peace.... In-Reply-To: Your message of "Sat, 11 Mar 95 01:24:44 +0500." <199503110624.AA18067@interlock.ans.net> Date: Mon, 13 Mar 95 11:02:19 -0500 From: bound@zk3.dec.com X-Mts: smtp Ted, Please send me what you call a flame. I can't see it. /jim From ipsec-request@ans.net Mon Mar 13 06:10:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22823 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 11:18:15 -0500 Received: by interlock.ans.net id AA53163 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 11:13:22 -0500 Message-Id: <199503131613.AA53163@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 11:13:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 11:13:22 -0500 Date: Mon, 13 Mar 95 11:10:38 EST From: hugo@watson.ibm.com To: Bill.Simpson@um.cc.umich.edu, ipsec@ans.net Subject: End of WG Last Call for AH+MD5 and ESP+DES+3DES Ref: Your note of Sat, 11 Mar 95 17:11:16 GMT Bill, what do you intend to have as the definition of keyed-MD5 in the draft? (there were a few contradictory messages on this issue and a clarification is needed) Thanks, Hugo From ipsec-request@ans.net Mon Mar 13 16:12:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22858 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 11:20:10 -0500 Received: by interlock.ans.net id AA47348 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 11:15:49 -0500 Message-Id: <199503131615.AA47348@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Mar 1995 11:15:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 11:15:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 11:15:49 -0500 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) Re: The besty In-Reply-To: Your message of "Sun, 12 Mar 95 08:50:23 EST." <9503121350.AA29308@snark.imsi.com> Date: Mon, 13 Mar 95 11:12:03 -0500 From: bound@zk3.dec.com X-Mts: smtp Perry, ************************ bound@zk3.dec.com says: > > BTW - unless I'm mistaken, Perry's main topic-of-rant was > >the notion of using exportable crypto instead of something like > >DES. Crypto policy being what it is, *ANY* encryption support for > >IP that is worth having will not be exportable. We need to accept > >that, and publish a relevant standard so that independent non-US > >iplementations can be developed without having to export code. > > I think your mistaken. No, I think, Jim, that YOU are mistaken. Marcus knew precisely what I had said. I was talking about your request that we find a crypto system other than DES that is acceptable to "all governments". You took my reply to that message and proceeded to rant about SKIP and in-band keying. Perhaps *you* wanted to talk about that, but your desire to discuss a topic has little impact on what topic I was writing about. This is the third and last time I'll tell you this. ********************** I am not ranting about encryption. I sent a note asking if there was a means to provide an encryption algorithm that was publicly available and had no restrictions anywhere. The answer was NO. My other mail is regarding in-band keying and the removal of the words presently in the IPv6 sec draft. Send me the mail where I mention SKIP. The only time I mentioned it was that I want the option to prototype SKIP or other proposals for host keying. Whats happening here is the debate is getting very focused and getting closer to the ONLY issue left. Removal of the present words in IPv6 sec about in-band keying. No more and no Less. /jim From ipsec-request@ans.net Mon Mar 13 16:59:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19936 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 12:04:21 -0500 Received: by interlock.ans.net id AA05198 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 12:00:00 -0500 Message-Id: <199503131700.AA05198@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 13 Mar 1995 12:00:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Mar 1995 12:00:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 12:00:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 12:00:00 -0500 To: hugo@watson.ibm.com Cc: ipsec@ans.net Subject: Re: End of WG Last Call for AH+MD5 and ESP+DES+3DES In-Reply-To: Your message of "Mon, 13 Mar 1995 11:10:38 EST." <199503131613.AA53163@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 13 Mar 1995 11:59:46 -0500 From: "Perry E. Metzger" hugo@watson.ibm.com says: > Ref: Your note of Sat, 11 Mar 95 17:11:16 GMT > > Bill, what do you intend to have as the definition of keyed-MD5 > in the draft? > (there were a few contradictory messages on this issue and a > clarification is needed) I believe that Bill has produced new draft which will be out momentarily that reflects the suggestion by Kaliski that the transform be MD5(MD5(text) + key) This should satisfy your earlier objections concerning the transform, I believe. Please advise us as to whether this does, in fact, satisfy your objections on the transform. Perry From ipsec-request@ans.net Mon Mar 13 17:48:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22363 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 12:53:11 -0500 Received: by interlock.ans.net id AA19032 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 12:48:46 -0500 Message-Id: <199503131748.AA19032@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Mar 1995 12:48:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 12:48:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 12:48:46 -0500 Date: Mon, 13 Mar 1995 10:48:39 -0700 From: Hilarie Orman To: perry@imsi.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199503131700.AA05198@interlock.ans.net> Subject: Re: End of WG Last Call for AH+MD5 and ESP+DES+3DES I think that MD5(key, text, key) may be more secure than the double hash. My understanding is that Kaliski's suggestion was based on the idea that MD5(text) might be a useful subfunction. However, I'm uneasy at the idea of a possible cryptanalysis of MD5(foo,key); not a question I've seen examined before. From ipsec-request@ans.net Mon Mar 13 18:58:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27120 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 14:08:17 -0500 Received: by interlock.ans.net id AA22026 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 13:58:43 -0500 Message-Id: <199503131858.AA22026@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 13 Mar 1995 13:58:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Mar 1995 13:58:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 13:58:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 13:58:43 -0500 To: Hilarie Orman Cc: jis@mit.edu, ipsec@ans.net Subject: Re: End of WG Last Call for AH+MD5 and ESP+DES+3DES In-Reply-To: Your message of "Mon, 13 Mar 1995 10:48:39 MST." <9503131748.AA21569@uncial.CS.Arizona.EDU> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Mon, 13 Mar 1995 13:58:28 -0500 From: "Perry E. Metzger" Hilarie Orman says: > I think that MD5(key, text, key) may be more secure than the double hash. > My understanding is that Kaliski's suggestion was based on the idea > that MD5(text) might be a useful subfunction. However, I'm uneasy at > the idea of a possible cryptanalysis of MD5(foo,key); not a question I've > seen examined before. All I know is that this was the suggestion being recommended by the PSRG. I've heard that Kaliski thinks this is actually better than MD5(key, text, key). Of course, at this point, I'm sufficiently flexible (i.e. my resistance has been crushed) that I'll take whatever the security area directorate, in their wisdom, deem to be secure. (Let it never be said that Bill and I haven't listened to what people have asked for.) I've come to this conclusion because we are going to have to move from the base transforms with time anyway -- the DES transform is already inadequate for most real uses. Given this, I'll happily accept what the experts say at the moment knowing that we're going to have to change it every few years no matter what we do. Therefore, I'd suggest that people bring up this issue with Jeff Schiller and the area directorate. At the moment, we are just doing what we are told. Bill Simpson may, of course disagree with me -- no one will ever accuse him of being a follower :-) Perry From ipsec-request@ans.net Mon Mar 13 07:16:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24400 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 14:22:33 -0500 Received: by interlock.ans.net id AA12978 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 14:17:04 -0500 Message-Id: <199503131917.AA12978@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Mar 1995 14:17:04 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 14:17:04 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 14:17:04 -0500 Date: Mon, 13 Mar 1995 12:16:40 +0500 From: Theodore Ts'o To: bound@zk3.dec.com Cc: Theodore Ts'o , ipng@sunroof.eng.sun.com, ipsec@ans.net In-Reply-To: bound@zk3.dec.com's message of Mon, 13 Mar 95 11:02:19 -0500, <199503131607.AA16846@interlock.ans.net> Subject: Re: A plea for peace.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 257 Date: Mon, 13 Mar 95 11:02:19 -0500 From: bound@zk3.dec.com Please send me what you call a flame. I can't see it. The message I was referring to was dated March 11, 1995 at 00:21:31 GMT-5, subject line "Re: (IPng) Re: The besty". - Ted From ipsec-request@ans.net Mon Mar 13 22:50:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17204 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 17:55:55 -0500 Received: by interlock.ans.net id AA10724 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 17:47:36 -0500 Message-Id: <199503132247.AA10724@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 17:47:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 17:47:36 -0500 Date: Mon, 13 Mar 1995 14:50:08 -0800 From: Phil Karn To: hugo@watson.ibm.com Cc: IPSEC@ans.net In-Reply-To: <199503022218.OAA13215@qualcomm.com> (hugo@watson.ibm.com) Subject: Re: A Photuris variant Hugo, I'm slowly catching up on my mail, so I just read your message. And yes, I have a few comments. Photuris uses DH + PK digital signatures only. The digital signature scheme could be either RSA or DSA. If you choose DSA and it withstands a PKP challenge, the whole Photuris scheme could be unencumbered as early as 1997 when the DH patent expires. On the other hand, your scheme requires a full public key encryption algorithm, i.e., RSA...the patent for which doesn't expire until 2000. Of course, all this is moot unless or until IBM is willing to place your scheme in the public domain. Please advise on this point before we spend too much time discussing it. Aside from that, I see a serious technical problem in your share phase. How does each party know the public key of the other party so it can encrypt the half-keys K1 and K2? If you first send your public key in the clear, then you've just identified yourself to a passive eavesdropper. But you'd have to do this since your correspondent can't infer your public key (e.g., from a table) solely on the basis of your IP source address -- it could well have been dynamically assigned by a dialup PPP router or DHCP server. (A major purpose of IPSP is to divorce authentication identities from IP addresses.) Photuris does the DH exchange first specifically to help cover the authentication exchange that follows, to provide anonymity against passive eavesdropping. I consider this to be a pretty important feature. Re DH overhead, we've discussed this at length before and I don't think anything has changed. DH just isn't that expensive, especially if you use an exponent length that's appropriate to your symmetric cipher. Furthermore, you do NOT have to re-execute DH everytime you establish a new session key. My current plan is to generate session keys by MD5 hashing the DH secret, the SAID and the cookies. So after a given host pair has done DH once, they can create as many new uniquely-keyed SAIDs as they need for only one MD5 operation each. (Of course, they'd always have the option of re-executing the DH exchange at any time.) Doesn't this satisfy your desire for a quick way to rekey your weak symmetric ciphers? Phil From ipsec-request@ans.net Tue Mar 14 01:03:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24480 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 20:09:13 -0500 Received: by interlock.ans.net id AA52302 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 20:05:58 -0500 Message-Id: <199503140105.AA52302@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 13 Mar 1995 20:05:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Mar 1995 20:05:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 20:05:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 20:05:58 -0500 Date: Mon, 13 Mar 1995 17:03:10 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: IPSEC@ans.net Subject: Re: A Photuris variant X-Sun-Charset: US-ASCII Hugo, I offer the following initial comments on your note. First, I observe that the freshness property of the protocol is achieved in the "share" phase, where K0 will be fresh when used with public-key encryption based share phase. However, you then suggest that the same protocol can be used with other key sharing models which don't necessarily have a fresh K0 e.g. manual key distribution, SKIP master keys etc. (Assuming I properly understood the "Compatibility with Other Key Sharing Models" section). When used with these other key-sharing models, the protocol loses its freshness property, and therefore there is nothing to prevent playbacks of {g^x, MAC_K0(g^x)}. This is especially bad since the protocol does not require the parties to prove that they can compute g^xy, so the above can be played back even if the attacker never learn's x. The fix to this problem appears to be simple. Include in the MAC_K0 computation the other side's exponential in a direction sensitive manner. Concretely, replace in the second message (using the last compact description of your proposal) MAC_K0(g^y) with MAC_K0(g^y, g^x) and in the last message MAC_K0(g^x) with MAC_K0(g^x, g^y). Throwing in the parties names in the MAC function (direction sensitive) probably wouldn't hurt either. This incurs minimal additional overhead, as all you are doing is computing the MAC over one extra exponential, while allowing K0 to be in fact something long-lived (and not per session). (If you do this, then this part of your proposal starts bearing a lot of similarity to an extension of the basic SKIP proposal I am in the process of drafting). Kind regards, Ashar. From ipsec-request@ans.net Mon Mar 13 11:32:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05044 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 22:56:51 -0500 Received: by interlock.ans.net id AA10993 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 22:52:02 -0500 Message-Id: <199503140352.AA10993@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 22:52:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 22:52:02 -0500 Date: Mon, 13 Mar 95 16:32:57 EST From: hugo@watson.ibm.com To: perry@imsi.com, IPSEC@ans.net Cc: jis@mit.edu, galvin@tis.com, burt@rsa.com Subject: Suggestions on keyed-MD5 Here is my suggestion on how to proceed with the issue of keyed-MD5. (The busy people (like me ;-) can read only the first part and skip the more technical Notes at the end.) As for background: my suggestions below are based on very recent analysis work done by Mihir Bellare, Ran Canetti and myself. (We will make the paper available as soon as it is written, here I am just mentioning some conclusions, and I allow myself some inaccuracies in the arguments to avoid being too technical). If I need to give a fast and easy to understand answer I would say go to MD5(K,text,K) (which, for example, is not subject to attacks via collisions-finding while Burt Kaliski's suggestion is - see Note 1 below) However, our analysis suggests a better construction. The later is related to Burt's suggestion but with some (significant) differences. Burt suggested: MD5(MD5(text),K) We suggest: MD5_K(MD5_K(text)) which is very similar to Burt's EXCEPT: the key K is used (not to apppend or prepend to the text but) as the INITIAL value of the registers ABCD in the computation of MD5 (subsequent iterations of MD5 are untouched). This suggestion has some significant security advantages in reducing the risk due to potential vulnerabilities of MD5 (see Note 2 - please read it if you really want to judge this proposal). It also has a minor performance advantage: no need to append or prepend text (this may, in some cases, save one MD5 application - no big deal). However, it also requires that the code of MD5 is (slightly) changed: instead of initiallizing ABCD to MD5's "magic numbers", you need to read into them the value of the key. This is a really minor change in the code (the iterations are untouched, only the initialization changed) but still a change. IMHO, that's enough to require a separate RFC to define it. CONCLUSION: My suggestion is to have in the current draft MD5(K,text,K) which is the best approximation to the above MD5_K that does not requires code changes to MD5 (it is also backed by many people in this list). In addition, there should be a pointer in the draft to an RFC that defines keyed-MD5 and that implementators should check. Such an RFC is being prepared (to the best of my knowledge) by Jim Galvin and Burt Kaliski. Whether the above MD5_K suggestion is acceptable should be judged by the RFC authors (Burt and Jim) and by the IETF, and reflected in that RFC. (Hopefully, that RFC will be ready by the time the IPSP drafts become a standard). As a final remark, all of the above applies to SHA (and other hash functions that work iteratively), therefore if relevant weaknesses of MD5 are found in the future one can move to another hash function, without modifying the basic scheme. Hugo Note 1: A fast and inacurate justification of MD5(K,text,K) as opposed to MD5(MD5(text),K) is that the later is very close - in its actual security - to MD5(text, K). In particular, both are broken if you find collisions in MD5. (A more ellaborated analysis is possible but "beyond the scope" of this message) That is, MD5(K,text,K) gives you most of the security of MD5(text,K) but also added security like resistance to collisions in MD5. The issue of resistance to collisions is IMPORTANT. It makes the current cryptanalysis work on the MD-family, e.g. collisions on the compression function, insufficient to attack the keyed version. Also (in a more subtle/paranoid point), whoever will build a collision finding machine (a la van OOrschot-Wiener) for MD5 shouldn't be able to use it against keyed-MD5. Notice that breaking MD5 via collisions is much valuable than breaking a message authentication function. The former can be used to change long-term contracts, the later looses any value once the key expires. Last, but not least. MD5(K,text,K) represents a better approximation to the MD5_K construction whose advantages are discussed in Note 2. Note 2: Security advantages of MD5_K(MD5_K(text)) (this is a rough sketch, and follows the mentioned paper in preparation) * Even if collisions in MD5 are found the message authentication is NOT BROKEN (Burt's suggestion is insecure given collisions) * If ONE iteration of MD5 (i.e. its compression function) with random ABCD is pseudorandom then the whole construction IS SECURE for message authentication. Roughly speaking, pseudorandom means that the output of the function "looks random", i.e. behaves as a good pseudorandom generator. This property is implicitly or explicitly assumed in uses of MD5 to generate keys (as SSL, MKMP, Phil Karn and many other have suggested). In the case of SHA, its pseudorandomness properties are suggested by the designers themselves (it is suggested as a pseudorandom generator for DSS). * If MD5 is collisions free and its compression function is a good MAC (i.e., unforgeable even after seeing many input-output pairs) the construction is secure. Burt's suggestion is based on (a variant) of the last assumption, while ours will work in this case but also under the first two cases. Namely, in order to break our construction one needs to break (keyed) MD5 as a pseudorandom function AND as a collision free function, OR the compression function needs to be broken as a MAC (in the later case no hope is left to base message authentication in MD5). From ipsec-request@ans.net Tue Mar 14 03:45:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05065 (5.65c/IDA-1.4.4 for ); Mon, 13 Mar 1995 23:01:29 -0500 Received: by interlock.ans.net id AA23371 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 13 Mar 1995 23:00:11 -0500 Message-Id: <199503140400.AA23371@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 13 Mar 1995 23:00:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 13 Mar 1995 23:00:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 13 Mar 1995 23:00:11 -0500 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) Principle Statement on Patents and Exports In-Reply-To: Your message of "Mon, 13 Mar 95 09:21:12 EST." Date: Mon, 13 Mar 95 22:45:13 -0500 From: bound@zk3.dec.com X-Mts: smtp thank you Robert, /jim From ipsec-request@ans.net Tue Mar 14 09:17:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20988 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 04:20:31 -0500 Received: by interlock.ans.net id AA52460 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 04:17:49 -0500 Message-Id: <199503140917.AA52460@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 04:17:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 04:17:49 -0500 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net Subject: Re: (IPng) Re: The besty In-Reply-To: Your message of "Mon, 13 Mar 1995 11:12:03 EST." <9503131612.AA12105@xirtlu.zk3.dec.com> Date: Tue, 14 Mar 1995 10:17:34 +0100 From: Christian Huitema Jim, We all know that we cannot find a crypto-algorithm that is acceptable by all governments (including France, Irak and Russia) and exportable from all countries (including the US). The IAB, the IESG, sevral working groups and research groups discussed the issue at length. There is however a wide recognition that: * we might allow sites to pick any algorithm on a bilateral basis. IDEA and triple DES come out as very reasonable choices. But in order for negotiations to converge, we need one fall common ball-back. * DES in CBC mode has good properties for selection as a common fall back. The specs are public (courtesy of the US govt), hardware and software are available, even public domain software from Finland. * Yes, export control is a pain. But there are at least two turnarounds. Big companies can develop in a country which does not restrict export, which I understand DEC is doing in Israel. Small companies can peer with local partners which add the crypto-stuff in their own country. * Overall, the gain of a common spec is worth the pain. Now, I wish we could get the silly export control restrictions removed, not to mention the absurd usage restrictions of France. But that seems more a task for the EFF or the ISOC than for the IETF. Christian Huitema From ipsec-request@ans.net Tue Mar 14 09:17:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22014 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 04:20:32 -0500 Received: by interlock.ans.net id AA38594 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 04:13:38 -0500 Message-Id: <199503140913.AA38594@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 04:13:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 04:13:38 -0500 Date: Tue, 14 Mar 1995 01:17:37 -0800 From: Phil Karn To: Danny.Nessett@eng.sun.com Cc: atkinson@itd.nrl.navy.mil, Danny.Nessett@eng.sun.com, ipsec@ans.net In-Reply-To: <199503071542.HAA01056@elrond.Eng.Sun.COM> (Danny.Nessett@Eng.Sun.COM) Subject: Re: WG last call for IPv4 AH and ESP There is another problem here, which is how a router will know if a host supports IPSP or not before it can send it an ICMP message. The whole issue seems too marginal to worry about. Phil From ipsec-request@ans.net Tue Mar 14 10:48:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21820 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 05:48:21 -0500 Received: by interlock.ans.net id AA16856 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 05:44:48 -0500 Message-Id: <199503141044.AA16856@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 05:44:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 05:44:48 -0500 Date: Tue, 14 Mar 1995 02:48:34 -0800 From: Phil Karn To: Danny.Nessett@eng.sun.com Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net In-Reply-To: <199503071827.AA21100@interlock.ans.net> (Danny.Nessett@Eng.Sun.COM) Subject: Re: Proposed message on perfect forward security >On the other hand, many other applications have no strong requirement for >perfect forward security. Examples of these fall generally into that class But this is not an argument against mechanisms that do provide perfect forward secrecy unless you can *prove* that the extra cost is unacceptable. As CPUs get faster, the authors of modexp routines get smarter, and the IPSEC group gets older, I find it increasing hard to justify developing lots of different algorithms. I'd much prefer to do one for the most general case and leave it at that. Phil From ipsec-request@ans.net Tue Mar 14 12:33:51 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22787 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 08:08:25 -0500 Received: by interlock.ans.net id AA24071 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 08:03:43 -0500 Message-Id: <199503141303.AA24071@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 08:03:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 08:03:43 -0500 Date: Tue, 14 Mar 95 12:33:51 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: MD5 hash calculation I thank you for your belated comments, but as the Subject announced "End of WG Last Call", this is a bit late. Please keep in mind that unless and until the WG Chair(s) announce that this is now a Proposed Standard, this is our individual effort. > From: Hilarie Orman > I think that MD5(key, text, key) may be more secure than the double hash. If you think this, then perhaps you could give us a proof? Until I see such a proof, I am not willing to make yet another last minute chnage. > My understanding is that Kaliski's suggestion was based on the idea > that MD5(text) might be a useful subfunction. However, I'm uneasy at > the idea of a possible cryptanalysis of MD5(foo,key); not a question I've > seen examined before. > No, it was based on the idea that MD5( key, text, key ) provides insufficient mixing of the key bits when the text part is long. MD5(key,MD5(text)) provides a dominance of the key bits in the mixing. Cryptanalysis requires unrolling MD5. We did _NOT_ use MD5(MD5(text),key)), because this only requires cryptanalysis of the _last_ block hash of MD5 and the key, which may be an easier problem. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Mar 14 05:33:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22736 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 11:13:44 -0500 Received: by interlock.ans.net id AA51781 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 11:06:42 -0500 Message-Id: <199503141606.AA51781@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 11:06:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 11:06:42 -0500 Date: Tue, 14 Mar 95 10:33:56 EST From: hugo@watson.ibm.com To: Bill.Simpson@um.cc.umich.edu, ipsec@ans.net Cc: BURT@RSA.COM Subject: MD5 hash calculation Ref: Your note of Tue, 14 Mar 95 12:33:51 GMT (attached) Bill, > MD5(key,MD5(text)) provides a dominance of the key bits in the mixing. > Cryptanalysis requires unrolling MD5. You asked for proofs: here is an attack that breaks the authentication without "unrolling" MD5. (And thus cryptanalysis does NOT require unrolling): If you know text and text' for which MD5(text)=MD5(text') then you can replace text by text' without even knowing the key. (See my previous note for more discussion on the importance to protect from such collision attacks). One solution to this problem is MD5(key,text,key). An even better solution (very close to your suggestion - and inspired by it): MD5(key, MD5(key,text)). (collisions in plain MD5 won't help here and, in addition, you keep all the bennefits of your construction). I suggest you go for the later and, as said in my previous note, you give a reference to an (eventual) RFC on keyed-MD5, where we'll (hopefully) converge to the best acceptable solution. Hugo PS: Burt, can you please comment on this From ipsec-request@ans.net Tue Mar 14 17:03:35 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21347 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 12:19:56 -0500 Received: by interlock.ans.net id AA44760 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 12:14:27 -0500 Message-Id: <199503141714.AA44760@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 14 Mar 1995 12:14:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Mar 1995 12:14:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 12:14:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 12:14:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 12:14:27 -0500 Date: Tue, 14 Mar 1995 09:03:35 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: karn@unix.ka9q.ampr.org Subject: Re: Proposed message on perfect forward security Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net X-Sun-Charset: US-ASCII Phil, Responding to my comment : > > >On the other hand, many other applications have no strong requirement for > >perfect forward security. Examples of these fall generally into that class you observe : > But this is not an argument against mechanisms that do provide perfect > forward secrecy unless you can *prove* that the extra cost is > unacceptable. As CPUs get faster, the authors of modexp routines get > smarter, and the IPSEC group gets older, I find it increasing hard to > justify developing lots of different algorithms. I'd much prefer to > do one for the most general case and leave it at that. I gather from your wording that you mean "prove" in the market acceptance sense (i.e., products using key distribution mechanisms providing perfect forward security will be widely used), rather than the mathematical or formal logic sense. If so, then I think we agree. My arguments are not "against mechanisms that do provide perfect forward secrecy," but rather for allowing the marketplace to do its job. It is too early to tell just what the market will desire and so, I believe, it is imprudent to limit IPv6 to a single class of key distribution mechanisms, viz., only those employing out-of-band keying. Regards, Dan From ipsec-request@ans.net Tue Mar 14 17:42:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21137 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 12:57:05 -0500 Received: by interlock.ans.net id AA39367 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 12:50:35 -0500 Message-Id: <199503141750.AA39367@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 12:50:35 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 12:50:35 -0500 Date: Tue, 14 Mar 95 17:42:46 GMT From: "William Allen Simpson" To: ipsec@ans.net Cc: BURT@RSA.COM Subject: Re: MD5 hash calculation > From: hugo@watson.ibm.com > You asked for proofs: here is an attack that breaks the authentication > without "unrolling" MD5. (And thus cryptanalysis does NOT require unrolling): > > If you know text and text' for which > MD5(text)=MD5(text') then you can replace text by text' without even knowing > the key. > (sigh) Try reading the introductory principles of RFC-1321, which says: It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. Quite frankly, I don't see how it is any easier to find MD5(text') than MD5(key,text',key). It is the same thing, the hardness of which is the guiding principle of cryptographic hashing. But you are partly correct. You might discover such a hash by luck. So what? Real cryptanalysis requires unrolling MD5. I suppose now you'll insist that all "proofs" should mention "luck". > a reference to an (eventual) RFC on keyed-MD5, where we'll (hopefully) > converge to the best acceptable solution. > Pretty hard to give references to things that don't yet exist. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Mar 14 18:20:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25852 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 13:25:18 -0500 Received: by interlock.ans.net id AA37743 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 13:20:56 -0500 Message-Id: <199503141820.AA37743@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Mar 1995 13:20:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 13:20:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 13:20:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 13:20:56 -0500 To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 14 Mar 1995 09:03:35 PST." <199503141703.JAA05979@elrond.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Mar 1995 13:20:37 -0500 From: "Perry E. Metzger" Dan Nessett says: > allowing the marketplace to do its job. It is too early to tell just what > the market will desire and so, I believe, it is imprudent to limit IPv6 > to a single class of key distribution mechanisms, viz., only those employing > out-of-band keying. The problem is this, Dan. SKIP can't use the transforms defined for IPSP or the SAID mechanisms defined for IPSP. It can't support multiple keys between hosts, either. In short, you have this "neither fish nor foul" proposal out there that doesn't really have any demonstrable advantages and doesn't fit in with the rest of the architecture. In the guise of saying "we need to be flexible" you keep coming back and saying that you think that we should rip up the architecture to make SKIP more feasable. Well, I'm sorry, but so far as I can tell a SKIP implementation can't even share the transform code that is used for other key management mechanisms. The thing isn't a modular key management system -- its a proposal that really seeks to fundamentally alter the entire way IPSP was architected. .pm From ipsec-request@ans.net Tue Mar 14 18:29:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21025 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 13:31:53 -0500 Received: by interlock.ans.net id AA04324 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 13:29:37 -0500 Message-Id: <199503141829.AA04324@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Mar 1995 13:29:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 13:29:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 13:29:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 13:29:37 -0500 To: "William Allen Simpson" Cc: ipsec@ans.net, BURT@RSA.COM Subject: Re: MD5 hash calculation In-Reply-To: Your message of "Tue, 14 Mar 1995 17:42:46 GMT." <199503141750.AA39367@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Mar 1995 13:29:24 -0500 From: "Perry E. Metzger" "William Allen Simpson" says: > (sigh) Try reading the introductory principles of RFC-1321, which says: > > It is conjectured that it is computationally infeasible to produce > two messages having the same message digest, or to produce any > message having a given prespecified target message digest. > > Quite frankly, I don't see how it is any easier to find MD5(text') than > MD5(key,text',key). It is the same thing, the hardness of which is the > guiding principle of cryptographic hashing. Actually, Bill, Hugo does indeed have a good point here which I don't think was being considered. It should actually be easier to find a collision than to deduce the keys and also find a collision. > But you are partly correct. You might discover such a hash by luck. > So what? Real cryptanalysis requires unrolling MD5. Well, a cryptographic hash has several properties here that are under consideration. Non-invertability and not being able to produce collisions are different properties, although the mechanisms by which they are achieved are similar. In MD5(MD5(text)+key) you need merely find a colliding text. For MD5(key+text+key) you do actually have to determine what the key was -- much harder. Given that our hash functions might be imperfect this might be a second level of protection. Certainly it protects against an Oorschot and Wiener Machine being used against you since that can only find collisions, not reversals of the hash. Perry From ipsec-request@ans.net Tue Mar 14 08:27:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27558 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 13:41:59 -0500 Received: by interlock.ans.net id AA31088 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 13:36:37 -0500 Message-Id: <199503141836.AA31088@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 13:36:37 -0500 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 13:36:37 -0500 To: "William Allen Simpson" Cc: ipsec@ans.net, BURT@RSA.COM Subject: Re: MD5 hash calculation Date: Tue, 14 Mar 95 13:27:26 EST (sigh) Try reading the introductory principles of RFC-1321, which say s: It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. Quite frankly, I don't see how it is any easier to find MD5(text') than MD5(key,text',key). It is the same thing, the hardness of which is the guiding principle of cryptographic hashing. But you are partly correct. You might discover such a hash by luck. So what? Real cryptanalysis requires unrolling MD5. No, it's easier to find MD5(text') than MD5(key,text). The reason is that in the former case, there's full known plaintext; in the latter, there's an unknown component. Furthermore, one can often generate chosen plaintext going to someone's terminal (this mail message, for example). If I have a large sample of legitimate packets authenticated by MD5(key,MD5(text)), then I can attack you if I can generate a nastygram whose hash matches any if the MD5(text_i)'s in my collection. I don't have to know the key. With MD5(key,text), I have to find some evil text that will generate the same authentication value *after* concatenation with a key I don't know. --Steve Bellovin From ipsec-request@ans.net Tue Mar 14 18:46:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27410 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 13:54:53 -0500 Received: by interlock.ans.net id AA22418 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 13:51:09 -0500 Message-Id: <199503141851.AA22418@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 13:51:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 13:51:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 13:51:09 -0500 To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 14 Mar 95 13:20:37 EST." <199503141820.AA37743@interlock.ans.net> Date: Tue, 14 Mar 95 13:46:33 -0500 From: bound@zk3.dec.com X-Mts: smtp Dan, Technical Questions: 1. To reveiw: Will in-band keying work with the present IPv6 specs (Rans work) without changes to the specifications? Not just SKIP (see next question). 2. Are there multiple ways to use in-band keying besides SKIP? I am asking this because I believe in-band keying should be something vendors should be able to build as a key-management solution. I am assuming SKIP is only one way to use in-band keying and others can exist too? 3. Can't we discuss this without mention of SKIP so that we can make sure either in-band or out-band can be used? I think its important we get to the heart of the architectural issues technically of the in/out modes and not get hung up on actual mechanisms? Or is this not a good idea? thanks /jim From ipsec-request@ans.net Tue Mar 14 19:18:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15940 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 14:19:48 -0500 Received: by interlock.ans.net id AA39230 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 14:16:13 -0500 Message-Id: <199503141916.AA39230@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 14:16:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 14:16:13 -0500 Date: Tue, 14 Mar 1995 11:18:24 -0800 From: Phil Karn To: ashar@osmosys.incog.com Cc: ipsec@ans.net Reply-To: karn@qualcomm.com In-Reply-To: <199503071910.AA21346@interlock.ans.net> (ashar@osmosys.incog.com) Subject: Re: Diffie's comments on Photuris Ashar, Thanks for forwarding that note from Whit. In thinking about it and similar comments from you and others, I've tentatively decided to modify Photuris to sign the shared secret. I've been thinking about a related problem for some time: finding a safe way to use my PGP key on my workstation at work. If I were to type my PGP passphrase into a machine I don't fully trust, I'd risk compromising *all* of the traffic I have ever received or will receive with that PGP key, including personal mail read only at home. Using separate keys is one possible approach, but that's clumsy. The ideal answer seems to be a smart-card that I can plug into the workstation that safely holds my RSA secret key and uses it to perform operations on behalf of the host without ever letting the secret key leave the card. For maximum safety, the card could log all operations and possibly even require a manual "go" button press to approve each operation. Even in the smartcard the RSA secret key would exist in plaintext only when it is in active use. At all other times it would be encrypted in a symmetric algorithm; before use the user would have to enter the key for the symmetric algorithm on a keypad on the card. One might even store the encrypted secret key on the host, eliminating the need for stable storage on the card. But this would place total reliance on the secrecy of the key for the symmetric algorithm, which is probably a bad idea given our experiences with badly chosen user passwords. A palmtop plugged into a serial port might make a good prototype smartcard. Well, you've made me realize that Photuris has to solve this same problem. (Especially since I plan to use the existing PGP key database.) How can I limit the damage that can be done by hacked workstation software to the compromise of the actual IPSP traffic I send or receive on that workstation? One approach already discussed is for the trusted signature function to enforce a maximum lifetime on the signatures of DH public halves. Kerberos does this, but it still leaves you vulnerable for a time. Imagine a public workstation at Interop or IETF. Somebody could hack its "kdestroy" command to secretly squirrel away my tickets before seeming to destroy them. I get up and walk away, and the attacker sits down and continues to access my home system. I'd like to prevent this in Photuris. If I sign the DH shared secret, then it should suffice to destroy it along with all associated SAIDs on just one end when I'm done (e.g., on my home system when I'm accessing it from IETF). A locally snarfed {DH public value, DH secret value, signature on shared secret} triple would then be useless if the remote machine initiates a new DH exchange with a new DH public value. Now this would seem to require that the remote system generate a new DH key pair for every SAID. But this isn't really necessary. It would be easy to add a message to Photuris to ask the other side to discard its existing DH key pair ahead of schedule. I could send that message whenever I log off and leave my local workstation to ensure that any locally snarfed keying material would become completely useless. But I could still rapidly generate a series of SAIDs from the same DH shared secret for just the cost of an MD5 hash. Comments? Phil From ipsec-request@ans.net Tue Mar 14 19:42:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18789 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 14:49:34 -0500 Received: by interlock.ans.net id AA41715 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 14:45:32 -0500 Message-Id: <199503141945.AA41715@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Mar 1995 14:45:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 14:45:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 14:45:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 14:45:32 -0500 To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 14 Mar 1995 13:46:33 EST." <199503141851.AA22418@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Mar 1995 14:42:32 -0500 From: "Perry E. Metzger" Jim, bound@zk3.dec.com says: > 3. Can't we discuss this without mention of SKIP so that we can > make sure either in-band or out-band can be used? The problem is that SKIP is the only proposal we've had thats of this form. Given that, its very difficult to discuss this in the general case -- I'm not even sure what the "general case" would look like. My suspicion is that other similar techniques would use very different machinery. SKIP, as it is, cannot reuse any of the standard IPSP machinery -- it needs its own transforms, its own hooks to the key management layer, etc. I'm not sure that other similar techniques could share any of SKIP's machinery, and I'm not sure at all that there is a "general case" here to discuss. Therefore, I prefer to keep discussion concrete and focus on SKIP. Perry From ipsec-request@ans.net Tue Mar 14 19:54:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16076 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 14:58:02 -0500 Received: by interlock.ans.net id AA53185 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 14:54:45 -0500 Message-Id: <199503141954.AA53185@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Mar 1995 14:54:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 14:54:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 14:54:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 14:54:45 -0500 To: ipng@sunroof.eng.sun.com Cc: ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 14 Mar 1995 11:40:52 PST." <199503141940.LAA06109@elrond.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Mar 1995 14:54:38 -0500 From: "Perry E. Metzger" Dan Nessett says: > Jim, > > In regards to your questions : > > > > > Technical Questions: > > > > 1. To reveiw: Will in-band keying work with the present IPv6 specs > > (Rans work) without changes to the specifications? Not just SKIP > > (see next question). > > No. In-band keying will not work with the present IPv6 specs. This issue > is independent of SKIP. The problem is there is no place to indicate in > either the AH or ESP that in-band keying is being used. Thats not true. The reserved SAIDs were envisioned for doing things like this. It wasn't thought that we'd actually *want* to use them, but we did leave in the flexibility just in case. So far as I can tell, using one of the reserved SAIDs, as has been repeatedly proposed, would work just fine for you. This is not to say that the mechanism is being encouraged, but it is possible. Given the inability to reuse most of the rest of the protocol machinery, however, I really don't see, overall, why you would even want to try to get the round SKIP peg to fit into a square IPSP hole -- you need all your own transforms, you don't use the SAIDs per se, etc, etc -- for the most part, you aren't using the IPSP mechanisms at all. > > 2. Are there multiple ways to use in-band keying besides SKIP? > > I am asking this because I believe in-band keying should be > > something vendors should be able to build as a key-management > > solution. I am assuming SKIP is only one way to use in-band keying > > and others can exist too? > > SKIP is only one way to do in-band keying. Other possibilities > exist. However, none have been proposed as serious contenders for IETF standardization.... > As far as I know, SKIP is the only > widely publicized in-band keying method proposed for IPv6, ...which you seem to realize. > > 3. Can't we discuss this without mention of SKIP so that we can > > make sure either in-band or out-band can be used? I think its > > important we get to the heart of the architectural issues > > technically of the in/out modes and not get hung up on actual > > mechanisms? Or is this not a good idea? > > I agree 100% that we should focus on the issue of in-band and out-of-band > keying and not concentrate on SKIP. Given that different hacks and kludges are probably needed for each similar method proposed, I would say that trying to ignore the specifics of the SKIP proposal, which is the only one currently on the table of its kind, would be foolish. Perry From ipsec-request@ans.net Tue Mar 14 20:20:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28133 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 15:29:12 -0500 Received: by interlock.ans.net id AA09794 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 15:23:32 -0500 Message-Id: <199503142023.AA09794@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Mar 1995 15:23:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 15:23:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 15:23:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 15:23:32 -0500 Date: Tue, 14 Mar 1995 12:20:39 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security X-Sun-Charset: US-ASCII > Dan, > > Technical Questions: > > 1. To reveiw: Will in-band keying work with the present IPv6 specs > (Rans work) without changes to the specifications? Not just SKIP > (see next question). (You addressed Dan, but since this was public, I'll offer a response as well). In-band might work. The reason I am hedging is that the words about "not supporting" in-band not implying "precluding" in-band in the IPv6 Arch spec strike me as ambiguous. People wishing to do this later, and relying solely on the specs and not being privy to our e-mail discussions may in fact conclude that in-band keying is precluded. (This was the conclusion that Dan and I arrived at after reading the document). Certainly, there is little guidance in the specs to indicate how to perform in-band keying, should someone wish to do such a thing. By contrast, IEEE 802.10b explicitly defines the Management Defined Field (MDF) which follows the SAID and states that one possible use of this is to carry encrypted keys. My preferred way to deal with this would be to remove the ambiguous text, and specify somewhere how to achieve in-band keying. There have been discussions about bits in the SAID or one reserved SAID to indicate such a thing. We are currently working under the assumption that a reserved SAID may work better because people objected to burning up half the SAID space. In fact, Dan had suggested this to me prior to the suggestions on ipsec/ipng, and we were discussing the right way to structure the information. I am planning on writing up a transform for IPSP to indicate use of such a reserved SAID to indicate in-band keys and hope to write this up before the Danvers meeting. > 2. Are there multiple ways to use in-band keying besides SKIP? > I am asking this because I believe in-band keying should be > something vendors should be able to build as a key-management > solution. I am assuming SKIP is only one way to use in-band keying > and others can exist too? Yes, and in fact there is a DEC patent (US 5081678) on techniques that employ in-band keying that are totally unrelated to SKIP. > 3. Can't we discuss this without mention of SKIP so that we can > make sure either in-band or out-band can be used? We can and I think we should. > I think its > important we get to the heart of the architectural issues > technically of the in/out modes and not get hung up on actual > mechanisms? I, for one, concur. Regards, Ashar. From ipsec-request@ans.net Tue Mar 14 22:25:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17937 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 17:36:26 -0500 Received: by interlock.ans.net id AA42719 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 17:32:54 -0500 Message-Id: <199503142232.AA42719@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 17:32:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 17:32:54 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Cc: ipsec@ans.net Subject: I-D ACTION:draft-metzger-esp-01.txt Date: Tue, 14 Mar 95 17:25:08 -0500 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Encapsulating Security Payload (ESP) Author(s) : P. Metzger, P. Karn, W. Simpson Filename : draft-metzger-esp-01.txt Pages : 18 Date : 03/13/1995 This document describes a privacy mechanism for for the Internet Protocol. End-to-end headers are encapsulated within an opaque envelope. In addition, this document describes the use of DES-CBC security transform. 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-metzger-esp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-metzger-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) 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-metzger-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: <19950313164032.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-metzger-esp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-metzger-esp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950313164032.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Mar 14 21:54:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15269 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 17:53:53 -0500 Received: by interlock.ans.net id AA47854 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 17:48:16 -0500 Message-Id: <199503142248.AA47854@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 17:48:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 17:48:16 -0500 Date: Tue, 14 Mar 1995 13:54:32 -0800 From: Phil Karn To: atkinson@itd.nrl.navy.mil Cc: Danny.Nessett@eng.sun.com, ipng@sunroof.eng.sun.com, ipsec@ans.net In-Reply-To: <199503081901.AA04753@interlock.ans.net> (message from Ran Atkinson on Wed, 8 Mar 1995 14:00:25 -0500) Subject: Re: user-to-user vs. host-to-host keying > Your analysis was limited to DES. The specifications are >algorithm-independent and NEED to support other algorithms >such as RCx, IDEA, etc. The need for user-to-user keying Actually, the analysis that resulted in the 2^32 block limitation would seem to apply to any block cipher with a 64-bit block, regardless of key length. 2^32 blocks is a lot of data, the weakness is rather academic, and it's so easy to rekey that I'm not going to lose any sleep over this one. Phil From ipsec-request@ans.net Tue Mar 14 22:25:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15049 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 17:57:26 -0500 Received: by interlock.ans.net id AA08832 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 17:55:37 -0500 Message-Id: <199503142255.AA08832@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 17:55:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 17:55:37 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Cc: ipsec@ans.net Subject: I-D ACTION:draft-metzger-ah-01.txt Date: Tue, 14 Mar 95 17:25:56 -0500 Sender: cclark@CNRI.Reston.VA.US --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Authentication Header (AH) Author(s) : P. Metzger, W. Simpson Filename : draft-metzger-ah-01.txt Pages : 13 Date : 03/13/1995 This document describes an authentication mechanism for the Internet Protocol. An intervening Authentication Header is inserted between the IP Header and any transport headers. In addition, this document describes the use of keyed MD5. 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-metzger-ah-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-metzger-ah-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-metzger-ah-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: <19950313164554.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-metzger-ah-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-metzger-ah-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950313164554.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Mar 14 23:13:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04983 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 18:14:58 -0500 Received: by interlock.ans.net id AA06850 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 18:09:26 -0500 Message-Id: <199503142309.AA06850@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 18:09:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 18:09:26 -0500 Date: Tue, 14 Mar 1995 15:13:46 -0800 From: Phil Karn To: ipsec@ans.net Reply-To: karn@qualcomm.com Subject: Comments from Paul Van Oorschot I got this in email. I'm forwarding it to the list as it seems much more relevant than so much of the discussion here recently. I'll follow up with some responses. Phil Date: Thu, 9 Mar 1995 16:00:00 -0500 Content-Identifier: re:My photuri... From: "paul (p.c.) van oorschot" Sender: "paul (p.c.) van oorschot" To: karn Cc: "marcus (m.d.) leech" , ashar@osmosys.incog.com, whitfield.diffie@eng.sun.com Subject: re:My photuris protocol >Hi. Marcus Leech tells me you're interested in reviewing my photuris key >exchange protocol. It's out as an Internet draft in the usual places, >e.g., > >ftp://ds.internic.net/internet-drafts/draft-karn-photuris-00.txt. > >I'd like to hear your comments, especially on the advisability of signing >just the DH public component so it can be done in advance to save delay. >This is a hot topic of discussion on the ipsec mailing list. > >Phil Phil, I have looked over your Photuris I-D of December 1994, and offer the following comments. As I don't participate in the mailing list regularly, it would seem inappropriate for me to post to the list and not be available for responses, so I respond to you directly. Please feel free to forward/discuss in the list if you think appropriate. 1. (section 1) The first discussion of "perfect forward secrecy" I am aware of is by Gunther in his Eurocrypt'89 paper, ``An identity-based key exchange protocol", pp.29-37, though it is possible this term was defined earlier. BTW, this paper is quite relevant background reading. 2. (section 3.3, Cookie Generation) If I understand correctly, it appears the cookie party A creates to use with party B is time-invariant. Does this imply that if B is a malicious party, then any party A which ever gives to B a cookie is subject to a flooding attack by B? If so, it would seem prudent to recommend cookies be time-variant. 3. (section 4.5, Moduli) It is only fair to list disadvantages as well as advantages, of a fixed prime, including: 1) a fixed prime is a much more rewarding cryptanalytic target 2) the security of the whole system rests on this prime being good 3) changing this prime may lead to difficulties 4. (section 5.1, Signature Transmission) The authenticated key exchange protocol seems very similar to the the Station-to-Station (STS) protocol described by Diffie, van Oorschot and Wiener ("Authentication and authenticated key exchanges", Designs, Codes and Cryptography vol.2 pp.107-125 (1992)), including allowing identities to remain hidden from eavesdroppers, and encrypting a subset of the protocol data messages exchanged themselves. I have sent a hard copy of this paper to you by post today, presuming you do not have access to it. 5. I strongly recommend against signing only a single exponential. Attacks are known against similar protocols which do so, and there are general concerns (e.g. see pp.116-117 of STS paper). Signing both exponentials provides entity authentication guarantees, which prevent one class of replay attacks; signing only one does not, and in general is vulnerable to a wide array of possible "interleaving" attacks. 6. Due to the incredibly embarrassing track record of newly proposed authentication and authenticated key exchange proposals, I hesitate to support any brand new protocol, and recommend the group consider choosing one (from the literature or elsewhere) which has already been well-studied by a large number of experts, or which can be proven to be cryptographically equivalent to such a protocol. Kindest regards, Paul. P.S. I have also recently looked at Perry Metzger's "Troublemakers DRAFT" draft-metzger-ah-md5-01.txt. Am I correct in concluding it is indeed a joke? As has been discussed in the literature, the secret-prefix method proposed therein is insecure. ------------------------------------------------------------------------------ Paul Van Oorschot Bell-Northern Research | EMAIL: paulv@bnr.ca | MAIL TO: SHIP TO: | VOICE: 613-763-4199 | BNR, Box 3511, Station C, BNR, 2 Constellation Cr. | FAX: 613-765-3520 | Ottawa, Canada K1Y 4H7 Nepean, ON, Canada K2G 5J9 | | ------------------------------------------------------------------------------ From ipsec-request@ans.net Tue Mar 14 18:55:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20015 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 18:55:13 -0500 Received: by interlock.ans.net id AA03622 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 18:51:16 -0500 Message-Id: <199503142351.AA03622@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 18:51:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 18:51:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 18:51:16 -0500 Date: Tue, 14 Mar 95 15:27:58 From: "Housley, Russ" Encoding: 741 Text To: ipsec@ans.net Subject: Re: (IPng) Proposed message on perfect forward security Amir says: > ... Let me clarify: I agree with most of Perry's reservations about SKIP > and in-line keying. But, I don't agree with his conclusion. SKIP and > in-line keying give some unique advantages to certain valid scenarios. > Therefore, it would be good to include them as options of our key > management and encapsulation standards. Of course they should not be the > only mode or even the default, furthermore I'll agree to eliminate them > if we had a good reason (i.e. a big cost in efficiency, security, or > complexity). Like Amir, I see no big deal supporting this as an option. Let's stop bickering and agree to an approach that supports both Photuris-like and SKIP-like key management approaches. Russ From ipsec-request@ans.net Tue Mar 14 19:12:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27096 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 19:12:04 -0500 Received: by interlock.ans.net id AA29505 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 19:07:51 -0500 Message-Id: <199503150007.AA29505@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 19:07:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 19:07:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 19:07:51 -0500 Date: Tue, 14 Mar 95 15:28:27 From: "Housley, Russ" Encoding: 767 Text To: Hilarie Orman Cc: ipsec@ans.net Subject: Re[2]: End of WG Last Call for AH+MD5 and ESP+DES+3DES Hilarie said: I think that MD5(key, text, key) may be more secure than the double hash. My understanding is that Kaliski's suggestion was based on the idea that MD5(text) might be a useful subfunction. However, I'm uneasy at the idea of a possible cryptanalysis of MD5(foo,key); not a question I've seen examined before. MD5(key,data,key) is one of the few things we had concensus about. Burt did not say that this was weak, rather he said that the other had more study behind it. I think that we should keep MD5(key,data,key) because it an be computed with one function invocation when implemented in hardware. MD5(MD5(data),key) will require two function invocations in hardware implementations. Russ From ipsec-request@ans.net Wed Mar 15 00:35:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25720 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 19:39:10 -0500 Received: by interlock.ans.net id AA51930 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 19:35:50 -0500 Message-Id: <199503150035.AA51930@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Mar 1995 19:35:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 19:35:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 19:35:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 19:35:50 -0500 To: "Housley, Russ" Cc: ipsec@ans.net Subject: Re: (IPng) Proposed message on perfect forward security In-Reply-To: Your message of "Tue, 14 Mar 1995 15:27:58." <199503142351.AA03622@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 14 Mar 1995 19:35:39 -0500 From: "Perry E. Metzger" "Housley, Russ" says: > > Amir says: > > ... Let me clarify: I agree with most of Perry's reservations about SKIP > > and in-line keying. But, I don't agree with his conclusion. SKIP and > > in-line keying give some unique advantages to certain valid scenarios. > > Therefore, it would be good to include them as options of our key > > management and encapsulation standards. Of course they should not be the > > only mode or even the default, furthermore I'll agree to eliminate them > > if we had a good reason (i.e. a big cost in efficiency, security, or > > complexity). > > Like Amir, I see no big deal supporting this as an option. Let's stop > bickering and agree to an approach that supports both Photuris-like and > SKIP-like key management approaches. I believe that for some time now it has been proposed that SKIP be given one of the "reserved" SAID values and that things be left at that. I don't see why this wouldn't be sufficient. .pm From ipsec-request@ans.net Tue Mar 14 20:32:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07159 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 20:28:34 -0500 Received: by interlock.ans.net id AA05096 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 20:25:51 -0500 Message-Id: <199503150125.AA05096@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 14 Mar 1995 20:25:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Mar 1995 20:25:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 20:25:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 20:25:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 20:25:51 -0500 Date: Tue, 14 Mar 1995 12:32:14 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipng@sunroof.eng.sun.com, perry@imsi.com Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net, bound@zk3.dec.com X-Sun-Charset: US-ASCII Perry, In an earlier message I point out : > > No. In-band keying will not work with the present IPv6 specs. This issue > > is independent of SKIP. The problem is there is no place to indicate in > > either the AH or ESP that in-band keying is being used. To which you reply : > Thats not true. > > The reserved SAIDs were envisioned for doing things like this. It > wasn't thought that we'd actually *want* to use them, but we did leave > in the flexibility just in case. > > So far as I can tell, using one of the reserved SAIDs, as has been > repeatedly proposed, would work just fine for you. This is not to say > that the mechanism is being encouraged, but it is possible. Given the > inability to reuse most of the rest of the protocol machinery, > however, I really don't see, overall, why you would even want to try > to get the round SKIP peg to fit into a square IPSP hole -- you need > all your own transforms, you don't use the SAIDs per se, etc, etc -- > for the most part, you aren't using the IPSP mechanisms at all. Allow me to quote from the current AH I-D : A 32-bit pseudo-random value identifying the security association for this datagram. If no security association has been established, the value of this field shall be 0x00000000. The set of SAID values in the range 0x00000001 through 0x000000FF are reserved for future use. There is similar language in the ESP I-D. I read this to mean that the reserved values are "reserved," i.e., not to be used, since they may be used for some unspecified purpose in the future. If the security documents are modified to indicate an SAID value that is to mean, "using in-band keying," then what you say would be true. However, at present it is not. Dan From ipsec-request@ans.net Tue Mar 14 19:40:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20150 (5.65c/IDA-1.4.4 for ); Tue, 14 Mar 1995 21:36:29 -0500 Received: by interlock.ans.net id AA04246 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 21:33:47 -0500 Message-Id: <199503150233.AA04246@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Tue, 14 Mar 1995 21:33:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 14 Mar 1995 21:33:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 21:33:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 21:33:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 21:33:47 -0500 Date: Tue, 14 Mar 1995 11:40:52 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipng@sunroof.eng.sun.com, ipsec@ans.net, bound@zk3.dec.com Subject: Re: (IPng) Re: Proposed message on perfect forward security X-Sun-Charset: US-ASCII Jim, In regards to your questions : > > Technical Questions: > > 1. To reveiw: Will in-band keying work with the present IPv6 specs > (Rans work) without changes to the specifications? Not just SKIP > (see next question). No. In-band keying will not work with the present IPv6 specs. This issue is independent of SKIP. The problem is there is no place to indicate in either the AH or ESP that in-band keying is being used. > 2. Are there multiple ways to use in-band keying besides SKIP? > I am asking this because I believe in-band keying should be > something vendors should be able to build as a key-management > solution. I am assuming SKIP is only one way to use in-band keying > and others can exist too? SKIP is only one way to do in-band keying. Other possibilities exist. For example, Russ Housley has reported on these lists that the IEEE 802.10 standard for Secure Data Exchange (SDE) supports an in-band keying approach developed by DEC. I believe this approach could also be used for in-band keying for IPv6, but would defer on that to the original designers of the protocol or to someone on the IEEE 802.10 committee. As far as I know, SKIP is the only widely publicized in-band keying method proposed for IPv6, but I haven't had a chance to read the recent proposal by Hugo at IBM, so I could be wrong about that. > 3. Can't we discuss this without mention of SKIP so that we can > make sure either in-band or out-band can be used? I think its > important we get to the heart of the architectural issues > technically of the in/out modes and not get hung up on actual > mechanisms? Or is this not a good idea? I agree 100% that we should focus on the issue of in-band and out-of-band keying and not concentrate on SKIP. It is others on this list that continually make accusations about this being a purely SKIP issue. From my perspective the issue is more general. The IPv6 security documents should be written in such a way as not to preclude or even discourage the use of in-band keying. They should be general enough to allow both. Dan From ipsec-request@ans.net Tue Mar 14 12:58:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21192 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 00:01:44 -0500 Received: by interlock.ans.net id AA03936 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 14 Mar 1995 23:58:54 -0500 Message-Id: <199503150458.AA03936@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 14 Mar 1995 23:58:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 14 Mar 1995 23:58:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 14 Mar 1995 23:58:54 -0500 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net, deering@parc.xerox.com Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Danny.Nessett's message of Tue, 14 Mar 95 11:40:52 -0800. <199503141940.LAA06109@elrond.Eng.Sun.COM> Date: Tue, 14 Mar 1995 20:58:28 PST Sender: Steve Deering From: Steve Deering Dan, > No. In-band keying will not work with the present IPv6 specs. This issue > is independent of SKIP. The problem is there is no place to indicate in > either the AH or ESP that in-band keying is being used. I haven't had time to follow the great In-Band/Out-of-Band keying debate in detail, so please excuse me if this is off-base. I thought I saw the suggestion that one of the reserved SAID values could be assigned the role of indicating the presence of in-packet keying material. Alternatively, you could use an option in a Destination (formerly End-to-End) Options header preceding the AH or ESP header to carry the in-packet key stuff. Is it simply the lack of a spec that defines either of those alternatives that leads you to say "In-band keying will not work with the present IPv6 specs."? If so, feel free to write such a spec. Steve From ipsec-request@ans.net Wed Mar 15 12:22:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28092 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 07:26:55 -0500 Received: by interlock.ans.net id AA06138 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 07:22:29 -0500 Message-Id: <199503151222.AA06138@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 07:22:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 07:22:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 07:22:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 07:22:29 -0500 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: Wed, 15 Mar 1995 07:22:12 -0500 To: ipsec@ans.net From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: Diffie's comments on Photuris Yesterday afternoon I attended a meeting of the Automotive Industry Action Group (AIAG)'s new OEM CAD/CAM Telecommunications Task Team. It appears to be the intent of the group to construct a private IP network for security reasons. Such a network would include connections to all of the North American car manufacturers and all of their suppliers. Even non-productive parts. We are talking in the neighborhood of 60 - 100K companies. If I had security in hand, I would be in a better position to argue against a private network. Remember, MCI, AT&T, Sprint, and others will be all too happy to build such a private network. The cost of this will be in the cost of our products. And noone else will benefit from the bandwidth. BTW, I want security on a private network as much as I want it on a public network, but many managers don't see that. The TELCOs have made convincing presentations.... Final note. Any comments on the TimeStep product (division of New Bridge). Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Wed Mar 15 12:14:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27070 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 07:26:55 -0500 Received: by interlock.ans.net id AA31175 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 07:15:22 -0500 Message-Id: <199503151215.AA31175@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 07:15:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 07:15:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 07:15:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 07:15:22 -0500 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: Wed, 15 Mar 1995 07:14:55 -0500 To: karn@qualcomm.com, ashar@osmosys.incog.com From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: Diffie's comments on Photuris Cc: ipsec@ans.net At 11:18 AM 3/14/95 -0800, karn@qualcomm.com wrote: >Ashar, > >Thanks for forwarding that note from Whit. In thinking about it and >similar comments from you and others, I've tentatively decided to modify >Photuris to sign the shared secret. > >I've been thinking about a related problem for some time: finding a >safe way to use my PGP key on my workstation at work. If I were to >type my PGP passphrase into a machine I don't fully trust, I'd risk >compromising *all* of the traffic I have ever received or will receive >with that PGP key, including personal mail read only at home. > >Using separate keys is one possible approach, but that's clumsy. > >The ideal answer seems to be a smart-card that I can plug into the >workstation that safely holds my RSA secret key and uses it to perform >operations on behalf of the host without ever letting the secret key >leave the card. For maximum safety, the card could log all operations >and possibly even require a manual "go" button press to approve each >operation. Even in the smartcard the RSA secret key would exist in >plaintext only when it is in active use. At all other times it would >be encrypted in a symmetric algorithm; before use the user would have >to enter the key for the symmetric algorithm on a keypad on the card. >One might even store the encrypted secret key on the host, eliminating >the need for stable storage on the card. But this would place total >reliance on the secrecy of the key for the symmetric algorithm, which >is probably a bad idea given our experiences with badly chosen user >passwords. The Cryptodisk from SmartDisk security Corp is a good start in this direction. It uses a 3.5" diskette format, so most devices can interface with it without special hardware. It has the Seimens chip in it so my understanding is it is limited to 512bit RSA keys. It has 8K of EEPROM for storage of various key information. Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Wed Mar 15 13:12:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15385 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 08:19:30 -0500 Received: by interlock.ans.net id AA30156 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 08:15:49 -0500 Message-Id: <199503151315.AA30156@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 08:15:49 -0500 From: Ran Atkinson Date: Wed, 15 Mar 1995 08:12:23 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: (IPng) Re: Proposed message on perfect forward security" (Mar 14, 12:32) References: <199503150125.AA05096@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.itd.nrl.navy.mil Dan, I will edit the drafts to clarify. Those "reserved for future use" SAIDs are reserved to the Internet Assigned Numbers Authority (IANA) per the universal IETF practice. The IANA has always been most reasonable about allocating numbers in all cases for the entire past for all protocols where IANA controls number spaces. It is often the case that IANA wants a public specification (e.g. Informational RFC or Experimental RFC or Standards-track RFC) to exist before granting the number. I will support allocating _1_ of the reserved SAIDs to SKIP once there is a public specification for how SKIP would be used. That public spec would need to be reasonably complete and reasonably clear (i.e. clear enough that someone else could implement it if patent issues and such did not exist). Such allocation would be the decision of the IANA, but there are zero cases where IANA has been unreasonable about allocating numbers. If I understand Ted, Bill, Perry, and Jeff correctly, they would also support allocating _1_ of the reserved SAIDs to SKIP once there were a clear public spec for how SKIP would be implemented/used with the IPv4/v6 security mechanisms. (Jim, The same applies for any "in-band" (sic) protocol that DEC would like to use. DEC should have no trouble obtaining a reserved SAID upon publication of an open specification for its key management scheme should DEC choose to go down that path :-). Because the IPv6/v4 security drafts are standards-track and the use of SKIP is not currently standards-track (or even the consensus of the IPsec WG, unlike Photuris which does have rough consensus in the IPsec WG), it is not appropriate for those IPv4/v6 drafts to specifically allocate an SAID to SKIP at this time. Furthermore, there is no I-D or RFC describing how SKIP would be used with IPv4/v6 security so it would be granting a special privilege to an undocumented protocol that is currently completely proprietary. This also makes it inappropriate for a standards-track specification such as the IPv4/IPv6 security drafts. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Mar 15 04:23:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22748 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 09:27:49 -0500 Received: by interlock.ans.net id AA04022 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 09:21:56 -0500 Message-Id: <199503151421.AA04022@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 09:21:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 09:21:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 09:21:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 09:21:56 -0500 To: ipsec@ans.net Subject: subscribe Date: Wed, 15 Mar 1995 09:23:07 EST From: Bryan Solie subscribe From ipsec-request@ans.net Wed Mar 15 13:57:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21726 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 09:27:49 -0500 Received: by interlock.ans.net id AA04284 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 09:22:02 -0500 Message-Id: <199503151422.AA04284@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 09:22:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 09:22:02 -0500 Date: Wed, 15 Mar 95 13:57:12 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: I-D ACTION:draft-metzger-esp-3des-cbc-01.txt Cynthia missed one: > Mime-Version: 1.0 > Content-Type: Multipart/Mixed; Boundary="NextPart" > To: IETF-Announce:@MorningStar.Com ; > Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US > From: Internet-Drafts@CNRI.Reston.VA.US > Reply-To: Internet-Drafts@CNRI.Reston.VA.US > Subject: I-D ACTION:draft-metzger-esp-3des-cbc-01.txt > Date: Tue, 14 Mar 95 17:27:33 -0500 > X-Orig-Sender: cclark@CNRI.Reston.VA.US > Message-Id: <9503141727.aa11370@IETF.CNRI.Reston.VA.US> > > --NextPart > > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : The ESP Triple DES-CBC Transform > Author(s) : P. Metzger, P. Karn, W. Simpson > Filename : draft-metzger-esp-3des-cbc-01.txt > Pages : 9 > Date : 03/13/1995 > > This document describes the Triple DES-CBC security transform for the > 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-metzger-esp-3des-cbc-01.txt". > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-metzger-esp-3des-cbc-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-metzger-esp-3des-cbc-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: <19950313172547.I-D@CNRI.Reston.VA.US> > > ENCODING mime > FILE /internet-drafts/draft-metzger-esp-3des-cbc-01.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-metzger-esp-3des-cbc-01.txt"; > site="ds.internic.net"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <19950313172547.I-D@CNRI.Reston.VA.US> > > --OtherAccess-- > > --NextPart-- > Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 15 14:12:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16102 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 09:27:56 -0500 Received: by interlock.ans.net id AA10182 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 09:22:09 -0500 Message-Id: <199503151422.AA10182@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 09:22:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 09:22:09 -0500 Date: Wed, 15 Mar 95 14:12:10 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: MD5 hash calculation > From: smb@research.att.com > No, it's easier to find MD5(text') than MD5(key,text). The reason is > that in the former case, there's full known plaintext; in the latter, > there's an unknown component. How does that help? If you are capable of modifying a text to produce the same hash, then you don't need to know the unknown component. The security of hashing rests on the resistance to generating another with the same hash, not the secret itself. > Furthermore, one can often generate chosen > plaintext going to someone's terminal (this mail message, for example). > If I have a large sample of legitimate packets authenticated by > MD5(key,MD5(text)), then I can attack you if I can generate a nastygram > whose hash matches any if the MD5(text_i)'s in my collection. I don't > have to know the key. With MD5(key,text), I have to find some evil > text that will generate the same authentication value *after* concatenation > with a key I don't know. > I don't understand the difference. If you have a collection of text authenticated with MD5(key,text), you still have the same list of possible hashes, and you can substitute the same pre-authenticated chosen plaintext without knowing the key at all. Again, the security rests on the difficulty and likelihood of finding the match, not on the secret itself. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 15 03:57:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15995 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 09:49:32 -0500 Received: by interlock.ans.net id AA29974 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 09:41:44 -0500 Message-Id: <199503151441.AA29974@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 09:41:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 09:41:44 -0500 Date: Wed, 15 Mar 95 08:57:32 EST From: hugo@watson.ibm.com To: karn@qualcomm.com Cc: IPSEC@ans.net Subject: A Photuris variant Phil, Thanks for your comments. Some clarifications are needed. > Photuris uses DH + PK digital signatures only. The digital signature > scheme could be either RSA or DSA. If you choose DSA and it withstands > a PKP challenge, the whole Photuris scheme could be unencumbered as > early as 1997 when the DH patent expires. > > On the other hand, your scheme requires a full public key encryption > algorithm, i.e., RSA...the patent for which doesn't expire until 2000. You are right on what you say about your scheme, but not on what you say about my variant. The same way you can use DSA for signatures in your scheme, you can use ElGamal encryption with mine. Moreover, while by using DSA you MAY eventually need to pay royalties until 2007 when Schnorr's patent expires, for ElGamal you WON'T pay anything after 1997. So, in this sense, if there is an advantage it is to my scheme (I am saying this because you brought the issue not because I see this as a significant reason to prefer mine). > Of course, all this is moot unless or until IBM is willing to place > your scheme in the public domain. Please advise on this point before > we spend too much time discussing it. Is there an implicit assumption here that the scheme is patented? Well, to the best of my knowledge there are no patents (except the PKP ones) covering this proposal. Do you know of any? If somebody knows of any relevant patents please let us know. (Same for the basic Photuris). > Aside from that, I see a serious technical problem in your share > phase. How does each party know the public key of the other party so > it can encrypt the half-keys K1 and K2? If you first send your public > key in the clear, then you've just identified yourself to a passive > eavesdropper. But you'd have to do this since your correspondent can't > infer your public key (e.g., from a table) solely on the basis of your > IP source address -- it could well have been dynamically assigned by a > dialup PPP router or DHCP server. (A major purpose of IPSP is to > divorce authentication identities from IP addresses.) > > Photuris does the DH exchange first specifically to help cover the > authentication exchange that follows, to provide anonymity against > passive eavesdropping. I consider this to be a pretty important > feature. Anonymity is indeed a significant feature required in some situations. This is why I thought it should be accomodated in my scheme. And, indeed, my scheme achieves that in a natural (and, as I said in my original note, transparent) way. The initiator encrypts its identity, together with K1, under the responder's public key in the first message (if anonymity is not required, this identity is just omitted from the encryption). I believe that in most cases a relatively short identity will suffice (e.g., a DNS name). However, if you want to support the sending of I's public-key (in that case I guess you want to send also a validating certificate) then there is no room in the public-key encryption to send all this information. In that (I believe, not so common) case, you will use K1 to encrypt that information (using a symetric algorithm). Now, if you are talking of an inititiator I that communicates to a responder R, and I does not have a way to get R's public key before the communication, then we have a problem. Before discussing this problem you'll need to convince me that this is a realistic situation. (If so, then the performance of a first phase of unauthenticated DH, as in your scheme, is the ONLY solution). Let me stop here and I'll continue in another message. Hugo From ipsec-request@ans.net Wed Mar 15 04:23:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28047 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 11:08:24 -0500 Message-Id: <199503151608.AA28047@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Wed, 15 Mar 1995 11:02:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 11:02:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 11:02:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 11:02:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 11:02:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 15 Mar 1995 11:02:29 -0500 To: ipsec@ans.net Subject: subscribe Date: Wed, 15 Mar 1995 09:23:07 EST From: Bryan Solie subscribe From ipsec-request@ans.net Wed Mar 15 16:21:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28050 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 11:30:47 -0500 Received: by interlock.ans.net id AA15240 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 11:20:15 -0500 Message-Id: <199503151620.AA15240@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 15 Mar 1995 11:20:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 11:20:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 11:20:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 11:20:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 11:20:15 -0500 To: stripes@uunet.uu.net Cc: ipsec@ans.net, throop@dg-rtp.dg.com Subject: Re: (IPng) More Endpoint Attributes In-Reply-To: Your message of "Wed, 15 Mar 95 10:35:46 EST." Date: Wed, 15 Mar 95 11:21:26 -0500 From: Andy Bayerl X-Mts: smtp [I am replying to this on the ipsec list, since that is where this discussion probably belongs.] You write: uid/gid info is very OS dependent. Not just the exact usage, but the concept, and storage type. It would be sufficant to represent Unix uid/gid info as a bunch of 32 bit values for all the systems I know of (or does the Alpha use 64bit uids and gids?), with an arbatary number of gid's. Likewise a large integer would do for the pid as well. [ and so on ...] I agree that the attributes are OS dependent and may even vary between differently configured hosts using the same OS and platforms. For example, on MLS CMW systems the label encodings files may be different but there may exist a reasonable mapping between the two. The issues have been addressed by the TSIG (Trusted Systems Interoperability Group) specifications grouped under the name TSIX. We have MLS products shipped which employ those specifications and have demonstrated its use between heterogeneous UNIX-based platforms. I do not believe anyone has as yet demonstrated operation against a non-UNIX platform but I believe the concepts would work in that environment. Briefly, in the TSIX model, the attributes are negotiated between the end points as 32-bit tokens using and out-of-band token mapping protocol. The protocol allows the end points to select domains of translation which allow for the attributes to be represented (between the token mappers) in ASCII or binary form. They also allow for tranforms to be applied between local representations and the wire representation of the attributes. Once the attributes have been mapped, the tokens are used in the end-to-end communication. From ipsec-request@ans.net Wed Mar 15 16:24:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04285 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 11:35:39 -0500 Received: by interlock.ans.net id AA10798 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 11:28:14 -0500 Message-Id: <199503151628.AA10798@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 15 Mar 1995 11:28:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 11:28:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 11:28:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 11:28:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 11:28:14 -0500 Date: Wed, 15 Mar 1995 08:24:47 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: deering@parc.xerox.com Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net X-Sun-Charset: US-ASCII Steve, Yes, you are right about : > I thought I saw the > suggestion that one of the reserved SAID values could be assigned the role > of indicating the presence of in-packet keying material. The problems with this are : o The existing security architecture I-D explicitly deprecates the use of in-band keying. While we know that it can be made to fit into the existing formats, those who read the documents without the benefit of reading all of the email on this subject that has appeared on the IPng list would legitimately conclude that in-band keying is outside the standard. o One of the reserved SAID values could be used, but right now they are "reserved for future use." Those who are interested in using one of them for in-band keying can't just unilaterally pick one and use it, since sometime in the future the IETF may pick it to be used for something else. I have emailed to the list a suggested value to use for this purpose (i.e., SAID = 1) and proposed that the existing security drafts be changed to include it. (Of course, I don't care if the value is 1, 4 7 or whatever, I just picked 1 as a concrete proposal). o Picking an SAID value for in-band keying still leaves the problem of parsing the remaining information. This problem has two parts. One is how the software will know which in-band keying algorithm is used, and the other is what data format is being used for the algorithm specific data. The first problem is solved by defining a standard way to indicate which algorithm is being used and where the algorithm specific data will go. I have suggested ways in which the current security I-Ds could be changed to do this (but am open to other ways). The second problem is solved on an algorithm by algorithm basis, probably in the form of an RFC per algorithm (much as Photuris will have its own RFC). While your suggestion : > Alternatively, you > could use an option in a Destination (formerly End-to-End) Options header > preceding the AH or ESP header to carry the in-packet key stuff. is possible, it would effectively mean that there would be two AH and ESP header formats (although, they might be called something different). The kind of data in the new option would be pretty much like that in the AH and ESP headers. This seems wasteful, since an IPv6 packet would not carry both an AH or ESP header formated according to the existing definitions as well as the in-band Destination Options header. Your other suggestion, i.e., > Is it > simply the lack of a spec that defines either of those alternatives that > leads you to say "In-band keying will not work with the present IPv6 specs."? > If so, feel free to write such a spec. I have tried to avoid, since it would mean taking 95% of the text from the existing security I-Ds, change it in the way I have suggested in previous email to the list and putting it out as separate drafts. Not only would this be rude to Ran (i.e., stealing someone's text is a somewhat hostile act), it would mean that there would now be two sets of drafts for the already streched people on the list to read and evaluate. Dan From ipsec-request@ans.net Wed Mar 15 14:12:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04291 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 11:35:43 -0500 Message-Id: <199503151635.AA04291@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Wed, 15 Mar 1995 11:31:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 11:31:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 11:31:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 15 Mar 1995 11:31:36 -0500 Date: Wed, 15 Mar 95 14:12:10 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: MD5 hash calculation > From: smb@research.att.com > No, it's easier to find MD5(text') than MD5(key,text). The reason is > that in the former case, there's full known plaintext; in the latter, > there's an unknown component. How does that help? If you are capable of modifying a text to produce the same hash, then you don't need to know the unknown component. The security of hashing rests on the resistance to generating another with the same hash, not the secret itself. > Furthermore, one can often generate chosen > plaintext going to someone's terminal (this mail message, for example). > If I have a large sample of legitimate packets authenticated by > MD5(key,MD5(text)), then I can attack you if I can generate a nastygram > whose hash matches any if the MD5(text_i)'s in my collection. I don't > have to know the key. With MD5(key,text), I have to find some evil > text that will generate the same authentication value *after* concatenation > with a key I don't know. > I don't understand the difference. If you have a collection of text authenticated with MD5(key,text), you still have the same list of possible hashes, and you can substitute the same pre-authenticated chosen plaintext without knowing the key at all. Again, the security rests on the difficulty and likelihood of finding the match, not on the secret itself. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 15 13:57:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22365 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 12:09:10 -0500 Message-Id: <199503151709.AA22365@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Wed, 15 Mar 1995 12:04:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 12:04:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 12:04:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 15 Mar 1995 12:04:00 -0500 Date: Wed, 15 Mar 95 13:57:12 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: I-D ACTION:draft-metzger-esp-3des-cbc-01.txt Cynthia missed one: > Mime-Version: 1.0 > Content-Type: Multipart/Mixed; Boundary="NextPart" > To: IETF-Announce:@MorningStar.Com ; > Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US > From: Internet-Drafts@CNRI.Reston.VA.US > Reply-To: Internet-Drafts@CNRI.Reston.VA.US > Subject: I-D ACTION:draft-metzger-esp-3des-cbc-01.txt > Date: Tue, 14 Mar 95 17:27:33 -0500 > X-Orig-Sender: cclark@CNRI.Reston.VA.US > Message-Id: <9503141727.aa11370@IETF.CNRI.Reston.VA.US> > > --NextPart > > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : The ESP Triple DES-CBC Transform > Author(s) : P. Metzger, P. Karn, W. Simpson > Filename : draft-metzger-esp-3des-cbc-01.txt > Pages : 9 > Date : 03/13/1995 > > This document describes the Triple DES-CBC security transform for the > 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-metzger-esp-3des-cbc-01.txt". > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-metzger-esp-3des-cbc-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-metzger-esp-3des-cbc-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: <19950313172547.I-D@CNRI.Reston.VA.US> > > ENCODING mime > FILE /internet-drafts/draft-metzger-esp-3des-cbc-01.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-metzger-esp-3des-cbc-01.txt"; > site="ds.internic.net"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <19950313172547.I-D@CNRI.Reston.VA.US> > > --OtherAccess-- > > --NextPart-- > Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 15 03:57:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04900 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 12:29:45 -0500 Message-Id: <199503151729.AA04900@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Wed, 15 Mar 1995 12:26:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 12:26:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 12:26:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 15 Mar 1995 12:26:00 -0500 Date: Wed, 15 Mar 95 08:57:32 EST From: hugo@watson.ibm.com To: karn@qualcomm.com Cc: IPSEC@ans.net Subject: A Photuris variant Phil, Thanks for your comments. Some clarifications are needed. > Photuris uses DH + PK digital signatures only. The digital signature > scheme could be either RSA or DSA. If you choose DSA and it withstands > a PKP challenge, the whole Photuris scheme could be unencumbered as > early as 1997 when the DH patent expires. > > On the other hand, your scheme requires a full public key encryption > algorithm, i.e., RSA...the patent for which doesn't expire until 2000. You are right on what you say about your scheme, but not on what you say about my variant. The same way you can use DSA for signatures in your scheme, you can use ElGamal encryption with mine. Moreover, while by using DSA you MAY eventually need to pay royalties until 2007 when Schnorr's patent expires, for ElGamal you WON'T pay anything after 1997. So, in this sense, if there is an advantage it is to my scheme (I am saying this because you brought the issue not because I see this as a significant reason to prefer mine). > Of course, all this is moot unless or until IBM is willing to place > your scheme in the public domain. Please advise on this point before > we spend too much time discussing it. Is there an implicit assumption here that the scheme is patented? Well, to the best of my knowledge there are no patents (except the PKP ones) covering this proposal. Do you know of any? If somebody knows of any relevant patents please let us know. (Same for the basic Photuris). > Aside from that, I see a serious technical problem in your share > phase. How does each party know the public key of the other party so > it can encrypt the half-keys K1 and K2? If you first send your public > key in the clear, then you've just identified yourself to a passive > eavesdropper. But you'd have to do this since your correspondent can't > infer your public key (e.g., from a table) solely on the basis of your > IP source address -- it could well have been dynamically assigned by a > dialup PPP router or DHCP server. (A major purpose of IPSP is to > divorce authentication identities from IP addresses.) > > Photuris does the DH exchange first specifically to help cover the > authentication exchange that follows, to provide anonymity against > passive eavesdropping. I consider this to be a pretty important > feature. Anonymity is indeed a significant feature required in some situations. This is why I thought it should be accomodated in my scheme. And, indeed, my scheme achieves that in a natural (and, as I said in my original note, transparent) way. The initiator encrypts its identity, together with K1, under the responder's public key in the first message (if anonymity is not required, this identity is just omitted from the encryption). I believe that in most cases a relatively short identity will suffice (e.g., a DNS name). However, if you want to support the sending of I's public-key (in that case I guess you want to send also a validating certificate) then there is no room in the public-key encryption to send all this information. In that (I believe, not so common) case, you will use K1 to encrypt that information (using a symetric algorithm). Now, if you are talking of an inititiator I that communicates to a responder R, and I does not have a way to get R's public key before the communication, then we have a problem. Before discussing this problem you'll need to convince me that this is a realistic situation. (If so, then the performance of a first phase of unauthenticated DH, as in your scheme, is the ONLY solution). Let me stop here and I'll continue in another message. Hugo From ipsec-request@ans.net Wed Mar 15 17:32:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27093 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 12:40:56 -0500 Received: by interlock.ans.net id AA29715 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 12:35:02 -0500 Message-Id: <199503151735.AA29715@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 12:35:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 12:35:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 12:35:02 -0500 X-Sender: hinden@servo.ipsilon.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Mar 1995 09:32:52 -0800 To: ipng@sunroof.eng.sun.com From: hinden@ipsilon.com (Bob Hinden) Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net Dan, I have been reading this exchange for a while now and think it has gone beyond the point of being constructive a long while ago. The current exchange seems to me be centered around the definition of the word "reserved". Some seem to think it excludes the possibility of "in-band keying", other think it allows it. This is no longer a technical discussion. Perhaps this debate could be ended if the text was changed to say something like: The set of SAID values in the range 0x00000001 through 0x000000FF are reserved for future use (for example "in-band keying"). Then perhaps everyone can go back to developing and deploying some real key management algorithms and software which we all really need if the internet is to have real security. Bob At 12:32 PM 3/14/95, Dan Nessett wrote: >Perry, > >In an earlier message I point out : > >> > No. In-band keying will not work with the present IPv6 specs. This issue >> > is independent of SKIP. The problem is there is no place to indicate in >> > either the AH or ESP that in-band keying is being used. > >To which you reply : > >> Thats not true. >> >> The reserved SAIDs were envisioned for doing things like this. It >> wasn't thought that we'd actually *want* to use them, but we did leave >> in the flexibility just in case. >> >> So far as I can tell, using one of the reserved SAIDs, as has been >> repeatedly proposed, would work just fine for you. This is not to say >> that the mechanism is being encouraged, but it is possible. Given the >> inability to reuse most of the rest of the protocol machinery, >> however, I really don't see, overall, why you would even want to try >> to get the round SKIP peg to fit into a square IPSP hole -- you need >> all your own transforms, you don't use the SAIDs per se, etc, etc -- >> for the most part, you aren't using the IPSP mechanisms at all. > >Allow me to quote from the current AH I-D : > > A 32-bit pseudo-random value identifying the security association > for this datagram. If no security association has been established, > the value of this field shall be 0x00000000. The set of SAID values > in the range 0x00000001 through 0x000000FF are reserved for future > use. > >There is similar language in the ESP I-D. I read this to mean that the >reserved values are "reserved," i.e., not to be used, since they may >be used for some unspecified purpose in the future. If the security documents >are modified to indicate an SAID value that is to mean, "using in-band >keying," then what you say would be true. However, at present it is not. > >Dan >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >Unsubscribe: unsubscribe ipng (as message body, not subject) >Direct all administrative requests to majordomo@sunroof.eng.sun.com From ipsec-request@ans.net Wed Mar 15 17:54:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21006 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 13:09:53 -0500 Received: by interlock.ans.net id AA21514 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 13:05:16 -0500 Message-Id: <199503151805.AA21514@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 13:05:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 13:05:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 13:05:16 -0500 From: Steve Bellovin To: ipng@sunroof.eng.sun.com Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net Date: Wed, 15 Mar 1995 12:54:29 -0500 Sender: smb@research.att.com > Perhaps this debate could be ended if the text was changed to say something > like: > > The set of SAID values in the range 0x00000001 through 0x000000FF > are reserved for future use (for example "in-band keying"). > > Then perhaps everyone can go back to developing and deploying some real key > management algorithms and software which we all really need if the internet > is to have real security. In principle, I have no objection, and I'd even suggest making the reserved range larger. But the real issue is still open: what will be the common, interoperable key exchange protocol, and will it be in-band or out-of-band. We've achieved nothing if adopting this language just prolongs the debate. From ipsec-request@ans.net Wed Mar 15 18:04:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21110 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 13:15:06 -0500 Received: by interlock.ans.net id AA29812 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 13:09:31 -0500 Message-Id: <199503151809.AA29812@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 15 Mar 1995 13:09:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 13:09:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 13:09:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 13:09:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 13:09:31 -0500 Date: Wed, 15 Mar 1995 10:04:10 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: hinden@servo.ipsilon.com, ipng@sunroof.eng.sun.com Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net X-Sun-Charset: US-ASCII Bob, Ran has recently sent out an email message stating that he will modify the security I-D to clarify that the IANA will control the range of reserved SAIDs. I think that is helpful. However, the draft still deprecates the use of in-band keying. Why? I guess I am puzzled by your observation that the exchange "has gone beyond the point of being constructive a long while ago." If to pursue an issue is unproductive, what does this say about the whole IETF process? The author of the security I-Ds is reluctant to change them to accomodate in-band keying. Why? However, if pursuing this issue is seen by the long term participants of the IPng working group as counter-productive, then I will retire. I thought this was supposed to be an open process. Dan From ipsec-request@ans.net Wed Mar 15 18:45:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22013 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 13:55:06 -0500 Received: by interlock.ans.net id AA26723 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 13:46:12 -0500 Message-Id: <199503151846.AA26723@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 13:46:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 13:46:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 13:46:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 13:46:12 -0500 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Wed, 15 Mar 1995 10:04:10 PST." <199503151809.AA29812@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Mar 1995 13:45:39 -0500 From: "Perry E. Metzger" Dan Nessett says: > Ran has recently sent out an email message stating that he will modify the > security I-D to clarify that the IANA will control the range of reserved > SAIDs. I think that is helpful. However, the draft still deprecates the > use of in-band keying. Why? Not "deprecates". "Is not intended for". The point is this. IPSP was not intended for this use. See that big 32 bit SAID? Well, if we were to use SKIP, that whole field would be a waste of space. If we had expected to use SKIP, it never would have been there. See those transforms we spent huge amounts of time discussing? Well, SKIP uses none of them, so they were a waste of time too. In fact, SKIP could just as well use some other packet type -- nothing in IPSP is of *any* use to SKIP. Thats why the language is there. Using SKIP inside IPSP is a kludge. If we really wanted to use SKIP, this wouldn't be the standard on top of which to build it. > However, if pursuing this issue is seen by the long term participants of the > IPng working group as counter-productive, then I will retire. I thought this > was supposed to be an open process. I believe the arguments have become repetitive at this point. Perry From ipsec-request@ans.net Wed Mar 15 08:57:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15117 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 14:21:02 -0500 Received: by interlock.ans.net id AA38304 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 14:13:45 -0500 Message-Id: <199503151913.AA38304@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 14:13:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 14:13:45 -0500 Date: Wed, 15 Mar 95 13:57:32 EST From: hugo@watson.ibm.com To: karn@qualcomm.com Cc: IPSEC@ans.net Subject: A Photuris variant Phil, More on you your comments. > Re DH overhead, we've discussed this at length before and I don't > think anything has changed. DH just isn't that expensive, especially > if you use an exponent length that's appropriate to your symmetric > cipher. Furthermore, you do NOT have to re-execute DH everytime you Actually, you are one of the people that helped convincing me that DH is NOT that INexpensive. You were mentioning not so encouraging timings (several seconds), you talked about weak machines, and more significantly, you proposed the use of precomputed (and then replayable) signatures. The only reason to think about such precomputation (with its attached security weaknesses) is because of its performance benefits; if performance is not such big deal why to suggest doing that? BTW, using a short exponent is another compromise for performance. To the best of my knowledge, your claims about the known security of short exponents is correct (namely, the best known attack based on the length k of the exponent is 2^{k/2}). However, this can eventually change. Do you know of Wiener's result on RSA short exponents? He shows a non-trivial atttack that works much better than the above expression for exponents of length up to 1/4 of the modulus. This attack does not seem to generalize to DH, but there was no reason to believe on non-trivial weaknesses of short RSA exponents before Wiener's work. Well, I am NOT trying to say that using relatively short exponents must be prohibited. I am only trying to point out that the cost of thiee operations is significant enough to encourage people going to these shortcuts. My proposal (which does not exclude the use of short DH exponents) tries to give clear trade-offs of computation and well-understood security. It is a reality that many people believe they do not need DH everywhere, and even for me, a security-exigent, it is reasonable that some scenarios do not require it. > establish a new session key. My current plan is to generate session > keys by MD5 hashing the DH secret, the SAID and the cookies. So after > a given host pair has done DH once, they can create as many new > uniquely-keyed SAIDs as they need for only one MD5 operation each. (Of > course, they'd always have the option of re-executing the DH exchange > at any time.) Doesn't this satisfy your desire for a quick way to > rekey your weak symmetric ciphers? This is an important issue. Whatever is your public-key based way of sharing keys, a secure and efficient (MD5-like complexity) mechanism for re-keying is required. There are several ways to do it. I'd like to hear exact details on how you propose to do it. In the meantime, my preferred method is the one we propose in our MKMP draft. Discussions on this last issue can be carried independently of discussions/decisions on the PK-based key management (it can, and should, be independent) Hugo From ipsec-request@ans.net Wed Mar 15 19:50:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23028 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 15:13:35 -0500 Received: by interlock.ans.net id AA28201 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 15:07:53 -0500 Message-Id: <199503152007.AA28201@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 15:07:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 15:07:53 -0500 Date: Wed, 15 Mar 95 19:50:30 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security Please retire. Open is not the same as Never Give Up. You have yet to submit a draft, as repeatedly requested by at least 6 members of 2 WGs. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 15 19:50:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25817 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 16:21:10 -0500 Message-Id: <199503152121.AA25817@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Wed, 15 Mar 1995 16:18:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 16:18:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 16:18:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 15 Mar 1995 16:18:23 -0500 Date: Wed, 15 Mar 95 19:50:30 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security Please retire. Open is not the same as Never Give Up. You have yet to submit a draft, as repeatedly requested by at least 6 members of 2 WGs. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Wed Mar 15 22:02:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12744 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 17:12:38 -0500 Received: by interlock.ans.net id AA15456 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 16:58:16 -0500 Message-Id: <199503152158.AA15456@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 16:58:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 16:58:16 -0500 Date: Wed, 15 Mar 1995 14:02:54 -0800 From: Phil Karn To: Danny.Nessett@eng.sun.com Cc: ipng@sunroof.eng.sun.com, ipsec@ans.net In-Reply-To: <199503141714.AA44760@interlock.ans.net> (Danny.Nessett@Eng.Sun.COM) Subject: Re: Proposed message on perfect forward security Reply-To: karn@qualcomm.com >I gather from your wording that you mean "prove" in the market acceptance >sense (i.e., products using key distribution mechanisms providing perfect >forward security will be widely used), rather than the mathematical or >formal logic sense. If so, then I think we agree. My arguments are not Yes. Market acceptance is the final test. Nothing the IETF does can force the market to adopt or use anything; this is the OSI lesson. My own belief is that a single, general purpose key management protocol designed for the most demanding case will be much more widely adopted by the market than a collection of incompatible protocols with different levels of security that are each supposedly epsilon more efficient in some particular circumstance. Again, consider TCP vs TP[0-4]. Phil From ipsec-request@ans.net Wed Mar 15 21:12:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21652 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 17:36:28 -0500 Received: by interlock.ans.net id AA17183 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 17:13:47 -0500 Message-Id: <199503152213.AA17183@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 15 Mar 1995 17:13:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 17:13:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 17:13:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 17:13:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 17:13:47 -0500 To: ipsec@ans.net Subject: Re: (IPng) More Endpoint Attributes In-Reply-To: Your message of "Wed, 15 Mar 95 15:07:16 EST." <9503152007.AA05154@snark.imsi.com> Date: Wed, 15 Mar 95 16:12:07 -0500 From: Andy Bayerl X-Mts: smtp Perry Metzger writes: Please do not confuse a Security Association with an SAID. Security Associations can have all sorts of arbitrary properties associated with them by a key management protocol. An SAID is NOT the same as an SA -- it is just an index into a table of SAs. The index is not the map which is not the territory. But that still means that a given transaction carries only a single SAID which addresses a specific SA. In the MLS CMW world, any or all of the attributes associates with one or both ends of a connections may modulate. This means that we need a SAID for all the attribute combinations that are used during a session. For example, in our (DEC MLS) world using trusted X-windows, the process privilege set may modulate at a fairly high frequency. In addition Information Labels may float based upon the data accessed and visible in a window at any given time. Now for any given session there may not be a *lot* of different privileges and/or information labels, but we still would need a SAID to represent each combination used and the total number is multiplicative as we add more users with different privileges, more sensitivity levels, etc. For example, if a user at say "top secret" references unclassified, secret and top secret information and the perhaps 2 privilege combinations are used, then we would end up needing 6 SAID's at the end points. If we had 10 users who could login at even 2 sensitivity levels and access that same information, we need 20 times that number of SAID's. It quickly gets out of hand. In the TSIG TSIX model, the attributes are carried as 32-bit tokens (similar in this case to SAID's but not necessarily the same) in a header that inserted and removed between the user application layer and the protocol layer. If a given attribute changes, then only that token is sent. The number of tokens needed in this case is additive and we only need 2+3+2+20=27. In an IPv4 world, putting the attributes in the data stream was the only viable approach, since there is not enough room in the IP header for the full set of attributes and sending a single id to represent a combination attributes gets back to the multiplicative problem above. Now, in an IPv6 world the same approach of putting the attributes in the data stream could still be taken and would work just as well. But it is by no means an ideal approach and given the capabilities built into IPv6 it would certainly seem reasonable to think about including the attributes in either the authentication header, an ESP header, perhaps in a separate well-defined header in its own right. Or, heaven-forbid, using a reserved SAID to indicate in-line attributes. (I am fully prepared, in light of the recent ipsec diatribes, for the flames to descend up my head for having said that, but I did need to say it :-) /andy From ipsec-request@ans.net Wed Mar 15 23:04:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04175 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 18:23:31 -0500 Received: by interlock.ans.net id AA20321 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 18:09:21 -0500 Message-Id: <199503152309.AA20321@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 15 Mar 1995 18:09:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 18:09:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 18:09:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 18:09:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 18:09:21 -0500 Date: Wed, 15 Mar 1995 15:04:48 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: tytso@MIT.EDU Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: hinden@servo.ipsilon.com, ipng@sunroof.eng.sun.com, ipsec@ans.net X-Sun-Charset: US-ASCII > But if we are where we think we are, I believe all we need to > do at this point is to make sure that the current proposal do not rule > out the use of in-band keying as an optional key management protocol. This is all I've been asking for since the beginning. > And, I believe this is the case already. > I don't agree. Ran has stated that he will clarify the text of the security architecture document so that it is clear the "reserved" SAIDs can be allocated by the IANA for key management purposes. Fine. That removes one impediment. However, the draft still says the architecture is not intended for in-band keying. Once the I-Ds become Proposed Standards, implementors will read them without the benefit of the email that has appeared on the IPng and IPsec lists. If I was going to implement according to the existing I-Ds I would read the section deprecating the use of in-band keying to mean the AH and ESP headers should not be used for that purpose. Dan From ipsec-request@ans.net Wed Mar 15 12:50:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06758 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 18:24:39 -0500 Received: by interlock.ans.net id AA15845 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 18:18:06 -0500 Message-Id: <199503152318.AA15845@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 18:18:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 18:18:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 18:18:06 -0500 Date: Wed, 15 Mar 1995 17:50:00 +0500 From: Theodore Ts'o To: Danny.Nessett@eng.sun.com Cc: hinden@servo.ipsilon.com, ipng@sunroof.eng.sun.com, ipsec@ans.net In-Reply-To: Dan Nessett's message of Wed, 15 Mar 1995 10:04:10 -0800, <199503151809.AA29812@interlock.ans.net> Subject: Re: (IPng) Re: Proposed message on perfect forward security Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 2667 Date: Wed, 15 Mar 1995 10:04:10 -0800 From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) However, if pursuing this issue is seen by the long term participants of the IPng working group as counter-productive, then I will retire. I thought this was supposed to be an open process. Dan, Let me be frank. My impression is that your company has a proprietary product which uses in-band keying, and so you are naturally trying to push to make sure there is a place for your company's product in the standard. Thus, you don't like the fact that the IPng specifications currently say that architecture is not intended for use in using in-band keying. I think it is fair to say that we should not rule out systems that use in-band keying. However, it is also fair to say that in the interests of interoperability, we do need to pick a basic method of doing key exchange, that everyone will support. My reading of the IPng specifications is that they mandate a particular architecture for use as the basic, commonly implemented key exchange --- and the architectural direction, which has already been determined, will be using out-of-band keying scheme. The details of that still need to be worked out, of course, but at some point you have to make certain basic architectural decisions, and then move forward. Otherwise, we will end up making no progress at all. My understanding is that the common, required implementation of key-exchange which everyone must implement in the interest of interoperability, has been decided, via an open process, to use out-of-band keying. With this decision already made, unless there are some extreme, extenuating circumstances which would call for us to revisit that decision, I would think that it would be counter-productive for people to continually be insisting that this decision be re-opened, and re-examined, over and over again, ad naseum. Now, my understanding of where we are in the process may be different from what other's people understanding have been --- especially since I haven't been all that active in the IPng discussions. So, I invite people to correct my understanding of where we are in the process. But if we are where we think we are, I believe all we need to do at this point is to make sure that the current proposal do not rule out the use of in-band keying as an optional key management protocol. And, I believe this is the case already. Perhaps some of the flailing that we've had on these lists has had to do with different understandings of where we are in this process. Hopefully if we can clear this up, we can move forward and actually get some real work done. - Ted From ipsec-request@ans.net Wed Mar 15 23:44:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17755 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 18:57:27 -0500 Received: by interlock.ans.net id AA17748 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 18:40:16 -0500 Message-Id: <199503152340.AA17748@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 18:40:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 18:40:16 -0500 Date: Wed, 15 Mar 1995 15:44:27 -0800 From: Phil Karn To: paulv@bnr.ca Cc: ipsec@ans.net In-Reply-To: <199503142309.AA06850@interlock.ans.net> (message from Phil Karn on Tue, 14 Mar 1995 15:13:46 -0800) Subject: Re: Comments from Paul Van Oorschot Reply-To: karn@qualcomm.com Paul, Many thanks for your comments. Here are a few in response: >1. (section 1) The first discussion of "perfect forward secrecy" I > am aware of is by Gunther in his Eurocrypt'89 paper, > ``An identity-based key exchange protocol", pp.29-37, > though it is possible this term was defined earlier. > BTW, this paper is quite relevant background reading. Thanks for the citation. I'll try to find it. >2. (section 3.3, Cookie Generation) If I understand correctly, it appears > the cookie party A creates to use with party B is time-invariant. > Does this imply that if B is a malicious party, then any party A which > ever gives to B a cookie is subject to a flooding attack by B? > If so, it would seem prudent to recommend cookies be time-variant. The cookie exchange is designed to stop flooding only by parties using false IP source addresses to which they cannot see reply traffic. (Recent events on the Internet show that IP address spoofing actually happens.) I don't see any way to stop intentional flooding by a remote party using its own IP address without either requiring that party to share, a priori, a secret with the local IPSP entity (e.g., a MD5 hash key) or by restricting access to certain remote IP addresses. Both approaches run counter to my original design goals for Photuris; the first by requiring that the local IPSP entity keep (and protect!) a highly sensitive database of user secret keys, and the second by not allowing a user to go anywhere on the network. Photoris is designed to rely solely on the remote entity being able to prove possession of the secret key that corresponds to a public key in the local database that identifies an authorized user, regardless of where that user may go in the Internet. There *are* some ways that a site might react to a flooding when the attacker uses his own IP address, such as blocking packets from the offending IP address or by chasing down the perpetrator. Both are beyond the scope of the protocol. >3. (section 4.5, Moduli) It is only fair to list disadvantages > as well as advantages, of a fixed prime, including: > 1) a fixed prime is a much more rewarding cryptanalytic target > 2) the security of the whole system rests on this prime being good > 3) changing this prime may lead to difficulties Valid concerns. I've had to rely on those who understand the discrete log problem far better than I. So far the consensus seems to be that there's no problem with a fixed prime as long as it's sufficiently large and is "strong" (both p and (p-1)/2 are prime). This thwarts the precomputation step that seems to be the basis of most attacks on the discrete log problem. It's also not clear to me that generating ephemeral strong primes for Diffie Hellman moduli will be practical any time soon. My own code, which I modestly assert is pretty well optimized, takes the better part of an hour on average to generate a random 1024-bit strong prime on a 66 Mhz 486. So it seems better to just standardize a single well-chosen prime, or perhaps a small family of strong primes of different sizes, say 512 bits, 1024 bits and even 2048 bits. This also avoids the risk that the other party may accidentally or deliberately choose a weak modulus. >4. (section 5.1, Signature Transmission) The authenticated key exchange > protocol seems very similar to the the Station-to-Station (STS) > protocol described by Diffie, van Oorschot and Wiener > ("Authentication and authenticated key exchanges", > Designs, Codes and Cryptography vol.2 pp.107-125 (1992)), > including allowing identities to remain hidden from eavesdroppers, and > encrypting a subset of the protocol data messages exchanged themselves. > I have sent a hard copy of this paper to you by post today, > presuming you do not have access to it. Yes, I do not claim to have invented this particular technique. I believe I first heard something like it from Jim Bidzos in person. I look forward to receiving the paper. >5. I strongly recommend against signing only a single exponential. > Attacks are known against similar protocols which do so, and there > are general concerns (e.g. see pp.116-117 of STS paper). Signing both > exponentials provides entity authentication guarantees, which prevent > one class of replay attacks; signing only one does not, and in general > is vulnerable to a wide array of possible "interleaving" attacks. This has been a major topic of debate. I have since decided to follow your advice and sign the shared secret instead. >6. Due to the incredibly embarrassing track record of newly proposed > authentication and authenticated key exchange proposals, I hesitate > to support any brand new protocol, and recommend the group consider > choosing one (from the literature or elsewhere) which has already > been well-studied by a large number of experts, or which can be > proven to be cryptographically equivalent to such a protocol. I am not wedded to Photuris or any of its specific details, as long as any substitute meets all of the design goals I had in mind when I started. And I am most interested in the best peer review I can get. Thanks again for your comments, I found them helpful. Phil From ipsec-request@ans.net Wed Mar 15 14:00:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16307 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 19:03:04 -0500 Received: by interlock.ans.net id AA13268 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 19:01:02 -0500 Message-Id: <199503160001.AA13268@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 19:01:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 19:01:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 19:01:02 -0500 Date: Wed, 15 Mar 1995 19:00:47 +0500 From: Theodore Ts'o To: Danny.Nessett@eng.sun.com Cc: hinden@servo.ipsilon.com, ipng@sunroof.eng.sun.com, ipsec@ans.net In-Reply-To: Dan Nessett's message of Wed, 15 Mar 1995 15:04:48 -0800, <199503152304.PAA07201@elrond.Eng.Sun.COM> Subject: Re: (IPng) Re: Proposed message on perfect forward security Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 769 Date: Wed, 15 Mar 1995 15:04:48 -0800 From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) I don't agree. Ran has stated that he will clarify the text of the security architecture document so that it is clear the "reserved" SAIDs can be allocated by the IANA for key management purposes. Fine. That removes one impediment. However, the draft still says the architecture is not intended for in-band keying. Well, that suggests one possible compromise --- which is that draft is modified to remove the comment deprecating in-band keying, but also stating that the intention is that the expectation is that the base level key exchange method will be using an out-of-band key exchange method. Is this something that everyone can live with? - Ted From ipsec-request@ans.net Wed Mar 15 14:04:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20992 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 19:06:46 -0500 Received: by interlock.ans.net id AA18957 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 19:04:20 -0500 Message-Id: <199503160004.AA18957@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 19:04:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 19:04:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 19:04:20 -0500 Date: Wed, 15 Mar 1995 19:04:14 +0500 From: Theodore Ts'o To: Andy Bayerl Cc: ipsec@ans.net In-Reply-To: Andy Bayerl's message of Wed, 15 Mar 95 16:12:07 -0500, <199503152213.AA17183@interlock.ans.net> Subject: Re: (IPng) More Endpoint Attributes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1604 Date: Wed, 15 Mar 95 16:12:07 -0500 From: Andy Bayerl But that still means that a given transaction carries only a single SAID which addresses a specific SA. In the MLS CMW world, any or all of the attributes associates with one or both ends of a connections may modulate. This means that we need a SAID for all the attribute combinations that are used during a session. For example, in our (DEC MLS) world using trusted X-windows, the process privilege set may modulate at a fairly high frequency. In addition Information Labels may float based upon the data accessed and visible in a window at any given time. Now for any given session there may not be a *lot* of different privileges and/or information labels, but we still would need a SAID to represent each combination used and the total number is multiplicative as we add more users with different privileges, more sensitivity levels, etc. Andy, You seem to be making an assumption that you need a different SAID to represent a different SA every time the attributes associated with a SA changes (or "modulates", using your terminology). If it is only the attributes associated with an SA which are modulating, while the SA remains constant --- since a SA lasts the lifetime of a TCP connection --- why can't the SAID remain the same, since it is still the same Security Association. True, the process privilege set may be bouncing up and down, but if it's the same security association, it should be the same SAID. It's only the attributes which are changing. - Ted From ipsec-request@ans.net Wed Mar 15 13:50:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22850 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 19:19:02 -0500 Received: by interlock.ans.net id AA17850 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 19:14:42 -0500 Message-Id: <199503160014.AA17850@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 19:14:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 19:14:42 -0500 Date: Wed, 15 Mar 95 18:50:22 EST From: hugo@watson.ibm.com To: ashar@osmosys.incog.com, IPSEC@ans.net Subject: A Photuris variant Ref: Your note of Mon, 13 Mar 1995 17:03:10 -0800 (attached) Ashar, thanks for the comments (and I expect more) I agree with all what you say. You know how many concerns I have raised about freshness in other protocols. Believe me I am not going to overlook this in mine. I did not include these aspects in the first description from fear to obscure the main ideas. I tried to put in that note everything that explain these ideas, as well as everything that is computational intensive. The freshness mechanisms, as you pointed out, are easy to add and have negligible performance impact or system complexity cost. (Still, they are essential for security). Moreover, we are in complete agreement on the way to provide freshness when the share phase is skiped. Another aspect not covered in my note is what happens when only the SHARE phase is performed and the DH skipped. How do the parties test that they have shared a key (notice that the SHARE phase as described in my note does not give assurance to I that it talked to R, only that nobody except R can learn the key). This hand-shake requires again some cheap exchange based on MD5 kind of functions. I prefer to get more feedback on the basic approach before I get into the presentation of these (important) details. Hugo > I offer the following initial comments on your note. > > First, I observe that the freshness property of the protocol > is achieved in the "share" phase, where K0 will be fresh > when used with public-key encryption based share phase. > > However, you then suggest that the same protocol can be used with > other key sharing models which don't necessarily have a fresh > K0 e.g. manual key distribution, SKIP master keys etc. (Assuming > I properly understood the "Compatibility with Other Key Sharing > Models" section). > > When used with these other key-sharing models, the protocol > loses its freshness property, and therefore there is > nothing to prevent playbacks of {g^x, MAC_K0(g^x)}. This > is especially bad since the protocol does not require > the parties to prove that they can compute g^xy, so > the above can be played back even if the attacker > never learn's x. > > The fix to this problem appears to be simple. Include in the > MAC_K0 computation the other side's exponential in a direction > sensitive manner. Concretely, replace in the second > message (using the last compact description of your > proposal) MAC_K0(g^y) with MAC_K0(g^y, g^x) and in the > last message MAC_K0(g^x) with MAC_K0(g^x, g^y). Throwing in > the parties names in the MAC function (direction sensitive) > probably wouldn't hurt either. > > This incurs minimal additional overhead, as all you are > doing is computing the MAC over one extra exponential, while > allowing K0 to be in fact something long-lived (and not > per session). > > (If you do this, then this part of your proposal starts bearing > a lot of similarity to an extension of the basic SKIP proposal I am > in the process of drafting). > > Kind regards, > Ashar. From ipsec-request@ans.net Thu Mar 16 02:26:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06819 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 21:24:00 -0500 Received: by interlock.ans.net id AA21758 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 21:21:37 -0500 Message-Id: <199503160221.AA21758@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 21:21:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 21:21:37 -0500 Date: Wed, 15 Mar 1995 18:26:13 -0800 From: Phil Karn To: hugo@watson.ibm.com Cc: IPSEC@ans.net Reply-To: karn@qualcomm.com In-Reply-To: <199503151441.GAA21248@qualcomm.com> (hugo@watson.ibm.com) Subject: Re: A Photuris variant I am not asserting any patents on Photuris. My understanding is that there are none on the basic perfect forward secrecy scheme, but of course there are never any guarantees of anything when it comes to patents. >Now, if you are talking of an inititiator I that communicates to >a responder R, and I does not have a way to get R's public key before >the communication, then we have a problem. Yes, this is exactly my concern. Let's say I want to use somebody else's ethernet or a radio system (CDPD, CDMA) to access my home system while traveling. I assume I will get an arbitrary IP address on the serving network using DHCP or a manual method. This arbitrary IP address will not be known to my home system until I use it. It will also be meaningless to any local eavesdroppers watching my packets. So I'll have to identify myself to my home system. I want to do this in such a way that the local eavesdropper can't get it. Now I suppose I could do this first requesting a copy of my home system's public key, which that system freely gives to anyone who asks, and using it to encrypt my identity. This would work, but if the protocol is symmetric this would entail something like two RSA secret and public key operations on each end, one public/secret pair for the confidential exchange of public keys and a secret/public pair for the exchange of signatures to verify identity. This would be in addition to the DH step required to provide perfect forward secrecy. So I might as well do the DH step first and use the result to protect my identity with the same symmetric cipher I'm going to use to protect my actual traffic. Only one secret and one public RSA operation is now required on each end for signature generation and verification. And it has the added minor advantage of hiding *both* parties' public keys from eavesdropping, not just that of the mobile station. Phil From ipsec-request@ans.net Thu Mar 16 04:06:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21306 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 23:05:30 -0500 Received: by interlock.ans.net id AA17826 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 23:01:32 -0500 Message-Id: <199503160401.AA17826@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 23:01:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 23:01:32 -0500 Date: Wed, 15 Mar 1995 20:06:16 -0800 From: Phil Karn To: hugo@watson.ibm.com Cc: IPSEC@ans.net Reply-To: karn@qualcomm.com In-Reply-To: <199503151914.LAA03365@qualcomm.com> (hugo@watson.ibm.com) Subject: Re: A Photuris variant >This is an important issue. Whatever is your public-key based way >of sharing keys, a secure and efficient (MD5-like complexity) mechanism >for re-keying is required. There are several ways to do it. >I'd like to hear exact details on how you propose to do it. >In the meantime, my preferred method is the one we propose in our >MKMP draft. I propose that the session key be derived from the following: MD5 { local cookie, remote cookie, shared DH secret, SAID } Use as many bits as you need from the front of the hash result. E.g., for single-key DES, take the first 64 bits and overwrite every 8th bit to have the proper parity. For IDEA, just use the entire MD5 result as-is. The cookies are included mainly so that different keys are generated for each direction of transmission. They're handy enough. Including the SAID in the hash is how I generate distinct keys for each new SAID between a given host pair without requiring a new DH exchange each time. This does imply a new SAID everytime you rekey, which I consider reasonable given the size of the field. It also keeps the protocol simple. Creating a new SAID without a new DH computation doesn't necessarily require adding new message types, although it could be done that way. It could simply follow the same Photuris exchange, possibly with a new set of cookies if they are time-varying. In the DH step, though, the previous public values would be exchanged. The DH module in the implementation could compare the new values to the ones previously received. If they're the same, and if we haven't generated a new public value on our end, we'd simply bypass the DH exponentiation and keep the old shared secret. And since all of these Photuris messages could be easily sent encrypted in an existing SAID, you'd gain an extra measure against passive eavesdropping. An eavesdropper wouldn't even know that a new SAID had been created until he saw IPSP packets using it. Even then he wouldn't know its parameters (encryption algorithm, etc). Phil From ipsec-request@ans.net Thu Mar 16 04:09:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15192 (5.65c/IDA-1.4.4 for ); Wed, 15 Mar 1995 23:11:08 -0500 Received: by interlock.ans.net id AA03644 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 15 Mar 1995 23:09:57 -0500 Message-Id: <199503160409.AA03644@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 15 Mar 1995 23:09:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 15 Mar 1995 23:09:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 15 Mar 1995 23:09:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 15 Mar 1995 23:09:57 -0500 To: ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Wed, 15 Mar 1995 15:04:48 PST." <199503152304.PAA07201@elrond.Eng.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 15 Mar 1995 23:09:44 -0500 From: "Perry E. Metzger" I apologize for replying one last time to this. As a consolation to readers, let me note that its my last word on the subject. Dan Nessett says: > I don't agree. Ran has stated that he will clarify the text of the security > architecture document so that it is clear the "reserved" SAIDs can be > allocated by the IANA for key management purposes. Fine. That removes one > impediment. However, the draft still says the architecture is not intended > for in-band keying. And it is indeed not designed for SKIP style keying. (I refuse to say "in-band" by the way because it is an inaccurate term.) I see no purpose in removing a factual statement from the documents. Trying to make SKIP fit into IPSP is very unnatural. As I repeatedly note, SKIP neither uses SAIDs nor the defined IPSP transforms. It ends up using IPSP as an unreliable datagram protocol -- you might as well build it on top of UDP given the amount of IPSP functionality you make use of. You note that naive readers will think that the design wasn't intended for SKIP style systems -- but it *wasn't*, and I indeed want naive readers to understand how the design was intended to work. I strongly recommend against any removal of the stated text from the draft precisely because it will make the purpose of the features of IPSP less clear and reduce the ability of readers to understand the architecture. Thats all there is to say. From what I can tell, this has been beaten into the ground. I see no reason to discuss it further, and therefore I won't. You all know my position. Perry From ipsec-request@ans.net Thu Mar 16 05:27:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21970 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 00:47:25 -0500 Received: by interlock.ans.net id AA21611 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 00:44:27 -0500 Message-Id: <199503160544.AA21611@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 00:44:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 00:44:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 00:44:27 -0500 To: karn@qualcomm.com Cc: Danny.Nessett@eng.sun.com, ipng@sunroof.eng.sun.com, ipsec@ans.net Subject: Re: Proposed message on perfect forward security In-Reply-To: Your message of "Wed, 15 Mar 95 14:02:54 PST." <199503152158.AA15456@interlock.ans.net> Date: Thu, 16 Mar 95 00:27:48 -0500 From: bound@zk3.dec.com X-Mts: smtp Phil, >My own belief is that a single, general purpose key management >protocol designed for the most demanding case will be much more widely >adopted by the market than a collection of incompatible protocols with >different levels of security that are each supposedly epsilon more >efficient in some particular circumstance. Again, consider TCP vs >TP[0-4]. I think your right regarding the odds for market acceptance. My belief is that we still have a lot of work to do regarding key management in general. I think this will require discussion about our technical beliefs/assumptions where technology must or will be in the future, and what the market can absorb regarding function and cost. Often we say this is not a technical discussion but in fact it truly is and is often at the crux of disagreement. It also is a MUST before an engineer can fully buy-in to any specification. We have to discuss more than just the bits and bytes, to understand the affect of a technology on the total network system. Working on Ran's drafts for some time (SIP, SIPP, and now IPv6) I have reviewed it technically as to the affect to a host kernel as a network layer header and how the design will affect that part of the code base for IPv6 in a network operating system. Now that it may move to proposed standard we must look at it from the perspective of key management too. Until recently there was not a discussion on this topic in SIP, SIPP, or IPv6. I think IPSEC should do that work and I think its started. I do not think TCP vs TP[0-4] is a fair analysis to in-band vs out-band. TCP and TPxxx are two different protocol suites, two different AFs to a socket, and I believe two different philosophies towards the functions of a transport layer protocol. In-band is an option customers may want to use who do not need perfect forwarding security. Everything else about the ip6_input layer is the same, all that changes is the module that processes the IPv6 Security Header (at least in our implementation design). What is not clear to me is what will the out-band key management winner be? To do testing I am assuming we will have to agree to use some out-band method to test Ran's specs in the kernel and at the application layer too. It would be nice if we could get some folks like yourself to agree soon what is a good way for IPv6 implementors to test our implementations. What about kerberos? I think all can get code to do this? [just for interoperability testing]. /jim From ipsec-request@ans.net Thu Mar 16 05:38:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18441 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 00:55:24 -0500 Received: by interlock.ans.net id AA16333 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 00:53:50 -0500 Message-Id: <199503160553.AA16333@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 00:53:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 00:53:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 00:53:50 -0500 To: ipng@sunroof.eng.sun.com Cc: Danny.Nessett@eng.sun.com, hinden@servo.ipsilon.com, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Wed, 15 Mar 95 17:50:00 +0500." <9503152250.AA22347@dcl.MIT.EDU> Date: Thu, 16 Mar 95 00:38:40 -0500 From: bound@zk3.dec.com X-Mts: smtp Ted, >Date: Wed, 15 Mar 1995 17:50:00 +0500 >From: Theodore Ts'o > My understanding is that the common, required implementation of >key-exchange which everyone must implement in the interest of >interoperability, has been decided, via an open process, to use >out-of-band keying. With this decision already made, unless there are >some extreme, extenuating circumstances which would call for us to >revisit that decision, I would think that it would be counter-productive >for people to continually be insisting that this decision be re-opened, >and re-examined, over and over again, ad naseum. Besides the in-band/out-band discussion. We have input to Ran regarding other parts of the specifications from Phil Rogaway, Dean Throop, and Andy Bayerl that will affect the specification, I would like to see responses to that input publicly as the questions and input were relative as to whether the specs are ready for proposed standard before Danvers. I have not decided in my mind if they may cause a change to the architecture, which Ran needs to give us his view of that set of input. Whether it affects keying I am not sure, but I think not? I do not think its counter-productive to implement the specs as they exist today, and because of interoperability testing, cause a change if necessary to the architecture or to the method or methods that can be implemented for customers who want to use IPv6 Security. /jim From ipsec-request@ans.net Thu Mar 16 05:44:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24462 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 01:09:03 -0500 Received: by interlock.ans.net id AA07585 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 01:05:47 -0500 Message-Id: <199503160605.AA07585@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 01:05:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 01:05:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 01:05:47 -0500 To: ipng@sunroof.eng.sun.com Cc: Danny.Nessett@eng.sun.com, hinden@servo.ipsilon.com, ipsec@ans.net Subject: Re: (IPng) Re: Proposed message on perfect forward security In-Reply-To: Your message of "Wed, 15 Mar 95 19:00:47 +0500." <9503160000.AA22457@dcl.MIT.EDU> Date: Thu, 16 Mar 95 00:44:34 -0500 From: bound@zk3.dec.com X-Mts: smtp Ted, >Date: Wed, 15 Mar 1995 19:00:47 +0500 >From: Theodore Ts'o >Well, that suggests one possible compromise --- which is that draft is >modified to remove the comment deprecating in-band keying, but also >stating that the intention is that the expectation is that the base >level key exchange method will be using an out-of-band key exchange >method. >Is this something that everyone can live with? Yes regarding the subject/topic of keying in the specs. This states the base key exchange method and does not mention others that may develop. This will let competition exist which IMHO is OK for any proposed standard evolution, and in fact good. /jim From ipsec-request@ans.net Thu Mar 16 13:10:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16274 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 08:18:21 -0500 Received: by interlock.ans.net id AA17386 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 08:10:52 -0500 Message-Id: <199503161310.AA17386@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 08:10:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 08:10:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 08:10:52 -0500 Date: Thu, 16 Mar 1995 08:10:42 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) To: ipsec@ans.net Subject: Re: (IPng) More Endpoint Attributes Cc: tytso@MIT.EDU > From: Theodore Ts'o > Cc: ipsec@ans.net > Subject: Re: (IPng) More Endpoint Attributes ... > You seem to be making an assumption that you need a different > SAID to represent a different SA every time the attributes associated > with a SA changes (or "modulates", using your terminology). > > If it is only the attributes associated with an SA which are > modulating, while the SA remains constant --- since a SA lasts the > lifetime of a TCP connection --- why can't the SAID remain the same, > since it is still the same Security Association. True, the process > privilege set may be bouncing up and down, but if it's the same security > association, it should be the same SAID. It's only the attributes which > are changing. This is a very good issue. As you said, "the process privilege set maybe bouncing up and down". When the receiver reads data, it may want to know if the data was sent when the privilege set was up or if it was down. If the data was a request, the response to the request may very well depend on what prvileges were in effect when the request was sent. For example an X-server may look at the privileges in effect when when an X_GRAB request was sent to determine if the client is acting as a privileged entity to get data to scale a display or if the client is acting upon a request from the user who maybe trying to use the X-server as way to bypass system policy. The only way to tell the receiver if the privileges were up or down when the data was sent is to include that information along with the data in the packet. In otherwords the privileges must be tied with the data. It isn't possible to send the privileges using a separate protocol because there isn't any way to mark in the data stream when a privilege change occured. The only thing in the current draft that can be varied to convey a change in privilege is the SAID. It appears the current architcture views SAIDs as statically assigned things that persist for the life of the connection or longer. If a SAID is the only thing available to modulate when the privilege state (or other attributes) modulates, we'll have to modulate it. Unfortunately modulatings SAIDs doesn't look like it will work very well. Probably a better idea would be add some additional fields that can be modulated as attributes modulate. Adding an optional sequence of type-value pairs after the AH header would give something to modulate while holding the SAID constant. A SAID definition can specify what types should be included with the each packet. Many SAIDs may not include any additional type-value pairs. Some may include many. Some may only include a type-value pair when something changes. Types probably should be 16-bits and values can be 32 bits (48 might work better). Take 10 bits of the reserved field in the AH header and make it a count of the number of type-value pairs included in the header. Then add that many 16-bit type and 48-bit value pairs after the fixed length header. Dean Throop throop@dg-rtp.dg.com From ipsec-request@ans.net Thu Mar 16 06:33:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23323 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 11:42:34 -0500 Received: by interlock.ans.net id AA25957 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 11:33:20 -0500 Message-Id: <199503161633.AA25957@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 11:33:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 11:33:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 11:33:20 -0500 Date: Thu, 16 Mar 1995 11:33:06 +0500 From: Theodore Ts'o To: throop@dg-rtp.dg.com Cc: ipsec@ans.net In-Reply-To: Dean D. Throop's message of Thu, 16 Mar 1995 08:10:42 -0500, <199503161310.AA17386@interlock.ans.net> Subject: Re: (IPng) More Endpoint Attributes Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 877 Date: Thu, 16 Mar 1995 08:10:42 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) Probably a better idea would be add some additional fields that can be modulated as attributes modulate. Adding an optional sequence of type-value pairs after the AH header would give something to modulate while holding the SAID constant. ... and indeed I believe that's the way the architecture was designed to deal with this. You basically use the IP Security Option for IPv4, and I believe that IPv6 was going to a similar option similar to IPSO to handle this. In any case, it certainly seems clear, as we have both observed, that trying to encode this information in the SAID is the wrong place to do this. (I believe the right place is in the IPv4 or IPv6 options field, ala IPSO.) In any case, this palces this functionality out of scope of IPSEC. - Ted From ipsec-request@ans.net Thu Mar 16 17:10:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17238 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 12:18:06 -0500 Received: by interlock.ans.net id AA28026 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 12:09:49 -0500 Message-Id: <199503161709.AA28026@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 16 Mar 1995 12:09:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 12:09:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 12:09:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 12:09:49 -0500 Date: Thu, 16 Mar 1995 12:10 -0500 (EST) From: Dean.Jagels@sciatl.com Subject: Re[2]: (IPng) More Endpoint Attributes To: bayerl@zk3.dec.com Cc: ipsec@ans.net Mime-Version: 1.0 Content-Type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT Date: Wed, 15 Mar 95 16:12:07 -0500 From: Andy Bayerl But that still means that a given transaction carries only a single SAID which addresses a specific SA. In the MLS CMW world, any or all of the attributes associates with one or both ends of a connections may modulate. This means that we need a SAID for all the attribute combinations that are used during a session. For example, in our (DEC MLS) world using trusted X-windows, the process privilege set may modulate at a fairly high frequency. In addition Information Labels may float based upon the data accessed and visible in a window at any given time. Now for any given session there may not be a *lot* of different privileges and/or information labels, but we still would need a SAID to represent each combination used and the total number is multiplicative as we add more users with different privileges, more sensitivity levels, etc. I'm sorry. I think that I missed why we're considering privileges or information labels as attributes that should be carried in an IP-level header. I see them both as data that are unnecessary for IP to do its work. They should be carried by a higher-level protocol. As far as I can tell, only sensitivity labels would be useful in an IP-level header. On first consideration, I don't feel at all uncomfortable with a different SAID for different sensitivity labels. Dean Jagels Scientific Atlanta Dean.Jagels@sciatl.com From ipsec-request@ans.net Thu Mar 16 17:34:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17254 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 13:46:07 -0500 Received: by interlock.ans.net id AA24166 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 12:38:09 -0500 Message-Id: <199503161738.AA24166@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 12:38:09 -0500 To: Theodore Ts'o Cc: Andy Bayerl , ipsec@ans.net Subject: Re: (IPng) More Endpoint Attributes In-Reply-To: Your message of Wed, 15 Mar 95 19:04:14 +0500. <199503160004.AA18957@interlock.ans.net> Date: Thu, 16 Mar 95 12:34:45 -0500 From: Steve Kent In the context of security labels, e.g., in an MLS environment, other network layer security protocols have tended to allow a security association to be labelled either implicity, at one level for its duration, or have provided explicit, per-packet, security labels. I think we discussed this earlier for IPSP and decided that implicit, per-session labeling was most generally useful for the intended IPSP audience. However, if there is a strong interest in the need for more dynamic, per-packet attribute labeling, then some form of option to carry those attributes might make sense. Steve From ipsec-request@ans.net Thu Mar 16 18:24:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27499 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 13:46:55 -0500 Received: by interlock.ans.net id AA35554 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 13:12:23 -0500 Message-Id: <199503161812.AA35554@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 16 Mar 1995 13:12:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 13:12:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 13:12:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 13:12:23 -0500 Date: Thu, 16 Mar 1995 10:24:24 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipng@sunroof.eng.sun.com Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From: "Theodore Ts'o" > Well, that suggests one possible compromise --- which is that draft is > modified to remove the comment deprecating in-band keying, but also > stating that the intention is that the expectation is that the base > level key exchange method will be using an out-of-band key exchange > method. > > Is this something that everyone can live with? Ted, In the interest of bringing this unfortunately long debate to an end, I will say "Yes". Not that this solution is ideal from my perspective, but that it appears to be better than the current situation. I believe that the correct way to resolve this issue is to actually build and deploy security/key-mgmt in the extremely diverse environments/applications possible in the Internet, and therefore to the extent that this permits experimentation with alternative approaches, I am for it. Ultimately, as we have all agreed, the market will decide the approach it prefers. Thanks, BTW for making a compromise proposal. Kind regards, Ashar. From ipsec-request@ans.net Thu Mar 16 18:07:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22896 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 13:47:43 -0500 Received: by interlock.ans.net id AA23000 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 13:11:29 -0500 Message-Id: <199503161811.AA23000@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 16 Mar 1995 13:11:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 16 Mar 1995 13:11:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 13:11:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 13:11:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 13:11:29 -0500 To: ipsec@ans.net Subject: Re: (IPng) More Endpoint Attributes In-Reply-To: Your message of "Thu, 16 Mar 95 11:33:06 +0500." <199503161633.AA25957@interlock.ans.net> Date: Thu, 16 Mar 95 13:07:38 -0500 From: Andy Bayerl X-Mts: smtp Ted writes: ... and indeed I believe that's the way the architecture was designed to deal with this. You basically use the IP Security Option for IPv4, and I believe that IPv6 was going to a similar option similar to IPSO to handle this. In which document would this be discussed? Ran's overview and AUTH specs talk more about using the SAID to carry the IP sensitivity label information, unless I misread that. There is no mention made of using IPv4 options for that purpose. In any case, it certainly seems clear, as we have both observed, that trying to encode this information in the SAID is the wrong place to do this. (I believe the right place is in the IPv4 or IPv6 options field, ala IPSO.) In any case, this palces this functionality out of scope of IPSEC. The IPSO options only solve part of the problem. Basically, they are only useful handling the sensitivity label at the network level. Here the label is used for deciding whether to allow data into or out of a given host or router and for making routing decision. They have been used in the past to a limited extent to allow for modulating the sensitivity label at session level, but only because there are MLS vendors who do not support TSIX (or some earlier MaxSix variants). And in both of these case the IPSO option (and the TSIG CIPSO option) are limited to the extent that IPv4 option space is limited. That is, they only work if the MLS compartments can be squeezed into the available space. For IPSO that imposing an absolute ceiling of ~200 compartments (in our product we limit it to 16 byte or 128 compartments). The TSIG CIPSO has variants which in effect allow for compression to occur and may allow for more compartment combinations to work, but it also has limitations. But in any event, both of these only handle the sensitivity level. We would need to define another variant that provides something similar to what Dean suggested. This is certainly feasible, if this ability of using IPv4 options (or variants) is available to us. From ipsec-request@ans.net Thu Mar 16 18:55:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16333 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 13:59:59 -0500 Received: by interlock.ans.net id AA39991 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 13:55:14 -0500 Message-Id: <199503161855.AA39991@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 13:55:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 13:55:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 13:55:14 -0500 Date: Thu, 16 Mar 1995 13:55:06 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) To: tytso@MIT.EDU Subject: Re: (IPng) More Endpoint Attributes Cc: ipsec@ans.net > From: Theodore Ts'o ... > In any case, it certainly seems clear, as we have both observed, that > trying to encode this information in the SAID is the wrong place to do > this. (I believe the right place is in the IPv4 or IPv6 options field, > ala IPSO.) In any case, this palces this functionality out of scope of > IPSEC. Given what little time I've thought on this I generally agree. Encoding end-to-end attributes as options of some header contained within the authentication header makes sense. Indeed encrypting those options might be desirable. However such options can not be used to make routing decisions. I guess a 32-bit SAID probably provides as much rope as routers will be able to handle for the next few years. Making all routing security decision based on SAID might give less flexable routing than comes with IPSO/RIPSO/CIPSO but this is due to making it more abstract. The abstraction means off the self routers could handle it. Clearly the abstract is better in this case. I hope that encoding endpoint attributes as inner protocol options doesn't mean we have to replicate the option definitions for UDP, TCP, and every other protocol we ever define. I'd like to see some of this reflected in the architecture document. It may be there by inference but it should be explicitly stated that endpoint attributes should be carried as options of headers within the AH payload using a not yet specified mechanism. I'd really like to see how this all fits together with a key management protocol, an endpoint security attribute negotiation/translation protocol, an endpoint security attribute option specification, and a policy routing mechanism. Dean Throop throop@dg-rtp.dg.com From ipsec-request@ans.net Thu Mar 16 08:42:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27599 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 13:59:59 -0500 Received: by interlock.ans.net id AA39778 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 13:57:11 -0500 Message-Id: <199503161857.AA39778@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 13:57:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 13:57:11 -0500 Date: Thu, 16 Mar 95 13:42:34 EST From: hugo@watson.ibm.com To: karn@qualcomm.com Cc: IPSEC@ans.net Subject: A Photuris variant Ref: Your note of Wed, 15 Mar 1995 18:26:13 -0800 (attached) > So I'll have to identify myself to my home system. I want to do this > in such a way that the local eavesdropper can't get it. > > Now I suppose I could do this first requesting a copy of my home > system's public key, which that system freely gives to anyone who > asks, and using it to encrypt my identity. This would work, but if the > protocol is symmetric this would entail something like two RSA secret > and public key operations on each end, one public/secret pair for the > confidential exchange of public keys and a secret/public pair for the > exchange of signatures to verify identity. This would be in > addition to the DH step required to provide perfect forward secrecy. > Phil, I am missing something here. Please be more explicit. Are you trying to communicate with the home's system or somebody behind that system (e.g., a particular user)? If the key exchange is done with the home's system then using my scheme you do not need two RSA (long) exponentiation on each end but just one. If it's a user "hidden" behing the home's system then you need to send his identity in the clear (e.g., IP address, user name) even if you first do a DH exchange. Notice that in many situations I (the initiator) discloses R's's identity. For example when requesting her public-key from a public directory (say, DNS). > So I might as well do the DH step first and use the result to protect > my identity with the same symmetric cipher I'm going to use to protect > my actual traffic. Only one secret and one public RSA operation is now > required on each end for signature generation and verification. And it > has the added minor advantage of hiding *both* parties' public keys > from eavesdropping, not just that of the mobile station. If really needed (I am still unconvinced) this can be done in my variant too. One just reverts the DH and SHARE phase. I wouldn't do that (as the default case) without a realistic common situation that calls for it. (Clearly, things can be built modular enough to allow switching the phases if needed. But I still see as the natural default the SHARE first and DH second). Hugo From ipsec-request@ans.net Thu Mar 16 19:56:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21853 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 14:57:43 -0500 Received: by interlock.ans.net id AA07580 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 14:43:52 -0500 Message-Id: <199503161943.AA07580@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 16 Mar 1995 14:43:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 14:43:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 14:43:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 14:43:52 -0500 Date: Thu, 16 Mar 1995 11:56:07 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: Re: Diffie's comments on Photuris X-Sun-Charset: US-ASCII >From: Phil Karn > > Thanks for forwarding that note from Whit. In thinking about it and > similar comments from you and others, I've tentatively decided to modify > Photuris to sign the shared secret. Phil, This is not what Paul and myself and Whit had suggested. The suggestion was to sign the two public exponentials, not the shared secret. This is what the Diffie-Van Oorschot-Wiener STS protocol does. As Paul has suggested, there is benefit in picking something well examined and analyzed from the literature. I don't see the benefit of signing the shared secret {g^xy} vs. signing the two public exponentials {g^x, g^y}. There is obviously no pre-computation advantage, as neither can be pre-computed. Also, although one might consider it a plus to be able to prove that a party is able to compute the session key, this proof is already provided in the STS protocol, since the signatures are encrypted/authenticated in the session key. So, there is no advantage in this regard as well. However, I do see some potential disadvantages. Consider the case of weak encryption used with strong authentication. In this case the signature of the shared secret can be recovered by breaking the weak encryption key, even though the strong authentication key may not be recoverable. We are now relying on the weaker of the two functions, the one-wayness of the signature hash or the Diffie-Hellman problem to protect the shared DH secret (which includes the authentication key). It is also important to observe, if only for academic purposes, that if we consider the case of identity-hash coupled with RSA signatures, then the shared DH secret is disclosed in the scenario described above because of the easy inversion of the identity function. Namely, weak encryption discloses the strong authentication key as well. Requiring strong encryption modules for products which may wish to do authentication-only is also a disadvantage. But the greater criticism is that this is not as well analyzed as the STS protocol. If we are going to modify the STS protocol, which I believe is a good basis for doing authenticated Diffie-Hellman, then there must be a clear system gain. Furthermore, it must be shown either through informal or formal argument that the changes do not adversely affect the security of the protocol. I will write, in a later message, what sort of changes I believe make sense, which provide clear system gains while not adversely affecting protocol security. This includes incorporation of some of the ideas presented by Hugo earlier. Kind Regards, Ashar. From ipsec-request@ans.net Thu Mar 16 18:35:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28002 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 14:57:45 -0500 Received: by interlock.ans.net id AA04357 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 14:37:40 -0500 Message-Id: <199503161937.AA04357@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 16 Mar 1995 14:37:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 16 Mar 1995 14:37:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 14:37:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 14:37:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 14:37:40 -0500 Date: Thu, 16 Mar 1995 10:35:44 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: tytso@MIT.EDU Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: hinden@servo.ipsilon.com, ipng@sunroof.eng.sun.com, ipsec@ans.net X-Sun-Charset: US-ASCII Ted, In the interests of getting this settled, I would accept the compromise. Dan > From tytso@MIT.EDU Wed Mar 15 16:01:12 1995 > To: Danny.Nessett@Eng > Cc: hinden@servo.ipsilon.com, ipng@sunroof.Eng.Sun.COM, ipsec@ans.net > Subject: Re: (IPng) Re: Proposed message on perfect forward security > Address: 1 Amherst St., Cambridge, MA 02139 > Phone: (617) 253-8091 > > Date: Wed, 15 Mar 1995 15:04:48 -0800 > From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) > > I don't agree. Ran has stated that he will clarify the text of the security > architecture document so that it is clear the "reserved" SAIDs can be > allocated by the IANA for key management purposes. Fine. That removes one > impediment. However, the draft still says the architecture is not intended > for in-band keying. > > Well, that suggests one possible compromise --- which is that draft is > modified to remove the comment deprecating in-band keying, but also > stating that the intention is that the expectation is that the base > level key exchange method will be using an out-of-band key exchange > method. > > Is this something that everyone can live with? > > - Ted > From ipsec-request@ans.net Thu Mar 16 19:23:51 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22412 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 15:02:58 -0500 Received: by interlock.ans.net id AA04868 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 14:57:44 -0500 Message-Id: <199503161957.AA04868@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 14:57:44 -0500 From: Ran Atkinson Date: Thu, 16 Mar 1995 14:23:51 -0500 In-Reply-To: Andy Bayerl "Re: (IPng) More Endpoint Attributes" (Mar 16, 13:07) References: <199503161811.AA23000@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: (IPng) More Endpoint Attributes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Andy, There is nothing to preclude the continued use of IPSO (etc.). IPSO is a standards-track IETF protocol, hence appropriate to cite. CIPSO is not a standards-track IETF protocol and the IETF CIPSO working group was recently formally disbanded for lack of visible effort in over a year. Hence CIPSO is not appropriate to cite. There is text about the need to authenticate explicit labelling information such as IPSO. There was general agreement fairly early on in the IPsec WG that explicit labels which lack cryptographic binding to their packet and lack cryptographic authentication mechanisms have serious security problems due to the lack of such authentication mechanisms. Fortunately, use of something like ESP or AH would address those specific security problems with explicit labelling. Similarly there is nothing to preclude the continued use of the (not currently publically documented) TSIG protocols. Again, those protocols would probably benefit greatly from the availability of cryptographic security mechanisms in the IP-layer that could be used to secure those TSIG protocols. I need to (and will) add text noting that explicit labels similar to IPSO could be added to IPv6 using either the IPv6 End-to-End Options Header or using the IPv6 Hop-by-Hop Options header. I will not attempt to write such specifications as they are outside the scope of my efforts. Because the TSIG specs are not in IETF standards-track RFCs, I do not plan to discuss them specifically or cite them. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Mar 16 17:34:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15581 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 15:06:35 -0500 Message-Id: <199503162006.AA15581@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Thu, 16 Mar 1995 15:04:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 15:04:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Thu, 16 Mar 1995 15:04:03 -0500 To: Theodore Ts'o Cc: Andy Bayerl , ipsec@ans.net Subject: Re: (IPng) More Endpoint Attributes In-Reply-To: Your message of Wed, 15 Mar 95 19:04:14 +0500. <199503160004.AA18957@interlock.ans.net> Date: Thu, 16 Mar 95 12:34:45 -0500 From: Steve Kent In the context of security labels, e.g., in an MLS environment, other network layer security protocols have tended to allow a security association to be labelled either implicity, at one level for its duration, or have provided explicit, per-packet, security labels. I think we discussed this earlier for IPSP and decided that implicit, per-session labeling was most generally useful for the intended IPSP audience. However, if there is a strong interest in the need for more dynamic, per-packet attribute labeling, then some form of option to carry those attributes might make sense. Steve From ipsec-request@ans.net Thu Mar 16 18:24:24 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18466 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 15:10:09 -0500 Message-Id: <199503162010.AA18466@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Thu, 16 Mar 1995 15:07:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 16 Mar 1995 15:07:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 15:07:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 15:07:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 15:07:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Thu, 16 Mar 1995 15:07:29 -0500 Date: Thu, 16 Mar 1995 10:24:24 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipng@sunroof.eng.sun.com Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net X-Sun-Charset: US-ASCII > From: "Theodore Ts'o" > Well, that suggests one possible compromise --- which is that draft is > modified to remove the comment deprecating in-band keying, but also > stating that the intention is that the expectation is that the base > level key exchange method will be using an out-of-band key exchange > method. > > Is this something that everyone can live with? Ted, In the interest of bringing this unfortunately long debate to an end, I will say "Yes". Not that this solution is ideal from my perspective, but that it appears to be better than the current situation. I believe that the correct way to resolve this issue is to actually build and deploy security/key-mgmt in the extremely diverse environments/applications possible in the Internet, and therefore to the extent that this permits experimentation with alternative approaches, I am for it. Ultimately, as we have all agreed, the market will decide the approach it prefers. Thanks, BTW for making a compromise proposal. Kind regards, Ashar. From ipsec-request@ans.net Thu Mar 16 18:07:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28096 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 15:40:01 -0500 Message-Id: <199503162040.AA28096@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Thu, 16 Mar 1995 15:37:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 16 Mar 1995 15:37:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 16 Mar 1995 15:37:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 15:37:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 15:37:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 15:37:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Thu, 16 Mar 1995 15:37:28 -0500 To: ipsec@ans.net Subject: Re: (IPng) More Endpoint Attributes In-Reply-To: Your message of "Thu, 16 Mar 95 11:33:06 +0500." <199503161633.AA25957@interlock.ans.net> Date: Thu, 16 Mar 95 13:07:38 -0500 From: Andy Bayerl X-Mts: smtp Ted writes: ... and indeed I believe that's the way the architecture was designed to deal with this. You basically use the IP Security Option for IPv4, and I believe that IPv6 was going to a similar option similar to IPSO to handle this. In which document would this be discussed? Ran's overview and AUTH specs talk more about using the SAID to carry the IP sensitivity label information, unless I misread that. There is no mention made of using IPv4 options for that purpose. In any case, it certainly seems clear, as we have both observed, that trying to encode this information in the SAID is the wrong place to do this. (I believe the right place is in the IPv4 or IPv6 options field, ala IPSO.) In any case, this palces this functionality out of scope of IPSEC. The IPSO options only solve part of the problem. Basically, they are only useful handling the sensitivity label at the network level. Here the label is used for deciding whether to allow data into or out of a given host or router and for making routing decision. They have been used in the past to a limited extent to allow for modulating the sensitivity label at session level, but only because there are MLS vendors who do not support TSIX (or some earlier MaxSix variants). And in both of these case the IPSO option (and the TSIG CIPSO option) are limited to the extent that IPv4 option space is limited. That is, they only work if the MLS compartments can be squeezed into the available space. For IPSO that imposing an absolute ceiling of ~200 compartments (in our product we limit it to 16 byte or 128 compartments). The TSIG CIPSO has variants which in effect allow for compression to occur and may allow for more compartment combinations to work, but it also has limitations. But in any event, both of these only handle the sensitivity level. We would need to define another variant that provides something similar to what Dean suggested. This is certainly feasible, if this ability of using IPv4 options (or variants) is available to us. From ipsec-request@ans.net Thu Mar 16 20:46:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24333 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 15:49:37 -0500 Received: by interlock.ans.net id AA25161 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 15:46:13 -0500 Message-Id: <199503162046.AA25161@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 15:46:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 15:46:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 15:46:13 -0500 Date: Thu, 16 Mar 1995 15:46:00 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) To: Dean.Jagels@sciatl.com Subject: Re[3]: (IPng) More Endpoint Attributes Cc: ipsec@ans.net, bayerl@zk3.dec.com > From: Dean.Jagels@Sciatl.COM > Subject: Re[2]: (IPng) More Endpoint Attributes > To: bayerl@zk3.dec.com ... > header. On first consideration, I don't feel at all uncomfortable > with a different SAID for different sensitivity labels. That was my first thought. However someone pointed out that maybe the MAC label should be encoded. If the MAC label is in plain text, that lets attackers concentrate their efforts on messages with the higher classification. The SAID would more correctly imply a range of MAC labels. Routers should restrict some SAIDs from some lines and thus restrict all data in that range from those lines. We may lose some routing flexability this way. A router might get a secret message with a SAID that means secret or top secret and not be able to send it on the secret line. However by abstracting all the MAC info into the SAID, off the shelf routers that know about SAIDs can be used. Dean Throop throop@dg-rtp.dg.com From ipsec-request@ans.net Thu Mar 16 18:55:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06860 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 16:02:44 -0500 Message-Id: <199503162102.AA06860@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Thu, 16 Mar 1995 16:00:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 16:00:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 16:00:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 16:00:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Thu, 16 Mar 1995 16:00:20 -0500 Date: Thu, 16 Mar 1995 13:55:06 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) To: tytso@MIT.EDU Subject: Re: (IPng) More Endpoint Attributes Cc: ipsec@ans.net > From: Theodore Ts'o ... > In any case, it certainly seems clear, as we have both observed, that > trying to encode this information in the SAID is the wrong place to do > this. (I believe the right place is in the IPv4 or IPv6 options field, > ala IPSO.) In any case, this palces this functionality out of scope of > IPSEC. Given what little time I've thought on this I generally agree. Encoding end-to-end attributes as options of some header contained within the authentication header makes sense. Indeed encrypting those options might be desirable. However such options can not be used to make routing decisions. I guess a 32-bit SAID probably provides as much rope as routers will be able to handle for the next few years. Making all routing security decision based on SAID might give less flexable routing than comes with IPSO/RIPSO/CIPSO but this is due to making it more abstract. The abstraction means off the self routers could handle it. Clearly the abstract is better in this case. I hope that encoding endpoint attributes as inner protocol options doesn't mean we have to replicate the option definitions for UDP, TCP, and every other protocol we ever define. I'd like to see some of this reflected in the architecture document. It may be there by inference but it should be explicitly stated that endpoint attributes should be carried as options of headers within the AH payload using a not yet specified mechanism. I'd really like to see how this all fits together with a key management protocol, an endpoint security attribute negotiation/translation protocol, an endpoint security attribute option specification, and a policy routing mechanism. Dean Throop throop@dg-rtp.dg.com From ipsec-request@ans.net Thu Mar 16 08:42:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21819 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 16:08:34 -0500 Message-Id: <199503162108.AA21819@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Thu, 16 Mar 1995 16:06:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 16:06:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 16:06:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Thu, 16 Mar 1995 16:06:14 -0500 Date: Thu, 16 Mar 95 13:42:34 EST From: hugo@watson.ibm.com To: karn@qualcomm.com Cc: IPSEC@ans.net Subject: A Photuris variant Ref: Your note of Wed, 15 Mar 1995 18:26:13 -0800 (attached) > So I'll have to identify myself to my home system. I want to do this > in such a way that the local eavesdropper can't get it. > > Now I suppose I could do this first requesting a copy of my home > system's public key, which that system freely gives to anyone who > asks, and using it to encrypt my identity. This would work, but if the > protocol is symmetric this would entail something like two RSA secret > and public key operations on each end, one public/secret pair for the > confidential exchange of public keys and a secret/public pair for the > exchange of signatures to verify identity. This would be in > addition to the DH step required to provide perfect forward secrecy. > Phil, I am missing something here. Please be more explicit. Are you trying to communicate with the home's system or somebody behind that system (e.g., a particular user)? If the key exchange is done with the home's system then using my scheme you do not need two RSA (long) exponentiation on each end but just one. If it's a user "hidden" behing the home's system then you need to send his identity in the clear (e.g., IP address, user name) even if you first do a DH exchange. Notice that in many situations I (the initiator) discloses R's's identity. For example when requesting her public-key from a public directory (say, DNS). > So I might as well do the DH step first and use the result to protect > my identity with the same symmetric cipher I'm going to use to protect > my actual traffic. Only one secret and one public RSA operation is now > required on each end for signature generation and verification. And it > has the added minor advantage of hiding *both* parties' public keys > from eavesdropping, not just that of the mobile station. If really needed (I am still unconvinced) this can be done in my variant too. One just reverts the DH and SHARE phase. I wouldn't do that (as the default case) without a realistic common situation that calls for it. (Clearly, things can be built modular enough to allow switching the phases if needed. But I still see as the natural default the SHARE first and DH second). Hugo From ipsec-request@ans.net Thu Mar 16 21:30:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14914 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 16:36:51 -0500 Received: by interlock.ans.net id AA16261 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 16:29:12 -0500 Message-Id: <199503162129.AA16261@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 16 Mar 1995 16:29:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 16 Mar 1995 16:29:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 16 Mar 1995 16:29:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 16 Mar 1995 16:29:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 16:29:12 -0500 To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net, barron@zk3.dec.com Subject: Re: (IPng) More Endpoint Attributes In-Reply-To: Your message of "Thu, 16 Mar 95 14:23:51 EST." <199503161957.AA04868@interlock.ans.net> Date: Thu, 16 Mar 95 16:30:40 -0500 From: Andy Bayerl X-Mts: smtp Ran writes: There is nothing to preclude the continued use of IPSO (etc.). IPSO is a standards-track IETF protocol, hence appropriate to cite. CIPSO is not a standards-track IETF protocol and the IETF CIPSO working group was recently formally disbanded for lack of visible effort in over a year. Hence CIPSO is not appropriate to cite. That is an issue to be taken up separately, somewhere, Maybe. There is text about the need to authenticate explicit labelling information such as IPSO. There was general agreement fairly early on in the IPsec WG that explicit labels which lack cryptographic binding to their packet and lack cryptographic authentication mechanisms have serious security problems due to the lack of such authentication mechanisms. Fortunately, use of something like ESP or AH would address those specific security problems with explicit labelling. Basically, you are saying that when the ESP or AH are present, the (C)IPSO options inherit the goodness of the authentication mechanisms, since they are part of the IP header stream covered by the ESP and/or the AH. Is that correct? Similarly there is nothing to preclude the continued use of the (not currently publically documented) TSIG protocols. Again, those protocols would probably benefit greatly from the availability of cryptographic security mechanisms in the IP-layer that could be used to secure those TSIG protocols. I agree. I need to (and will) add text noting that explicit labels similar to IPSO could be added to IPv6 using either the IPv6 End-to-End Options Header or using the IPv6 Hop-by-Hop Options header. I will not attempt to write such specifications as they are outside the scope of my efforts. That is also quite reasonable to expect. It would be our (i.e., TSIG as the coordinating body for MLS vendors) responsibility to write up the specifications and get them into the IETF standards-track RFCs (or not as the case may be). Because the TSIG specs are not in IETF standards-track RFCs, I do not plan to discuss them specifically or cite them. Ok. From ipsec-request@ans.net Thu Mar 16 21:35:38 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15205 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 16:40:07 -0500 Received: by interlock.ans.net id AA20510 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 16 Mar 1995 16:38:04 -0500 Message-Id: <199503162138.AA20510@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 16 Mar 1995 16:38:04 -0500 From: Ran Atkinson Date: Thu, 16 Mar 1995 16:35:38 -0500 In-Reply-To: Andy Bayerl "Re: (IPng) More Endpoint Attributes" (Mar 16, 16:21) References: <9503162121.AA02561@capecod.zk3.dec.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: (IPng) More Endpoint Attributes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil On Mar 16, 16:21, Andy Bayerl wrote: % Basically, you are saying that when the ESP or AH are present, the % (C)IPSO options inherit the goodness of the authentication mechanisms, % since they are part of the IP header stream covered by the ESP and/or % the AH. % % Is that correct? Andy, I'm not entirely comfortable with your wording, but I think that is the general thrust of what I've been trying to say. To put it another way, the ESP and AH mechanisms are designed to provide general-use cryptographic security to the IP-layer. Hence they could be used to provide cryptographic security to things in that layer and above that layer. I should note that one might use ESP to encrypt the TCP portion but not encrypt the IP portion. In that case, things below TCP would not be protected. {One can ubstitute other upper-layer protocols such as but not limited to UDP and ICMP for TCP in the above example}. In the other case, one might use ESP to encrypt an entire IP datagram. In that case, the entire encrypted IP datagram would be protected. AH can't protect IP-layer fields that must change during transit if their value at the destination cannot be predicted a priori. The usual example of a field that can't be protected is the IPv4 TTL or IPv6 Hop Limit (which are the same field really, but have different names in the two versions of IP :-). IPSO is not a field which should normally change in transit from source to destination. Am I being more clear now ? Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Mar 17 12:19:42 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16001 (5.65c/IDA-1.4.4 for ); Fri, 17 Mar 1995 07:52:32 -0500 Received: by interlock.ans.net id AA24663 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 17 Mar 1995 07:47:58 -0500 Message-Id: <199503171247.AA24663@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 17 Mar 1995 07:47:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 17 Mar 1995 07:47:58 -0500 Date: Fri, 17 Mar 95 12:19:42 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Routing > From: throop@dg-rtp.dg.com (Dean D. Throop) > We may lose some routing flexability this way. A router might get a > secret message with a SAID that means secret or top secret and not be > able to send it on the secret line. > There seems to be a very serious misconception about a SAID here. This may be because the term SAID is used in other contexts, and we should use another term for IPSec (I complained about this long ago). SAIDs are relative to the Destination. No intermediate router knows the meaning of the SAID. No router can use a SAID in its routing decisions. In the event that a Source wishes to specify a particular route for a packet to travel, it needs to use a Source Route, or another policy-based routing mechanism such as IDPR and Nimrod. Routing is outside the scope of this WG. > However by abstracting all the MAC > info into the SAID, off the shelf routers that know about SAIDs can be > used. > First, this is inapplicable, since routers don't need to know about SAIDs. Second, it would help if you used the terminology in the drafts. MAC is not a term used in this context. SAIDs will not encode Media Access Control information. (Yes, _I_ know you meant "Message Authentication Code", but that implies the _result_ of the hash, which is called "Authentication Data" in our drafts. Only the authentication _mechanism_ is indicated by our SAID.) You have _read_ the drafts, haven't you? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Fri Mar 17 14:16:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20454 (5.65c/IDA-1.4.4 for ); Fri, 17 Mar 1995 09:18:24 -0500 Received: by interlock.ans.net id AA17210 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 17 Mar 1995 09:15:09 -0500 Message-Id: <199503171415.AA17210@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 17 Mar 1995 09:15:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 17 Mar 1995 09:15:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 17 Mar 1995 09:15:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 17 Mar 1995 09:15:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 17 Mar 1995 09:15:09 -0500 To: "William Allen Simpson" Cc: ipsec@ans.net, barron@zk3.dec.com Subject: Re: Routing In-Reply-To: Your message of "Fri, 17 Mar 95 12:19:42 GMT." <199503171247.AA24663@interlock.ans.net> Date: Fri, 17 Mar 95 09:16:54 -0500 From: Andy Bayerl X-Mts: smtp Bill writes: Second, it would help if you used the terminology in the drafts. MAC is not a term used in this context. SAIDs will not encode Media Access Control information. (Yes, _I_ know you meant "Message Authentication Code", but that implies the _result_ of the hash, which is called "Authentication Data" in our drafts. Only the authentication _mechanism_ is indicated by our SAID.) I think Dean was using yet a 3rd meaning to MAC which is very familiar to the MLS CMW world, namely "Mandatory Access Control", which refers to using sensitivity labels to strictly control access to data. The security architecture document itself refers to *MAC* in that context: 5.5 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS A multi-level secure (MLS) network is one where a single network is used to communicate data at different sensitivity levels (e.g. Unclassified and Secret). Many governments have significant interest in MLS networking. [DIA] The IPv6 security mechanisms have been designed to support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC) which ordinary users are ^^^ incapable of controlling or violating. Mandatory Access Controls differ from Discretionary Access Controls in this respect. (You did _read_ the document, did you not? :-) There is a paragraph in there that I think may have Dean (and I also) to infer that the document implied overloading the SAID with *MAC* information. The Encapsulating Security Payload can be combined with appropriate key policies to provide full multi-level secure networking. In this case each key must be used only at a single sensitivity level and compartment. For example, Key "A" might be used only for sensitive Unclassified packets, while Key "B" is used only for Secret/No-compartments traffic, and Key "C" is used only for Secret/No-Foreign traffic. I (at least) had equated the *key* in this paragraph to the SAID. From Ran's comments on the subject and a closer rereading of the this section I believe I now understand it much more clearly in the sense that is strictly referring to the authentication strength of the key and is not in any way related to the *MAC* dominance rules of CMW sensitivity labels. /andy From ipsec-request@ans.net Fri Mar 17 14:20:51 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16124 (5.65c/IDA-1.4.4 for ); Fri, 17 Mar 1995 09:22:34 -0500 Received: by interlock.ans.net id AA17360 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 17 Mar 1995 09:21:06 -0500 Message-Id: <199503171421.AA17360@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 17 Mar 1995 09:21:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 17 Mar 1995 09:21:06 -0500 X-Sender: cfm@bugs.columbia.sparta.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Mar 1995 09:20:51 -0500 To: "William Allen Simpson" , ipsec@ans.net From: cfm@columbia.sparta.com (Carl F. Muckenhirn) Subject: Re: Routing At 7:19 AM 3/17/95, William Allen Simpson wrote: >> From: throop@dg-rtp.dg.com (Dean D. Throop) >> We may lose some routing flexability this way. A router might get a >> secret message with a SAID that means secret or top secret and not be >> able to send it on the secret line. >> >There seems to be a very serious misconception about a SAID here. This >may be because the term SAID is used in other contexts, and we should use >another term for IPSec (I complained about this long ago). > >SAIDs are relative to the Destination. No intermediate router knows the >meaning of the SAID. No router can use a SAID in its routing decisions. > Why not, if the security association exists between the router and another entity (isn't that the entire reason for encapsulation, to allow intermediate systems to encapsulate datagrams for protected transport across the net?), further postulate a multi-level secure router, attached to multiple red/plaintext side single-level nets. The router therefore needs to distinguish between messages of differing classifications, and as I've seen the SAID described he can encode it that way. (I'll point out that if you do this it is really broken, since the data (not the association) should be labeled. If one looks at classification as simply another QOS identifier, then the SAID can be assigned on the basis of (or included encoding for) a classification. All this being said, I don't see this as a routing problem, but one of security architecture and fuzzy thought. >In the event that a Source wishes to specify a particular route for a >packet to travel, it needs to use a Source Route, or another policy-based >routing mechanism such as IDPR and Nimrod. Routing is outside the scope >of this WG. No argument. > > >> However by abstracting all the MAC >> info into the SAID, off the shelf routers that know about SAIDs can be >> used. >> >First, this is inapplicable, since routers don't need to know about SAIDs. > >Second, it would help if you used the terminology in the drafts. MAC is >not a term used in this context. SAIDs will not encode Media Access >Control information. (Yes, _I_ know you meant "Message Authentication >Code", but that implies the _result_ of the hash, which is called >"Authentication Data" in our drafts. Only the authentication _mechanism_ >is indicated by our SAID.) I think MAC here means mandatory access control (classification or other rule-based discriminator). And if he thinks that off the shelf routers (presumably un-"trusted") will be allowed to provide MAC he needs to think about it again. > >You have _read_ the drafts, haven't you? > >Bill.Simpson@um.cc.umich.edu Most of them! carl. From ipsec-request@ans.net Fri Mar 17 14:55:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21083 (5.65c/IDA-1.4.4 for ); Fri, 17 Mar 1995 09:57:50 -0500 Received: by interlock.ans.net id AA30742 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 17 Mar 1995 09:54:12 -0500 Message-Id: <199503171454.AA30742@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 17 Mar 1995 09:54:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 17 Mar 1995 09:54:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 17 Mar 1995 09:54:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 17 Mar 1995 09:54:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 17 Mar 1995 09:54:12 -0500 To: cfm@columbia.sparta.com (Carl F. Muckenhirn) Cc: ipsec@ans.net, barron@zk3.dec.com Subject: Re: Routing In-Reply-To: Your message of "Fri, 17 Mar 95 09:20:51 EST." <199503171421.AA17360@interlock.ans.net> Date: Fri, 17 Mar 95 09:55:59 -0500 From: Andy Bayerl X-Mts: smtp Carl writes: I've seen the SAID described he can encode it that way. (I'll point out that if you do this it is really broken, since the data (not the association) should be labeled. I totally agree. This was the ultimate gist of what we finally resolved, at least until we can look into it more. Basically, given that we can use IP4 options (such as RFC1108 iPSO or TSIG MIL STD CIPSO) with strong authentication, we should have the means to make routing decisions at MLS trusted gateways *guarding* MLS networks. I think MAC here means mandatory access control (classification or other rule-based discriminator). And if he thinks that off the shelf routers (presumably un-"trusted") will be allowed to provide MAC he needs to think about it again. Off the shelf routers already provide MAC under IP4 in restricted environments. Cisco routers (and possibly other, I am not sure) implement at least some to the RFC1108 MAC capabilites (although I have found that they get in the way more than anything). There are now also *trusted* routers from Network Systems and Harris that provide the capability for TSIG CIPSO as well as RFC1108. And the Boeing A1 LAN product also does so. And most MLS CMW products can also act as routers, albeit expensive ones. /andy From ipsec-request@ans.net Fri Mar 17 04:58:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22556 (5.65c/IDA-1.4.4 for ); Fri, 17 Mar 1995 10:20:20 -0500 Received: by interlock.ans.net id AA19378 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 17 Mar 1995 10:15:41 -0500 Message-Id: <199503171515.AA19378@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 17 Mar 1995 10:15:41 -0500 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 17 Mar 1995 10:15:41 -0500 To: cfm@columbia.sparta.com (Carl F. Muckenhirn) Cc: "William Allen Simpson" , ipsec@ans.net Subject: Re: Routing Date: Fri, 17 Mar 95 09:58:54 EST Why not, if the security association exists between the router and another entity (isn't that the entire reason for encapsulation, to allow intermediate systems to encapsulate datagrams for protected transport across the net?), further postulate a multi-level secure router, attached to multiple red/plaintext side single-level nets. The router therefore needs to distinguish between messages of differing classifications, and as I've seen the SAID described he can encode it that way. (I'll point out that if you do this it is really broken, since the data (not the association) should be labeled. If one looks at classification as simply another QOS identifier, then the SAID can be assigned on the basis of (or included encoding for) a classification. All this being said, I don't see this as a routing problem, but one of security architecture and fuzzy thought. There are certainly many possible ways to implement a security architecture. It may be that the drafts are not clear. The intent of the current design is the SAID is strictly an endpoint concept, and is not known to intermediate hops. It manifestly is not a security label. I personally prefer the term ``key identifier'', from the SP3/SP4 drafts; it's much less confusing than OSIspeak. With the exception of the reserved values -- which are a concession to the need for other possible models of how to do things -- the SAID can be thought of as strictly a table index. The table itself supplies the cryptographic algorithm identifier, the current session key, the security level, the expiration time, and any host-specific information, such as userid. There is a missing architectural piece: some IPv6 header or hop-by-hop option to carry a security label. If ESP is deployed gateway-to-gateway or gateway-to-host, in a multilevel environment, there needs to be some way for the host and the encrypting gateway (which may or may not be a router) to communicate. The SAID was not intended for this purpose for a number of reasons. First, of course, it was intended primarily for use in non-MLS environments. A related point is that you can only believe encoded semantics if they arrive from a trustworthy source; most wires on today's Internet (and for that matter, most hosts) cannot be trusted in that fashion. Third, it's not, in my opinion, a good idea to label sensitive traffic; what better signal to an eavesdropper about what traffic to collect and try to (crypt)analyze? It's much better to keep that hidden inside the key management protocol. If, by some chance, you have a cipher system that is suitable for carrying Top Secret information, but only over Secret-rated lines -- well, as I said, there is a need for a label attribute somewhere. I've mentioned this in the past; I now suggest that someone from the affected communities should write a draft. --Steve Bellovin From ipsec-request@ans.net Fri Mar 17 15:16:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24353 (5.65c/IDA-1.4.4 for ); Fri, 17 Mar 1995 10:20:53 -0500 Received: by interlock.ans.net id AA16078 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 17 Mar 1995 10:17:58 -0500 Message-Id: <199503171517.AA16078@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 17 Mar 1995 10:17:58 -0500 To: "Dean D. Throop" Cc: Dean.Jagels@sciatl.com, ipsec@ans.net, bayerl@zk3.dec.com Subject: Re: Re[3]: (IPng) More Endpoint Attributes In-Reply-To: Your message of Thu, 16 Mar 95 15:46:00 -0500. <199503162046.AA25161@interlock.ans.net> Date: Fri, 17 Mar 95 10:16:43 -0500 From: Steve Kent Dean, I believe the SAID is meaningful only to the end points of the security association. If a router is acting as an endpoint, then it has the necessary labeling info from the association establishment procedure. If a router is not an endpoint, I would not expect it to have access to the mapping from SAID to sensitivity level. Perhaps I misunderstood your discussion about routers looking at SAIDs to make routing decisions based on sensitivity level. Steve From ipsec-request@ans.net Fri Mar 17 17:48:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12777 (5.65c/IDA-1.4.4 for ); Fri, 17 Mar 1995 13:02:51 -0500 Received: by interlock.ans.net id AA33746 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 17 Mar 1995 12:49:03 -0500 Message-Id: <199503171749.AA33746@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 17 Mar 1995 12:49:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 17 Mar 1995 12:49:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 17 Mar 1995 12:49:03 -0500 Date: Fri, 17 Mar 1995 12:48:43 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) To: kent@BBN.COM Subject: Re[5]: (IPng) More Endpoint Attributes Cc: ipsec@ans.net I'm getting confused here. I guess I don't understand the association model. The "IPv6 Security Architecture" in section 5.3 sez " The Security Association Identifiers (SAIDs) used in the IPv6 security mechanisms are receiver-oriented, making them well suited for use in IP multicast." I'm trying to figure out what to put in a packet to send it for some hypothetical example. Lets assume the first hop is a router that doesn't know anything about security; it just picks the packet up from this LAN and moves it to another LAN. The second hop is a security aware router and I guess it knows about the SAID and enforces whether the packet is allowed (or directs the path of the packet depending on the packet contents). Eventually the packet ends up at the other host I want to talk with. What is the receiver in this case? is it the local router that doesn't know about security, is the security knowledgeable router, or is it final destination? If the receiver is the intermediate security aware router, how does the sender figure out what SAID that receiver wants? I guess I'm assuming the IPv4 model where all the sender knows is the next hop. Maybe there are some IPv6 mechanisms I don't know about. > To: "Dean D. Throop" > Cc: Dean.Jagels@sciatl.com, ipsec@ans.net, bayerl@zk3.dec.com > Subject: Re: Re[3]: (IPng) More Endpoint Attributes > In-Reply-To: Your message of Thu, 16 Mar 95 15:46:00 -0500. > <199503162046.AA25161@interlock.ans.net> > Date: Fri, 17 Mar 95 10:16:43 -0500 > From: Steve Kent > Dean, > > I believe the SAID is meaningful only to the end points of the > security association. If a router is acting as an endpoint, then it > has the necessary labeling info from the association establishment > procedure. If a router is not an endpoint, I would not expect it to > have access to the mapping from SAID to sensitivity level. Perhaps > I misunderstood your discussion about routers looking at SAIDs to > make routing decisions based on sensitivity level. > > Steve > Dean Throop throop@dg-rtp.dg.com From ipsec-request@ans.net Fri Mar 17 17:48:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21668 (5.65c/IDA-1.4.4 for ); Fri, 17 Mar 1995 13:47:48 -0500 Message-Id: <199503171847.AA21668@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Fri, 17 Mar 1995 13:44:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 17 Mar 1995 13:44:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 17 Mar 1995 13:44:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 17 Mar 1995 13:44:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Fri, 17 Mar 1995 13:44:30 -0500 Date: Fri, 17 Mar 1995 12:48:43 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) To: kent@BBN.COM Subject: Re[5]: (IPng) More Endpoint Attributes Cc: ipsec@ans.net I'm getting confused here. I guess I don't understand the association model. The "IPv6 Security Architecture" in section 5.3 sez " The Security Association Identifiers (SAIDs) used in the IPv6 security mechanisms are receiver-oriented, making them well suited for use in IP multicast." I'm trying to figure out what to put in a packet to send it for some hypothetical example. Lets assume the first hop is a router that doesn't know anything about security; it just picks the packet up from this LAN and moves it to another LAN. The second hop is a security aware router and I guess it knows about the SAID and enforces whether the packet is allowed (or directs the path of the packet depending on the packet contents). Eventually the packet ends up at the other host I want to talk with. What is the receiver in this case? is it the local router that doesn't know about security, is the security knowledgeable router, or is it final destination? If the receiver is the intermediate security aware router, how does the sender figure out what SAID that receiver wants? I guess I'm assuming the IPv4 model where all the sender knows is the next hop. Maybe there are some IPv6 mechanisms I don't know about. > To: "Dean D. Throop" > Cc: Dean.Jagels@sciatl.com, ipsec@ans.net, bayerl@zk3.dec.com > Subject: Re: Re[3]: (IPng) More Endpoint Attributes > In-Reply-To: Your message of Thu, 16 Mar 95 15:46:00 -0500. > <199503162046.AA25161@interlock.ans.net> > Date: Fri, 17 Mar 95 10:16:43 -0500 > From: Steve Kent > Dean, > > I believe the SAID is meaningful only to the end points of the > security association. If a router is acting as an endpoint, then it > has the necessary labeling info from the association establishment > procedure. If a router is not an endpoint, I would not expect it to > have access to the mapping from SAID to sensitivity level. Perhaps > I misunderstood your discussion about routers looking at SAIDs to > make routing decisions based on sensitivity level. > > Steve > Dean Throop throop@dg-rtp.dg.com From ipsec-request@ans.net Fri Mar 17 19:15:11 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27635 (5.65c/IDA-1.4.4 for ); Fri, 17 Mar 1995 14:22:40 -0500 Received: by interlock.ans.net id AA08238 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 17 Mar 1995 14:13:50 -0500 Message-Id: <199503171913.AA08238@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 17 Mar 1995 14:13:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 17 Mar 1995 14:13:50 -0500 X-Sender: hughes@129.191.63.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Mar 1995 13:15:11 -0600 To: Andy Bayerl , cfm@columbia.sparta.com (Carl F. Muckenhirn) From: hughes@hughes.network.com (James P Hughes) Subject: Re: Routing Cc: ipsec@ans.net, barron@zk3.dec.com > I think MAC here means mandatory access control (classification or other > rule-based discriminator). And if he thinks that off the shelf routers > (presumably un-"trusted") will be allowed to provide MAC he needs to think > about it again. > >There are now also *trusted* routers from Network Systems and Harris >that provide the capability for TSIG CIPSO as well as RFC1108. This is correct. The DX router is in evaluation for the B1 level. This is a COTS high performance router which will provide trusted and evaluated MAC. Jim ---------------------- James P Hughes Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 From ipsec-request@ans.net Fri Mar 17 23:30:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05101 (5.65c/IDA-1.4.4 for ); Fri, 17 Mar 1995 18:39:23 -0500 Received: by interlock.ans.net id AA20724 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 17 Mar 1995 18:34:05 -0500 Message-Id: <199503172334.AA20724@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 17 Mar 1995 18:34:05 -0500 To: "Dean D. Throop" Cc: ipsec@ans.net Subject: Re: Re[5]: (IPng) More Endpoint Attributes In-Reply-To: Your message of Fri, 17 Mar 95 12:48:43 -0500. <9503171748.AA26245@commtg3> Date: Fri, 17 Mar 95 18:30:00 -0500 From: Steve Kent Dean, In your example, the first router to implement IPSP (an intermediate vs. first hop router in yoru example) would be an IPSP endpoint, and the final destination would be an IPSP endpoint. The SAIDs exist only at the intermediate router and the final destination. I assume the sender does not implement IPSP in your example and thus it does not deal with an SAID. The tone of your comments makes the SAID sound more like a security label, which it is not. Only systems, hosts or routers, implementing IPSP make use of SAIDs. Perhaps an issue you are raising indirectly is how does a host communicate its security requirements to a router (first hop or intermediate), where IPSP is implemented. In other network layer security protocols there is not facility for this; rather the router makes its decisions about what security service to provide based on local management info and an examination of (IP and, if it cheats, TCP) header information. In such cicrumstances, there is not a one-to-one corrspondence between SAID and source/destination IP addresses, because the router may group security-equivalent streams associated with different hosts into a single security association that terminates at another router. Steve From ipsec-request@ans.net Sat Mar 18 22:56:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15503 (5.65c/IDA-1.4.4 for ); Sat, 18 Mar 1995 18:15:22 -0500 Received: by interlock.ans.net id AA16059 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 18 Mar 1995 18:11:32 -0500 Message-Id: <199503182311.AA16059@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 18 Mar 1995 18:11:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 18 Mar 1995 18:11:32 -0500 Date: Sat, 18 Mar 1995 14:56:10 -0800 From: Phil Karn To: hugo@watson.ibm.com Cc: IPSEC@ans.net In-Reply-To: <199503161857.KAA10283@qualcomm.com> (hugo@watson.ibm.com) Reply-To: karn@qualcomm.com Subject: Re: A Photuris variant >Are you trying to communicate with the home's system or somebody behind that >system (e.g., a particular user)? Doesn't really matter. IPSP is designed for host-to-host security at the IP level, although it may also be used in a gateway-to-gateway or host-to-gateway mode. Let's pick the last mode. I set up a central IPSP gateway at Qualcomm and encourage its use by all of our many traveling employees. Then I too go on the road with my laptop and wish to log back into my workstation at Qualcomm to get my mail. I would much rather do this in a way that didn't let an eavesdropper know where I am. That means not sending in the clear anything that would identify myself to eavesdroppers, including the credentials I must send to the IPSP gateway to authenticate myself. With Photuris as I've specified it, all a passive eavesdropper could tell is that *someone* on a particular network is communicating with something inside Qualcomm; they couldn't tell *who*. Now it is true that if I ran IPSP on an end-to-end basis from my laptop to my office workstation, servo.qualcomm.com, then an eavesdropper who knew that I am the only user of that particular workstation could reasonably infer my location from seeing servo's IP address on the packets I generate from the road. But I could address this problem by nesting two IPSP security associations, one between my laptop and the end system and the other between my laptop and the central gateway. I've said it before and I'll say it again -- traffic analysis is *important*. It doesn't get nearly the attention that it should in the civilian world. Phil From ipsec-request@ans.net Sat Mar 18 23:39:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21061 (5.65c/IDA-1.4.4 for ); Sat, 18 Mar 1995 18:42:43 -0500 Received: by interlock.ans.net id AA09787 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 18 Mar 1995 18:39:56 -0500 Message-Id: <199503182339.AA09787@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 18 Mar 1995 18:39:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 18 Mar 1995 18:39:56 -0500 Date: Sat, 18 Mar 1995 15:39:00 -0800 From: Phil Karn To: ashar@osmosys.incog.com Cc: ipsec@ans.net In-Reply-To: <199503161943.AA07580@interlock.ans.net> (ashar@osmosys.incog.com) Subject: Re: Diffie's comments on Photuris Ashar, Thanks for your message. I had no particular reason for signing the shared secret as opposed to the two public keys. I just received a copy of the Diffie-Van Oorschot-Wiener paper by snail mail and will read it. Phil From ipsec-request@ans.net Sat Mar 18 19:20:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21041 (5.65c/IDA-1.4.4 for ); Sat, 18 Mar 1995 19:20:25 -0500 Received: by interlock.ans.net id AA15351 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 18 Mar 1995 19:17:10 -0500 Message-Id: <199503190017.AA15351@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 18 Mar 1995 19:17:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 18 Mar 1995 19:17:10 -0500 Date: Sat, 18 Mar 1995 16:14:52 -0800 From: Phil Karn To: bound@zk3.dec.com Cc: Danny.Nessett@eng.sun.com, ipng@sunroof.eng.sun.com, ipsec@ans.net Reply-To: karn@qualcomm.com In-Reply-To: <9503160527.AA29567@xirtlu.zk3.dec.com> (bound@zk3.dec.com) Subject: Re: Proposed message on perfect forward security >I do not think TCP vs TP[0-4] is a fair analysis to in-band vs >out-band. TCP and TPxxx are two different protocol suites, two >different AFs to a socket, and I believe two different philosophies >towards the functions of a transport layer protocol. In-band is an >option customers may want to use who do not need perfect forwarding >security. Everything else about the ip6_input layer is the same, all Ah, but I think TP[0-4] *is* an excellent analogy. The reason given for having 5 different transport protocols, all of which provided the same interface to the user, was that the "heavier" protocol (TP4) was not needed when the underlying network claimed to provide reliability. As we saw, however, the benefits of having a single, universal transport protocol providing a virtual byte stream service outweighed any concerns about performance -- many of which became moot when clever tricks like VJ header compression came along. And so I believe it will be with IP security. Once it becomes popular, people will find clever coding tricks and CPUs will get faster. But it won't become popular if there are a half dozen non-interoperable standards competing with each other. That says we should try to make the most general purpose protocol we can. Phil From ipsec-request@ans.net Sun Mar 19 19:44:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18172 (5.65c/IDA-1.4.4 for ); Sun, 19 Mar 1995 14:57:22 -0500 Received: by interlock.ans.net id AA05886 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 19 Mar 1995 14:53:41 -0500 Message-Id: <199503191953.AA05886@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 19 Mar 1995 14:53:41 -0500 To: ipsec@ans.net Subject: Comments on draft-metzger-ah-01.txt Date: Sun, 19 Mar 95 14:44:14 -0500 From: David Waitzman Section 2.1 second to last paragraph of Authentication Data: It says "filled with unspecified implementation dependent (random) values". The word "random" is perhaps dangerous here, since you (I presume) don't mean cryptographicly random. I suggest removing it. Section 3.1 third paragraph: Could you clarify which IP options are calculated in the calculation? IP LSRR, timestamp, etc. options are modified in transit so should not be in it. Section 3.1 last paragraph: Must the ICMP data containing part of the offending IP datagram have unmodified (e.g. pre-zeroing) values for those fields zeroed in the crypto-checksum calculation? This would require making a copy of the original datagram or at least of the fields that will be zeroed, just in case the datagram is rejected but may provide better error information. I suspect that you want the faster behavior (e.g. no copying). -david waitzman (please send responses directly to me as I'm not on the ipsec list) From ipsec-request@ans.net Mon Mar 20 03:12:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27109 (5.65c/IDA-1.4.4 for ); Sun, 19 Mar 1995 22:15:41 -0500 Received: by interlock.ans.net id AA05195 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 19 Mar 1995 22:12:38 -0500 Message-Id: <199503200312.AA05195@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 19 Mar 1995 22:12:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 19 Mar 1995 22:12:38 -0500 X-Sender: cfm@bugs.columbia.sparta.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 19 Mar 1995 22:12:12 -0500 To: smb@research.att.com, cfm@columbia.sparta.com (Carl F. Muckenhirn) From: cfm@columbia.sparta.com (Carl F. Muckenhirn) Subject: Re: Routing Cc: "William Allen Simpson" , ipsec@ans.net At 9:58 AM 3/17/95, smb@research.att.com wrote: >There are certainly many possible ways to implement a security >architecture. It may be that the drafts are not clear. That's true, I sometimes wonder what security architecture we are building. > The intent of >the current design is the SAID is strictly an endpoint concept, and is >not known to intermediate hops. It manifestly is not a security >label. I personally prefer the term ``key identifier'', from the >SP3/SP4 drafts; it's much less confusing than OSIspeak. I agree. (The following are random thoughs on a battle already lost, but here goes.) If it's just a key-id (on a per-host basis) its hard to see why 32 bits are needed, 8 bits seem quite generous (256 simultaneous keys per "host(or multicast group)-pair"). (I know, word aligned, faster parsers, free bandwidth, ATM to the desktop yesterday ....) > >With the exception of the reserved values -- which are a concession to >the need for other possible models of how to do things -- the SAID can >be thought of as strictly a table index. The table itself supplies the >cryptographic algorithm identifier, the current session key, the >security level, the expiration time, and any host-specific information, >such as userid. > Sounds an awful lot like how I'd implement an SP3/4 device, hmmmm. >There is a missing architectural piece: some IPv6 header or hop-by-hop >option to carry a security label. If ESP is deployed >gateway-to-gateway or gateway-to-host, in a multilevel environment, >there needs to be some way for the host and the encrypting gateway >(which may or may not be a router) to communicate. After my above comments about SAID size, I shouldn't even say anything in the context of IPv6, but, oh well I'm here... One might expect that the gov't agencies who worry about this (DISA, DIA, NSA mostly) may someday provide a way of mapping the CIPSO/BIPSO/RIPSO stuff as either a data item encapsulated with the IPv6-gram (I find it hard to call it a datagram, headergram maybe), or an IPv6 option (i'm not up on the optioning capabilities of IPv6) like the RIPSO/CIPSO/BIPSO. >The SAID was not intended for this purpose for a number of reasons. >First, of course, it was intended primarily for use in non-MLS >environments. That's true, but what about other "rule-based" access control models, i.e., Barings bank derivative trades, Barings bank LOC extension, comptroller, ... > --Steve Bellovin carl. From ipsec-request@ans.net Sun Mar 19 21:54:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21290 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 03:18:59 -0500 Received: by interlock.ans.net id AA15707 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 03:16:13 -0500 Message-Id: <199503200816.AA15707@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Mar 1995 03:16:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 03:16:13 -0500 Date: Sun, 19 Mar 95 21:54:30 GMT From: "William Allen Simpson" To: ipsec@ans.net Cc: David Waitzman Subject: Re: Comments on draft-metzger-ah-01.txt > From: David Waitzman > Section 2.1 second to last paragraph of Authentication Data: It says > "filled with unspecified implementation dependent (random) values". > The word "random" is perhaps dangerous here, since you (I presume) > don't mean cryptographicly random. I suggest removing it. > The parenthetical aside "(random)", which is implementation dependent, could certainly be cryptographically random if the implementation so desires. In any case, completely unspecified implementation dependent values could appear to be random or appear to be the same, randomly; that's what "unspecified implementation dependent" means. > Section 3.1 third paragraph: Could you clarify which IP options are > calculated in the calculation? IP LSRR, timestamp, etc. options are > modified in transit so should not be in it. > If you already know that these options are modified in transit, then I'm sure that others can figure out the same thing. There are many options, some obsolete, and new ones may show up at any time. It is not useful to list all possible past, present and future options. It is not useful to spell out every last implementation detail in a protocol specification. > Section 3.1 last paragraph: Must the ICMP data containing part of the > offending IP datagram have unmodified (e.g. pre-zeroing) values for > those fields zeroed in the crypto-checksum calculation? This would > require making a copy of the original datagram or at least of the > fields that will be zeroed, just in case the datagram is rejected but > may provide better error information. I suspect that you want the > faster behavior (e.g. no copying). > I have no idea what you are talking about. The fields in the appended IP datagram (in those messages which append an IP datagram), will no longer be modified in transit, even if they are options which may have been previously modified in transit to that point, and therefore would not be zeroed during the calculation prior to sending. Your implementation is responsible for handling the calculation, and such details as copying are outside the scope of this document. (I presume from your comments that you are implementing?) > (please send responses directly to me as I'm not on the ipsec list) > Just this once. If you wish to participate, you should be on the list. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Mar 20 09:36:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24451 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 05:07:36 -0500 Received: by interlock.ans.net id AA20624 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 05:00:40 -0500 Message-Id: <199503201000.AA20624@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Mar 1995 05:00:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 05:00:40 -0500 Date: Mon, 20 Mar 95 09:36:44 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Security Parameter Index > From: smb@research.att.com > There are certainly many possible ways to implement a security > architecture. It may be that the drafts are not clear. The intent of > the current design is the SAID is strictly an endpoint concept, and is > not known to intermediate hops. It manifestly is not a security > label. I personally prefer the term ``key identifier'', from the > SP3/SP4 drafts; it's much less confusing than OSIspeak. > I agree. But it covers more than the Key. And Identifier is overused. > With the exception of the reserved values -- which are a concession to > the need for other possible models of how to do things -- the SAID can > be thought of as strictly a table index. The table itself supplies the > cryptographic algorithm identifier, the current session key, the > security level, the expiration time, and any host-specific information, > such as userid. > We could change the name from SAID to "Index". Militaristic linguists could call it a "Security Parameter Index", or "SecParIn" for short. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Mar 20 09:20:35 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22917 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 05:07:37 -0500 Received: by interlock.ans.net id AA04487 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 05:00:30 -0500 Message-Id: <199503201000.AA04487@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 05:00:30 -0500 Date: Mon, 20 Mar 95 09:20:35 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Routing > From: Andy Bayerl > I think Dean was using yet a 3rd meaning to MAC which is very familiar > to the MLS CMW world, namely "Mandatory Access Control", which refers > to using sensitivity labels to strictly control access to data. > The security architecture document itself refers to *MAC* in that context: > I'm not in that world, so the acronym went right by me. Heck, I don't know what CMW is either. The term is not used in Ran's draft. Damn militarism. > There is a paragraph in there that I think may have Dean (and I also) > to infer that the document implied overloading the SAID with *MAC* > information. > > The Encapsulating Security Payload can be combined with appropriate > key policies to provide full multi-level secure networking. In this > case each key must be used only at a single sensitivity level and > compartment. For example, Key "A" might be used only for sensitive > Unclassified packets, while Key "B" is used only for > Secret/No-compartments traffic, and Key "C" is used only for > Secret/No-Foreign traffic. > Ran proposes using different session key material for each such access type, not _routing_ based on each access type. > I (at least) had equated the *key* in this paragraph to the SAID. Each session key is indicated by a different SAID. The SAID is not a key. > >From Ran's comments on the subject and a closer rereading of the this > section I believe I now understand it much more clearly in the sense that > is strictly referring to the authentication strength of the key and is not > in any way related to the *MAC* dominance rules of CMW sensitivity > labels. > Yes. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Mar 20 09:55:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14989 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 05:07:45 -0500 Received: by interlock.ans.net id AA09364 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 05:00:43 -0500 Message-Id: <199503201000.AA09364@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Mar 1995 05:00:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 05:00:43 -0500 Date: Mon, 20 Mar 95 09:55:12 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Auth Header Length I have been thinking that it would be a minor simplification of my header processing to have the header length as the first byte, instead of the second. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This allows Header Compression to be somewhat simpler. Any objections? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Mar 20 13:03:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07100 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 08:08:31 -0500 Received: by interlock.ans.net id AA04375 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 08:03:48 -0500 Message-Id: <199503201303.AA04375@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 20 Mar 1995 08:03:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 20 Mar 1995 08:03:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 20 Mar 1995 08:03:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Mar 1995 08:03:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 08:03:48 -0500 X-Mailer: exmh version 1.5.3 12/28/94 To: ipsec@ans.net Subject: Need for single versatile and modular key management protocol In-Reply-To: Your message of "Sat, 18 Mar 1995 16:14:52 PST." <199503190017.AA15351@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Mar 1995 08:03:43 -0500 From: " " I agree with Phil. We need a flexible, versatile and modular design, which would offer all the features some of us need (including perfect forward secrecy and similar resiliency to key exposures). We need to keep it simple and efficient, too; in particular the more expensive features should be optional when there's a simple way to make them so. Another thing I'll like to have is to allow license-free implementations of at least a useful subset. I think that we are not very far from these goals, esp. with the variant that Hugo has described. Best, Amir > And so I believe it will be with IP security. Once it becomes popular, > people will find clever coding tricks and CPUs will get faster. But it > won't become popular if there are a half dozen non-interoperable > standards competing with each other. That says we should try to make > the most general purpose protocol we can. > > Phil > From ipsec-request@ans.net Mon Mar 20 13:44:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22900 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 09:15:34 -0500 Received: by interlock.ans.net id AA03615 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 09:08:48 -0500 Message-Id: <199503201408.AA03615@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 09:08:48 -0500 From: Ran Atkinson Date: Mon, 20 Mar 1995 08:44:04 -0500 In-Reply-To: Andy Bayerl "Re: Routing" (Mar 17, 9:16) References: <199503171415.AA17210@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: MLS Security Associations, etc. Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil On Mar 17, 9:16, Andy Bayerl wrote: } Subject: Re: Routing % I think Dean was using yet a 3rd meaning to MAC which is very familiar % to the MLS CMW world, namely "Mandatory Access Control", which refers % to using sensitivity labels to strictly control access to data. The % security architecture document itself refers to *MAC* in that context: Yes, I also think that Dean Throop was using MAC in that manner. Perhaps it would be less confusing if none of us used the abbreviation "MAC" in email on this list since there are several possible meanings ? 5.5 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS A multi-level secure (MLS) network is one where a single network is used to communicate data at different sensitivity levels (e.g. Unclassified and Secret). Many governments have significant interest in MLS networking. [DIA] The IPv6 security mechanisms have been designed to support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC) which ordinary users are ^^^ incapable of controlling or violating. Mandatory Access Controls differ from Discretionary Access Controls in this respect. % There is a paragraph in there that I think may have Dean (and I also) % to infer that the document implied overloading the SAID with *MAC* % information. The Encapsulating Security Payload can be combined with appropriate key policies to provide full multi-level secure networking. In this case each key must be used only at a single sensitivity level and compartment. For example, Key "A" might be used only for sensitive Unclassified packets, while Key "B" is used only for Secret/No-compartments traffic, and Key "C" is used only for Secret/No-Foreign traffic. % I (at least) had equated the *key* in this paragraph to the SAID. The _combination_ of SAID and Destination Address _does_ imply a particular single key that is in use for that traffic. The SAID does not "equate" to the key, but it is "related" to the key. % From Ran's comments on the subject and a closer rereading of the this % section I believe I now understand it much more clearly in the sense % that is strictly referring to the authentication strength of the key % and is not in any way related to the *MAC* dominance rules of CMW % sensitivity labels. Not exactly. The "not in any way related" part is incorrect. They are related, but are not equal. One has a "Security Association" which is uniquely determined by the pair of SAID and Destination Address. A Security Association has a number of different parameters. In an MLS environment, one of those parameters is the highest sensitivity level of traffic that uses that Security Association. Under normal circumstances if one has SECRET traffic, then one will use a "Security Association" which has a security level of SECRET and one will use a SECRET-level key. In that case, the combination of SAID and Destination Address _does_ imply a security level of SECRET. In an MLS environment, One MUST NOT use a key having a lower security level (e.g. SECRET) to protect higher security level traffic (e.g. TOP SECRET). That relation could be expressed by saying that the sensitivity level of the traffic MUST NOT dominate the sensitivity level of the key. If one were to have a single multi-level session, then the applicable "Security Association" would have a key for the _highest_ level of traffic permitted in that session and that "Security Association" would have an associated sensitivity level that was equal to the highest possible level of that session. To give a specific example, one might have a "Security Association" that was TOP SECRET, a key that was TOP SECRET, and traffic ranging from SECRET to TOP SECRET (inclusive). A better approach to this example would be to use _2_ Security Associations, one at SECRET and another at TOP SECRET. In this better approach, outgoing traffic would select the lowest sensitivity level Security Association that dominated the sensitivity level of the traffic. As a practical matter, implementations might choose to ignore horizontal compartments when dealing with Security Associations because the number of compartments can be very large and the management of Security Associations could become unwieldy if horizontal compartments had to be taken into consideration all the time. If the current text is unclear in this area, I'm happy to try to clean it up. Folks outside the MLS world need not be worried. The current specification language clearly indicates that the MLS text only applies to systems which claim to provide MLS capabilities. The MLS text does need to be there to ensure interoperability and correct implementation of ESP/AH within such MLS-capable systems. Some MLS work (e.g. RFC-1108 IPSO) has been done within the IETF and MLS discussions have been occurring within IPsec since its beginning, so this is clearly within scope for the IPsec WG. Regards, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Mar 20 14:50:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07148 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 10:05:30 -0500 Received: by interlock.ans.net id AA17115 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 09:51:32 -0500 Message-Id: <199503201451.AA17115@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 09:51:32 -0500 To: William Allen Simpson Cc: ipsec@ans.net Subject: Re: Comments on draft-metzger-ah-01.txt In-Reply-To: Your message of Sun, 19 Mar 95 21:54:30 +0000. <4324.Bill.Simpson@um.cc.umich.edu> Date: Mon, 20 Mar 95 09:50:28 -0500 From: David Waitzman > > Section 2.1 second to last paragraph of Authentication Data: It says > > "filled with unspecified implementation dependent (random) values". > > The word "random" is perhaps dangerous here, since you (I presume) > > don't mean cryptographicly random. I suggest removing it. > > > The parenthetical aside "(random)", which is implementation dependent, > could certainly be cryptographically random if the implementation so > desires. In any case, completely unspecified implementation dependent > values could appear to be random or appear to be the same, randomly; > that's what "unspecified implementation dependent" means. Is there any point to the values being cryptographically random? I doubt it if you're doing authentication but probably yes if you're doing privacy. Saying just "unspecified implementation dependent" is sufficient to get your point across. "(random)" is misleading because it is not necessary. > > Section 3.1 last paragraph: Must the ICMP data containing part of the > > offending IP datagram have unmodified (e.g. pre-zeroing) values for > > those fields zeroed in the crypto-checksum calculation? This would > > require making a copy of the original datagram or at least of the > > fields that will be zeroed, just in case the datagram is rejected but > > may provide better error information. I suspect that you want the > > faster behavior (e.g. no copying). > > > I have no idea what you are talking about. The fields in the appended > IP datagram (in those messages which append an IP datagram), will no > longer be modified in transit, even if they are options which may have > been previously modified in transit to that point, and therefore would > not be zeroed during the calculation prior to sending. Heres the flow I was trying to explain: 1. IP Datagram comes in on the wire 2. Some checks are done. 3. Some ICMP messages may be sent at this point. 4. Certain fields in the IP datagram are zeroed. [ Is a copy done now?? ] 5. The crypto calculation is done. 6. The datagram is then examined for other problems. 7. Some ICMP messages may be sent at this point. -> If so, if the ICMP message requires part of the original IP datagram to be returned, is it the IP datagram from before or after step #4? > Your implementation is responsible for handling the calculation, and > such details as copying are outside the scope of this document. (I > presume from your comments that you are implementing?) I am not implementing. Perhaps later. I would like a standard IPv4 authentication and privacy protocol to be available. -david From ipsec-request@ans.net Mon Mar 20 13:03:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19622 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 10:27:05 -0500 Message-Id: <199503201527.AA19622@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Mon, 20 Mar 1995 10:22:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 20 Mar 1995 10:22:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 20 Mar 1995 10:22:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 20 Mar 1995 10:22:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Mar 1995 10:22:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 10:22:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Mon, 20 Mar 1995 10:22:58 -0500 X-Mailer: exmh version 1.5.3 12/28/94 To: ipsec@ans.net Subject: Need for single versatile and modular key management protocol In-Reply-To: Your message of "Sat, 18 Mar 1995 16:14:52 PST." <199503190017.AA15351@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Mar 1995 08:03:43 -0500 From: " " I agree with Phil. We need a flexible, versatile and modular design, which would offer all the features some of us need (including perfect forward secrecy and similar resiliency to key exposures). We need to keep it simple and efficient, too; in particular the more expensive features should be optional when there's a simple way to make them so. Another thing I'll like to have is to allow license-free implementations of at least a useful subset. I think that we are not very far from these goals, esp. with the variant that Hugo has described. Best, Amir > And so I believe it will be with IP security. Once it becomes popular, > people will find clever coding tricks and CPUs will get faster. But it > won't become popular if there are a half dozen non-interoperable > standards competing with each other. That says we should try to make > the most general purpose protocol we can. > > Phil > From ipsec-request@ans.net Mon Mar 20 13:52:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21291 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 11:07:27 -0500 Received: by interlock.ans.net id AA24914 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 11:01:26 -0500 Message-Id: <199503201601.AA24914@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 11:01:26 -0500 From: Ran Atkinson Date: Mon, 20 Mar 1995 08:52:52 -0500 In-Reply-To: cfm@columbia.sparta.com (Carl F. Muckenhirn) "Re: Routing" (Mar 17, 9:20) References: <199503171421.AA17360@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: Routing Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Bill, I do not see any reason why the specs should prohibit an intermediate router from being party to a Security Association between two other systems (call them S and D) as long as those systems (S and D) choose to let that router be party to their Security Association. Now key management (etc) are much harder in such usage, but that is a problem tobe solved by the users desiring such an arrangement. I don't think that any standards-track key mgmt protocol is required to solve that intermediate-router keying problem. The specs CURRENTLY DO NOT PROHIBIT such an arrangement and it might be desirable in some user communities to operate in that manner. Further, I note that the IAB Workshop report from last spring clearly stated that letting some intermediate routers be party to a Security Association might be desirable in some cases. (That RFC used different language but clearly had that meaning). Finally, in many cases routers will also act as dedicated IP encryptors on behalf of systems behind the router. In this case, the end systems might not actually implement end-to-end encryption themselves and might instead rely on the encrypting routers. This scenario is especially likely in commercial IPv4 environments where traffic leaving the firm would be encrypted and traffic within the firm would not be encrypted. Management of encryption at routers is often sensible since router administrators are often more technically sophisticated that plant-floor workstation operators. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Mar 20 14:19:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17965 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 11:07:27 -0500 Received: by interlock.ans.net id AA29784 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 11:01:30 -0500 Message-Id: <199503201601.AA29784@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 11:01:30 -0500 From: Ran Atkinson Date: Mon, 20 Mar 1995 09:19:31 -0500 In-Reply-To: throop@dg-rtp.dg.com (Dean D. Throop) "Re[5]: (IPng) More Endpoint Attributes" (Mar 17, 12:48) References: <199503171749.AA33746@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: Re[5]: (IPng) More Endpoint Attributes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil On Mar 17, 12:48, Dean D. Throop wrote: % I'm getting confused here. I guess I don't understand the association % model. The "IPv6 Security Architecture" in section 5.3 sez " The % Security Association Identifiers (SAIDs) used in the IPv6 security % mechanisms are receiver-oriented, making them well suited for use in % IP multicast." An SAID is NOT (repeat NOT) comparable to an IPSO label. An SAID is just an opaque identifier that is used (along with the Destination Address) to help locate the correct "Security Association". Examining an SAID will NOT, in the absence of being a party to the particular Security Association, tell anyone the sensitivity level of that Security Association or of that packet. This is a _feature_ because an adversary cannot use the SAID to immediately ascertain which packets are high-value targets. % I'm trying to figure out what to put in a packet to send it for some % hypothetical example. Lets assume the first hop is a router that % doesn't know anything about security; it just picks the packet up from % this LAN and moves it to another LAN. The second hop is a security % aware router and I guess it knows about the SAID and enforces whether % the packet is allowed (or directs the path of the packet depending on % the packet contents). Eventually the packet ends up at the other host % I want to talk with. % What is the receiver in this case? % is it the local router that doesn't know about security, NO % is the security knowledgeable router, or NO % is it final destination? YES. The "receiver" always equates to the entity (entities in the case of multicast) addressed by the Destination Address of the packet. We use the term "receiver" because it is the convention when talking about multicast technologies. Deering's IP Multicast is "receiver-oriented" while other technologies (which are NOT used with IP) are "sender-oriented". Please see Deering's RFC on IP Multicasting (RFC-1112 ???) for a better explanation of how multicasting works in the Internet. It is possible that neither end system actually implements security features. In this case, security might be provided between some links via encrypting gateways that operate on behalf of systems behind those gateways. Such gateways might be encrypting routers, bulk IP encryptors, and/or encrypting firewalls. The packet's Destination Address is still used in combination with the SAID to determine the Security Association, even though the destination system is not directly participating and is instead represented by its proxy encrypting gateway. NOTE: When encrypting gateways are in use to encrypt traffic originating on another system, host-to-host keying will generally be the only choice because user-to-user keying is not practical when the system performing the encryption does not dependably know which user is originating the traffic. I believe the current language makes this keying issue of intermediate encryption reasonably clear. If the language doesn't seem clear, please send me email and tell me which bits are confusing. % If the receiver is the intermediate security aware router, how does % the sender figure out what SAID that receiver wants? I guess I'm % assuming the IPv4 model where all the sender knows is the next hop. % Maybe there are some IPv6 mechanisms I don't know about. The Sender knows which Destination Address it is putting into the packet. The Security Association is determinable by the Sender by examining the sending userid, the Destination Address, and possibly additional information (e.g. process or socket sensitivity level in the case of a CMW). Steve Kent is entirely correct that, unless the router is a part of the particular Security Association in use, the router cannot know the sensitivity level of the session and hence cannot perform any Mandatory-Access-Control (MAC) filtering. Such MAC filtering is no longer important when real encryption (e.g. Type 1) is being used for traffic between Source and Destination. That MAC filtering at routers is being used at present for IPv4 traffic in order to reduce risk of compromise since users don't have universally available IP encryption. If IPSO had been renamed the "IP Security Label Option" it might not be as confusing now. Neither IPSO nor CIPSO provide security (security == confidentiality, authentication, integrity). Both IPSO and CIPSO provide unauthenticated sensitivity labels to packets. As Steve Bellovin has recently noted, IPSO and CIPSO labelling have a very serious problem in that it tells the adversary which packets are most important and hence are worth attacking (via passive eavesdropping, cryptanalysis, or what have you). Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Mar 20 15:16:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26933 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 11:07:36 -0500 Received: by interlock.ans.net id AA29533 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 11:01:34 -0500 Message-Id: <199503201601.AA29533@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 11:01:34 -0500 From: Ran Atkinson Date: Mon, 20 Mar 1995 10:16:31 -0500 In-Reply-To: "William Allen Simpson" "Auth Header Length" (Mar 20, 9:55) References: <199503201000.AA09364@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: William Allen Simpson , ipsec@ans.net Subject: Re: Auth Header Length Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Bill, Your proposed change would not be consistent with the IPv6 practice on location of header fields. I believe the cost of inconsistency is greater than the benefit of having it first. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Mar 20 09:31:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18688 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 14:32:38 -0500 Received: by interlock.ans.net id AA24200 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 14:28:23 -0500 Message-Id: <199503201928.AA24200@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 20 Mar 1995 14:28:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Mar 1995 14:28:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 14:28:23 -0500 Date: Mon, 20 Mar 95 14:31:29 EST From: rcallon@pobox.wellfleet.com (Ross Callon) To: ipng@sunroof.eng.sun.com, karn@unix.ka9q.ampr.org Subject: Re: (IPng) Re: Proposed message on perfect forward security Cc: ipsec@ans.net > >I do not think TCP vs TP[0-4] is a fair analysis to in-band vs > >out-band. TCP and TPxxx are two different protocol suites, two > >different AFs to a socket, and I believe two different philosophies > >towards the functions of a transport layer protocol. In-band is an > >option customers may want to use who do not need perfect forwarding > >security. Everything else about the ip6_input layer is the same, all > > Ah, but I think TP[0-4] *is* an excellent analogy. The reason given > for having 5 different transport protocols, all of which provided the > same interface to the user, was that the "heavier" protocol (TP4) was > not needed when the underlying network claimed to provide reliability. > As we saw, however, the benefits of having a single, universal transport > protocol providing a virtual byte stream service outweighed any > concerns about performance -- many of which became moot when clever > tricks like VJ header compression came along. I also agree that this is at least a partly reasonable analogy. Some of us who were working on CLNP/TP4 etc at the time figured that TP4 was obviously necessary (for the same reasons as TCP over IP), and that the market would figure this out. What happened instead was that having five transport layer standards and at least two network layer standards helped to confuse potential users, which added still more delay and confusion to potential use of OSI. Now, the analogy probably partly fails in that network and transport layer problems were NOT what stopped OSI (at least in my opinion). I think that OSI suffered more from application complexity, particular complexity as seen by the user (eg, ugly Email names), and other problems independent of the network and transport layers. However, if OSI had said "TP4 and CLNP are our transport and network layer standards" then this would have made it simpler for folks who thought that they needed to deploy OSI to actually start doing so. > And so I believe it will be with IP security. Once it becomes popular, > people will find clever coding tricks and CPUs will get faster. But it > won't become popular if there are a half dozen non-interoperable > standards competing with each other. That says we should try to make > the most general purpose protocol we can. > > Phil Also, if encryption is really *necessary* for security in the Internet to work, and if simultaneous security and performance in the Internet is necessary for the global information super- highway to have a several orders of magnitude increase in its commercial value, then encryption may need to be in hardware. Clearly hardware can be cheaper if there are fewer standards to implement (although patents and laws may also throw a monkey wrench in the works). Ross From ipsec-request@ans.net Mon Mar 20 09:43:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23500 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 15:59:53 -0500 Received: by interlock.ans.net id AA34433 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 15:12:55 -0500 Message-Id: <199503202012.AA34433@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Mar 1995 15:12:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 15:12:55 -0500 Date: Mon, 20 Mar 95 14:43:06 EST From: hugo@watson.ibm.com To: karn@qualcomm.com Cc: IPSEC@ans.net Subject: A Photuris variant Phil, In your example below there is no reason for the mobile user not to carry the workstation's public key in his laptop. In that case, my solution works fine (without requiring a first unauthenticated DH exchange). Of course, in some cases a user (even a non-mobile one) will need to find a PK that is not available to her. The level of protection for such a query will depend on where and from whom you are getting that information. For example, in the case of a DNS query, an eavesdropper can find out whose PK you are requesting, regardless of the key management protocol you use. I agree that in some cases, having a DH exchange first may help. That option may be easily added to my proposal. However, I would prefer to avoid non-typical cases from dictating the form of the default protocol. Now, if the need for DH first is "more typical" than I believe we can modify the (basic) protocol in that way. Hugo ----------------------------- Note follows ------------------------------ >Are you trying to communicate with the home's system or somebody behind that >system (e.g., a particular user)? Doesn't really matter. IPSP is designed for host-to-host security at the IP level, although it may also be used in a gateway-to-gateway or host-to-gateway mode. Let's pick the last mode. I set up a central IPSP gateway at Qualcomm and encourage its use by all of our many traveling employees. Then I too go on the road with my laptop and wish to log back into my workstation at Qualcomm to get my mail. I would much rather do this in a way that didn't let an eavesdropper know where I am. That means not sending in the clear anything that would identify myself to eavesdroppers, including the credentials I must send to the IPSP gateway to authenticate myself. With Photuris as I've specified it, all a passive eavesdropper could tell is that *someone* on a particular network is communicating with something inside Qualcomm; they couldn't tell *who*. Now it is true that if I ran IPSP on an end-to-end basis from my laptop to my office workstation, servo.qualcomm.com, then an eavesdropper who knew that I am the only user of that particular workstation could reasonably infer my location from seeing servo's IP address on the packets I generate from the road. But I could address this problem by nesting two IPSP security associations, one between my laptop and the end system and the other between my laptop and the central gateway. I've said it before and I'll say it again -- traffic analysis is *important*. It doesn't get nearly the attention that it should in the civilian world. Phil From ipsec-request@ans.net Mon Mar 20 20:38:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22703 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 16:54:05 -0500 Received: by interlock.ans.net id AA32830 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 16:41:53 -0500 Message-Id: <199503202141.AA32830@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 20 Mar 1995 16:41:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 20 Mar 1995 16:41:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 20 Mar 1995 16:41:53 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Mar 1995 16:41:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 16:41:53 -0500 Date: 20 Mar 95 14:38:00 -0600 To: rja@bodhi.cs.nrl.navy.mil, ipsec@ans.net, ho@cs.arizona.edu Subject: Intermediate SA - was Re[2]: Routing Message authorized by: : rja@bodhi.nrl.navy.mil@INTERNET at #EMAIL Ran, >I do not see any reason why the specs should prohibit an intermediate >router from being party to a Security Association between two other >systems (call them S and D) as long as those systems (S and D) choose >to let that router be party to their Security Association. I agree even though I believe the use of intermediate routers sharing a SA between two end systems is suspect. Other techniques (like multiple pair-wise SAs) could be used to meet the same requirement. However, since the IAB workshop documented this approach we should include it as one of the ways an SA can be established. What if we treat the "intermediate router SA" as one ways that SAs can have more than two participants. A "intermediate router SA" must use the same mechanisms for shared SAs as broadcast or muliticast traffic since the usual pair-wise negotiations will not guarantee uniqueness. Paul ---- possible specification text ---- Glossary Terms SA Security Association SAID Security Association IDentifier An SA consists of attributes shared between two or more security systems. A SA shared between two systems provides "pair-wise" security. A SA can also be established between multiple security systems to support broadcast traffic or multicast communications. Intermediate systems may also share a SA between other systems. This arrange might be of use [reference IAB report] to support authenticated traffic traversing a Firewall. From ipsec-request@ans.net Tue Mar 21 00:22:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20348 (5.65c/IDA-1.4.4 for ); Mon, 20 Mar 1995 19:12:51 -0500 Received: by interlock.ans.net id AA20093 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 20 Mar 1995 19:10:24 -0500 Message-Id: <199503210010.AA20093@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 20 Mar 1995 19:10:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 20 Mar 1995 19:10:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 20 Mar 1995 19:10:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 20 Mar 1995 19:10:24 -0500 Date: Mon, 20 Mar 1995 16:22:32 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: Abstract STS protocol Cc: whitfield.diffie@eng.sun.com, paulv@bnr.ca X-Sun-Charset: US-ASCII I was discussing a proposed STS variant with Whitfield Diffie when he suggested that what makes sense here is an abstract form of the Diffie-Van Oorschot-Wiener STS protocol. (BTW, for those of you haven't read the Diffie-Van Oorschot-Wiener paper, the STS protocol is similar to Photuris, with the difference that the signature is computed over both parties' public exponentials, as opposed to merely over the sender's exponentials. This is the most important difference. There are other minor differences having to do with certified Diffie-Hellman parameters etc. STS stands for Station-To-Station.) Then Hugo Krawcyk made a proposal that is modular with respect to accommodating different authentication models, which I believe has many attractive qualities. In thinking about this issue, I believe Diffie's suggestion is a good one, and that the protocol that makes most sense is an abstract form of the STS protocol, where the authentication phase is abstracted out. This is in line with the modularity proposed by Hugo earlier. I will observe that we already have to abstract out aspects of the authentication phase, simply to accommodate different trust models. Namely, I think we cannot go in with the belief that a single trust model will emerge in the Internet (e.g. Hierarchically delegated vs. Web of Trust). So we have to abstract this layer in any case. The abstraction proposed here simply abstracts one level higher and allows different types of symmetric and asymmetric keys for the authentication phase. This is in fact an important element of Hugo's proposal, and to some extent this part can be considered as reiterating this element of his proposal. As will be described, this provides a clear system gain in many different environments. I will also present an informal argument as to why this doesn't adversely affect the security of the STS protocol. Although it may be possible to reduce this argument to a formal level, I will not attempt this reduction here. The protocol is described as follows: (Photuris style cookies are omitted here, as they are mostly orthogonal to the issues being discussed, and for purposes of clarity). I->R g^x R->I g^y This is simply vanilla Diffie-Hellman. The parties now encrypt/authenticate using g^xy or subset as the session key Ks. Now follows the authentication phase. This is as follows; I->R {I_AuthKeyInfo, I_Auth(g^x, g^y)}Ks R->I {R_AuthKeyInfo, R_Auth(g^y, g^x)}Ks This is essentially the anonymity preserving variant of the STS protocol, with the signatures replaced with direction sensitive authentication information labelled I_Auth, and R_Auth. In order for the other party to be able to verify the authentication information, there is acommpanying key information to identify the authentication key. One possibility is for the authentication information to be a signature (e.g. RSA). In this case the key information would be either a certificate path leading to the signature key, or a multiply signed PGP key etc. This would serve to identify (and authenticate) the signature key. In this case, the protocol described above is exactly the STS protocol, which also uses signatures for authentication purposes. Another possibility is that the authentication information is a MAC computed using an authenticated symmetric key. Some examples of an authenticated symmetric key are as follows. It may be an existing session key with that party. In this case the acommpanying key information would be the existing SAID. This allows re-keying to be more efficient than initial keying, while still maintaining separation of sessions for the sake of perfect forward secrecy. This is because signatures (which are computationally expensive) have been replaced by MACs (e.g. MD5 based) which are far cheaper. The symmetric key may be a manually distributed key, or a key obtained from a KDC (e.g. Kerberos), or even a share phase as suggested by Hugo. The symmetric keys may be either short-lived (e.g. existing session keys) or long-lived (e.g. manually distributed). The authentication aspect of the protocol is not dependent on freshness properties of the symmetric key. Also, the symmetric authentication key may be derived from each parties' certified long-term Diffie-Hellman keys. The advantage of this approach is that the symmetric keys need only be computed once, or may be pre-computed. This gives the same performance advantage as signature pre-computation, without some of the associated weaknesses. In this case, the accompanying key information would be either a certificate path leading to the certified DH key, or a DH key signed by multiple PGP RSA keys etc. In case there is no caching of keys from DH certificates, the worst case performance of this protocol is similar to the STS protocol, in that a single exponentiation is required to compute the authenticated symmetric key. (I am glossing over the difference between RSA and DH exponentiations here). This worst case performance is also the same as that of Phil's recently proposed modification of Photuris, or Hugo's scheme when used with RSA based "share phase". Of course, if symmetric keys can be cached or precomputed, (which will be feasible with many kinds of crypto-hw devices that we are evaluating) then these two real-time long RSA exponentiations are eliminated. Using symmetric keys in general also has the advantage that one doesn't use non-repudiable signatures in the protocol, because as Hugo has mentioned, non-repudiable signatures in protocols also represent a privacy concern. Certified DH keys also give rise to a zero-message protocol like SKIP. This I believe has advantages in many different environments/applications. Because of these desirable aspects of using certified DH keys, I believe that this is an authentication mechanism that should be given serious consideration. Of course, other authentication mechanisms may also exist in the same protocol, as described above. This abtsract form of the STS protocol is I believe cryptographically similar in intent to the original STS protocol, because the only change is from signatures to direction sensitive MACs. It may be argued that the only intent of signatures in the STS protocol was to serve as a directional integrity check. No one other than the two parties needed to be able to verify the signatures, so the integrity broadcast aspect of signatures was absent. Directional MACs serve exactly the same cryptographic purpose. The proposed abstraction allows performance enhancements not possible if we consider the authentication phase to be limited to signatures only. Specifically, this allows removal of two real-time exponentiations from the STS protocol, bringing the total number of required real-time exponentiations to 1 on each side (when coupled with pre-computation of each party's public exponential). This is a substantial system gain. The difference between this proposal and Hugo's is that this one is closely modelled on the Diffie-Van Oorschot-Wiener STS protocol, which has the benefit of greater public scrutiny/analysis. However, I prefer to emphasize the similarities between this proposal and Hugo's and Phil Karn's recent proposals. Comments are, of course, welcomed. Kind Regards, Ashar. From ipsec-request@ans.net Tue Mar 21 12:51:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25644 (5.65c/IDA-1.4.4 for ); Tue, 21 Mar 1995 08:02:05 -0500 Received: by interlock.ans.net id AA26903 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 21 Mar 1995 07:52:24 -0500 Message-Id: <199503211252.AA26903@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 21 Mar 1995 07:52:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 21 Mar 1995 07:52:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 21 Mar 1995 07:52:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 21 Mar 1995 07:52:24 -0500 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, 21 Mar 1995 07:51:06 -0500 To: karn@qualcomm.com, hugo@watson.ibm.com From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Re: A Photuris variant Cc: IPSEC@ans.net At 02:56 PM 3/18/95 -0800, karn@qualcomm.com wrote: >>Are you trying to communicate with the home's system or somebody behind that >>system (e.g., a particular user)? > >Doesn't really matter. IPSP is designed for host-to-host security at >the IP level, although it may also be used in a gateway-to-gateway or >host-to-gateway mode. > >Let's pick the last mode. I set up a central IPSP gateway at Qualcomm >and encourage its use by all of our many traveling employees. Then I >too go on the road with my laptop and wish to log back into my >workstation at Qualcomm to get my mail. I would much rather do this in >a way that didn't let an eavesdropper know where I am. That means not >sending in the clear anything that would identify myself to >eavesdroppers, including the credentials I must send to the IPSP >gateway to authenticate myself. With Photuris as I've specified it, >all a passive eavesdropper could tell is that *someone* on a >particular network is communicating with something inside Qualcomm; >they couldn't tell *who*. Phil, This is EXACTLY the model I need for Chrysler. This will allow me to get out of the PPP provisioning business and outsource it; a big win for everyone. By year end, I expect to have around 4,000 such users needing this facility... Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Wed Mar 22 08:53:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18936 (5.65c/IDA-1.4.4 for ); Wed, 22 Mar 1995 08:53:03 -0500 Received: by interlock.ans.net id AA22944 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 22 Mar 1995 08:43:48 -0500 Message-Id: <199503221343.AA22944@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 22 Mar 1995 08:43:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 22 Mar 1995 08:43:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 22 Mar 1995 08:43:48 -0500 Date: Wed, 22 Mar 95 05:14:29 From: "Housley, Russ" Encoding: 1349 Text To: ipsec@ans.net, "William Allen Simpson" Subject: Re: Security Parameter Index Bill & Steve: >> From: smb@research.att.com >> There are certainly many possible ways to implement a security >> architecture. It may be that the drafts are not clear. The intent of >> the current design is the SAID is strictly an endpoint concept, and is >> not known to intermediate hops. It manifestly is not a security >> label. I personally prefer the term ``key identifier'', from the >> SP3/SP4 drafts; it's much less confusing than OSIspeak. > >Reply From: Bill.Simpson@um.cc.umich.edu >I agree. But it covers more than the Key. And Identifier is overused. I was involved in SDNS which coined the term key identifier (KID) and IEEE 802.10b which coined the term security associaion identifier (SAID). The IEEE 802.10b standard has many similarities to SDNS SP3/SP4. This is becasue a significant number of people were involved in both efforts. The term KID was changed to SAID to amplify the fact that the identifier (or index) names more than a key. It names a key and attributes of the association. The SDNS documents called this association a cryptographic association; the IEEE 802.10b documnet calls this association a security association. The point is simple: interoperability requires that the keying material and attributes assoicated with the security protocol be common. Russ From ipsec-request@ans.net Thu Mar 23 06:43:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21266 (5.65c/IDA-1.4.4 for ); Thu, 23 Mar 1995 11:50:53 -0500 Received: by interlock.ans.net id AA10568 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 23 Mar 1995 11:43:27 -0500 Message-Id: <199503231643.AA10568@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 23 Mar 1995 11:43:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 23 Mar 1995 11:43:27 -0500 Date: Thu, 23 Mar 95 11:43:15 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: new Security Drafts available for ftp Folks, Revised security drafts are available via anonymous ftp from ftp.nrl.navy.mil. I'm not sending them via email because I'm told the list is now too large for big I-Ds to be posted to it. They have also been submitted to the I-D archive folks at CNRI and should appear at the usual I-D archive sites when those folks get time. They will appear with the prefix draft-ietf-ipsec-*.txt at the I-D archive sites. The online IPng drafts having a prefix of draft-ietf-ipngwg-esp-*, draft-ietf-ipngwg-auth-*, and draft-ietf-ipngwg-sec-* are now obsoleted by these new drafts. Approximate URLs are: ftp://ftp.nrl.navy.mil/pub/security/ip-auth.txt ftp://ftp.nrl.navy.mil/pub/security/ip-esp.txt ftp://ftp.nrl.navy.mil/pub/security/ip-sec.txt Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Mar 24 02:44:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18447 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 07:50:11 -0500 Received: by interlock.ans.net id AA11373 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 07:44:32 -0500 Message-Id: <199503241244.AA11373@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 07:44:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 07:44:32 -0500 Date: Fri, 24 Mar 95 07:44:08 EST From: D_P_Sanford%caasd3@MWMGATE3.mitre.org To: ipsec@ans.net Subject: Re: (IPng) IPng W.G. Last Call for Security Drafts ---------------------------- Forwarded with Changes --------------------------- From: ipng@sunroof.Eng.Sun.COM at -smtp- Date: 3/23/95 1:17PM *To: ipng@sunroof.Eng.Sun.COM at -smtp- Subject: Re: (IPng) IPng W.G. Last Call for Security Drafts ------------------------------------------------------------------------------- I am gathering this is not a majordomo list, so please subscribe me as: dsanford@mitre.org to the ipsec mailing list. Dave Sanford (703) 883-7027 please do all discussions on these documents on the ipsec mailing list (ipsec@ans.net) ( -request to subscribe ) From ipsec-request@ans.net Fri Mar 24 18:17:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26979 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 13:32:37 -0500 Received: by interlock.ans.net id AA25459 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 13:20:31 -0500 Message-Id: <199503241820.AA25459@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 13:20:31 -0500 From: Ran Atkinson Date: Fri, 24 Mar 1995 13:17:02 -0500 Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: 2 additional Security drafts available for ftp Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Folks, There are two additional security drafts that are now available for anonymous ftp. They are the mandatory algorithm/transform specifications for use with the IP Authentcation Header and the IP Encapsulating Security Payload. They were written by Metzger, Karn, and Simpson. They are products of both IPsec and IPng working groups and are for use both with IPv4 and IPv6. I believe that a Last Call on these will start soon. They are being made available for ftp now because there is the usual last-minute submission crunch in I-D processing at the IETF Secretariat. They are not being emailed because of mailing list size and document size. Approximate URLs for these drafts are: ftp://ftp.nrl.navy.mil/pub/security/draft-ietf-ipsec-esp-des-cbc-*.txt ftp://ftp.nrl.navy.mil/pub/security/draft-ietf-ipsec-ah-md5--*.txt A note about ftp.nrl.navy.mil: Like many modern anonymous ftp sites, you should type either your "loginid@your.domain" or "guest@" for the password instead of just "guest". Also, that system will do an inverse DNS lookup on your IP address -- if that inverse DNS lookup fails you might not be allowed access. Any system properly registered in the DNS should have no technical problems accessing the site. If there are problems and you've followed these instructions, please send email to atkinson@itd.nrl.navy.mil and I'll work on the problem. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Mar 24 20:00:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18615 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 15:14:35 -0500 Received: by interlock.ans.net id AA08961 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 15:06:29 -0500 Message-Id: <199503242006.AA08961@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 15:06:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 15:06:29 -0500 Date: Fri, 24 Mar 1995 15:00:18 -0500 From: "Ray I. McFarland Jr." To: ipsec@ans.net Subject: request to subscribe Cc: rimcfar@afterlife.ncsc.mil -request to subscribe From ipsec-request@ans.net Fri Mar 24 22:29:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26896 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 17:49:21 -0500 Received: by interlock.ans.net id AA31369 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 17:38:02 -0500 Message-Id: <199503242238.AA31369@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 24 Mar 1995 17:38:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 17:38:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 17:38:02 -0500 To: ipsec@ans.net Cc: jis@mit.edu, deering@parc.xerox.com, rcallon@pobox.wellfleet.com, hinden@ipsilon.com, bound@zk3.dec.com Subject: IPv6 Security Last Call Initial Questions Date: Fri, 24 Mar 95 17:29:03 -0500 From: bound@zk3.dec.com X-Mts: smtp Ran, If you can respond to these initial questions it would be appreciated. I have other input regarding style and editing in the document I will send privately to you. Ran as author I would appreciate responses from you, others will be listened to (and most likely not responded to which DOES NOT mean I agree), your response is the important one for this last call, as author. 1. Is draft-ietf-ipsec-arch-00.txt going to be an Informational RFC only? The reason I ask is that there is much text in ipsec that does not apply to an actual implementation, but is history, opinions on directions, and boilerplate type material. I believe this is good data in an Informational RFC like the Hinden IPng White Paper and useful to the IETF community at large, but not necessary or useful in a proposed standard. The standard that goes with the IPng White Paper is the Deering/Hinden IPv6 Base Specification, which is a good example of how a standard to implement should be written. 2. DES-CBC Encryption. Could I get the formal answer to this question from you for the record? This question could also be asked of the IESG at that Last Call effort too [if necessary]. An IPv6 implementation is required (MUST) to implement DES-CBC. Yet in my country (U.S.A.) being conformant means that vendors MUST build a product that cannot be exported to the International market. Changing it to SHOULD would eliminate this objection to the draft. Why cannot we use the word SHOULD? 3. The term 'userid' is used in the drafts for the sending host. What is the 'userid' and how do I know as an implementor where I get the userid on a node? 4. Could we have examples of manual configuration, host to host keying, and user to user keying? I am not sure how I should implement any of these, and in the case of user to user keying, I am not clear what that actually means? 5. In 4. Key Management section. 'Support for key management methods where the key management data is carried within the IP layer is not a design objective for these IP-layer security mechanisms.' If this means it will not work then I think a standard should say that, or else say nothing. Saying this means nothing to me as an implementor. I cannot test for this case, so why is it an implementation standard? This last point is critical. Statements in standards for which I cannot implement as a test case is suspect as to the words being useful for an implementor. 6. Security warnings and statements of potential attack. Would it be possible to put these in an appendix, when they are not in the standard to provide implementation details? 7. The specs reference two new IDs (or work in progress) for MD5 and DES-CBC? These are new. Are these the specifications you are stating to implement MD5 and DES-CBC? Because you have stated MUST, if these specs cannot be made proposed in the same time frame as your standard, it will hold up the IPv6 Security work from going to proposed standard. By saying SHOULD or they are an option, you free your work from those work items reaching proposed standard IMHO. thanks /jim From ipsec-request@ans.net Sat Mar 25 01:09:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18833 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 20:14:33 -0500 Received: by interlock.ans.net id AA17653 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 20:08:59 -0500 Message-Id: <199503250108.AA17653@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 20:08:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 20:08:59 -0500 X-Sender: jis@e40-po.mit.edu (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Mar 1995 20:09:01 -0500 To: bound@zk3.dec.com From: jis@mit.edu (Jeffrey I. Schiller) Subject: Re: IPv6 Security Last Call Initial Questions Cc: ipsec@ans.net, jis@mit.edu, deering@parc.xerox.com, rcallon@pobox.wellfleet.com, hinden@ipsilon.com, bound@zk3.dec.com At 17:29 3/24/95, bound@zk3.dec.com wrote: >2. DES-CBC Encryption. Could I get the formal answer to this question > from you for the record? This question could also be asked of the IESG > at that Last Call effort too [if necessary]. > > An IPv6 implementation is required (MUST) to implement DES-CBC. Yet > in my country (U.S.A.) being conformant means that vendors MUST build a > product that cannot be exported to the International market. > Changing it to SHOULD would eliminate this objection to the draft. > > Why cannot we use the word SHOULD? I'll throw my two cents in here. It says MUST because in the IETF when one designs a protocol that permits different algorithm suites, one must be specified as required. Otherwise it would be possible for two conforming implementations to not interoperate. The name of the game *is* interoperation, so this really isn't a good situation to be in. A long time ago we decided within the IETF that we will standardize on strong security technology and not let the foibles of one (or more) governments cause us to standardize less then strong alternatives (like 40 bit keyed RC4). Now given that we must have a required algorithm, what are our alternatives: 1) DES-CBC (or something similar) which has export problems from the U.S. and some other countries. 2) 40 bit RC4, which we really cannot standardize because RC4 is an unpublished trade-secret algorithm of a proprietary nature (one can argue that since its publication on the Internet, the cat is out of the bag, but the technology authors have yet to acknowledge that fact and we don't want to fight this one). This approach also may violate the "we use strong stuff" criteria. We could just punt on ESP, which I am sure some governments would think is just fine. However, to me, the whole point of standardizing ESP is to have a strong confidentiality service. Given U.S. export control law, some vendors will choose to not implement ESP, even for domestic use. If customers want it, they will go to other vendors. Overseas other companies can market ESP based products within their own countries and beyond (depending upon their laws). My opinion is that U.S. vendors should spend their efforts working with the U.S. government to remove the byzantine and counter productive export control laws rather then insist that the Internet standards process give them an easy out. Sorry. That's how I feel about it. -Jeff From ipsec-request@ans.net Sat Mar 25 01:11:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17954 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 20:17:36 -0500 Received: by interlock.ans.net id AA12627 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 20:13:18 -0500 Message-Id: <199503250113.AA12627@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 24 Mar 1995 20:13:18 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 20:13:18 -0500 Date: Fri, 24 Mar 1995 17:11:52 -0800 From: touch@ISI.EDU Posted-Date: Fri, 24 Mar 1995 17:11:52 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 20:13:18 -0500 To: ipsec@ans.net Subject: Re: MD5 versus SHA Cc: touch@ISI.EDU The following was forwarded at Bill Simpson's request. These updated MD5 numbers appear in a Sigcomm '95 submission, which is not being widely distributed until the notifications (at Sigcomm's request). The SHA and DES performance figures will appear in the updated publication, presuming acceptance. Joe Touch touch@isi.edu http://www.isi.edu/div7/atomic2 From touch@ISI.EDU Wed Mar 22 15:51:54 1995 Date: Wed, 22 Mar 1995 15:50:36 -0800 To: bill.simpson@um.cc.umich.edu Subject: Re: MD5 versus SHA ... I ran some preliminary numbers through SHA, and found it to be worse than MD5. I also measured a "fast" DES too: MD5 (orig) MD5 (opt) SHA DES (desCore) Sun 10/51 34 Mbps 37 Mbps 19 Mbps 20 Mbps Sun 20/61 36 Mbps 38 Mbps 23 Mbps 29 Mbps Sun 20/71 54 Mbps 57 Mbps 29 Mbps 37 Mbps So in speed: MD5 > DES > SHA I hope that helps a little... Joe ----- End Included Message ----- From ipsec-request@ans.net Fri Mar 24 22:36:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21709 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 20:32:59 -0500 Received: by interlock.ans.net id AA17571 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 20:28:48 -0500 Message-Id: <199503250128.AA17571@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 20:28:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 20:28:48 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.eng.sun.com Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-esp-des-cbc-03.txt Date: Fri, 24 Mar 95 17:36:28 -0500 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-03.txt Pages : 8 Date : 03/23/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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-des-cbc-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) 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-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: <19950323135417.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-des-cbc-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-des-cbc-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950323135417.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Fri Mar 24 22:36:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21717 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 20:33:54 -0500 Received: by interlock.ans.net id AA15005 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 20:28:43 -0500 Message-Id: <199503250128.AA15005@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 20:28:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 20:28:43 -0500 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@ans.net From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.eng.sun.com Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-ah-md5-02.txt Date: Fri, 24 Mar 95 17:36:23 -0500 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-02.txt Pages : 4 Date : 03/23/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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-md5-02.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-ietf-ipsec-ah-md5-02.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: <19950323134830.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-md5-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-md5-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950323134830.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Fri Mar 24 22:37:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14929 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 20:51:29 -0500 Received: by interlock.ans.net id AA17700 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 20:47:02 -0500 Message-Id: <199503250147.AA17700@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 20:47:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 20:47:02 -0500 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-00.txt Date: Fri, 24 Mar 95 17:37:04 -0500 Sender: cclark@CNRI.Reston.VA.US --NextPart A New 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-00.txt Pages : 12 Date : 03/23/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-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-00.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-ietf-ipsec-esp-00.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: <19950324173111.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950324173111.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Fri Mar 24 22:37:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18522 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 20:55:19 -0500 Received: by interlock.ans.net id AA09542 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 20:49:39 -0500 Message-Id: <199503250149.AA09542@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 20:49:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 20:49:39 -0500 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-00.txt Date: Fri, 24 Mar 95 17:37:18 -0500 Sender: cclark@CNRI.Reston.VA.US --NextPart A New 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-00.txt Pages : 11 Date : 03/23/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. In addition, this document describes the use of keyed MD5 in conjunction with this 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-auth-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-auth-00.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-ietf-ipsec-auth-00.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: <19950323165047.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950323165047.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Fri Mar 24 22:37:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21087 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 20:55:25 -0500 Received: by interlock.ans.net id AA08257 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 20:49:36 -0500 Message-Id: <199503250149.AA08257@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 20:49:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 20:49:36 -0500 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-00.txt Date: Fri, 24 Mar 95 17:37:12 -0500 Sender: cclark@CNRI.Reston.VA.US --NextPart A New 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-00.txt Pages : 19 Date : 03/23/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-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-00.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-ietf-ipsec-arch-00.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: <19950324173009.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950324173009.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Sat Mar 25 02:55:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18135 (5.65c/IDA-1.4.4 for ); Fri, 24 Mar 1995 21:59:44 -0500 Received: by interlock.ans.net id AA10235 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 24 Mar 1995 21:55:31 -0500 Message-Id: <199503250255.AA10235@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 24 Mar 1995 21:55:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 24 Mar 1995 21:55:31 -0500 Date: Fri, 24 Mar 1995 21:55:39 -0500 (EST) From: Scott Bradner To: bound@zk3.dec.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions Cc: deering@parc.xerox.com, hinden@ipsilon.com, jis@mit.edu, rcallon@pobox.wellfleet.com Jim, Ran may also respond but this is a co-AD response 1. Is draft-ietf-ipsec-arch-00.txt going to be an Informational RFC only? >> this sounds like a thing to think about - it does make sense to me 2. DES-CBC Encryption. Could I get the formal answer to this question from you for the record? This question could also be asked of the IESG at that Last Call effort too [if necessary]. An IPv6 implementation is required (MUST) to implement DES-CBC. Yet in my country (U.S.A.) being conformant means that vendors MUST build a product that cannot be exported to the International market. Changing it to SHOULD would eliminate this objection to the draft. Why cannot we use the word SHOULD? >> This issue was dicussed within the IPng directorate, the IESG and the >> IAB and the (non-unanimous) consensus was that it should be a requirement >> that all complient IPv6 implementatons must support encryption and a >> specific encryption protocol. The IESG in approving the IPng >> recommendation (RFC 1752) as a Proposed Standard endorced that >> position. 5. In 4. Key Management section. 'Support for key management methods where the key management data is carried within the IP layer is not a design objective for these IP-layer security mechanisms.' If this means it will not work then I think a standard should say that, or else say nothing. Saying this means nothing to me as an implementor. I cannot test for this case, so why is it an implementation standard? This last point is critical. Statements in standards for which I cannot implement as a test case is suspect as to the words being useful for an implementor. >> The reason to have any mention of this type is to ensure that some >> implementer not assume that the specific requirements of that type >> of key management will be fully met by this proposal. The requirements >> may or may not be met but the specific work has not been done to be >> sure which. 7. The specs reference two new IDs (or work in progress) for MD5 and DES-CBC? These are new. Are these the specifications you are stating to implement MD5 and DES-CBC? Because you have stated MUST, if these specs cannot be made proposed in the same time frame as your standard, it will hold up the IPv6 Security work from going to proposed standard. By saying SHOULD or they are an option, you free your work from those work items reaching proposed standard IMHO. >> these two IDs were posted today and should be ready for advancement >> at the same time as Ran's documents. Scott From ipsec-request@ans.net Sun Mar 26 12:19:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19529 (5.65c/IDA-1.4.4 for ); Sun, 26 Mar 1995 17:44:46 -0500 Received: by interlock.ans.net id AA11667 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 26 Mar 1995 17:41:28 -0500 Message-Id: <199503262241.AA11667@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 26 Mar 1995 17:41:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 26 Mar 1995 17:41:28 -0500 Date: Sun, 26 Mar 95 17:19:45 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: key-ed MD5 again (and before any final call) Ran's draft (draft-ietf-ipsec-auth-00.txt) requires MD5(key,text,key) but also requires compliance with: [MS95] Perry Metzger & Bill Simpson, "IP Authentication with Keyed MD5", Work in Progress, 21 March 1995. which I did not see. However, in the document by these authors titled "draft-ietf-ipsec-ah-md5-02.txt" it says: The invariant fields of the entire IP datagram are hashed first. The variable length secret authentication key is concatenated with (immediately followed by) this initial 128-bit digest, and the combination is hashed again. This final 128-bit digest is inserted into the Authentication Data field. So there seems to be a potential contradiction here. MOST IMPORTANTLY, the later proposal (i.e., MD5(key,MD5(text)) ) can be easily and significantly improved to MD5(key,MD5(key,text)) (key included in the internal MD5). In other words, MD5(key,MD5(text)) must be abandoned (at least, I strongly oppose it) Hugo From ipsec-request@ans.net Mon Mar 27 04:43:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06740 (5.65c/IDA-1.4.4 for ); Mon, 27 Mar 1995 09:52:25 -0500 Received: by interlock.ans.net id AA17549 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Mar 1995 09:48:07 -0500 Message-Id: <199503271448.AA17549@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Mar 1995 09:48:07 -0500 To: ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: fast DES information Content-Length: 477 Date: Mon, 27 Mar 95 9:43:14 EST From: Ran Atkinson Sender: rja@bodhi.cs.nrl.navy.mil In a posting to sci.crypt.research, Bruce Schneier indicates that VLSI's commercial DES chip (the 6868) has a 32 MHz clock and encrypts data at 256 MB/second. Bruce also reports that a DEC Alpha 4000/610 can encrypt DES at 154,000 8-byte encryptions per second. I mention this only in the context of earlier concerns about getting DES to encrypt at high speeds. This is not and must not be misconstrued as a product endorsement of any sort. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Mar 27 14:30:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18466 (5.65c/IDA-1.4.4 for ); Mon, 27 Mar 1995 10:16:43 -0500 Received: by interlock.ans.net id AA32868 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Mar 1995 10:07:49 -0500 Message-Id: <199503271507.AA32868@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 Mar 1995 10:07:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Mar 1995 10:07:49 -0500 Date: Mon, 27 Mar 95 14:30:28 GMT From: "William Allen Simpson" To: IPSEC@ans.net Subject: Re: key-ed MD5 again (and before any final call) First, I will reply to your inane subject line: I issued a last call on this topic some weeks ago. The IPng WG has now issued a last call, but the discussion is taking place on this list. Copy of the announcement appended. Second, as to your obtuse inability to read the drafts: > From: hugo@watson.ibm.com > Ran's draft (draft-ietf-ipsec-auth-00.txt) > requires MD5(key,text,key) but also requires compliance with: > > [MS95] Perry Metzger & Bill Simpson, "IP Authentication with Keyed MD5", > Work in Progress, 21 March 1995. > > which I did not see. > > However, in the document by these authors titled > "draft-ietf-ipsec-ah-md5-02.txt" it says: > It's surprising that you did not see this draft, since it was announced to this list _before_ Ran's drafts. Obviously, you have had some difficulty with your transfer of the text, since my transfer just now from ds.internic.net yielded: IP Authentication using Keyed MD5 draft-ietf-ipsec-ah-md5-02.txt | This is amazingly close to the reference. The RFC Editor will touch up the references section when RFCs are published. Bill.Simpson@um.cc.umich.edu Date: Thu, 23 Mar 1995 13:17:32 -0500 (EST) From: Scott Bradner Message-Id: <199503231817.NAA22623@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: (IPng) IPng W.G. Last Call for Security Drafts Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reply-To: ipng@sunroof.eng.sun.com please do all discussions on these documents on the ipsec mailing list (ipsec@ans.net) ( -request to subscribe ) thanks Scott ----- Date: Thu, 23 Mar 1995 09:35:16 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@ipsilon.com (Bob Hinden) Subject: (IPng) IPng W.G. Last Call for Security Drafts Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The constitutes the IPng working group last call for the three security drafts. The period of the last call is one week. Bob >Date: Thu, 23 Mar 95 11:43:15 EST >From: atkinson@itd.nrl.navy.mil (Ran Atkinson) >To: ipng@sunroof2.Eng.Sun.COM, ipsec@ans.net >Subject: (IPng) new Security Drafts available for ftp >Sender: owner-ipng@sunroof.Eng.Sun.COM >Precedence: bulk >Reply-To: ipng@sunroof.Eng.Sun.COM > >Folks, > > Revised security drafts are available via anonymous ftp from >ftp.nrl.navy.mil. I'm not sending them via email because I'm told the >list is now too large for big I-Ds to be posted to it. > > They have also been submitted to the I-D archive folks at CNRI and >should appear at the usual I-D archive sites when those folks get >time. They will appear with the prefix draft-ietf-ipsec-*.txt >at the I-D archive sites. > > The online IPng drafts having a prefix of draft-ietf-ipngwg-esp-*, >draft-ietf-ipngwg-auth-*, and draft-ietf-ipngwg-sec-* are now >obsoleted by these new drafts. > > >Approximate URLs are: > ftp://ftp.nrl.navy.mil/pub/security/ip-auth.txt > ftp://ftp.nrl.navy.mil/pub/security/ip-esp.txt > ftp://ftp.nrl.navy.mil/pub/security/ip-sec.txt > >Ran >atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Mar 27 14:48:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16673 (5.65c/IDA-1.4.4 for ); Mon, 27 Mar 1995 10:16:43 -0500 Received: by interlock.ans.net id AA20586 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Mar 1995 10:07:51 -0500 Message-Id: <199503271507.AA20586@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 Mar 1995 10:07:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Mar 1995 10:07:51 -0500 Date: Mon, 27 Mar 95 14:48:58 GMT From: "William Allen Simpson" To: IPSEC@ans.net Subject: Re: key-ed MD5 again > From: hugo@watson.ibm.com > Ran's draft (draft-ietf-ipsec-auth-00.txt) > requires MD5(key,text,key) You are incorrect. This does not appear anywhere in the text. The text does contain an error, left over from an earlier verion of the draft, which should be removed. When a keyed message digest algorithm (e.g. MD5) is used, the secret key is fed into the algorithm first, followed by the invariant fields of the IP datagram in sequence and then concluding by feeding the secret key in a second time. We long ago agreed that these transform dependent information must be in the transforms, not the AH text. Thank you for the reminder. > MOST IMPORTANTLY, the later proposal (i.e., MD5(key,MD5(text)) ) > can be easily and significantly improved to MD5(key,MD5(key,text)) > (key included in the internal MD5). > This is silly. It might be stronger (although this mere conjecture was not proven in your message), but there are even stronger possibilities that have been previously mentioned, including using the key on every MD5 block. This type of criticism is based on wishful thinking. Ultimate "strength" is not an issue. Some significant analysts think that a single key at the beginning of MD5 does not provide enough key material when the text is long. The MD5(key,MD5(text)) was suggested to improve the effect of the key in the final hash. > In other words, MD5(key,MD5(text)) must be abandoned > (at least, I strongly oppose it) > You've said this before. Why do you waste our time repeating yourself? Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Mon Mar 27 16:43:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17757 (5.65c/IDA-1.4.4 for ); Mon, 27 Mar 1995 11:53:11 -0500 Received: by interlock.ans.net id AA39820 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Mar 1995 11:48:36 -0500 Message-Id: <199503271648.AA39820@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Mar 1995 11:48:36 -0500 From: Ran Atkinson Date: Mon, 27 Mar 1995 11:43:30 -0500 In-Reply-To: bound@zk3.dec.com "IPv6 Security Last Call Initial Questions" (Mar 24, 17:29) References: <199503242238.AA31369@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil On Mar 24, 17:29, bound@zk3.dec.com wrote: %1. Is draft-ietf-ipsec-arch-00.txt going to be an Informational RFC % only? % The reason I ask is that there is much text in ipsec that does not % apply to an actual implementation, but is history, opinions on % directions, and boilerplate type material. I believe this is good % data in an Informational RFC like the Hinden IPng White Paper and % useful to the IETF community at large, but not necessary or useful % in a proposed standard. The standard that goes with the IPng White % Paper is the Deering/Hinden IPv6 Base Specification, which is a good % example of how a standard to implement should be written. At present, the architecture document contains significant amounts of standards-track material (to give one example, the definition of a "Security Association", as that term is used by both ESP and AH, only exists there). Hence that document currently needs to be on the standards-track. Much of the material common to ESP and AH specifications was moved into the Security Architecture document in response to suggestions from others (including Scott Bradner) that the material common to both the ESP and AH specs should be consolidated into the Security Architecture draft. That standards-track material needs to be in a standards-track RFC that moves in parallel with the ESP and AH drafts. If the Sec Arch document were not standards-track, then that standards-track material would need to be moved into a standards-track draft prior to Proposed Standard RFCs being issued. % 2. DES-CBC Encryption. Could I get the formal answer to this question % from you for the record? This question could also be asked of the % IESG at that Last Call effort too [if necessary]. % % An IPv6 implementation is required (MUST) to implement DES-CBC. Yet % in my country (U.S.A.) being conformant means that vendors MUST build % a product that cannot be exported to the International market. % Changing it to SHOULD would eliminate this objection to the draft. Please permit me to make a correction. DES _is_ exportable from the US. Depending on how it is going to be used and the intended customer, export of DES might require an export license from the US Government. There are many known cases of such export licenses being issued. There is widespread belief that it can be time consuming to obtain such export licenses. % Why cannot we use the word SHOULD? There is rough consensus that implementation of encryption is mandatory for IPv6. The word "MUST" is used to indicate mandatory items. The word "SHOULD" is used to indicate items that are not absolutely mandatory. Changing "MUST" to "SHOULD" would decrease consensus because it would eliminate the requirement that encryption be implemented in all IPv6 systems. % 3. The term 'userid' is used in the drafts for the sending host. % % What is the 'userid' and how do I know as an implementor where I get % the userid on a node? A "userid" is an implementation-specific identifier used to distinguish between different users of a system. In the case of POSIX.1 systems, the "uid" would map nicely to a "userid". Implementation-specific methods are used to obtain a userid. In the case of a UNIX operating system, the getuid() or geteuid() calls might be used by an implementation. On other systems (for example, HP MPE or IBM MVS), other implementation-specific calls would be used. % 4. Could we have examples of manual configuration, host to host keying, % and user to user keying? % % I am not sure how I should implement any of these, and in the case of % user to user keying, I am not clear what that actually means? Are you reading the most recent documents ? I don't believe the terms "host-to-host" and "user-to-user" appear in the current drafts. If they do, it is an editing error that I somehow missed. The corrected terms are "host-oriented" and "user-oriented" keying. The text in this area was completely rewritten in response to feedback from various people. The text should be reasonably clear in the current draft. I believe the existing text noted that manual configuration could mean that one put the keys and other data in a flat file. If desired, I could create an informational (i.e. not standards-track) appendix illustrating one possible flat file format that could be used. There is significant detail in the ESP and AH drafts on the process by which an incoming or outgoing packet is handled. The combination of that text and the text in the Security Architecture makes clear how to implement this. This is one of several reasons that the ESP and AH drafts cite the Architecture draft as standards-track. All 5 drafts need to be read as a set. % 5. In 4. Key Management section. % % 'Support for key management methods where the key management data is % carried within the IP layer is not a design objective for these % IP-layer security mechanisms.' % % If this means it will not work then I think a standard should say % that, or else say nothing. Saying this means nothing to me as an % implementor. I cannot test for this case, so why is it an % implementation standard? % % This last point is critical. Statements in standards for which I % cannot implement as a test case is suspect as to the words being % useful for an implementor. There is rough consensus that this information is important to implementers so that there is a clear understanding of what the design objectives were and were not for the security specifications. Removing that language would decrease consensus. Many existing Internet standards contain similar language about design goals. The IETF document style is significantly different from that of other standards groups such as IEEE and ANSI. This document complies with IETF document style because it is an IETF document. % 6. Security warnings and statements of potential attack. % % Would it be possible to put these in an appendix, when they are not % in the standard to provide implementation details? Within RFCs, the "Security Considerations" section is supposed to describe security issues and residual security risks relating to the material described in that document. Moving these to an appendix would not conform to IETF document standards (see RFC-1543, Section 8). Further, removing that material would decrease consensus. % 7. The specs reference two new IDs (or work in progress) for MD5 and % DES-CBC? % These are new. Are these the specifications you are stating to % implement MD5 and DES-CBC? Because you have stated MUST, if these % specs cannot be made proposed in the same time frame as your % standard, it will hold up the IPv6 Security work from going to % proposed standard. By saying SHOULD or they are an option, you free % your work from those work items reaching proposed standard IMHO. These were actually announced by the InterNIC prior to their announcement of my drafts. All 5 drafts were actually available online at the Internet-Drafts directories for significant time prior to their announcement by CNRI. Further, all 5 drafts were ftp'able from ftp.nrl.navy.mil even prior to their announcement by the InterNIC and that location was announced by me to IPng and IPsec mailing lists. Those drafts contain much clearer text describing the security transforms and are improved versions of the text formerly in Appendix A of the ESP and AH drafts. The revised text is based on implementation experience of Phil Karn and Perry Metzger. It is intended that all 5 drafts move forward as a set. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Mar 27 16:43:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25126 (5.65c/IDA-1.4.4 for ); Mon, 27 Mar 1995 13:21:09 -0500 Message-Id: <199503271821.AA25126@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Mon, 27 Mar 1995 13:19:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Mar 1995 13:19:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Mon, 27 Mar 1995 13:19:06 -0500 From: Ran Atkinson Date: Mon, 27 Mar 1995 11:43:30 -0500 In-Reply-To: bound@zk3.dec.com "IPv6 Security Last Call Initial Questions" (Mar 24, 17:29) References: <199503242238.AA31369@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil On Mar 24, 17:29, bound@zk3.dec.com wrote: %1. Is draft-ietf-ipsec-arch-00.txt going to be an Informational RFC % only? % The reason I ask is that there is much text in ipsec that does not % apply to an actual implementation, but is history, opinions on % directions, and boilerplate type material. I believe this is good % data in an Informational RFC like the Hinden IPng White Paper and % useful to the IETF community at large, but not necessary or useful % in a proposed standard. The standard that goes with the IPng White % Paper is the Deering/Hinden IPv6 Base Specification, which is a good % example of how a standard to implement should be written. At present, the architecture document contains significant amounts of standards-track material (to give one example, the definition of a "Security Association", as that term is used by both ESP and AH, only exists there). Hence that document currently needs to be on the standards-track. Much of the material common to ESP and AH specifications was moved into the Security Architecture document in response to suggestions from others (including Scott Bradner) that the material common to both the ESP and AH specs should be consolidated into the Security Architecture draft. That standards-track material needs to be in a standards-track RFC that moves in parallel with the ESP and AH drafts. If the Sec Arch document were not standards-track, then that standards-track material would need to be moved into a standards-track draft prior to Proposed Standard RFCs being issued. % 2. DES-CBC Encryption. Could I get the formal answer to this question % from you for the record? This question could also be asked of the % IESG at that Last Call effort too [if necessary]. % % An IPv6 implementation is required (MUST) to implement DES-CBC. Yet % in my country (U.S.A.) being conformant means that vendors MUST build % a product that cannot be exported to the International market. % Changing it to SHOULD would eliminate this objection to the draft. Please permit me to make a correction. DES _is_ exportable from the US. Depending on how it is going to be used and the intended customer, export of DES might require an export license from the US Government. There are many known cases of such export licenses being issued. There is widespread belief that it can be time consuming to obtain such export licenses. % Why cannot we use the word SHOULD? There is rough consensus that implementation of encryption is mandatory for IPv6. The word "MUST" is used to indicate mandatory items. The word "SHOULD" is used to indicate items that are not absolutely mandatory. Changing "MUST" to "SHOULD" would decrease consensus because it would eliminate the requirement that encryption be implemented in all IPv6 systems. % 3. The term 'userid' is used in the drafts for the sending host. % % What is the 'userid' and how do I know as an implementor where I get % the userid on a node? A "userid" is an implementation-specific identifier used to distinguish between different users of a system. In the case of POSIX.1 systems, the "uid" would map nicely to a "userid". Implementation-specific methods are used to obtain a userid. In the case of a UNIX operating system, the getuid() or geteuid() calls might be used by an implementation. On other systems (for example, HP MPE or IBM MVS), other implementation-specific calls would be used. % 4. Could we have examples of manual configuration, host to host keying, % and user to user keying? % % I am not sure how I should implement any of these, and in the case of % user to user keying, I am not clear what that actually means? Are you reading the most recent documents ? I don't believe the terms "host-to-host" and "user-to-user" appear in the current drafts. If they do, it is an editing error that I somehow missed. The corrected terms are "host-oriented" and "user-oriented" keying. The text in this area was completely rewritten in response to feedback from various people. The text should be reasonably clear in the current draft. I believe the existing text noted that manual configuration could mean that one put the keys and other data in a flat file. If desired, I could create an informational (i.e. not standards-track) appendix illustrating one possible flat file format that could be used. There is significant detail in the ESP and AH drafts on the process by which an incoming or outgoing packet is handled. The combination of that text and the text in the Security Architecture makes clear how to implement this. This is one of several reasons that the ESP and AH drafts cite the Architecture draft as standards-track. All 5 drafts need to be read as a set. % 5. In 4. Key Management section. % % 'Support for key management methods where the key management data is % carried within the IP layer is not a design objective for these % IP-layer security mechanisms.' % % If this means it will not work then I think a standard should say % that, or else say nothing. Saying this means nothing to me as an % implementor. I cannot test for this case, so why is it an % implementation standard? % % This last point is critical. Statements in standards for which I % cannot implement as a test case is suspect as to the words being % useful for an implementor. There is rough consensus that this information is important to implementers so that there is a clear understanding of what the design objectives were and were not for the security specifications. Removing that language would decrease consensus. Many existing Internet standards contain similar language about design goals. The IETF document style is significantly different from that of other standards groups such as IEEE and ANSI. This document complies with IETF document style because it is an IETF document. % 6. Security warnings and statements of potential attack. % % Would it be possible to put these in an appendix, when they are not % in the standard to provide implementation details? Within RFCs, the "Security Considerations" section is supposed to describe security issues and residual security risks relating to the material described in that document. Moving these to an appendix would not conform to IETF document standards (see RFC-1543, Section 8). Further, removing that material would decrease consensus. % 7. The specs reference two new IDs (or work in progress) for MD5 and % DES-CBC? % These are new. Are these the specifications you are stating to % implement MD5 and DES-CBC? Because you have stated MUST, if these % specs cannot be made proposed in the same time frame as your % standard, it will hold up the IPv6 Security work from going to % proposed standard. By saying SHOULD or they are an option, you free % your work from those work items reaching proposed standard IMHO. These were actually announced by the InterNIC prior to their announcement of my drafts. All 5 drafts were actually available online at the Internet-Drafts directories for significant time prior to their announcement by CNRI. Further, all 5 drafts were ftp'able from ftp.nrl.navy.mil even prior to their announcement by the InterNIC and that location was announced by me to IPng and IPsec mailing lists. Those drafts contain much clearer text describing the security transforms and are improved versions of the text formerly in Appendix A of the ESP and AH drafts. The revised text is based on implementation experience of Phil Karn and Perry Metzger. It is intended that all 5 drafts move forward as a set. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Mon Mar 27 18:28:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26758 (5.65c/IDA-1.4.4 for ); Mon, 27 Mar 1995 13:32:37 -0500 Received: by interlock.ans.net id AA14198 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Mar 1995 13:29:57 -0500 Message-Id: <199503271829.AA14198@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 27 Mar 1995 13:29:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 27 Mar 1995 13:29:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 27 Mar 1995 13:29:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 Mar 1995 13:29:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Mar 1995 13:29:57 -0500 Date: Mon, 27 Mar 1995 10:28:26 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipsec@ans.net Subject: IPv6 Security Last Call Questions Cc: deering@parc.xerox.com, jis@mit.edu, rcallon@pobox.wellfleet.com, sob@newdev.harvard.edu X-Sun-Charset: US-ASCII Ran, As author of the IPv6 security architecture document, I wonder if you would respond to the following two questions : Question 1 ---------- In section 4.6, the first paragraph, it states : This section defines key management requirements for all IPv6 implementations and for those IPv4 implementations that implement the IP Authentication Header, the IP Encapsulating Security Payload, or both. In section 4.6, the second paragraph, it states : All such implementations MUST support the configuration and use of user-oriented keying for traffic originating at that system. In section 4.6, the third paragraph, it states : A device that encrypts or authenticates IP packets originated on other systems, for example a dedicated IP encryptor or an encrypting gateway, cannot generally provide user-oriented keying for traffic originating on other systems. Hence, such systems MUST implement support for host-oriented keying for traffic originating on other systems. Such systems MAY additionally implement support for user-oriented keying for traffic originating on other systems. Since the first paragraph makes it clear that the subsequent text applies to *all* IPv6 implementations and *all* IPv4 implementations that implement the IP Authentication Header, the IP Encapsulating Security Payload, or both, the text in paragraphs 2 and 3 seem inconsistent. In paragraph 2 you specify that all implementations MUST support user-oriented keying and then in paragraph 3 you state that certain implementations cannot generally do so for traffic originating on other systems. Could you clarify this point? Question 2 ---------- Several highly respected experts in the field of cryptography and computer communications have offered an opinion that the cryptanalytic threats used to motivate mandatory user-oriented keying are effectively countered by more traditional techniques, e.g., proper management of the session key cryptoperiod. In view of this, could you explain why user-oriented keying remains a mandatory requirement? Thanks. Regards, Dan From ipsec-request@ans.net Mon Mar 27 22:05:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07185 (5.65c/IDA-1.4.4 for ); Mon, 27 Mar 1995 17:10:58 -0500 Received: by interlock.ans.net id AA02853 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Mar 1995 17:06:37 -0500 Message-Id: <199503272206.AA02853@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 27 Mar 1995 17:06:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 Mar 1995 17:06:37 -0500 Date: Mon, 27 Mar 1995 14:05:09 -0800 From: touch@ISI.EDU Posted-Date: Mon, 27 Mar 1995 14:05:09 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Mar 1995 17:06:37 -0500 To: ipsec@ans.net Subject: Re: MD5 versus SHA Cc: touch@ISI.EDU Earlier I posted the following information. It has been pointed out that the DES code I used probably is showing caching effects which are unrealistic for comparison to the MD5 code. Running DES over a 2 M byte file in /tmp (RAM), I got the following numbers: DES (libDes) Sun 10/51 5.7 Mbps Sun 20/61 7.5 Mbps Sun 20/71 9.5 Mbps I'm not sure if the desCore numbers are realistic, as a result. Joe > The following was forwarded at Bill Simpson's request. > > These updated MD5 numbers appear in a Sigcomm '95 submission, > which is not being widely distributed until the notifications > (at Sigcomm's request). The SHA and DES performance figures > will appear in the updated publication, presuming acceptance. > > Joe Touch > touch@isi.edu > http://www.isi.edu/div7/atomic2 > > >From touch@ISI.EDU Wed Mar 22 15:51:54 1995 > Date: Wed, 22 Mar 1995 15:50:36 -0800 > To: bill.simpson@um.cc.umich.edu > Subject: Re: MD5 versus SHA > ... > > I ran some preliminary numbers through SHA, and found it to be > worse than MD5. I also measured a "fast" DES too: > > MD5 (orig) MD5 (opt) SHA DES (desCore) > > Sun 10/51 34 Mbps 37 Mbps 19 Mbps 20 Mbps > Sun 20/61 36 Mbps 38 Mbps 23 Mbps 29 Mbps > Sun 20/71 54 Mbps 57 Mbps 29 Mbps 37 Mbps > > > So in speed: > > MD5 > DES > SHA > > I hope that helps a little... > > Joe From ipsec-request@ans.net Mon Mar 27 21:55:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25207 (5.65c/IDA-1.4.4 for ); Mon, 27 Mar 1995 18:04:17 -0500 Received: by interlock.ans.net id AA25774 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Mar 1995 17:58:44 -0500 Message-Id: <199503272258.AA25774@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Mon, 27 Mar 1995 17:58:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 27 Mar 1995 17:58:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 27 Mar 1995 17:58:44 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 Mar 1995 17:58:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Mar 1995 17:58:44 -0500 Date: 27 Mar 95 15:55:00 -0600 To: ipsec@ans.net Subject: Working Group Last Call Working Group Last Call to Review Five security drafts have been released: draft-ietf-ipsec-arch-00.txt draft-ietf-ipsec-esp-00.txt draft-ietf-ipsec-auth-00.txt draft-ietf-ipsec-esp-des-cbc-03 draft-ietf-ipsec-ah-md5-02.txt The working group is requested to review and comment on the progression of these documents. All comments should be submitted on or before April 10th (two weeks including IETF week in Danvers). Paul A. Lambert From ipsec-request@ans.net Tue Mar 28 02:12:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15727 (5.65c/IDA-1.4.4 for ); Mon, 27 Mar 1995 21:13:04 -0500 Received: by interlock.ans.net id AA15381 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Mar 1995 21:10:19 -0500 Message-Id: <199503280210.AA15381@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 Mar 1995 21:10:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Mar 1995 21:10:19 -0500 Date: Mon, 27 Mar 1995 18:12:58 -0800 From: Phil Karn To: rja@bodhi.cs.nrl.navy.mil Cc: ipng@sunroof2.eng.sun.com, ipsec@ans.net In-Reply-To: <199503271448.AA17549@interlock.ans.net> (message from Ran Atkinson on Mon, 27 Mar 95 9:43:14 EST) Subject: Re: fast DES information >Bruce also reports that a DEC Alpha 4000/610 can encrypt DES >at 154,000 8-byte encryptions per second. Here's another data point. I recently upgraded the CPU in my home BSDI box from a 486DX2-66 to a 486DX4-100. That's a 486 with a 100 MHz internal clock and a 33 MHz external bus. In protected (32-bit) mode, the speed of my public domain DES code went up almost directly with the 1.5x increase in internal clock speed: 102,987 8-byte encryptions/sec vs 69,348/sec for the 486DX2-66. That's 6.59 megabits/sec vs 4.4 megabits/sec. My Pentium figures are all for real mode, so they aren't comparable. Phil From ipsec-request@ans.net Mon Mar 27 23:01:11 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21433 (5.65c/IDA-1.4.4 for ); Mon, 27 Mar 1995 23:01:11 -0500 Received: by interlock.ans.net id AA18337 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 27 Mar 1995 22:54:31 -0500 Message-Id: <199503280354.AA18337@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 27 Mar 1995 22:54:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 27 Mar 1995 22:54:31 -0500 From: Masataka Ohta Subject: Re: key-ed MD5 again To: Bill.Simpson@um.cc.umich.edu (William Allen Simpson) Date: Tue, 28 Mar 95 12:52:33 JST Cc: IPSEC@ans.net In-Reply-To: <199503271507.AA20586@interlock.ans.net>; from "William Allen Simpson" at Mar 27, 95 2:48 pm X-Mailer: ELM [version 2.3 PL11] > Some significant analysts think that a single key at the beginning of > MD5 does not provide enough key material when the text is long. The > MD5(key,MD5(text)) was suggested to improve the effect of the key in the > final hash. Are there any reference of the analysis? As MD5 is a chain of addition, a transitive 1-to-1 mapping, of hashed values, it is unlikely that the initial scrambling effect by the added hased key is weakened later. Masataka Ohta From ipsec-request@ans.net Tue Mar 28 17:17:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21052 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 12:24:37 -0500 Received: by interlock.ans.net id AA38758 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 12:19:25 -0500 Message-Id: <199503281719.AA38758@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 12:19:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 12:19:25 -0500 Date: Tue, 28 Mar 1995 09:17:58 -0800 From: touch@ISI.EDU Posted-Date: Tue, 28 Mar 1995 09:17:58 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 12:19:25 -0500 To: smb@research.att.com Subject: Re: MD5 versus SHA Cc: touch@ISI.EDU, ipsec@ans.net > From smb@research.att.com Tue Mar 28 09:01:47 1995 > To: touch@ISI.EDU > Cc: ipsec@ans.net > Subject: Re: MD5 versus SHA > From: "Steven M. Bellovin" > > The following was forwarded at Bill Simpson's request. > > MD5 (orig) MD5 (opt) SHA DES (de > sCore) > > Sun 10/51 34 Mbps 37 Mbps 19 Mbps 20 Mbps > Sun 20/61 36 Mbps 38 Mbps 23 Mbps 29 Mbps > Sun 20/71 54 Mbps 57 Mbps 29 Mbps 37 Mbps > > > So in speed: > > MD5 > DES > SHA > > But we know that DES can be done at at least 1Gbps in hardware. One of > the points of the draft that was circulated a while back was that MD5 > was *inherently* unable to run at that speed. Or am I missing something? Well, there are a few points to be made: a) if you can do hardware, DES is fine, and MD5 is not. b) the IP security community has (as far as I have read from RFCs) stated that software is preferable for several reasons: - compatibility with existing hardware base - agility (ability to change the algorithm if the need arises, e.g., someone cracks DES :-) c) my argument against MD5 in IPv6 is that the requirements state that IPv6 should run at least as fast as IPv4. "At least as fast" presumes the existing hardware; I can do IPv4 at 75 Mbps with no real effort, and 120 Mbps with some effort (i.e., user-level protocols sharing a kernel-based port). That's in software on the existing hardware. If I ran IPv6 on the same hardware, it'd have to be an all-software implementation, which would slow it to around 40 Mbps. What we probably need to ask is the following: - do we want a fast hardware or fast software solution? these aren't necessarily mutually exclusive, but in comparing DES and MD5 they are - what level of security is appropriate? If it's in software, we have about 2-4 instructions per 32-bit word. MD5 uses 45. Can there even exist a reasonable hash function that follows these rules: - 2-4 instructions per 32-bit word - "working set" of words is small (8? 16?) - uses only RISC instructions NO ROTATE (can take 3 opcodes to emulate) NO ONE's COMPLEMENT ADDITION (2 opcodes) NO MULTI-INPUT FUNCTIONS THAT CAN'T BE TABLE-IZED (these are just my observations, not hard-and-fast rules) Joe From ipsec-request@ans.net Tue Mar 28 16:24:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12619 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 12:27:38 -0500 Received: by interlock.ans.net id AA38395 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 12:24:40 -0500 Message-Id: <199503281724.AA38395@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 12:24:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 12:24:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 12:24:40 -0500 To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net Subject: Re: Routing Date: Tue, 28 Mar 1995 11:24:04 -0500 From: "Steven M. Bellovin" Bill, I do not see any reason why the specs should prohibit an intermediate router from being party to a Security Association between two other systems (call them S and D) as long as those systems (S and D) choose to let that router be party to their Security Association. Now key management (etc) are much harder in such usage, but that is a problem tobe solved by the users desiring such an arrangement. I don't think that any standards-track key mgmt protocol is required to solve that intermediate-router keying problem. The specs CURRENTLY DO NOT PROHIBIT such an arrangement and it might be desirable in some user communities to operate in that manner. Yup. This is by intent. At least, it was my intention that this be permitted in my input on the subject. Further, I note that the IAB Workshop report from last spring clearly stated that letting some intermediate routers be party to a Security Association might be desirable in some cases. (That RFC used different language but clearly had that meaning). Again, yes. I was at the workshop, and I pushed this point. My reasoning is very simple: given the current paucity of tamper-resistant crypto gear in the civilian market, one can often achieve greater security by doing the encryption in some ordinary box that's in a secured room. Besides, many LANs are administered as a single machine that happens to have a long skinny yellow backplane... From ipsec-request@ans.net Tue Mar 28 16:25:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12634 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 12:28:14 -0500 Received: by interlock.ans.net id AA39507 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 12:25:16 -0500 Message-Id: <199503281725.AA39507@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 12:25:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 12:25:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 12:25:16 -0500 To: touch@isi.edu Cc: ipsec@ans.net Subject: Re: MD5 versus SHA Date: Tue, 28 Mar 1995 11:25:52 -0500 From: "Steven M. Bellovin" The following was forwarded at Bill Simpson's request. These updated MD5 numbers appear in a Sigcomm '95 submission, which is not being widely distributed until the notifications (at Sigcomm's request). The SHA and DES performance figures will appear in the updated publication, presuming acceptance. Joe Touch touch@isi.edu http://www.isi.edu/div7/atomic2 MD5 (orig) MD5 (opt) SHA DES (de sCore) Sun 10/51 34 Mbps 37 Mbps 19 Mbps 20 Mbps Sun 20/61 36 Mbps 38 Mbps 23 Mbps 29 Mbps Sun 20/71 54 Mbps 57 Mbps 29 Mbps 37 Mbps So in speed: MD5 > DES > SHA But we know that DES can be done at at least 1Gbps in hardware. One of the points of the draft that was circulated a while back was that MD5 was *inherently* unable to run at that speed. Or am I missing something? From ipsec-request@ans.net Tue Mar 28 16:25:52 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21054 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 13:18:43 -0500 Message-Id: <199503281818.AA21054@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Tue, 28 Mar 1995 13:10:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 13:10:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 13:10:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 13:10:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Mar 1995 13:10:12 -0500 To: touch@isi.edu Cc: ipsec@ans.net Subject: Re: MD5 versus SHA Date: Tue, 28 Mar 1995 11:25:52 -0500 From: "Steven M. Bellovin" The following was forwarded at Bill Simpson's request. These updated MD5 numbers appear in a Sigcomm '95 submission, which is not being widely distributed until the notifications (at Sigcomm's request). The SHA and DES performance figures will appear in the updated publication, presuming acceptance. Joe Touch touch@isi.edu http://www.isi.edu/div7/atomic2 MD5 (orig) MD5 (opt) SHA DES (de sCore) Sun 10/51 34 Mbps 37 Mbps 19 Mbps 20 Mbps Sun 20/61 36 Mbps 38 Mbps 23 Mbps 29 Mbps Sun 20/71 54 Mbps 57 Mbps 29 Mbps 37 Mbps So in speed: MD5 > DES > SHA But we know that DES can be done at at least 1Gbps in hardware. One of the points of the draft that was circulated a while back was that MD5 was *inherently* unable to run at that speed. Or am I missing something? From ipsec-request@ans.net Tue Mar 28 07:50:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27461 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 13:19:00 -0500 Received: by interlock.ans.net id AA11732 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 13:12:42 -0500 Message-Id: <199503281812.AA11732@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 28 Mar 1995 13:12:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 13:12:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 13:12:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 13:12:42 -0500 Date: Tue, 28 Mar 95 12:50:08 EST To: touch@ISI.EDU Subject: Re: MD5 versus SHA From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: smb@research.att.com, touch@ISI.EDU, ipsec@ans.net Content-Length: 1441 > c) my argument against MD5 in IPv6 is that the requirements state > that IPv6 should run at least as fast as IPv4. > > "At least as fast" presumes the existing hardware; > I can do IPv4 at 75 Mbps with no real effort, and 120 Mbps > with some effort (i.e., user-level protocols sharing a > kernel-based port). > That's in software on the existing hardware. > If I ran IPv6 on the same hardware, it'd have to be > an all-software implementation, which would slow it to > around 40 Mbps. I am somewhat familiar with the IPv6 requirements. The intent of the text is that, everything else being equal, the two protocols should be roughly the same speed. Now, 40 and 75 are not "roughly the same speed", true. But everything else is NOT equal. Your note implies that, for v4 there is some hardware assist, whilst v6 would not benefit from that assist. It would not be reasonable to expect, and I imagine that the authors of the v6 requirements document do not expect, that IPv6 runs 'at least as fast' as v4 when v4 has hardware assists and v6 does not. The question to ask is what speeds can be reached with the _same_ level of assist. -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln From ipsec-request@ans.net Tue Mar 28 18:09:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AB15692 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 13:19:07 -0500 Received: by interlock.ans.net id AA10954 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 13:12:28 -0500 Message-Id: <199503281812.AA10954@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 13:12:28 -0500 From: Ran Atkinson Date: Tue, 28 Mar 1995 13:09:03 -0500 In-Reply-To: touch@ISI.EDU "Re: MD5 versus SHA" (Mar 28, 9:17) References: <199503281719.AA38758@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: touch@ISI.EDU, smb@research.att.com Subject: Re: MD5 versus SHA Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Joe, Given that IPv4 and IPv6 are using the same security mechanisms, the speed of encryption/authentication is not different between IPv4 and IPv6. The property that IPv6 not be slower than IPv4 is preserved if one compares secure to secure or insecure to insecure. IPv6 requires that security be implemented but does not require that a user must use security. The problem with using another algorithm than MD5 is lack of community consensus that other algorithms are both faster and "strong enough". The mechanism is algorithm-independent so if, in due time, the community consensus is to use your modified MD5 or some other algorithm, then it is straight-forward to do so. Going to Proposed Standard now with MD5 does not preclude changing algorithms prior to going to Draft Standard, for example. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Mar 28 16:24:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22323 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 13:46:38 -0500 Message-Id: <199503281846.AA22323@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Tue, 28 Mar 1995 13:43:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 13:43:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 13:43:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 13:43:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Mar 1995 13:43:34 -0500 To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net Subject: Re: Routing Date: Tue, 28 Mar 1995 11:24:04 -0500 From: "Steven M. Bellovin" Bill, I do not see any reason why the specs should prohibit an intermediate router from being party to a Security Association between two other systems (call them S and D) as long as those systems (S and D) choose to let that router be party to their Security Association. Now key management (etc) are much harder in such usage, but that is a problem tobe solved by the users desiring such an arrangement. I don't think that any standards-track key mgmt protocol is required to solve that intermediate-router keying problem. The specs CURRENTLY DO NOT PROHIBIT such an arrangement and it might be desirable in some user communities to operate in that manner. Yup. This is by intent. At least, it was my intention that this be permitted in my input on the subject. Further, I note that the IAB Workshop report from last spring clearly stated that letting some intermediate routers be party to a Security Association might be desirable in some cases. (That RFC used different language but clearly had that meaning). Again, yes. I was at the workshop, and I pushed this point. My reasoning is very simple: given the current paucity of tamper-resistant crypto gear in the civilian market, one can often achieve greater security by doing the encryption in some ordinary box that's in a secured room. Besides, many LANs are administered as a single machine that happens to have a long skinny yellow backplane... From ipsec-request@ans.net Tue Mar 28 18:57:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04300 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 14:02:55 -0500 Received: by interlock.ans.net id AA08963 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 13:59:12 -0500 Message-Id: <199503281859.AA08963@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 13:59:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 13:59:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 13:59:12 -0500 Date: Tue, 28 Mar 1995 11:57:00 -0700 From: Hilarie Orman To: rja@bodhi.cs.nrl.navy.mil, smb@research.att.com, touch@ISI.EDU, ipsec@ans.net In-Reply-To: Yourmessage <199503281812.AA10954@interlock.ans.net> Subject: Timings I'd like to insert a few words of caution about timings of crypto routines. The speed of eating an apple, orange, or banana differs depending on whether or not you start with peeled fruit, partially digested, or juiced. Similarly, the following factors must be normalized when timing software: 1. Blocksize and number of blocks. Working with the same short piece of data several hundred thousand times can be misleading due to data cache effects. Blocks that are too large can cause swapping and TLB miss rates that might cause overly pessimistic timings. 2. Data dependencies. Some algorithms have different data usage patterns depending on the input. Encrypting a block of all 0's, for example, obscures this effect. 3. Endianicity. For protocols, the time to rearrange the data to/from network byte order should be considered. This transformation is sometimes embedded into the algorithm details. 4. The compiler and switches. Try all the compilers that are available for the machine, and try all the optimization levels. Make sure the routine still gets correct results, choose the fastest result. Code developers usually distribute a timing test with the routines. Often this is useful to the developer for determining if a change helps or hurts, but it might be useless for comparisons to other implementations or other algorithms due to the factors listed above. From ipsec-request@ans.net Tue Mar 28 17:17:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16777 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 14:18:27 -0500 Message-Id: <199503281918.AA16777@nis.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Tue, 28 Mar 1995 14:13:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 14:13:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 14:13:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 14:13:56 -0500 Date: Tue, 28 Mar 1995 09:17:58 -0800 From: touch@ISI.EDU Posted-Date: Tue, 28 Mar 1995 09:17:58 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Tue, 28 Mar 1995 14:13:56 -0500 To: smb@research.att.com Subject: Re: MD5 versus SHA Cc: touch@ISI.EDU, ipsec@ans.net > From smb@research.att.com Tue Mar 28 09:01:47 1995 > To: touch@ISI.EDU > Cc: ipsec@ans.net > Subject: Re: MD5 versus SHA > From: "Steven M. Bellovin" > > The following was forwarded at Bill Simpson's request. > > MD5 (orig) MD5 (opt) SHA DES (de > sCore) > > Sun 10/51 34 Mbps 37 Mbps 19 Mbps 20 Mbps > Sun 20/61 36 Mbps 38 Mbps 23 Mbps 29 Mbps > Sun 20/71 54 Mbps 57 Mbps 29 Mbps 37 Mbps > > > So in speed: > > MD5 > DES > SHA > > But we know that DES can be done at at least 1Gbps in hardware. One of > the points of the draft that was circulated a while back was that MD5 > was *inherently* unable to run at that speed. Or am I missing something? Well, there are a few points to be made: a) if you can do hardware, DES is fine, and MD5 is not. b) the IP security community has (as far as I have read from RFCs) stated that software is preferable for several reasons: - compatibility with existing hardware base - agility (ability to change the algorithm if the need arises, e.g., someone cracks DES :-) c) my argument against MD5 in IPv6 is that the requirements state that IPv6 should run at least as fast as IPv4. "At least as fast" presumes the existing hardware; I can do IPv4 at 75 Mbps with no real effort, and 120 Mbps with some effort (i.e., user-level protocols sharing a kernel-based port). That's in software on the existing hardware. If I ran IPv6 on the same hardware, it'd have to be an all-software implementation, which would slow it to around 40 Mbps. What we probably need to ask is the following: - do we want a fast hardware or fast software solution? these aren't necessarily mutually exclusive, but in comparing DES and MD5 they are - what level of security is appropriate? If it's in software, we have about 2-4 instructions per 32-bit word. MD5 uses 45. Can there even exist a reasonable hash function that follows these rules: - 2-4 instructions per 32-bit word - "working set" of words is small (8? 16?) - uses only RISC instructions NO ROTATE (can take 3 opcodes to emulate) NO ONE's COMPLEMENT ADDITION (2 opcodes) NO MULTI-INPUT FUNCTIONS THAT CAN'T BE TABLE-IZED (these are just my observations, not hard-and-fast rules) Joe From ipsec-request@ans.net Tue Mar 28 19:28:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15373 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 14:33:33 -0500 Received: by interlock.ans.net id AA26094 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 14:28:52 -0500 Message-Id: <199503281928.AA26094@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 14:28:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 14:28:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 14:28:52 -0500 Date: Tue, 28 Mar 1995 12:28:26 -0700 From: Hilarie Orman To: smb@research.att.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199503281906.AA10317@optima.cs.arizona.edu> Subject: Re: Routing I'm wondering about the following questions. Will it be clear to people reading the RFC that routers are special cases, or does it implicitly open up the protocol to an interpretation that makes host identification and pairwise privacy a possibility but not a requirement? Would it be allowable for an entire domain to use the same SA's so that the hosts could read each other's traffic and impersonate each other? From ipsec-request@ans.net Tue Mar 28 15:36:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21707 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 14:56:11 -0500 Received: by interlock.ans.net id AA18445 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 14:49:49 -0500 Message-Id: <199503281949.AA18445@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 14:49:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 14:49:49 -0500 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-aziz-skip-01.txt Date: Tue, 28 Mar 95 10:36:46 -0500 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 : Simple Key-Management For Internet Protocols-Plus (SKIPP) Author(s) : A. Aziz Filename : draft-ietf-ipsec-aziz-skip-01.txt Pages : 21 Date : 03/27/1995 There are occasions where it is advantageous to put authenticity and privacy features at the network layer. The vast majority of the privacy and authentication protocols in the literature deal with session oriented key-management schemes. However, many of the commonly used network layer protocols (e.g. IP and IPv6) are session-less datagram oriented protocols. We describe a key-management scheme that is particularly well suited for use in conjunction with a session-less datagram protocol like IP or IPv6. We also describe a simple extension of this protocol to provide scalable group key-management for Internet multicasting protocols. In this revision of the draft we describe how the basic certified key infrastructure proposed can be used to negotiate keys for traditional session oriented key-management. This provides perfect forward secrecy, for situations where forward secrecy is essential. We describe a particularly efficient ephemeral key-negotiation mechanism using the basic certified key infrastructure described above, which also addresses some basic privacy related concerns. SKIPP is designed to be plugged into the IP Security Protocol (IPSP) or IPv6. This draft describes how to use SKIPP in the context of the IPSP. 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-aziz-skip-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-aziz-skip-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-ietf-ipsec-aziz-skip-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: <19950327130713.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-aziz-skip-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-aziz-skip-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950327130713.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Mar 28 14:26:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07422 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 15:04:12 -0500 Received: by interlock.ans.net id AA18511 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 15:00:25 -0500 Message-Id: <199503282000.AA18511@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 15:00:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 15:00:25 -0500 Date: Tue, 28 Mar 95 14:26:29 GMT From: "William Allen Simpson" To: IPSEC@ans.net Subject: Re: key-ed MD5 again > From: Masataka Ohta > > Some significant analysts think that a single key at the beginning of > > MD5 does not provide enough key material when the text is long. The > > MD5(key,MD5(text)) was suggested to improve the effect of the key in the > > final hash. > > As MD5 is a chain of addition, a transitive 1-to-1 mapping, of > hashed values, it is unlikely that the initial scrambling effect > by the added hased key is weakened later. > An excellent question? The conclusion was passed to me word of mouth. But, looking at the algorithm, it seems to me that up to 4 bits of influence can be lost from the high end of the sum on each block from lost carry in the four registers. As the text grows longer, less of the initial key effect is seen. It is that addition was used instead of xor that has this result. Bill.Simpson@um.cc.umich.edu From ipsec-request@ans.net Tue Mar 28 10:10:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24976 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 15:16:18 -0500 Received: by interlock.ans.net id AA34134 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 15:12:42 -0500 Message-Id: <199503282012.AA34134@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 15:12:42 -0500 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 15:12:42 -0500 To: Hilarie Orman Cc: ipsec@ans.net Subject: Re: Routing Date: Tue, 28 Mar 95 15:10:25 EST I'm wondering about the following questions. Will it be clear to people reading the RFC that routers are special cases, or does it implicitly open up the protocol to an interpretation that makes host identification and pairwise privacy a possibility but not a requirement? Would it be allowable for an entire domain to use the same SA's so that the hosts could read each other's traffic and impersonate each other? Speaking for myself -- I certainly would allow that latter case, not because I like it but because I think that, on balance, it is often more secure than the (affordable) alternatives. But it is necessary that the hosts with which you communicate understand the granularity of your protection, a point I've made in other messages. --Steve Bellovin From ipsec-request@ans.net Tue Mar 28 10:19:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04213 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 17:24:10 -0500 Received: by interlock.ans.net id AA32496 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 17:16:29 -0500 Message-Id: <199503282216.AA32496@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 17:16:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 17:16:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 17:16:29 -0500 Date: Tue, 28 Mar 95 15:19:39 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) To: ipsec@ans.net Subject: I-D ACTION:draft-nsa-isakmp-00.txt, .ps For those who missed the I-D announcement, we encourage review of the subject I-D. We will be discussing it at the Danvers IPSEC meeting. Doug Maughan Barbara Patrick Mark Schertler ----- Begin Included Message ----- From ietf-announce-request@IETF.CNRI.Reston.VA.US Thu Mar 23 22:29:49 1995 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@IETF.CNRI.Reston.VA.US@relay.ncsc.mil@tycho.ncsc.mil Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-nsa-isakmp-00.txt, .ps Date: Thu, 23 Mar 95 17:26:22 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Content-Length: 4484 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, B. Patrick, M. Schertler Filename : draft-nsa-isakmp-00.txt, .ps Pages : 23 Date : 03/22/1995 This memo describes a combination of security concepts and protocols for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association Protocol which negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those enclaves with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and an anti-clogging mechanism, all of which are necessary to establish and maintain secure communications (via IPSP or any other security protocol) in an Internet environment. 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-nsa-isakmp-00.txt". Or "get draft-nsa-isakmp-00.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-nsa-isakmp-00.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-nsa-isakmp-00.txt". Or "FILE /internet-drafts/draft-nsa-isakmp-00.ps". 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: <19950322141446.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-nsa-isakmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nsa-isakmp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950322141446.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ----- End Included Message ----- From ipsec-request@ans.net Tue Mar 28 22:56:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15617 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 18:06:05 -0500 Received: by interlock.ans.net id AA33939 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 17:57:39 -0500 Message-Id: <199503282257.AA33939@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 17:57:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 17:57:39 -0500 Date: Tue, 28 Mar 1995 14:56:13 -0800 From: touch@ISI.EDU Posted-Date: Tue, 28 Mar 1995 14:56:13 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 17:57:39 -0500 To: kasten@ftp.com Subject: Re: MD5 versus SHA Cc: smb@research.att.com, touch@ISI.EDU, ipsec@ans.net > From kasten@mailserv-D.ftp.com Tue Mar 28 09:57:13 1995 > > c) my argument against MD5 in IPv6 is that the requirements state > > that IPv6 should run at least as fast as IPv4. > > > > "At least as fast" presumes the existing hardware; > > I can do IPv4 at 75 Mbps with no real effort, and 120 Mbps > > with some effort (i.e., user-level protocols sharing a > > kernel-based port). > > That's in software on the existing hardware. > > If I ran IPv6 on the same hardware, it'd have to be > > an all-software implementation, which would slow it to > > around 40 Mbps. > > I am somewhat familiar with the IPv6 requirements. The intent of the > text is that, everything else being equal, the two protocols should > be roughly the same speed. Now, 40 and 75 are not "roughly the same > speed", true. But everything else is NOT equal. Your note implies > that, for v4 there is some hardware assist, whilst v6 would not FYI: No hardware assist was used for 75 Mbps or 120 Mbps. The latter is via dual-stack protocols, which is a software-only modification to the drivers. Joe From ipsec-request@ans.net Tue Mar 28 23:02:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04162 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 18:11:12 -0500 Received: by interlock.ans.net id AA27213 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 18:03:48 -0500 Message-Id: <199503282303.AA27213@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 18:03:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 18:03:48 -0500 Date: Tue, 28 Mar 1995 15:02:21 -0800 From: touch@ISI.EDU Posted-Date: Tue, 28 Mar 1995 15:02:21 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 18:03:48 -0500 To: touch@ISI.EDU, smb@research.att.com, atkinson@itd.nrl.navy.mil Subject: Re: MD5 versus SHA Cc: ipsec@ans.net > From rja@bodhi.cs.nrl.navy.mil Tue Mar 28 10:13:06 1995 > From: Ran Atkinson ... > Given that IPv4 and IPv6 are using the same security mechanisms, > the speed of encryption/authentication is not different between > IPv4 and IPv6. The property that IPv6 not be slower than IPv4 is > preserved if one compares secure to secure or insecure to insecure. > IPv6 requires that security be implemented but does not require > that a user must use security. I agree completely. However, putting MD5 in as the default to an option, where we know a-priori that this will kill bandwidth, seems like something we ought to avoid at all cost. The problem is that security is going to be turned on somewhere. The authentication algorithm is likely to define the upper-bound on bandwidth if this is the case. I'd like to suggest that this be a primary concern now, while the standards are being determined, rather than later... > The problem with using another algorithm than MD5 is lack of > community consensus that other algorithms are both faster and > "strong enough". The mechanism is algorithm-independent so if, > in due time, the community consensus is to use your modified MD5 > or some other algorithm, then it is straight-forward to do so. > Going to Proposed Standard now with MD5 does not preclude changing > algorithms prior to going to Draft Standard, for example. I'd like to suggest something a bit stronger. While I agree that consensus on strength is important, I would like to argue that consensus on speed is equally important. If we don't have something that breaks 100 Mbps on a Sparc 10/51 in software (ballpark...), I propose that we do not specify a default authentication algorithm at all at this time. ********************************* If not specifying a default will be detrimental to the acceptance and use of the option, I see this as a challenge to find an algorithm that is fast; not an excuse to use one that is not. ********************************* I'm still seeking one, if anyone has any ideas. Joe From ipsec-request@ans.net Tue Mar 28 13:16:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15714 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 18:21:16 -0500 Received: by interlock.ans.net id AA25228 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 18:13:23 -0500 Message-Id: <199503282313.AA25228@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 18:13:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 18:13:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 18:13:23 -0500 Date: Tue, 28 Mar 95 18:16:31 EST From: cmadson@wellfleet.com (Cheryl Madson) To: ipsec@ans.net Subject: Is there an agenda yet? Cc: cmadson@wellfleet.com Or at least a list of the documents that we *should* have read and should be ready to discuss? I'm desparately trying to prioritize my ever-growing reading list. I was caught off guard by the I-D announcement of the ISAKMP spec, and I'd really like to know what else there is lurking out there. - C From ipsec-request@ans.net Tue Mar 28 23:28:17 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27574 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 18:40:06 -0500 Received: by interlock.ans.net id AA24536 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 18:29:47 -0500 Message-Id: <199503282329.AA24536@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 18:29:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 18:29:47 -0500 Date: Tue, 28 Mar 1995 15:28:17 -0800 From: touch@ISI.EDU Posted-Date: Tue, 28 Mar 1995 15:28:17 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 18:29:47 -0500 To: rja@bodhi.cs.nrl.navy.mil, smb@research.att.com, touch@ISI.EDU, ipsec@ans.net, ho@cs.arizona.edu Subject: Re: Timings > Date: Tue, 28 Mar 1995 11:57:00 -0700 > From: Hilarie Orman > I'd like to insert a few words of caution about timings of crypto routines. > The speed of eating an apple, orange, or banana differs depending on > whether or not you start with peeled fruit, partially digested, or juiced. > Similarly, the following factors must be normalized when timing software: I suppose this is worth a disclaimer. The numbers I posted before were as follows: MD5 - tested alternating blocks of RAM, designed not to see caching SHA - run over a 7.5 Mbyte file in /tmp (RAM) "system" time was not counted, as it was related to the read calls. DES - run over a 7.5 Mbyte file in /tmp (RAM) same as SHA "system" calls not counted, as in SHA The code was as follows: MD5 - reference code from the RFC (orig) and optimized code (cache-avoidance double-buffering, optimized byte reordering for big-endian machines, loop unrolling, etc.) SHA - off the net, with the following tag line: (includes byte-reordering for little-endian machines, no other modifications) * Copyright 1993, Dr. James J. Gillogly * This code may be freely used in any application. DES - from ripem.msu.edu: (from the readme:) desCore-2-How.tar.Z Dana How Portable, very fast implementation of basic DES routines only. Supposedly the fastest C version around. Not so fast at key-setting (i.e., password hacking). This code was submitted to comp.sources.misc as Volume 29, Issue 80 and later updated in Volume 29, Issue 128. May 92 version. All were compiled with gcc version 2.6.0, with all optimizations on. The tests were considered comparable because in each case, when the code was compiled with profiling on (-p, -pg), the profiling indicated that 99% of the user time was spent in the encryption/authentication code. Caching was inhibited by using double-buffering with block sizes larger than 1/2 the cache size for the machines tested, or by using large /tmp files as input. Data dependency was avoided by random initialization of the blocks (for authentication) and random file data as input. In these cases the random data was created off-line or before timing began. Endian costs were approximately 25% of the overall costs of the MD5 algorithm (on big-endian machines). There was no endian cost for SHA on a big-endian machine. I don't know the endian-ness of DES off the top of my head, though. Joe From ipsec-request@ans.net Tue Mar 28 23:39:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21750 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 18:51:30 -0500 Received: by interlock.ans.net id AA20640 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 18:40:32 -0500 Message-Id: <199503282340.AA20640@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 28 Mar 1995 18:40:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 18:40:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 18:40:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 18:40:32 -0500 To: cmadson@wellfleet.com (Cheryl Madson) Cc: ipsec@ans.net Subject: Re: Is there an agenda yet? In-Reply-To: Your message of "Tue, 28 Mar 1995 18:16:31 EST." <199503282313.AA25228@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 28 Mar 1995 18:39:46 -0500 From: "Perry E. Metzger" Cheryl Madson says: > Or at least a list of the documents that we *should* have read and > should be ready to discuss? > > I'm desparately trying to prioritize my ever-growing reading list. > I was caught off guard by the I-D announcement of the ISAKMP spec, > and I'd really like to know what else there is lurking out there. More than you think, I suspect. BTW, I'd like it if our chair (ARE YOU LISTENING, MR. CHAIR?) reserved some time for an in-person discussion of the authentication algorithm question. Perry From ipsec-request@ans.net Tue Mar 28 19:36:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27475 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 19:36:10 -0500 Received: by interlock.ans.net id AA36192 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 19:25:59 -0500 Message-Id: <199503290025.AA36192@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 19:25:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 19:25:59 -0500 From: Masataka Ohta Subject: Re: key-ed MD5 again To: Bill.Simpson@um.cc.umich.edu (William Allen Simpson) Date: Wed, 29 Mar 95 9:24:11 JST Cc: IPSEC@ans.net In-Reply-To: <199503282000.AA18511@interlock.ans.net>; from "William Allen Simpson" at Mar 28, 95 2:26 pm X-Mailer: ELM [version 2.3 PL11] > > > Some significant analysts think that a single key at the beginning of > > > MD5 does not provide enough key material when the text is long. The > > > MD5(key,MD5(text)) was suggested to improve the effect of the key in the > > > final hash. > > > > As MD5 is a chain of addition, a transitive 1-to-1 mapping, of > > hashed values, it is unlikely that the initial scrambling effect > > by the added hased key is weakened later. > > > An excellent question? The conclusion was passed to me word of mouth. ..... > But, looking at the algorithm, it seems to me that up to 4 bits of > influence can be lost from the high end of the sum on each block from > lost carry in the four registers. Are you seriously thinking that, MD5, which is designed by professionals for digesting long messages such as mails, can not protect except the last (64*8)/4 bits of the messages? Lost carry does not mean loss of the information. That is, carry ignoring addition of y=x+c is 1-to-1 mapping from 'x' onto 'y' and no information is lost. 'x' can be reconstructed without any ambiguity from 'y' by subtraction of 'c' with lost borrow. MSB of x does affect the MSB of y. > It is that addition was used instead of xor that has this result. Addtion and xor are equally good bijections. So, defects, *IF* any, should be a lot more subtle. Masataka Ohta From ipsec-request@ans.net Tue Mar 28 15:23:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27578 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 20:33:56 -0500 Received: by interlock.ans.net id AA34149 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 20:26:01 -0500 Message-Id: <199503290126.AA34149@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 20:26:01 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 20:26:01 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 20:26:01 -0500 Date: Tue, 28 Mar 1995 20:23:12 +0500 From: Theodore Ts'o To: touch@ISI.EDU Cc: touch@ISI.EDU, smb@research.att.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: touch@ISI.EDU's message of Tue, 28 Mar 1995 15:02:21 -0800, <199503282303.AA27213@interlock.ans.net> Subject: Re: MD5 versus SHA Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1216 Date: Tue, 28 Mar 1995 15:02:21 -0800 From: touch@ISI.EDU If we don't have something that breaks 100 Mbps on a Sparc 10/51 in software (ballpark...), I propose that we do not specify a default authentication algorithm at all at this time. If we don't specify a default authentication algorithm at this point, then we will certainly run as fast as IPv4. We will also be as secure as IPv4, which is to say that by default most vendors won't implement any form of IP security, so we won't be able to use *any* security for a very long time, and getting everyone to add the same kind of encryption later will be painfully difficult --- just like IPv4. For this reason, I think we *must* specify a default authentication algorithm which vendors must implement. In the interests of speed, someone can elect to turn it off (and suffer the security consequences), but that's a decision which the user should be allowed to make. This whole emphasis on speed reminds me of the Intel position on the Pentium --- "It's fast! What's wrong that you're only 99.9999997% sure that you got the right answer?" :-) If we want ubiquitous security, we have to deploy a defult authentication option. - Ted From ipsec-request@ans.net Wed Mar 29 02:41:46 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15734 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 21:46:34 -0500 Received: by interlock.ans.net id AA08437 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 21:39:07 -0500 Message-Id: <199503290239.AA08437@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 21:39:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 21:39:07 -0500 Date: Tue, 28 Mar 1995 18:41:46 -0800 From: Phil Karn To: ho@cs.arizona.edu Cc: rja@bodhi.cs.nrl.navy.mil, smb@research.att.com, touch@ISI.EDU, ipsec@ans.net In-Reply-To: <199503281859.AA08963@interlock.ans.net> (message from Hilarie Orman on Tue, 28 Mar 1995 11:57:00 -0700) Subject: Re: Timings >I'd like to insert a few words of caution about timings of crypto routines. >The speed of eating an apple, orange, or banana differs depending on >whether or not you start with peeled fruit, partially digested, or juiced. >Similarly, the following factors must be normalized when timing software: Glad you brought them up. > 1. Blocksize and number of blocks. Working with the same > short piece of data several hundred thousand times > can be misleading due to data cache effects. > Blocks that are too large can cause swapping and TLB miss > rates that might cause overly pessimistic timings. If data memory speed is significant, then you have a *really* good encryption algorithm. My DES code is about as tight as I can make it, but the nearly proportional speedup in going from a clock-doubled to a clock-tripled 486 chip shows that it's still limited by the internal CPU speed and not by the relatively slow memory bus bandwidth. (Some of the other CPU-intensive benchmarks I ran at the same time *are* memory bus limited. E.g. my Viterbi decoder, which improved only 15% because of its heavy memory write traffic occasioned by the 486's write-through cache). > 2. Data dependencies. Some algorithms have different data > usage patterns depending on the input. Encrypting a > block of all 0's, for example, obscures this effect. This is unlikely to be a problem with most DES implementations given the scrambling effect of the 16 rounds. Even if you repeatedly encrypt the same data, I suspect that the entire 2K SP table quickly lands in the on-chip cache. Nevertheless, I run my tests in OFB mode just to be sure. Easy enough to do. > 3. Endianicity. For protocols, the time to rearrange the > data to/from network byte order should be considered. > This transformation is sometimes embedded into the algorithm > details. True, but this is usually taken into account when you specify the CPU you're running on. > 4. The compiler and switches. Try all the compilers that are > available for the machine, and try all the optimization levels. > Make sure the routine still gets correct results, choose the > fastest result. True -- for C code. My code is hand-optimized assembler, so I doubt the compiler will make much of a difference... Phil From ipsec-request@ans.net Wed Mar 29 02:47:21 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15754 (5.65c/IDA-1.4.4 for ); Tue, 28 Mar 1995 21:52:08 -0500 Received: by interlock.ans.net id AA42072 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 28 Mar 1995 21:47:34 -0500 Message-Id: <199503290247.AA42072@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 28 Mar 1995 21:47:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 28 Mar 1995 21:47:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 28 Mar 1995 21:47:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 28 Mar 1995 21:47:34 -0500 To: "Theodore Ts'o" Cc: ipsec@ans.net Subject: A Modest Proposal In-Reply-To: Your message of "Tue, 28 Mar 1995 20:23:12 +0500." <199503290126.AA34149@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 28 Mar 1995 21:47:21 -0500 From: "Perry E. Metzger" I'd like to make the following modest proposal. At Danvers, I'd like for the entire non-cryptographer population of the IPSEC committee to force Hugo, Ashar, the NSA folks, and whomever else is nearby who has cryptography credentials into a room. The room is to remain locked until such time as the cryptographers come up with a proposal for an authentication algorithm that they actually believe to be both strong and reasonably fast. We will supply bread and water sufficient for the first day of deliberations by the cryptographers, and we will supply an unlimited supply of blank sheets of paper and pencils. The room will be furnished with enough table space for all the cryptographers to write but no chairs, and the floor of the room is to be made of unfinished concrete. I've been begging the cryptography people to come up with something for months now. If nothing else, perhaps this proposal would convince them that we are serious about needing help on this problem. Perry From ipsec-request@ans.net Wed Mar 29 05:13:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23345 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 00:23:40 -0500 Received: by interlock.ans.net id AA40762 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 00:16:39 -0500 Message-Id: <199503290516.AA40762@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 00:16:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 00:16:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 00:16:39 -0500 To: Theodore Ts'o Cc: touch@ISI.EDU, smb@research.att.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net, bound@zk3.dec.com Subject: Re: MD5 versus SHA In-Reply-To: Your message of "Tue, 28 Mar 95 20:23:12 +0500." <199503290126.AA34149@interlock.ans.net> Date: Wed, 29 Mar 95 00:13:23 -0500 From: bound@zk3.dec.com X-Mts: smtp >If we want ubiquitous security, we have to deploy a defult >authentication option. Well we are only going to attempt 'proposed standard' and I hope we get prototypes up to test the default. It could be that in 4 months we have a new and faster default. Speaking of prototypes. How many folks out there could be ready for an interoperability test fest say July before Stockholm IETF with IPv6 implementations (meaning your kernel can do Rans architecture)? This implies you have done a lot of other IPv6 work at the API and the kernel including IPv6 system discovery to even talk to the other IPv6 nodes on the LAN. I guess we could tunnel the packets. I guess we would all have to agree on the key mangement even manual? I would like to use in-band (just kidding). But seriously could we use kerberos for such a fest? Do we need a Security API Spec for this testing? /jim From ipsec-request@ans.net Wed Mar 29 06:35:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26892 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 01:38:44 -0500 Received: by interlock.ans.net id AA26745 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 01:31:19 -0500 Message-Id: <199503290631.AA26745@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 01:31:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 01:31:19 -0500 X-Sender: hughes@129.191.63.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Mar 1995 00:35:32 -0600 To: perry@imsi.com, "Theodore Ts'o" From: hughes@hughes.network.com (James P Hughes) Subject: Re: A Modest Proposal (for a MD5 replacement) Cc: ipsec@ans.net I will be putting a set of thoughts out at the meeting either formally or informally. There is a potential to increase the performance because a keyed hash can keep the nonlinear permutations private to the association and thus the attacks available are reduced. I have some serious questions that I must answer before the I will be satified about the contents. There will probably be several itterations before an algorithm can be settled on. I agree with others that the AH document can move forward to the standards track draft status and this or other hashing algorithms can be added later. By the way, Can I get 30 minutes or so on the agenda to discuss this? Thanks Jim ---------------------- James P Hughes Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 From ipsec-request@ans.net Wed Mar 29 06:49:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21446 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 02:06:49 -0500 Received: by interlock.ans.net id AA13117 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 02:00:23 -0500 Message-Id: <199503290700.AA13117@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 02:00:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 02:00:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 02:00:23 -0500 To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net, bound@zk3.dec.com Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Mon, 27 Mar 95 11:43:30 EST." <199503271648.AA39820@interlock.ans.net> Date: Wed, 29 Mar 95 01:49:53 -0500 From: bound@zk3.dec.com X-Mts: smtp Ran, %1. Is draft-ietf-ipsec-arch-00.txt going to be an Informational RFC % only? % The reason I ask is that there is much text in ipsec that does not % apply to an actual implementation, but is history, opinions on % directions, and boilerplate type material. I believe this is good % data in an Informational RFC like the Hinden IPng White Paper and % useful to the IETF community at large, but not necessary or useful % in a proposed standard. The standard that goes with the IPng White % Paper is the Deering/Hinden IPv6 Base Specification, which is a good % example of how a standard to implement should be written. @ At present, the architecture document contains significant @amounts of standards-track material (to give one example, the @definition of a "Security Association", as that term is used by both @ESP and AH, only exists there). Hence that document currently needs to @be on the standards-track. Much of the material common to ESP and AH @specifications was moved into the Security Architecture document in @response to suggestions from others (including Scott Bradner) that the @material common to both the ESP and AH specs should be consolidated @into the Security Architecture draft. I think a 'pure' design document should be an info RFC. Those parts that define knowledge required to implement the standard should be moved to AUTH and ESP. For example on Page 6 paragraph 3: "The receiver-orientation of the Security Association implies that, in the case of unicast traffic, the destination system will normally select the SPI value." What does 'normally' mean to me as an implementor? If its a case type primitive I do not know from this spec what the conditions are for the switch() or the the object for which the conditions are being tested. But as an information statement I can accept it as it is presently. I could go through the spec and point out other places where the wording is of this nature. Also in the above and in other places replace system with node, per IPv6 base spec. @ That standards-track material needs to be in a standards-track @RFC that moves in parallel with the ESP and AH drafts. If the Sec @Arch document were not standards-track, then that standards-track @material would need to be moved into a standards-track draft prior to @Proposed Standard RFCs being issued. Or just put what you need in AUTH and ESP drafts. Less is better in many cases (not in all I realize). % 2. DES-CBC Encryption. Could I get the formal answer to this question % from you for the record? This question could also be asked of the % IESG at that Last Call effort too [if necessary]. % % An IPv6 implementation is required (MUST) to implement DES-CBC. Yet % in my country (U.S.A.) being conformant means that vendors MUST build % a product that cannot be exported to the International market. % Changing it to SHOULD would eliminate this objection to the draft. @Please permit me to make a correction. @ DES _is_ exportable from the US. Depending on how it is going @to be used and the intended customer, export of DES might require an @export license from the US Government. There are many known cases of @such export licenses being issued. There is widespread belief that it @can be time consuming to obtain such export licenses. A correction to your correction. This is common knowledge, but some countries are more difficult than others per agreements with those countries. Not all countries can recieve export licenses one will want to do business with simply because of government policy. This is the problem and the IETFs' in making standards not the vendors. Also this does not change the fact that requiring DES requires vendors to build products that may not be exportable in their country. Conformance can mean that reaching an international market with that product is prevented. We are trying to make the Internet more International and easier to business with in that manner not less. % Why cannot we use the word SHOULD? @ There is rough consensus that implementation of encryption is @mandatory for IPv6. The word "MUST" is used to indicate mandatory @items. The word "SHOULD" is used to indicate items that are not @absolutely mandatory. Changing "MUST" to "SHOULD" would decrease @consensus because it would eliminate the requirement that encryption @be implemented in all IPv6 systems. Well I do not agree with you that this has rough consensus. I challenge any claim to rough consensus in the vendor community, which is a large part of the IETF community. Not sure how either of us prove this one way or the other? % 3. The term 'userid' is used in the drafts for the sending host. % % What is the 'userid' and how do I know as an implementor where I get % the userid on a node? @ A "userid" is an implementation-specific identifier used to @distinguish between different users of a system. In the case of @POSIX.1 systems, the "uid" would map nicely to a "userid". I know that, in fact my name is on that standard and I worked on it. My point is that we should say more about what a userid is so it is clearly defined. Putting it under terminology or technical definitions in AUTH or ESP would be a good idea IMHO. > Implementation-specific methods are used to obtain a userid. >In the case of a UNIX operating system, the getuid() or geteuid() >calls might be used by an implementation. On other systems (for >example, HP MPE or IBM MVS), other implementation-specific calls would >be used. But in UNIX they could be the same across systems, they are not guaranteed to be unique, anymore than process-IDs. This is true for other systems including a POSIX Conforming System. As long as you brought up POSIX take a look at POSIX.3 Test Methods and Conformance. This is where assertions are developed to test the code implementation details of POSIX.1, as one case. It clearly points out the problems with standards that are written for which a test case cannot be defined. Hence, producing bugs in implementations. I am having trouble with the assertions for testing in the spec. A good example of specs that are very clear are the IPv6 base spec, IPv6 System Discovery, and the new IPv6 Transition spec (except for tunnel state/config which is complex). The security specs do not have this manner of implementation clarity. % 4. Could we have examples of manual configuration, host to host keying, % and user to user keying? % % I am not sure how I should implement any of these, and in the case of % user to user keying, I am not clear what that actually means? @Are you reading the most recent documents ? @ I don't believe the terms "host-to-host" and "user-to-user" @appear in the current drafts. If they do, it is an editing error that @I somehow missed. The corrected terms are "host-oriented" and @"user-oriented" keying. The text in this area was completely @rewritten in response to feedback from various people. The text @should be reasonably clear in the current draft. They do say user-oriented now, my mistake when responding. Its not clear because its not stated how the user-oriented key is passed to the other implementation. Also stated that "User A on host 1 might have more than one key for its traffic destined for host 2", seems contradictory to user-oriented keying? Unless two-way sessions are not to be established? @ I believe the existing text noted that manual configuration @could mean that one put the keys and other data in a flat file. If @desired, I could create an informational (i.e. not standards-track) @appendix illustrating one possible flat file format that could be @used. I think we need more than that? An explanation of what it means to an implementation and where/how the manual key is used in the protocol I think at a minimum should be stated if this is a MUST. @ There is significant detail in the ESP and AH drafts on the @process by which an incoming or outgoing packet is handled. The @combination of that text and the text in the Security Architecture @makes clear how to implement this. This is one of several reasons @that the ESP and AH drafts cite the Architecture draft as @standards-track. All 5 drafts need to be read as a set. Then make them one draft. I should not have to read ESP to implement AUTH. I should not have to read SEC to implement any draft. Except for parts that should be moved to the AUTH and SEC drafts. % 5. In 4. Key Management section. % % 'Support for key management methods where the key management data is % carried within the IP layer is not a design objective for these % IP-layer security mechanisms.' % % If this means it will not work then I think a standard should say % that, or else say nothing. Saying this means nothing to me as an % implementor. I cannot test for this case, so why is it an % implementation standard? % % This last point is critical. Statements in standards for which I % cannot implement as a test case is suspect as to the words being % useful for an implementor. @ There is rough consensus that this information is important to @implementers so that there is a clear understanding of what the design @objectives were and were not for the security specifications. @Removing that language would decrease consensus. Many existing @Internet standards contain similar language about design goals. The @IETF document style is significantly different from that of other @standards groups such as IEEE and ANSI. This document complies with @IETF document style because it is an IETF document. I do not agree we have rough consensus on this issue. in-band can work with your architecture. There is no good reason to state this is not a design objective. If it will not work then the 'warning' should be noted. Its my impression it can work and I can implement it that way if I choose for customers who want to use in-band who do not need or require perfect forwarding security. I am well aware of the IETF style no need to remind me, and that is not the issue at hand. Also this was not under the Design Objective section fyi. I have worked on several styles of standards including defacto as opposed to dejure. What I like about the IETF is the notion of implementations are critical to prove a techncial belief. What I am questioning is the implementation thinking behind the specs. In that effort as an engineer I also must consider cost, and having to build eeventual products to specifications that increase costs or prevent other products is prudent on my part as an engineer to question what I am questioning. Its not a witch hunt or pick on Security. These issues are all important so we are very sure we get Internet security right for all parties concerned. Including us engineers, who are stuck with being concerned about cost as part of our trade. This security is very costly to all: reduces performance, no key management in sight, conformance to a standard could mean I can't export a product, statements that limit what kind of keying is good for this architecture, and many statements that say "this is unclear" or "in the normal case" while I am reading an implementation spec. Thats why the IETF is good too. I can ask and check the implementation details consistently until they are clear and implementable at a reasonable cost. Add no key distribution as another issue as an unknown. % 6. Security warnings and statements of potential attack. % % Would it be possible to put these in an appendix, when they are not % in the standard to provide implementation details? @ Within RFCs, the "Security Considerations" section is supposed @to describe security issues and residual security risks relating to @the material described in that document. Moving these to an appendix @would not conform to IETF document standards (see RFC-1543, Section @8). Further, removing that material would decrease consensus. I am not talking about a "section" but the consistent warnings "throughout" the documents. I agree we need them, so put them all in one seciton as you suggest above. % 7. The specs reference two new IDs (or work in progress) for MD5 and % DES-CBC? % These are new. Are these the specifications you are stating to % implement MD5 and DES-CBC? Because you have stated MUST, if these % specs cannot be made proposed in the same time frame as your % standard, it will hold up the IPv6 Security work from going to % proposed standard. By saying SHOULD or they are an option, you free % your work from those work items reaching proposed standard IMHO. @ These were actually announced by the InterNIC prior to their @announcement of my drafts. All 5 drafts were actually available @online at the Internet-Drafts directories for significant time prior @to their announcement by CNRI. Further, all 5 drafts were ftp'able from @ftp.nrl.navy.mil even prior to their announcement by the InterNIC and @that location was announced by me to IPng and IPsec mailing lists. @ Those drafts contain much clearer text describing the security @transforms and are improved versions of the text formerly in Appendix @A of the ESP and AH drafts. The revised text is based on @implementation experience of Phil Karn and Perry Metzger. @It is intended that all 5 drafts move forward as a set. Were these implementations on an IPv4 stack or IPv6 stack? What IP kernels were changed to accomodate the tests? What we used for IPv6 was RFC 1321. The new MD5 seems to add value but we have not had time to test it in code yet. DES-CBC is another issue per above, but I guess we could prototype it in the U.S. from an advanced development perspective to test the implementation of the specs, as IETF participants and team players in the IETF. /jim From ipsec-request@ans.net Wed Mar 29 03:36:08 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15793 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 08:45:53 -0500 Received: by interlock.ans.net id AA21998 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 08:37:04 -0500 Message-Id: <199503291337.AA21998@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 08:37:04 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 08:37:04 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 08:37:04 -0500 Date: Wed, 29 Mar 95 08:36:08 EST X-Sender: shirey@smiley.mitre.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: touch@ISI.EDU From: shirey@mitre.org (Robert W. Shirey) Subject: Re: MD5 versus SHA Cc: smb@research.att.com, ipsec@ans.net At 9:17 AM 3/28/95, touch@ISI.EDU wrote: >b) the IP security community has (as far as I have read from RFCs) > stated that software is preferable for several reasons: > > - compatibility with existing hardware base > - agility (ability to change the algorithm if the need arises, > e.g., someone cracks DES :-) > As we, the PSRG, note in our Internet-Draft : 1.6.3.3 Preference for Software To maximize interoperability in the Internet, security designs that can be implemented in either software or hardware should be preferred over those that require hardware. Also, security designs should prefer software security mechanisms that are freely and publicly available in source code. This is especially true if security mechanisms must be implemented in end systems. Hardware often can provide additional protection or improved performance for security mechanisms, but designs that can be implemented in either software or hardware permit the choice as a local implementation option, not visible at external interfaces. Source code maximizes the potential for interoperability because if a mechanism is available only in object code, the range of platforms on which it can be used may be very limited. Source code is important for other reasons, too. Without source code, it is harder to conduct open peer review (see Section 1.6.2.1) and develop confidence that software works properly and contains no Trojan horses. Restricting distribution of security mechanisms to object code is a kind of "security by obscurity" that usually is ineffective in the Internet, especially if the mechanism is weak. It is inevitable that someone will decompile the object code and search for vulnerabilities that may remain because the source code was not subject to wide review. That one person can then provide attack information to the entire Internet (see Section 1.5.4.3). History shows that attackers are often more motivated to search for vulnerabilities than are the system designers and legitimate users. Regards, -Rob- Robert W. Shirey SHIREY@MITRE.ORG tel 703.883.7210, sec 703.883.5749, fax 703.883.1397 Info. Security Div., The MITRE Corp., Mail Stop Z231 7525 Colshire Drive, McLean, Virginia 22102-3481 USA From ipsec-request@ans.net Wed Mar 29 14:35:16 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28415 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 09:41:37 -0500 Received: by interlock.ans.net id AA18834 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 09:35:32 -0500 Message-Id: <199503291435.AA18834@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 29 Mar 1995 09:35:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 09:35:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 09:35:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 09:35:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 09:35:32 -0500 X-Mailer: exmh version 1.5.3 12/28/94 To: perry@imsi.com Cc: "Theodore Ts'o" , ipsec@ans.net Subject: Re: A Modest Proposal In-Reply-To: Your message of "Tue, 28 Mar 1995 21:47:21 EST." <199503290247.AA42072@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Mar 1995 09:35:16 -0500 From: " " Perry, Nice joke. But I think you wanted also a serious reply, and here is one. There are really two very different questions being discussed in the list re message authentication algs: 1. What is the right mode of keyed MD5? (Hugo and Bill's friendly exchange) 2. Is MD5 fast enough or do we need something new (and what that is)? (Joe, Hillarie, Ted,... ) If MD5 is not good (Q2) then of course Q1 becomes irrelevant... but... We need a solution NOW, to get standard-complying (as much as possible) products this year. Finding a faster auth function is not a possibility; the only reasonable candidates are MD5 and DES based. I'll be happy with either as they have roughly complementing merits: MD5 is faster in SW, DES is faster in HW and more scalable (to even faster HW). I think MD5 should be required as most implementations would be sw based (which we found to give acceptable performance for many purposes). So my answer to Q2 is: we'll use MD5 for now, and let's do research to come up with a faster alternative in 3 years. As to Q1, I agree with you, we need an answer to that NOW too... and we should try to be productive (for a change). For technical reasons, I agree with Hugo: we need either the `traditional' MD5(key, data, key) or the `improved' MD5(key, MD5(key, data)). I don't see Bill's point in saying essentially `I don't understand why MD5(key, MD5(data)) is not enough so that's it!', as the performance is negligibly affected by Hugo's variant, while the only crypto expert voicing an opion on the two so far is Hugo... [I think; my apologies if I missed/forgot some relevant note - too much pressure etc...) (let me add my two cents to support Hugo's technical view) But let's not despair; there is an easy way to resolve this. We need opinion of additional crypto folks, preferably Burt (who proposed MD5(key, MD5(data)) but so far did not compare it to MD5(key, MD5(key, data)). If these would support Hugo (as I'm quite sure they would) then we are done. Let me state clearly that while I'm sorry Bill got so upset about this, I do support his (and your) urge to get this issue resolved already. The right method is to put more pressure on additional crypto experts (esp. Burt) to voice their opinion NOW. Best, Amir Herzberg From ipsec-request@ans.net Wed Mar 29 04:31:54 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12812 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 09:45:35 -0500 Received: by interlock.ans.net id AA38176 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 09:43:07 -0500 Message-Id: <199503291443.AA38176@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 09:43:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 09:43:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 09:43:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 09:43:07 -0500 Date: Wed, 29 Mar 95 09:31:54 EST To: touch@ISI.EDU Subject: Re: MD5 versus SHA From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: touch@ISI.EDU, smb@research.att.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net Content-Length: 2182 There is a logical flaw with not specifying a 'default' algorithm. If an algorithm is the "default algorithm" then one can assume that that algorithm is common to all implementations. Every node and implementation can be assured that every other node which does security will do the default. Now, consider what happens if there is no default. I may implement algorithms B and C and you might implement algorithm D. Each of these may be stronger or better (in whatever sense) than algorithm A. But we will not be able to communicate in a secure manner since we do not do the same algorithms. We each will say "We are better than A" but we will not be able to communicate securely. Is this good? A common, default, widely-fielded, algorithm is required. You say that speed is important. It is. But I urge that we specify an algorithm and field it. Soon. The internet has needed, and lacked, a security scheme for many years. In part it's because we've always been searching for a 'better' system -- faster, cheaper, stronger, etc. We've put off fielding what we have because tomorrow we might have something better. We might get something better tomorrow, but what we can field today is infinitely better than what we are using today. > I'd like to suggest something a bit stronger. > > While I agree that consensus on strength is important, > I would like to argue that consensus on speed is equally important. > > If we don't have something that breaks 100 Mbps on a Sparc 10/51 > in software (ballpark...), I propose that we do not specify > a default authentication algorithm at all at this time. > > ********************************* > > If not specifying a default will be detrimental to the acceptance > and use of the option, I see this as a challenge to find an > algorithm that is fast; not an excuse to use one that is not. > > ********************************* > > I'm still seeking one, if anyone has any ideas. > > > Joe > -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln From ipsec-request@ans.net Wed Mar 29 15:13:51 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22063 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 10:19:41 -0500 Received: by interlock.ans.net id AA32816 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 10:16:43 -0500 Message-Id: <199503291516.AA32816@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 10:16:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 10:16:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 10:16:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 10:16:43 -0500 To: bound@zk3.dec.com Cc: ipsec@ans.net Subject: Re: MD5 versus SHA In-Reply-To: Your message of "Wed, 29 Mar 1995 00:13:23 EST." <199503290516.AA40762@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 29 Mar 1995 10:13:51 -0500 From: "Perry E. Metzger" bound@zk3.dec.com says: > Speaking of prototypes. How many folks out there could be ready for an > interoperability test fest say July before Stockholm IETF with IPv6 > implementations (meaning your kernel can do Rans architecture)? I'll be ready to interoperably test IPv4 with Phil by then I believe (with his IPSP stuff -- NOT photuris unless I steal his code, which would sort of obviate part of the exercise.) I don't know about v6 people -- to my knowledge, thats Ran at this point. .pm From ipsec-request@ans.net Wed Mar 29 15:58:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27576 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 11:04:16 -0500 Received: by interlock.ans.net id AA26131 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 10:58:21 -0500 Message-Id: <199503291558.AA26131@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 10:58:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 10:58:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 10:58:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 10:58:21 -0500 To: " " Cc: ipsec@ans.net Subject: Re: A Modest Proposal In-Reply-To: Your message of "Wed, 29 Mar 1995 09:35:16 EST." <9503291435.AA31595@gimili.watson.ibm.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 29 Mar 1995 10:58:13 -0500 From: "Perry E. Metzger" > Nice joke. But I think you wanted also a serious reply, Indeed I did. > We need a solution NOW, to get standard-complying (as much as > possible) products this year. Indeed we do, and I am NOT NOT NOT proposing that we touch the extant MD5 authentication draft, at least not much. (I would like us all to decide that MD5(key, text, key) is acceptable and get on with our lives so we can implement). I am proposing however that we have to look for alternatives for the future in a serious way, and that the crypto people would probably be adding the most value possible to this process if they started studying the question in a solid way. Perry From ipsec-request@ans.net Wed Mar 29 16:44:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15443 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 11:49:44 -0500 Received: by interlock.ans.net id AA38475 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 11:45:05 -0500 Message-Id: <199503291645.AA38475@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 11:45:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 11:45:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 11:45:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 11:45:05 -0500 X-Mailer: Novell GroupWise 4.1 Date: Wed, 29 Mar 1995 09:44:36 -0700 From: Ed Reed To: kasten@ftp.com Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net, smb@research.att.com, touch@ISI.EDU Subject: Re: MD5 versus SHA -Reply I second Frank's remarks. 1) defaults are intended to provide a least common denominator. They may not be as fast or even as secure as later options. 2) design the protocol for extensibility so future extensions are easy to adopt. In this case, with algorithm IDs to describe interworking solutions. 3) don't let the proposal go forward without some required, common, even if sub-optimal required algorithms (two, really - a null facility meaning we're not doing security on this session, and one of the algorithms under discussion. 4) for the default algorithm, select on the basis of strength rather than speed. Other algorithms will provide speed. We're sunk if the mandated algorithm lacks "adequate" strength for some measure of adequacy which may be obsoleted at sometime in the future. All of this is, of course, modulo import/export and trans-boarder data flow issues. I presume that since MD5 transformations are not reversable that the thrust of the current discussion has to do with data integrity checks, and tying that to the identity of the remote party via a negotiated symetrical session key. And that there is not a notion of *mandating* support for data stream encryption in IPv6 compliant implementations. Right? Ed Reed Novell, Inc. >>> Frank Kastenholz 03/29/95 07:31am >>> There is a logical flaw with not specifying a 'default' algorithm. If an algorithm is the "default algorithm" then one can assume that that algorithm is common to all implementations. Every node and implementation can be assured that every other node which does security will do the default. Now, consider what happens if there is no default. I may implement algorithms B and C and you might implement algorithm D. Each of these may be stronger or better (in whatever sense) than algorithm A. But we will not be able to communicate in a secure manner since we do not do the same algorithms. We each will say "We are better than A" but we will not be able to communicate securely. Is this good? A common, default, widely-fielded, algorithm is required. You say that speed is important. It is. But I urge that we specify an algorithm and field it. Soon. The internet has needed, and lacked, a security scheme for many years. In part it's because we've always been searching for a 'better' system -- faster, cheaper, stronger, etc. We've put off fielding what we have because tomorrow we might have something better. We might get something better tomorrow, but what we can field today is infinitely better than what we are using today. > I'd like to suggest something a bit stronger. > > While I agree that consensus on strength is important, > I would like to argue that consensus on speed is equally important. > > If we don't have something that breaks 100 Mbps on a Sparc 10/51 > in software (ballpark...), I propose that we do not specify > a default authentication algorithm at all at this time. > > ********************************* > > If not specifying a default will be detrimental to the acceptance > and use of the option, I see this as a challenge to find an > algorithm that is fast; not an excuse to use one that is not. > > ********************************* > > I'm still seeking one, if anyone has any ideas. > > > Joe > -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln From ipsec-request@ans.net Wed Mar 29 16:55:05 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21369 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 12:14:17 -0500 Received: by interlock.ans.net id AA15035 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 12:04:08 -0500 Message-Id: <199503291704.AA15035@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 12:04:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 12:04:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 12:04:08 -0500 To: perry@imsi.com Cc: bound@zk3.dec.com, ipsec@ans.net Subject: Re: MD5 versus SHA In-Reply-To: Your message of "Wed, 29 Mar 95 10:13:51 EST." <9503291513.AA14548@snark.imsi.com> Date: Wed, 29 Mar 95 11:55:05 -0500 From: bound@zk3.dec.com X-Mts: smtp Perry et al; >> Speaking of prototypes. How many folks out there could be ready for an >> interoperability test fest say July before Stockholm IETF with IPv6 >> implementations (meaning your kernel can do Rans architecture)? >I'll be ready to interoperably test IPv4 with Phil by then I believe >(with his IPSP stuff -- NOT photuris unless I steal his code, which >would sort of obviate part of the exercise.) I don't know about v6 >people -- to my knowledge, thats Ran at this point. Cool. But for my work its ONLY IPv6. The work is funded to do research and advanced development on IPv6 and that which is new (e.g. Security, System Discovery) and that which is altered (e.g. DNSIND and DHCPv6). I will poke those that build IPv4 products, but I am only championing an IPv6 test bed (for more than Security too ). I don't do this by myself of course (its too much change in the kernel). I work with a team of individuals that are dedicated to testing the IPv6 specs with code, to verify the next generation Internet protocol specs are implementable at a reasonable cost and are interoperable in a multivendor open systems environment. Of course we also get to check new things out like using the IPv6 flow-id in the IPv6 Sockets API spec (e.g. RSVP) or see what the anycast address can do in a distributed IPv6 environment, but most of it is testing parts like Ran's specs (and yours and Bills) for IPv6. With IPv4 the IETF cannot make IPSEC a must implement as 'we' are doing with IPv6. So I guess if vendors feel there is 'profit' in doing security for IPv4 they will implement the IPSEC work on IPv4. I have no clue if this is true or not. But I bet no one will make existing IPv4 products non-exportable without a 'big payback in revenue-streams'. I am not a product/business person so the above is just an individual opinion by me and I admit to not knowing what all customers require. Vendors may just get screwed with IPv6 is my fear per Security as an engineer/architect working in the IETF as an individual. thanks /jim From ipsec-request@ans.net Wed Mar 29 18:26:45 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22421 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 13:32:30 -0500 Received: by interlock.ans.net id AA09890 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 13:28:13 -0500 Message-Id: <199503291828.AA09890@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 13:28:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 13:28:13 -0500 Date: Wed, 29 Mar 1995 10:26:45 -0800 From: touch@ISI.EDU Posted-Date: Wed, 29 Mar 1995 10:26:45 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 13:28:13 -0500 To: touch@ISI.EDU, shirey@mitre.org Subject: Re: MD5 versus SHA Cc: smb@research.att.com, ipsec@ans.net > Date: Wed, 29 Mar 95 08:36:08 EST > From: shirey@mitre.org (Robert W. Shirey) > > At 9:17 AM 3/28/95, touch@ISI.EDU wrote: > > >b) the IP security community has (as far as I have read from RFCs) > > stated that software is preferable for several reasons: > > > > - compatibility with existing hardware base > > - agility (ability to change the algorithm if the need arises, > > e.g., someone cracks DES :-) > > > > As we, the PSRG, note in our Internet-Draft > : > > 1.6.3.3 Preference for Software > > To maximize interoperability in the Internet, security designs that can > be implemented in either software or hardware should be preferred over > those that require hardware. Also, security designs should prefer > software security mechanisms that are freely and publicly available in > states (page 2): ... Standard default algorithms (i.e. keyed MD5, DES CBC) are specified to ensure interoperability in the global Internet. The selected algorithms are the same as the standard default algorithms used in SNMPv2. However, the choice of MD5 for SNMP did not include performance considerations. states (Page 7): An appendix of [3] contains a C Programming Language implementation of the algorithm. This code was written with portability being the principal objective. Implementors may wish to optimize the implementation with respect to the characteristics of their hardware and software platforms. This appears to hint that MD5 was believed to have optimization potential, because only a reference implementation was given. It turned out that the potential was very limited. At this time, it may be important to recognize: - known limitations in the performance of MD5 - the fact that hardware doesn't speed-up some things as much as others e.g., DES can be accellerated by a factor of 100, but MD5 can be accellerated by a factor of only 4 or so in general: algorithms based on bit-wise logical operations and table lookups can be accellerated rather well in hardware algorithms based on multiplication, addition (2's or 1's complement), etc. are not accellerated well in hardware At this time, my limited investigation hints at the following as being better choices, performance-wise, than MD5: general Feistel ciphers (of which DES is a member?) N-DFA hash mechanisms (I'm seeking further info on both). Joe From ipsec-request@ans.net Wed Mar 29 18:48:29 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12898 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 13:55:42 -0500 Received: by interlock.ans.net id AA45111 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 13:49:58 -0500 Message-Id: <199503291849.AA45111@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 13:49:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 13:49:58 -0500 Date: Wed, 29 Mar 1995 10:48:29 -0800 From: touch@ISI.EDU Posted-Date: Wed, 29 Mar 1995 10:48:29 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 13:49:58 -0500 To: kasten@ftp.com, Ed_Reed@Novell.COM Subject: Re: MD5 versus SHA -Reply Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net, smb@research.att.com, touch@ISI.EDU > From Ed_Reed@Novell.COM Wed Mar 29 08:45:07 1995 > I second Frank's remarks. > > 3) don't let the proposal go forward without some required, common, even if sub-optimal > required algorithms (two, really - a null facility meaning we're not doing security on this > session, and one of the algorithms under discussion. > > 4) for the default algorithm, select on the basis of strength rather than speed. Other > algorithms will provide speed. We're sunk if the mandated algorithm lacks "adequate" > strength for some measure of adequacy which may be obsoleted at sometime in the future. > > All of this is, of course, modulo import/export and trans-boarder data flow issues. Any chance of defining MD5-2? One MAJOR flaw in MD5 is using little-endian (anti-"network standard" byte order). This means that big-endians incur a byte-reordering cost they don't usually incur. Little-endians already incur this cost, so it isn't an extra burden on them. (assuming you're interested in what changes are useful, choosing an algorithm with little-endian order on a network-entity seems to be correctable...) Joe From ipsec-request@ans.net Wed Mar 29 19:04:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20556 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 14:17:06 -0500 Received: by interlock.ans.net id AA48558 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 14:04:48 -0500 Message-Id: <199503291904.AA48558@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 29 Mar 1995 14:04:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 14:04:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 14:04:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 14:04:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 14:04:48 -0500 From: uri@watson.ibm.com Subject: Re: IPv6 Security Last Call Initial Questions To: atkinson@itd.nrl.navy.mil Date: Wed, 29 Mar 1995 14:04:47 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <199503271648.AA39820@interlock.ans.net> from "Ran Atkinson" at Mar 27, 95 11:43:30 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: 1341 Ran Atkinson says: > % 2. DES-CBC Encryption. Could I get the formal answer to this question > % from you for the record? This question could also be asked of the > % IESG at that Last Call effort too [if necessary]. > % An IPv6 implementation is required (MUST) to implement DES-CBC. Yet > % in my country (U.S.A.) being conformant means that vendors MUST build > % a product that cannot be exported to the International market. > % Changing it to SHOULD would eliminate this objection to the draft. > > DES _is_ exportable from the US. Depending on how it is going > to be used and the intended customer, export of DES might require an > export license from the US Government. There are many known cases of > such export licenses being issued. There is widespread belief that it > can be time consuming to obtain such export licenses. And then there is CDMF, which is rather similar to DES, and which enjoys similar exportability as RC2/RC4 (except the review time is 15 days instead of 7)... It's patented by IBM, and so far our lawyers say, that they'd allow royalty-free usage of the algorithm in the standard, but if the party who uses it, holds another patent, it should allow IBM royalty-free usage of their patent... ??? -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Wed Mar 29 19:34:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23545 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 14:46:16 -0500 Received: by interlock.ans.net id AA20870 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 14:38:23 -0500 Message-Id: <199503291938.AA20870@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 14:38:23 -0500 From: Ran Atkinson Date: Wed, 29 Mar 1995 14:34:19 -0500 In-Reply-To: uri@watson.ibm.com "Re: IPv6 Security Last Call Initial Questions" (Mar 29, 14:04) References: <199503291904.AA48558@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's patented algorithm Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Uri, There is community consensus behind DES CBC, which has been long analysed in the public and has no patent issues. I don't believe that any proprietary algorithm would be a good choice as a mandatory to implement algorithm. I personally find the IBM license terms that you describe to be onerous. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Mar 29 10:36:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26644 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 15:44:09 -0500 Received: by interlock.ans.net id AA21353 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 15:39:16 -0500 Message-Id: <199503292039.AA21353@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 15:39:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 15:39:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 15:39:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 15:39:16 -0500 Date: Wed, 29 Mar 95 15:36:43 EST To: touch@ISI.EDU Subject: Re: MD5 versus SHA -Reply From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: kasten@ftp.com, Ed_Reed@Novell.COM, atkinson@itd.nrl.navy.mil, ipsec@ans.net, smb@research.att.com, touch@ISI.EDU Content-Length: 689 > Any chance of defining MD5-2? > > One MAJOR flaw in MD5 is using little-endian (anti-"network standard" > byte order). > > This means that big-endians incur a byte-reordering cost they don't > usually incur. > Little-endians already incur this cost, so it isn't an extra burden on them. As long as we are getting into that argument, there are a lot more little endian machines out there than big-endian. I'd rather we change all the other things to be little endian. -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln From ipsec-request@ans.net Wed Mar 29 10:41:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23335 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 15:45:09 -0500 Received: by interlock.ans.net id AA52740 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 15:41:53 -0500 Message-Id: <199503292041.AA52740@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 15:41:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 15:41:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 15:41:53 -0500 Date: Wed, 29 Mar 1995 15:41:39 +0500 From: Theodore Ts'o To: uri@watson.ibm.com Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: uri@watson.ibm.com's message of Wed, 29 Mar 1995 14:04:47 -0500 (EST), <199503291904.AA48558@interlock.ans.net> Subject: Re: IPv6 Security Last Call Initial Questions Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 549 From: uri@watson.ibm.com Date: Wed, 29 Mar 1995 14:04:47 -0500 (EST) And then there is CDMF, which is rather similar to DES, and which enjoys similar exportability as RC2/RC4 (except the review time is 15 days instead of 7)... IP issues aside, what's the strength of CDMF? My understanding of 40 bit RC4 is that it doesn't give away anything about the NSA's ability to crack cyphers. 40-bit RC4 is reportedly quiet easy for anyone to cryptoanalyze. If CDMF is similarily weak, what's the point of using it at all? - Ted From ipsec-request@ans.net Wed Mar 29 20:45:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22331 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 15:49:38 -0500 Received: by interlock.ans.net id AA20847 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 15:47:20 -0500 Message-Id: <199503292047.AA20847@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 29 Mar 1995 15:47:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 15:47:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 15:47:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 15:47:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 15:47:20 -0500 Date: Wed, 29 Mar 1995 15:45:36 -0500 From: pau@watson.ibm.com (Pau-Chen Cheng) To: atkinson@itd.nrl.navy.mil Subject: IPv6 Security Last Call Questions Cc: ipsec@ans.net Ran, I am reviewing the I-D's to see what is needed to make the current IBM IPSP implementation conformant. I have a few questions/suggestions : 1. In the ESP I-D (not DDES-CBC I-D), beginning of section 3 on page 4 : "... (ESP) may appear anywhere after the IP header." My undersatnding of the entire ESP I-D is that ESP can be placed before an encapsulated IP packet or after an IP header but before a transport header (e.g, a TCP header). If I am right, then the word "anywhere" is a little bit misleading. 2. In sections 4.1 and 4.2 of the ESP I-D, it says that the receiver MUST create a log if there is not security association to process a received ESP. I fully agree that logging is the right thing to do. However, I think whether to log these events or not should be a local decision and not a requirement of the protocol. 3. If we have ESP between two firewalls in the following configuration : +------+ +----------+ +------+ -----+ FW X +--+ Internet +---+ FW Y +------ +------+ +----------+ +------+ If the goal is to protect communication between A and B, is it possible to use transport-mode ESP between FW's X and Y ? If the answer is YES, then I think X and Y must reconstruct IP packets after decapsulation. 4. On computing "Authentication Data" of AH on a IPv4 datagram, what are the "invariant fields" that must be included in the computation ? Is the following list exclusive : version, ID, protocol, src and dest addresses. I am not an expert on routers; I am not sure if the DF flag is on then the 3-bit flags field and 13-bit fragment offset field are also invariant. 5. If AH is computed on a to-be-encrypted IP datagram, can the entire IP datagram be considered "invariant" ? From ipsec-request@ans.net Wed Mar 29 21:02:10 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26818 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:01:21 -0500 Received: by interlock.ans.net id AA13596 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 15:57:56 -0500 Message-Id: <199503292057.AA13596@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 15:57:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 15:57:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 15:57:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 15:57:56 -0500 From: "Marcus J. Ranum" Subject: Re: MD5 versus SHA -Reply To: kasten@ftp.com Date: Wed, 29 Mar 1995 16:02:10 -0500 (EST) Cc: touch@ISI.EDU, Ed_Reed@Novell.COM, atkinson@itd.nrl.navy.mil, ipsec@ans.net, smb@research.att.com In-Reply-To: <199503292039.AA21353@interlock.ans.net> from "Frank Kastenholz" at Mar 29, 95 03:36:43 pm Organization: Trusted Information Systems, Inc. Glenwood, MD Phone: 301-854-6889 Coredump: Infocalypse Now!!! Content-Type: text Content-Length: 444 >As long as we are getting into that argument, there are a lot more little >endian machines out there than big-endian. I'd rather we change all the >other things to be little endian. It seems to be vaguely ridiculous to be debating the question at all. When you're already talking about the computing cost of encryption and signature, what are a few byte swaps one way or another? I know, let's encode all the IP packets in ASN.1 :) mjr. From ipsec-request@ans.net Wed Mar 29 21:02:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23505 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:04:57 -0500 Received: by interlock.ans.net id AA17727 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:02:08 -0500 Message-Id: <199503292102.AA17727@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 29 Mar 1995 16:02:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 16:02:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 16:02:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 16:02:08 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:02:08 -0500 From: uri@watson.ibm.com Subject: Re: IBM's patented algorithm To: atkinson@itd.nrl.navy.mil Date: Wed, 29 Mar 1995 16:02:06 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <199503291938.AA20870@interlock.ans.net> from "Ran Atkinson" at Mar 29, 95 02:34:19 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: 1219 Ran Atkinson says: > There is community consensus behind DES CBC, which has been long > analysed in the public and has no patent issues. But it has exportability issues. You choose the problem you're comfortable with: no-export, or patent concerns. If you take 56-bit key, weaken it down to 40 bits, then expand it again to 56 bits and feed it to DES - you got CDMF... > I don't believe > that any proprietary algorithm would be a good choice as a mandatory > to implement algorithm. CDMF is essentially DES with known strength. To say it "proprietary" sounds more like a name-calling. It's less "proprietary" than RSA, for example. At least here you can get some free commercial usage (:-). > I personally find the IBM license terms that you describe to be onerous. We [technical people in IBM] are fighting to make it royalty-free. The lawyers [so far] don't agree. What I described was the best we could get from them [till now]. The battle continues. But personally - I don't think it's too onerous to say: "You can use my patent free, if you allow me to use yours (unless you have no patent,in which case just use mine)". -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Wed Mar 29 21:12:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21376 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:19:01 -0500 Received: by interlock.ans.net id AA23834 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:12:41 -0500 Message-Id: <199503292112.AA23834@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 29 Mar 1995 16:12:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 16:12:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 16:12:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 16:12:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:12:41 -0500 From: uri@watson.ibm.com Subject: Re: IPv6 Security Last Call Initial Questions To: tytso@MIT.EDU (Theodore Ts'o) Date: Wed, 29 Mar 1995 16:12:25 -0500 (EST) Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: <9503292041.AA01462@dcl.MIT.EDU> from "Theodore Ts'o" at Mar 29, 95 03:41:39 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: 1328 Theodore Ts'o says: > IP issues aside, what's the strength of CDMF? My understanding of 40 > bit RC4 is that it doesn't give away anything about the NSA's ability to > crack cyphers. 40-bit RC4 is reportedly quiet easy for anyone to > cryptoanalyze. Let's see - it's 56 bits in, internally weakened to 40. SO overall strength is 40 bits - but you can't just mount brute-force attack. But why trust me - look it up and decide for yourself! > If CDMF is similarily weak, what's the point of using it at all? Well, it's only 40 bits strong. I don't think it's as weak as 40-bits RC4. Under today's laws, even this was quite a bitch to get exportable. I can't see how anything better will be exportable, unless the regulations change. So if being exportable is your goal - you'll have to balance the security requirements (yes, DES with subkeys provided by pseudo-random generator is more secure - but you'll never export it, ever) with your other constrains, like can you afford a product, that is stuck witnin USA? My answer to your question would be - I'd use CDMF if being exportable were more important for me, than being absolutely unbreakable. I realize that it is impossible to satisfy both under current laws. Sacrifice - you choose. -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Wed Mar 29 21:03:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20609 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:19:01 -0500 Received: by interlock.ans.net id AA53822 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:13:09 -0500 Message-Id: <199503292113.AA53822@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 16:13:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 16:13:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 16:13:09 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:13:09 -0500 From: "Marcus J. Ranum" Subject: Re: IPv6 Security Last Call Initial Questions To: tytso@MIT.EDU (Theodore Ts'o) Date: Wed, 29 Mar 1995 16:03:56 -0500 (EST) Cc: uri@watson.ibm.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net In-Reply-To: <199503292041.AA52740@interlock.ans.net> from "Theodore Ts'o" at Mar 29, 95 03:41:39 pm Organization: Trusted Information Systems, Inc. Glenwood, MD Phone: 301-854-6889 Coredump: Infocalypse Now!!! Content-Type: text Content-Length: 339 > enjoys similar exportability as RC2/RC4 (except the review time > is 15 days instead of 7)... > >IP issues aside, what's the strength of CDMF? My understanding of 40 If it's exportable, then you already know everything you need to about its strength. Sure, it's better than ROT13 but not enough that I'd want to use it. :) mjr. From ipsec-request@ans.net Wed Mar 29 11:10:49 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07299 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:19:03 -0500 Received: by interlock.ans.net id AA21319 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:13:16 -0500 Message-Id: <199503292113.AA21319@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 16:13:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 16:13:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 16:13:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:13:16 -0500 Date: Wed, 29 Mar 95 16:10:49 EST To: mjr@tis.com Subject: Re: MD5 versus SHA -Reply From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: touch@ISI.EDU, Ed_Reed@Novell.COM, atkinson@itd.nrl.navy.mil, ipsec@ans.net, smb@research.att.com Content-Length: 657 > >As long as we are getting into that argument, there are a lot more little > >endian machines out there than big-endian. I'd rather we change all the > >other things to be little endian. > > It seems to be vaguely ridiculous to be debating the question > at all. When you're already talking about the computing cost of > encryption and signature, what are a few byte swaps one way or > another? Oh dear. Did I forget the :-)? -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln From ipsec-request@ans.net Wed Mar 29 07:04:11 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23439 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:19:28 -0500 Received: by interlock.ans.net id AA52258 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:12:46 -0500 Message-Id: <199503292112.AA52258@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 16:12:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:12:46 -0500 Date: Wed, 29 Mar 95 12:04:11 EST From: hugo@watson.ibm.com To: karn@qualcomm.com Cc: IPSEC@ans.net Subject: fast re-keying Phil, This is a response to an "old" note of you on fast re-keying (2 weeks and 300 messages old ;-), which I believe is an important issue. I am glad that we agree on the necessity of a fast re-keying mechanism based on MD5 or alike functions in addition to the basic (and significantly more expensive) key exchanges based on public key and/or Diffie-Hellman. Now it just remains to agree on the details. Following are my comments to your proposal (indented text is from your note). > I propose that the session key be derived from the following: > > MD5 { local cookie, remote cookie, shared DH secret, SAID } > > Use as many bits as you need from the front of the hash result. E.g., > for single-key DES, take the first 64 bits and overwrite every 8th bit > to have the proper parity. For IDEA, just use the entire MD5 result > as-is. 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). > > The cookies are included mainly so that different keys are generated > for each direction of transmission. They're handy enough. > > Including the SAID in the hash is how I generate distinct keys for > each new SAID between a given host pair without requiring a new DH > exchange each time. This does imply a new SAID everytime you rekey, > which I consider reasonable given the size of the field. It also keeps > the protocol simple. 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). You can say: where do I put these nonces in the protocol? Very simple, put them instead of the DH parts g^x, g^y. 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 g and p it will come to 3000 bits that are essentially unused). Since in any case the field for g^x is variable-length (it depends on the size of the modulus) one can specify that a length of less than, say, 128 bits, means that the field carries a nonce. The later is just to demonstrate that you do not have to create new message types in order to support fast re-keying (although I personally prefer to have these messages independent from the basic key exchange, i.e. from the details of the PK/DH based protocol. In any case, this is a separate issue for discussion). > > Creating a new SAID without a new DH computation doesn't necessarily > require adding new message types, although it could be done that way. > It could simply follow the same Photuris exchange, possibly with a new > set of cookies if they are time-varying. In the DH step, though, the > previous public values would be exchanged. The DH module in the > implementation could compare the new values to the ones previously > received. If they're the same, and if we haven't generated a new > public value on our end, we'd simply bypass the DH exponentiation > and keep the old shared secret. 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. Now, if you want to see a particular implementation of the ideas sketched above you can check our MKMP draft (draft-cheng-modular-ikmp-00.txt or .ps). It contains a fast re-key protocol that exactly fits the above description; we call this, I guess, the short-lived key protocol. In that specific protocol, we assume shared nonces but that's just for efficiency and not essential; if you prefer, you can exchange nonces during the protocol itself. In that case, it fits exactly the message structure of Photuris or my variant. There are important additional issues that you did not cover in your description, e.g., how do you derive long or multiple keys, the advantage of refreshing the "master" key with each fast re-key, reducing plaintext/ciphertext information, etc. These are left for future messages. Hugo From ipsec-request@ans.net Wed Mar 29 21:17:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA29093 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:23:07 -0500 Received: by interlock.ans.net id AA52104 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:19:41 -0500 Message-Id: <199503292119.AA52104@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 16:19:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 16:19:41 -0500 Date: Wed, 29 Mar 1995 13:17:23 -0800 From: touch@ISI.EDU Posted-Date: Wed, 29 Mar 1995 13:17:23 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:19:41 -0500 To: kasten@ftp.com, mjr@tis.com Subject: Re: MD5 versus SHA -Reply Cc: touch@ISI.EDU, Ed_Reed@Novell.COM, atkinson@itd.nrl.navy.mil, ipsec@ans.net, smb@research.att.com > >As long as we are getting into that argument, there are a lot more little > >endian machines out there than big-endian. I'd rather we change all the > >other things to be little endian. > > It seems to be vaguely ridiculous to be debating the question > at all. When you're already talking about the computing cost of > encryption and signature, what are a few byte swaps one way or > another? Perhaps. But perhaps it's ridiculous to define an authentication mechanism that explicitly defines non-standard network byte order. :-} Joe From ipsec-request@ans.net Wed Mar 29 21:21:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25300 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:31:51 -0500 Received: by interlock.ans.net id AA53769 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:25:24 -0500 Message-Id: <199503292125.AA53769@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:25:24 -0500 From: Ran Atkinson Date: Wed, 29 Mar 1995 16:21:48 -0500 In-Reply-To: uri@watson.ibm.com "Re: IBM's patented algorithm" (Mar 29, 16:02) References: <9503292102.AA22922@buoy.watson.ibm.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: uri@watson.ibm.com Subject: Re: IBM's patented algorithm Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Uri, ALL export of encryption algorithms used to provide confidentiality require a license under US law. You could try to argue about ease of obtaining a license, but there is no way to prove much either way since I know of commercial export of DES that was licensed very fast. It is not productive to continue this discussion, so I won't. Ran From ipsec-request@ans.net Wed Mar 29 11:24:40 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25114 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:39:15 -0500 Received: by interlock.ans.net id AA30953 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:33:44 -0500 Message-Id: <199503292133.AA30953@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 16:33:44 -0500 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:33:44 -0500 To: Theodore Ts'o Cc: uri@watson.ibm.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions Date: Wed, 29 Mar 95 16:24:40 EST From: uri@watson.ibm.com Date: Wed, 29 Mar 1995 14:04:47 -0500 (EST) And then there is CDMF, which is rather similar to DES, and which enjoys similar exportability as RC2/RC4 (except the review time is 15 days instead of 7)... IP issues aside, what's the strength of CDMF? My understanding of 40 bit RC4 is that it doesn't give away anything about the NSA's ability to crack cyphers. 40-bit RC4 is reportedly quiet easy for anyone to cryptoanalyze. If CDMF is similarily weak, what's the point of using it at all? CDMF is very elegant. ``Its strength is as the strength of DES, because its S-boxes are pure''... More seriously, CDMF is DES-based. If you can't cryptanalyze DES, you can't cryptanalyze CDMF. You can do a brute-force search on the 40-bit key, of course, but there are barriers to short-cut attacks. The paper is well worth reading. From ipsec-request@ans.net Wed Mar 29 11:29:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28195 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:39:43 -0500 Received: by interlock.ans.net id AA49879 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:33:34 -0500 Message-Id: <199503292133.AA49879@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 16:33:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 16:33:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 16:33:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:33:34 -0500 Date: Wed, 29 Mar 95 16:29:30 EST To: touch@ISI.EDU Subject: Re: MD5 versus SHA -Reply From: solensky@ftp.com (Frank T Solensky) Cc: ipsec@ans.net Sender: solensky@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Wed Mar 29 16:29:26 1995] Originating-Client: beehive.ftp.com Content-Length: 201 > One MAJOR flaw in MD5 is using little-endian (anti-"network standard" > byte order). Those of us who work on little-endians might see that as a way of distributing the pain.. ;-) -- Frank S From ipsec-request@ans.net Wed Mar 29 21:36:57 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15434 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:43:55 -0500 Received: by interlock.ans.net id AA56778 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:38:24 -0500 Message-Id: <199503292138.AA56778@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 16:38:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 16:38:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 16:38:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:38:24 -0500 To: uri@watson.ibm.com Cc: ipsec@ans.net Subject: Re: IBM's patented algorithm In-Reply-To: Your message of "Wed, 29 Mar 1995 16:02:06 EST." <199503292102.AA17727@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 29 Mar 1995 16:36:57 -0500 From: "Perry E. Metzger" uri@watson.ibm.com says: > Ran Atkinson says: > > There is community consensus behind DES CBC, which has been long > > analysed in the public and has no patent issues. > > But it has exportability issues. On the other hand, independent implementations overseas are a dime a dozen. .pm From ipsec-request@ans.net Wed Mar 29 21:46:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20648 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 16:51:39 -0500 Received: by interlock.ans.net id AA52668 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 16:47:19 -0500 Message-Id: <199503292147.AA52668@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 29 Mar 1995 16:47:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 16:47:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 16:47:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 16:47:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 16:47:19 -0500 From: uri@watson.ibm.com Subject: Re: IPv6 Security Last Call Initial Questions To: tytso@MIT.EDU (Theodore Ts'o) Date: Wed, 29 Mar 1995 16:46:37 -0500 (EST) Cc: ipsec@ans.net In-Reply-To: <9503292135.AA01893@dcl.MIT.EDU> from "Theodore Ts'o" at Mar 29, 95 04:35:40 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: 1105 Theodore Ts'o says: > Could one of you send me a reference to the paper? > (On-line preferred, of course. :-) I don't have the oaper online, only the reference. Sorry! (:-). Posting this in case somebody else (not you, Ran, I understand! :-) are interested. 1. The description of the CDMF algorithm has been published in the open literature, as follows: a. D.B.Johnson, S.M. Matyas, A.V. Le, and J.D. Wilkins, "Design of the Commercial Data Masking Facility Data Privacy Algorithm," Proceedings of the 1st ACM Conference on Computer and Communications Security, November 3-5, 1993, Fairfax, Virginia, 1993. pp. 93-96. b. D.B Johnson, S.M. Matyas, A.V. Le, and J.D. Wilkins, "The Commercial Data Masking Facility (CDMF) Data Privacy algorithm," IBM Jour. of Research and Development, Vol. 38, No. 2, 217-226 (March 1994). 2. IBM holds a patent on the CDMF, see R.C. Elander et al., "Commercial Data Masking," issued U.S. patent no. 5,323,464 (Jun. 21, 1994). -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Wed Mar 29 22:08:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04203 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 17:12:12 -0500 Received: by interlock.ans.net id AA51951 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 17:08:26 -0500 Message-Id: <199503292208.AA51951@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 29 Mar 1995 17:08:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 17:08:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 17:08:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 17:08:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 17:08:26 -0500 X-Mailer: exmh version 1.5.3 12/28/94 To: atkinson@itd.nrl.navy.mil Cc: uri@watson.ibm.com, ipsec@ans.net Subject: Re: IBM's patented algorithm In-Reply-To: Your message of "Wed, 29 Mar 1995 16:21:48 EST." <199503292125.AA53769@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Mar 1995 17:08:13 -0500 From: " " Ran says: > Uri, > > ALL export of encryption algorithms used to provide confidentiality > require a license under US law. Unless you get a blanket license for a particular algorithm. As far as I know, this is NOT the case for CDMF. Apart from this, I don't want to be involved with discussing the appropriateness of CDMF, as this is a project of a different IBM group. (of course I can connect interested parties to that group.) > You could try to argue about ease > of obtaining a license, but there is no way to prove much either way > since I know of commercial export of DES that was licensed very fast. That's different - Uri talks about `blanket license' which does not look at the application. But CDMF does NOT have that as far as I know. > It is not productive to continue this discussion, so I won't. Completely agree!! I'll join Ran. Best, Amir From ipsec-request@ans.net Wed Mar 29 22:26:28 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07272 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 17:48:27 -0500 Received: by interlock.ans.net id AA50917 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 17:41:46 -0500 Message-Id: <199503292241.AA50917@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 17:41:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 17:41:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 17:41:46 -0500 To: uri@watson.ibm.com Cc: tytso@MIT.EDU (Theodore Ts'o), ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Wed, 29 Mar 95 16:46:37 EST." <199503292147.AA52668@interlock.ans.net> Date: Wed, 29 Mar 95 17:26:28 -0500 From: bound@zk3.dec.com X-Mts: smtp Uri, I am interested in your idea and I think the IPSEC WG should pursue it and I think the discussion is productive. If we can find an algorithm for encryption that will make exporting easier this could help us to reach connsensus in the vendor community to have a default with a MUST in the spec, for ESP. I can't speak for my folks but I need to ask first. If I have a patent for security other than cryptography would we have to let IBM use that? Or does this only apply to patents we may have for the specific function for ESP? Do we need to get someone from U.S. Exports on this list? p.s. I did not think your terms were onerous at all. I just looked the word up and your terms presented are actually counter to being onerous. /jim From ipsec-request@ans.net Thu Mar 30 13:53:56 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28262 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 18:15:25 -0500 Received: by interlock.ans.net id AA52576 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 18:09:13 -0500 Message-Id: <199503292309.AA52576@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 29 Mar 1995 18:09:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 18:09:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 18:09:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 18:09:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 18:09:13 -0500 From: "Ian Farquhar" Date: Thu, 30 Mar 1995 08:53:56 -0500 In-Reply-To: "Theodore Ts'o" "Re: IPv6 Security Last Call Initial Questions" (Mar 29, 3:41pm) References: <199503292041.AA52740@interlock.ans.net> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions Cc: ianf@wiley.sydney.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 29, 3:41pm, Theodore Ts'o wrote: > IP issues aside, what's the strength of CDMF? Yes, I must admit that it's not one I have ever seen a description of. Is anyone in a position to post or direct us to an algorithm description? > My understanding of 40 > bit RC4 is that it doesn't give away anything about the NSA's ability to > crack cyphers. 40-bit RC4 is reportedly quiet easy for anyone to > cryptoanalyze. Presuming that what was posted to the net recently was actually RC4 (which on the weight of evidence so far seems likely), I have not seen any reasonable cryptanalytic attacks on the cipher if it is used properly. RSA is supposed to possess a whole bunch of studies of it, but they are not making them public at this stage, as far as I know. As for the time required to break a 40 bit key, I'd suggest that someone actually try it. The key schedule needs 256 iterations of a data-dependent loop, and optimizations which would reduce that time are certainly NOT obvious. I'd say that RSA's own estimate of 200 MIP/years to crack the cipher is fairly accurate. Sure, it's doable. But it's not a kid-with-a-PC- in-a-week proposition. It's barely an engineer-with-a-large-MP-system-in- a-work proposition, in fact. Ian. From ipsec-request@ans.net Wed Mar 29 23:55:12 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27549 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 19:03:54 -0500 Received: by interlock.ans.net id AA42911 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 18:58:12 -0500 Message-Id: <199503292358.AA42911@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 18:58:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 18:58:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 18:58:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 18:58:12 -0500 To: bound@zk3.dec.com Cc: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Wed, 29 Mar 1995 17:26:28 EST." <199503292241.AA50917@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Wed, 29 Mar 1995 18:55:12 -0500 From: "Perry E. Metzger" bound@zk3.dec.com says: > I am interested in your idea and I think the IPSEC WG should pursue it > and I think the discussion is productive. Jim; Just to repeat -- any exportable algorithm is too weak to provide any security. This is the case with all these 40 bit key algorithms. You can break them over the weekend in your lab. Perry From ipsec-request@ans.net Wed Mar 29 14:57:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07260 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 20:07:08 -0500 Received: by interlock.ans.net id AA19605 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 19:59:53 -0500 Message-Id: <199503300059.AA19605@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 29 Mar 1995 19:59:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 19:59:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 19:59:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 19:59:53 -0500 Date: Wed, 29 Mar 95 19:57:48 EST To: bound@zk3.dec.com Subject: Re: IPv6 Security Last Call Initial Questions From: solensky@ftp.com (Frank T Solensky) Cc: ipsec@ans.net Sender: solensky@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Wed Mar 29 19:57:46 1995] Originating-Client: beehive.ftp.com Content-Length: 787 > Date: Wed, 29 Mar 95 17:26:28 -0500 > From: bound@zk3.dec.com > > I can't speak for my folks but I need to ask first. If I have a patent > for security other than cryptography would we have to let IBM use that? > Or does this only apply to patents we may have for the specific > function for ESP? If "my folks" and "we" is DEC, that still begs the meta-issue. While neither are technical issues, patents seem to be a greater huldle to adoption than exportability. If I (in the generic sense) can't export it, I can still tell you about someplace where you can import it and we're interoperating. Patents often involves paying some money to someone. Regardless of how nominal that fee is, it still acts as a barrier to someone implementing off open standards. -- Frank S From ipsec-request@ans.net Sun Mar 30 02:11:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25129 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 21:25:13 -0500 Received: by interlock.ans.net id AA47454 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 21:21:29 -0500 Message-Id: <199503300221.AA47454@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 21:21:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 21:21:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 21:21:29 -0500 Date: 29 Mar 1995 18:11:23 -0800 From: "Joe Tardo" Subject: Re: IPv6 Security Last Call To: smb@research.att.com, "Theodore Ts'o" Cc: atkinson@itd.nrl.navy.mil, ipsec@ans.net, uri@watson.ibm.com X-Mailer: Mail*Link SMTP-QM 3.0.2 Reply to: RE>>IPv6 Security Last Call Initial Questions >CDMF is very elegant. ``Its strength is as the strength of DES, because >its S-boxes are pure''... > >More seriously, CDMF is DES-based. If you can't cryptanalyze DES, you >can't cryptanalyze CDMF. You can do a brute-force search on the 40-bit >key, of course, but there are barriers to short-cut attacks. The paper >is well worth reading. So, can anyone document that CDMF is *really* exportable with a C.J., something akin to NSA's "Mass Market Software Product" criteria published in John Gilmore's "CJR kit" for 7-day C.J. using RC4? From ipsec-request@ans.net Thu Mar 30 02:38:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26758 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 21:42:40 -0500 Received: by interlock.ans.net id AA13855 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 21:38:26 -0500 Message-Id: <199503300238.AA13855@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 29 Mar 1995 21:38:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 21:38:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 21:38:26 -0500 Date: Wed, 29 Mar 1995 19:38:19 -0700 From: Hilarie Orman To: IPSEC@ans.net Subject: Re: key-ed MD5 again An additional note on this subject from Richard Schroeppel (rcs@cs.arizona.edu) follows. As it is a rather detailed missive, let me summarize the bottom line as a contribution to rough concensus in favor of MD5(key,data,key). Date: Tue, 28 Mar 95 14:26:29 GMT From: "William Allen Simpson" To: IPSEC@ans.net Subject: Re: key-ed MD5 again Status: R > From: Masataka Ohta > > Some significant analysts think that a single key at the beginning of > > MD5 does not provide enough key material when the text is long. The > > MD5(key,MD5(text)) was suggested to improve the effect of the key in the > > final hash. > > As MD5 is a chain of addition, a transitive 1-to-1 mapping, of > hashed values, it is unlikely that the initial scrambling effect > by the added hased key is weakened later. > An excellent question? The conclusion was passed to me word of mouth. But, looking at the algorithm, it seems to me that up to 4 bits of influence can be lost from the high end of the sum on each block from lost carry in the four registers. As the text grows longer, less of the initial key effect is seen. It is that addition was used instead of xor that has this result. Bill.Simpson@um.cc.umich.edu The final few lines of the reference inplementation of MD5 are buf[0] += a; buf[1] += b; buf[2] += c; buf[3] += d; Here buf[] is an array of 4 32bit words that represent the state of MD5 before eating the present block (64 bytes) of information; and a,b,c,d are 4 32bit words that are a very-complicated function of both buf[] and the 64byte data block. The fact that the combining operator used here is + rather than xor doesn't cause any information loss. The missing carries don't matter in the least: If we know the contents of buf[] after this code has been executed, and the values of a,b,c,d, then we can perfectly well determine the contents of buf[] prior to the code; in fact, we could do buf[0] -= a; buf[1] -= b; buf[2] -= c; buf[3] -=d; to recover the original four 32bit numbers in buf[]. Using an xor operator would be equivalent, from the perspective of (no) information loss in these 4 lines of code. The information loss in MD5(key, VeryLongText) is more subtle, and arguably inconsequential. Suppose we model the MD5 block-eating operation as a random map of 128bits -> 128bits, with the particular details of the map determined by the 64 byte data block that is consumed. The range of such a random map will typically include only 63% of the possible values; each range value has a 1/e chance of not appearing. About 37% of the range values have one inverse, 18% have two inverses, etc. Eating one data block has, in effect, erased .66 bits of information from the original 128bit state, since the range contains only 2^127.34 values. This is no big deal, but clearly will be a problem if multiple rounds of the MD5 operation continue to erase .66 bits on each round. But this doesn't happen. On the next round, since the first-round range has diminished by a factor of .63, the percentage of colliding values also drops: After two random maps, the expected range size is 47% of the initial range, which is larger than .63^2. The recursion for the expected range size after N applications of (independent) random maps is - F(N) F(0) = 1; F(N+1) = 1 - e The first few values after F(0) = 1 are F(1) = .632, F(2) = .469, F(3) = .374, F(4) = .312, F(5) = .268 ... 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. Now suppose Shamir comes up with some discovery that, say, the high bit of each word of the MD5 state is lost during the mapping process, so that 16 initial MD5 states map to one range state. It almost doesn't matter! The recursion above becomes - 16 F(N) F(0) = 1; F(N+1) = 1 - e Although the information loss in the first round is dramatic, the asymptotic formula for this revised F is just F(N) ~= 2 / (16 N + log terms). So the amount of extra information loss from the initial state is 4 bits. The formula MD5(Key, VeryLongText) means that Key is a 128bit initial value put into the MD5 state. We can achieve almost the same effect by prefixing Key to VeryLongText and using regular MD5 with the standard initial state. If we also append Key, getting MD5( Key .conc. VeryLongText .conc. Key ) then we cancel out all of the intermediate information loss discussed above, and also protect against some appending attacks. Rich Schroeppel rcs@cs.arizona.edu From ipsec-request@ans.net Wed Mar 29 16:44:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24977 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 21:47:27 -0500 Received: by interlock.ans.net id AA46254 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 21:45:18 -0500 Message-Id: <199503300245.AA46254@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 21:45:18 -0500 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 21:45:18 -0500 To: ipsec@ans.net Subject: IBM's Commercial Data Masking Facility Date: Wed, 29 Mar 95 21:44:27 EST Folks interested in it may want to retrieve http://www.town.hall.org/Archives/patent/data/05323/05323464 From ipsec-request@ans.net Wed Mar 29 23:11:51 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04267 (5.65c/IDA-1.4.4 for ); Wed, 29 Mar 1995 23:11:51 -0500 Received: by interlock.ans.net id AA08390 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 29 Mar 1995 22:56:22 -0500 Message-Id: <199503300356.AA08390@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 29 Mar 1995 22:56:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 29 Mar 1995 22:56:22 -0500 From: Masataka Ohta Subject: Re: key-ed MD5 again To: ho@cs.arizona.edu (Hilarie Orman) Date: Thu, 30 Mar 95 12:54:30 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] > An additional note on this subject from Richard Schroeppel > (rcs@cs.arizona.edu) follows. As it is a rather detailed missive, let > me summarize the bottom line as a contribution to rough concensus in > favor of MD5(key,data,key). No objections. But, > MD5( Key .conc. VeryLongText .conc. Key ) > > then we cancel out all of the intermediate information loss discussed > above, and also protect against some appending attacks. I can feel a little more happy, if someone can explain why, MD5( Key .conc. Initialtext .conc. VeryLongText .conc. Key ) the forgery of the Initialtext part is less important, and why, MD5, which also hashes the message length, must be protected against appending attacks. Masataka Ohta From ipsec-request@ans.net Thu Mar 30 04:58:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21397 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 00:08:56 -0500 Received: by interlock.ans.net id AA24607 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 00:02:24 -0500 Message-Id: <199503300502.AA24607@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 00:02:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 00:02:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 00:02:24 -0500 To: solensky@ftp.com (Frank T Solensky) Cc: bound@zk3.dec.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Wed, 29 Mar 95 19:57:48 EST." <9503300057.AA11315@mailserv-D.ftp.com> Date: Wed, 29 Mar 95 23:58:50 -0500 From: bound@zk3.dec.com X-Mts: smtp > Date: Wed, 29 Mar 95 17:26:28 -0500 > From: bound@zk3.dec.com > > I can't speak for my folks but I need to ask first. If I have a patent > for security other than cryptography would we have to let IBM use that? > Or does this only apply to patents we may have for the specific > function for ESP? >If "my folks" and "we" is DEC, that still begs the meta-issue. Not sure my representation of 'folks' required the above response but OK. I also say words like 'ya all' or 'yo dude' or 'mey boyz'. Many studies in the U.S. have taught us to reach true freedom we must all learn to value each others differences. This includes the dialect of others who may not be known to us. Besides that where I am from that could "really piss someone off" (to use a dialect in one area of the U.S. I have lived anyway, not mine of course!!). The point is to keep this mail civil we have to be careful how we respond. It doesn't really matter what "folks" defined at all and was my way of talking off the top of my head in a response. >While neither are technical issues, patents seem to be a greater Whats the point of your "While..." clause in the sentence above I ask before I interpret it to be courteous to you? If its that engineers only concern themselves with 'technical' issues then I disagree completely? Or if the IETF discussions should only consist of bits and bytes discussions I again disagree? But I assume you mean't something else? Many products have been built that were great engineering pieces of work, but nobody bought them on the market. This I think is OK for artists or even philosophers, but if one would do this as an engineer, if I ran a business, and it happened more than once (you can screw up once) I would fire the engineer for being incompetent, or move them to research if they were really good with ideas and generating prototypes to look at for the market. >huldle to adoption than exportability. If I (in the generic sense) >can't export it, I can still tell you about someplace where you can >import it and we're interoperating. Patents often involves paying >some money to someone. Regardless of how nominal that fee is, it >still acts as a barrier to someone implementing off open standards. But the nominal fee may be cheaper than the cost in "time" to deal with getting another export license, so it could be cheaper. These kinds of decisions are now in engineering made all the time in our industry its the decision to buy vs build. Plus CDMF costs nothing unless you have a patent, so your input "may" apply in the abstract case, but not in this case. CDMP sounds like virtual GNU freeware. /jim From ipsec-request@ans.net Thu Mar 30 05:07:25 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15529 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 00:12:42 -0500 Received: by interlock.ans.net id AA23587 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 00:11:07 -0500 Message-Id: <199503300511.AA23587@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 00:11:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 00:11:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 00:11:07 -0500 To: perry@imsi.com Cc: bound@zk3.dec.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Wed, 29 Mar 95 18:55:12 EST." <9503292355.AA16549@snark.imsi.com> Date: Thu, 30 Mar 95 00:07:25 -0500 From: bound@zk3.dec.com X-Mts: smtp Date: Wed, 29 Mar 1995 18:55:12 -0500 From: "Perry E. Metzger" >bound@zk3.dec.com says: > I am interested in your idea and I think the IPSEC WG should pursue it > and I think the discussion is productive. >Jim; >Just to repeat -- any exportable algorithm is too weak to provide any >security. This is the case with all these 40 bit key algorithms. You >can break them over the weekend in your lab. I have heard this but not from what "I" consider the experts (e.g. Bellovin, Karn, Kent, Kaufmann, Eastlake, S. Crocker, Nessett, Tardo, Linn, and others). I take the comments so far to be some input and I am not jumping completely on the band-wagon, but I think CDMF needs to be investigated as I have a real problem as all know by now with the ESP DES MUST. And we do not have consensus obviously by all as this mail shows, that ESP should state MUST DES. For sure NOT in the vendor community. Thus the investigation continues.............but if your right we will know shortly for sure. /jim From ipsec-request@ans.net Thu Mar 30 11:06:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12921 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 06:21:28 -0500 Received: by interlock.ans.net id AA44051 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 06:06:33 -0500 Message-Id: <199503301106.AA44051@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 30 Mar 1995 06:06:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 06:06:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 06:06:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 06:06:33 -0500 X-Mailer: exmh version 1.5.2 12/21/94 To: bound@zk3.dec.com Cc: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions Organization: Open Software Systems Group, DRA Malvern, UK References: <199503300502.AA24607@interlock.ans.net> In-Reply-To: <199503300502.AA24607@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Mar 1995 12:06:03 +0100 From: Christopher Samuel In message <199503300502.AA24607@interlock.ans.net>, bound@zk3.dec.com writes: > But the nominal fee may be cheaper than the cost in "time" to deal with > getting another export license, so it could be cheaper. I doubt if this would be well received by the free Un*x community. The default option, IMHO, *must* be free to be used in something like Linux, otherwise it'll just get laughed at. I suspect that this is going to be a very thorny problem. Disclaimer: just speaking for myself. -- Christopher Samuel Open Software Systems Group chris@rivers.dra.hmg.gb N-115, Defence Research Agency, St Andrews Road, Great Malvern, England, UK "You can't write space opera in a vacuum" -- Iain Banks From ipsec-request@ans.net Thu Mar 30 02:14:18 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12997 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 07:23:34 -0500 Received: by interlock.ans.net id AA13053 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 07:15:12 -0500 Message-Id: <199503301215.AA13053@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 07:15:12 -0500 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 07:15:12 -0500 To: bound@zk3.dec.com Cc: perry@imsi.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions Date: Thu, 30 Mar 95 07:14:18 EST Date: Wed, 29 Mar 1995 18:55:12 -0500 From: "Perry E. Metzger" >Just to repeat -- any exportable algorithm is too weak to provide any >security. This is the case with all these 40 bit key algorithms. You >can break them over the weekend in your lab. I have heard this but not from what "I" consider the experts (e.g. Bellovin, Karn, Kent, Kaufmann, Eastlake, S. Crocker, Nessett, Tardo, Linn, and others). I'm afraid it's a simple matter of arithmetic. Let's look at Joe Touch's performance numbers. He got DES speeds ranging from 20-37 Mbps. To make the arithmetic easy, let's just say 32 Mbps. At 64 bits per block, that's .5 M encryptions/second, or 2 microseconds per encryption. To exhaustively search a 40-bit key space, we need to do about 10^12 operations. Assume that the key setup overhead for an exportable cipher is about 5 DES operations (and that's an overestimate, in my opinion), or 10^-5 seconds. That means that a single processor could search the key space in 10^7 seconds. Run this in parallel on 100 idle machines (or hacked machines on a LAN), and you're done in 10^5 seconds. That's a bit over one day. Note that the only real assumption in this analysis is how long it takes to do one key setup+encryption operation. Even if I'm off by a factor of 10, it still gives you no privacy protection, though arguably it's safe for now for authentication, since few sessions last 11.5 days. --Steve Bellovin From ipsec-request@ans.net Thu Mar 30 03:49:05 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04265 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 08:55:10 -0500 Received: by interlock.ans.net id AA13446 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 08:50:12 -0500 Message-Id: <199503301350.AA13446@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 08:50:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 08:50:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 08:50:12 -0500 Date: Thu, 30 Mar 95 08:49:05 EST X-Sender: shirey@smiley.mitre.org (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: touch@ISI.EDU From: shirey@mitre.org (Robert W. Shirey) Subject: Re: MD5 versus SHA Cc: touch@ISI.EDU, smb@research.att.com, ipsec@ans.net, galvin@tis.com, Burt Kaliski , Jim Galvin At 10:26 AM 3/29/95, touch@ISI.EDU wrote: ... >However, the choice of MD5 for SNMP did not include performance >considerations. Jim Galvin, who chaired the original SNMP Security WG, or perhaps one of the other implementers at that time, would probably be a better person to comment on this. However, I recall being at that WG in Santa Fe when MD5 was finally selected. Until then, there has been the usual speculation about "too slow" etc. At that meeting, the implementers presented performance results gathered since the previous IETF. They indicated that the MD5 operations did not add significantly to SNMP processing and the "too slow" discussion was a waste of time. I suggest that what is needed now is experience with prototype ipsec implementations with MD5 and, if you wish, with other schemes. Then, and only then, should a final decision be made. However, given that we have begun to accumulate substantial experience with MD5 that is leading to confidence in its cryptographic strength, the "other" schemes have to be a "lot" faster than MD5 to risk replacing MD5. And, if the "other" scheme is new, and has not been subject to substantial cryptanalysis, it will be too risky to use anyway. Have I missed something? -Rob- From ipsec-request@ans.net Thu Mar 30 14:27:19 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12715 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 09:30:46 -0500 Received: by interlock.ans.net id AA46083 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 09:27:13 -0500 Message-Id: <199503301427.AA46083@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 09:27:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 09:27:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 09:27:13 -0500 Reply-To: James M Galvin To: touch@isi.edu Cc: ipsec@ans.net, burt@rsa.com Subject: Re: MD5 versus SHA In-Reply-To: 's message of Thu, 30 Mar 1995 08:49:05 EST. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <21993.796573638.1@tis.com> Date: Thu, 30 Mar 1995 09:27:19 -0500 From: James M Galvin >However, the choice of MD5 for SNMP did not include performance >considerations. In fact, this is exactly why we chose it. I should know. I was chair fo the SNMP Security Working Group and I'm co-author of the security documents. Originally, we chose MD4, precisely because of its performance. However, Rivest/RSADSI was quick to point out that the techniques used in MD4 were "cutting edge" for hash algorithms and he was concerned about its adoption before it had a chance to be properly scrutinized (viz the recent observation about "patterns" in the second and third rounds of its four rounds). Thus was born MD5, an algorithm designed to be "fast" using techniques generally considered "secure". I'm sure Burt will let us know if I'm misrepresented Rivest/RSADSI's position. Jim From ipsec-request@ans.net Thu Mar 30 15:27:20 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20627 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 10:33:12 -0500 Received: by interlock.ans.net id AA44440 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 10:30:13 -0500 Message-Id: <199503301530.AA44440@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 30 Mar 1995 10:30:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 10:30:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 10:30:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 10:30:13 -0500 To: bound@zk3.dec.com Cc: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Thu, 30 Mar 1995 00:07:25 EST." <9503300507.AA02052@xirtlu.zk3.dec.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 30 Mar 1995 10:27:20 -0500 From: "Perry E. Metzger" bound@zk3.dec.com says: > >Just to repeat -- any exportable algorithm is too weak to provide any > >security. This is the case with all these 40 bit key algorithms. You > >can break them over the weekend in your lab. > > I have heard this but not from what "I" consider the experts (e.g. > Bellovin, Karn, Kent, Kaufmann, Eastlake, S. Crocker, Nessett, Tardo, > Linn, and others). Jim; I believe J.I. is monitoring this mailing list, so I'll let him speak for himself, but he figured out for me last year when he was playing with RC4 that 40 bit RC4 could be broken with the resources he had available at the CS department at Columbia in a few days. If you like, I'll try to make sure that he posts figures. I'll point out that I consider anything that can be broken for under $1,000,000 to be completely unacceptable given my interests in the banking community, and DES already is dangerously weak in that regard -- I'd almost prefer standardizing on 3DES. 40 bits by my measure is a complete joke. Perry From ipsec-request@ans.net Thu Mar 30 15:28:48 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28313 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 10:33:40 -0500 Received: by interlock.ans.net id AA20284 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 10:29:01 -0500 Message-Id: <199503301529.AA20284@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 30 Mar 1995 10:29:01 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 30 Mar 1995 10:29:01 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 10:29:01 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 10:29:01 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 10:29:01 -0500 From: uri@watson.ibm.com Subject: Re: IPv6 Security Last Call Initial Questions To: smb@research.att.com Date: Thu, 30 Mar 1995 10:28:48 -0500 (EST) Cc: bound@zk3.dec.com, perry@imsi.com, ipsec@ans.net In-Reply-To: <199503301215.AA13053@interlock.ans.net> from "smb@research.att.com" at Mar 30, 95 07:14:18 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: 719 smb@research.att.com says: > I'm afraid it's a simple matter of arithmetic. > > Let's look at Joe Touch's performance numbers. He got DES speeds > ranging from 20-37 Mbps. To make the arithmetic easy, let's just say > 32 Mbps. At 64 bits per block, that's .5 M encryptions/second, or 2 > microseconds per encryption. But Steve, isn't this bulk-rate encryption speed? I.e. key setup is done once, and then you pipe your data in as fast as you can? While during cryptanalysis you must perform a new key setup with every encryption (thus slowing down considerably)? Any numbers on how many key schedule setups per second can one do? -- Regards, Uri uri@watson.ibm.com N2RIU =========== From ipsec-request@ans.net Thu Mar 30 15:53:01 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23399 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 10:59:22 -0500 Received: by interlock.ans.net id AA03574 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 10:53:11 -0500 Message-Id: <199503301553.AA03574@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 30 Mar 1995 10:53:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 10:53:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 10:53:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 10:53:11 -0500 To: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Thu, 30 Mar 1995 12:06:03 +0100." <199503301106.AA44051@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 30 Mar 1995 10:53:01 -0500 From: "Perry E. Metzger" Christopher Samuel says: > In message <199503300502.AA24607@interlock.ans.net>, > bound@zk3.dec.com writes: > > But the nominal fee may be cheaper than the cost in "time" to deal with > > getting another export license, so it could be cheaper. > > I doubt if this would be well received by the free Un*x community. > The default option, IMHO, *must* be free to be used in something > like Linux, otherwise it'll just get laughed at. This isn't a joke, by the way. A friend of mine makes a very large amount of money selling Linux CDs. There are at least half a million Linux users out there, and the growth curve hasn't stopped. There are also people who have business interests in selling unencumbered 4.4lite derived systems. Perry From ipsec-request@ans.net Thu Mar 30 16:55:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22331 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 12:03:21 -0500 Received: by interlock.ans.net id AA30333 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 11:58:41 -0500 Message-Id: <199503301658.AA30333@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 11:58:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 11:58:41 -0500 To: perry@imsi.com Cc: bound@zk3.dec.com, ipsec@ans.net, cfm@columbia.sparta.com Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Thu, 30 Mar 95 10:27:20 EST." <199503301530.AA44440@interlock.ans.net> Date: Thu, 30 Mar 1995 11:55:31 -0500 From: Carl Muckenhirn In message <199503301530.AA44440@interlock.ans.net> you wrote: > > bound@zk3.dec.com says: > > >Just to repeat -- any exportable algorithm is too weak to provide any > > >security. This is the case with all these 40 bit key algorithms. You > > >can break them over the weekend in your lab. > > > > I have heard this but not from what "I" consider the experts (e.g. > > Bellovin, Karn, Kent, Kaufmann, Eastlake, S. Crocker, Nessett, Tardo, > > Linn, and others). > > Jim; > > I believe J.I. is monitoring this mailing list, so I'll let him speak > for himself, but he figured out for me last year when he was playing > with RC4 that 40 bit RC4 could be broken with the resources he had > available at the CS department at Columbia in a few days. If you like, > I'll try to make sure that he posts figures. > > I'll point out that I consider anything that can be broken for under > $1,000,000 to be completely unacceptable given my interests in the > banking community, and DES already is dangerously weak in that regard > -- I'd almost prefer standardizing on 3DES. 40 bits by my measure is a > complete joke. > > Perry It's quite a statement to say that DES "already is dangerously weak", last time I checked the national and international banking standards use just that. If DES was so bad, I'd expect that the Fed, not to mention the for profit banks, would be clamoring much harder for a "better" solution. In any case, current export regulations allow for easy (as easy as it gets) export of DES into banking systems, so use of DES for that application shouldn't present anyone with a problem. If (as has been implied over and over again) a $1M machine can be built to "break" DES, then I would expect that bank profits would be way down by now (they wouldn't announce it was through electronic theft of course). I'll also point out that privacy of wholesale bank transactions is really not the problem, it is authentication, and there the standard is symmetric-keyed Message Authentication Codes. (which now that I think of it is not much worse than keyed MD5, oh well). Also, in most countries bank records are not, to any real approximation, private, and some transactions are reported directly to the government (horrors!). As far as IP standardization goes, DES is probably the way to go, with options for other things (the Internet way!). Although US companies will need to deal with the export issue (everyone call Sec. Brown, give him a job related problem to worry about), a 40 bit toy doesn't fare any better than DES, since both need to go through the motions of export licensing. As for non-US firms, they have their own government's to worry about (cf. France). In practice, if we standardized on the Unix random() function and key management simply passed around the seeds, 99.9% of the net would never know the difference. For those that are truly worried about security, the standard needs to provide them the ability to slip in better cryptography as they see fit. carl. From ipsec-request@ans.net Thu Mar 30 17:05:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27526 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 12:09:16 -0500 Received: by interlock.ans.net id AA29674 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 12:07:01 -0500 Message-Id: <199503301707.AA29674@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 12:07:01 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 12:07:01 -0500 Date: Thu, 30 Mar 1995 09:05:30 -0800 From: touch@ISI.EDU Posted-Date: Thu, 30 Mar 1995 09:05:30 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 12:07:01 -0500 To: galvin@tis.com Subject: Re: MD5 versus SHA Cc: ipsec@ans.net, burt@rsa.com, touch@ISI.EDU > From: James M Galvin > > >However, the choice of MD5 for SNMP did not include performance > >considerations. > > In fact, this is exactly why we chose it. I should know. I was chair > fo the SNMP Security Working Group and I'm co-author of the security > documents. It appeared to me (and other subsequent RFC authors regarding the use of MD5 in RIP, etc), that performance (i.e., 100+ Mbps) was not a concern, only overhead with respect to SNMPv2: > From: shirey@mitre.org (Robert W. Shirey) > > However, I recall being at that WG in Santa Fe when MD5 was finally > selected. Until then, there has been the usual speculation about "too > slow" etc. At that meeting, the implementers presented performance results > gathered since the previous IETF. They indicated that the MD5 operations > did not add significantly to SNMP processing and the "too slow" discussion > was a waste of time. I fact, the RFC itself hints that the reference implementation of MD5 isn't as fast as desired, calling for optimization (page 7): An appendix of [3] contains a C Programming Language implementation of the algorithm. This code was written with portability being the principal objective. Implementors may wish to optimize the implementation with respect to the characteristics of their hardware and software platforms. What I tried to do was show upper-bounds on these optimizations with analysis. Given that information, and the fact that the performance requirements of IP should be higher than SNMP (i.e., SNMP can afford to be "low BW", - 20 Mbps), this should affect the decision to use MD5 in IPv6. Joe PS - the words performance speed bandwidth do not appear in RFC-1446, on which I was commenting. From ipsec-request@ans.net Thu Mar 30 01:08:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27051 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 12:14:42 -0500 Received: by interlock.ans.net id AA27073 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 12:10:22 -0500 Message-Id: <199503301710.AA27073@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 12:10:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 12:10:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 12:10:22 -0500 Date: Thu, 30 Mar 95 09:08:59 PST From: "burt" To: touch@isi.edu, James M Galvin Cc: ipsec@ans.net, Ron Rivest Subject: Re[2]: MD5 versus SHA Jim -- You've represented Ron's position accurately; RFC 1321 states: > The MD5 algorithm is an extension of the MD4 message-digest algorithm > 1,2]. MD5 is slightly slower than MD4, but is more "conservative" in > design. MD5 was designed because it was felt that MD4 was perhaps > being adopted for use more quickly than justified by the existing > critical review; because MD4 was designed to be exceptionally fast, > it is "at the edge" in terms of risking successful cryptanalytic > attack. MD5 backs off a bit, giving up a little in speed for a much > greater likelihood of ultimate security. It incorporates some > suggestions made by various reviewers, and contains additional > optimizations. The MD5 algorithm is being placed in the public domain > for review and possible adoption as a standard. While MD5 is designed for fast software implementation and is sufficiently fast for many applications, I do agree with Joe Touch's observations that there the iterative nature of MD5's design places limits on how much it can be sped up with hardware. This is not unique to MD5; other hash functions (SHA-1, MDC2) and several modes of block ciphers (CBC, OFB, CFB) have similar limitations. A more parallelizable design would be worth considering for the next generation of hash functions, though MD5 should remain fast enough for most applications for a while. -- Burt ______________________________ Reply Separator _________________________________ Subject: Re: MD5 versus SHA Author: James M Galvin at INTERNET Date: 3/30/95 6:29 AM Received: by ccmail from RSA.COM From galvin@tis.com X-Envelope-From: galvin@tis.com Received: from relay.tis.com by RSA.COM with SMTP id AA15850; Thu, 30 Mar 95 06:23:31 PST Received: from mailhub.tis.com(192.33.112.100) by relay.tis.com via smap (a1.4) id sma024905; Thu Mar 30 09:26:26 1995 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA18810; Thu, 30 Mar 95 09:26:14 EST Message-Id: <9503301426.AA18810@tis.com> Reply-To: James M Galvin To: touch@isi.edu Cc: ipsec@ans.net, burt@RSA.COM Subject: Re: MD5 versus SHA In-Reply-To: 's message of Thu, 30 Mar 1995 08:49:05 EST. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <21993.796573638.1@tis.com> Date: Thu, 30 Mar 1995 09:27:19 -0500 From: James M Galvin >However, the choice of MD5 for SNMP did not include performance >considerations. In fact, this is exactly why we chose it. I should know. I was chair fo the SNMP Security Working Group and I'm co-author of the security documents. Originally, we chose MD4, precisely because of its performance. However, Rivest/RSADSI was quick to point out that the techniques used in MD4 were "cutting edge" for hash algorithms and he was concerned about its adoption before it had a chance to be properly scrutinized (viz the recent observation about "patterns" in the second and third rounds of its four rounds). Thus was born MD5, an algorithm designed to be "fast" using techniques generally considered "secure". I'm sure Burt will let us know if I'm misrepresented Rivest/RSADSI's position. Jim From ipsec-request@ans.net Thu Mar 30 17:06:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22189 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 12:14:43 -0500 Received: by interlock.ans.net id AA31929 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 12:10:17 -0500 Message-Id: <199503301710.AA31929@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 30 Mar 1995 12:10:17 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 12:10:17 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 12:10:17 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 12:10:17 -0500 To: Carl Muckenhirn Cc: bound@zk3.dec.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Thu, 30 Mar 1995 11:55:31 EST." <9503301655.AA06445@columbia.sparta.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 30 Mar 1995 12:06:47 -0500 From: "Perry E. Metzger" Carl Muckenhirn says: > It's quite a statement to say that DES "already is dangerously weak", last > time I checked the national and international banking standards use just > that. Actually, the ANSI X9 committee just approved triple DES for the banking community precisely because they tend to agree with me. Using a Weiner and Van Oorschot machine, which you can *build* for under $1million, you can crack DES keys like they were walnuts. Read their paper yourself if you don't believe me. > If (as has been implied over and over again) a $1M machine can be built to > "break" DES, then I would expect that bank profits would be way down by now > (they wouldn't announce it was through electronic theft of course). I suspect that the set of people who both know how to build such machines and know what to do with them is small. That is not to say that the situation is safe, however. > In practice, if we standardized on the Unix random() function and key > management simply passed around the seeds, 99.9% of the net would never know > the difference. They would, because people would keep breaking them. > For those that are truly worried about security, the standard needs > to provide them the ability to slip in better cryptography as they > see fit. Carl; The standard we have already is designed for that. This doesn't mean that we should go for something even worse than DES for our initial cut. Perry From ipsec-request@ans.net Thu Mar 30 07:16:30 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27437 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 12:30:48 -0500 Received: by interlock.ans.net id AA24759 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 12:27:18 -0500 Message-Id: <199503301727.AA24759@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 12:27:18 -0500 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 12:27:18 -0500 To: uri@watson.ibm.com Cc: bound@zk3.dec.com, perry@imsi.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions Date: Thu, 30 Mar 95 12:16:30 EST smb@research.att.com says: > I'm afraid it's a simple matter of arithmetic. > > Let's look at Joe Touch's performance numbers. He got DES speeds > ranging from 20-37 Mbps. To make the arithmetic easy, let's just sa y > 32 Mbps. At 64 bits per block, that's .5 M encryptions/second, or 2 > microseconds per encryption. But Steve, isn't this bulk-rate encryption speed? I.e. key setup is done once, and then you pipe your data in as fast as you can? While during cryptanalysis you must perform a new key setup with every encryption (thus slowing down considerably)? Any numbers on how many key schedule setups per second can one do? I tried accounting for this with my factor of five between the bulk encryption rate and the trial rate, but there's no substitute for real numbers. So -- I tried some tests on ... well, let's call it a stream cipher that I picked up off the net, a cipher that's very fast, but has a relatively slow key setup time. I changed it to use a macro instead of a subroutine to swap bytes. The machine was a SPARCserver 1000 running Solaris 2.4; the compiler was gcc with the -O option specified. Key setup time was 200 microseconds. That's rather higher (well, a factor of 20 higher) than I'd guessed, but I suspect that hand-optimized assembler would do better. For that matter, my driver isn't optimized even at the C level. Even so, at worst we're talking about less than a month to crack this 40-bit cipher. Btw -- if you need incentive to work on this, check out http://www.c3.lanl.gov/~mcn/watcher.html, a pointer to which was widely posted yesterday. I'm not sure I'll dare log in from Danvers if I can't get encryption deployed between now and next week; I'm quite sure I wouldn't dare do it a month from now. From ipsec-request@ans.net Thu Mar 30 17:16:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15406 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 13:22:21 -0500 Received: by interlock.ans.net id AA20498 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 13:17:57 -0500 Message-Id: <199503301817.AA20498@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 30 Mar 1995 13:17:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 30 Mar 1995 13:17:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 13:17:57 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 13:17:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 13:17:57 -0500 Date: 30 Mar 95 11:16:00 -0600 To: ipsec@ans.net Cc: zmuda@spyrus.com, atkinson@itd.nrl.navy.mil, jis@mit.edu, Paul_Lambert-P15452@email.mot.com Subject: IPSEC Working Group Co-Chair I would like to thank Jim Zmuda for his contributions to our working group. Jim's work commitments have recently limited his ability to serve as co-chair and he is giving up this post. Ran Atkinson has been appointed as a new co-chair (with Paul Lambert) of this working group. Ran's many contributions to IPng security should help lead our group towards a consensus providing strong security solutions for the Internet. Thank you, Paul A. Lambert Paul_Lambert@email.mot.com Motorola, Inc. IPSEC Co-Chair From ipsec-request@ans.net Thu Mar 30 17:18:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28223 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 13:27:12 -0500 Received: by interlock.ans.net id AA16824 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 13:22:31 -0500 Message-Id: <199503301822.AA16824@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 30 Mar 1995 13:22:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 30 Mar 1995 13:22:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 13:22:31 -0500 From: Paul_Lambert-P15452@email.mot.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 13:22:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 13:22:31 -0500 Date: 30 Mar 95 11:18:00 -0600 To: ipsec@ans.net Subject: IPSEC Agenda There will be one IP Security (IPSEC) WG Meeting at the Thirty-Second IETF (April 3 - April 7, 1995). It is scheduled as follows: 0900-1130 Thursday, April 6, 1995 - Morning Session SEC IP Security WG - Key Management (ipsec) (Paul Lambert/Motorola and Ran Atkinson/NRL) ----------------------------------------------------------------------- IPSEC Agenda Thirty-Second IETF (April 6, 1995) ------------------- Thursday, April 6, 1995 - Morning Session on IPSP an IKMP 9:00 Introductions o Review and Approve Agenda o Minutes of Previous Meeting (San Jose) 9:05 Review of Charter and Schedule o Comments from the Area Director 9:10 IPSEC Document Status and Work Plan: o draft-ietf-ipsec-arch-00.txt o draft-ietf-ipsec-esp-00.txt o draft-ietf-ipsec-auth-00.txt o draft-ietf-ipsec-esp-des-cbc-03 o draft-ietf-ipsec-ah-md5-02.txt 9:20 Internet Key Management Protocol o Background and Review o IKMP Requirements o Manditory versus Optional Capabilities 9:30 draft-karn-photuris-00.txt Phil Karn (Qualcomm) 10:00 Open Discussion of Photuris 10:15 "Photuris Hybrid" - Hugo Krawczyk 10:25 draft-nsa-isakmp-00.txt Mark Schertler (DoD) 11:00 draft-ietf-ipsec-aziz-skip-01.txt Ashar Aziz (Sun Microsystems, Inc.) 11:10 Summary of IKMP Discussions o Review of Group Decisions and Requirements o Review of Work Plan o Open Issues o Action Items 11:30 Adjourn From ipsec-request@ans.net Thu Mar 30 18:29:51 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20693 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 13:38:57 -0500 Received: by interlock.ans.net id AA24849 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 13:30:02 -0500 Message-Id: <199503301830.AA24849@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 13:30:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 13:30:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 13:30:02 -0500 Date: Thu, 30 Mar 1995 11:29:51 -0700 From: Hilarie Orman To: smb@research.att.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199503301727.AA24759@interlock.ans.net> Subject: Re: IPv6 Security Last Call Initial Questions I think the key setup time can be considerably reduced, down by the factor of 20 that you expect. But these numbers in themselves aren't necessarily disturbing. Having all the world's computers spending all weekend cracking weekday session keys wouldn't really be cause for any individual to worry; we fear drive-by shootings but few of us wear bullet-proof vests. However, there is the prospect of generating a table of encryptions of a known prefix block. Suppose all datagrams began with the same bytes, then one table would suffice to break all datagrams. Now, the datagrams don't begin with common plaintext, but the attack might still be feasible if a single address were targeted, for example. Now, I can well believe that 40 bits is Good Enough for many purposes, but it seems to me that it would be easily strengthened if salt were added to the datagrams. Suppose you choose 16 bits of salt prefix, hash that with 40 bits of key, and select 56 of the hash to be the session key. This could well be acceptable to the majority users. On the other hand, user reaction to the Pentium divide bug might well be a counterexample to the idea that Good Enough would be generally acceptable. Hard to say. From ipsec-request@ans.net Thu Mar 30 09:16:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28370 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 14:35:19 -0500 Received: by interlock.ans.net id AA21768 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 14:31:20 -0500 Message-Id: <199503301931.AA21768@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 14:31:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 14:31:20 -0500 Date: Thu, 30 Mar 95 14:16:44 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: presentation on "Photuris variant" I plan to make a presentation in Danvers on a proposal I sent to this list a few weeks ago in a note with subject line: "A Photuris variant". My proposal essentially provides all the functionality of Photuris plus added features that were present in other proposals to the WG, all within the same message structure of Photuris and same complexity (some of the options in the protocol are actually cheaper). I believe that this approach is worth being considered. For those who do not have my original note anymore, I will be re-sending it in the next message. You can safely erase it if you already have it. The note is quite sketchy but reading it will (hopefully) help understanding the ideas and approach. Hugo From ipsec-request@ans.net Thu Mar 30 09:31:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28385 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 14:37:16 -0500 Received: by interlock.ans.net id AA51395 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 14:33:13 -0500 Message-Id: <199503301933.AA51395@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 14:33:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 14:33:13 -0500 Date: Thu, 30 Mar 95 14:31:50 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: Resending: A Photuris variant This is a long note. However, I encourage anybody interested in key management for IP to read it. (Especially those who are going to comment on it ;-) It presents a variation on Photuris which enjoys, in my opinion, some advantages over the basic Photuris proposal, while keeping the full functionality and basic goals of Photuris. (Familiarity with Photuris, draft-karn-photuris-00.txt, is assumed). Please send comments (no need to send directly to me if you also send them to the list). Phil, needless to say, your comments are a "must". Hugo I start with a brief description and then go into commenting on the design properties and comparison with basic Photuris. A more detailed description of the protocol appears at the end of the note (I am just affraid that by putting it at the beginning it will discourage people from reading it). BRIEF DESCRIPTION: ***************** For consistency with Photuris terminology, I use I and R to denote the parties (initiator and responder). As in Photuris, there are 6 messages exchanged between parties (in implementation, can be collapsed to 5 by piggybacking). They correspond to 3 "phases" (with two messages each phase): Cookies, Share and Diffie-Hellman. The cookies phase is identical to the cookies exchange of Photuris. Then, in the Share phase, the parties exchange a key K0 by each of them sending to the other a half-key (denoted K1 and K2, resp.) each encrypted under the other's party public key. After this phase they share a secret key K0=K1 xor K2. The public key encryption of K1 sent from I to R is used also to encrypt I's identity (thus, providing *anonymity*). In the third phase, the parties perform a Diffie-Hellman exchange, where the DH parts (g^x and g^y) are authenticated using a SYMETRIC message authentication (or integrity check) function using the just exchanged key K0 (keyed-MD5, for example, is such a message authentication function). The output of the DH exchange is denoted K = g^(xy) mod p. The public-key operation (in the Share phase) can be done using any public key cryptosystem. For performance considerations we assume RSA which is the less expensive one (in our comparison with Photuris, we also assume that Photuris does RSA for signatures; again this is not a requirement but it's the most efficient implementation). PROPERTIES OF THE SCHEME: ************************ Security: ******** The scheme accomodates different levels of security and provides for clear trade-offs security/performance. Very importantly, it gives the *option* of two basic security levels: * full perfect forward secrecy provided by DH: an eavesdropper will not learn the exchanged key (K) even if eventually (e.g., much after K is no longer in use) it finds the private keys of both I and R (the only ways to learn the key are to steal the key itself, to actively impersonate one of the parties during the exchange or to break the DH scheme). * partial forward secrecy: if the DH exchange is omitted, then the exchanged key (K0) is secure for as long as at least one of the private keys of the parties is not exposed. (I.e., K0 is immune to the discovery of one party's private key). In both cases: * an adversary willing to impersonate a party during a key exchange must know that party's private key. The above first option is provided by Photuris. The second is not. As for the third property, it exist in Photuris if the signature is performed on-line and with some freshness parameter; it is not provided if the signature is done off-line. Against impersonation the scheme is as secure as Photuris with on-line signatures and has the same performance cost. The relative drawback of our variant is that it does not include an off-line signature option as in plain Photuris. However, the off-line signature allows for replay and/or impersonation based on stolen state information only which in some cases may represent a "security hole" and then not desirable. For constrained machines/applications the partial forward secrecy option that we provide gives a clear trade-off security-performance (it saves two DH exponentiations to each party!). A discussion of scenarios where partial forward secrecy may be acceptable is discussed below. Performance: *********** The overall communication required by the scheme is identical to Photuris, the total computation of the full scheme is also the same (one RSA (long) exponentiation, two DH exponentiations). However, * while Photuris allows for off-line performance of the RSA operation (a signature in Photuris) here this operation (a decryption) is done on-line only (with the resultant added security; see above). * while Photuris requires in any case the performance of the (two) Diffie-Hellman exponentiations, the present variant supports ALSO key exchange without these exponentiations. Note: A detailed performance comparison should also include the cost of RSA exponentiations vs DH exponentiations. The former are significantly cheaper than the later via the Chinese Reminder Theorem; on the other hand, going to short exponents in DH, as proposed by Photuris put the complexities closer to each other (my opinion is that the short exponent, which is a security "shortcut", should not be mandated but exist as an option for the user/implementation both in plain Photuris and the present variant). The default scheme and the options ********************************** Shouldn't the full protocol including Diffie-Hellman be the default option? YES! It gives better security and should be performed whenever possible. On the other hand, a cheaper, still significantly secure OPTION is desirable for whoever wants to use it. Who may want to use partial forward secrecy? We note that PGP, PEM and other systems provide keys that are breakable by compromising ONLY ONE private key, and many people seem to be satisfied with that. The shared K0 is even better than that: it requires the breaking of THE TWO private keys to find the key K0. Following is an example where partial forward secrecy may be acceptable. Assume a pair of nodes that exchange a key for use with IPv4/6 AH only (i.e., authentication but not confidentiality). Do they need Perfect Forward Secrecy? Not strictly, since the key is used only for authentication of information and not for secrecy. Therefore, a future compromise of this key (when no longer in use) is useless for the adversary. That is, the main attractiveness of DH for long term protection of keys used for secrecy is irreleveant here. This is a fundamental difference between secrecy and authentication scenarios (in the former a key may be useful to the adversary even long after the key has expired). (This is not to say that DH has no advantages even in the above authentication scenario. Notice that an adversary that *already* knows I's and R's private keys at the time of exchange can learn K0 by eavesdropping the Share phase. If DH phase is also performed then to learn K the adversary needs to participate actively in that phase). An additional example for use of partial forward secrecy is when encryption is used but with weak (for perfromance or export) algorithms. In that case a long-term protection via DH is useless since the adversary can break the encryption directly from the ciphertext (and some knowledge of the plaintext). In this case, the best defense is to refresh keys as often as possible to increase the adversary's work factor. And then a more efficient key exchange is very valuable. In addition, if one considers its own private keys well protected and/or refreshed frequently (e.g., once a month) then partial forward secrecy may be a reasonable option. Compatibility with other key sharing models ******************************************* Another important advantage of our proposed variant is the way it naturally accomodates different security models. For example, with a Key Distribution Center model a la Kerberos, two parties get a common key from the center. Then they can use our protocol by ignoring the share phase (they'll use as K0 the key provided by the center) and going directly to the DH phase (where K0 is used for authentication only via a (fast) symetric algorithm). Notice that by doing this, a corrupted server (the KDC) will not learn anything which is protected via the shared DH key K (except if it actively impersonates the parties during the DH exchange). This gives Kerberos-based key-sharing AND perfect forward secrecy. Similarly, if two parties got K0 manually installed they can use it in the above mode. Other ways for parties to share keys are conceivable. In the SKIP proposal parties share keys via public DH parts. The use of that technique can be combined with our protocol by letting this shared key be K0, and then proceed with our protocol without the share phase (and still get perfect forward secrecy). And so on, and so on. The signature-less property *************************** The proposed variant does not use digital signatures. We claim this as an advantage. Digital signatures provide non-repudiation; a great property when needed and a bad one when forced. For example, it can be used to prove (by your interlocutor or third party) that you have been communicating with somebody. Indeed, if for authentication purposes you sign a string containing the identity of the party you are communicating with (this may have good security reasons, e.g., against replay, etc.) , this information can be later used to prove you talked to that party. In a sense this is a worst privacy violation than not preserving anonymity. Anonymity is usually protected against an eavesdropper in the network, but this eavesdropper cannot necesarily prove that you talked to somebody. Using your signature he can. Protocols that use signature can (and should) be designed carefully not to force a user to provide non-repudable information. However, this is one of the aspects that can be easily overlooked in a design (or modifications to it in the future). It is also a delicate issue to deal with, e.g., if you sign (among other things) a nonce sent by the other party, that nonce could have been produced as the hash of the identity of that person, etc. Another problem of signatures, related to anonymity, is that if you want to protect anonymity you must encrypt the signatures. Otherwise, by simple signature verification (using your public key) your identity can be tested. The bottom line is: if we can do it w/o digital signature then better. We can. Transparent design for (improved) Anonymity ******************************************* Photuris has introduced the requirement of keeping anonymity of the parties (e.g., for mobile users). Photuris achieves that property but at a certain cost. First it requires the delay of signatures (for DH authentication) until after the completion of the DH exchange. Second it requires the encryption of these signatures using the exchanged DH key. Even if the later does not have a big computational cost, the addition of a symetric encryption algorithm to the key exchange phase is otherwise unnecesary. Our solution provides for the anonymity requirement as in Photuris, but achieves it in a completely transparent way. It only requires the inclusion of the initiator's identity inside the encryption message where the half-key K1 is sent. In cases where anonymity is not required then this identity is just omitted from the encryption parameters. Moreover, this solution improves anonymity since it protects it even against an active attacker. Photuris only protects it against eavesdroppers. (Photuris relies on a non-authenticated DH exchange for anonymity). A DETAILED DESCRIPTION ********************** Here I present a more detiled description of this variant. It is not a complete one (e.g., it does not specify the exact way information is to structured before applying a PK encryption operation). These details are left for future description. The flows (or messages) of the protocol are as follows. For consistency with Photuris terminology, I use I and R to denote the parties (initiator and responder). As in Photuris, there are 6 messages exchanged between parties (in implementation, can be collapsed to 5 by peggy-backing). They correspond to 3 "phases" (with two messages each phase): Cookies, Share and Diffie-Hellman. I denote them C1, C2, S1, S2, DH1, DH2. 1) Cookies ******* C1 and C2 are EXACTLY Photuris cookies exchange (against clogging). 2) Share ***** S1 and S2 are intended to exchange a key K0 between I and R (before Diffie-Hellman). It goes: S1 (I --> R) : cookies, ENC_R(Id(I), K1) where: * cookies: are I's and R's cookies as exchanged in C1 and C2 (same as in Photuris) * ENC_R(...) denotes encryption under R's public key of the information inside the parentheses. * Id(I) denotes the identity of I (hidden in the encryption for anonymity). * K1 is a random key chosen by I (its length and purpose will be discussed below). S2 (R --> I) : cookies, ENC_I(K2) where: * cookies: are I's and R's cookies as exchanged in C1 and C2 (same as in Photuris) * ENC_I(...) denotes encryption under I's public key of the information inside the parentheses. * K2 is a random key chosen by R (its length and purpose will be discussed below). (see below for details on the way parameters to the encryption function are encoded before encryption). The parties, I and R, set K0=K1 XOR K2. (Other combinations of K1, K2 into K0 are possible, e.g. K0=MD5(K1,K2), these details are omitted here). 3) Diffie-Hellman ************** DH1, DH2 are Diffie-Hellman exchanges: correspond to DH_REQUEST and DH_RESPONSE in Photuris DH1 (I --> R) : cookies, g^x , MAC_K0(g^x) where: * g^x is the DH part sent by I (i.e., g^x mod p; the values of g and p may also be sent as part of the message if the values are not fixed or known in advance). * MAC_K0 means a message authentication code (or integrity check function) using the key K0 and applied to the information sent in the message. MAC_K0 can be keyed-MD5 (with K0 as the key), DES CBC-MAC, etc. DH2 (R --> I) : cookies, g^y , MAC_K0(g^y) where: * g^y is the DH part sent by R (i.e., g^y mod p; the values of g and p may also be sent as part of the message if the values are not fixed or known in advance). * MAC_K0 means a message authentication code (or integrity check function) using the key K0 and applied to the information sent in the message. MAC_K0 can be keyed-MD5 (with K0 as the key), DES CBC-MAC, etc. The parties now share a Diffie-Hellman key: K = g^(xy) (mod p) The details of g,p and computation of x, y and exponentiations are all the same as in Photuris. Also, the use of timers for retransmission, erasure of old pairs (x,g^x) and so on are the same as in Photuris. A more compact implementation of the protocol that merges the Share and DH phases is as follows. It has the advantage of one less message and allows carrying out the computation of g^(xy) while waiting for the other party's response. (Cookies are omitted). I-->R: g^x, ENC_R(Id(I), K1) R-->I: g^y, ENC_R(K2), MAC_K0(g^y) I-->R: MAC_K0(g^x) From ipsec-request@ans.net Thu Mar 30 19:56:17 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26658 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 15:06:43 -0500 Received: by interlock.ans.net id AA37734 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 14:56:23 -0500 Message-Id: <199503301956.AA37734@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 14:56:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 14:56:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 14:56:23 -0500 Date: Thu, 30 Mar 1995 12:56:17 -0700 From: Hilarie Orman To: ipsec@ans.net Subject: fast hash Since there's some interest, I'd like to contribute the following code for comment. It was an exercise I set myself after timing MD5 on a 64-bit architecture and playing around with optimizing the byte loading. First I modified the algorithm to use ALU operations on 64-bits at a time, so the constants became 64 bits long, etc. Then, I began removing computation from the MD5Transform a little at a time, trying to get it to run fast. Most of it disappeared. Then I tried adding in more operations, looking for ways to mix the data in quickly. The result is something that is only vaguely related to the original algorithm. It runs at 400 Mbps on a 175 MHz DEC Alpha if the byte order is not important. Half that speed if the bytes must be rearranged (code for this is not provided in this note). I've got no idea how well this resists cryptanalysis, and I realize that answering that question is probably much harder than coming up with the algorithm. It has the basic property of each output bit being statistically sensitive to each input bit. I present it in the hope that it might provoke some discussion about design or analysis methods for a class of algorithms that aspire to sit on the very brink of insecurity in exchange for acceptable speed. =======================C Code below this line============================ typedef unsigned long int UINT8; /* Constants for HKOTransform routine. */ #define S11 7 #define S12 12 #define S13 17 #define S14 22 #define S21 5 #define S22 9 #define S23 14 #define S24 20 #define S31 4 #define S32 11 #define S33 16 #define S34 23 #define S41 6 #define S42 10 #define S43 15 #define S44 21 #define U11 29 #define U12 41 #define U13 39 #define U14 61 #define U21 14 #define U22 23 #define U23 34 #define U24 54 #define U31 15 #define U32 26 #define U33 39 #define U34 62 #define U41 16 #define U42 26 #define U43 36 #define U44 57 /* ROTATE_LEFT rotates x left n bits. */ #define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (64-(n)))) /* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4. Rotation is separate from addition to prevent recomputation. */ #define FF(a, y, z1, z2, z3, z4, b, c, d, x, s, t, u, ac) { \ (a) ^= y; \ (a) += F ((b), (c), (d)) + ROTATE_LEFT(x, u) + (UINT8)(ac); \ (a) = ROTATE_LEFT ((a), (s)) + (b); \ (d) += (b) ^ (~(z1)) + ~(ROTATE_LEFT ((a), (t))); \ tmp = (a) ^ (x); \ (c) -= (d) ^ (~(z2)) ^ ~((z4) + (ROTATE_LEFT (tmp, (t+11)))); \ tmp = (a) ^ (d); \ (b) ^= (c) + (~(z3)) + ~(ROTATE_LEFT (tmp, (t+23))); \ } #define GG(a, y, z1, z2, z3, z4, b, c, d, x, s, t, u, ac) { \ (a) ^= y; \ (a) += G ((b), (c), (d)) + ROTATE_LEFT(x, u) + (UINT8)(ac); \ (a) = ROTATE_LEFT ((a), (s)) + (b); \ (d) ^= (b) + ((z1) ^ ((z4) + ~(ROTATE_LEFT ((a), (t))))); \ tmp = (a) ^ (x); \ (c) += (d) ^ (z2) ^ ~(ROTATE_LEFT (tmp, (t+11))); \ tmp = (a) ^ (d); \ (b) -= (c) ^ (z3) ^ ~(ROTATE_LEFT (tmp, (t+23))); \ } #define HH(a, y, z1, z2, z3, z4, b, c, d, x, s, t, u, ac) { \ (a) ^= y; \ (a) += H ((b), (c), (d)) + ROTATE_LEFT(x, u) + (UINT8)(ac); \ (a) = ROTATE_LEFT ((a), (s)) + (b); \ (d) -= (b) ^ ((~(z1)) + ((z4) ^ ~(ROTATE_LEFT ((a), (t))))); \ tmp = (a) ^ (x); \ (c) ^= (d) + (~(z2)) + ~(ROTATE_LEFT (tmp, (t+11))); \ tmp = (a) ^ (d); \ (b) += (c) ^ (~(z3)) ^ ~(ROTATE_LEFT (tmp, (t+23))); \ } #define II(a, y, z1, z2, z3, z4, b, c, d, x, s, t, u, ac) { \ (a) ^= y; \ (a) += I ((b), (c), (d)) + ROTATE_LEFT(x, u) + (UINT8)(ac); \ (a) = ROTATE_LEFT ((a), (s)) + (b); \ (d) ^= (~b) + (z1) + ((z4) ^ ~(ROTATE_LEFT ((a), (t)))); \ tmp = (a) ^ (x); \ (c) += (~d) ^ (z2) ^ ~(ROTATE_LEFT (tmp, (t+11))); \ tmp = (a) ^ (d); \ (b) -= (~c) ^ (z3) ^ ~(ROTATE_LEFT (tmp, (t+23))); \ } static void HKOTransform (state, block) UINT4 state[4]; unsigned char block[64]; { register UINT8 x01, x23, x45, x67, x89, x1011, x1213, x1415; register UINT8 a = state[0], b = state[1], c = state[2], d = state[3]; register UINT8 tmp; x01 = *(UINT8 *) ( &block[0] ); x23 = *(UINT8 *) (&block[8]); x45 = *(UINT8 *) (&block[16]); x67 = *(UINT8 *) (&block[24]); x89 = *(UINT8 *) (&block[32]); x1011 = *(UINT8 *) (&block[40]); x1213 = *(UINT8 *) (&block[48]); x1415 = *(UINT8 *) (&block[56]); /* Round 1 */ FF (a, x89, x23, x67, x45, x1011, b, c, d, x01, S11, S12, U11, 0xd76aa478e8c7b756UL); /* 1 */ /* Round 2 */ GG (b, x45, x01, x23, x1415, x89, c, d, a, x1213, S21, S22, U21, 0xd62f105d2441453UL); /* 21 */ /* Round 3 */ HH (c, x1011, x67, x1415, x1213, x01, d, a, b, x23, S33, S34, U32, 0x6d9d6122fde5380cUL); /* 35 */ /* Round 4 */ II (d, x67, x45, x89, x1011, x67, a, b, c, x1415, S43, S44, U42, 0xffeff47d85845dd1UL); /* 55 */ state[0] += (a ^ (b>>32)); state[1] += (b ^ (c>>32)); state[2] += (c ^ (d>>32)); state[3] += (d ^ (a>>32)); } From ipsec-request@ans.net Thu Mar 30 10:09:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12617 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 15:12:46 -0500 Received: by interlock.ans.net id AA35108 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 15:09:46 -0500 Message-Id: <199503302009.AA35108@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 15:09:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 15:09:46 -0500 Date: Thu, 30 Mar 95 15:09:34 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) To: ipng@sunroof2.eng.sun.com, ipsec@ans.net Subject: new Photuris draft available for ftp Folks, I've put Phil Karn's most recent Photuris key mgmt protocol draft out for anonymous ftp from ftp.nrl.navy.mil in pub/security/draft-karn-*.txt; I did so at his and Bill's request. This draft was too late to make the pre-Danvers I-D submission deadline, but it seemed useful to make it widely available prior to next week's IPsec meeting where it will be discussed. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Mar 30 20:13:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12640 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 15:15:32 -0500 Received: by interlock.ans.net id AA57186 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 15:13:21 -0500 Message-Id: <199503302013.AA57186@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 15:13:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 15:13:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 15:13:21 -0500 Date: Thu, 30 Mar 1995 13:13:13 -0700 From: Hilarie Orman To: ipsec@ans.net Subject: IV is salt In my note about 40 bit ciphers, I forgot that the IV performs the function of salt; Steve Bellovin pointed this out to me, and I'm sure it was evident to everyone else. That being a solved problem, then I'd simply like note that a fast 40 bit cipher might be acceptable for many purposes. I'd never use it, of course, and you wouldn't, but maybe your brother-in-law would. From ipsec-request@ans.net Thu Mar 30 20:24:00 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28335 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 15:22:31 -0500 Received: by interlock.ans.net id AA20586 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 15:19:32 -0500 Message-Id: <199503302019.AA20586@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 30 Mar 1995 15:19:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 15:19:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 15:19:32 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 15:19:32 -0500 From: "Marcus J. Ranum" Subject: Re: IPv6 Security Last Call Initial Questions To: ho@cs.arizona.edu (Hilarie Orman) Date: Thu, 30 Mar 1995 15:24:00 -0500 (EST) Cc: smb@research.att.com, ipsec@ans.net In-Reply-To: <199503301830.AA24849@interlock.ans.net> from "Hilarie Orman" at Mar 30, 95 11:29:51 am Organization: Trusted Information Systems, Inc. Glenwood, MD Phone: 301-854-6889 Coredump: Infocalypse Now!!! Content-Type: text Content-Length: 1624 >Now, I can well believe that 40 bits is Good Enough for many purposes, >but it seems to me that it would be easily strengthened if salt were added >to the datagrams. If you strengthen it to beyond "slightly better than ROT13" strength, rest assured it will not pass muster for export control. I'm also not convinced that export permission will be granted for IP encryption *EVEN* if the cryptosystem is a toy. Widely deployed toy crypto is still a pain to sort through. The current export control regs have had a terrific cooling effect on *any* commercial deployment of crypto, as they were intended to -- it was the threat of *widespread* deployment of crypto that brought us the wiretapping bill and Clipper. In other words, don't assume that just because IBM thinks they can get their toy crypto exported [One of our guys here points out that he believes that is not a "done deal" yet] for their purposes, it may not equate to a blanket permission amounting to "here, go ahead and encrypt all your IP packets." Export control is the catch-22. If the decision is to standardize on toy crypto to meet export control regs, then you can rest assured that all this effort (and Email) will be wasted, since nobody will deploy it who needs it, and if it's widely deployed and the intelligence community/law enforcement realize that a lot of toy crypto is still tough to deal with, they'll pull the plug. Vendors who settle for low-quality crypto in an attempt to be able to bring stuff to market are being short-sighted in following the percieved path of least resistance. There *IS* no path of least resistance. mjr. From ipsec-request@ans.net Thu Mar 30 20:42:14 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20692 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 15:57:38 -0500 Received: by interlock.ans.net id AA17224 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 15:52:04 -0500 Message-Id: <199503302052.AA17224@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 15:52:04 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 15:52:04 -0500 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 "Thu, 30 Mar 1995 15:09:34 EST." <9503302009.AA28086@itd.nrl.navy.mil> Date: Fri, 31 Mar 1995 06:42:14 +1000 From: Robert Elz Date: Thu, 30 Mar 95 15:09:34 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-ID: <9503302009.AA28086@itd.nrl.navy.mil> This draft was too late to make the pre-Danvers I-D submission deadline, but it seemed useful to make it widely available prior to next week's IPsec meeting where it will be discussed. I have no interest in this particular draft, so I'm going to comment on it rather than others that are in a similar position. There's a reason there's a deadline for drafts, and its not only because the secretariat have better things to do in the week before the IETF. Its that there needs to be time before the IETF's for people to obtain and digest the draft before the IETF meeting. Even a week before is tight (lots of people are at interop this week I gather). I know that no I'm at home, I leave for the airport in a couple of hours, and I'm not going anywhere near a printer in the meantime. If I wanted to fetch that draft and understand it before the IETF I'd have no chance, which would mean any attempt to work out what is going on would have to depend on what I picked up at the meeting itself, which is absolutely not the way things are supposed to work. 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. kre From ipsec-request@ans.net Thu Mar 30 20:53:26 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16645 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 15:58:19 -0500 Received: by interlock.ans.net id AA29105 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 15:53:24 -0500 Message-Id: <199503302053.AA29105@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 15:53:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 15:53:24 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Mar 1995 12:53:26 -0800 To: ipsec@ans.net From: jis@mit.edu (Jeffrey I. Schiller) Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) There has been some discussion (I apologize if I missed some of it, I am traveling and having trouble keeping up with all of my e-mail) about the per-user keying mandate. Specifically the justification given in the drafts is pretty weak. However there are important reaons for supporting it. I sent the following paragraph to Ran for consideration as an alternative justification: "IPv6 Security is intended to be able to provide Authentication, Integrity and Confidentiality for application programs operating on connected end-systems. Integrity and confidentiality can be provided by the proper use of per-host keys. However authentication of principals using applications on end-systems requires that processes running such applications have the necessary facilities to set up their own Security Parameters Indices. In this fashion applications can make use of key distribution facilities which provide authentication." What do people think? -Jeff From ipsec-request@ans.net Thu Mar 30 21:11:43 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22034 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 16:17:44 -0500 Received: by interlock.ans.net id AA05246 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 16:12:46 -0500 Message-Id: <199503302112.AA05246@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 16:12:46 -0500 From: Ran Atkinson Date: Thu, 30 Mar 1995 16:11:43 -0500 In-Reply-To: jis@mit.edu (Jeffrey I. Schiller) "Re: IPv6 Security Last Call Initial Questions (per user keying)" (Mar 30, 12:53) References: <199503302053.AA29105@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Cc: jis@mit.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil I will happily take Jeff's proposed text into the draft. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Thu Mar 30 22:37:44 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA25088 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 17:37:57 -0500 Received: by interlock.ans.net id AA49089 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 17:34:49 -0500 Message-Id: <199503302234.AA49089@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 17:34:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 17:34:49 -0500 X-Sender: hughes@129.191.63.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Mar 1995 16:37:44 -0600 To: ipng@sunroof2.eng.sun.com, ipsec@ans.net From: hughes@hughes.network.com (James P Hughes) Subject: New Photuris draft available for ftp Phil Karn's most recent Photuris key mgmt protocol draft is also available for anonymous ftp from ftp.network.com in ftp://ftp.network.com/IETF/IPSEC/draft-karn-photuris-01.txt This is in addition to the nrl copy. Jim ---------------------- James P Hughes Key fingerprint = 68 E7 D5 75 3C 88 86 71 D4 34 36 C3 8E DD 48 17 From ipsec-request@ans.net Fri Mar 31 00:48:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14836 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 20:02:18 -0500 Received: by interlock.ans.net id AA10936 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 19:49:30 -0500 Message-Id: <199503310049.AA10936@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Thu, 30 Mar 1995 19:49:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 30 Mar 1995 19:49:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 19:49:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 19:49:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 19:49:30 -0500 Date: Thu, 30 Mar 1995 16:48:09 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipsec@ans.net, jis@mit.edu Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Cc: sun-ipng-project@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Jeff, If the text : > > "IPv6 Security is intended to be able to provide Authentication, > Integrity and Confidentiality for application programs operating on > connected end-systems. Integrity and confidentiality can be > provided by the proper use of per-host keys. However authentication of > principals using applications on end-systems requires that processes > running such applications have the necessary facilities to set up their > own Security Parameters Indices. In this fashion applications can make > use of key distribution facilities which provide authentication." > means that an IPv6 implementation must accept an SPI from an application and use it, then I think there might be some problems. For example, o If the security context associated with a particular SPI is retrieved from somewhere other than the requesting process, how would the IP implementation know the application has the right to use it? o If the security context is accepted from the process along with the SPI, how is this going to affect the programming interface? For example, how will the security context state be passed in a way that leaves existing interfaces reasonably unaffected (e.g., will new ioctl calls to specify the integrity and confidentiality algorithms, the keying information, and other security mechanism specific data be required? Will there be new informational ioctl calls to find out which algorithms the IP implementation supports?)? IPv6 was agreed on after there was some implementation experience on which to base the decision. As far as I can tell, there is no implementation experience on which to base the decision for or against a mandatory requirement for supporting application supplied SPIs. So I still argue against making this a mandatory requirement. There seems to be enough people interested in user-oriented keying that if it is recommended that implementations support it, some will. From this we can determine whether it is useful or not and whether it is implementable in a reasonable way. If so, it can be made mandatory in the draft standard. Dan From ipsec-request@ans.net Fri Mar 31 01:52:09 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04232 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 20:59:02 -0500 Received: by interlock.ans.net id AA42859 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 20:52:22 -0500 Message-Id: <199503310152.AA42859@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 20:52:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 20:52:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 20:52:22 -0500 Date: Thu, 30 Mar 1995 18:52:09 -0700 From: Hilarie Orman To: smb@research.att.com Cc: ipsec@ans.net, bound@zk3.dec.com In-Reply-To: Yourmessage <199503301727.AA24759@interlock.ans.net> Subject: Re: IPv6 Security Last Call Initial Questions > From: smb@research.att.com > Cc: bound@zk3.dec.com, perry@imsi.com, ipsec@ans.net > Date: Thu, 30 Mar 95 12:16:30 EST > smb@research.att.com says: > > I'm afraid it's a simple matter of arithmetic. > > > > Let's look at Joe Touch's performance numbers. He got DES speeds > > ranging from 20-37 Mbps. To make the arithmetic easy, let's just say > > 32 Mbps. At 64 bits per block, that's .5 M encryptions/second, or 2 > > microseconds per encryption. Please note that these numbers were later corrected to 5.7-9.5 Mbps. From ipsec-request@ans.net Fri Mar 31 01:52:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04241 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 20:59:30 -0500 Received: by interlock.ans.net id AA32886 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 20:52:34 -0500 Message-Id: <199503310152.AA32886@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 30 Mar 1995 20:52:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 20:52:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 20:52:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 20:52:34 -0500 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipsec@ans.net, jis@mit.edu, sun-ipng-project@sunroof.eng.sun.com Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) In-Reply-To: Your message of "Thu, 30 Mar 1995 16:48:09 PST." <199503310049.AA10936@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 30 Mar 1995 20:52:02 -0500 From: "Perry E. Metzger" Dan Nessett says: > means that an IPv6 implementation must accept an SPI from an application > and use it, then I think there might be some problems. For example, > > o If the security context associated with a particular SPI is retrieved > from somewhere other than the requesting process, how would the > IP implementation know the application has the right to use it? Very easily. My implementation for 4.4BSD has a design to handle this very nicely. Security Association related information is stored in the kernel in SA structures, which are pointed to by the socket structures. The processes have very limited ability to alter the associations on their own, but they can be passed the associations using the same mechanisms BSD uses to pass file descriptors around. Its all very clean, if I do say so myself. > o If the security context is accepted from the process along with > the SPI, how is this going to affect the programming interface? For > example, how will the security context state be passed in a way that > leaves existing interfaces reasonably unaffected (e.g., will new > ioctl calls to specify the integrity and confidentiality algorithms, > the keying information, and other security mechanism specific data > be required? Will there be new informational ioctl calls to find > out which algorithms the IP implementation supports?)? Well, new calls (not ioctls) are indeed needed. You call this a problem. This is hardly a problem. Old programs need not pay attention, and new ones can if they like. > IPv6 was agreed on after there was some implementation experience on > which to base the decision. As far as I can tell, there is no > implementation experience on which to base the decision for or > against a mandatory requirement for supporting application supplied > SPIs. You are mistaken. I am developing the experience (so far no problems have arisen), and I believe Ran is developing experience. > So I still argue against making this a mandatory requirement. If I might sound like a broken record, it would appear that you are really against this because SKIP can't support it. From ipsec-request@ans.net Thu Mar 30 16:14:47 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20527 (5.65c/IDA-1.4.4 for ); Thu, 30 Mar 1995 21:21:16 -0500 Received: by interlock.ans.net id AA10517 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Mar 1995 21:14:57 -0500 Message-Id: <199503310214.AA10517@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Mar 1995 21:14:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Mar 1995 21:14:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Mar 1995 21:14:57 -0500 Date: Thu, 30 Mar 1995 21:14:47 +0500 From: Theodore Ts'o To: Danny.Nessett@eng.sun.com Cc: ipsec@ans.net, jis@MIT.EDU, sun-ipng-project@sunroof.eng.sun.com In-Reply-To: Dan Nessett's message of Thu, 30 Mar 1995 16:48:09 -0800, <199503310049.AA10936@interlock.ans.net> Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1124 Date: Thu, 30 Mar 1995 16:48:09 -0800 From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) means that an IPv6 implementation must accept an SPI from an application and use it, then I think there might be some problems. For example, o If the security context associated with a particular SPI is retrieved from somewhere other than the requesting process, how would the IP implementation know the application has the right to use it? Presumably the SPI will include the necessary keying material for the security context. If the application doesn't have the right to use it, then it shouldn't have it. If the application does have access to keying material which it shouldn't have a right to, then you've got bigger problems..... I believe what's driving this as a requirement is that some applications may want to exchange keying information on a user-specific level, using some GSSAPI mechanism (including perhaps Kerberos), and that there be a way to set the keys derived from authentication done at a user-specific granularity to be used by the IPsec encryption encapsulation. - Ted From ipsec-request@ans.net Fri Mar 31 05:09:15 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26923 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 00:12:51 -0500 Received: by interlock.ans.net id AA24891 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 00:09:19 -0500 Message-Id: <199503310509.AA24891@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 00:09:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 00:09:19 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 00:09:19 -0500 Date: Thu, 30 Mar 1995 22:09:15 -0700 From: Hilarie Orman To: ipsec@ans.net Subject: Some timings Here are some timings on various routines, machines, compilers. All tests unless otherwise noted were run with 10000 byte block inputs, 10000 times. Varying the block size upward caused no timing changes. The machines were all running one flavor or another of Unix. The sparc10 is a sparc 20/612, the mips is a decstation 3000/200, the alpha is a 3000/600 175 Hz machine. MD5 ======================= 486 66MHz gcc -O2 1.37 Mbyte/sec sparc ipc gcc2 -O2 .99 Mbyte/sec mips 25MHz gcc -O 1.31 Mbyte/sec hp 735 5.26 Mbyte/sec sparc10 gcc2 -O2 5.88 Mbyte/sec dec alpha 600 cc -O2 7.8 Mbyte/sec MD4 ======================= dec alpha 600 cc -O 6.25 Mbyte/sec SHA ======================= 486 66MHz gcc -O4 1.16 Mbyte/sec sparc10 gcc2 -O2 3.1 Mbyte/sec dec alpha 600 gcc2 -O2 5.0 Mbyte/sec HAVAL ======================= 486 66MHz gcc -O .42 MByte/sec sparc ipc gcc2 -O2 .60 MByte/sec mips 25MHz R3000 gcc -O .74 MByte/sec sparc10 cc -O2 3.17 MByte/sec dec alpha gcc -O2 2.33 MByte/sec* *wrong answer; source code not converted to 64-bit ints. DES ("random" data) ======================= 486 66MHz gcc -O2 .43 Mbyte/sec sparc ipc gcc2 -O2 .31 Mbyte/sec mips 25MHz .25 Mbyte/sec sparc10 gcc2 -O2 1.04 Mbyte/sec dec alpha 600 gcc2 -O2 1.87 Mbyte/sec DES keysetup only ======================= 486 66MHz gcc -O2 115 usec/key sparc10 cc -O2 40 usec/key dec alpha 600 gcc2 -O2 23 used/key RSA (512 bit modulus), GNU MP package, nothing fancy 63 byte input chunk ======================= 66MHz 486 95 bytes/sec sparcIPC 84 bytes/sec sparc10 350 bytes/sec DEC alpha 600 1250 bytes/sec In the following two timings, the two Diffie-Hellman methods offer the same resistance to a discrete log attack, but one uses smaller numbers. The elliptic curve method has an optimization that is applicable to the mod p method and yields a speedup by a factor of 2.5. DH key exchange (512 bit, mod p) ======================= Total = 2*Offer + Reply: Sparc IPC (25MHz) 2670 msec Dec Alpha 600 (175 MHz) 185 msec DH key exchange (155 bit, elliptic curve, GF[2^155] (with table of powers of g) ======================= Total = 2*Offer + Reply: sparc ipc 136.9 msec dec alpha 11.62 msec Phil Karn points out that the mod p case can be considerably faster if we use 128 exponents. Applying that optimization, and the optimization of the table of powers of g, we estimate DH key exchange (512 bit, mod p) (128 bits of exponent, table of powers of g) ======================= Total = 2*Offer + Reply: Sparc IPC (25MHz) 380 msec estimated Dec Alpha 600 (175 MHz) 26.2 msec estimated The elliptic curve method would speed up slightly with 128 bit exponents DH key exchange (elliptic curve, GF[2^155] (128 bits of exponent, table of powers of g) ======================= Total = 2*Offer + Reply: Sparc IPC (25MHz) 114 msec estimated Dec Alpha 600 (175 MHz) 21.8 msec estimated From ipsec-request@ans.net Fri Mar 31 13:08:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04261 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 08:23:39 -0500 Received: by interlock.ans.net id AA30343 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 08:13:34 -0500 Message-Id: <199503311313.AA30343@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 08:13:34 -0500 From: Ran Atkinson Date: Fri, 31 Mar 1995 08:08:32 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: IPv6 Security Last Call Initial Questions (per user keying)" (Mar 30, 16:48) References: <199503310049.AA10936@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Dan, Your assertion that "there is no implementation experience on which to base the decision" for user-oriented keying is false. THere is implementation experience with this. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Mar 31 13:43:13 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26968 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 08:57:37 -0500 Received: by interlock.ans.net id AA50211 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 08:53:36 -0500 Message-Id: <199503311353.AA50211@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 08:53:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 08:53:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 08:53:36 -0500 To: perry@imsi.com Cc: bound@zk3.dec.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Thu, 30 Mar 95 10:27:20 EST." <9503301527.AA17368@snark.imsi.com> Date: Fri, 31 Mar 95 08:43:13 -0500 From: bound@zk3.dec.com X-Mts: smtp Perry; >I believe J.I. is monitoring this mailing list, so I'll let him speak >for himself, but he figured out for me last year when he was playing >with RC4 that 40 bit RC4 could be broken with the resources he had >available at the CS department at Columbia in a few days. If you like, >I'll try to make sure that he posts figures. I am convinced. >I'll point out that I consider anything that can be broken for under >$1,000,000 to be completely unacceptable given my interests in the >banking community, and DES already is dangerously weak in that regard >-- I'd almost prefer standardizing on 3DES. 40 bits by my measure is a complete joke. > I agree and $1 million would do it too. Having done a stinch as contractor for Banks in the early 80's and worked on CIRUS (very early CIRUS) and ATMs (the teller machines), where are the banks going to use ESP for the Internet? )---> thanks (ah a requirement I love them). And what are they doing now without ESP IPSP? So even though I don't want ESP DES MUST I think as an individual I would like a weak algorithm that can be broken less. thanks /jim From ipsec-request@ans.net Fri Mar 31 14:14:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12815 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 09:20:54 -0500 Received: by interlock.ans.net id AA10696 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 09:18:20 -0500 Message-Id: <199503311418.AA10696@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 09:18:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 09:18:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 09:18:20 -0500 To: atkinson@itd.nrl.navy.mil Cc: ipsec@ans.net, jis@mit.edu Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) In-Reply-To: Your message of "Thu, 30 Mar 95 16:11:43 EST." <199503302112.AA05246@interlock.ans.net> Date: Fri, 31 Mar 95 09:14:32 -0500 From: bound@zk3.dec.com X-Mts: smtp Ran, per Jeff's user-oriented keying wording: Could you wait until after the IETF IPSEC meeting. We need more than one day to think about statements in such an important draft as IPSP. In addition we should be talking about drafts that made the IETF deadline of March 24th. Per Robert Elz recent note on deadlines for the IETF I agree completly. If you care enough you will make the deadlines. NO special cases. thanks /jim From ipsec-request@ans.net Fri Mar 31 14:42:59 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21019 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 09:54:59 -0500 Received: by interlock.ans.net id AA05099 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 09:49:21 -0500 Message-Id: <199503311449.AA05099@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 09:49:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 09:49:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 09:49:21 -0500 To: ipsec@ans.net, jis@mit.edu Subject: MIssing the IETF Deadline of March 24th for IDs Date: Fri, 31 Mar 95 09:42:59 -0500 From: bound@zk3.dec.com X-Mts: smtp This reminds me of a saying: Poor planning on your part does not constitute an emergency on mine. /jim From ipsec-request@ans.net Fri Mar 31 14:51:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28209 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 09:56:32 -0500 Received: by interlock.ans.net id AA42921 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 09:53:55 -0500 Message-Id: <199503311453.AA42921@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 09:53:55 -0500 From: Ran Atkinson Date: Fri, 31 Mar 1995 09:51:36 -0500 In-Reply-To: bound@zk3.dec.com "Re: IPv6 Security Last Call Initial Questions (per user keying)" (Mar 31, 9:14) References: <9503311414.AA23435@xirtlu.zk3.dec.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: bound@zk3.dec.com, atkinson@itd.nrl.navy.mil Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Cc: ipsec@ans.net, jis@mit.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil Jim, Jeff's proposed re-wording is an "editorial" change, not a "technical" one and so is a permitted change. It is NOT any kind of special case to make editorial changes as part of the Last Call process -- in fact, such changes are routine during Last Call. I have no plans to release revised drafts in the near future in any event. Perhaps I am misunderstanding your concern, but I hope the above information ameliorates matters. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Mar 31 15:15:36 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14656 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 10:25:47 -0500 Received: by interlock.ans.net id AA34998 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 10:22:03 -0500 Message-Id: <199503311522.AA34998@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 10:22:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 10:22:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 10:22:03 -0500 To: atkinson@itd.nrl.navy.mil Cc: bound@zk3.dec.com, 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 09:51:36 EST." <9503310951.ZM12708@bodhi> Date: Fri, 31 Mar 95 10:15:36 -0500 From: bound@zk3.dec.com X-Mts: smtp Ran, I agree its editorial. But all words in a standard are important. I realize this is proposed and I am being to nit picky so I will lighten up on that in the future. My special case statement was not for Jeffs change, but rather adding words or text to drafts that were due March 24th for the WG members to review. The bottom line is this. The way I read the IETF Mar 24th deadline (for all WGs) is that I as WG member read and prepare for the meeting with the drafts that made the deadline I have done my job to prepare. New material should be done at Danvers not on the mail list Friday before an IETF meeing. So my "no special cases" did not apply to the editorial change but rather adding to our already full security basket of work in the 11th hour. Is this clear now.. sorry if it came across to just your work which was submitted on time I might add and I appreciate too. Because Jeff is out of town is too bad thats the way it goes. Its not my problem as a WG member and that also means no special cases evern for IESG or Area Directors. They are not bosses just leaders. /jim From ipsec-request@ans.net Fri Mar 31 16:02:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21206 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 11:08:29 -0500 Received: by interlock.ans.net id AA41821 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 11:03:24 -0500 Message-Id: <199503311603.AA41821@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 31 Mar 1995 11:03:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 31 Mar 1995 11:03:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 11:03:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 11:03:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 11:03:24 -0500 Date: Fri, 31 Mar 1995 08:02:03 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: perry@imsi.com Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Cc: ipsec@ans.net, jis@mit.edu X-Sun-Charset: US-ASCII Perry, I'm going to break a rule I have set for myself against responding to ad hominem arguments, in particular : > If I might sound like a broken record, it would appear that you are > really against this because SKIP can't support it. in order to clarify a point you keep raising. Specifically, I am not working on SKIP. That is being developed in another part of the company. Ashar Aziz and I talk on occasion, but it is on the level of a professional exchange of ideas, rather than a working collaboration. As a matter of fact, my manager has specifically told me *not* to work on SKIP. I hope this will help focus the debate on substantive issues. Dan From ipsec-request@ans.net Fri Mar 31 16:21:32 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27011 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 11:28:30 -0500 Received: by interlock.ans.net id AA57190 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 11:25:14 -0500 Message-Id: <199503311625.AA57190@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 31 Mar 1995 11:25:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 11:25:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 11:25:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 11:25:14 -0500 To: bound@zk3.dec.com Cc: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Fri, 31 Mar 1995 08:43:13 EST." <9503311343.AA22039@xirtlu.zk3.dec.com> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 31 Mar 1995 11:21:32 -0500 From: "Perry E. Metzger" bound@zk3.dec.com says: > where are the banks going to use > ESP for the Internet? )---> thanks (ah a requirement I love them). And > what are they doing now without ESP IPSP? My clients these days are typically investment houses and not commercial banks. They tend communicate a lot over international TCP/IP WANs. (I was very amused when a certain ignorant government official actually claimed in my presense that no one was using "the internet" for mission critical applications. Maybe they don't use commercial service providers for them, but loads of people would be dead without their internets.) These corporate WANs can, of course, be easily tapped. Right now, tye typical solution is link encryptors for exposed (i.e. off premises) legs of the communications networks, but in the long run real safety requires end to end solutions. In the long run, without end to end encryption of the ESP sort, these institutions are going to start facing frequent, er, losses, as a result of inadequate security. As soon as prototypes of this stuff arrive people like me are going to start putting enormous pressure on our vendors to supply it. Whether there is a "MUST" in the document or not isn't going to matter much to you in the medium term -- Wall Street buys workstations by the trainload. Perry From ipsec-request@ans.net Fri Mar 31 15:59:53 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14793 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 11:39:54 -0500 Received: by interlock.ans.net id AA14856 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 11:33:05 -0500 Message-Id: <199503311633.AA14856@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 11:33:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 11:33:05 -0500 Date: Fri, 31 Mar 95 15:59:53 GMT From: "William Allen Simpson" To: ipsec@ans.net Cc: ipng@sunroof.eng.sun.com Subject: Re: new Photuris draft available for ftp > From: Robert Elz > Its that there needs to be time before the IETF's for people to > obtain and digest the draft before the IETF meeting. Even a week > before is tight (lots of people are at interop this week I > gather). > As a person who pushed for the Internet-Draft deadline, I absolutely agree. Two weeks would have been even better. > I leave for the airport in a couple of > hours, and I'm not going anywhere near a printer in the meantime. It is particularly important for those like KRE who are travelling long distances. On the other hand, KRE has previously announced that he refuses to take a laptop on the road, merely because he doesn't like the operating systems available. A laptop would solve many of his problems, and he'd be able to read on the plane. > 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. > I agree. Fortunately, in this case there was the -00 draft. The -01 draft merely adds information from implementation experience, including revised packet formats and editorial matters. I'll make sure we cover those differences during the presentation for people who are only familiar with the earlier draft. Thanks for the reminder. 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 Fri Mar 31 15:41:58 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17870 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 11:39:58 -0500 Received: by interlock.ans.net id AA18945 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 11:33:03 -0500 Message-Id: <199503311633.AA18945@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 11:33:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 11:33:03 -0500 Date: Fri, 31 Mar 95 15:41:58 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Some timings Wonderful! Many Thanks!!! > From: Hilarie Orman > MD5 > ======================= > 486 66MHz gcc -O2 1.37 Mbyte/sec > sparc ipc gcc2 -O2 .99 Mbyte/sec > mips 25MHz gcc -O 1.31 Mbyte/sec > hp 735 5.26 Mbyte/sec > sparc10 gcc2 -O2 5.88 Mbyte/sec > dec alpha 600 cc -O2 7.8 Mbyte/sec > > MD4 > ======================= > dec alpha 600 cc -O 6.25 Mbyte/sec > This is the only MD4 versus MD5 comparison, but it makes me question the consistency of the results. MD5 is supposedly _slower_ by design than MD4 -- how did it speed up? -O2 alone? > DH key exchange (512 bit, mod p) > (128 bits of exponent, table of powers of g) > ======================= > Total = 2*Offer + Reply: > Sparc IPC (25MHz) 380 msec estimated > Dec Alpha 600 (175 MHz) 26.2 msec estimated > > The elliptic curve method would speed up slightly with 128 bit exponents > > DH key exchange (elliptic curve, GF[2^155] > (128 bits of exponent, table of powers of g) > ======================= > Total = 2*Offer + Reply: > Sparc IPC (25MHz) 114 msec estimated > Dec Alpha 600 (175 MHz) 21.8 msec estimated > Need to get these estimates verified. Would like to see as large a range of machines as MD5 above. Even so, it is now clear that either will produce satisfactory results for interactive keying. Nobody is even going to notice the telnet latency on startup. The usual telnet option negotiation will dominate. 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 Fri Mar 31 16:34:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14625 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 11:47:03 -0500 Received: by interlock.ans.net id AA41845 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 11:36:06 -0500 Message-Id: <199503311636.AA41845@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 31 Mar 1995 11:36:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 31 Mar 1995 11:36:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 11:36:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 11:36:06 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 11:36:06 -0500 Date: Fri, 31 Mar 1995 08:34:50 -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: ipsec@ans.net, jis@MIT.EDU X-Sun-Charset: US-ASCII Ted, Your suggestion : > Presumably the SPI will include the necessary keying material for the > security context. if I understand it correctly, confuses the SPI, which is the 32 bit identifier carried in IP packets, with the security context information it identifies. The SPI is just a number that anyone can guess or snoop from the network. I understand your observation that > > I believe what's driving this as a requirement is that some applications > may want to exchange keying information on a user-specific level, using > some GSSAPI mechanism (including perhaps Kerberos), and that there be a > way to set the keys derived from authentication done at a user-specific > granularity to be used by the IPsec encryption encapsulation. > and I am not opposed to trying this idea out. My only dispute is making the support for it mandatory. Claims by Perry Metzger to the contrary, I don't think we know enough about this approach to force implementers to support it. My specific concern is that they will spend a great deal of time and effort attempting to engineer a solution, time that is probably better spent getting the core security services implemented. Remember, for IPv6 at least, there is alot of other work to be done in addition to that directed at security. Dan From ipsec-request@ans.net Fri Mar 31 16:42:23 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21041 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 11:48:34 -0500 Received: by interlock.ans.net id AA18380 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 11:43:24 -0500 Message-Id: <199503311643.AA18380@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 31 Mar 1995 11:43:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 31 Mar 1995 11:43:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 11:43:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 11:43:24 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 11:43:24 -0500 Date: Fri, 31 Mar 1995 08:42:23 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: ipsec@ans.net, atkinson@itd.nrl.navy.mil Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) X-Sun-Charset: US-ASCII > From rja@bodhi.cs.nrl.navy.mil Fri Mar 31 05:25:20 1995 > To: ipsec@ans.net > Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) > Mime-Version: 1.0 > > Dan, > > Your assertion that "there is no implementation experience on which > to base the decision" for user-oriented keying is false. THere is > implementation experience with this. > > Ran > atkinson@itd.nrl.navy.mil > OK. Can you share it with us? Dan From ipsec-request@ans.net Fri Mar 31 17:49:55 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07315 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 13:00:29 -0500 Received: by interlock.ans.net id AA25300 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 12:51:23 -0500 Message-Id: <199503311751.AA25300@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 12:51:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 12:51:23 -0500 Date: Fri, 31 Mar 1995 09:49:55 -0800 From: touch@ISI.EDU Posted-Date: Fri, 31 Mar 1995 09:49:55 -0800 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 12:51:23 -0500 To: touch@ISI.EDU, hugo@watson.ibm.com Subject: Re: Breaking 40-bit DES Cc: smb@research.att.com, ipsec@ans.net Hi, everyone, The DES numbers I posted were very preliminary, and unfortunately there was an error in my calculation (factor of 2 over). (I was doing ballpark estimation). > I'm afraid it's a simple matter of arithmetic. > > Let's look at Joe Touch's performance numbers. He got DES speeds > ranging from 20-37 Mbps. To make the arithmetic easy, let's just say > 32 Mbps. At 64 bits per block, that's .5 M encryptions/second, or 2 > microseconds per encryption. To exhaustively search a 40-bit key > space, we need to do about 10^12 operations. Assume that the key setup > overhead for an exportable cipher is about 5 DES operations (and that's > an overestimate, in my opinion), or 10^-5 seconds. That means that a > single processor could search the key space in 10^7 seconds. Run > this in parallel on 100 idle machines (or hacked machines on a LAN), > and you're done in 10^5 seconds. That's a bit over one day. > > Note that the only real assumption in this analysis is how long it takes to > do one key setup+encryption operation. Even if I'm off by a factor of > 10, it still gives you no privacy protection, though arguably it's > safe for now for authentication, since few sessions last 11.5 days. > > > --Steve Bellovin Here are more precise measurements (no variance - just one-shot): DESCORE: encry BW key time 10/51 5us 12.8 58us 20/61 4us 16 49us 20/71 3.1us 20.6 38us LIBDES: 10/51 9.9us 6.4 17.3us 20/61 8.3us 7.7 14.2us 20/71 6.5us 9.8 14.2us So, if you are doing encryption, I'd say 20-30 Mbps is still realistic (include Alphas and Pentiums, etc). As to the key time, it depends on what you use, (above). If you want a single set key and then a single encrypt, the best thing to use is LIBDES. Steve's estimate of 5x for key setup (vs. encrypt block) is emperically very accurate, but note that the above varies widely. Searching the key space could be done in 14.2us each, which is right in line with his estimate of 10us (even though *my* math was the one whose was off... :-) Joe From ipsec-request@ans.net Fri Mar 31 09:30:37 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26799 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 14:43:24 -0500 Received: by interlock.ans.net id AA23814 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 14:30:41 -0500 Message-Id: <199503311930.AA23814@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 14:30:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 14:30:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 14:30:41 -0500 Date: Fri, 31 Mar 1995 14:30:37 +0500 From: Theodore Ts'o To: Danny.Nessett@eng.sun.com Cc: ipsec@ans.net, jis@MIT.EDU In-Reply-To: Dan Nessett's message of Fri, 31 Mar 1995 08:34:50 -0800, <199503311634.IAA04100@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: 1287 Date: Fri, 31 Mar 1995 08:34:50 -0800 From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) Your suggestion : > Presumably the SPI will include the necessary keying material for the > security context. if I understand it correctly, confuses the SPI, which is the 32 bit identifier carried in IP packets, with the security context information it identifies. The SPI is just a number that anyone can guess or snoop from the network. ... which recent messages have termed the "SAID". This may all be a confusion with the terminology that's used. and I am not opposed to trying this idea out. My only dispute is making the support for it mandatory. Claims by Perry Metzger to the contrary, I don't think we know enough about this approach to force implementers to support it. On the contrary. In so far as we are requiring the support of out-of-band keying as a default mechanism which must be implemented, the ability to set the security context information outside of the kernel is both (a) trivial, and (b) a good idea in terms of requiring abstraction boundaries. As Ran said, I don't see this as an editorial change, but rather being more explicit in stating what has always been the case, as a fundamental design philosophy. - Ted From ipsec-request@ans.net Fri Mar 31 19:48:33 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15903 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 14:54:47 -0500 Received: by interlock.ans.net id AA40778 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 14:52:03 -0500 Message-Id: <199503311952.AA40778@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 14:52:03 -0500 To: "Steven M. Bellovin" Cc: ipsec@ans.net Subject: Re: Routing In-Reply-To: Your message of Tue, 28 Mar 95 11:24:04 -0500. <199503281724.AA38395@interlock.ans.net> Date: Fri, 31 Mar 95 14:48:33 -0500 From: Steve Kent Steve, I agree with your asseement that using an intermediate system to implement IPSP will often be appropriate for a variety of reasons, not only the difficulty and cost of providing tamper-resistant crypto at end systems. However, the question of having an intermediate system be a party to an IPSP security association is a different matter. I too was at the IAB security workshop in question and I recall the presentations on having intermediate systems interact with end systems to provide security services better than those now offered by various firewalls. However, I am not confident that IPSP, as it is defined so far, has been engineered with appropriate provisions for the sort of multi-party security association management that appears to be implied by the suggestions that both you and Ran have put forth. Experience suggests that it is fairly difficult to implement a flexible network layer security protocol at an intermediate system, even when the protocol is still point-to-point. IPSP makes some efforts to accommodate multi-point communication, which ups the ante. What I think I hear you and Ran suggesting, and please correct me if I misunderstood, is to have an intermediate system perform the crypto for IPSP but to have much of the rest of the protocol execute back at the endpoint. Alternatively, I may have heard a suggestion that some of IPSP operate at the intermediate system, but that most of it operate at the intermediate system, essentially allowing the end system to signal security association control parameters to the intermediate system. I'd feel much more confortable these suggestions were backed up with detailed discussions of the scenarios under which these features would be employed, plus an analysis of how end and intermediate system implementations of (vanilla) IPSP would have to operate differently to function properly in this new mode. It's easy to say that such uses are not prohibited, but until we do the homework to ensure that such configurations do not introduce significant complexity into the protocol, or into end or intermediate system implementations that communicate with these distributed implementations, I worry that we may be promising more than we know how to deliver. Steve From ipsec-request@ans.net Fri Mar 31 10:00:41 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24673 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 15:03:56 -0500 Received: by interlock.ans.net id AA49322 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 15:01:38 -0500 Message-Id: <199503312001.AA49322@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 15:01:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 15:01:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 15:01:38 -0500 Date: Fri, 31 Mar 95 15:00:41 EST X-Sender: shirey@smiley.mitre.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: perry@imsi.com From: shirey@mitre.org (Robert W. Shirey) Subject: Re: IPv6 Security Last Call Initial Questions Cc: ipsec@ans.net At 11:21 AM 3/31/95, Perry E. Metzger wrote: ... >TCP/IP WANs. (I was very amused when a certain ignorant government >official actually claimed in my presense that no one was using "the >internet" for mission critical applications. Perry, I am not amused, and have not been amused for some time, by your frequent use of "ignorant" and other perjorative terms. In this case, I think it's a matter of your lack of familiarity of the terminology used in the Government, particularly the U.S. Department of Defense. In the DoD and other parts of Government, this is the usual definition: A service is *critical* or *mission-critical* if denial of service would directly or indirectly jeopardize human life or adversely affect national security by impairing the ability of a major defense component to perform a primary mission function. (Even the defining terms here are heavily loaded with meaning, particularly "national security", and "primary mission function" when used in combination with "major defense component". Try "control of the sealanes" in the context of "Commander Atlantic Fleet".) Data networks are used to provide mission-critical services throughout DoD and rest of the Federal community. I am not yet aware of such usage on the Internet. -Rob- From ipsec-request@ans.net Fri Mar 31 17:05:27 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23340 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 15:18:15 -0500 Received: by interlock.ans.net id AA39345 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 15:11:39 -0500 Message-Id: <199503312011.AA39345@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 15:11:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 15:11:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 15:11:39 -0500 To: perry@imsi.com Cc: bound@zk3.dec.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Fri, 31 Mar 95 11:21:32 EST." <9503311621.AA21354@snark.imsi.com> Date: Fri, 31 Mar 95 12:05:27 -0500 From: bound@zk3.dec.com X-Mts: smtp Perry, Thanks....Excellent market input.... >These corporate WANs can, of course, be easily tapped. Right now, tye >typical solution is link encryptors for exposed (i.e. off premises) >legs of the communications networks, but in the long run real safety >requires end to end solutions. In the long run, without end to end >encryption of the ESP sort, these institutions are going to start >facing frequent, er, losses, as a result of inadequate security. As >soon as prototypes of this stuff arrive people like me are going to >start putting enormous pressure on our vendors to supply it. Whether >there is a "MUST" in the document or not isn't going to matter much to >you in the medium term -- Wall Street buys workstations by the >trainload. Your last sentence is the key to what I have been arguing. If Wall Street is going to buy lots of workstations any vendor that does not conform to IPSP will not gain profit in the market. I have agreed long ago to MUST implement IPSP and MAY USE in the market. I would like to build an implementation that has the flexibility to comply to customer and market requirements and not have to build standards into a product that prohibit experimentation or create costs that will raise the cost of the product. We can build IPSP and leave the algorithms to a list of SHOULDs which affords the vendors freedom in designing our architecture of IPSP to respond to changes as they evolve. There will be customers with varying security level requirements. Each needing different levels. Thats all I asked and am asking for now. Please lets not prohibit anything unless its outright dumb. Like saying the IPv6 security payload can have the fields in different places. As an individual I am against any type of regulation when it is not necessary, and believe private enterprise will figure it out better. In fact if you look at the back of my truck if you see me drive up to the Tara at Danvers you will see a sticker on the back of my bumper that says "I Vote for Less Government" (I am local at this meeting). But then again I think its a disgrace that every person in the U.S. does not have health care. Its like the notion of the astrological sign Libra. We need to keep a balance. I think ESP MUST IMPLEMENT DES tips the scales too far against the vendors in our IETF community and is a form of incorrect 'regulation" that is not justified or necessary technically or from a business perspective. If we could get past this I and others would join you and others and go build the best damn security for the Internet possible (I also hope the Internet does not get regulated in the U.S. either). Would that not be a good thing to do? Change MUST to SHOULD for DES. I will even accept MUST for MD5 for authentication as that has no export issue. p.s. if you want one of those bumper stickers see Ross Callon. /jim From ipsec-request@ans.net Fri Mar 31 20:23:05 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23388 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 15:26:38 -0500 Received: by interlock.ans.net id AA23712 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 15:23:30 -0500 Message-Id: <199503312023.AA23712@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 31 Mar 1995 15:23:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 15:23:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 15:23:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 15:23:30 -0500 To: shirey@mitre.org (Robert W. Shirey) Cc: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Fri, 31 Mar 1995 15:00:41 EST." Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 31 Mar 1995 15:23:05 -0500 From: "Perry E. Metzger" Robert W. Shirey says: > At 11:21 AM 3/31/95, Perry E. Metzger wrote: > ... > > >TCP/IP WANs. (I was very amused when a certain ignorant government > >official actually claimed in my presense that no one was using "the > >internet" for mission critical applications. > > In this case, I think it's > a matter of your lack of familiarity of the terminology used in the > Government, particularly the U.S. Department of Defense. The individual in question believed the internet to be a toy without commercial application, and had reason to know better. BTW, "mission critical" on Wall Street means you start losing significant money or go bankrupt if the application in question goes down. This is the equivalent of the DOD notion of "mission critical" meaning that loss of the application would endanger life or national security, since for a corporate entity where billions of dollars are at stake in a day's trading the urgency is often as extreme, at least to the company. The situation is in some sense more extreme than you would expect because in some firms such as highly leveraged trading operations one is essentially "at war" at all times. > Data networks are used to provide mission-critical services throughout DoD > and rest of the Federal community. I am not yet aware of such usage on the > Internet. I know of financial institutions that could conceivably go bankrupt within a brief period without their corporate TCP/IP networks remaining functional. This is not to say that these companies depend on external service providers to keep these networks working. Keep in mind, by the way, that the protocols we are talking about are used internally in organizations as well as externally. My interest in a functioning IPSP is far more frequently for internal use by my clients, although of course the external applications are also nice. Perry From ipsec-request@ans.net Fri Mar 31 20:33:39 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23540 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 15:38:06 -0500 Received: by interlock.ans.net id AA51882 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 15:34:41 -0500 Message-Id: <199503312034.AA51882@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 31 Mar 1995 15:34:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 31 Mar 1995 15:34:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 15:34:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 15:34:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 15:34:41 -0500 Date: Fri, 31 Mar 1995 12:33:39 -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: ipsec@ans.net, jis@MIT.EDU X-Sun-Charset: US-ASCII Ted, You argue : > On the contrary. In so far as we are requiring the support of > out-of-band keying as a default mechanism which must be implemented, the > ability to set the security context information outside of the kernel is > both (a) trivial, and (b) a good idea in terms of requiring abstraction > boundaries. Setting the security context information outside the kernel and doing so on a per-user basis are two very different things. When per-host keying is used, the IP implementation already has enough information, e.g., the destination address, to pass to a user-level daemon to establish/access a security context. When per-user keying is used, there will be changes required to the socket/TLI/XTI/etc/ interfaces so that an application can pass an SPI and security context information to the kernel. Dan From ipsec-request@ans.net Fri Mar 31 10:58:31 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21684 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 16:03:11 -0500 Received: by interlock.ans.net id AA52698 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 15:58:55 -0500 Message-Id: <199503312058.AA52698@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 15:58:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 15:58:55 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 15:58:55 -0500 Date: Fri, 31 Mar 1995 15:58:31 +0500 From: Theodore Ts'o To: Theodore Ts'o Cc: Danny.Nessett@eng.sun.com, ipsec@ans.net, jis@MIT.EDU In-Reply-To: Theodore Ts'o's message of Fri, 31 Mar 1995 14:30:37 +0500, <9503311930.AA11832@dcl.MIT.EDU> Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 559 Date: Fri, 31 Mar 1995 14:30:37 +0500 From: Theodore Ts'o As Ran said, I don't see this as an editorial change, but rather being more explicit in stating what has always been the case, as a fundamental design philosophy. Oops.... my fingers got ahead of my thoughts. Sorry about that. This should have read: As Ran said, I don't see this as being a substantive technical change, but rather an editorial one, by being more explicit in stating what has always been the case, as a fundamental design philosophy. - Ted From ipsec-request@ans.net Fri Mar 31 20:58:04 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27393 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 16:07:46 -0500 Received: by interlock.ans.net id AA32181 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 16:03:58 -0500 Message-Id: <199503312103.AA32181@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 16:03:58 -0500 From: Ran Atkinson Date: Fri, 31 Mar 1995 15:58:04 -0500 In-Reply-To: Danny.Nessett@Eng.Sun.COM (Dan Nessett) "Re: IPv6 Security Last Call Initial Questions (per user keying)" (Mar 31, 12:33) References: <199503312034.AA51882@interlock.ans.net> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.0 15dec93) To: Dan Nessett , tytso@MIT.EDU Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Cc: ipsec@ans.net, jis@MIT.EDU Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: rja@bodhi.cs.nrl.navy.mil On Mar 31, 12:33, Dan Nessett wrote: % When per-user keying is used, there will be changes % required to the socket/TLI/XTI/etc/ interfaces so that an % application can pass an SPI and security context information % to the kernel. I disagree. Changes to the Socket/TLI/XTI interfaces will be needed in any event so that applications that are "security-aware" can request the particular security services that they desire. A document that discusses some of the API issues is already online with a filename similar to "draft-mcdonald-sec-api-*.txt". I should mention that the Security API draft is a drafty draft mainly out to focus discussions. Also, the IETF doesn't standardise APIs so that would become an Informational RFC if it went to RFC in the future. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Fri Mar 31 21:16:50 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24977 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 16:21:27 -0500 Received: by interlock.ans.net id AA39733 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 16:17:05 -0500 Message-Id: <199503312117.AA39733@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 31 Mar 1995 16:17:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 16:17:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 16:17:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 16:17:05 -0500 To: Danny.Nessett@eng.sun.com (Dan Nessett) Cc: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) In-Reply-To: Your message of "Fri, 31 Mar 1995 12:33:39 PST." <199503312034.AA51882@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 31 Mar 1995 16:16:50 -0500 From: "Perry E. Metzger" Dan Nessett says: > > On the contrary. In so far as we are requiring the support of > > out-of-band keying as a default mechanism which must be implemented, the > > ability to set the security context information outside of the kernel is > > both (a) trivial, and (b) a good idea in terms of requiring abstraction > > boundaries. > > Setting the security context information outside the kernel and doing so > on a per-user basis are two very different things. When per-host keying > is used, the IP implementation already has enough information, e.g., the > destination address, to pass to a user-level daemon to establish/access a > security context. When per-user keying is used, there will be changes > required to the socket/TLI/XTI/etc/ interfaces so that an application can > pass an SPI and security context information to the kernel. You speak of these changes as if they were some sort of obstacle. They aren't. They are just a few additions to the API, and aren't such a big deal. I believe that more than one of us has already prototyped such additions to the API and they seem straightforward. BTW, I would appreciate it if you used our terminology. "SPI" isn't the local jargon, and it gets difficult to keep track of all the terms being bandied about. Please say "Security Association" or "SAID" if you are refering to one of those... Perry From ipsec-request@ans.net Fri Mar 31 21:35:34 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22136 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 16:49:40 -0500 Received: by interlock.ans.net id AA50634 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 16:44:10 -0500 Message-Id: <199503312144.AA50634@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 16:44:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 16:44:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 16:44:10 -0500 To: ipsec@ans.net Subject: Seucurity API Date: Fri, 31 Mar 95 16:35:34 -0500 From: bound@zk3.dec.com X-Mts: smtp Subject was: Re: IPv6 Security Last Call Initial Questions (per user keying) > A document that discusses some of the API issues is already online >with a filename similar to "draft-mcdonald-sec-api-*.txt". I should >mention that the Security API draft is a drafty draft mainly out to >focus discussions. Also, the IETF doesn't standardise APIs so that >would become an Informational RFC if it went to RFC in the future. This is true. But we have found it very beneficial to have a working and implemented API for the IPv6 WG to test. It also brings out issues as to how the protocol is used. Also the API spec in the case of IPv6 also defined the socket structure which is used in BSD derived systems in the IPv6 test systems I am aware of for IPv6 which is only two I admit. INRIA and Digital. Also others that are still working on implementations to join the test soon I hope. If you want to test any IPv6 implementations you have let me know off line and I will send you a pointer. We can at least test out IPv6-IPv4 tunneling which tests the API, transport, and parts of the network layer. I urge the IPSEC WG strongly to listen to Dan on the API issue as my input, because it is also a test of implementing the standard, and we all will need some kind of API to do keying. /jim From ipsec-request@ans.net Fri Mar 31 21:46:06 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22153 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 16:50:19 -0500 Received: by interlock.ans.net id AA35372 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 16:46:14 -0500 Message-Id: <199503312146.AA35372@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 31 Mar 1995 16:46:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 16:46:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 16:46:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 16:46:14 -0500 To: ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) In-Reply-To: Your message of "Fri, 31 Mar 1995 16:16:50 EST." <199503312117.AA39733@interlock.ans.net> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Fri, 31 Mar 1995 16:46:06 -0500 From: "Perry E. Metzger" "Perry E. Metzger" says: > BTW, I would appreciate it if you used our terminology. "SPI" isn't > the local jargon, and it gets difficult to keep track of all the terms > being bandied about. Please say "Security Association" or "SAID" if > you are refering to one of those... I am told that the jargon has changed in the most recent draft, which *I* must confess to not having read (MEGO has hit me and Ran has been acting as editor and I trust him). That will teach me not to shoot my mouth off. .pm From ipsec-request@ans.net Fri Mar 31 12:22:22 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27566 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 17:26:55 -0500 Received: by interlock.ans.net id AA19544 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 17:22:30 -0500 Message-Id: <199503312222.AA19544@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 17:22:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 17:22:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 17:22:30 -0500 Date: Fri, 31 Mar 1995 17:22:22 +0500 From: Theodore Ts'o To: Danny.Nessett@eng.sun.com Cc: ipsec@ans.net, jis@MIT.EDU In-Reply-To: Dan Nessett's message of Fri, 31 Mar 1995 12:33:39 -0800, <199503312033.MAA04237@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: 990 Date: Fri, 31 Mar 1995 12:33:39 -0800 From: Danny.Nessett@Eng.Sun.COM (Dan Nessett) Setting the security context information outside the kernel and doing so on a per-user basis are two very different things. When per-host keying is used, the IP implementation already has enough information, e.g., the destination address, to pass to a user-level daemon to establish/access a security context. When per-user keying is used, there will be changes required to the socket/TLI/XTI/etc/ interfaces so that an application can pass an SPI and security context information to the kernel. And you consider this difficult? As someone who does kernel hacking for recreational purposes, adding a socket-level interface which will allow this information to be passed in on a per-socket level, I would think this will actually be easier than to do than necessary work of defining a new interface for specifying which key needs to be used on a per-host basis. - Ted From ipsec-request@ans.net Fri Mar 31 12:29:07 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20714 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 17:32:20 -0500 Received: by interlock.ans.net id AA41067 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 17:29:23 -0500 Message-Id: <199503312229.AA41067@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 17:29:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 17:29:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 17:29:23 -0500 Date: Fri, 31 Mar 1995 17:29:07 +0500 From: Theodore Ts'o To: bound@zk3.dec.com Cc: perry@imsi.com, bound@zk3.dec.com, ipsec@ans.net In-Reply-To: bound@zk3.dec.com's message of Fri, 31 Mar 95 12:05:27 -0500, <199503312011.AA39345@interlock.ans.net> Subject: Re: IPv6 Security Last Call Initial Questions Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 1324 Date: Fri, 31 Mar 95 12:05:27 -0500 From: bound@zk3.dec.com If we could get past this I and others would join you and others and go build the best damn security for the Internet possible (I also hope the Internet does not get regulated in the U.S. either). Would that not be a good thing to do? Change MUST to SHOULD for DES. I will even accept MUST for MD5 for authentication as that has no export issue. There has already been significant community conensus --- beyond this working group, as this is a general IETF issue --- that we should not take into account export issues, which tend to be very country specific(*), when deciding which technologies we should standardize on. Furthermore, we must require at least one algorithm so that we can guanratee interoperability. You seem to be the only one argueing for making DES optional.... - Ted (*) Remember, the IETF is an international, technical organization. If a particular country wishes to make its companies suffer under a competitive disadvantage compared to the rest of the world, that's that country's business, not the IETF's. If one lives in such a country, and is concerned about such stupidity, I would encourage that person to write to his or her governemnt representatives. But that is *not* a matter for the IETF. From ipsec-request@ans.net Fri Mar 31 23:21:03 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27645 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 18:28:50 -0500 Received: by interlock.ans.net id AA04754 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 18:24:25 -0500 Message-Id: <199503312324.AA04754@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 18:24:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 18:24:25 -0500 Organization: To: shirey@mitre.org (Robert W. Shirey) Cc: perry@imsi.com, ipsec@ans.net Subject: Re: IPv6 Security Last Call Initial Questions In-Reply-To: Your message of "Fri, 31 Mar 1995 15:00:41 EST." <199503312001.AA49322@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <15715.796692063.1@forthnet.gr> Date: Sat, 01 Apr 1995 02:21:03 +0300 From: "Aggelos D. Keromitis" -----BEGIN PGP SIGNED MESSAGE----- In message <199503312001.AA49322@interlock.ans.net>, Robert W. Shirey writes: > >Data networks are used to provide mission-critical services throughout DoD >and rest of the Federal community. I am not yet aware of such usage on the >Internet. > Always learning: there is a project here in Crete (Greece) called EURIPACS, which will use the existing network (which is a part of Internet, albeit a small one) to transfer medical images from one hospital to another. This is just testing for now, but in the future all the hospitals in Crete (and then probably in Greece...i have to see that tho) will be interconnected; due to high cost and constant unavailability of links by the PTT, they'll use the backbone already created by FORTHnet (where i work) and the other major network provider in Greece. So the Internet (capital I) may be used after all for "critical missions". - -Aggelos ============================================================================= Aggelos Keromitis kermit@csd.uch.gr Heraclion, Greece kermit@forthnet.gr Finger kermit@vicky.forthnet.gr for public PGP key ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBL3yOWr0pBjh2h1kFAQGorwQAmsN1rdWFWMldgTZN6NFHuz724VNBjhOT /WJs2H2JPqqCKxu6E61/t0GsLl+5fbw6Xm87Agn2HGIyhpk3EUxgiKomCkcdSGxW 8k6sUup4IZ+9UHtFVx/DeOmG6ZO2XyP0DWmGlTHQeXknZOY91fXF+PKzKzxB8iA0 w+HNOwVEPms= =5s8L -----END PGP SIGNATURE----- From ipsec-request@ans.net Fri Mar 31 22:41:02 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04100 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 18:29:25 -0500 Received: by interlock.ans.net id AA32903 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 18:24:11 -0500 Message-Id: <199503312324.AA32903@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 18:24:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 18:24:11 -0500 Date: Fri, 31 Mar 95 22:41:02 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Mission-Critical > From: shirey@mitre.org (Robert W. Shirey) > >TCP/IP WANs. (I was very amused when a certain ignorant government > >official actually claimed in my presense that no one was using "the > >internet" for mission critical applications. > > I am not amused, and have not been amused for some time, by your frequent > use of "ignorant" and other perjorative terms. In this case, I think it's > a matter of your lack of familiarity of the terminology used in the > Government, particularly the U.S. Department of Defense. "Mission-Critical" has been long used in the private sector. It has a similar meaning, which perform a primary mission function. The local University Hospitals use the Internet, and would have serious human life problems otherwise. Going through Infoworld, we see "mission-critical" applied to trucking, point-of-sale terminals, manufacturing, and ski resorts, as well as the usual electrical power companies and securities firms. Perry's use of the word "ignorant" was accurate. > Data networks are used to provide mission-critical services throughout DoD > and rest of the Federal community. I am not yet aware of such usage on the > Internet. > They all use the Internet. The "Federal community" is not the the world. And isn't that the same DoD which funded the developement of IP? Are you saying they don't actually use it? 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 Fri Mar 31 23:26:35 1995 Received: from interlock.ans.net by nis.ans.net with SMTP id AA24597 (5.65c/IDA-1.4.4 for ); Fri, 31 Mar 1995 18:32:18 -0500 Received: by interlock.ans.net id AA17425 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 31 Mar 1995 18:27:58 -0500 Message-Id: <199503312327.AA17425@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 31 Mar 1995 18:27:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 31 Mar 1995 18:27:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 31 Mar 1995 18:27:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 31 Mar 1995 18:27:58 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 31 Mar 1995 18:27:58 -0500 Date: Fri, 31 Mar 1995 15:26:35 -0800 From: Danny.Nessett@eng.sun.com (Dan Nessett) To: tytso@MIT.EDU, atkinson@itd.nrl.navy.mil Subject: Re: IPv6 Security Last Call Initial Questions (per user keying) Cc: ipsec@ans.net, jis@MIT.EDU X-Sun-Charset: US-ASCII Ran, You observe that: > > Changes to the Socket/TLI/XTI interfaces will be needed in any event > so that applications that are "security-aware" can request the > particular security services that they desire. which, I agree, is true. > A document that discusses some of the API issues is already online > with a filename similar to "draft-mcdonald-sec-api-*.txt". I should > mention that the Security API draft is a drafty draft mainly out to > focus discussions. Also, the IETF doesn't standardise APIs so that > would become an Informational RFC if it went to RFC in the future. Note, the McDonald draft doesn't address the issue of moving security context information between an application process and the kernel. I talked with Bob Gilligan about this and we sketched out a way that such an interface might work (on both the client and server sides). However, I think the proponents of making per-user keying mandatory should at least provide a feasibility design that sketches out how, for example, the socket interface could be changed to allow per-user keying. It is only prudent that such an existence proof exist before making per-user keying mandatory. I think the design needs to address at least the following issues : o How will the SPI and security context information be passed from both connecting and accepting processes to the IP implementation? o How might this information be derived from the key management protocol? Any choice here can be used, Photuris, Kerberos, etc. o What will happen when an IP packet is processed both on the sending and receiving sides? o What calls are necessary so that an application can find out the algorithms and key parameters that the system supports. This doesn't have to be an Internet Draft or anything, a simple email message will do. But the IPsec WG should be convinced that per-user keying can be supported before making it mandatory. Dan P.S. Ted says this is easy, so perhaps he can consider this as a challenge :-).