From ipsec-request@ans.net Fri Dec 1 00:28:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17194 (5.65c/IDA-1.4.4 for ); Thu, 30 Nov 1995 15:53:32 -0500 Received: by interlock.ans.net id AA04987 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Nov 1995 15:45:28 -0500 Message-Id: <199511302045.AA04987@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Nov 1995 15:45:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Nov 1995 15:45:28 -0500 X-Sender: karn@servo.qualcomm.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Nov 1995 16:28:07 -0800 To: ashar@osmosys.incog.com (Ashar Aziz), ipsec@ans.net From: Phil Karn Subject: Re: WG Last Call for SKIP I-D At 05:41 PM 11/27/95 -0800, Ashar Aziz wrote: >The solution is to let the certified DH public key be instead >a set of certified DH public keys, each of which have shorter >validity than a typical certificate, say one or two weeks. The set >of intervals over which each public key is valid would be contiguous >and non-overlapping, and the sum of these intervals would equal >the validity period of a typical certificate, say six >months or a year. Ashar, While key lifetimes of a week or two may technically qualify as "perfect forward secrecy", I for one want *much* shorter lifetimes, more on the order of minutes to perhaps an hour, max. Phil From ipsec-request@ans.net Thu Nov 30 10:50:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18775 (5.65c/IDA-1.4.4 for ); Thu, 30 Nov 1995 16:04:20 -0500 Received: by interlock.ans.net id AA05597 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Nov 1995 16:00:50 -0500 Message-Id: <199511302100.AA05597@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Nov 1995 16:00:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Nov 1995 16:00:50 -0500 Date: Thu, 30 Nov 95 15:50:49 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: SKEME For those that need some reading material during the flight to Dallas, you may want to take a look at a paper that I have written on a proposal I have once presented to this group for enhancing Photuris (I called that proposal "Photuris variant"). For the paper, I have renamed the protocol to SKEME (Secure Key Exchange MEchanism). The paper discusses in some detail requirements (as I see them) for an Internet's key management protocol, and proposes a particular solution to achieve these requirements. I am offering this as reading material for people interested on these issues. I am *not* proposing it as yet another proposal for IPSEC (although I definitely support the addition of some of the features in SKEME to Photuris). I will be glad to have personal discussions with people in Dallas regarding the (many) issues raised in that paper. Enjoy! (I hope) The paper can be retrieved from URL: http://www.research.ibm.com/xw-941f-skeme This work will be presented at the February's Internet Society Symposium on Network and Distributed System Security (SNDSS'96) in San Diego. Hugo From ipsec-request@ans.net Thu Nov 30 23:31:46 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19657 (5.65c/IDA-1.4.4 for ); Thu, 30 Nov 1995 18:40:22 -0500 Received: by interlock.ans.net id AA09257 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Nov 1995 18:33:05 -0500 Message-Id: <199511302333.AA09257@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Nov 1995 18:33:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Nov 1995 18:33:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Nov 1995 18:33:05 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: Phil Karn Cc: ashar@osmosys.incog.com (Ashar Aziz), ipsec@ans.net Subject: Re: WG Last Call for SKIP I-D In-Reply-To: karn's message of Thu, 30 Nov 1995 16:28:07 -0800. <199511302045.AA04987@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 30 Nov 1995 18:31:46 -0500 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii While key lifetimes of a week or two may technically qualify as "perfect forward secrecy", I for one want *much* shorter lifetimes, more on the order of minutes to perhaps an hour, max. Hmm. Given the current CPU cost of exponential key exchange, I suspect some installations will want somewhat longer lifetimes than 1 hour (though probably not ones as long as Ashar's "2 weeks"). Assuming that the modular exponentiation involved in the DH exchange takes 1 CPU second, a system in regular communication with 1000 other systems would then wind up spending just under 30% of its time doing modular exponentiations. Server fanout like this isn't as improbable as it might sound.. a couple of AFS file servers at MIT I just checked have ~650 active clients at the moment. This brings up another point (and some suggested text for the photuris I-D): If a number of communicating systems use similar SPI and/or exchange lifetimes, their photuris exchanges will likely tend to cluster, which may result in periodic CPU load spikes or other erratic behavior. To avoid this, implementations should add a significant amount of random jitter to the exchange and SPI lifetimes to avoid synchronization of this form. The exact amount of jitter needed will need to be determined experimentally once photuris is deployed. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBML4+0Fpj/0M1dMJ/AQHcugP7Bl4SQnysw2+NopY2H01vvMqv0SClD3Qr xQbuwwnjMORyqKWsnRECAufRZxXO5tnjerDO+6/ru/8JVhpRfArdkgamtnrUVUf8 gqViHNKVrOwIdJ6y5E4DZ9iwhxi7++hdRHBgaokVL4VRtZ1bUyqZvOTvWNK8oATe gX0x32rlkDE= =EqeE -----END PGP SIGNATURE----- From ipsec-request@ans.net Thu Nov 30 23:43:57 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20439 (5.65c/IDA-1.4.4 for ); Thu, 30 Nov 1995 18:47:57 -0500 Received: by interlock.ans.net id AA09436 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Nov 1995 18:44:03 -0500 Message-Id: <199511302344.AA09436@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 30 Nov 1995 18:44:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Nov 1995 18:44:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Nov 1995 18:44:03 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: ipsec@ans.net Subject: long lifetime SPI's Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 30 Nov 1995 18:43:57 -0500 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii photuris-08 contains: The careful reader will undoubtedly notice that this scenario is | somewhat tongue-in-cheek. Repeated crashes of servers might be | fixed by changing to a different vendor.... | It's worth pointing out that sometimes server outages are caused by power failures, which are usually beyond the control of the either the installation or the server vendor. Photuris implementations should be engineered to behave gracefully during a severe startup transient; the cleanest way to do this may well be for responders to temporarily stop responding to cookie requests if the number of pending exchange computations got too large.. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCUAwUBML5Br1pj/0M1dMJ/AQEe6gP3fm81MVqkSC+DsrQdMSOMn4vF8gdcOGWM 1EijrkiI6PZKItwONskdpLt1QUjtjruhDrcvK2lEfnKCiSo0PwDUczUOLXpTAGgx TMwOHyC0VEC5IG2LRnuV+M6TKpB4xJjzILN/suuBDZztgBqNXM6J3V4VrDkOtSIT cC4iwgeJIA== =kJV1 -----END PGP SIGNATURE----- From ipsec-request@ans.net Fri Dec 1 03:19:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19343 (5.65c/IDA-1.4.4 for ); Thu, 30 Nov 1995 22:28:03 -0500 Received: by interlock.ans.net id AA13043 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 30 Nov 1995 22:19:59 -0500 Message-Id: <199512010319.AA13043@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 30 Nov 1995 22:19:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 30 Nov 1995 22:19:59 -0500 From: David A Wagner Subject: Re: length of exponents To: ipsec@ans.net Date: Thu, 30 Nov 1995 19:19:53 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 811 hugo@watson.ibm.com writes: > If one uses 160 long exponents the security becomes at most 2^80 because > of Shanks/Pollard attacks that require roughly 2^{t/2} operations to find an > exponent whose length is t (this number is independent of the modulus > length). I think this is sound advice. As I've mentioned in private email, Wiener & van Oorschot's results on efficient parallel collision search seem relevant here. In particular, I believe their methods can be used to parallelize Shanks' & Pollard's attacks on short exponents, without incurring extra time or space penalties. This underscores the recommendation to use > 128 bit exponents, since a parallelizable attack requiring 2^64 operations is right on the edge of feasibility (whereas a serial-only attack might not be as much of a concern). From ipsec-request@ans.net Fri Dec 1 09:33:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20308 (5.65c/IDA-1.4.4 for ); Fri, 1 Dec 1995 01:36:34 -0500 Received: by interlock.ans.net id AA16023 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 1 Dec 1995 01:33:47 -0500 Message-Id: <199512010633.AA16023@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 1 Dec 1995 01:33:47 -0500 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 1 Dec 1995 01:33:47 -0500 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 1 Dec 1995 01:33:47 -0500 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 1 Dec 1995 01:33:47 -0500 X400-Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 1 Dec 1995 01:33:47 -0500 Date: Fri, 1 Dec 1995 10:33:51 +0100 X400-Originator: didier.guerin@sept.fr X400-Recipients: ipsec@ans.net X400-Mts-Identifier: [/PRMD=sept/ADMD=ATLAS/C=FR/;81780323170070001GUERIND] X400-Content-Type: P2-1984 (2) Content-Identifier: UCOMX Alternate-Recipient: Allowed From: Didier GUERIN (Tel 3331759219) To: ipsec@ans.net (Non Receipt Notification Requested) Subject: subscribe ipsec@ans.net subscribe ipsec-request@ans.net From ipsec-request@ans.net Fri Dec 1 04:40:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17795 (5.65c/IDA-1.4.4 for ); Fri, 1 Dec 1995 09:59:44 -0500 Received: by interlock.ans.net id AA22233 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 1 Dec 1995 09:41:16 -0500 Message-Id: <199512011441.AA22233@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 1 Dec 1995 09:41:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 1 Dec 1995 09:41:16 -0500 Date: Fri, 1 Dec 95 09:40:53 EST From: hugo@watson.ibm.com To: daw@CS.Berkeley.EDU, ipsec@ans.net Subject: length of exponents Ref: Your note of Thu, 30 Nov 1995 19:19:53 -0800 (PST) (attached) daw@CS.Berkeley.EDU writes: > > hugo@watson.ibm.com writes: > > If one uses 160 long exponents the security becomes at most 2^80 because > > of Shanks/Pollard attacks that require roughly 2^{t/2} operations to find an > > exponent whose length is t (this number is independent of the modulus > > length). > > I think this is sound advice. > > As I've mentioned in private email, Wiener & van Oorschot's results > on efficient parallel collision search seem relevant here. > > In particular, I believe their methods can be used to parallelize > Shanks' & Pollard's attacks on short exponents, without incurring > extra time or space penalties. This is right, and the parallelization applies to their improved attacks on short exponent Diffie-Hellman as well. > > This underscores the recommendation to use > 128 bit exponents, > since a parallelizable attack requiring 2^64 operations is right > on the edge of feasibility (whereas a serial-only attack might > not be as much of a concern). Right. A crucial issue that I failed to point out to.Thanks for clarifying that. Hugo From ipsec-request@ans.net Fri Dec 1 04:43:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17285 (5.65c/IDA-1.4.4 for ); Fri, 1 Dec 1995 09:59:44 -0500 Received: by interlock.ans.net id AA22258 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 1 Dec 1995 09:44:02 -0500 Message-Id: <199512011444.AA22258@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 1 Dec 1995 09:44:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 1 Dec 1995 09:44:02 -0500 Date: Fri, 1 Dec 95 09:43:39 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: keyed-MD5 (referenece) Reference [BCK1] in draft-krawczyk-keyed-md5-01.txt is now available on line from http://www.research.ibm.com/xw-941f-bck1 Hugo From ipsec-request@ans.net Fri Dec 1 04:43:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19915 (5.65c/IDA-1.4.4 for ); Fri, 1 Dec 1995 12:17:06 -0500 Message-Id: <199512011717.AA19915@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Fri, 1 Dec 1995 12:04:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 1 Dec 1995 12:04:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 1 Dec 1995 12:04:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Fri, 1 Dec 1995 12:04:15 -0500 Date: Fri, 1 Dec 95 09:43:39 EST From: hugo@watson.ibm.com To: IPSEC@ans.net Subject: keyed-MD5 (referenece) Reference [BCK1] in draft-krawczyk-keyed-md5-01.txt is now available on line from http://www.research.ibm.com/xw-941f-bck1 Hugo From ipsec-request@ans.net Fri Dec 1 04:40:53 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19967 (5.65c/IDA-1.4.4 for ); Fri, 1 Dec 1995 12:32:53 -0500 Message-Id: <199512011732.AA19967@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Fri, 1 Dec 1995 12:25:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 1 Dec 1995 12:25:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 1 Dec 1995 12:25:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Fri, 1 Dec 1995 12:25:50 -0500 Date: Fri, 1 Dec 95 09:40:53 EST From: hugo@watson.ibm.com To: daw@CS.Berkeley.EDU, ipsec@ans.net Subject: length of exponents Ref: Your note of Thu, 30 Nov 1995 19:19:53 -0800 (PST) (attached) daw@CS.Berkeley.EDU writes: > > hugo@watson.ibm.com writes: > > If one uses 160 long exponents the security becomes at most 2^80 because > > of Shanks/Pollard attacks that require roughly 2^{t/2} operations to find an > > exponent whose length is t (this number is independent of the modulus > > length). > > I think this is sound advice. > > As I've mentioned in private email, Wiener & van Oorschot's results > on efficient parallel collision search seem relevant here. > > In particular, I believe their methods can be used to parallelize > Shanks' & Pollard's attacks on short exponents, without incurring > extra time or space penalties. This is right, and the parallelization applies to their improved attacks on short exponent Diffie-Hellman as well. > > This underscores the recommendation to use > 128 bit exponents, > since a parallelizable attack requiring 2^64 operations is right > on the edge of feasibility (whereas a serial-only attack might > not be as much of a concern). Right. A crucial issue that I failed to point out to.Thanks for clarifying that. Hugo From ipsec-request@ans.net Fri Dec 1 14:29:00 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17480 (5.65c/IDA-1.4.4 for ); Sat, 2 Dec 1995 07:43:38 -0500 Received: by interlock.ans.net id AA17401 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 2 Dec 1995 07:32:59 -0500 Message-Id: <199512021232.AA17401@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 2 Dec 1995 07:32:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 2 Dec 1995 07:32:59 -0500 Date: Fri, 1 Dec 95 14:29:00 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: length of exponents > From: David A Wagner > hugo@watson.ibm.com writes: > > If one uses 160 long exponents the security becomes at most 2^80 because > > of Shanks/Pollard attacks that require roughly 2^{t/2} operations to find an > > exponent whose length is t (this number is independent of the modulus > > length). > > I think this is sound advice. > Good, then I'm sure that you both will support the fact that at least the past two draft revisions already state [page 48]: Exponent lengths of 196 to 256 bits are recommended. That seems to be a fair bit more than 128 and/or 160. It is in line with the estimated strength of the modulus, which is the driving factor. 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 Dec 1 14:15:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18762 (5.65c/IDA-1.4.4 for ); Sat, 2 Dec 1995 07:43:39 -0500 Received: by interlock.ans.net id AA17393 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 2 Dec 1995 07:32:57 -0500 Message-Id: <199512021232.AA17393@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 2 Dec 1995 07:32:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 2 Dec 1995 07:32:57 -0500 Date: Fri, 1 Dec 95 14:15:38 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: long lifetime SPI's > From: Bill Sommerfeld > Photuris implementations should be engineered to behave gracefully > during a severe startup transient; the cleanest way to do this may > well be for responders to temporarily stop responding to cookie > requests if the number of pending exchange computations got too > large.. > There is already such a Responder error return: 6.2.3. Resource Limit This Error_Message Code is sent when a Cookie_Request or Change_Message is received, and too many SPI values are already in use for that peer, or some other Photuris resource is unavailable. When this Code is received, the party SHOULD NOT instantiate another SPI until it has deleted an existing SPI, or waited for a cached SPI entry to expire. I will add: The implementation SHOULD double the retransmission timeout for sending another Cookie_Request. Just common sense for most implementors (don't all timeout routines work that way since Van Jacobson?), but sometimes it pays to state the obvious. 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 Mon Dec 4 22:17:59 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18712 (5.65c/IDA-1.4.4 for ); Mon, 4 Dec 1995 17:29:52 -0500 Received: by interlock.ans.net id AA10927 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 4 Dec 1995 17:18:17 -0500 Message-Id: <199512042218.AA10927@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 4 Dec 1995 17:18:17 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 4 Dec 1995 17:18:17 -0500 From: Lim Shinyoung(staff) Subject: On Subscription To: ipsec@ans.net Date: Tue, 5 Dec 1995 07:17:59 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 93 Dear Colleague, I would like to subscribe to your working Group. sylim@garam.kreonet.re.kr From ipsec-request@ans.net Tue Dec 5 04:11:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18923 (5.65c/IDA-1.4.4 for ); Mon, 4 Dec 1995 23:21:13 -0500 Received: by interlock.ans.net id AA16995 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 4 Dec 1995 23:11:14 -0500 Message-Id: <199512050411.AA16995@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 4 Dec 1995 23:11:14 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 4 Dec 1995 23:11:14 -0500 X-Authentication-Warning: seusa.sumitomo.com: Host localhost didn't use HELO protocol To: ipsec@ans.net Subject: A question on SPI name space. Date: Mon, 04 Dec 95 20:11:07 -0800 From: Shin & Hi, I have a question on SPI name space. Do AH and ESP share a same SPI name space, or do AH and ESP have separate SPI name spaces? For example, if a packet has a AH and a ESP, should/can SPI of the AH and SPI of the ESP be the same value? Thank you. ---------------------------------------------------------------------- Shin Yoshida (JIS: 吉田真一) Communications & Software Research Phone: 408-737-8517 Sumitomo Electric U.S.A., Inc. FAX: 408-737-0134 ---------------------------------------------------------------------- From ipsec-request@ans.net Tue Dec 5 04:36:14 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20241 (5.65c/IDA-1.4.4 for ); Mon, 4 Dec 1995 23:42:33 -0500 Received: by interlock.ans.net id AA17374 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 4 Dec 1995 23:32:07 -0500 Message-Id: <199512050432.AA17374@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 4 Dec 1995 23:32:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 4 Dec 1995 23:32:07 -0500 Date: Mon, 4 Dec 1995 22:36:14 -0600 (CST) From: "Peter M. B. Mokros" To: ipsec@ans.net Subject: Mailing lists Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please subscribe me and/or reply with the mailing lists offered if more than one. If this inadvertantly gets mailed as a submission to the mailing list, please accept my apologies. Pete. ============================================================================== Peter Markus Bernhardt Mokros pmokros@math.macalstr.edu (NeXT Mail) Macalester College pmokros@macalstr.edu 1600 Grand Avenue http://www.math.macalstr.edu/~pmokros St. Paul, MN 55105-1899 Bigelow 357 // 612.696.7103 "Change is the only universal constant." -James Burke From ipsec-request@ans.net Tue Dec 5 05:16:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA21128 (5.65c/IDA-1.4.4 for ); Tue, 5 Dec 1995 00:24:51 -0500 Received: by interlock.ans.net id AA18371 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 5 Dec 1995 00:16:41 -0500 Message-Id: <199512050516.AA18371@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 5 Dec 1995 00:16:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 5 Dec 1995 00:16:41 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Shin & Cc: ipsec@ans.net Subject: Re: A question on SPI name space. In-Reply-To: Your message of "Mon, 04 Dec 1995 20:11:07 PST." <199512050411.AA16995@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 05 Dec 1995 00:16:33 -0500 From: "Perry E. Metzger" Shin & writes: > I have a question on SPI name space. > Do AH and ESP share a same SPI name space, or do AH and ESP > have separate SPI name spaces? An interesting question. At first, I thought that since the destination assigns the SPIs that it would make no difference, but I realized afterwards that that is not the case -- implementations might want to be able to key based only on destination and SPI. I'd therefore say that we ought to make it clear in our documents that the SPI space is shared. .pm From ipsec-request@ans.net Tue Dec 5 21:41:37 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20974 (5.65c/IDA-1.4.4 for ); Tue, 5 Dec 1995 13:19:42 -0500 Received: by interlock.ans.net id AA09629 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 5 Dec 1995 12:58:13 -0500 Message-Id: <199512051758.AA09629@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 5 Dec 1995 12:58:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 5 Dec 1995 12:58:13 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 5 Dec 1995 12:58:13 -0500 X-Sender: karn@servo.qualcomm.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Dec 1995 13:41:37 -0800 To: Bill Sommerfeld , Phil Karn From: Phil Karn Subject: Re: WG Last Call for SKIP I-D Cc: ashar@osmosys.incog.com (Ashar Aziz), ipsec@ans.net At 06:31 PM 11/30/95 -0500, Bill Sommerfeld wrote: >Assuming that the modular exponentiation involved in the DH exchange >takes 1 CPU second, a system in regular communication with 1000 other >systems would then wind up spending just under 30% of its time doing >modular exponentiations. Well, if that 30% would otherwise be idle time, why not recompute shared secrets that often? You can vary the recompute time based on how much idle time you have, with perhaps some established minimum and maximum rate. I've always liked Hilarie Orman's saying: encrypt until it hurts, then maybe back off a little. Phil From ipsec-request@ans.net Tue Dec 5 22:00:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA18690 (5.65c/IDA-1.4.4 for ); Tue, 5 Dec 1995 13:30:25 -0500 Received: by interlock.ans.net id AA10048 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 5 Dec 1995 13:16:23 -0500 Message-Id: <199512051816.AA10048@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 5 Dec 1995 13:16:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 5 Dec 1995 13:16:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 5 Dec 1995 13:16:23 -0500 X-Sender: karn@servo.qualcomm.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Dec 1995 14:00:16 -0800 To: Shin & From: Phil Karn Subject: Re: A question on SPI name space. Cc: ipsec@ans.net At 08:11 PM 12/4/95 -0800, you wrote: >Hi, > >I have a question on SPI name space. >Do AH and ESP share a same SPI name space, or do AH and ESP >have separate SPI name spaces? > >For example, if a packet has a AH and a ESP, should/can SPI of the AH >and SPI of the ESP be the same value? Because AH and ESP have their own protocol IDs, there is never any confusion as to whether a given SPI refers to AH or ESP. So you can use the same SPI for both AH and ESP if you like. Or you can use different SPIs, it will work either way. Phil From ipsec-request@ans.net Thu Dec 7 14:49:14 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17596 (5.65c/IDA-1.4.4 for ); Thu, 7 Dec 1995 10:03:38 -0500 Received: by interlock.ans.net id AA29276 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 7 Dec 1995 09:49:25 -0500 Message-Id: <199512071449.AA29276@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 7 Dec 1995 09:49:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 7 Dec 1995 09:49:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 7 Dec 1995 09:49:25 -0500 Date: Thu, 7 Dec 1995 07:49:14 -0700 From: Oliver Spatscheck To: ipsec@ans.net, spatsch@cs.arizona.edu Subject: Multiple Transforms per SPI, user to user keying in Photuris Content-Length: 1139 After the ipsec meeting yesterday I had a discussion with Bill Simpson and Angelos D. Keromytis about the Photuris draft. I raised the following two topics which I thought might be of interest to the ipsec community. 1. Multiple Attribute Choices in the Identity message. We agreed that it would be a good idea to limit the number of attributes in the identity message to one AH attribute and one ESP attribute for one SPI. The reasons are a clearer design and the fact that the session key used by multiple attribute choices would be the same. If somebody wants to use more then one ESP transform s/he should negotiate multiple SPIs and apply a set of SPIs to each package. 2. Identification for user to user keying There should be a way to determine both user on the responder side during the key exchange. Only then it is possible to establish user to user keying with one key exchange. This can easily be accomplished by defining an new Identity-Choice which contains the identity of both user in the Identification field. Another approach would be to add a second identification field to the identification message. Oliver From ipsec-request@ans.net Fri Dec 8 08:01:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA21428 (5.65c/IDA-1.4.4 for ); Fri, 8 Dec 1995 13:19:44 -0500 Received: by interlock.ans.net id AA03792 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 8 Dec 1995 13:01:48 -0500 Message-Id: <199512081801.AA03792@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 8 Dec 1995 13:01:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 8 Dec 1995 13:01:48 -0500 Date: Fri, 08 Dec 1995 13:01:21 EST From: gbnwbg2b@ibmmail.com To: ipsec@ans.net X-Sender-Info: THATCHER,D. Department: ITD Extension : 4277 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I have recently read mail from a mail-list that suggested that this email address could be used to get further info about tcp/ip. If this is a mail-list then would you advise me how to subscribe, please? If this is not a mail-list then please tell me what this email address is used for. Thanks, Darren Thatcher gbnwbg2b@ibmmail.com From ipsec-request@ans.net Sat Dec 9 03:00:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20289 (5.65c/IDA-1.4.4 for ); Fri, 8 Dec 1995 22:13:48 -0500 Received: by interlock.ans.net id AA17746 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 8 Dec 1995 22:01:42 -0500 Message-Id: <199512090301.AA17746@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 8 Dec 1995 22:01:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 8 Dec 1995 22:01:42 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 8 Dec 1995 22:01:42 -0500 Date: Fri, 8 Dec 1995 22:00:36 -0500 From: kermit@soscorp.com (Angelos D Keromytis) To: ipsec@ans.net Subject: MD4 I suggest MD4 be removed from the attributes list in the Photuris document; it's broken, so no point supporting it. -Angelos From ipsec-request@ans.net Sun Dec 10 22:02:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20156 (5.65c/IDA-1.4.4 for ); Sun, 10 Dec 1995 17:17:32 -0500 Received: by interlock.ans.net id AA07863 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 10 Dec 1995 17:02:57 -0500 Message-Id: <199512102202.AA07863@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 10 Dec 1995 17:02:57 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 10 Dec 1995 17:02:57 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: kermit@soscorp.com (Angelos D Keromytis) Cc: ipsec@ans.net Subject: Re: MD4 In-Reply-To: Your message of "Fri, 08 Dec 1995 22:00:36 EST." <199512090301.AA17746@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Dec 1995 17:02:48 -0500 From: "Perry E. Metzger" Angelos D Keromytis writes: > I suggest MD4 be removed from the attributes list in the Photuris document; > it's broken, so no point supporting it. Probably reasonable. Lets not encourage using bad algorithms. .pm From ipsec-request@ans.net Mon Dec 11 04:40:46 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17609 (5.65c/IDA-1.4.4 for ); Sun, 10 Dec 1995 23:55:15 -0500 Received: by interlock.ans.net id AA11632 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 10 Dec 1995 23:40:49 -0500 Message-Id: <199512110440.AA11632@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 10 Dec 1995 23:40:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 10 Dec 1995 23:40:49 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: ipsec@ans.net Subject: Matt Blaze: Paul Kocher's timing attack Date: Sun, 10 Dec 1995 23:40:46 -0500 From: "Perry E. Metzger" The attack in question is quite general and probably works for both Photuris and SKIP -- both should be changed around in the light of Kocher's attack. [Rumor has it, by the way, that the attack works on several NSA sponsored crypto systems like protocols using Capstone chips/Fortezza cards] Perry ------- Forwarded Message To: cypherpunks@toad.com Subject: Paul Kocher's timing attack Date: Sun, 10 Dec 1995 22:12:21 -0500 From: Matt Blaze Paul Kocher's brutally clever timing attack against on-line implementations of RSA, DSA and fixed-exponent Diffie-Hellman is reported on page A1 of Monday's New York Times ("Secure Digital Transactions Just Got a Little Less Secure" by John Markoff). The attack requires only a few thousand ciphertext samples and works against most implementations of public-key cryptosystems in which the attacker can measure accurately the target's computation time for each sample. I think Kocher's paper is online somewhere; I'll post the URL when I find it. - -matt ------- End of Forwarded Message From ipsec-request@ans.net Mon Dec 11 14:40:24 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17578 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 09:56:33 -0500 Received: by interlock.ans.net id AA19498 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 09:40:29 -0500 Message-Id: <199512111440.AA19498@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 09:40:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 09:40:29 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: ipsec@ans.net Subject: John Lull: Re: Paul Kocher's timing attack Date: Mon, 11 Dec 1995 09:40:24 -0500 From: "Perry E. Metzger" ------- Forwarded Message From: lull@acm.org (John Lull) To: cypherpunks@toad.com Subject: Re: Paul Kocher's timing attack Date: Mon, 11 Dec 1995 04:46:05 GMT Matt Blaze wrote: > I think Kocher's paper is online somewhere; I'll post the URL > when I find it. ftp://ftp.cryptography.com/pub/kocher_timing_attack.ps ftp://ftp.cryptography.com/pub/kocher_timing_attack.ps.gz ------- End of Forwarded Message From ipsec-request@ans.net Mon Dec 11 15:25:55 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA21794 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 10:55:47 -0500 Received: by interlock.ans.net id AA21362 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 10:42:52 -0500 Message-Id: <199512111542.AA21362@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 10:42:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 10:42:52 -0500 Date: Mon, 11 Dec 95 15:25:55 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: MD4 > From: kermit@soscorp.com (Angelos D Keromytis) > I suggest MD4 be removed from the attributes list in the Photuris document; > it's broken, so no point supporting it. > OK. Thanks. 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 Mon Dec 11 14:39:18 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20777 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 10:55:48 -0500 Received: by interlock.ans.net id AA21343 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 10:42:45 -0500 Message-Id: <199512111542.AA21343@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 10:42:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 10:42:45 -0500 Date: Mon, 11 Dec 95 14:39:18 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: Multiple Transforms per SPI > From: Oliver Spatscheck > We agreed that it would be a good idea to limit the > number of attributes in the identity message > to one AH attribute and one ESP attribute for one SPI. > The reasons are a clearer design and the fact that the > session key used by multiple attribute choices would be the > same. Yes. I will add explicit language to the draft. In my version of the code, I simply had a while loop around the SPI attribute list, and perform the listed attributes in order. So, it was not a problem in implementation. But it did cause confusion, and would be a worthwhile simplification. > If somebody wants to use more then one ESP transform s/he > should negotiate multiple SPIs and apply a set of SPIs to > each package. > Yes. This moves the problem back to the IP Protocol level (looping on next header). We also need some wording as to interpretation of ordering of the attributes. If the AH attribute comes before the ESP attribute, in my code this will put the AH _inside_ the ESP. Some folks have stated that the AH should always be _outside_ the ESP. The current Security Architecture allows both orders. 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 Mon Dec 11 15:27:33 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17448 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 10:55:48 -0500 Received: by interlock.ans.net id AA21394 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 10:43:54 -0500 Message-Id: <199512111543.AA21394@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 10:43:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 10:43:54 -0500 Date: Mon, 11 Dec 95 15:27:33 GMT From: "William Allen Simpson" To: ipsec@ans.net Cc: Matt Blaze Subject: Re: Matt Blaze: Paul Kocher's timing attack > From: "Perry E. Metzger" > ------- Forwarded Message > The attack requires only a few thousand ciphertext samples and works > against most implementations of public-key cryptosystems in which > the attacker can measure accurately the target's computation time for > each sample. > This will be fixed in Photuris by dithering the return time of the Identification_Message. A few extra milliseconds on top of a second won't be a problem. Thanks for bringing this up! 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 Mon Dec 11 15:00:07 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20011 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 10:55:49 -0500 Received: by interlock.ans.net id AA21350 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 10:42:50 -0500 Message-Id: <199512111542.AA21350@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 10:42:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 10:42:50 -0500 Date: Mon, 11 Dec 95 15:00:07 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Re: user to user keying in Photuris > From: Oliver Spatscheck > There should be a way to determine both user on the responder > side during the key exchange. Only then it is possible > to establish user to user keying with one key exchange. > > This can easily be accomplished by defining an new Identity-Choice > which contains the identity of both user in the Identification > field. > I like this, it is very elegant. > Another approach would be to add a second identification field > to the identification message. > I think this is overkill, by adding a field for all messages which would only rarely be used. And it complicates the protocol. Bill Sommerfeld suggested using the currently MBZ Responder Cookie in the Cookie_Request, to contain the Initiator Cookie from a previous Photuris Exchange. This is exceedingly clever! Bill also had some ideas on how to specify particular application processes. This is emphatically outside the scope of the Photuris base protocol. I had asked Bill over a month ago to write up the process oriented keying as a separate draft. I recommend that he join with Oliver as authors to include both ideas. 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 Mon Dec 11 15:39:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA21814 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 10:55:54 -0500 Received: by interlock.ans.net id AA21222 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 10:40:07 -0500 Message-Id: <199512111540.AA21222@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 11 Dec 1995 10:40:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 10:40:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 10:40:07 -0500 To: "Perry E. Metzger" Cc: ipsec@ans.net Subject: Re: Matt Blaze: Paul Kocher's timing attack In-Reply-To: Your message of "Sun, 10 Dec 1995 23:40:46 EST." <199512110440.AA11632@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <14353.818696365.1@fearless.soscorp.com> Date: Mon, 11 Dec 1995 10:39:26 -0500 From: "Angelos D. Keromytis" In message <199512110440.AA11632@interlock.ans.net>, "Perry E. Metzger" writes: > >The attack in question is quite general and probably works for both >Photuris and SKIP -- both should be changed around in the light of >Kocher's attack. > Most certainly works for both. One solution (in Photuris at least) is to always wait until the closest x second multiple (i'd say x = 5) after the exponentation has finished. So, if exponentation starts at time Y and finishes at Y + 7, the packet should be transmitted no sooner than Y + 10. Essentially, packet transmission delay (the time between receiving an EXCHANGE_RESPONSE and sending an IDENTIFICATION) should be independent from the actual exponentation time. Note that the attack only works on the exchange mentioned above. -Angelos PS. The paper implies that the same attack can be pulled on symetric cryptosystems as well, but no analysis is done. From ipsec-request@ans.net Mon Dec 11 15:39:15 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19243 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 12:53:20 -0500 Received: by interlock.ans.net id AA25992 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 12:37:33 -0500 Message-Id: <199512111737.AA25992@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 12:37:33 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 12:37:33 -0500 Date: Mon, 11 Dec 95 15:39:15 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: Photuris meeting discussions Because we were not allotted enough time to adequately discuss the Photuris points during the IPSec meetings, a number of lunch, dinner, hallway, and terminal room BOFs occurred. Here is a synopsis of the results: 1) The burgeoning security analysis is getting in the way of the reading for implementors, and needs to be in a separate document. This has the advantage that new progress in the field can be documented without republishing the main Photuris specification. Because of her extensive textual contributions to the Photuris draft, Hilary Orman has been asked to join with us in co-authoring the separate draft. 2) The user-oriented keying has also been moved to a separate draft. As noted in an earlier message, I have asked both Sommerfeld and Spatscheck to combine their ideas. 3) It is becoming clear that we need an API draft which lists minimum application and kernel requirements for support of user-oriented keying. This could be based on the current IPv6 MacDonald draft for a starting point. No consensus was reached on details, except that it should not delay progress of the Photuris draft. 4) Bellovin suggests that the prose section before each pair of messages needs to be made more stylized, re-written as pseudo-code, as in the IETF tradition of TCP, RIP, etc. Also, the Attributes and other field sections need more repetition and more cross-referencing to avoid forgetfulness. While this is a matter of style (I prefer to remove repetition), there is no substantive reason (other than my fingers, and the amount of extra pages) why it cannot be done. 5) The Offered-Attributes are unclear when one or more attributes can be used for more than purpose. This principly applies to such things which are not well specified, such as the label, the OUI, and other multipurpose attributes. Also, having more than one AH and/or ESP transform for a single SPI is not well defined. The solution is two-fold. Each Attribute number will be used for only one purpose, which will be included in its name. This means that there will be 3 OUI Attributes, for example. Offered-Attributes will be split into 3 lists, Identification-Attributes, Authentication-Attributes, and Encryption-Attributes; the lists will be separated by new AH and ESP "header attributes". 6) The mandatory attributes need to be specified earlier than the appendix. The '*' in the Appendix isn't visually distinguishable from the '+'. 7) More Numbered Headers to provide better cross-referencing. 8) A complete Example including full-sized cookies, public-values, and hash results to help in debugging. This is a lot of work.... If there are other topics I missed, please remind me. I don't have the Photuris discussion list at hand. I assume that will be in the minutes. As this is a major reorganization, Phil and I will be busy on it for several days. Please have patience. 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 Mon Dec 11 08:29:32 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17566 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 13:40:06 -0500 Received: by interlock.ans.net id AA28029 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 13:29:47 -0500 Message-Id: <199512111829.AA28029@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 11 Dec 1995 13:29:47 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 13:29:47 -0500 From: rivest@theory.lcs.mit.edu (Ron Rivest) Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 13:29:47 -0500 Date: Mon, 11 Dec 95 13:29:32 EST To: ipsec@ans.net Subject: Paul Kocher's timing attack Bill Simpson says, regarding Kocher's timing attack: This will be fixed in Photuris by dithering the return time of the Identification_Message. A few extra milliseconds on top of a second won't be a problem. ... This helps to reduce the leakage of key information, but does not eliminate it. The best thing to do is to ensure that the public-key computation time is CONSTANT, independent of the message being encrypted (or signed). I don't think the Photuris specs should specify dithering, since it a good implementation will have fixed (i.e. constant) timings for the cryptographic operations. The Photuris specs should mention this issue and recommend that the implementations should have fixed-time operations to avoid vulnerability to Kocher's timing attack. (As a side note, I suspect that this sort of attack is probably extremely difficult to mount in an Internet environment, due to packet-routing timing variabilities. However, it's wise to be careful...) Ron Rivest From ipsec-request@ans.net Mon Dec 11 18:36:17 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA20131 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 13:43:40 -0500 Received: by interlock.ans.net id AA28208 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 13:36:39 -0500 Message-Id: <199512111836.AA28208@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 13:36:39 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 13:36:39 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: "William Allen Simpson" Cc: ipsec@ans.net, Matt Blaze Subject: Re: Matt Blaze: Paul Kocher's timing attack In-Reply-To: Your message of "Mon, 11 Dec 1995 15:27:33 GMT." <199512111543.AA21394@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Dec 1995 13:36:17 -0500 From: "Perry E. Metzger" "William Allen Simpson" writes: > > From: "Perry E. Metzger" > > ------- Forwarded Message > > The attack requires only a few thousand ciphertext samples and works > > against most implementations of public-key cryptosystems in which > > the attacker can measure accurately the target's computation time for > > each sample. > > > This will be fixed in Photuris by dithering the return time of the > Identification_Message. A few extra milliseconds on top of a second > won't be a problem. Thanks for bringing this up! Actually, it might be better to determine the length of time the maximal computation takes and to assure (by checking the time before and after the computation, and then sleeping for a moment) that all computations appear to take the same amount of time to an outsider. Perry From ipsec-request@ans.net Mon Dec 11 19:46:06 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA19263 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 15:00:55 -0500 Received: by interlock.ans.net id AA00709 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 14:46:30 -0500 Message-Id: <199512111946.AA00709@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 14:46:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 14:46:30 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: rivest@theory.lcs.mit.edu (Ron Rivest) Cc: ipsec@ans.net Subject: Re: Paul Kocher's timing attack In-Reply-To: Your message of "Mon, 11 Dec 1995 13:29:32 EST." <199512111829.AA28029@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Dec 1995 14:46:06 -0500 From: "Perry E. Metzger" Ron Rivest writes: > (As a side note, I suspect that this sort of attack is probably extremely > difficult to mount in an Internet environment, due to packet-routing > timing variabilities. I disagree. NTP has demonstrated that you can calculate packet traversal and dispersion times to great accuracy. Do enough timings and packet measurements and you can probably get plenty of statistical fodder for the cracking engine. > However, it's wise to be careful...) Exactly. Perry From ipsec-request@ans.net Mon Dec 11 20:17:03 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA17585 (5.65c/IDA-1.4.4 for ); Mon, 11 Dec 1995 15:30:57 -0500 Received: by interlock.ans.net id AA01906 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 11 Dec 1995 15:17:11 -0500 Message-Id: <199512112017.AA01906@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 11 Dec 1995 15:17:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 11 Dec 1995 15:17:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 11 Dec 1995 15:17:11 -0500 Date: Mon, 11 Dec 95 15:17:03 -0500 Sender: rivest@theory.lcs.mit.edu From: Ron Rivest X-Mailer: Mozilla 1.1N (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 Newsgroups: sci.crypt To: ipsec@ans.net Subject: Re: Announce: Timing cryptanalysis of RSA, DH, DSS References: <4agcf3$enr@ixnews2.ix.netcom.com> X-Url: news:4agcf3$enr@ixnews2.ix.netcom.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The simplest way to defeat Kocher's timing attack is to ensure that the cryptographic computations take an amount of time that does not depend on the data being operated on. For example, for RSA it suffices to ensure that a modular multiplication always takes the same amount of time, independent of the operands. A second way to defeat Kocher's attack is to use blinding: you "blind" the data beforehand, perform the cryptographic computation, and then unblind afterwards. For RSA, this is quite simple to do. (The blinding and unblinding operations still need to take a fixed amount of time.) This doesn't give a fixed overall computation time, but the computation time is then a random variable that is independent of the operands. - ============================================================================== Ronald L. Rivest 617-253-5880 617-253-8682(Fax) rivest@theory.lcs.mit.edu ============================================================================== From ipsec-request@ans.net Tue Dec 12 23:45:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11609 (5.65c/IDA-1.4.4 for ); Tue, 12 Dec 1995 18:52:46 -0500 Received: by interlock.ans.net id AA05728 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 12 Dec 1995 18:45:44 -0500 Message-Id: <199512122345.AA05728@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 12 Dec 1995 18:45:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 12 Dec 1995 18:45:44 -0500 Date: Tue, 12 Dec 1995 15:45:36 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: SPIs, etc. Folks, My vague recollection of the NRL implementation is that it might NOT support having the same SPI for an AH session as for an ESP session for a given destination address. I don't currently have access to the sources and I could be entirely mistaken on this. There is no particular reason that this can't be fixed in some future revisiion of the NRL software and I don't think it would be hard to fix. A change in getassocbyspi() is about all that would be required because the caller of getassocbyspi() does know whether an ESP association or an AH association is being sought. Phil Karn is right that the SPI number spaces should be separate for AH and ESP because they are different protocols. All are correct that the current RFCs do NOT make this point sufficiently clear. I intend to fix this before Draft Standard. If I don't fix them when I put out new I-Ds on 1825-1827, a gentle reminder to me that this needs fixing and why it needs to be fixed how would be entirely proper. With my recent relocation, many of my notes on needed fixes/clarifications for the documents are lost to me. My access to the ipsec list remains erratic, in part due to matters beyond the control of anyone on my end of the list. Stuff that one needs me to see should Bcc: me in addition to the list to be safe. By the way, there is a plan to rehost the ipsec list onto a system at a different organisation (the new system will be running MajorDomo with MMDF), but that will be implemented in January at the earliest. Ran rja@cisco.com From ipsec-request@ans.net Wed Dec 13 03:09:16 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13063 (5.65c/IDA-1.4.4 for ); Tue, 12 Dec 1995 22:27:02 -0500 Received: by interlock.ans.net id AA08450 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 12 Dec 1995 22:09:27 -0500 Message-Id: <199512130309.AA08450@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 12 Dec 1995 22:09:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 12 Dec 1995 22:09:27 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: SPIs, etc. In-Reply-To: Your message of "Tue, 12 Dec 1995 15:45:36 PST." <199512122345.AA05728@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Tue, 12 Dec 1995 22:09:16 -0500 From: "Perry E. Metzger" Ran Atkinson writes: > My vague recollection of the NRL implementation is that it might NOT > support having the same SPI for an AH session as for an ESP session > for a given destination address. I don't currently have access to the > sources and I could be entirely mistaken on this. Others have mentioned their systems have similar problems. I know you can fix the NRL one, but I think it is harmless and probably better to say that the name space is shared. If it isn't, ALL implementations must support having split namespace, and that could be a problem. Perry From ipsec-request@ans.net Wed Dec 13 03:45:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11820 (5.65c/IDA-1.4.4 for ); Tue, 12 Dec 1995 22:50:51 -0500 Received: by interlock.ans.net id AA09051 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 12 Dec 1995 22:45:29 -0500 Message-Id: <199512130345.AA09051@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 12 Dec 1995 22:45:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 12 Dec 1995 22:45:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 12 Dec 1995 22:45:29 -0500 Date: Tue, 12 Dec 1995 20:45:20 -0700 From: Hilarie Orman To: ipsec@ans.net Subject: URLs The web page where I've been trying to keep useful things about the IPSEC WG is at http://www.cs.arizona.edu/xkernel/www/ipsec/ipsec.html From there you can get to URL's for postscript form of slides that I used at the Dec. 6 WG meeting and a pointer to our UofA research group's paper on efficient implmentation of elliptic curve groups. From ipsec-request@ans.net Wed Dec 13 13:35:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11891 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 09:28:04 -0500 Received: by interlock.ans.net id AA16935 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 09:04:02 -0500 Message-Id: <199512131404.AA16935@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 09:04:02 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 09:04:02 -0500 Date: Wed, 13 Dec 95 13:35:21 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: ICMP Security Failures Well, as I said in my earlier message, adding all that state machine (as in TCP) is a lot of typing and reorganization. Put in 20 hours already, and the end is not in sight! Meanwhile, could you folks review the icmp-fail-00 draft? It applies to all security implementations. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Dec 13 13:35:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10594 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 11:07:19 -0500 Message-Id: <199512131607.AA10594@ftp.ans.net> Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@ftp.ans.net); Wed, 13 Dec 1995 10:54:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 10:54:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 10:54:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Wed, 13 Dec 1995 10:54:40 -0500 Date: Wed, 13 Dec 95 13:35:21 GMT From: "William Allen Simpson" To: ipsec@ans.net Subject: ICMP Security Failures Well, as I said in my earlier message, adding all that state machine (as in TCP) is a lot of typing and reorganization. Put in 20 hours already, and the end is not in sight! Meanwhile, could you folks review the icmp-fail-00 draft? It applies to all security implementations. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From ipsec-request@ans.net Wed Dec 13 16:32:47 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11682 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 11:52:33 -0500 Received: by interlock.ans.net id AA03477 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 11:32:53 -0500 Message-Id: <199512131632.AA03477@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 11:32:53 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 11:32:53 -0500 Date: Wed, 13 Dec 1995 08:32:47 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: correction on SPIs It turns out that my memory is not to be trusted (not entirely surprising :-). The NRL software does indeed have separate number spaces for SPIs and so an AH session and an ESP session to the same destination with the same SPI value will indeed be different Security Associations in the Key Engine. IMHO, this is how all implementations ought to work. Unless there is WG consensus to the contrary, I intend to make this separation very clearly required in the revision to RFC-1825 when I edit it in a few months. This should not be hard to implement and makes things much simpler for the key mgmt mechanisms. Ran rja@cisco.com From ipsec-request@ans.net Wed Dec 13 19:34:18 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11549 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 15:00:51 -0500 Received: by interlock.ans.net id AA08264 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 14:34:50 -0500 Message-Id: <199512131934.AA08264@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 13 Dec 1995 14:34:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 14:34:50 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 14:34:50 -0500 Date: Wed, 13 Dec 1995 12:34:18 -0700 From: Hilarie Orman To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199512131632.AA03477@interlock.ans.net> Subject: Re: correction on SPIs Could you be really specific about this, do you mean that we need a triple to define a security association, i.e. -> security association ??? That would be quite surprising. From ipsec-request@ans.net Wed Dec 13 19:44:41 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11875 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 15:16:03 -0500 Received: by interlock.ans.net id AA08548 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 14:44:46 -0500 Message-Id: <199512131944.AA08548@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 14:44:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 14:44:46 -0500 Date: Wed, 13 Dec 1995 11:44:41 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: Re: correction on SPIs % Could you be really specific about this, do you mean that we need a triple % to define a security association, i.e. % % -> security association Hilarie, It is an implementation detail whether a triple is needed or not. If an implementation has separate storage for AH Security Associations and ESP Security Associations, then the triple is not needed. If an implementation has a single shared store for all Security Associations (ESP, AH, RIP, OSPF, whatever), then a triple might be needed within that implementation in order to locate the correct SA. The NRL implementation of the Key Engine is an example of a common store for all sorts of Security Associations (including routing protocol authentication, not just ESP or AH). The point here is that if I use (SPI =N, Dest Addr = Foo) for an AH security association, I can (if I wish) still use (SPI =N, Dest Addr = Foo) for a completely distinct ESP security association. It is NOT the case that a single Security Association can include both AH and ESP. It is the case that an AH security association might be used in addition to an ESP security association for some packet headed for some destination (so there is no loss of capability in the previous sentence). This is one of several areas in RFC-1825 that is not clearly written. Ran rja@cisco.com From ipsec-request@ans.net Wed Dec 13 10:06:18 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13210 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 15:31:06 -0500 Received: by interlock.ans.net id AA09239 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 15:06:37 -0500 Message-Id: <199512132006.AA09239@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 15:06:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 15:06:37 -0500 Date: Wed, 13 Dec 95 15:06:18 EST From: mjs@tycho.ncsc.mil (Mark J. Schertler) To: ipsec@ans.net Subject: Re: correction on SPIs Cc: rja@cisco.com, sds@tycho.ncsc.mil Ran Atkinson said: > > > It turns out that my memory is not to be trusted (not entirely surprising :-). > > The NRL software does indeed have separate number spaces for SPIs and so > an AH session and an ESP session to the same destination with the same > SPI value will indeed be different Security Associations in the Key > Engine. > > IMHO, this is how all implementations ought to work. Unless there is > WG consensus to the contrary, I intend to make this separation > very clearly required in the revision to RFC-1825 when I edit it > in a few months. This should not be hard to implement and makes things > much simpler for the key mgmt mechanisms. > > Ran > rja@cisco.com > Ran, Requiring separate SPIs space for ESP and AH seems to break both the ISAKMP and Photuris model of using a single SPI to reference the complete set of protections (e.g. both ESP and AH) to be applied to a packet. The result of an ISAKMP or Photuris negotiation is a single SPI. Mark From ipsec-request@ans.net Wed Dec 13 20:27:42 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10674 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 15:42:22 -0500 Received: by interlock.ans.net id AA09791 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 15:27:48 -0500 Message-Id: <199512132027.AA09791@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 15:27:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 15:27:48 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: correction on SPIs In-Reply-To: Your message of "Wed, 13 Dec 1995 08:32:47 PST." <199512131632.AA03477@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 13 Dec 1995 15:27:42 -0500 From: "Perry E. Metzger" Ran Atkinson writes: > The NRL software does indeed have separate number spaces for SPIs and so > an AH session and an ESP session to the same destination with the same > SPI value will indeed be different Security Associations in the Key > Engine. This will also require, by the way, that the key management daemon be congnisant of the distinction between AH and ESP SPIs. Not necessarily horrid, all things considered, but again, another little nit to consider. From ipsec-request@ans.net Wed Dec 13 14:41:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12983 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 15:42:40 -0500 Received: by interlock.ans.net id AA10277 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 15:39:07 -0500 Message-Id: <199512132039.AA10277@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 15:39:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 15:39:07 -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-skip-05.txt Date: Wed, 13 Dec 95 09:41:40 -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 IP Security Protocol Working Group of the IETF. Title : Simple Key-Management For Internet Protocols (SKIP) Author(s) : A. Aziz Filename : draft-ietf-ipsec-skip-05.txt Pages : 55 Date : 12/12/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 (for example, 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. SKIP has been designed to work with the IP Security Protocols AH and ESP [8,9,10] which are specified for both IPv4 and IPv6. 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-skip-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-05.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-skip-05.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: <19951212154628.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951212154628.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Wed Dec 13 20:31:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13244 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 15:43:24 -0500 Received: by interlock.ans.net id AA09971 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 15:31:41 -0500 Message-Id: <199512132031.AA09971@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 15:31:41 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 15:31:41 -0500 Date: Wed, 13 Dec 1995 12:31:36 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: Re: correction on SPIs % This will also require, by the way, that the key management daemon be % congnisant of the distinction between AH and ESP SPIs. Not necessarily % horrid, all things considered, but again, another little nit to % consider. If the key mgmt mechanism doesn't already understand this difference, then it already has much bigger problems, IMHO. Ran rja@cisco.com From ipsec-request@ans.net Wed Dec 13 20:46:37 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12997 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 15:48:15 -0500 Received: by interlock.ans.net id AA10644 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 15:46:12 -0500 Message-Id: <199512132046.AA10644@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 13 Dec 1995 15:46:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 13 Dec 1995 15:46:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 13 Dec 1995 15:46:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 15:46:12 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 15:46:12 -0500 Date: Wed, 13 Dec 1995 15:46:37 -0500 From: pau@watson.ibm.com Subject: RE: correction on SPIs To: rja@cisco.com Cc: ipsec@ans.net Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: h2jZOgVMMQYT3C6Nj6sibg== Ran, this is how I implemented it also. A SPI value can refer to different keys, depending on whether this API is for ESP or AH. My code does allow different SPI values for ESP and AH in the same message. However, I don't see any real need for this flexibility. Pau-Chen > From @yktvmv.watson.ibm.com:postmaster@watson.vnet.ibm.com Wed Dec 13 13:41:23 1995 > Message-Id: <199512131632.AA03477@interlock.ans.net> > Date: Wed, 13 Dec 1995 08:32:47 -0800 > From: Ran Atkinson > To: ipsec@ans.net > Subject: correction on SPIs > Content-Length: 635 > Status: RO > > > It turns out that my memory is not to be trusted (not entirely surprising :-). > > The NRL software does indeed have separate number spaces for SPIs and so > an AH session and an ESP session to the same destination with the same > SPI value will indeed be different Security Associations in the Key > Engine. > > IMHO, this is how all implementations ought to work. Unless there is > WG consensus to the contrary, I intend to make this separation > very clearly required in the revision to RFC-1825 when I edit it > in a few months. This should not be hard to implement and makes things > much simpler for the key mgmt mechanisms. > > Ran > rja@cisco.com > ------------- End Forwarded Message ------------- ------------- End Forwarded Message ------------- From ipsec-request@ans.net Wed Dec 13 21:03:23 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12584 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 16:13:47 -0500 Received: by interlock.ans.net id AA11395 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 16:03:29 -0500 Message-Id: <199512132103.AA11395@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 13 Dec 1995 16:03:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 16:03:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 16:03:29 -0500 Date: Wed, 13 Dec 1995 14:03:23 -0700 From: Hilarie Orman To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199512131944.AA08548@interlock.ans.net> Subject: Re: correction on SPIs So, in formal terms, the triple maps to the SA. I think this should be mentioned prominently in the arch doc. Unfortunately, I had the mapping of the double to SA in mind as a firm principle in doing my implementation. From ipsec-request@ans.net Mon Dec 11 20:17:01 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13094 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 16:13:47 -0500 Received: by interlock.ans.net id AA11389 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 16:03:22 -0500 Message-Id: <199512132103.AA11389@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 16:03:22 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 16:03:22 -0500 Path: news2.acs.oakland.edu!nntp.coast.net!chi-news.cic.net!newsxfer.itd.umich.edu!news.mathworks.com!uhog.mit.edu!grapevine.lcs.mit.edu!usenet@lcs.mit.edu From: Ron Rivest Newsgroups: sci.crypt Subject: Re: Announce: Timing cryptanalysis of RSA, DH, DSS Date: 11 Dec 1995 20:17:01 GMT Organization: MIT Laboratory for Computer Science Lines: 17 References: <4agcf3$enr@ixnews2.ix.netcom.com> Nntp-Posting-Host: swan.lcs.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1N (X11; I; SunOS 4.1.4 sun4m) To: ipsec@ans.net X-Url: news:4agcf3$enr@ixnews2.ix.netcom.com The simplest way to defeat Kocher's timing attack is to ensure that the cryptographic computations take an amount of time that does not depend on the data being operated on. For example, for RSA it suffices to ensure that a modular multiplication always takes the same amount of time, independent of the operands. A second way to defeat Kocher's attack is to use blinding: you "blind" the data beforehand, perform the cryptographic computation, and then unblind afterwards. For RSA, this is quite simple to do. (The blinding and unblinding operations still need to take a fixed amount of time.) This doesn't give a fixed overall computation time, but the computation time is then a random variable that is independent of the operands. - ============================================================================== Ronald L. Rivest 617-253-5880 617-253-8682(Fax) rivest@theory.lcs.mit.edu ============================================================================== From ipsec-request@ans.net Wed Dec 13 21:15:18 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11832 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 16:22:10 -0500 Received: by interlock.ans.net id AA11905 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 16:15:38 -0500 Message-Id: <199512132115.AA11905@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Wed, 13 Dec 1995 16:15:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Wed, 13 Dec 1995 16:15:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 13 Dec 1995 16:15:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 16:15:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 16:15:38 -0500 Subject: Re: correction on SPIs To: ipsec@ans.net Date: Wed, 13 Dec 1995 16:15:18 -0500 (EST) From: "Uri Blumenthal" In-Reply-To: <199512132006.AA09239@interlock.ans.net> from "Mark J. Schertler" at Dec 13, 95 03:06:18 pm X-External-Networks: yes Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 263 In my eyes, the whole reason to have SPI's is to put all the protocols and algorithms needed to deal with the given connection, in one place. I do suggest, that there should be only one SPI space. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From ipsec-request@ans.net Wed Dec 13 21:23:37 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10566 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 16:30:19 -0500 Received: by interlock.ans.net id AA12185 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 16:23:44 -0500 Message-Id: <199512132123.AA12185@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 13 Dec 1995 16:23:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 16:23:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 16:23:44 -0500 Date: Wed, 13 Dec 1995 14:23:37 -0700 From: Hilarie Orman To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199512132031.AA09971@interlock.ans.net> Subject: Re: correction on SPIs > If the key mgmt mechanism doesn't already understand this difference, > then it already has much bigger problems, IMHO. Ran, could you elaborate on this remark? Why should not the key management essential information be restricted to identifier, number of bits of key, key? This seems like a clean way of separating key exchange from key use. From ipsec-request@ans.net Wed Dec 13 21:31:28 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12388 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 16:35:56 -0500 Received: by interlock.ans.net id AA12536 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 16:31:40 -0500 Message-Id: <199512132131.AA12536@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 16:31:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 16:31:40 -0500 Date: Wed, 13 Dec 1995 13:31:28 -0800 From: Ran Atkinson To: ho@cs.arizona.edu Subject: Re: correction on SPIs Cc: ipsec@ans.net See RFC-1825. There is ALREADY much more than just key length, key, and identifier within an IPsec Security Association. One of my issues with some of the key mgmt proposals on the table at present is that they do not specify how to indicate all of the properties of a given Security Association to both parties to that association. Ran From ipsec-request@ans.net Wed Dec 13 21:48:55 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13779 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 16:54:25 -0500 Received: by interlock.ans.net id AA13308 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 16:49:01 -0500 Message-Id: <199512132149.AA13308@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 16:49:01 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 16:49:01 -0500 Date: Wed, 13 Dec 1995 13:48:55 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: Re: correction on SPIs % In my eyes, the whole reason to have SPI's is to put all the % protocols and algorithms needed to deal with the given % connection, in one place. One can put them all in one place -- without having to share the number space such that a single (dest addr, SPI) pair refers to _2_ separate Security Associations. The goal is that one (dest addr, SPI) pair uniquely identifies the Security Association for the protocol carrying the SPI field. By the point one has an SPI to examine, one must already know which protocol is being processed. How one stores the Security Association data is an implementation matter, not a specification matter. Combining number spaces makes things MUCH harder IMHO. Consider that we have more than just AH and ESP to consider (particularly in key mgmt, which ought to be generic to moving keys between systems and not tied to AH/ESP) that we already have OSPF with MD5, RIPv2 with MD5, and a concrete proposal for RSVP with MD5. The list of protocols that have built-in cryptographic mechanisms is getting longer, not shorter. We need a generic approach that will scale. Separate number spaces has this property. Ran rja@cs.nrl.navy.mil From ipsec-request@ans.net Wed Dec 13 21:55:47 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12769 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 16:58:08 -0500 Received: by interlock.ans.net id AA13601 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 16:56:31 -0500 Message-Id: <199512132156.AA13601@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 13 Dec 1995 16:56:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 16:56:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 16:56:31 -0500 To: perry@piermont.com Cc: Ran Atkinson , ipsec@ans.net Subject: Re: correction on SPIs In-Reply-To: Your message of "Wed, 13 Dec 1995 15:27:42 EST." <199512132027.AA09791@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <15787.818891747.1@fearless.soscorp.com> Date: Wed, 13 Dec 1995 16:55:47 -0500 From: "Angelos D. Keromytis" In message <199512132027.AA09791@interlock.ans.net>, "Perry E. Metzger" writes: > >This will also require, by the way, that the key management daemon be >congnisant of the distinction between AH and ESP SPIs. Not necessarily >horrid, all things considered, but again, another little nit to >consider. Actually it simplifies a few things (see Mark's mail). -Angelos From ipsec-request@ans.net Thu Dec 14 02:43:04 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12872 (5.65c/IDA-1.4.4 for ); Wed, 13 Dec 1995 21:46:37 -0500 Received: by interlock.ans.net id AA20386 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 13 Dec 1995 21:43:10 -0500 Message-Id: <199512140243.AA20386@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 13 Dec 1995 21:43:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 13 Dec 1995 21:43:10 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 13 Dec 1995 21:43:10 -0500 Date: Wed, 13 Dec 1995 19:43:04 -0700 From: Hilarie Orman To: bsimpson@morningstar.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199512131717.AA25629@optima.cs.arizona.edu> Subject: Re: ICMP Security Failures A few things occur to me. > This document specifies ICMP messages for indicating failures when > using IP Security Protocols (AH, ESP, and Photuris). > > > Pointer Two octets. An offset into the Original Internet > Headers which locates most significant octet of the > offending SPI. Will be zero when no SPI is present. Does this apply to Photuris as of draft 08? > 2.1. Bad SPI > Indicates when a received datagram includes a Security Parameters > Index (SPI) that is invalid or has expired. "Indicates that a ... " ? (and so on through the document) > Note that in "transport-mode", the SPI indicated will be of the outer I think I get it, but I'm not familiar with the term "transport-mode". > Security Considerations > > This mechanism is amenable to use of the Internet Security Protocols > for authentication and privacy. Does this mean that the ICMP messages can be protected with AH and/or ESP? I missed that interpretation on my first several readings. > ??? I don't think that any action should be taken on non-authenticated messages, and even then, there's a distinct problem if the identities associated with the SPI's aren't identical. However, I might be missing some startup scenario where the non-authenticated messages are the only hint that will get Photuris unstuck or something. I'd recommend saying that the identities inside and out must match. Might also note that implementations are not required to send these messages. From ipsec-request@ans.net Thu Dec 14 13:33:09 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11082 (5.65c/IDA-1.4.4 for ); Thu, 14 Dec 1995 10:01:48 -0500 Received: by interlock.ans.net id AA00014 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 14 Dec 1995 09:53:38 -0500 Message-Id: <199512141453.AA00014@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 14 Dec 1995 09:53:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 14 Dec 1995 09:53:38 -0500 Date: Thu, 14 Dec 95 13:33:09 GMT From: "William Allen Simpson" To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: correction on SPIs I will admit, I am completely confused here about your "combined" or "separate" number spaces. I think that some of the folks on the list are talking past each other. Here's what Karn did (and Simpson has a slight variant): - Each SPI can be used by both AH and ESP. - AH and ESP have different keys, even when using the same SPI. - AH and ESP use different algorithms, even when using the same SPI. - AH and ESP can both be negotiated at the same time (the same exchange). So, I think of this as a "combined" number space, with orthogonal usage. Is that what you mean? I hope that this is clearer in the next Photuris draft. 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 Thu Dec 14 16:13:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13567 (5.65c/IDA-1.4.4 for ); Thu, 14 Dec 1995 11:22:14 -0500 Received: by interlock.ans.net id AA02476 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 14 Dec 1995 11:13:56 -0500 Message-Id: <199512141613.AA02476@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 14 Dec 1995 11:13:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 14 Dec 1995 11:13:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 14 Dec 1995 11:13:56 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 14 Dec 1995 11:13:56 -0500 Date: Thu, 14 Dec 1995 11:13:48 -0500 X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "William Allen Simpson" From: naganand@ftp.com (Naganand Doraswamy) Subject: Re: correction on SPIs Cc: ipsec@ans.net Bill, >Here's what Karn did (and Simpson has a slight variant): > > - Each SPI can be used by both AH and ESP. > > - AH and ESP have different keys, even when using the same SPI. > > - AH and ESP use different algorithms, even when using the same SPI. > > - AH and ESP can both be negotiated at the same time (the same exchange). > >So, I think of this as a "combined" number space, with orthogonal usage. >Is that what you mean? > If I understand what Ran said correctly, Photuris can still negotiate for SPI's and transforms as it is doing currently. However, when we build the SA we will have to identify if it is for ESP or AH. This has to be done if we are using a single name space. If we use different name spaces, then we can store the SPI's, key's, and algorithm in the respective names space (AH and ESP). --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)659-6743 (O) From ipsec-request@ans.net Thu Dec 14 22:57:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11607 (5.65c/IDA-1.4.4 for ); Thu, 14 Dec 1995 18:00:52 -0500 Received: by interlock.ans.net id AA16651 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 14 Dec 1995 17:57:40 -0500 Message-Id: <199512142257.AA16651@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 14 Dec 1995 17:57:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 14 Dec 1995 17:57:40 -0500 Date: Thu, 14 Dec 1995 14:57:36 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: WG Last Call on SKIP All, The chairs have measured consensus on the list and in private email to the chairs regarding the WG Last Call on SKIP. We find that there is not yet WG consensus that the current SKIP draft is ready to move to Proposed Standard. The SKIP editor needs to revise the draft to take into consideration comments from the meeting in Dallas, from the WG Chairs, and the Security Area Director. After that has been done and there has been adequate opportunity for WG list discussion of the revised I-D, another WG Last Call will occur. Ran rja@cisco.com From ipsec-request@ans.net Thu Dec 14 23:23:02 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14493 (5.65c/IDA-1.4.4 for ); Thu, 14 Dec 1995 18:26:44 -0500 Received: by interlock.ans.net id AA17027 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 14 Dec 1995 18:16:52 -0500 Message-Id: <199512142316.AA17027@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Thu, 14 Dec 1995 18:16:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 14 Dec 1995 18:16:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 14 Dec 1995 18:16:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 14 Dec 1995 18:16:52 -0500 Date: Thu, 14 Dec 1995 15:23:02 -0800 From: ashar@osmosys.incog.com (Ashar Aziz) To: ipsec@ans.net Subject: forward secrecy X-Sun-Charset: US-ASCII Folks, I would like to raise a few issues regarding forward secrecy that, I believe, have received insufficient discussion to date. First of all, the attack scenario that a typical "perfect forward secrecy" protocol using ephemeral Diffie-Hellman guards against has always been implicit, and not explicit. I would like to make the assumptions of this attack more explicit, and discuss other attacks of a different nature that also affect forward secrecy. The attack that an ephemeral DH exchange guards against is compromise of a long-term secret. If long-term secrets are properly guarded (e.g. tamper resist token devices, encrypted under passwords etc.) then such an attack to compromise the long-term secret is an active attack, and in cases of tamper resist hardware token devices it is an active physical attack. It is important to observe that an ephemeral Diffie-Hellman exchange needs to be efficient, (since it happens interactively in real time) and in order to be efficient the sizes of the DH parameters have to be chosen carefully. With Diffie-Hellman there is a clear tradeoff between efficiency and security. The greater the sizes of the DH parameters (exponent, modulus) the greater the security but the slower the speed of the operation. Another observation is that the DH problem, over time, becomes more tractable. Let's take as an example an ephemeral DH protocol that might have been used 10 years ago. For reasons of efficiency the modulus size for such a DH exchange would very likely have been 512 bits. Clearly now, 10 years later, it is possible to mount attacks on a 512 bit DH problem, especially for well funded adversaries. Now assume the adversary is someone like the NSA. For purposes of this discussion, this could also be the foreign equivalents of the NSA. The NSA is primarily a signals intelligence agency. If the NSA performs field operations, they are probably of a very limited nature. The same is true of the foreign equivalents of the NSA. Such agencies operate primarily using *passive* attacks. What the NSA (and their foreign equivalents) are far more likely to do is to record all cipherbits, and if necessary, store them for a few years/decades, until they can be broken. A recently disclosed case of such a passive attack revealed that the NSA saved ciphertext for 40+ years, waiting for the moment it could be broken. I would like to argue that this passive attck a more likely form of attack, especially considering signals intelligence agencies as the enemy. What the ephemeral DH exchange is doing is hardening against the active attack (I argue, a less likely scenario) while *weakening* the protocol (for practical efficiency reasons) against a passive sit-on-it-until-it-can-be-crunched form of attack. To summarize: There are two forms of attacks that pertain to forward secrecy. The active attack, and a passive time delayed attack, mountable by tenacious and well-funded adversaries. So far, the discussion on forward secrecy has focused on the active attack. The forward secrecy solution that I described on this list and presented at Dallas (pre-certified short lived Diffie-Hellman keys), in the context of SKIP, has the advantage that none of the DH operations needs to be performed in real time. They can all be precomputed. This makes it feasible to use much larger DH parameters, say 4000 bit DH exponents/modulus, than is practical today with an interactive ephemeral DH exchange. This provides much more effective hardening against a time delayed passive attack. Now, one could argue, that with lots of ephemeral DH exchanges, occurring every few minutes/hours, the enemy doesn't have to break just one DH exchange, there are many such exchanges to break. Unfortunately, the work factor of a time delayed passive attack only goes up by a small linear factor, even with many ephemeral DH exchanges. With a much larger DH exponent/modulus, the work factor goes up in a super-polynomial fashion, assuming Number Field Sieve as the best attack on classic DH. (Again taking the 512 bit DH case as an example, if the NSA can break one of these, it could also break a few thousand of these. On the other hand, breaking a single 1024 bits DH today is probably infeasible). Therefore, I argue that we need to provide hardening against *both* the active and the passive attack. The question is what attack should the protocol be better hardened against, since there is a clear tradeoff involved. If we believe that the active attack is a more likely form of attack, then frequent ephemeral DH exchanges (e.g. as in Photuris) provide a better forward secrecy solution. However, if we believe that the passive attack is more likely, then the pre-certified short lived DH keys, in conjunction with much larger DH parameters, provides a better forward secrecy solution. I hesitate to use the term "perfect", since this is an overstatement in either case. (The only way to get really perfect forward secrecy is to use a one-time pad, which is destroyed after use). [There are other issues, apart from forward secrecy, that could be considered, such as the real-time response to a large number of simultaneous connection attempts, etc., but this discussion can focus solely on forward secrecy issues.] Comments? Ashar. From ipsec-request@ans.net Thu Dec 14 23:49:51 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11976 (5.65c/IDA-1.4.4 for ); Thu, 14 Dec 1995 18:56:50 -0500 Received: by interlock.ans.net id AA17704 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 14 Dec 1995 18:49:54 -0500 Message-Id: <199512142349.AA17704@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 14 Dec 1995 18:49:54 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 14 Dec 1995 18:49:54 -0500 Date: Thu, 14 Dec 1995 15:49:51 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: Re: forward secrecy [personal commentary] I disagree with Ashar's assumptions about the threat environment. As Bob Moscowitz (Chrysler) stated at the IPsec meeting in Dallas, there is a very real and legitimate need for Perfect Forward Secrecy that SKIP does not provide. I don't find obfuscation of reality to be productive. [observation as co-chair] There was a clear explanation of what Perfect Forward Secrecy meant and why it is necessary during the Dallas IETF meeting. There was then discussion within the working group during the meeting. At the end of that discussion it was very clear that there is smooth (not rough, but smooth) consensus within the WG that Perfect Forward Secrecy remains a key management requirement of the WG. This matter has been discussed repeatedly in the past and the group has consistently reached the same consensus conclusion. Ran rja@cisco.com From ipsec-request@ans.net Fri Dec 15 01:09:26 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14468 (5.65c/IDA-1.4.4 for ); Thu, 14 Dec 1995 20:16:14 -0500 Received: by interlock.ans.net id AA18798 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 14 Dec 1995 20:09:31 -0500 Message-Id: <199512150109.AA18798@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 14 Dec 1995 20:09:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 14 Dec 1995 20:09:31 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 14 Dec 1995 20:09:31 -0500 Date: Thu, 14 Dec 1995 18:09:26 -0700 From: Hilarie Orman To: ashar@osmosys.incog.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199512142316.AA17027@interlock.ans.net> Subject: Re: forward secrecy First, a wry comment: It's difficult to fight against perfection. Maybe if SKIP had instead been named "Perfectly Stateless Keying" you'd be on more even footing. Then, three non-wry comments: While most hackers would prefer the joy of a passive attack, it would seem more fruitful to mount an active attack than a passive one, and I'm sure most operatives would agree. Modular exponentiation isn't the only group in town, and elliptic curve groups, for example, have a reduced computational cost. And there's no reason to believe that these are the only two representations that will support DH efficiently and securely. SKIP will probably be acceptable to some user communities. It's statelessness and resulting protocol simplicity are certainly pleasing. But, I don't think that the schism over the threat model is going to disappear through persuasion, so unless a third approach emerges, combining PFS and statelessness, I doubt that there will be a way to satisfy all parties. From ipsec-request@ans.net Fri Dec 15 09:33:38 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14563 (5.65c/IDA-1.4.4 for ); Fri, 15 Dec 1995 15:20:15 -0500 Received: by interlock.ans.net id AA07670 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 15 Dec 1995 15:08:23 -0500 Message-Id: <199512152008.AA07670@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 15 Dec 1995 15:08:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 15 Dec 1995 15:08:23 -0500 Date: Fri, 15 Dec 95 14:33:38 EST From: hugo@watson.ibm.com To: ho@cs.arizona.edu, ashar@osmosys.incog.com Cc: ipsec@ans.net Subject: forward secrecy: satisfying all parties Ref: Your note of Thu, 14 Dec 1995 18:09:26 -0700 (attached) Hilarie Orman writes: > > SKIP will probably be acceptable to some user communities. It's > statelessness and resulting protocol simplicity are certainly pleasing. > But, I don't think that the schism over the threat model is going to > disappear through persuasion, so unless a third approach emerges, combining > PFS and statelessness, I doubt that there will be a way to satisfy all > parties. > I believe that there is such a way. I call it SKEME and its description can be downloaded via the web or anonymous ftp from the addresses below. It shows how to "upgrade" either Photuris or SKIP to provide a full range of forward secrecy: from none to good to perfect, and all in one compact protocol. The complexity of implementation is comparable to Photuris but it can offer as a well-defined subset the functionality and stateless-ness of SKIP (in particular, see last paragraph in the "Concluding Remarks" section). Retrieve it from: http://www.research.ibm.com/xw-941f-skeme ftp://software.watson.ibm.com/pub/security/ (the ftp link will not be operational until Monday) Hugo From ipsec-request@ans.net Sat Dec 16 01:57:35 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10711 (5.65c/IDA-1.4.4 for ); Fri, 15 Dec 1995 21:05:59 -0500 Received: by interlock.ans.net id AA14236 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 15 Dec 1995 20:58:16 -0500 Message-Id: <199512160158.AA14236@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 15 Dec 1995 20:58:16 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 15 Dec 1995 20:58:16 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Hilarie Orman Cc: ipsec@ans.net Subject: Re: forward secrecy In-Reply-To: Your message of "Thu, 14 Dec 1995 18:09:26 MST." <199512150109.AA18798@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 15 Dec 1995 20:57:35 -0500 From: "Perry E. Metzger" Hilarie Orman writes: > SKIP will probably be acceptable to some user communities. It's > statelessness and resulting protocol simplicity are certainly pleasing. > But, I don't think that the schism over the threat model is going to > disappear through persuasion, so unless a third approach emerges, combining > PFS and statelessness, I doubt that there will be a way to satisfy all > parties. I'd like to note, as I periodically do, that SKIP is in no way actually stateless. Thats just marketing hype by Ashar. In order to use a SKIP datagram in any real system you are going to have to get keys from a keyserver, thus almost completely obviating the claimed advantages of SKIP. You can, of course, operate SKIP with statically configured keys -- but in that case why not just run ESP and AH with statically configured keys and get rid of the overhead? Perry From ipsec-request@ans.net Sat Dec 16 06:48:11 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11824 (5.65c/IDA-1.4.4 for ); Sat, 16 Dec 1995 01:58:58 -0500 Received: by interlock.ans.net id AA17569 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 16 Dec 1995 01:48:59 -0500 Message-Id: <199512160648.AA17569@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 16 Dec 1995 01:48:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 16 Dec 1995 01:48:59 -0500 Subject: CFP: Special issue on ATM SWITCHING To: ipsec@ans.net, iplpdn@cnri.reston.va.us, sig11@roses.stanford.edu, smds@cnri.reston.va.us Date: Sat, 16 Dec 1995 17:48:11 +1100 (EST) Reply-To: atiq@eng.monash.edu.au (Mohammed Atiquzzaman) From: atiq@eng.monash.edu.au (Mohammed Atiquzzaman) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3299 Call for Papers Special Issue of International Journal of Computer Systems Science & Engineering on ATM Switching Guest Editors: Hussein T. Mouftah, Queen's University, Canada Mohammed Atiquzzaman, Monash University, Australia. _______________________________________________________________________________ Papers are solicited for a special issue of the International Journal of Computer Systems Science & Engineering on Asynchronous Transfer Mode (ATM) Switching to be published in the third quarter of 1996. During the past decade, a considerable amount of effort has been made in studying and designing ATM switches which is believed to be the most developed aspect of ATM. The field has now become a mature area and ATM switches are becoming commercially available. This special issue will include a set of original and survey articles from both industry and academia that represents the current state-of-the-art in ATM switching. Possible topics include (but are not limited to): o Switch architectures o Fault tolerance o Buffering schemes o Congestion control and traffic management o Performance modeling o Practical experience & field trials o Buffer management o Simulation techniques for large switches o Commercial switches Five copies of complete manuscripts (not to exceed 25 double-spaced pages) should be sent to Mohammed Atiquzzaman by 1 February 1996. Please include a title page containing author(s) names and affiliations, postal addresses, e-mail addresses, telephone numbers, and fax numbers. Electronic (PostScript only) submissions are encouraged. Authors should follow the IJCSSE manuscript submission format. _______________________________________________________________________________ Guest Editors: _______________________________________________________________________________ Mohammed Atiquzzaman Hussein T. Mouftah Dept. of Elect. & Comp. Systems Engg. Department of Elect. & Comp. Engg. Monash University, Clayton 3168 Queen's University, Kingston Melbourne, Australia. Ontario, Canada K7L 3N6. Tel: +61 3 9905 5383 Tel: +1 613-545-2934 Fax: +61 3 9905 3454 Fax: +1 613-545-6615 Email: atiq@eng.monash.edu.au Email: mouftah@eleceng.ee.queensu.ca WWW: http://www.eng.monash.edu.au/~atiq _______________________________________________________________________________ Important Dates: _______________________________________________________________________________ Deadline for receipt of manuscripts: 1 February 1996 Notification of acceptance/rejection: 30 April 1996 ASCII and PostScript versions of this announcement and the author's guidelines for IJCSSE are available from http://www.eng.monash.edu.au/~atiq IJCSSE is published by CRL Publishing, London, UK. Please contact the editor-in-chief Prof. Tharam Dillon (tharam@latcs1.lat.oz.au) for queries regarding the journal and J. Thompson (100113.2636@CompuServe.com) for sample copies. From ipsec-request@ans.net Mon Dec 18 05:42:36 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10639 (5.65c/IDA-1.4.4 for ); Mon, 18 Dec 1995 00:56:52 -0500 Received: by interlock.ans.net id AA14602 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 18 Dec 1995 00:43:21 -0500 Message-Id: <199512180543.AA14602@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 18 Dec 1995 00:43:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 18 Dec 1995 00:43:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 18 Dec 1995 00:43:21 -0500 Date: Mon, 18 Dec 1995 06:42:36 +0100 To: ipsec@ans.net From: Germano Caronni Subject: Re: forward secrecy At 08:57 PM 12/15/95 -0500, Perry E. Metzger wrote: > >I'd like to note, as I periodically do, that SKIP is in no way >actually stateless. Thats just marketing hype by Ashar. In order to >use a SKIP datagram in any real system you are going to have to get >keys from a keyserver, thus almost completely obviating the claimed >advantages of SKIP. This is *not* true for any real system. Just for a (certainly very large) part of systems. By the way, could you please explain to me, why using a key server introduces state? >You can, of course, operate SKIP with statically configured keys -- >but in that case why not just run ESP and AH with statically >configured keys and get rid of the overhead? Even in this somewhat degenerated scenario SKIP still supports multiple name spaces, and allows for traffic keys and a (currently *very* coarse) playback protection. Native AH/ESP does not give you that. Friendly greetings, Germano From ipsec-request@ans.net Mon Dec 18 14:24:56 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11979 (5.65c/IDA-1.4.4 for ); Mon, 18 Dec 1995 09:33:27 -0500 Received: by interlock.ans.net id AA21170 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 18 Dec 1995 09:25:37 -0500 Message-Id: <199512181425.AA21170@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 18 Dec 1995 09:25:37 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 18 Dec 1995 09:25:37 -0500 X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol To: Germano Caronni Cc: ipsec@ans.net Subject: Re: forward secrecy In-Reply-To: Your message of "Mon, 18 Dec 1995 06:42:36 +0100." <199512180543.AA14602@interlock.ans.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 18 Dec 1995 09:24:56 -0500 From: "Perry E. Metzger" Germano Caronni writes: > At 08:57 PM 12/15/95 -0500, Perry E. Metzger wrote: > >I'd like to note, as I periodically do, that SKIP is in no way > >actually stateless. Thats just marketing hype by Ashar. In order to > >use a SKIP datagram in any real system you are going to have to get > >keys from a keyserver, thus almost completely obviating the claimed > >advantages of SKIP. > > This is *not* true for any real system. Just for a (certainly very large) > part of systems. Yes, you are correct. I'm sure that a tiny fraction of systems will be happy with manual keying, in which case why not use ESP/AH. > By the way, could you please explain to me, why using a key server > introduces state? Who cares if it induces state? It induces all the delays that the claimed "statelessness" of SKIP supposedly avoids. I don't care about semantic debates. The fact remains that if you use SKIP in the real world, you don't have a system where you just fire a packet and it can be received and decoded at once -- the destination must look up the keys, which involves network round trips. Once the keys are in place, the delay goes away -- same as with Photuris, of course. I again ask people -- what is the point of SKIP if it costs you perfect forward secrecy and lots of other things and buys you nothing at all? All the claimed benefits are marketing hype -- there is no substance to them. SKIP has not a single advantage and lots of disadvantages. > >You can, of course, operate SKIP with statically configured keys -- > >but in that case why not just run ESP and AH with statically > >configured keys and get rid of the overhead? > > Even in this somewhat degenerated scenario SKIP still supports multiple > name spaces, So do ESP/AH -- they are multiple SAIDs, which your implementation of ESP/AH doesn't support, I will note, thus making it non-conformant. Perry From ipsec-request@ans.net Mon Dec 18 16:18:09 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12982 (5.65c/IDA-1.4.4 for ); Mon, 18 Dec 1995 11:25:44 -0500 Received: by interlock.ans.net id AA24460 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 18 Dec 1995 11:18:21 -0500 Message-Id: <199512181618.AA24460@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 18 Dec 1995 11:18:21 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 18 Dec 1995 11:18:21 -0500 Date: Mon, 18 Dec 1995 08:18:09 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: Re: forward secrecy I don't know what the implementation in Switzerland looks like and I don't want to wade into a semantic swamp, but let me just make one observation that is independent of any particular implementation. All conforming/compliant implementations of ESP/AH _MUST_ support the use of regular SPIs and MUST support the use of manual key distribution. Anything that only supported SKIP key distribution and did not support regular SPIs and manual key distribution is __NOT__ a conforming or compliant implementation of ESP/AH. Claims to the contrary would constitute criminal fraud under US laws. If an implementation doesn't meet ALL of the requirements in RFC-1825-1827, then it should only be characterised as "incomplete" or "non-conforming" or "broken". Regards, Ran rja@cisco.com Opinions expressed are my own, not necessarily my employer's. From ipsec-request@ans.net Mon Dec 18 07:32:19 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12373 (5.65c/IDA-1.4.4 for ); Mon, 18 Dec 1995 12:42:18 -0500 Received: by interlock.ans.net id AA26677 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 18 Dec 1995 12:37:27 -0500 Message-Id: <199512181737.AA26677@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 18 Dec 1995 12:37:27 -0500 From: smb@research.att.com Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 18 Dec 1995 12:37:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 18 Dec 1995 12:37:27 -0500 To: Ran Atkinson Cc: ipsec@ans.net Subject: Re: forward secrecy Date: Mon, 18 Dec 95 12:32:19 EST All conforming/compliant implementations of ESP/AH _MUST_ support the se of regular SPIs and MUST support the use of manual key distribution. Anything that only supported SKIP key distribution and did not support regular SPIs and manual key distribution is __NOT__ a conforming or compliant implementation of ESP/AH. Claims to the contrary would constitute criminal fraud under US laws. If an implementation doesn't meet ALL of the requirements in RFC-1825-1827, then it should only be characterised as "incomplete" or "non-conforming" or "broken". Given that I've yet to see even one implementation that conforms to all of RFC 1122 and 1123, I can't take this very seriously. From ipsec-request@ans.net Mon Dec 18 12:22:06 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14450 (5.65c/IDA-1.4.4 for ); Mon, 18 Dec 1995 23:15:48 -0500 Received: by interlock.ans.net id AA10853 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 18 Dec 1995 23:11:03 -0500 Message-Id: <199512190411.AA10853@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 18 Dec 1995 23:11:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 18 Dec 1995 23:11:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 18 Dec 1995 23:11:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 18 Dec 1995 23:11:03 -0500 Sender: "David F. Luther" From: "David F. Luther" X-Mailer: SecureMail [2.3] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: HannaH beta Test Sign-up To: dfl@sware.com Date: Mon, 18 Dec 95 17:22:06 EST SecureWare's Hannah network security product adds cryptographic authentication, integrity, and encryption security to TCP connections without modifications to applications. You have previously expressed interest in our Hannah network security product. We are currently taking requests for beta test sites for the HannaH product. If you are interested, please visit our Home page, read about the Hannah product, and complete the Hannah beta request form (http://www.secureware.com). If you want to sign up but do not have access to a Web browser, please respond via Email with your FAX number and a form will be FAXed to you. If you have already submitted an on-line application for the beta program, there is no need to submit a new one. Thanks for your interest in SecureWare Internet security products. David Luther email: luther@secureware.com SecureWare Inc. phone: 404-315-6296 x-121 2957 Clairmont Rd., Suite 200 FAX : 404-315-0293 (FAX) Atlanta, GA 30329-1647 URL : http://www.secureware.com From ipsec-request@ans.net Tue Dec 19 06:25:49 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12935 (5.65c/IDA-1.4.4 for ); Tue, 19 Dec 1995 01:33:09 -0500 Received: by interlock.ans.net id AA12805 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 19 Dec 1995 01:27:23 -0500 Message-Id: <199512190627.AA12805@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 19 Dec 1995 01:27:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 19 Dec 1995 01:27:23 -0500 From: Germano Caronni Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 19 Dec 1995 01:27:23 -0500 Subject: Re: forward secrecy To: rja@cisco.com (Ran Atkinson) Date: Tue, 19 Dec 1995 07:25:49 +0100 (MET) Cc: ipsec@ans.net In-Reply-To: <199512181618.AA24460@interlock.ans.net> from "Ran Atkinson" at Dec 18, 95 08:18:09 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Content-Length: 287 Ran Atkinson wrote: > Anything that only supported SKIP key distribution and did not support > regular SPIs and manual key distribution is __NOT__ a conforming or > compliant implementation of ESP/AH. Yes, this is clearly stated in section 4.6 of RFC1825. Greetings, Germano From ipsec-request@ans.net Tue Dec 19 06:43:58 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11689 (5.65c/IDA-1.4.4 for ); Tue, 19 Dec 1995 01:50:38 -0500 Received: by interlock.ans.net id AA12948 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 19 Dec 1995 01:44:04 -0500 Message-Id: <199512190644.AA12948@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 19 Dec 1995 01:44:04 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 19 Dec 1995 01:44:04 -0500 Date: Mon, 18 Dec 1995 22:43:58 -0800 (PST) From: Phil Karn To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: <199512122345.AA05728@interlock.ans.net> (message from Ran Atkinson on Tue, 12 Dec 1995 15:45:36 -0800) Subject: Re: SPIs, etc. > Phil Karn is right that the SPI number spaces should be separate for AH >and ESP because they are different protocols. Right. And for this same reason I've argued that there should be separate attribute lists in Photuris for AH and ESP. These are independent protocols with their own orthogonal options and number spaces. I'd like to add language something like the following to future versions of the AH and ESP documents: Implementations MUST accept and properly process incoming "nested" security packets, i.e., packets using both the AH and ESP, where the SPIs for AH and ESP are the same. Implementations SHOULD be capable of generating nested packets with the same SPIs for AH and ESP, but they MAY be configured not to do so. Phil From ipsec-request@ans.net Tue Dec 19 06:56:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13496 (5.65c/IDA-1.4.4 for ); Tue, 19 Dec 1995 01:59:15 -0500 Received: by interlock.ans.net id AA13030 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 19 Dec 1995 01:56:28 -0500 Message-Id: <199512190656.AA13030@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 19 Dec 1995 01:56:28 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 19 Dec 1995 01:56:28 -0500 Date: Mon, 18 Dec 1995 22:56:21 -0800 (PST) From: Phil Karn To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: <199512131632.AA03477@interlock.ans.net> (message from Ran Atkinson on Wed, 13 Dec 1995 08:32:47 -0800) Subject: Re: correction on SPIs >The NRL software does indeed have separate number spaces for SPIs and so >an AH session and an ESP session to the same destination with the same >SPI value will indeed be different Security Associations in the Key >Engine. My code has a single SPI database but each entry provides for separate AH and ESP transforms, which is the important part. In effect there are two separate databases merged into one. I don't care about the details of an implementation; as long as it can handle ESP and AH independently that's good enough by me. Phil From ipsec-request@ans.net Tue Dec 19 07:33:31 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12840 (5.65c/IDA-1.4.4 for ); Tue, 19 Dec 1995 02:44:14 -0500 Received: by interlock.ans.net id AA13446 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 19 Dec 1995 02:33:40 -0500 Message-Id: <199512190733.AA13446@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 19 Dec 1995 02:33:40 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 19 Dec 1995 02:33:40 -0500 Date: Mon, 18 Dec 1995 23:33:31 -0800 (PST) From: Phil Karn To: ho@cs.arizona.edu Cc: bsimpson@morningstar.com, ipsec@ans.net In-Reply-To: <199512140243.AA20386@interlock.ans.net> (message from Hilarie Orman on Wed, 13 Dec 1995 19:43:04 -0700) Subject: Re: ICMP Security Failures >> Note that in "transport-mode", the SPI indicated will be of the outer >I think I get it, but I'm not familiar with the term "transport-mode". I'd like to expunge use of the terms "transport-mode" and "tunnel-mode" from IPSEC documents. Not because the modes they describe aren't useful, but because I really consider them completely orthogonal to the security mechanisms IPSEC provides. "Tunnel mode" simply implies that a host has the ability to tunnel and detunnel packets, irrespective of whether that host also implements IPSEC (AH and ESP). It simply means that the host implements IP Protocol No. 4. If the host also happens to implement IP Protocols Nos. 50 and 51 (IP Security), it's free to combine all three in any fashion it chooses. But the mechanisms of IP security are completely independent of whether the payload is a UDP or TCP segment or another IP datagram. Phil From ipsec-request@ans.net Tue Dec 19 08:09:15 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13467 (5.65c/IDA-1.4.4 for ); Tue, 19 Dec 1995 03:16:53 -0500 Received: by interlock.ans.net id AA13827 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 19 Dec 1995 03:11:51 -0500 Message-Id: <199512190811.AA13827@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 19 Dec 1995 03:11:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 19 Dec 1995 03:11:51 -0500 Date: Tue, 19 Dec 1995 00:09:15 -0800 (PST) From: Phil Karn To: ashar@osmosys.incog.com Cc: ipsec@ans.net In-Reply-To: <199512142316.AA17027@interlock.ans.net> (ashar@osmosys.incog.com) Subject: Re: forward secrecy Ashar, You make some good points, mainly (to rephrase) that a single really good DH exchange is better than a bunch of bad DH exchanges. True, but Photuris still gives you the option of 'turning a knob' to make the DH exchanges as good (and as infrequent, if that's necessary) as you like. While you're probably right that the NSA performs mostly passive vacuum-cleaner attacks, this doesn't apply in all cases. In particular, the recent revelations about cracking Soviet WWII and Cold War-era spy communications (see "Dark Sun" by Richard Rhodes) really describe active attacks: during WWII the Finns discovered a Soviet code book and sold it to the OSS, who copied it before returning it to their nominal allies. This is a classic active attack, as were the "black bag jobs" (covert break ins) also performed by the US against the Russians. Since the Russians were (and probably still are) very fond of one-time pads, this sort of thing was pretty much required to get any measure of success. Clearly, ephemeral DH exchanges would thwart these attacks. My philosophy: do DH with big enough exponents to thwart NSA for a very long time, AND redo it often enough to limit your exposure. And if that's too much of a CPU burden, either tune up your exponentiation code or buy a bigger CPU. Phil From ipsec-request@ans.net Tue Dec 19 13:12:37 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14356 (5.65c/IDA-1.4.4 for ); Tue, 19 Dec 1995 08:24:56 -0500 Received: by interlock.ans.net id AA17108 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 19 Dec 1995 08:15:23 -0500 Message-Id: <199512191315.AA17108@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Tue, 19 Dec 1995 08:15:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Tue, 19 Dec 1995 08:15:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 19 Dec 1995 08:15:23 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 19 Dec 1995 08:15:23 -0500 X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2b10 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Dec 1995 08:12:37 -0500 To: Phil Karn , ashar@osmosys.incog.com From: Robert Moskowitz Subject: Re: forward secrecy Cc: ipsec@ans.net At 12:09 AM 12/19/95 -0800, Phil Karn wrote: > >Clearly, ephemeral DH exchanges would thwart these attacks. My >philosophy: do DH with big enough exponents to thwart NSA for a very >long time, AND redo it often enough to limit your exposure. And if >that's too much of a CPU burden, either tune up your exponentiation >code or buy a bigger CPU. I think Hilarie had it right " encrypt until it hurts, then back off a little". I would add, "just a little, maybe". Robert Moskowitz Chrysler Corporation (810) 758-8212 From ipsec-request@ans.net Tue Dec 19 18:18:32 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14548 (5.65c/IDA-1.4.4 for ); Tue, 19 Dec 1995 13:31:28 -0500 Received: by interlock.ans.net id AA26223 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 19 Dec 1995 13:19:18 -0500 Message-Id: <199512191819.AA26223@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 19 Dec 1995 13:19:18 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 19 Dec 1995 13:19:18 -0500 Date: Tue, 19 Dec 1995 10:18:32 -0800 From: Ran Atkinson To: karn@unix.ka9q.ampr.org Subject: Re: ICMP Security Failures Cc: ipsec@ans.net % I'd like to expunge use of the terms "transport-mode" and % "tunnel-mode" from IPSEC documents. Not because the modes they % describe aren't useful, but because I really consider them completely % orthogonal to the security mechanisms IPSEC provides. % % "Tunnel mode" simply implies that a host has the ability to tunnel and % detunnel packets, irrespective of whether that host also implements % IPSEC (AH and ESP). It simply means that the host implements IP % Protocol No. 4. If the host also happens to implement IP Protocols % Nos. 50 and 51 (IP Security), it's free to combine all three in any % fashion it chooses. But the mechanisms of IP security are completely % independent of whether the payload is a UDP or TCP segment or another % IP datagram. The reason that both modes continue to need to be described is that elsewise implementers will build support for only one or another of the modes in an implementation rather than supporting both modes. Both modes need to be widely available to applications. The two modes are defined so that we can then mandate that both are implemented. If they are not defined, we could not mandate that both are implemented and interoperability and portability of secured applications would decrease. Implementing support for IP tunnels does not imply that the same implementation would automatically support secure IP tunnels if ESP/AH were also implemented on that system (implementer might only permit ESP/AH processing to be called prior to IP processing -- which might not be smart but would be conforming under your proposal). If you don't like the terms, please feel free to propose clearer terms. Alternately, you perhaps can find a better way to specify things such that it is very clear that an implementation must support both styles of use for ESP. Ran rja@cisco.com From ipsec-request@ans.net Wed Dec 20 07:26:20 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12691 (5.65c/IDA-1.4.4 for ); Wed, 20 Dec 1995 03:02:11 -0500 Received: by interlock.ans.net id AA11276 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 20 Dec 1995 02:26:29 -0500 Message-Id: <199512200726.AA11276@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 20 Dec 1995 02:26:29 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 20 Dec 1995 02:26:29 -0500 Date: Wed, 20 Dec 1995 02:26:20 -0500 X-Sender: mpwagner@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Phil Karn From: daw@cs.berkeley.edu (David Wagner) Subject: Re: ICMP Security Failures Cc: ipsec@ans.net > >I'd like to expunge use of the terms "transport-mode" and >"tunnel-mode" from IPSEC documents. Not because the modes they >describe aren't useful, but because I really consider them completely >orthogonal to the security mechanisms IPSEC provides. > Hrmm, I don't have any comments on the wisdom of this change, but... Even if the words "transport-mode" and "tunnel-mode" are expunged, I hope the documents will clearly explain this type of usage and its importance somewhere. Tunnelling is a very useful mode. It's most useful for routers, bump-in-the-stack encryptors, IP forwarding (e.g. IP ``remailers''), and perhaps also firewalls...but I don't think the utility is limited to those situations. It's important that implementors realize they must support this mode of operation. The tunnel/transport modes aren't orthogonal, from the implementation perspective: to support tunnel-mode, the IPSEC modules must be re-entrant, and must deal with remembered security state when processing IP headers. Implementors probably won't think to support all this if it's not described explicitly in the spec. From ipsec-request@ans.net Wed Dec 20 19:02:27 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10500 (5.65c/IDA-1.4.4 for ); Wed, 20 Dec 1995 14:08:41 -0500 Received: by interlock.ans.net id AA22842 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 20 Dec 1995 14:02:49 -0500 Message-Id: <199512201902.AA22842@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 20 Dec 1995 14:02:49 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 20 Dec 1995 14:02:49 -0500 Date: Wed, 20 Dec 1995 11:02:27 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: ADMIN: Dallas IETF Minutes for IP Security WG All, Appended below are the written minutes for the IP Security WG that were submitted to CNRI for inclusion in the written proceedings. Special thanks are due to Richard Graveman (Bellcore) who once again provided the co-chairs with his clearly written notes on the meetings and did so very shortly after each session. Our minutes are almost entirely his words. Ran Atkinson Paul Lambert rja@cisco.com palamber@us.oracle.com --------------------- cut here --------------------------------- Minutes for IP Security Working Group 34th IETF, Dallas, TX, December 1995. These minutes are largely based on the notes taken by Richard Graveman during the meetings. The WG chairs thank him for his assistance in taking good notes during the meeting. Co-chair Paul Lambert was the floor moderator for most of this session. He was assisted by Randall Atkinson . Paul noted that both of the co-chairs recently changed employers and so have new email addresses. IP Security WG mailing list is likely to be rehomed early in 1996. If it moves, the change will be announced on the main ietf mailing list. The current (as of December 1995) mailing list addresses are: Postings: ipsec@ans.net Admin: ipsec-request@ans.net IP Security (IPSEC) Session 1, December 4th, 1995: -------------------------------------------------- RFC 1825 through RFC-1829 define the IP Encapsulating Security Payload (ESP) and the IP Authentication Header (AH). These were issued as Proposed Standard RFCs this past August. The discussions during the first IPsec meeting were focused on these specifications. LIAISONS: Ran noted that options in IPv6 are handled differently from IPv4. A bag of Hop-By-Hop options may follow the base IPv6 header. After these may come Destination Options and then the upper layer protocol (e.g. ICMP, TCP, or UDP). Destination Options are only handled by specifically listed destination systems for the IPv6 packet, while Hop-By-Hop options are handled by each intermediate system and end system (host or router). It might be useful to consider specifying AH for IPv6 as either a Hop-By-Hop Option or Destination Option rather than as a separate header. One advantage is that if AH were specified in this new way, the semantics of AH processing might be more clear for IPv6 implementations and two different semantics could be supported. Another possible advantage is to force AH to be parsed first at the destination(s), even though would not be handled at the routers. This is expected to be discussed more during the IPng WG meetings later this week. AH/ESP IMPLEMENTATION STATUS: Ran posed the following questions for all implementers: Whose implementation ? Implemented in what (host router, etc) ? Is it commercial or freely available? Which transforms were implemented ? It is known to interoperate with ? Which key distribution techniques are implemented ? Ran: The freely distributable NRL implementation covers IPv4 and IPv6 for hosts and routers, is based on 4.4-Lite BSD, Implements Keyed MD5 and DES-CBC, works with Karn and Morningstar, and has manual key management. A particular feature is that this implementation includes a Key Management Socket (PF_KEY) that permits key management daemons to be implemented outside the kernel in a portable manner. It is likely that NRL will document PF_KEY in an Informational RFC during the next few months. Additional transforms are easy to add to this implementation. Configured secure tunnels, dynamic tunnel-mode encryption, and transport-mode encryption are all supported using extensions to the widely used BSD network Sockets API. Applications that support use of IPsec via command-line options are also included in the distribution. See Dan McDonald or Bao Phan for more information. This implementation is freely available (modulo US Export Controls) and is reportedly online at ftp://ftp.c2.org MIT is expected to be the official archive site for the NRL software, but is still working on getting the software online. Enhancements to the NRL software are underway and will also become freely distributable. A paper on the details of this implementation will be presented at the January 1995 USENIX Conference. John Ioannidis ("JI") : This implementation was implemented in Greece, runs on BSDI, and will be freely available. It implements keyed MD5 and DES CBC, uses manual key distribution or Photuris (also implemented outside US) key distribution, and handles multiple transformations in any order with built in tunneling. Contact JI at for more information. Phil Karn: KA9Q implementation for hosts and routers based on MS-DOS, does encapsulation separately, will be distributable, uses keyed MD5, DES, and 3DES (IDEA perhaps next). It talks to at least Morningstar and NRL, and has manual key management. Photuris is planned for the future. Contact Phil Karn for more information. Mark Linehan: IBM's Pau-Chen Cheng has an implementation that runs on AIX, will be in a commercial firewall product. Mark indicated that they will have an exportable version, and uses manual key distribution. Pau-Chen has a copy of the implementation at the IETF so that interoperability testing can occur this week. Contact Pau-Chen for more information. Steve Bellovin: Two implementations were done last summer by David Wagner (UC Berkeley) while he was at AT&T Bell Labs. The first implementation runs on BSDI and uses keyed MD5 and DES. This AH is known to not interoperate with other implementations. The second implementation runs on MSDOS, uses keyed MD5 for AH, looks like a packet driver, so it can work with many boards and IP stacks. This has been tested with ftp Software and a paper on this implementation will be presented at ISOC in February. Contact Steve Bellovin for more information. Hilarie Orman: This implementation was done in the "x-kernel" research operating system at the University of Arizona. It is a user process in MACH, implements AH with keyed MD5, and implements ESP with DES CBC and 3DES. It has ping and ftp clients. Tools for manual key distribution exist. A Photuris implementation also exists. Will be freely distributable with the x-kernel software. Contact Hilarie Orman for more information. Ashar Aziz: Sun has implementations of ESP and AH with SKIP for SunOS 4.1.3 (kernel driver source), and Solaris 2.x (binaries only). Contact Ashar Aziz at for more information. Swiss Federal Institute of Technology: Runs on Solaris 2.x, IRIS, and NetBSD, freely distributable, implements AH and ESP with a fixed SPI (i.e. only works with SKIP key distribution). Key distribution is manual or with SKIP. Rob Glenn: NIST and NSA have an implementation of ESP and AH with MD5 and DES-CBC. It runs on BSDI, SunOS 4.1.x, FreeBSD, and NetBSD. They brought a FreeBSD implementation for interoperability testing and are working to make the implementation freely distributable within the US. Their implementation can use ISAKMP and was designed to support multiple security policies. Contact Rob Glenn for more information. Other: Two other implementations were mentioned without much detail. Jeff Kramer of Raptor has implemented some of IPsec. Antonio Fernandez of Bellcore has an AH implementation. Interoperability testing will occur in a hotel meeting room on Tuesday afternoon, thanks to Tim Matthews who arranged for the room. OPEN ISSUES: Where do current RFCs need clarification? The current RFCs will be cleaned up and reissued as Internet Drafts before the next IETF. Then everyone should send comments (preferably with replacement text) on confusing portions of the current specs so that the specifications can be cleared up prior to moving to Draft Standard RFC. We already meet the interoperability requirements to move to Draft Standard. Paul Lambert solicited implementor comments on AH/ESP RFCs and also on the DES, MD5, 3DES, and SHA tranforms RFCs: Bellovin and others asked which fields in the IPv4 header should be zeroed. There was consensus that this is the biggest problem with AH/ESP. Ran responded that the next version of the AH spec will specifically enumerate which IPv4 options and header fields are included in AH calculations and which are zeroed. A note to the IPsec WG mailing list late last August enumerated these in more detail than was present in the RFCs. The options important to include in the Authentication Data calculation are IPSO (RFC-1108)and CIPSO (no public specification exists). JI suggested adding sequence numbers to AH. It is in the Photuris extensions draft and would use the 16 bits of reserved AH header. Bob Moscowitz brought up concerns about interactions with firewalls. Perry Metzger brought up need for ways to use (fast) stream ciphers (synchronization problem). Bill Simpson asked for comments on the transform RFCs. The main comment was that many implementers have been confused on how to perform the MD5 padding. Hilarie Orman suggested including example C source code in an informational Appendix to the MD5 transform draft in order to make this more clear. NEW TRANSFORMS: Hugo from IBM discussed an alternate approach to Keyed MD5. RFC 1828 specifies: MD5(K pad x K). New nested mode: MD5(K padsub2 MD5(K padsub1 x)) |K| = 16 bytes padsub1 = 0x36 repeated 48 times padsub2 = 0x5C repeated 48 times Hugo's Comparison: - is still MD5 based (available, unrestricted, good performance) - is replaceable (SHA, MD6, ...) - no performance degradation - short keys, simple setup - MD5 unchanged - better security: * improved analysis * weaker assumptions about hash function * tighter security: MAC as secure as underlying hash function * double key effect He asserted that to break the new MD5 transform, either the output of the MD5 compression is predictable or MD5 collisions can be found even when the IV is secret and random. Both of these are believed to be untrue for MD5. The underlying construction considers MD5 with the IV set to K. Only one K is needed but the pads have to be different. Also, for added efficiency, implementations can compute the first block once and use each time with a given key. Much discussion followed. Perry Metzger, Bill Simpson, Hilarie Orman, JI, Steve Bellovin, Ted Ts'o, Bob Moscowitz, Phil Karn, and Jeff Schiller had comments on this. Simpson suggested using Hugo's approach with SHA and not MD5. Hilarie asked where Hugo's analysis could be obtained and noted the need for outside cryptographic and mathematical review of Hugo's proposal. WG Consensus seemed to be: Put this new transform out as a Proposed Standard (Elective) in its own RFC with a new transform identifier. Advertise that either 1828 or this new transform might become the required future transform when we move to Draft Standard. In order to move the new transform to Draft Standard, at least 2 independent interoperable implementations must exist and be demonstrated interoperating. OTHER TRANSFORMS: Paul Lambert noted that there might be other transforms (e.g. DES-CBC integrated with MD5 for use with ESP) needed. He solicited volunteers to write up additional drafts. Only Bill Simpson and Perry Metzger volunteered. Other volunteers are still solicited by the WG chairs. Volunteers should write up their proposed transforms and put them out as Internet Drafts (filenames of the form draft-LASTNAME-TRANSFORM_NAME-*.txt should be used) and mention the published I-Ds on the WG list. IP Security WG, Session 2, 6 December 1995: ------------------------------------------- This session was mostly focused on key management and related issues. Paul Lambert showed the matrix of AH and ESP interoperability testing. The grid was about half filled in. Ran observed that not all combinations of implementations had been tested, so a blank space was not necessarily indicative of non-interoperability. A number of implementation bugs were found and fixed on Tuesday during the information interoperability testing session. Two SKIP implementations worked together. Two Photuris implementations worked together. The group was pleasantly surprised at the rapid progress towards interoperability and the unexpectedly large number of independent implementations. LIAISONS: ANSI: John Kennedy discussed ANSI X9F. There are two drafts: X9.52 for Triple-DES (3DES) is near working draft status. Contact Bill Latin +1 (408) 735-6679 or via email at for more information on X9.F2. X9.42 is on Diffie-Hellman (DH). Contact John Kennedy at +1 (408) 735-5885 or via email to kennedy@cylink.com for more information. Also ANSI X9.55 is tracking the X.509 Public Key certificate standards work; see Russ Housley or Warwick Ford for more information. IEEE Microprocessor standards: This group covers RSA, DH, and related techniques. Burt Kaliski is the Chair. See ftp://ftp.rsa.com for more information. Elliptic curve (EC) implementation of discrete log systems is going to ballot within IEEE. The patent situation is different for EC than DH. Other sections on RSA, DH, and random number generation. The next meeting of this IEEE group is the two days before ISOC Security Symposium that will be held during February in San Diego. The usual comments about the need for no-cost on-line availability of these non-IETF specifications followed. PATENT ISSUES: Paul Lambert noted that many of the technologies discussed by the IPsec WG might be affected by patent claims. He then tried to summarise all known patent claims that might be issues. Ashar noted that the Sun patents relating to SKIP are available for use at no cost. Patents claimed by NeXT are reportedly under negotiation. Hugo noted that IBM issued an RFC on use of one of their patents. UUNET has a US patent claim on all network encryption. Novell has a claim on the use of Message Authentication Codes such as Keyed MD5. Motorola has patent claims on certain compression techniques. Paul solicited information on non-US patents, but no one had any information on this. It was suggested that any other known patent claims be mentioned on the IPsec mailing list. For Cylink: see http://www.cylink.com or telephone Bob Fougner at +1 (408) 735-5893. For RSA, see http://www.rsa.com or telephone Paul Livesay at +1 (415) 595-8782. For UUNET, contact Rick Adams ELLIPTICAL CURVE PRESENTATION: Hilarie Orman presented an argument for using Elliptical Curves instead of Modular Exponentiation with Public-key technology. She showed a graph illustrating that to get more key bits, DH compute time increases rapidly even using Karatsuba multiplication and Montgomery reduction. For DH modulus M, |M| = 512-2048 bits and exponent E, |E| = 128-256 bits, compute time is |E| |M|^1.6. Strength depends on: minimum(E/2, 2.5M^(1/3), log(M)^((2/3)-15)). Using |E| = 128, |M| = 512 really only yields 53 bits of equivalent DES key strength. This estimate used an interpolation into an asymptotic bound for the number field sieve based on the factoring of a 119 digit number with that method. ECs give equivalent strength with 155 bits over a field of characteristic 2. More information on this subject is available at http://www.cs.arizona.edu/xkernel/www/ipsec/ipsec.html. Hugo questioned some of the conclusions that Hilarie drew. The WG was very interested in Hilarie's presentation but no consensus either way was obvious. The matter remains open for further study and discussion. ALTERNATIVE ENCRYPTION ALGORITHM: John Kennedy presented Jim Massey's "Safer SK" algorithm. This is a 64 bit block cipher with 40, 64, or 128 bit keys. It is freely available and robust against differential and linear cryptanalysis. He suggested that this might be of interest. It was suggested that he document an ESP transform for this as an Internet Draft so that the WG could discuss this proposal in more concrete terms. It was also suggested that an Informational RFC documenting the cryptographic algorithm would be helpful. KEY MANAGMENT: Paul then turned discussion towards the currently available Internet Drafts on Key Management technology. There are 3 documents online at present, namely Photuris, SKIP, and ISAKMP. Photuris: Phil Karn presented the changes to Photuris. Interchangeable parts of the protocol may lead to weaknesses (exchange, key generation, signature). Two implementations exist today that interoperate: JI (University of Crete) and HO (University of Arizona). Also work is underway or contemplated at NRL (on top of PF_KEY), and by Simon Spero and Phil Karn. Phil expects a "bottom up" deployment from AH and ESP to cases where a public key already exists, say in a password file, and access control is being enforced. Two questions were posed: How to support multiple ESP transforms ? How to support user-to-user keying ? Phil Karn then solicited issues from the WG and came up with the following list: 1. Are options for the station-to-station (STS) phase necessary ? 2. What is the public key certificate infrastructure ? 3. Security association attribute negotiation is needed. 4. Document is too long and hard to comprehend. 5. Session key from shared secret: use of dependent keys. 6. Should encryption for privacy in STS really be mandatory ? 7. Is there potential for convergence with SKIP ? SKIP: Ashar Aziz presented SKIP to the Working Group. Since Danvers there have been several major changes such that the current draft is not compatible with older SKIP implementations. Specifically, - The SKIP header now only performs key management and ESP/AH are used for IP authentication or encryption. The new structure is: [IP header][SKIP header][AH or ESP][upper-layer protocol] - A public-key Certificate Discovery Protocol based on UDP was developed in order to obtain long-term keys. This allows multiple certificate types (PGP, X.509, etc.) and can be run bilaterally or with a central server. One effect of this change is that SKIP now has some state. Ran Atkinson asked to move this protocol into a separate draft from SKIP so that it could be used more generally rather than only for SKIP. Ashar agreed to make this change. Phil Zimmermann stated that this protocol will work with a new release of PGP expected in January 1996. - A "SKIP Algorithm Discovery Protocol" based on ICMP has been added. This message is authenticated but is sent in the clear. This addition also adds state into SKIP. - Naming is now disassociated from source and destination IP addressees: This helps support mobile hosts with dynamic IP addresses better. - A specification bug relating to IP multicasting was fixed. Two "SKIP with ESP and DES-CBC and certificate discovery" implementations interoperate. Raised hands from the audience indicate that other implementations of this are being considered. ISAKMP: Mark Schertler presented the ISAKMP specification. Their goal is to have a single key management protocol that is usable by ESP/AH and also other protocols (e.g. SSL, PCT, RIP-II, 802.10 SDE, TLS, OSPF). They seek independence from security policy, mechanism, and algorithm. All approaches that have been proposed in the WG allow protocol as well as crypto attacks. The focus of his work has been on resolving the protocol attacks. The main changes are: 1. User Negotiation protected by server established SA, 2. Situation (usage policy), 3. Authentication only mode, 4. Version number. They brought a prototype demonstration on DTOS microkernel that was shown afterwards in the hallway. This implementation could be moved to BSD with little difficulty. They have the TIS version of DNS Security (DNSsec) running on SunOS 4.1.3, and they can extract certificates from Fortezza tokens and may use PGP certificates in the future. The implementation is not copyrighted and available to US citizens or government agencies. They are willing do interoperability testing with independent implementations from outside the US. Mark then commented on the other key management protocols: SKIP works best with connectionless protocols and does not support security association management. Photuris is ESP and AH specific and not compatible with security tokens (this was challenged by Simpson and was deferred for further discussion). WORKING GROUP SUMMARY: Paul observed that SKIP is now in WG last call for Proposed Standard (Elective). Jeff Schiller asked whether SKIP meets the WG charter? What about perfect forward secrecy? At Ran's request, Jeff then summarised the property of Perfect Forward Secrecy and why it is important. Jeff then described the IETF standards process. Hugo asked whether perfect forward secrecy is still a consensus goal for a mandatory standard? Ashar responded by explaining the limited forward secrecy possible with SKIP. Karn stated that Perfect Forward Secrecy should be at least available. Bob Moscowitz stated that Perfect Forward Secrecy is sometimes necessary in a business environment. Perry Metzger mentioned need to support multiple mechanisms. WG CONSENSUS: There was very clear working group consensus that Perfect Forward Secrecy remains a requirement for any specification moving forward as a mandatory-to-implement IETF standard. SKIP does not claim to provide this property, while Photuris claims to provide it. ISAKMP can support a session-key exchange that provides this property but does not currently specify any session-key exchange algorithm. From ipsec-request@ans.net Wed Dec 20 21:06:35 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12736 (5.65c/IDA-1.4.4 for ); Wed, 20 Dec 1995 17:39:36 -0500 Received: by interlock.ans.net id AA29006 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 20 Dec 1995 17:35:15 -0500 Message-Id: <199512202235.AA29006@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 20 Dec 1995 17:35:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 20 Dec 1995 17:35:15 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 20 Dec 1995 17:35:15 -0500 Date: 20 Dec 95 13:06:35 -0800 From: "PALAMBER.US.ORACLE.COM" To: daw@cs.berkeley.edu, ipsec@ans.net Subject: Re: ICMP Security Failures X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:daw@cs.berkeley.edu's message of 20-Dec-95 03:27 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-2422669-0-0 --Boundary-2422669-0-0 >Tunnelling is a very useful mode. It's most useful for routers, >bump-in-the-stack encryptors, IP forwarding (e.g. IP >``remailers''), and perhaps also firewalls...but I don't >think the utility is limited to those situations. >It's important that implementors realize they must support this mode >of operation. The intent has always been to mandate support in all implementations of both "end-system" and "router-like" (a.k.a. firewalls, intermediate systems, etc.) signaling. Several approaches are viable to support the necessary remapping of addresses and the group has had a strong consensus on the use of the "tunneling" (e.g. IP/ESP/IP) to provide this functionality. Obviously minor tweaks in the next release of the specification could help clarify these interoperability requirements. Paul PS - Implementations that allow multiple encapsulation (ESP/ESP/IP, or ESP/ESP/ESP/IP, etc.) may not be exportable as a product from the US. Exportable implementations may be required to block ESP over ESP :-( -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-2422669-0-0 Content-Type: message/rfc822 Date: 20 Dec 95 02:26:20 From:"David Wagner" To: Phil,Karn,karn@qualcomm.com Subject: Re: ICMP Security Failures Cc: ipsec@ans.net X-Sender: mpwagner@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.3 X-Orcl-Application: Mime-Version: 1.0 X-Orcl-Application: Content-Type: text/plain; charset="us-ascii" > >I'd like to expunge use of the terms "transport-mode" and >"tunnel-mode" from IPSEC documents. Not because the modes they >describe aren't useful, but because I really consider them completely >orthogonal to the security mechanisms IPSEC provides. > Hrmm, I don't have any comments on the wisdom of this change, but... Even if the words "transport-mode" and "tunnel-mode" are expunged, I hope the documents will clearly explain this type of usage and its importance somewhere. Tunnelling is a very useful mode. It's most useful for routers, bump-in-the-stack encryptors, IP forwarding (e.g. IP ``remailers''), and perhaps also firewalls...but I don't think the utility is limited to those situations. It's important that implementors realize they must support this mode of operation. The tunnel/transport modes aren't orthogonal, from the implementation perspective: to support tunnel-mode, the IPSEC modules must be re-entrant, and must deal with remembered security state when processing IP headers. Implementors probably won't think to support all this if it's not described explicitly in the spec. --Boundary-2422669-0-0-- From ipsec-request@ans.net Wed Dec 20 21:31:06 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11994 (5.65c/IDA-1.4.4 for ); Wed, 20 Dec 1995 17:58:18 -0500 Received: by interlock.ans.net id AA29541 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Wed, 20 Dec 1995 17:53:59 -0500 Message-Id: <199512202253.AA29541@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Wed, 20 Dec 1995 17:53:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 20 Dec 1995 17:53:59 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 20 Dec 1995 17:53:59 -0500 Date: 20 Dec 95 13:31:06 -0800 From: "PALAMBER.US.ORACLE.COM" To: ipsec@ans.net Subject: Fwd: Proposed PAR for 802.10i Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-2423781-0-0 --Boundary-2423781-0-0 The attached "PAR" is loosely related to ipsec issues for the support of multicast. SAIDs/SPIs are normally locally unique (for a recipient). Some approaches for multicast support may require additional restrictions to be placed on SAIDs/SPIs. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- --Boundary-2423781-0-0 Content-Type: message/rfc822 Date: 20 Dec 95 17:10:15 From:"Alonge Ken" To: sils@mintaka.orion.ncsc.mil Subject: Proposed PAR for 802.10i X-Mailer: Mail*Link SMTP-MS 3.0.2 All- Attached below is the proposed PAR for 802.10i that we came up with at our ad hoc meeting yesterday. Please let me know ASAP if you have any problem with the wording of the PAR. This refinement of the SAID field will also support the VLAN folks needs. This PAR will have to be approved at our Salt Lake meeting, so that it can be forwarded to the LMSC Exec for approval in March. Ken ************************************************** ATTACHED PAR ************************************************** 1. Date of Request: 14 March 1996 2. Assigned Project #: 802.10i 3. Does this PAR revise a previously approved PAR: No 4. Description of Proposed Document: Revision of Standard IEEE Std 802.10-1992; Full Use 5. Project Title: Revised Standard for Interoperable LAN Security (SILS) Part B - Secure Data Exchange (802.10b) 6. Scope of Proposed Standard: To refine the Security Association Identifier (SAID) field of the current Standard to support Multicast Key Center identification. Neither the SDE PDU format, nor the elements of procedure are changed by this refinement. 7. Prupose of Proposed Standard: To allow independent Multicast Key Centers to assign unique SAIDs. The current Standard requires a global MKC, or coordination among all MKCs to prevent re-use of the same SAID. Add Figure here. 8. Sponsor: LMSC 9. Name of group that will write the Standard: IEEE 802.10 Working Group 10. Target Completion Date: November 1996 11. Proposed Coordination: SCC10 (Dictionary) - Circulation of Drafts X3S3 - Circulation of Drafts IEEE 802.1 - Circulation of Drafts 12. Are you aware of any patent, copyright, or trademark issues? No 13. Copyright Agreement for IEEE Standards I hereby acknowledge my appointment as Official Reporter to the IEEE 802.10 Committee to write/revise a Standards Publication (entitled or to be entitled) Standard for Interoperable LAN Security (SILS) Part B - Secure Data Exchange (IEEE 802.10b) In consideration of my appointment and the publication of the Standards Publication identifying me, at my option, as an Official Reporter, I agree to avoid *knowingly* incorporating any copyrighted or proprietary material of another without such other's consent and acknowledge that the Standards Publication shall constitute a "work made for hire" as defined by the Copyright Act, and, that as to any work not so defined, I agree and do hereby transfer any right or interest I may have in the copyright to said Standards Publication to IEEE. Name Kenneth G. Alonge _______________________ (signature of chair of working group) Title Chair, IEEE Project 802.10 Working Group Date March 14, 1996 14. Person delegated to receive communications and conduct liaison with interested bodies: (This is normally the chair of the working group. If not, please indicated IEEE position.) Name Kenneth G. Alonge Telephone 703-883-8603 Company PRC Inc M/S ????? Fax 708-556-3528 Address 1500 PRC Dr Telex City McLean, Virginia Zip 22102 E Mail alonge_ken@po.gis.prc.com 15. Submitted By: (This is normally the sponsor's liaison to the Standards Board. If not, please indicate IEEE position and relationship to the sponsor.) Name Donald C. Loughry Telephone 408-447-2454 Company Hewlett-Packard Company Fax 408-447-2247 Address 19420 Holmstead Rd. M/S 43UC Telex City Cupertino CA Zip 95014 E Mail loughry@cup.hp.com Name D. C. Loughry ________________________ (signature of submitter) Title Chair, LMSC Date March 1996 --Boundary-2423781-0-0-- From ipsec-request@ans.net Thu Dec 21 21:01:40 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14044 (5.65c/IDA-1.4.4 for ); Thu, 21 Dec 1995 16:12:35 -0500 Received: by interlock.ans.net id AA22124 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 21 Dec 1995 16:01:48 -0500 Message-Id: <199512212101.AA22124@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 21 Dec 1995 16:01:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 21 Dec 1995 16:01:48 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 21 Dec 1995 16:01:48 -0500 X-Mailer: exmh version 1.6.2 7/18/95 To: "PALAMBER.US.ORACLE.COM" Cc: daw@cs.berkeley.edu, ipsec@ans.net Subject: Re: ICMP Security Failures In-Reply-To: PALAMBER's message of 20 Dec 1995 13:06:35 -0800. <199512202235.AA29006@interlock.ans.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Dec 1995 16:01:40 -0500 From: Bill Sommerfeld -----BEGIN PGP SIGNED MESSAGE----- content-type: text/plain; charset=us-ascii PS - Implementations that allow multiple encapsulation (ESP/ESP/IP, or ESP/ESP/ESP/IP, etc.) may not be exportable as a product from the US. Exportable implementations may be required to block ESP over ESP :-( Exportable implementations will probably not be allowed to implement ESP at all since single-DES CBC is the mandatory ESP transform and single-DES itself is not exportable. Given the requirement that ESP support manual keying, a conformant implementation woulld also not likely be exportable under the proposed (but hopefully irrelevant) "software key escrow"/"Clipper II" regulations. BTW, given recent talks with the export control folks: they would probably attempt to prevent export of ESP implementations which only supported ROT-13 if they were too easy to modify to add other algorithms.. - Bill -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMNnLIlpj/0M1dMJ/AQGxNAP+KxQnsT1FFv62AnnRsSwq0NtQBHYhMoSB +JDNTjGIYmtBeNu2rIcoRCHNwsJD3HfPkEn/Ml15ive0vY/2voLNwpQkPL8MSXIX ojPzKQl21Gqze4HuTBKaIoTtE0Yfc+UNaZBf1qUtutzCvkItJHi1/NhzkJSmmAFV GcjnhrNJHy8= =egTK -----END PGP SIGNATURE----- From ipsec-request@ans.net Thu Dec 21 21:55:02 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10700 (5.65c/IDA-1.4.4 for ); Thu, 21 Dec 1995 18:07:52 -0500 Received: by interlock.ans.net id AA24563 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 21 Dec 1995 17:58:34 -0500 Message-Id: <199512212258.AA24563@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 21 Dec 1995 17:58:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 21 Dec 1995 17:58:34 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 21 Dec 1995 17:58:34 -0500 Date: 21 Dec 95 13:55:02 -0800 From: "PALAMBER.US.ORACLE.COM" To: sommerfeld@apollo.hp.com Subject: ESP over ESP was Re: ICMP Security Failures Cc: ipsec@ans.net Mime-Version: 1.0 Bill, It is a common misconception that DES is not exportable: >Exportable implementations will probably not be allowed to implement >ESP at all since single-DES CBC is the mandatory ESP transform and >single-DES itself is not exportable. DES is exportable (from the US) with a license to 51% US owned companies, banks and financial institutions and many other specific applications on a case by case basis. ESP implementing only 40 bit RC4 (of course this is not quite compliant with the mandated implementation of single-DES) would be exportable, but only if the implementation prevented multiple ESP transforms. I do not mean to belabor the export issues, but only wanted to point out that "commercial US" implementations may need to selectively block ESP running over ESP (selectively since it would be all right in the US or with special licenses). Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- From ipsec-request@ans.net Thu Dec 21 23:24:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12775 (5.65c/IDA-1.4.4 for ); Thu, 21 Dec 1995 18:31:48 -0500 Received: by interlock.ans.net id AA25170 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 21 Dec 1995 18:24:27 -0500 Message-Id: <199512212324.AA25170@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 21 Dec 1995 18:24:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 21 Dec 1995 18:24:27 -0500 Date: Thu, 21 Dec 1995 15:24:22 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: Re: ESP over ESP [personal comment] Even though it wouldn't be a candidate for the IETF standards-track, it would be useful IMHO if someone wrote up an RC4 (with integrity protection) transform for ESP as an Experimental RFC (the way IDEA and SHA transforms are currently Experimental) to enhance interoperability among those implementations that happen to include RC4. Ran From ipsec-request@ans.net Fri Dec 22 00:04:05 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13390 (5.65c/IDA-1.4.4 for ); Thu, 21 Dec 1995 19:11:20 -0500 Received: by interlock.ans.net id AA25880 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Thu, 21 Dec 1995 19:05:27 -0500 Message-Id: <199512220005.AA25880@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 21 Dec 1995 19:05:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 21 Dec 1995 19:05:27 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 21 Dec 1995 19:05:27 -0500 Date: Thu, 21 Dec 1995 19:04:05 -0500 From: Theodore Ts'o To: "PALAMBER.US.ORACLE.COM" Cc: sommerfeld@apollo.hp.com, ipsec@ans.net In-Reply-To: PALAMBER.US.ORACLE.COM's message of 21 Dec 95 13:55:02 -0800, <199512212258.AA24563@interlock.ans.net> Subject: Re: ESP over ESP was Re: ICMP Security Failures Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 945 Date: 21 Dec 95 13:55:02 -0800 From: "PALAMBER.US.ORACLE.COM" It is a common misconception that DES is not exportable: Actually, I think a fairer statement (especially in regards to people within the IETF who have been grappling with these issues for a long time --- and I include Bill in this group) is that people use the term "DES is not exportable" as a shorthand to mean: A product containing DES for the purposes of data hiding will generally not be eligible for an export license which permits the product to the general public outside of the United States. At this point, I suspect most people in the ipsec working group are aware of the exceptions --- US owned companies, financial institutions, for authentication use only, etc. These exceptions, however, are generally not useful when a U.S. Company is trying to compete with European software vendors in the European market. - Ted From ipsec-request@ans.net Fri Dec 22 16:32:50 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14693 (5.65c/IDA-1.4.4 for ); Fri, 22 Dec 1995 11:39:40 -0500 Received: by interlock.ans.net id AA09056 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 22 Dec 1995 11:31:51 -0500 Message-Id: <199512221631.AA09056@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-5); Fri, 22 Dec 1995 11:31:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Fri, 22 Dec 1995 11:31:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 22 Dec 1995 11:31:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 22 Dec 1995 11:31:51 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 22 Dec 1995 11:31:51 -0500 Date: Fri, 22 Dec 1995 11:32:50 -0500 From: pau@watson.ibm.com To: ipsec@ans.net Subject: Re: ADMIN: Dallas IETF Minutes for IP Security WG Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: LTjB3GE9bi4etXi1G4ekOA== > > Date: Wed, 20 Dec 1995 11:02:27 -0800 > From: Ran Atkinson > To: ipsec@ans.net > Subject: ADMIN: Dallas IETF Minutes for IP Security WG > Content-Length: 22017 > Status: RO > > > Mark Linehan: > IBM's Pau-Chen Cheng has an implementation that runs on AIX, > will be in a commercial firewall product. Mark indicated that they > will have an exportable version, and uses manual key distribution. > Pau-Chen has a copy of the implementation at the IETF so that > interoperability testing can occur this week. Contact Pau-Chen > for more information. ^^^^^^^^^^^^^^^^^^^^^^^^ Hi, all, my e-mail address is . Regards, Pau-Chen Happy Holidays. From ipsec-request@ans.net Fri Dec 22 15:39:42 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13939 (5.65c/IDA-1.4.4 for ); Fri, 22 Dec 1995 11:47:15 -0500 Received: by interlock.ans.net id AA09381 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 22 Dec 1995 11:41:44 -0500 Message-Id: <199512221641.AA09381@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 22 Dec 1995 11:41:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 22 Dec 1995 11:41:44 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 22 Dec 1995 11:41:44 -0500 Date: 22 Dec 95 07:39:42 -0800 From: "PALAMBER.US.ORACLE.COM" To: tytso@mit.edu Subject: Re: ESP over ESP was Re: ICMP Security Failures Cc: ipsec@ans.net X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:tytso@MIT.EDU's message of 21-Dec-95 20:05 Mime-Version: 1.0 Ted, you are right ... > A product containing DES for the purposes of data hiding will > generally not be eligible for an export license which permits > the product to the general public outside of the United States. Multiple encryption seems to be considered by the reviewing bodies to be more "dangerous" than DES. So: An implementation of ESP that supports the recursive encapsulation of ESP will generally not be eligible for an export license which permits the product to the general public outside of the United States. Our dialog here seems to be "flogging the dead horse of US export policy"... export of "good" encryption is possible, but not to the masses. To attempt to add a little value to this thread ... there was yet another NIST sponsored escrow/export meeting December 5. Minor modifications were made to the "Draft Software Key Escrow Encryption Export Criteria". The criteria promise to ease export if vendors institute escrow. Even with escrow, the criteria still limit key length to 64 bits :-( The criteria are avaialble at a NIST web site. After having heard (?) comments on the criteria the U.S. Department of State "anticipates issuing guidance incorporating these criteria, revised as appropriate based upon today's (Dec. 5) meeting, in early 1996." Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com -------------------------------------------------------------- From ipsec-request@ans.net Fri Dec 22 17:18:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA15327 (5.65c/IDA-1.4.4 for ); Fri, 22 Dec 1995 12:39:35 -0500 Received: by interlock.ans.net id AA10900 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 22 Dec 1995 12:32:25 -0500 Message-Id: <199512221732.AA10900@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 22 Dec 1995 12:32:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 22 Dec 1995 12:32:25 -0500 Date: Fri, 22 Dec 1995 11:18:39 -0600 (CST) From: Todd Graham Lewis To: Bill Sommerfeld Cc: "PALAMBER.US.ORACLE.COM" , daw@cs.berkeley.edu, ipsec@ans.net Subject: Re: ICMP Security Failures In-Reply-To: <199512212101.AA22124@interlock.ans.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Attention: NSA start quoting here for my indictment: I am pretty sure that I already know what the answer would be, but what if some hypothetical individual were working on a freely-distributable Linux ESP implementation that, say, included _no_ implementations but was easily extensible? I hate to clutter the list with politico-crypto-flame bait, but would this fall under the range of the "permissible"? Todd Graham Lewis todd@wooster.org On Thu, 21 Dec 1995, Bill Sommerfeld wrote: > > PS - Implementations that allow multiple encapsulation (ESP/ESP/IP, or > ESP/ESP/ESP/IP, etc.) may not be exportable as a product from the US. > Exportable implementations may be required to block ESP over ESP :-( > > Exportable implementations will probably not be allowed to implement > ESP at all since single-DES CBC is the mandatory ESP transform and > single-DES itself is not exportable. > > Given the requirement that ESP support manual keying, a conformant > implementation woulld also not likely be exportable under the proposed > (but hopefully irrelevant) "software key escrow"/"Clipper II" > regulations. > > BTW, given recent talks with the export control folks: they would probably > attempt to prevent export of ESP implementations which only supported ROT-13 > if they were too easy to modify to add other algorithms.. > > - Bill From ipsec-request@ans.net Fri Dec 22 20:07:41 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13601 (5.65c/IDA-1.4.4 for ); Fri, 22 Dec 1995 15:19:45 -0500 Received: by interlock.ans.net id AA14331 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 22 Dec 1995 15:10:07 -0500 Message-Id: <199512222010.AA14331@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 22 Dec 1995 15:10:07 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 22 Dec 1995 15:10:07 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Dec 1995 15:07:41 -0500 To: Todd Graham Lewis From: cfm@columbia.sparta.com (Carl F. Muckenhirn) Subject: Re: ICMP Security Failures Cc: Bill Sommerfeld , "PALAMBER.US.ORACLE.COM" , daw@cs.berkeley.edu, ipsec@ans.net At 11:18 am 12/22/95, Todd Graham Lewis wrote: >Attention: NSA start quoting here for my indictment: First, NSA doesn't indict anyone, that's up to the Atty. Gen. > >I am pretty sure that I already know what the answer would be, but what >if some hypothetical individual were working on a freely-distributable >Linux ESP implementation that, say, included _no_ implementations but was >easily extensible? I hate to clutter the list with politico-crypto-flame >bait, but would this fall under the range of the "permissible"? > >Todd Graham Lewis >todd@wooster.org > Cryptographic interface software has historically been lumped in with actual implementations vis a vis the ITARs. If you are really concerned consult an attorney. carl. From ipsec-request@ans.net Fri Dec 22 20:47:08 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14735 (5.65c/IDA-1.4.4 for ); Fri, 22 Dec 1995 15:59:20 -0500 Received: by interlock.ans.net id AA15327 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 22 Dec 1995 15:48:36 -0500 Message-Id: <199512222048.AA15327@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 22 Dec 1995 15:48:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 22 Dec 1995 15:48:36 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 22 Dec 1995 15:48:36 -0500 Date: Fri, 22 Dec 1995 15:47:08 -0500 From: Theodore Ts'o To: Todd Graham Lewis Cc: Bill Sommerfeld , "PALAMBER.US.ORACLE.COM" , daw@cs.berkeley.edu, ipsec@ans.net In-Reply-To: Todd Graham Lewis's message of Fri, 22 Dec 1995 11:18:39 -0600 (CST), <199512221732.AA10900@interlock.ans.net> Subject: Re: ICMP Security Failures Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Content-Length: 855 Date: Fri, 22 Dec 1995 11:18:39 -0600 (CST) From: Todd Graham Lewis I am pretty sure that I already know what the answer would be, but what if some hypothetical individual were working on a freely-distributable Linux ESP implementation that, say, included _no_ implementations but was easily extensible? I hate to clutter the list with politico-crypto-flame bait, but would this fall under the range of the "permissible"? Cough, cough..... Hypothetically, this individual would be best served if it included a ESP-based mechanism using a rot-13 or XOR-based encryption scheme, it only had an "internal, non-published" interface between the main body of the code and the XOR encryption module. - Ted P.S. What's in a name? Quite a lot, actually. A rose by any other name may not smell as sweet! From ipsec-request@ans.net Sat Dec 23 07:18:09 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13382 (5.65c/IDA-1.4.4 for ); Fri, 22 Dec 1995 17:22:08 -0500 Received: by interlock.ans.net id AA17653 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 22 Dec 1995 17:14:25 -0500 Message-Id: <199512222214.AA17653@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 22 Dec 1995 17:14:25 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 22 Dec 1995 17:14:25 -0500 X-Sender: caronni@ktik0.ethz.ch X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Dec 1995 23:18:09 -0800 To: ipsec@ans.net From: Germano Caronni Subject: Re: forward secrecy At 08:57 PM 12/15/95 -0500, Perry E. Metzger wrote: > >I'd like to note, as I periodically do, that SKIP is in no way >actually stateless. Thats just marketing hype by Ashar. In order to >use a SKIP datagram in any real system you are going to have to get >keys from a keyserver, thus almost completely obviating the claimed >advantages of SKIP. This is *not* true for any real system. Just for a (certainly very large) part of systems. By the way, could you please explain to me, why using a key server introduces state? >You can, of course, operate SKIP with statically configured keys -- >but in that case why not just run ESP and AH with statically >configured keys and get rid of the overhead? Even in this somewhat degenerated scenario SKIP still supports multiple name spaces, and allows for traffic keys and a (currently *very* coarse) playback protection. Native AH/ESP does not give you that. Friendly greetings, Germano From ipsec-request@ans.net Fri Dec 22 23:25:02 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10695 (5.65c/IDA-1.4.4 for ); Fri, 22 Dec 1995 18:32:37 -0500 Received: by interlock.ans.net id AA19012 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 22 Dec 1995 18:25:11 -0500 Message-Id: <199512222325.AA19012@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 22 Dec 1995 18:25:11 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 22 Dec 1995 18:25:11 -0500 Date: Fri, 22 Dec 1995 15:25:02 -0800 (PST) From: Phil Karn To: daw@cs.berkeley.edu Cc: ipsec@ans.net In-Reply-To: <199512200726.CAA03264@hiway1.exit109.com> (daw@cs.berkeley.edu) Subject: Re: ICMP Security Failures >Tunnelling is a very useful mode. It's most useful for routers, >bump-in-the-stack encryptors, IP forwarding (e.g. IP ``remailers''), >and perhaps also firewalls...but I don't think the utility is limited >to those situations. Absolutely! >It's important that implementors realize they must support this mode >of operation. The tunnel/transport modes aren't orthogonal, from >the implementation perspective: to support tunnel-mode, the IPSEC >modules must be re-entrant, and must deal with remembered security >state when processing IP headers. Implementors probably won't think >to support all this if it's not described explicitly in the spec. Again, I agree. Your point about re-entrancy is well taken. Perhaps we could word the requirement that way. We should specifically require that receiving implementations accept packets with arbitrarily nested AH/ESP/tunnel headers, even if they can't generate them. Exact language is open to discussion. Phil From ipsec-request@ans.net Sat Dec 23 00:53:25 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14452 (5.65c/IDA-1.4.4 for ); Fri, 22 Dec 1995 20:00:05 -0500 Received: by interlock.ans.net id AA20096 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 22 Dec 1995 19:53:30 -0500 Message-Id: <199512230053.AA20096@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 22 Dec 1995 19:53:30 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 22 Dec 1995 19:53:30 -0500 Date: Fri, 22 Dec 1995 16:53:25 -0800 From: Ran Atkinson To: ipsec@ans.net, caronni@tik.ee.ethz.ch Subject: Re: AH/ESP [Personal opinion] Germano, AH/ESP most certainly does support session keys (aka traffic keys) by using multiple Security Associations. AH/ESP also support multiple namespaces. Playback protection is a matter for the transforms at present, though that could be changed before Draft Standard IFF the WG wants to make that change and a specific proposal were made. The playback protection in SKIP is IMHO not worth what it costs to implement (i.e. its VERY low rent protection at present and not that hard to defeat). Regards, Ran rja@cisco.com From ipsec-request@ans.net Sat Dec 23 00:56:39 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14714 (5.65c/IDA-1.4.4 for ); Fri, 22 Dec 1995 20:01:51 -0500 Received: by interlock.ans.net id AA20129 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 22 Dec 1995 19:56:46 -0500 Message-Id: <199512230056.AA20129@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 22 Dec 1995 19:56:46 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 22 Dec 1995 19:56:46 -0500 Date: Fri, 22 Dec 1995 16:56:39 -0800 From: Ran Atkinson To: daw@cs.berkeley.edu, karn@qualcomm.com Subject: Re: ICMP Security Failures Cc: ipsec@ans.net Phil, Part of the reason for the current language is that implementations are currently required to at least implement support for IP tunnel-mode encryption (for BOTH sending and receiving) and also implement transport-mode (for BOTH sending and receiving). Clearer language is fine, but it is important that the requirement to implement both modes for BOTH sending and receiving needs to be clearly stated in the proposed language revisions. I don't think that saying that reintrancy on receive side is a sufficient statement, though it is necessary. Ran rja@cisco.com From ipsec-request@ans.net Sat Dec 23 02:01:48 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10535 (5.65c/IDA-1.4.4 for ); Fri, 22 Dec 1995 21:08:22 -0500 Received: by interlock.ans.net id AA20824 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Fri, 22 Dec 1995 21:02:00 -0500 Message-Id: <199512230202.AA20824@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Fri, 22 Dec 1995 21:02:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Fri, 22 Dec 1995 21:02:00 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Fri, 22 Dec 1995 21:02:00 -0500 Date: Fri, 22 Dec 1995 19:01:48 -0700 From: Hilarie Orman To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199512230056.AA20129@interlock.ans.net> Subject: Re: ICMP Security Failures I've found it useful to describe the possible combinations in terms of a regular expression consisting of IP, AH, and ESP. Here are a couple of questions: Suppose a sequence of headers involves several different identities; may a host have a local policy rejecting some or all such combinations and still be conforming? Also, must/should the ip-in-ip protocol be supported? From ipsec-request@ans.net Sat Dec 23 11:08:13 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13718 (5.65c/IDA-1.4.4 for ); Sat, 23 Dec 1995 06:16:21 -0500 Received: by interlock.ans.net id AA03728 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sat, 23 Dec 1995 06:07:05 -0500 Message-Id: <199512231107.AA03728@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sat, 23 Dec 1995 06:07:05 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sat, 23 Dec 1995 06:07:05 -0500 Date: Sat, 23 Dec 1995 13:08:13 +0200 From: Tatu Ylonen To: "PALAMBER.US.ORACLE.COM" Cc: tytso@mit.edu, ipsec@ans.net Subject: Re: ESP over ESP was Re: ICMP Security Failures In-Reply-To: <199512221641.AA09381@interlock.ans.net> References: <199512221641.AA09381@interlock.ans.net> Organization: Helsinki University of Technology, Finland > An implementation of ESP that supports the recursive encapsulation > of ESP will generally not be eligible for an export license which > permits the product to the general public outside of the United States. Since the United States at present generally only allows export of products that are breakable even by individual hackers, not to mention organized criminal, major corporations, and governments, in my opinion it is better to not include stuff in the standard that would undermine its original goals by rendering it again insecure. If we are seeking to solve the security problems on the internet, please lets do it right this time. If the US corporations cannot export products that provide a decent level of security, I am sure there will be other companies outside the United States who will. The techniques themselves are very widespread. (Some information on foreign availability can be found at http://www.cs.hut.fi/crypto.) Tatu From ipsec-request@ans.net Sun Dec 24 00:10:08 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14329 (5.65c/IDA-1.4.4 for ); Sun, 24 Dec 1995 00:10:08 -0500 Received: by interlock.ans.net id AA23878 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 24 Dec 1995 00:02:04 -0500 Message-Id: <199512240502.AA23878@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 24 Dec 1995 00:02:04 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 24 Dec 1995 00:02:04 -0500 Date: Sat, 23 Dec 1995 21:01:55 -0800 (PST) From: Phil Karn To: ho@cs.arizona.edu Cc: rja@cisco.com, ipsec@ans.net In-Reply-To: <199512230202.AA20824@interlock.ans.net> (message from Hilarie Orman on Fri, 22 Dec 1995 19:01:48 -0700) Subject: Re: ICMP Security Failures >I've found it useful to describe the possible combinations in terms of >a regular expression consisting of IP, AH, and ESP. Seems to me that any combination of these protocols is possible, if not necessarily useful. All three have 8-bit protocol fields in their headers that refer to one of the Internet transport protocols, including IP (4), AH (51) and ESP (50). >Suppose a sequence of headers involves several different identities; >may a host have a local policy rejecting some or all such combinations >and still be conforming? Local policies can reject anything they want. But the implementation itself can't be the cause of the rejection, i.e., if the policy is to permit something, the implementation should allow it. >Also, must/should the ip-in-ip protocol be supported? That's tunnel mode. Yes, it should be supported, though the requirements for its use are always subject to local policy. Phil From ipsec-request@ans.net Sun Dec 24 20:17:30 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA12010 (5.65c/IDA-1.4.4 for ); Sun, 24 Dec 1995 06:21:23 -0500 Received: by interlock.ans.net id AA26559 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Sun, 24 Dec 1995 06:13:45 -0500 Message-Id: <199512241113.AA26559@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Sun, 24 Dec 1995 06:13:45 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Sun, 24 Dec 1995 06:13:45 -0500 X-Sender: caronni@ktik0.ethz.ch X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 24 Dec 1995 12:17:30 -0800 To: Ran Atkinson , ipsec@ans.net From: Germano Caronni Subject: Re: AH/ESP / Replay Protection At 16:53 22.12.95 -0800, Ran Atkinson wrote: >AH/ESP most certainly does support session keys (aka traffic keys) by using >multiple Security Associations. AH/ESP also support multiple namespaces. Agreed. The problem was that I was comparing SKIP against AH/ESP, should have compared it against Photuris. AH/ESP certainly allows for session keys. But only Photuris (and SKIP) realize them. Point taken. >Playback protection is a matter for the transforms at present, though that >could be changed before Draft Standard IFF the WG wants to make that change >and a specific proposal were made. What about having a separate 'Replay Protection Header/Protocol' as suggested by different persons? Or does everybody agree that replay protection makes only sense if authentication via an AH or a (combined) authenticating ESP transform takes place? In one case we have a new header and protocol type, in the other case we have keyed MD5, nested MD5, SHA, ... and all these with replay protection added -> a multitude of transforms. What would be preferable? >The playback protection in SKIP is IMHO not worth what it costs to implement >(i.e. its VERY low rent protection at present and not that hard to defeat). It is defeated if you can change clocks in a radical manner. But in that case, as already pointed out somewhere, any system using key lifetimes and other timing information is in danger. (btw, the cost to implement the hourly 'n' is rather small. And I sure can tell ;-) ) At the moment it seems better to me to have 'n' and a 3 hour granularity, than a granularity of up to [lifetime of top-level shared secret in Photuris, on a system with a large amount of traffic] (meaning the 'knobs' are turned towards 'performance' and not 'maximum security'). I am not sure how long a shared secrect may be kept valid... Sure, a dedicated mechanism for replay protection would be better. Merry Christmas and a happy new year to you all! Germano From ipsec-request@ans.net Tue Dec 26 18:08:21 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13809 (5.65c/IDA-1.4.4 for ); Tue, 26 Dec 1995 13:17:33 -0500 Received: by interlock.ans.net id AA23676 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 26 Dec 1995 13:08:26 -0500 Message-Id: <199512261808.AA23676@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 26 Dec 1995 13:08:26 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 26 Dec 1995 13:08:26 -0500 Date: Tue, 26 Dec 1995 10:08:21 -0800 From: Ran Atkinson To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection [Personal opinion] All, I am concerned about the potentially exponential increase in header combinations that would be encouraged by having a separate replay protection header. I'd MUCH rather see a trend towards ESP transforms that provide more capabilities (such as the combined transform that provides both integrity and confidentiality) than towards more headers. Ignoring other concerns for the moment, implementation complexity increases a lot when there are multiple headers that are interacting. The greater the implementation complexity, the higher the probability of interoperability problems. Regards, Ran rja@cisco.com From ipsec-request@ans.net Tue Dec 26 19:34:50 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA11174 (5.65c/IDA-1.4.4 for ); Tue, 26 Dec 1995 16:22:15 -0500 Received: by interlock.ans.net id AA26826 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 26 Dec 1995 16:11:03 -0500 Message-Id: <199512262111.AA26826@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 26 Dec 1995 16:11:03 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 26 Dec 1995 16:11:03 -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-skip-mc-00.txt Date: Tue, 26 Dec 95 14:34:50 -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 IP Security Protocol Working Group of the IETF. Title : SKIP Extensions for IP Multicast Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-mc-00.txt Pages : 11 Date : 12/22/1995 This document describes extensions to the base SKIP [1] protocol to allow encrypted/authenticated multicast communications. 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-skip-mc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-mc-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-skip-mc-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: <19951222131916.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-mc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-mc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951222131916.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Dec 26 19:34:27 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13993 (5.65c/IDA-1.4.4 for ); Tue, 26 Dec 1995 16:22:17 -0500 Received: by interlock.ans.net id AA26837 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 26 Dec 1995 16:11:20 -0500 Message-Id: <199512262111.AA26837@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 26 Dec 1995 16:11:20 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 26 Dec 1995 16:11:20 -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-skip-udh-00.txt Date: Tue, 26 Dec 95 14:34:27 -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 IP Security Protocol Working Group of the IETF. Title : Encoding of an Unsigned Diffie-Hellman Public Value Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-udh-00.txt Pages : 6 Date : 12/22/1995 It is useful to be able to communicate public keys in the absence of a certificate hierarchy and a signature infrastructure. This document describes a method by which certificates which communicate Diffie-Hellman public values and parameters may be encoded and securely named. 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-skip-udh-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-udh-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-skip-udh-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: <19951222130915.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-udh-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-udh-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951222130915.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Dec 26 19:34:32 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13484 (5.65c/IDA-1.4.4 for ); Tue, 26 Dec 1995 16:22:17 -0500 Received: by interlock.ans.net id AA26815 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 26 Dec 1995 16:10:43 -0500 Message-Id: <199512262110.AA26815@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 26 Dec 1995 16:10:43 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 26 Dec 1995 16:10: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 Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ipsec-cdp-00.txt Date: Tue, 26 Dec 95 14:34:32 -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 IP Security Protocol Working Group of the IETF. Title : Certificate Discovery Protocol Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-cdp-00.txt Pages : 13 Date : 12/22/1995 Use of Public key cryptography is becoming widespread on the Internet in such applications as electronic mail and IP Security (IPSEC). Currently, however, a common public key certificate infrastructure does not exist which is interoperable with other systems and ubiquitous. In light of this, we describe a protocol which may be used to exchange or retrieve certificates (essentially signed public keys) with or from another entity. The protocol may be used to request certificates from a directory/name server or from the entity who owns the certificate. 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-cdp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-cdp-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-cdp-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: <19951222131320.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-cdp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-cdp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951222131320.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Dec 26 19:34:22 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA10674 (5.65c/IDA-1.4.4 for ); Tue, 26 Dec 1995 16:22:20 -0500 Received: by interlock.ans.net id AA26808 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 26 Dec 1995 16:10:38 -0500 Message-Id: <199512262110.AA26808@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 26 Dec 1995 16:10:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 26 Dec 1995 16:10:38 -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-skip-x509-00.txt Date: Tue, 26 Dec 95 14:34:22 -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 IP Security Protocol Working Group of the IETF. Title : X.509 Encoding of Diffie-Hellman Public Values Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-x509-00.txt Pages : 6 Date : 12/22/1995 This document describes the ASN.1 [1] encoding of the CCITT 1988 X.509 [2] certificate with Diffie-Hellman public values for use with SKIP [5]. 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-skip-x509-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-x509-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-skip-x509-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: <19951222130534.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-x509-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-x509-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951222130534.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Dec 26 19:34:44 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA14263 (5.65c/IDA-1.4.4 for ); Tue, 26 Dec 1995 16:22:21 -0500 Received: by interlock.ans.net id AA26822 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 26 Dec 1995 16:10:52 -0500 Message-Id: <199512262110.AA26822@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 26 Dec 1995 16:10:52 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 26 Dec 1995 16:10:52 -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-skip-adp-00.txt Date: Tue, 26 Dec 95 14:34:44 -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 IP Security Protocol Working Group of the IETF. Title : SKIP Algorithm Discovery Protocol Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-adp-00.txt Pages : 7 Date : 12/22/1995 SKIP [1] provides privacy and authentication with Internet Protocols. It does not define a method by which two entities may mutually agree on encryption, authentication and compression algorithms. We describe a protocol which will allow one SKIP entity to inform another entity of the capabilities it supports. 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-skip-adp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-adp-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-skip-adp-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: <19951222131622.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-adp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-adp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951222131622.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From ipsec-request@ans.net Tue Dec 26 19:34:17 1995 Received: from interlock.ans.net by ftp.ans.net with SMTP id AA13753 (5.65c/IDA-1.4.4 for ); Tue, 26 Dec 1995 16:22:22 -0500 Received: by interlock.ans.net id AA26809 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Tue, 26 Dec 1995 16:10:38 -0500 Message-Id: <199512262110.AA26809@interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 26 Dec 1995 16:10:38 -0500 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 26 Dec 1995 16:10:38 -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-skip-06.txt Date: Tue, 26 Dec 95 14:34:17 -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 IP Security Protocol Working Group of the IETF. Title : Simple Key-Management For Internet Protocols (SKIP) Author(s) : A. Aziz, T. Markson, H. Prafullchandra Filename : draft-ietf-ipsec-skip-06.txt Pages : 34 Date : 12/22/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 (for example, IPv4 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 IPv4 or IPv6. SKIP has been designed to work with the IP Security Protocols AH and ESP [8, 9, 10] which are specified for both IPv4 and IPv6. 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-skip-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-06.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) 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-skip-06.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: <19951222130138.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-skip-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-skip-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951222130138.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From majordom@p-o.ans.net Tue Dec 26 11:36:16 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14045 (5.65c/IDA-1.4.4 for ); Tue, 26 Dec 1995 16:36:34 -0500 Received: by p-o.ans.net id AA04199 (5.65c/IDA-1.4.4 for ipsec-outgoing); Tue, 26 Dec 1995 21:36:24 GMT Message-Id: <199512262136.AA27391@interlock.ans.net> Date: Tue, 26 Dec 95 16:36:16 EST From: Ka Kau Chan To: ipsec@ans.net Position: Associate Engineer, Management Information Systems Company: ANS CO+RE Systems - Elmsford, NY Phone: (914) 789-5387 Subject: final test (hopefully), please ignore Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net ignore From majordom@p-o.ans.net Wed Dec 27 19:52:15 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13514 (5.65c/IDA-1.4.4 for ); Wed, 27 Dec 1995 15:02:21 -0500 Received: by p-o.ans.net id AA21391 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 27 Dec 1995 19:52:46 GMT Date: Wed, 27 Dec 1995 12:52:15 -0700 From: Hilarie Orman Message-Id: <9512271952.AA19612@uncial.CS.Arizona.EDU> To: karn@qualcomm.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199512240502.AA23878@interlock.ans.net> Subject: Re: ICMP Security Failures Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >>I've found it useful to describe the possible combinations in terms of >>a regular expression consisting of IP, AH, and ESP. > >Seems to me that any combination of these protocols is possible, if >not necessarily useful. All three have 8-bit protocol fields in their >headers that refer to one of the Internet transport protocols, >including IP (4), AH (51) and ESP (50). Some combinations may not be possible, due to ambiguities in processing order. For example, IP-AH-AH or IP-ESP-AH. From majordom@p-o.ans.net Wed Dec 27 20:12:52 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13838 (5.65c/IDA-1.4.4 for ); Wed, 27 Dec 1995 15:20:06 -0500 Received: by p-o.ans.net id AA16913 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 27 Dec 1995 20:13:04 GMT Message-Id: <9512272012.AA22452@maildig1.us.oracle.com> Date: Wed, 27 Dec 1995 12:12:52 -0800 From: "RWESSMAN.US.ORACLE.COM" To: ipsec@ans.net Subject: Out of office 12/20-12/27 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Boundary-15075820-0-0 Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net --Boundary-15075820-0-0 I will be out of the office from 12/20-12/27. I will not be monitoring either voice mail or e-mail. For questions about Secure Network Services, please contact Paul Lambert (palamber). Thanks, Rick --Boundary-15075820-0-0 Content-Type: message/rfc822 Date: 27 Dec 95 12:52:15 From:"Hilarie Orman " To: karn@qualcomm.com Subject: Re: ICMP Security Failures Cc: ipsec@ans.net Reply-to: ipsec@ans.net X-Orcl-Application: In-Reply-To: Yourmessage <199512240502.AA23878@interlock.ans.net> X-Orcl-Application: Sender: ipsec-owner@ans.net X-Orcl-Application: Precedence: bulk >>I've found it useful to describe the possible combinations in terms of >>a regular expression consisting of IP, AH, and ESP. > >Seems to me that any combination of these protocols is possible, if >not necessarily useful. All three have 8-bit protocol fields in their >headers that refer to one of the Internet transport protocols, >including IP (4), AH (51) and ESP (50). Some combinations may not be possible, due to ambiguities in processing order. For example, IP-AH-AH or IP-ESP-AH. --Boundary-15075820-0-0-- From majordom@p-o.ans.net Wed Dec 27 21:23:36 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15058 (5.65c/IDA-1.4.4 for ); Wed, 27 Dec 1995 16:34:17 -0500 Received: by p-o.ans.net id AA40980 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 27 Dec 1995 21:28:04 GMT To: ipsec@ans.net Subject: Re: ICMP Security Failures In-Reply-To: Your message of "Wed, 27 Dec 1995 12:52:15 MST." <9512271952.AA19612@uncial.CS.Arizona.EDU> Date: Wed, 27 Dec 1995 16:23:36 -0500 From: Craig Metz Message-Id: <9512271623.aa07357@cs.nrl.navy.mil> Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In message <9512271952.AA19612@uncial.CS.Arizona.EDU>, Hilarie Orman writes: >Some combinations may not be possible, due to ambiguities in >processing order. For example, IP-AH-AH or IP-ESP-AH. I think IP-AH-AH is valid, though maybe not very useful. You would process those in order, i.e., the first AH would cover the payload, and the second AH would cover the first AH and the payload. I don't think IP-ESP-AH is valid -- it would have to be IP-ESP-IP-AH. -Craig From majordom@p-o.ans.net Wed Dec 27 21:59:19 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11581 (5.65c/IDA-1.4.4 for ); Wed, 27 Dec 1995 17:08:31 -0500 Received: by p-o.ans.net id AA13275 (5.65c/IDA-1.4.4 for ipsec-outgoing); Wed, 27 Dec 1995 21:59:29 GMT Date: Wed, 27 Dec 1995 14:59:19 -0700 From: Hilarie Orman Message-Id: <9512272159.AA21296@uncial.CS.Arizona.EDU> To: cmetz@sundance.itd.nrl.navy.mil Cc: ipsec@ans.net In-Reply-To: Yourmessage <9512271623.aa07357@cs.nrl.navy.mil> Subject: Re: ICMP Security Failures Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > I think IP-AH-AH is valid, though maybe not very useful. You > would process those in order, i.e., the first AH would cover the payload, > and the second AH would cover the first AH and the payload. ?? Do you derive this interpretation from the RFC's? What sense would you make of the IP length field during this? From majordom@p-o.ans.net Thu Dec 28 04:57:45 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14820 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 00:45:17 -0500 Received: by p-o.ans.net id AA38194 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 28 Dec 1995 05:20:47 GMT Date: Thu, 28 Dec 95 04:57:45 GMT From: "William Allen Simpson" Message-Id: <4671.bsimpson@morningstar.com> To: ipsec@ans.net Subject: AH and ESP Combinations Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: Craig Metz > In message <9512271952.AA19612@uncial.CS.Arizona.EDU>, Hilarie Orman writes: > >Some combinations may not be possible, due to ambiguities in > >processing order. For example, IP-AH-AH or IP-ESP-AH. > > I think IP-AH-AH is valid, though maybe not very useful. You > would process those in order, i.e., the first AH would cover the payload, > and the second AH would cover the first AH and the payload. > No, I don't think that is valid. AH specifically covers the IP header, including the Length, and it would be pretty hard to figure out the length used in each. Presumably, we could define it so that the inner one used the Length which was appropriate without the outer one, and the outer one used a Length including both inner and outer. But, I think it is easier to outlaw the construct. > I don't think IP-ESP-AH is valid -- it would have to be IP-ESP-IP-AH. > The current text allows AH inside without IP, but I think it is ambiguous. Let's explicitly disallow this one, too. We need a major revision of the Architecture, I think. Only a few cases, with each clearly specified, would help interoperability. 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 majordom@p-o.ans.net Thu Dec 28 05:06:58 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12770 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 00:45:17 -0500 Received: by p-o.ans.net id AA41011 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 28 Dec 1995 05:20:48 GMT Date: Thu, 28 Dec 95 05:06:58 GMT From: "William Allen Simpson" Message-Id: <4672.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: I-D ACTION:draft-krawczyk-keyed-md5-01.txt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net I finally had time to read the draft, and I find it unconvincing. It has several inaccuracies, some unsubstantiated claims, and has insufficient detail to understand why the proposed double hash is any more robust than the current technique in the face of a weakness of the compression function of MD5 (or anything else). I haven't yet read his reference, to be published elsewhere. Perhaps Hugo could combine the two in the internet-draft to make it more understandable. 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 majordom@p-o.ans.net Thu Dec 28 07:34:48 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13588 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 03:04:57 -0500 Received: by p-o.ans.net id AA40052 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 28 Dec 1995 07:35:01 GMT Date: Thu, 28 Dec 1995 02:34:48 -0500 Message-Id: <199512280734.CAA18874@hiway1.exit109.com> X-Sender: mpwagner@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: daw@cs.berkeley.edu (David Wagner) Subject: Re: ICMP Security Failures Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Craig Metz writes: >Hilarie Orman writes: >>Some combinations may not be possible, due to ambiguities in >>processing order. For example, IP-AH-AH or IP-ESP-AH. > > I think IP-AH-AH is valid, though maybe not very useful. You >would process those in order, i.e., the first AH would cover the payload, >and the second AH would cover the first AH and the payload. > > I don't think IP-ESP-AH is valid -- it would have to be >IP-ESP-IP-AH. No, sadly, I don't think IP-AH-AH is safe to use with today's AH spec. It has been decided (or "decided"?) that the AH header covers some stuff preceding it, not just the payload: at least part of the previous IP header, and everything following it, is protected. You could probably implement IP-AH-AH by constructing a skeleton of all the headers in the first pass, zeroing out the Authentication Data field in each AH header & zeroing other relevant stuff in the IP header, and then do the relevant MAC calculations in a second pass. This is a royal pain in the ass. The other implementation strategy is to completely fill out the inner AH header in a first pass, and then completely fill out the outer AH header in a second pass (noting that the IP header will have changed between the two passes in this case). The two algorithms will NOT be compatible. (The issue is whether to use the same IP header values when calculating both MACs.) The AH document doesn't specify which algorithm to use, as far as I can see. I also didn't find anything in the AH spec to indicate clearly whether IP-AH-AH is compliant. I suspect it's invalid. Clarification, anyone? (A quote from the AH spec would be nice.) In short, IMHO, I think the AH spec is deficient when it comes to multiple uses of ipsec headers. (In clarity, at least, and perhaps in design too: see below.) Obligatory repetitive bitching and moaning: If AH didn't try to protect bits of the datagram that precede the AH header (or used a pseudo-header), there wouldn't be a problem: IP-AH-AH and IP-ESP-AH would be valid & trivial to handle, as would other more complicated combinations. From majordom@p-o.ans.net Thu Dec 28 11:58:09 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14914 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 07:25:04 -0500 Received: by p-o.ans.net id AA38329 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 28 Dec 1995 11:58:29 GMT To: ipsec@ans.net Subject: Re: ICMP Security Failures In-Reply-To: Your message of "Thu, 28 Dec 1995 02:34:48 EST." <199512280734.CAA18874@hiway1.exit109.com> Date: Thu, 28 Dec 1995 06:58:09 -0500 From: Craig Metz Message-Id: <9512280658.aa08088@cs.nrl.navy.mil> Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net In message <199512280734.CAA18874@hiway1.exit109.com>, David Wagner writes: >Craig Metz writes: >> I think IP-AH-AH is valid, though maybe not very useful. You >>would process those in order, i.e., the first AH would cover the payload, >>and the second AH would cover the first AH and the payload. >> >> I don't think IP-ESP-AH is valid -- it would have to be >IP-ESP-IP-AH. > >No, sadly, I don't think IP-AH-AH is safe to use with today's AH spec. I never said it's safe. A layered implementation that fixes up the IP header as it goes along the processing path could do it, though. There's nothing explicitly saying in the spec that it could or couldn't be done. (There's some haze here, but we really only want an AH to be able to cover an IP header that actually exists on the wire, not some possible fabrication of a stack) -Craig From majordom@p-o.ans.net Thu Dec 28 12:05:15 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14663 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 07:27:31 -0500 Received: by p-o.ans.net id AA27379 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 28 Dec 1995 12:08:34 GMT To: ipsec@ans.net Subject: Re: ICMP Security Failures In-Reply-To: Your message of "Thu, 28 Dec 1995 06:58:09 EST." Date: Thu, 28 Dec 1995 07:05:15 -0500 From: Craig Metz Message-Id: <9512280705.aa08122@cs.nrl.navy.mil> Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net I wrote: >(There's some haze here, but we really only want an AH to be able to cover an >IP header that actually exists on the wire, not some possible fabrication of >a stack) Well, maybe that isn't so. Consider: IP-ESP-[IP-AH]. The encrypted [IP-AH] doesn't actually exist on the wire, but is a predictable intermediate result in the network stack's processing and is something that we really might want an AH to be able to cover. -Craig From majordom@p-o.ans.net Thu Dec 28 06:01:05 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14661 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 11:38:25 -0500 Received: by p-o.ans.net id AA41027 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 28 Dec 1995 16:19:05 GMT Message-Id: <199512281618.AA02386@interlock.ans.net> Date: Thu, 28 Dec 95 11:01:05 EST From: hugo@watson.ibm.com To: ipsec@ans.net Subject: I-D ACTION:draft-krawczyk-keyed-md5-01.txt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Ref: Your note of Thu, 28 Dec 95 05:06:58 GMT (attached) Bill, > I finally had time to read the draft, and I find it unconvincing. The draft was intended to describe the function and to give some minimal background. For a full rationale you'll have to read the paper which will be available in two weeks. > > It has several inaccuracies, some unsubstantiated claims, and has > insufficient detail to understand why the proposed double hash is any > more robust than the current technique in the face of a weakness of the > compression function of MD5 (or anything else). Please point to me any inaccuracies you found so I can correct/clarify in future versions. If by "unsubstantiated claims" you mean the missing mathematical analysis that's fine. As I said the draft is not intended to convey that information. However, excluding the pure technical details I have provided much of the information on the function's rationale during my presentation in Dallas and a note to this list that I sent before Dallas. I will send a copy of that note to you personally in case you missed it. Hugo PS: As for the general mathematical theory behind this type of functions you can read the BCK1 reference in the draft which can be retrieved from the Web as I have already pointed out in the past. From majordom@p-o.ans.net Thu Dec 28 02:04:19 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14872 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 13:21:00 -0500 Received: by p-o.ans.net id AA14535 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 28 Dec 1995 18:03:53 GMT Date: Thu, 28 Dec 95 10:04:19 PST From: rja@rja-ss20.cisco.com (Randall Atkinson) Message-Id: <9512281804.AA09641@rja-ss20.cisco.com.noname> To: ipsec@ans.net Subject: Re: ICMP Security Failures Newsgroups: cisco.external.ietf.ipsec In-Reply-To: <199512280734.CAA18874@hiway1.exit109.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net IMHO, the combination of IP-AH-AH-ULP isn't sensible. It adds no value to the IP-AH-ULP combination. Similarly, the combination of IP-ESP-AH-ULP or IP-AH-ESP-ULP isn't very sensible. Both of those should use IP-ESP-ULP with an ESP transform combining confidentiality with strong integrity. >Obligatory repetitive bitching and moaning: > >If AH didn't try to protect bits of the datagram that precede the >AH header (or used a pseudo-header), there wouldn't be a problem: >IP-AH-AH and IP-ESP-AH would be valid & trivial to handle, as would >other more complicated combinations. If AH didn't protect bits of the IP header, then AH would be useless because it wouldn't provide efficient packet-origin authentication, which is one of the main points of using AH. While a pseudo-header might appeal to those more concerned with theoretical purity than with practicality, there is ample evidence that AH as currently specified can be built and interoperate. In Dallas several independent implementations were shown to interoperate using AH, to give a concrete example. Ran rja@cisco.com From majordom@p-o.ans.net Thu Dec 28 09:05:12 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14224 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 14:24:35 -0500 Received: by p-o.ans.net id AA41122 (5.65c/IDA-1.4.4 for ipsec-outgoing); Thu, 28 Dec 1995 19:07:32 GMT Message-Id: <199512281907.AA06017@interlock.ans.net> From: smb@research.att.com To: ipsec@ans.net Subject: Re: ICMP Security Failures Date: Thu, 28 Dec 95 14:05:12 EST Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net If AH didn't protect bits of the IP header, then AH would be useless because it wouldn't provide efficient packet-origin authentication, which is one of the main points of using AH. While a pseudo-header might appeal to those more concerned with theoretical purity than with practicality, there is ample evidence that AH as currently specified can be built and interoperate. In Dallas several independent implementations were shown to interoperate using AH, to give a concrete example. As has been pointed out in the past, if the SPI is bound to a source address it doesn't matter if the address in the packet is protected or not. But you're right; that issue has been discussed ad infinitum. I'm more concerned with two other issues. The first is what we're really arguing about here -- a mismatch between the syntax of header composition and the semantics of (a) what we want to do, and (b) the ways we can request such things, via (for example) Photuris. Syntactically, we can build any sequence of nested headers. There are some definition issues with respect to AH -- and that alone should raise a warning flag -- but for the most part, we can comgine anything with anything else. On the other hand, it isn't clear that most combinations make sense. Furthermore, what the user and/or the user's program wants is to say things like ``confidential'', ``authentic'', ``protected between these two gateways'', etc. At the very least, we need an RFC (or a section of the architecture RFC) that maps such concepts into a particular set of headers. But that's another warning flag, that we have a structure so general that we need to define a profile of standard subsets for interoperability. That way lies GOSIP and other forms of madness. It isn't clear to me what the right answer is. We could accept the full generality, and redefine AH and ESP to permit that. A necessary consequence would be that we'd have to enhance Photuris to list the desired choices for each nested header in a sequence. From the sending side, the semantics are clear; it's less obvious how to handle that on the receiving side, since the user will have specified high-level concepts like ``confidential''. Another choice would be to admit that ESP is wrong, and to produce a new AESP protocol that provides authentication and confidentiality. We could add the (very necessary) replay protection at the same time. (I confess I don't understand where one might want confidentiality without authentication.) Then our choice set is much reduced. Finally -- and in the real world, this is probably the right answer -- we could have a very simple set of rules for legal header sequences. Perhaps something like IP-AH-transp IP-AH-ESP-transp (or switch ESP and AH if you want) with tunnel mode -- IP+anything -- allowed instead of transp. That is, if you want to play funny games, such as multiple levels of authentication, tunnel it and ignore the (miniscule) efficiency gains from leaving out an extra IP header. In a totally different vein, it isn't clear to me that it makes sense to tie anything to IP addresses, and therefore to protect them. While I'm not yet ready to make any suggestions, the ipsec community should review Christian Huitema's multihome draft to see where my concerns are coming from. From majordom@p-o.ans.net Fri Dec 29 00:31:16 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14363 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 21:07:29 -0500 Received: by p-o.ans.net id AA16969 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 02:02:58 GMT Date: Fri, 29 Dec 95 00:31:16 GMT From: "William Allen Simpson" Message-Id: <4676.bsimpson@morningstar.com> To: ipsec@ans.net Subject: AH and ESP Combinations Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net First of all, you folks are still using the ICMP Subject. Could you please use better subject lines? > From: smb@research.att.com > It isn't clear to me what the right answer is. We could accept the > full generality, and redefine AH and ESP to permit that. A necessary > consequence would be that we'd have to enhance Photuris to list the > desired choices for each nested header in a sequence. As was suggested in our terminal room and lunch BOFs. I have made this change to Photuris. 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 majordom@p-o.ans.net Fri Dec 29 00:19:14 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13340 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 21:07:29 -0500 Received: by p-o.ans.net id AA22587 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 02:02:46 GMT Date: Fri, 29 Dec 95 00:19:14 GMT From: "William Allen Simpson" Message-Id: <4674.bsimpson@morningstar.com> To: ipsec@ans.net Subject: AH and ESP Combinations Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: rja@rja-ss20.cisco.com (Randall Atkinson) > IMHO, the combination of IP-AH-AH-ULP isn't sensible. It adds no value > to the IP-AH-ULP combination. > Probably true. > Similarly, the combination of IP-ESP-AH-ULP or IP-AH-ESP-ULP isn't very > sensible. Both of those should use IP-ESP-ULP with an ESP transform > combining confidentiality with strong integrity. > I firmly disagree. Indeed, the whole point of separating AH from ESP was that the authentication function should be separate and orthogonal to the encryption function. I doubt that the WG would have ever gotten done otherwise. Even when ESP provides integrity (and we do not have any such encryption technique specified), there will still be a need for authentication which is separate from the encryption. You were chastized (by others) previously for this error in your RFCs, and I hope that you have fixed it in your next versions for Draft Standard. 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 majordom@p-o.ans.net Fri Dec 29 04:21:27 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14138 (5.65c/IDA-1.4.4 for ); Thu, 28 Dec 1995 23:26:07 -0500 Received: by p-o.ans.net id AA41624 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 04:21:37 GMT Date: Thu, 28 Dec 1995 20:21:27 -0800 (PST) From: Phil Karn Message-Id: <199512290421.UAA08879@servo.qualcomm.com> To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: <199512261808.AA23676@interlock.ans.net> (message from Ran Atkinson on Tue, 26 Dec 1995 10:08:21 -0800) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >I am concerned about the potentially exponential increase in header >combinations that would be encouraged by having a separate replay >protection header. What's wrong with lots of permissible header combinations? It's easy to support an arbitrary sequence of headers, you just parse and decode each one in sequence. >I'd MUCH rather see a trend towards ESP transforms that provide more >capabilities (such as the combined transform that provides both >integrity and confidentiality) than towards more headers. I mildly agree that I'd like to see some more capable ESP modes, but for a different reason -- reduced total header overhead compared to combining separate protocols in modular tinker-toy fashion. The big problem with integrated authentication/encryption ESP modes, and the reason I don't support them as strongly as I used to, is that here's where you can get the real explosion of implementation complexity. I already support six different ESP transforms in my code -- DES and 3DES, each with 0-bit, 32-bit and 64-bit IVs. Most of my esp_input and esp_output routines consist of switch statements on the encapsulation mode, and its likely to get much worse when I start folding in authentication. For starters it will double the total number of modes to 12, the six I already support plus those six with MD5 authentication. Then somebody will want to add SHA for extra security, and somebody else will probably want a "shortened MD5" for less overhead on slow links. And *then* somebody will want IDEA and SAFER cipher support... you get the idea? Phil From majordom@p-o.ans.net Fri Dec 29 04:57:30 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14221 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 00:01:42 -0500 Received: by p-o.ans.net id AA22549 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 04:57:53 GMT Date: Thu, 28 Dec 1995 20:57:30 -0800 (PST) From: Phil Karn Message-Id: <199512290457.UAA08958@servo.qualcomm.com> To: ho@cs.arizona.edu Cc: ipsec@ans.net In-Reply-To: <9512271952.AA19612@uncial.CS.Arizona.EDU> (message from Hilarie Orman on Wed, 27 Dec 1995 12:52:15 -0700) Subject: Re: ICMP Security Failures Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >Some combinations may not be possible, due to ambiguities in >processing order. For example, IP-AH-AH or IP-ESP-AH. What do you mean? I agree that they might not be especially useful, but if you encode a packet like that they're still not ambiguous. Phil From majordom@p-o.ans.net Fri Dec 29 05:06:15 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15042 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 00:09:44 -0500 Received: by p-o.ans.net id AA11107 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 05:06:24 GMT Date: Thu, 28 Dec 1995 21:06:15 -0800 (PST) From: Phil Karn Message-Id: <199512290506.VAA08980@servo.qualcomm.com> To: ipsec@ans.net In-Reply-To: <199512280734.CAA18874@hiway1.exit109.com> (daw@cs.berkeley.edu) Subject: Re: ICMP Security Failures Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >The other implementation strategy is to completely fill out the >inner AH header in a first pass, and then completely fill out the >outer AH header in a second pass (noting that the IP header will >have changed between the two passes in this case). This is the most obvious and straightforward way to handle this case. It's equivalent to using a pseudo-header that happens to be a copy of the current IP header, with the length updated to include only those headers that have been added to the packet so far. You always build a packet from right to left, and you parse it left to right. Phil From majordom@p-o.ans.net Fri Dec 29 15:07:27 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA14484 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 10:13:39 -0500 Received: by p-o.ans.net id AA44748 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 15:08:03 GMT From: Uwe Ellermann Date: Fri, 29 Dec 1995 16:07:27 +0100 Message-Id: <199512291507.QAA17151@cops.cert.dfn.de> To: ipsec@ans.net Subject: Re: ICMP Security Failures X-Sun-Charset: US-ASCII Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: rja@rja-ss20.cisco.com (Randall Atkinson) > IMHO, the combination of IP-AH-AH-ULP isn't sensible. It adds no value > to the IP-AH-ULP combination. > How would two hosts communicate via AH, if an intervening router acting as a firewall is in place to enforce communication with AH? (similar to the scenario in the photuris draft section C.3) With IP-AH-ULP the router needs the key used to generate the AH. Otherwise the intervening router could only check, that there is an AH present, but could not check if AH is correct. Sharing the key with the router on the other hand degrades security, because the router can forge the AH of the host. With IP-AH-AH-ULP the sending host could generate one AH with the key shared with the router and the other AH with a key shared with the other host. Uwe From majordom@p-o.ans.net Fri Dec 29 15:14:24 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11677 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 10:17:37 -0500 Received: by p-o.ans.net id AA44565 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 15:14:09 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Dec 1995 10:14:24 -0500 To: ipsec@ans.net From: Stephen Kent Subject: Re: AH/ESP & Replay Protection Cc: rja@cisco.com, ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Phil, I think a major reason for the combinatorial complexity you allude to in your message is because of the way in which ESP and the transforms are currently separated. If an integrity check and an IV were both (optional) parts of the base ESP spec, then the transform specs would be much cleaner and more easily separable. The current structuring, in which ESP is just a shell, tends to create more complexity at the next layer of specification. Steve From majordom@p-o.ans.net Fri Dec 29 17:09:06 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11663 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 12:14:05 -0500 Received: by p-o.ans.net id AA40668 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 17:09:16 GMT Date: Fri, 29 Dec 1995 09:09:06 -0800 From: Ran Atkinson Message-Id: <199512291709.JAA07195@puli.cisco.com> To: karn@qualcomm.com Subject: Re: AH/ESP & Replay Protection Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net % What's wrong with lots of permissible header combinations? It's easy % to support an arbitrary sequence of headers, you just parse and decode % each one in sequence. One of the problems is figuring out what the effective protections were on the data, passing that information to the policy engine, and informing the application of what protections it got. Also, there is kernel bloat and increased per-packet processing cost as compared with a more integrated solution. % >I'd MUCH rather see a trend towards ESP transforms that provide more % >capabilities (such as the combined transform that provides both % >integrity and confidentiality) than towards more headers. % % I mildly agree that I'd like to see some more capable ESP modes, but % for a different reason -- reduced total header overhead compared to % combining separate protocols in modular tinker-toy fashion. Yes. You traditionally worry much more about bandwidth than about processing costs, so I'm not surprised. Integrated approaches will generally reduce both bandwidth and processing costs. % The big problem with integrated authentication/encryption ESP modes, % and the reason I don't support them as strongly as I used to, is that % here's where you can get the real explosion of implementation % complexity. I already support six different ESP transforms in my code % -- DES and 3DES, each with 0-bit, 32-bit and 64-bit IVs. Most of my % esp_input and esp_output routines consist of switch statements on the % encapsulation mode, and its likely to get much worse when I start % folding in authentication. For starters it will double the total % number of modes to 12, the six I already support plus those six with % MD5 authentication. Then somebody will want to add SHA for extra % security, and somebody else will probably want a "shortened MD5" for % less overhead on slow links. And *then* somebody will want IDEA and % SAFER cipher support... you get the idea? A conforming implementation doesn't have to support all of those modes. There is a minimum set that is mandatory. Implementing more than that is essentially a decision to add features. By contrast, my concern has to do with items that are mandatory to implement. In the NRL code, which supports DES-CBC with 32-bit and 64-bit IVs, the variable IV length costs two if/else statements and an increment in the normal case (add a call to random() in the case where the increment causes the IV to be all zeros). This isn't expensive. It certainly isn't the case that one has lots of redundant code lying around. If you're concerned about complexity, I'd suggest removing the support for confidentiality without strong integrity (once better transforms appear) since that is known to be vulnerable to active attacks described in past IPsec meetings. Talk of "SHA" or "shortened MD5" or other hypothetical combinations just tells me that the WG needs to come up with a single well chosen pair of mandatory transforms (one each for AH and ESP). We have already got a single set at Proposed Standard. The others (e.g. SHA for AH, 3DES for ESP) are all experimental and aren't required. Just because someone wants IDEA doesn't mean that everyone has to implement it. You've mixed apples (complexity that is mandatory to implement) and oranges (complexity that one chose to implement but is not mandatory), IMHO. Ran rja@cisco.com From majordom@p-o.ans.net Fri Dec 29 21:26:37 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA13524 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 16:31:42 -0500 Received: by p-o.ans.net id AA19802 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 21:26:54 GMT Date: Fri, 29 Dec 1995 16:26:37 -0500 Message-Id: <199512292126.QAA07123@hiway1.exit109.com> X-Sender: mpwagner@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: daw@cs.berkeley.edu (David Wagner) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >One of the problems is figuring out what the effective protections were >on the data, passing that information to the policy engine, and informing >the application of what protections it got. Ahh, this is an important issue. My current view is that a nice way to pass the information to the policy engine is using "key K says data D" notation, instead of "ip->ip_src says data D". This handles nested packets very nicely; for instance, the packet IP1-AH1-*-AH2-payload translates into (essentially) "key K1 and K2 say payload". (Since AH protects the IP header, the real statement is actually a bit stronger than that.) Then the policy engine (in this view) should base all policy decisions on key-based authentication, and never on IP source addresses. IP source addresses would become mainly a convenient "return-address" to know where to send responses to, instead of security-critical values. This is very similar to the approach presented in Lampson, Abadi, Burrows, and Wobber's "Authentication in Distributed Systems: Theory and Practice." IMHO, this viewpoint captures AH's true cryptographic guarantees more accurately than a IP-source-addr-based mechanism. Still, I'll admit it probably still needs more fleshing out; and I don't have any implementation experience with large policy engines, so I'm a biased judge of its merits. Any comments? From majordom@p-o.ans.net Fri Dec 29 21:26:20 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA15062 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 16:31:42 -0500 Received: by p-o.ans.net id AA37682 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 21:26:31 GMT Date: Fri, 29 Dec 1995 16:26:20 -0500 Message-Id: <199512292126.QAA07097@hiway1.exit109.com> X-Sender: mpwagner@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: daw@cs.berkeley.edu (David Wagner) Subject: Re: ICMP Security Failures Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >>Craig Metz writes: >>No, sadly, I don't think IP-AH-AH is safe to use with today's AH spec. > I never said it's safe. A layered implementation that fixes up the >IP header as it goes along the processing path could do it, though. There's >nothing explicitly saying in the spec that it could or couldn't be done. But the spec is not clear enough to determine the correct algorithm to use when doing IP-AH-AH processing; and there's more than one possible algorithm you could use. So the spec's ambiguity means that an ipsec-compliant implementation had better not do IP-AH-AH! I wish the spec would be clarified to either - clearly disallow AH unless it directly follows an IP header, or - clearly allow any & all nesting of AH, and specify which algorithm to use to calculate the Authentication Data. (I guess it's a good thing Hilarie Orman for brought up the issue of which nestings are valid!) From majordom@p-o.ans.net Fri Dec 29 21:26:26 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA12760 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 16:31:43 -0500 Received: by p-o.ans.net id AA27196 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 21:26:39 GMT Date: Fri, 29 Dec 1995 16:26:26 -0500 Message-Id: <199512292126.QAA07109@hiway1.exit109.com> X-Sender: mpwagner@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipsec@ans.net From: daw@cs.berkeley.edu (David Wagner) Subject: ESP and AH combinations Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net >IMHO, the combination of IP-AH-AH-ULP isn't sensible. It adds no value >to the IP-AH-ULP combination. Hrmm, so are you saying that there are no useful situations where you'd want two private keys to sign the same data; or that in these situations, people should use IP-AH-IP-AH? > If AH didn't protect bits of the IP header, then AH would be useless >because it wouldn't provide efficient packet-origin authentication Today's AH doesn't provide authentication of the IP src address either! I think that this reflects a subtle misconception in the way people are viewing the guarantees AH provides. If you receive an IP packet P protected by AH with integrity key K, then you can conclude "K says P", but not necessarily that "P.ip_src says P". Don't be fooled into thinking that AH's crypto magically provides a more secure form of source-based authentication. IP-source-addr-based authentication is a confusing & outmoded perspective, IMHO; AH really provides key-based authentication. I think the difference is important. (You can easily see the difference when several IP hosts use the same signing key K; then any one of those could impersonate any of the others, so upon receiving a packet signed by K, you can only conclude that it came from key K, i.e. from one of those IP hosts.) If you trust everyone who has the signing key refrain from tampering with other parties who have the same signing key, and you're willing to trust the IP source address & use source-based authentication for packets signed with that key, and you're worried about active attacks from outside parties, then and only then does protecting the source address in the IP header help you. One might say that including the IP header in the MAC input can provide only additional message integrity protection for the IP src addr but no additional packet-origin authentication. >there is ample evidence that AH as currently specified can be built and >interoperate. You're right, this is an old argument. I'll drop it. I just responded because I wanted to point out the difference between "K says P" and "P.ip_src says P". From majordom@p-o.ans.net Fri Dec 29 22:23:42 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11597 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 17:27:52 -0500 Received: by p-o.ans.net id AA12397 (5.65c/IDA-1.4.4 for ipsec-outgoing); Fri, 29 Dec 1995 22:23:07 GMT X-Sender: kent@eudora.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Dec 1995 17:23:42 -0500 To: ipsec@ans.net From: Stephen Kent Subject: Re: ESP and AH combinations Cc: ipsec@ans.net Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net David, In general, I'm not sure that two layers of integrity checks (they are not really signatures!) on the same data would be useful. IP-AH-AH-ULP seems more than a bit odd to me. This is not application layer data, but rather network or transport layer data. In contrast, your exmaple of IP-AH-IP-AH-ULP makes more sense in that it could be the result of an end-system applying AH to the packets it emits, then an encrypting router encapsulating those packets and adding an outer later of protection. Your point about what data origin authentication is provided by AH (or ESP) is an important one, that I would phrase differently. When we establish an SA, we should be determining what range of source addresses can be asserted by the entity at the other end, if we are going to persist in using IP addresses as inputs to access control decisions. If the other end is an end system, this is fairly simple. The address might come from a certificate exchanged during SA establishment or it might be hard configured into an ACL along with the public key for the other end. However, if the other end is a router, the problem is much more complex! One needs to have some way of constraining the range of addresses that the other site is authorized to emit, either via some for of authorization certificate, a set of certificates held for each indivdiaul end system served by the router, or some manual configuration procedure. I agree with your fundamental argument, i.e., source authentication is more subtle here than one might first think, especially in the case of IPSEC implemented in routers. It is fundamentally a case of what granularity of access control is appropriate and what form of identities are best suited for ACLs and the people who will manage them. Using DNS IDs and matching certificates from the DNS security work might be appropriate in some instances, but will that translate well for the hosts behind an encrypting router? Ultimately, access control decisions are likely to be based on some form of identity and thinking about a key as an identity is not very intuitive for security administration purposes. Also, having one form of identity verified at an encrypting router, but having another form acted upon by hosts behind the router (which don't get to see explicit results of the access control check at the router) is probably a bad idea. For most purposes, it may be appropriate to be very explicit about how the mapping between a key and a set of addresses is constrained, especially when dealing with routers. Steve From majordom@p-o.ans.net Sat Dec 30 01:11:48 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11932 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 20:16:13 -0500 Received: by p-o.ans.net id AA37820 (5.65c/IDA-1.4.4 for ipsec-outgoing); Sat, 30 Dec 1995 01:11:58 GMT Date: Fri, 29 Dec 1995 18:11:48 -0700 From: Hilarie Orman Message-Id: <9512300111.AA17367@uncial.CS.Arizona.EDU> To: hugo@watson.ibm.com Cc: ipsec@ans.net In-Reply-To: Yourmessage <199512281618.AA02386@interlock.ans.net> Subject: Re: I-D ACTION:draft-krawczyk-keyed-md5-01.txt Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net Two minor comments. What is the reason for suggesting 1Gbyte as the data volume limit? Do you mean to imply that if one were hashing a 2Gbyte file, one should use two keys, or is the recommendation loosely related to the time period of use or number of uses? Just for clarification, is it not possible that other modes of use could provide equivalent security? You are simply saying that you have proofs for your proposed scheme and not for others? From majordom@p-o.ans.net Sat Dec 30 02:40:39 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11580 (5.65c/IDA-1.4.4 for ); Fri, 29 Dec 1995 21:46:14 -0500 Received: by p-o.ans.net id AA19819 (5.65c/IDA-1.4.4 for ipsec-outgoing); Sat, 30 Dec 1995 02:40:50 GMT Date: Fri, 29 Dec 1995 18:40:39 -0800 (PST) From: Phil Karn Message-Id: <199512300240.SAA11540@servo.qualcomm.com> To: rja@cisco.com Cc: ipsec@ans.net In-Reply-To: <199512291709.JAA07195@puli.cisco.com> (message from Ran Atkinson on Fri, 29 Dec 1995 09:09:06 -0800) Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net First, a question to the list manager. Has somebody modified the list to include "Reply-To: ipsec@ans.net" in the header? It seems to have appeared recently, and is arguably broken. >One of the problems is figuring out what the effective protections were >on the data, passing that information to the policy engine, and informing >the application of what protections it got. Also, there is kernel bloat >and increased per-packet processing cost as compared with a more integrated >solution. I've not completely built the mechanisms to do this in my own code, but I have started. Basically, the internal representation of each incoming packet carries three "out-of-band" tags: a pointer to the interface it came in on, a binary flag indicating whether the packet was received as a link-level broadcast (to stop broadcast storms), and the 32-bit SPI of any security transform providing authentication. All this information is available to upper-level policy mechanisms, including transport protocols (like TCP, which may wish to ignore physical layer broadcasts), the IP routing code (e.g., which may wish to route only authenticated packets from certain interfaces, but route all packets from another), and to applications (which may use AH in lieu of their own authentication mechanisms). When the packet first comes in, of course, the out-of-band SPI field is null. If the packet contains AH, normal transport protocol demuxing passes it to the AH module which strips it off and adjusts the length and protocol fields in the IP header. If the authentication fails, the packet is tossed. If the authentication passes, the AH module sets the SPI tag and puts the reconstructed packet, now minus its authentication header, back into the "hopper" where it is processed again by the transport demux code to handle the next transport header. This time, the out-of-band SPI field is available to drive routing, transport and application policy decisions as desired. Since there is only room for one SPI tag per packet, wrapping one AH header inside another is not too meaningful. In that case I think I overwrite the SPI tag set from the outer AH with the SPI from the inner AH header. Both AH headers have to pass, but the packet carries only the privileges from the inner AH. I don't see this as much of a problem since it's hard to conceive of a real use for nested AH-AH to the same destination, as opposed to two AHs to different destinations (e.g., one to a firewall and another to an end system.) In this latter case, there's an IP header between the two AHs. >If you're concerned about complexity, I'd suggest removing the support >for confidentiality without strong integrity (once better transforms >appear) since that is known to be vulnerable to active attacks described >in past IPsec meetings. Talk of "SHA" or "shortened MD5" or other Well, since we've made that mandatory (32-bit IV single key DES) we'd have to change that. Actually, this is the mode I use most often since I'm concerned mainly about passive, NSA-style vacuum-cleaner monitoring. But you're right, I'd be better off including some real authentication, especially when I can afford the bandwidth. Phil From majordom@p-o.ans.net Sat Dec 30 14:25:40 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA10590 (5.65c/IDA-1.4.4 for ); Sat, 30 Dec 1995 10:21:10 -0500 Received: by p-o.ans.net id AA38563 (5.65c/IDA-1.4.4 for ipsec-outgoing); Sat, 30 Dec 1995 15:07:44 GMT Date: Sat, 30 Dec 95 14:25:40 GMT From: "William Allen Simpson" Message-Id: <4689.bsimpson@morningstar.com> To: ipsec@ans.net Subject: Re: AH/ESP & Replay Protection Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > From: daw@cs.berkeley.edu (David Wagner) > My current view is that a nice way to pass the information to the > policy engine is using "key K says data D" notation, instead of > "ip->ip_src says data D". > Yes, this is what Karn's code does, too. He passes the SPI up the stack, and since the SPI is uniquely maintained by the Destination, it makes a convenient tag for the policy engine to determine the validity of the data. No Source involved at all! > Then the policy engine (in this view) should base all policy decisions > on key-based authentication, and never on IP source addresses. IP > source addresses would become mainly a convenient "return-address" > to know where to send responses to, instead of security-critical values. > > This is very similar to the approach presented in Lampson, Abadi, > Burrows, and Wobber's "Authentication in Distributed Systems: > Theory and Practice." > (sigh) Another book to buy? > IMHO, this viewpoint captures AH's true cryptographic guarantees more > accurately than a IP-source-addr-based mechanism. > An excellent analysis. My question is: does this mean that it was a waste of time to authenticate the IP Header, and the other IPv6 Routing Headers and cruft? If we don't need to authenticate the Source, is there any reason that we would care to authenticate the path that the data arrived? If the SPI uniquely determines the policy (as I've long advocated), there would be no need to authenticate the CIPSO labels, either. The code didn't turn out to be too bad for IPv4, once we agreed to zero a lot of fields. But it could be a real simplification for IPng. 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 majordom@p-o.ans.net Sun Dec 31 20:02:32 1995 Received: from p-o.ans.net by ftp.ans.net with SMTP id AA11173 (5.65c/IDA-1.4.4 for ); Sun, 31 Dec 1995 14:48:57 -0500 Received: by p-o.ans.net id AA38853 (5.65c/IDA-1.4.4 for ipsec-outgoing); Sun, 31 Dec 1995 19:42:55 GMT Message-Id: <199512312002.PAA11090@metis.milkyway.com> X-Mailer: exmh version 1.6.4 10/10/95 X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4 =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf |;W@E2K#{U~%vhvth^uDLWD` In-Reply-To: Your message of "Fri, 29 Dec 1995 16:07:27 +0100." <199512291507.QAA17151@cops.cert.dfn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 Dec 1995 15:02:32 -0500 From: Michael Richardson Sender: ipsec-owner@ans.net Precedence: bulk Reply-To: ipsec@ans.net > With IP-AH-ULP the router needs the key used to generate the AH. Otherwise > the intervening router could only check, that there is an AH present, but > could not check if AH is correct. Sharing the key with the router on the > other hand degrades security, because the router can forge the AH of the host. This is true. I don't see a general solution to this using the MD5 transforms. Digital signature checking scares me. > With IP-AH-AH-ULP the sending host could generate one AH with the key shared with > the router and the other AH with a key shared with the other host. This works fine with one security gateway. Road warrior to home base, say. A typical case might involve two gateways: one at each end. I prove to my gateway that I'm authorized to use the internet, I then prove to your gateway that I'm authorized to pass through it, and then finally prove to your host that I am who I say I am. This is independant of whether or not our gateways happen to implement a tunnel to provide privacy as well. But, it gets worse. Let's say I want to reserve bandwidth (I don't know much about these efforts, btw) for a video conference. How many routers will have to authenticate my packets before giving them preference? And will authenticating these packets take so long as to make the bandwidth reservation pointless?