From owner-ipsec@lists.tislabs.com Wed Aug 1 01:42:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f718gFs13805; Wed, 1 Aug 2001 01:42:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25188 Wed, 1 Aug 2001 03:35:53 -0400 (EDT) Message-Id: <3.0.3.32.20010801094510.007f3630@pop.wanadoo.fr> X-Sender: jr.peulve@pop.wanadoo.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 01 Aug 2001 09:45:10 +0200 To: Michael Choung Shieh From: Jean-Rene Peulve Subject: RE: IPSec performance statistics Cc: "'Kopeikin, Roy A (Roy)'" , Marc Solsona-Palomar , Parijat Mishra , awank@future.futsoft.com, ipsec@lists.tislabs.com In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B028F3607@NS-CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA25185 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Don't forget that IP tunneling + ESP adds around 52 bytes overhead. This is almost 50% overhead on small packet. So wire speed is a dream. At 10:18 31/07/01 -0700, Michael Choung Shieh wrote: > >The performance lost of ipsec processing depends on the architecture of the >design and the size of packets. Some vendors can achieve wire-speed while >the others only improve a little even with hardware acceleration. It's also >easier to boost the performance for large size packets(1500bytes) than small >size (64bytes). > >Hardware accelaration does reduce the difference of processing time between >encryption algorithms. The differences between DES and 3DES processing may >be less than 10%. > >I would say the performance really depends on the gateway you used. There >are many reports and comparisons out there. > >-------------------------------------------- >Michael Shieh >NetScreen Technologies, Inc >350 Oakmead Parkway >Sunnyvale, CA 94085 >TEL: (408)730-6060 >FAX: (408)730-6050 >Email: mshieh@netscreen.com >-------------------------------------------- > >-----Original Message----- >From: Kopeikin, Roy A (Roy) [mailto:rkopeikin@lucent.com] >Sent: Tuesday, July 31, 2001 9:26 AM >To: Marc Solsona-Palomar >Cc: Parijat Mishra; awank@future.futsoft.com; ipsec@lists.tislabs.com >Subject: RE: IPSec performance statistics > > >Marc, >Do you think these cycles lost can bd quantified into performanc statistics? >roy > >-----Original Message----- >From: Marc Solsona-Palomar [mailto:marc@iprg.nokia.com] >Sent: Tuesday, July 31, 2001 4:22 AM >To: Kopeikin, Roy A (Roy) >Cc: Parijat Mishra; awank@future.futsoft.com; ipsec@lists.tislabs.com >Subject: Re: IPSec performance statistics > > >IPsec processing implies an overhead. Even the fact to send the packet >somewhere else (like to an accelerator card) means cycles lost. What an >accelerator will provide is more unified results across different algorithms >as the chips have been optimized for this type of processing. > >marc > >"Kopeikin, Roy A (Roy)" wrote: > >> Correct me if I'm wrong but I think this is a non-issue for corporate VPNs >> since accelerator boards are typically integrated to handle the encryption >> and decryption functions. It is unacceptable for VPNs to degrade >> router/internework performance. >> Roy >> >> -----Original Message----- >> From: Parijat Mishra [mailto:mishrap@cwc.nus.edu.sg] >> Sent: Monday, July 30, 2001 9:26 PM >> To: awank@future.futsoft.com; ipsec@lists.tislabs.com >> Subject: Re: IPSec performance statistics >> >> There will be lots of statistics, but they'll depend on the machines >> used, and the packet size. However, my observation is that with >> ESP-3DES, the time taken to process packets is almost doubled. >> >> It should be easy to run performance tests for your own setup. >> >> Parijat >> ----- Original Message ----- >> From: "Awan Kumar" >> To: >> Sent: Monday, July 30, 2001 12:26 PM >> Subject: IPSec performance statistics >> >> | Hi, >> | Can anybody provide some statistics on the percentage of change in >> | performance (throughtput) due to the inclusion of IPsec in the IP >> stack. Are >> | there any statistics available which shows the reduction in >> performance due >> | to the use of DES or 3DES for ESP. >> | >> | Thanks in advance. >> | >> | Regards, >> | Awan >> | >> | ---------------------------- >> | Awan Kumar Sharma >> | Sr. Software Engg., >> | Future Software Ltd., >> | Chennai, India. >> | Ph: 4330 550 Extn: 437 >> | (www.futsoft.com) >> | ------------------------------ >> | >> | > Jean-Rene Peulve Les Tilleuls Chemin de Vermillčre 84.160 Cadenet France Tel: (33)4.90.68.36.86 Fax: (33)4.90.68.36.87 Email: jr.peulve@wanadoo.fr From owner-ipsec@lists.tislabs.com Wed Aug 1 10:34:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71HYbs11904; Wed, 1 Aug 2001 10:34:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26432 Wed, 1 Aug 2001 12:16:36 -0400 (EDT) Message-Id: <3.0.3.32.20010801092204.00ecec30@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 01 Aug 2001 09:22:04 -0700 To: Mike Fratto , "Kopeikin, Roy A (Roy)" , Parijat Mishra , awank@future.futsoft.com, ipsec@lists.tislabs.com From: Alex Alten Subject: RE: IPSec performance statistics In-Reply-To: <5.0.2.1.2.20010731124944.04073690@128.230.92.5> References: <80B684C5E29FD211AA8000A0C9CDD91908FCE8DB@il0015exch005u.ih .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could you provide specific URLs? Thanks, - Alex At 01:01 PM 7/31/2001 -0400, Mike Fratto wrote: >There have been several performance reviews published over the last several >years. For more detailed information, read the test bed scenario and if you >have specific questions about the testing, contact the author for details. -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Wed Aug 1 19:37:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f722bAs25617; Wed, 1 Aug 2001 19:37:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27520 Wed, 1 Aug 2001 21:16:29 -0400 (EDT) Date: Thu, 2 Aug 2001 03:22:32 +0200 From: Marco Ender X-Mailer: The Bat! (v1.53bis) Educational Reply-To: Marco Ender X-Priority: 3 (Normal) Message-ID: <1750576405.20010802032232@dungeonmaster.at> To: ipsec@lists.tislabs.com Subject: SPD Selector (Newbie) Question MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, i am writing on my diploma thesis about VPNs (not in english as you may guess ;)) and have a question which may someone of you can answer. If this is not the place to ask such questions i am sorry, but i couldn´t find a newsgroup for IPSec, if there is another newsgroup or list that fits better please tell me and i will no longer bother you =) In RFC2401 (Security Architecture for the Internet Protocoll) on page 17 it is mentioned that in the SPD there can be used IP-Adresses (and adress ranges) or Identifiers like names. Now my question: Suppose i want to use names, how does a security gateway match incoming IP-packets from the local subnet (which should be sent secured over the internet to somewhere else) to those names? The hosts will not send identifiers along with every IP-packet i guess, so how does it work? If every SPD-entry has to have ip-adresses in addition to the name, what is the name good for? hope you can help me Marco From owner-ipsec@lists.tislabs.com Wed Aug 1 20:19:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f723JHs26621; Wed, 1 Aug 2001 20:19:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA27618 Wed, 1 Aug 2001 22:28:23 -0400 (EDT) From: "David Carman" To: Cc: Subject: RE: IPSec performance statistics Date: Wed, 1 Aug 2001 22:35:10 -0400 Message-ID: <000001c11afb$c1a6eba0$6501a8c0@na.nai.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000001c118af$d0d44440$0702060a@future.futsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Awan, A data point that has a finite chance at usefulness for a Pentium II 400 MHz, FreeS/WAN (Linux), ESP, authentication only, is located at: http://www.pgp.com/research/nailabs/cryptographic/adaptive-cryptographic.asp Check out Figure 3 in our final report at: http://download.nai.com/products/media/pgp/pdf/acsa_final_report.pdf Regards - Dave Carman +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ David W. Carman, Principal Cryptographic Engineer NAI Labs, The Security Research Division of Network Associates, Inc. email: David_Carman@nai.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Awan Kumar > Sent: Monday, July 30, 2001 12:27 AM > To: ipsec@lists.tislabs.com > Subject: IPSec performance statistics > > > Hi, > Can anybody provide some statistics on the percentage of change in > performance (throughtput) due to the inclusion of IPsec in > the IP stack. Are > there any statistics available which shows the reduction in > performance due > to the use of DES or 3DES for ESP. > > Thanks in advance. > > Regards, > Awan > > ---------------------------- > Awan Kumar Sharma > Sr. Software Engg., > Future Software Ltd., > Chennai, India. > Ph: 4330 550 Extn: 437 > (www.futsoft.com) > ------------------------------ > From owner-ipsec@lists.tislabs.com Thu Aug 2 05:24:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72CO2s07708; Thu, 2 Aug 2001 05:24:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28526 Thu, 2 Aug 2001 07:02:16 -0400 (EDT) Message-Id: <3.0.5.32.20010802093146.050a29d0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 02 Aug 2001 09:31:46 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: SPD Selector (Newbie) Question In-Reply-To: <1750576405.20010802032232@dungeonmaster.at> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA28167 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:22 02.08.01 +0200, you wrote: >Hello, > >i am writing on my diploma thesis about VPNs (not in english as you >may guess ;)) and have a question which may someone of you can answer. >If this is not the place to ask such questions i am sorry, but i >couldnĄt find a newsgroup for IPSec, if there is another newsgroup or >list that fits better please tell me and i will no longer bother you >=) > Don't worry, you found the correct list. >In RFC2401 (Security Architecture for the Internet Protocoll) on page >17 it is mentioned that in the SPD there can be used IP-Adresses (and >adress ranges) or Identifiers like names. Now my question: Suppose i >want to use names, how does a security gateway match incoming >IP-packets from the local subnet (which should be sent secured over >the internet to somewhere else) to those names? The hosts will not >send identifiers along with every IP-packet i guess, so how does it >work? If every SPD-entry has to have ip-adresses in addition to the >name, what is the name good for? > >hope you can help me > >Marco "names" in the SPD are only used for the Phase 1, the authentication part. The most natural ID for a computer is it's IP address. So you normally put that into the certificate and send an ID payload containing the IP address. But there are situations where this won't work. Most common is a client using dialup. Now this client has to use more other ID. In this case the client might send the full distiguished name of his certificate, not containing any IP address. In order to accept that, the SPD might contain that distinguished name. The same works for email addresses, which can be used as IKE ID payloads. The client sends it, and the GW looks up his SPD for it. >work? If every SPD-entry has to have ip-adresses in addition to the >name, what is the name good for? Well, this SPD-entry for the client will _not_ have an ip address in it. In Phase 2, only IP addresses, ranges and subnets are used for ID payloads. J–rn Sierwald, www.f-secure.com From owner-ipsec@lists.tislabs.com Thu Aug 2 13:11:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72KB8s27341; Thu, 2 Aug 2001 13:11:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29794 Thu, 2 Aug 2001 15:01:11 -0400 (EDT) Message-Id: <3.0.3.32.20010802120638.00e22c70@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 02 Aug 2001 12:06:38 -0700 To: "David Carman" , From: Alex Alten Subject: RE: IPSec performance statistics Cc: In-Reply-To: <000001c11afb$c1a6eba0$6501a8c0@na.nai.com> References: <000001c118af$d0d44440$0702060a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Based on your figure 3 and using the 3DES costs from Antoon Bosselaers URL at http://www.esat.kuleuven.ac.be/~bosselae/fast.html, I get the following per byte cycle costs on a Pentium. IP-Only about 5 cycles/byte IPSec w/o crypto about +6 cycles/byte HMAC-SHA-1-96 about +13 cycles/byte 3DES about +14 to +15 cycles/byte (from Bosselaers url) -------------------------------------- Total IPSEC w/SHA1 & 3DES is about 38 to 39 cycles/byte. So I should see almost an order of magnitude (about 1/8) slow down when IPSec is used between two hosts versus when just ordinary IP is running. Does this correlate with what people are seeing in actual IPSec deployments? Or is everyone only using hardware to get around this problem (but introducing other problems like extra cost and deployment issues). Does anyone have metrics for SA setup costs, with and without IKE? I've seen claims of about 1 setup (w/out IKE?) per second in hardware. Any metrics for Pentium class PC's? - Alex At 10:35 PM 8/1/2001 -0400, David Carman wrote: >Awan, > >A data point that has a finite chance at usefulness for a Pentium II 400 >MHz, FreeS/WAN (Linux), ESP, authentication only, is located at: > >http://www.pgp.com/research/nailabs/cryptographic/adaptive-cryptographic.asp > >Check out Figure 3 in our final report at: > >http://download.nai.com/products/media/pgp/pdf/acsa_final_report.pdf > >Regards - Dave Carman >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >David W. Carman, Principal Cryptographic Engineer >NAI Labs, The Security Research Division of Network Associates, Inc. >email: David_Carman@nai.com > >> -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Awan Kumar >> Sent: Monday, July 30, 2001 12:27 AM >> To: ipsec@lists.tislabs.com >> Subject: IPSec performance statistics >> >> >> Hi, >> Can anybody provide some statistics on the percentage of change in >> performance (throughtput) due to the inclusion of IPsec in >> the IP stack. Are >> there any statistics available which shows the reduction in >> performance due >> to the use of DES or 3DES for ESP. >> >> Thanks in advance. >> >> Regards, >> Awan >> >> ---------------------------- >> Awan Kumar Sharma >> Sr. Software Engg., >> Future Software Ltd., >> Chennai, India. >> Ph: 4330 550 Extn: 437 >> (www.futsoft.com) >> ------------------------------ >> > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Thu Aug 2 13:41:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72Kfks28222; Thu, 2 Aug 2001 13:41:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29980 Thu, 2 Aug 2001 16:03:28 -0400 (EDT) Message-Id: <200108022009.f72K9hJ06140@thunk.east.sun.com> From: Bill Sommerfeld To: Alex Alten cc: "David Carman" , ipsec@lists.tislabs.com, David_Carman@nai.com Subject: Re: IPSec performance statistics In-reply-to: Your message of "Thu, 02 Aug 2001 12:06:38 PDT." <3.0.3.32.20010802120638.00e22c70@mail> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 02 Aug 2001 16:09:42 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Does anyone have metrics for SA setup costs, with and without IKE? > I've seen claims of about 1 setup (w/out IKE?) per second in > hardware. That's really kind of pessimistic. I'm reluctant to quote exact numbers on a product not yet shipping, but the IPsec/IKE product I'm currently working on, running without any specialized hardware, does considerably better than that when the peers are "close" as the packet flies.. I can readily believe 1 second setup time *including* the IKE exchange when the round trip time between peers is in the 100-200ms range. Main mode + quick mode + first-user-traffic winds up being about 5 round trips, so network latency winds up being a dominant factor in how long it takes to get things flowing.. - Bill From owner-ipsec@lists.tislabs.com Thu Aug 2 19:28:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732S2s05160; Thu, 2 Aug 2001 19:28:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA00986 Thu, 2 Aug 2001 21:24:01 -0400 (EDT) Message-ID: <3B69FF7B.85CF61@nortelnetworks.com> Date: Thu, 02 Aug 2001 21:33:47 -0400 From: "Marcus Leech" Organization: Nortel Networks: Information Systems X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Position statement on IKE development Content-Type: multipart/mixed; boundary="------------700C1CE7C41A16595853A0C3" X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------700C1CE7C41A16595853A0C3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm sending the attached ASCII TEXT document on behalf of myself, Jeff Schiller, and Steve Bellovin, to clarify our position with respect to IKE development. It is our hope that it will clarify, to some extent, some fuzziness in this area that has evolved over the last year or so. --------------700C1CE7C41A16595853A0C3 Content-Type: text/plain; charset=us-ascii; name="statement.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="statement.txt" In the several years since the standardization of the IPSEC protocols (ESP, AH, and ISAKMP/IKE), there have come to light several security problems with the protocols, most notably the key-agreement protocol, IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and Simpson, have shown that the security problems in IKE stem directly from its complexity. It seems only a matter of time before more analyses show more serious security issues in the protocol design that stem directly from its complexity. It seems also, only a matter of time, before serious *implementation* problems become apparent, again due to the complex nature of the protocol, and the complex implementation that must surely follow. Despite the obviously complex nature of IKE, several proposals have been put forward to extend ISAKMP/IKE in various ways, for various purposes. Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and others do nothing to improve the complexity situation with regard to IKE as a whole. While many of these proposals are, individually, based on sound engineering and reasonably prudent practice, when cast in the larger context of IKE, it seems clear that they can do nothing to improve the complexity picture. It is with that in mind that the Security Area directors in the IETF, with the consultation of appropriate people on the IESG and IAB, hereby place a temporary moratorium on the addition of new features to IKE. It is fairly clear that work on IKE should focus on fixing identified weaknesses in the protocol, rather than adding features that detract from the goal of simplicity and correctness. We are concerned that trying to reuse too much of the IKE code base in new protocols -- PIC and GDOI come to mind -- will lead to more complex (and hence vulnerable) implementations. We suggest that implementors resist this temptation, with the obvious exception of common library functions that perform functions such as large modular exponentiations. Attempts to share state or to optimize message exchanges are likely to lead to disaster. The Security Area Directors have asked the IPSEC working group to come up with a replacement for IKE. This work is underway and is known in the community as "Son of IKE". This effort is at serious risk of suffering the "second system effect", where all the features that were left out of the first version, end up in the second. For this to happen would be a spectacular disaster, and very much detract from the goal: to produce a more secure, simpler, and more robust version of IKE. Arriving at this point has been exceedingly difficult and harrowing. Understandably, egos have been bruised, and the "change not the IKE, for it is subtle and quick to anger" position has been taken as a personal afront by some members of the IPSEC community. Nothing could be further from the intent of either of the Security Area directors. If IKE is vulnerable, we must all share a burden of responsibility for allowing it to get to the state it is in and we must all work together to correct the problems. The IPSEC community must act prudently in moving forward with a replacement for IKE. The IPSEC auxillary groups (IPSRA, MSEC, IPSP) must act with good judgment (chairs and members alike) in designing protocols that don't interfere with the goal of security and simplifying our IPSEC key-agreement protocol. Marcus Leech (IESG) Jeff Schiller (IESG) Steve Bellovin (IAB) --------------700C1CE7C41A16595853A0C3-- From owner-ipsec@lists.tislabs.com Thu Aug 2 19:43:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732hus05565; Thu, 2 Aug 2001 19:43:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01029 Thu, 2 Aug 2001 22:03:32 -0400 (EDT) Message-Id: <200107271107.HAA06703@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt Date: Fri, 27 Jul 2001 07:07:56 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : Responder Lifetime Notify Message for IKE Author(s) : S. Fanning Filename : draft-ietf-ipsec-ike-lifetime-00.txt Pages : 5 Date : 26-Jul-01 This document describes how the RESPONDER-LIFETIME notify message, used within the ISAKMP DOI can be used to facilitate lifetime negotiation and rekeying. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt Internet-Drafts are also 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-ike-lifetime-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <20010726170632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-lifetime-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170632.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Aug 2 22:48:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f735mas08670; Thu, 2 Aug 2001 22:48:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA01378 Fri, 3 Aug 2001 00:59:34 -0400 (EDT) Message-Id: <3.0.3.32.20010802220454.00fc0530@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 02 Aug 2001 22:04:54 -0700 To: "Marcus Leech" , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com From: Alex Alten Subject: Re: Position statement on IKE development In-Reply-To: <3B69FF7B.85CF61@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Marcus, Jeff and Steve, May I make a suggestion given the seriousness of this? Let's hold an international design competition to select a key management protocol for IPSec in a manner similar to how NIST did the AES selection (although I hope it takes less than 5 years). Once we get to a final 5, then let's cryptanalyze them and select the best one. In this manner hopefully we can avoid a 2nd debacle. Sincerely, - Alex Alten At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote: >I'm sending the attached ASCII TEXT document on behalf of myself, Jeff >Schiller, and > Steve Bellovin, to clarify our position with respect to IKE >development. It is our hope > that it will clarify, to some extent, some fuzziness in this area that >has evolved over > the last year or so.In the several years since the standardization of the IPSEC protocols >(ESP, AH, and ISAKMP/IKE), there have come to light several security >problems with the protocols, most notably the key-agreement protocol, >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and >Simpson, have shown that the security problems in IKE stem directly >from its complexity. It seems only a matter of time before more >analyses show more serious security issues in the protocol design that >stem directly from its complexity. It seems also, only a matter of >time, before serious *implementation* problems become apparent, again >due to the complex nature of the protocol, and the complex >implementation that must surely follow. ... > > >Marcus Leech (IESG) >Jeff Schiller (IESG) >Steve Bellovin (IAB) > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Thu Aug 2 23:29:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f736Trs15894; Thu, 2 Aug 2001 23:29:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA01453 Fri, 3 Aug 2001 01:35:42 -0400 (EDT) Message-ID: <002901c11bdf$9d1f0f80$ae0510ac@roc.com> Reply-To: "lokesh" From: "lokesh" To: Subject: problem with HMAC precomputes. Date: Fri, 3 Aug 2001 11:16:12 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C11C0D.B3F64BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C11C0D.B3F64BA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello all, I'm doing a project on Ipsecurity and have come across a=20 problem. I'm sure some of you can help me with an answer Many Crypto Accelerator Chips expect Ipsec application to=20 supply inner and outer digests of HMAC Authentication only once when Key = is formed or a New SA is created, and they use those digests to = Authenticate or to calculate ICV of packet using HMAC. Again Application = need to supply inner and outer digests only if keys is changed or New SA = is formed.=20 RFC 2104 on HMAC Keyed Hashing tells that packet processing using = authentication mechanism of HMAC computation using MD5 or SHA can be = enhanced by having precomputed inner and outer digests of (K XOR ipad and K XOR opad , where K is Authentication Key, ipad 0x36 = and opad is 0x5c as defined in RFC2104) K_ipad and K_opad zero padded strings. So that we need to to precompute these values only once when keys are = created and can be used directly when there is a packet to process thus = avoiding two hashes on Kipad and Kopad for every packet. however RFC = does not tell about exact method of precomputing inner and outer digests = of HMAC computation only once and using them untill key is changed. In my case Authentication is failing because I'm not able to precompute = the inner and outer digests correctly :( . because, I dont have clear Idea on this aspect. Can you tell me how it can be done ? I mean what is the Exact method to = do this? How Precomputed hashes on Kipad and Kopad are used=20 for Authenticating packet? Thank You=20 Lokesh ------=_NextPart_000_0024_01C11C0D.B3F64BA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello all,
 
I'm doing a project on Ipsecurity and = have come=20 across a
problem. I'm sure some of you can help = me with an=20 answer
 
Many Crypto Accelerator Chips expect = Ipsec=20 application to
supply inner and outer digests of HMAC=20 Authentication only once when Key is formed or a New SA is created, and = they use=20 those digests to Authenticate or to calculate ICV of packet using HMAC. = Again=20 Application need to supply inner and outer digests only if keys is = changed=20 or New SA is formed.
 
RFC 2104  on HMAC Keyed Hashing = tells that=20 packet processing using authentication mechanism of  HMAC = computation=20 using  MD5 or SHA can be enhanced by having precomputed inner and = outer=20 digests of
 (K XOR ipad and K XOR opad , where K is Authentication Key, ipad 0x36 and opad = is 0x5c as=20 defined in RFC2104)
 K_ipad and K_opad zero padded=20 strings.
So that we need to to precompute = these values=20 only once when keys are created and can be used  directly when = there=20 is a packet to process thus avoiding two hashes on Kipad and Kopad for = every=20 packet. however RFC does not tell about exact method of precomputing = inner and=20 outer digests of HMAC computation  only once and using them untill = key is=20 changed.
 
In my case Authentication is failing = because I'm=20 not able to precompute the inner and outer digests correctly :( = .
because, I dont have=20 clear Idea on this aspect.
Can you tell me how it can be done ? I = mean what is=20 the Exact method to do this?
How Precomputed hashes on Kipad and = Kopad are used=20
for Authenticating packet?
 
Thank You
Lokesh
 
 
------=_NextPart_000_0024_01C11C0D.B3F64BA0-- From owner-ipsec@lists.tislabs.com Fri Aug 3 00:40:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f737eUs26906; Fri, 3 Aug 2001 00:40:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01613 Fri, 3 Aug 2001 02:44:19 -0400 (EDT) Message-Id: <3.0.3.32.20010802234951.00e4eb00@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 02 Aug 2001 23:49:51 -0700 To: "Marcus Leech" , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com From: Alex Alten Subject: Re: Position statement on IKE development In-Reply-To: <3.0.3.32.20010802220454.00fc0530@mail> References: <3B69FF7B.85CF61@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk After just reading the papers by Meadows, Schneier/Ferguson and Simpson, I now have serious doubts that IPsec delivers the security required by the Internet community. This is a very serious issue. To make a mistake of this caliber when so many firms have committed large amounts of resources for software, board, ASIC and chip designs, implementations and manufactures is a terrible thing. I agree with Schneier & Ferguson. A security protocol/system cannot be designed by a large committee, unlike many other successful insecure protocols. Their suggestion to use a process like NIST's for selecting the AES standard is an excellent one. It's a pity they did not suggest it a decade ago. However it should be considered seriously not only for the replacement of IKE, but possibly also for the modification or simplification of the entire IPsec protocol suite. (I hesitate to say the replacement of IPSEC given the tremendous repercussions of doing so.) - Alex At 10:04 PM 8/2/2001 -0700, Alex Alten wrote: > >Dear Marcus, Jeff and Steve, > >May I make a suggestion given the seriousness of this? > >Let's hold an international design competition to select a key >management protocol for IPSec in a manner similar to how NIST did >the AES selection (although I hope it takes less than 5 years). >Once we get to a final 5, then let's cryptanalyze them and select >the best one. In this manner hopefully we can avoid a 2nd debacle. > >Sincerely, > >- Alex Alten > > >At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote: >>I'm sending the attached ASCII TEXT document on behalf of myself, Jeff >>Schiller, and >> Steve Bellovin, to clarify our position with respect to IKE >>development. It is our hope >> that it will clarify, to some extent, some fuzziness in this area that >>has evolved over >> the last year or so.In the several years since the standardization of >the IPSEC protocols >>(ESP, AH, and ISAKMP/IKE), there have come to light several security >>problems with the protocols, most notably the key-agreement protocol, >>IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and >>Simpson, have shown that the security problems in IKE stem directly >>from its complexity. It seems only a matter of time before more >>analyses show more serious security issues in the protocol design that >>stem directly from its complexity. It seems also, only a matter of >>time, before serious *implementation* problems become apparent, again >>due to the complex nature of the protocol, and the complex >>implementation that must surely follow. > >... > >> >> >>Marcus Leech (IESG) >>Jeff Schiller (IESG) >>Steve Bellovin (IAB) >> >-- > >Alex Alten > >Alten@Home.Com > > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Fri Aug 3 02:44:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f739i2s07765; Fri, 3 Aug 2001 02:44:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA01941 Fri, 3 Aug 2001 04:48:14 -0400 (EDT) Message-Id: <200107271107.HAA06703@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt Date: Fri, 27 Jul 2001 07:07:56 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : Responder Lifetime Notify Message for IKE Author(s) : S. Fanning Filename : draft-ietf-ipsec-ike-lifetime-00.txt Pages : 5 Date : 26-Jul-01 This document describes how the RESPONDER-LIFETIME notify message, used within the ISAKMP DOI can be used to facilitate lifetime negotiation and rekeying. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt Internet-Drafts are also 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-ike-lifetime-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt". NOTE: The mail server at ietf.org 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. 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@ietf.org" Content-Type: text/plain Content-ID: <20010726170632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-lifetime-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170632.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Aug 3 07:21:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73ELvs16426; Fri, 3 Aug 2001 07:21:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02507 Fri, 3 Aug 2001 09:28:17 -0400 (EDT) Message-ID: <3B6AA869.73844050@storm.ca> Date: Fri, 03 Aug 2001 09:34:33 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: msec@securemulticast.org CC: ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development References: <3B69FF7B.85CF61@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Marcus Leech wrote: > In the several years since the standardization of the IPSEC protocols > (ESP, AH, and ISAKMP/IKE), there have come to light several security > problems with the protocols, most notably the key-agreement protocol, > IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and > Simpson, have shown that the security problems in IKE stem directly > from its complexity. ... For anyone who has not seen those papers, there are links to them at: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/web.html#analysis From owner-ipsec@lists.tislabs.com Fri Aug 3 07:21:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73ELvs16427; Fri, 3 Aug 2001 07:21:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02423 Fri, 3 Aug 2001 09:02:15 -0400 (EDT) Message-ID: <490717515EE6D41187A60003470D713629D3DF@kanatamail.kanata.unispherenetworks.ca> From: "Lordello, Claudio" To: "'lokesh'" , ipsec@lists.tislabs.com Subject: RE: problem with HMAC precomputes. Date: Fri, 3 Aug 2001 09:08:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11C1D.6B455620" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11C1D.6B455620 Content-Type: text/plain; charset="windows-1252" Just do a partial H transform to (K xor ipad) to get the inner digest and another partial transform to (K xor opad) to get the outer digest. By partial transform I mean apply the actual MD5/SHA1 transforms to the (K xor *pad) block without the final padding (that will be done later when computing the icv). The MD5 transform is described in RFC 1321 and SHA in FIPS PUB 180-1. Claudio. -----Original Message----- From: lokesh [mailto:lokeshnb@intotoinc.com] Sent: Friday, August 03, 2001 1:46 AM To: ipsec@lists.tislabs.com Subject: problem with HMAC precomputes. Hello all, I'm doing a project on Ipsecurity and have come across a problem. I'm sure some of you can help me with an answer Many Crypto Accelerator Chips expect Ipsec application to supply inner and outer digests of HMAC Authentication only once when Key is formed or a New SA is created, and they use those digests to Authenticate or to calculate ICV of packet using HMAC. Again Application need to supply inner and outer digests only if keys is changed or New SA is formed. RFC 2104 on HMAC Keyed Hashing tells that packet processing using authentication mechanism of HMAC computation using MD5 or SHA can be enhanced by having precomputed inner and outer digests of (K XOR ipad and K XOR opad , where K is Authentication Key, ipad 0x36 and opad is 0x5c as defined in RFC2104) K_ipad and K_opad zero padded strings. So that we need to to precompute these values only once when keys are created and can be used directly when there is a packet to process thus avoiding two hashes on Kipad and Kopad for every packet. however RFC does not tell about exact method of precomputing inner and outer digests of HMAC computation only once and using them untill key is changed. In my case Authentication is failing because I'm not able to precompute the inner and outer digests correctly :( . because, I dont have clear Idea on this aspect. Can you tell me how it can be done ? I mean what is the Exact method to do this? How Precomputed hashes on Kipad and Kopad are used for Authenticating packet? Thank You Lokesh ------_=_NextPart_001_01C11C1D.6B455620 Content-Type: text/html; charset="windows-1252"
Just do a partial H transform to (K xor ipad) to get the inner digest and another partial transform to (K xor opad) to get the outer digest. By partial transform I mean apply the actual MD5/SHA1 transforms to the (K xor *pad) block without the final padding (that will be done later when computing the icv). The MD5 transform is described in RFC 1321 and SHA in FIPS PUB 180-1.
 
Claudio.
-----Original Message-----
From: lokesh [mailto:lokeshnb@intotoinc.com]
Sent: Friday, August 03, 2001 1:46 AM
To: ipsec@lists.tislabs.com
Subject: problem with HMAC precomputes.

Hello all,
 
I'm doing a project on Ipsecurity and have come across a
problem. I'm sure some of you can help me with an answer
 
Many Crypto Accelerator Chips expect Ipsec application to
supply inner and outer digests of HMAC Authentication only once when Key is formed or a New SA is created, and they use those digests to Authenticate or to calculate ICV of packet using HMAC. Again Application need to supply inner and outer digests only if keys is changed or New SA is formed.
 
RFC 2104  on HMAC Keyed Hashing tells that packet processing using authentication mechanism of  HMAC computation using  MD5 or SHA can be enhanced by having precomputed inner and outer digests of
 (K XOR ipad and K XOR opad , where K is Authentication Key, ipad 0x36 and opad is 0x5c as defined in RFC2104)
 K_ipad and K_opad zero padded strings.
So that we need to to precompute these values only once when keys are created and can be used  directly when there is a packet to process thus avoiding two hashes on Kipad and Kopad for every packet. however RFC does not tell about exact method of precomputing inner and outer digests of HMAC computation  only once and using them untill key is changed.
 
In my case Authentication is failing because I'm not able to precompute the inner and outer digests correctly :( .
because, I dont have clear Idea on this aspect.
Can you tell me how it can be done ? I mean what is the Exact method to do this?
How Precomputed hashes on Kipad and Kopad are used
for Authenticating packet?
 
Thank You
Lokesh
 
 
------_=_NextPart_001_01C11C1D.6B455620-- From owner-ipsec@lists.tislabs.com Fri Aug 3 07:31:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73EVjs16684; Fri, 3 Aug 2001 07:31:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02603 Fri, 3 Aug 2001 09:39:10 -0400 (EDT) Reply-To: From: "JEEVA" To: Subject: ipsec design related questions. Date: Fri, 3 Aug 2001 13:55:41 +0530 Message-Id: <000001c11bf6$fb099ae0$2a05080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Disposition-Notification-To: "JEEVA" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi, i just had a doubt - where is IPSec placed in the network stack? conceptually, IPSec should be placed like this (please comment if wrong): Design -1 +--------------------------------+ Tcp/udp +--------------------------------+ IP other functions (Like routing etc.) +--------------------------------+ IPSec +--------------------------------+ low -level layer fuctions +--------------------------------+ Design - 2 : +--------------------------------+ tcp/udp +--------------------------------+ IPsec +-------------------------------+ IP other fuctions. +------------------------------+ low-level layer functions +-------------------------------+ Design -3 : +-------------------------------+ tcp/udp +-------------------------------+ IP/ IPsec +------------------------------+ low -level layer functions. +-----------------------------+ Design - 4: +---------------------------------+ applications +---------------------------------+ ---------------------------------- some intermediate layer for making ipsec independent. (e.g to implement socket layer ) ----------------------------------- --------------------------------- IPsec ------------------------------- thnaks. regards, jeeva. From owner-ipsec@lists.tislabs.com Fri Aug 3 07:33:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73EXks16734; Fri, 3 Aug 2001 07:33:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02542 Fri, 3 Aug 2001 09:36:07 -0400 (EDT) Message-Id: <200108022331.f72NVWB13759@marajade.sandelman.ottawa.on.ca> To: sommerfeld@East.Sun.COM cc: ipsec@lists.tislabs.com Subject: Re: IPSec performance statistics In-reply-to: Your message of "Thu, 02 Aug 2001 16:09:42 EDT." <200108022009.f72K9hJ06140@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 02 Aug 2001 19:30:28 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bill" == Bill Sommerfeld writes: Bill> Main mode + quick mode + first-user-traffic winds up being about 5 Bill> round trips, so network latency winds up being a dominant factor in Bill> how long it takes to get things flowing.. so long as there is enough CPU leftover, of course. I'd be interested to know how long it takes before 1000 road warriors are able to function again after rebooting the gateway :-) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Aug 3 08:06:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73F6ts19313; Fri, 3 Aug 2001 08:06:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02753 Fri, 3 Aug 2001 10:16:54 -0400 (EDT) Date: Fri, 3 Aug 2001 10:23:20 -0400 (EDT) From: Henry Spencer To: JEEVA cc: ipsec@lists.tislabs.com Subject: Re: ipsec design related questions. In-Reply-To: <000001c11bf6$fb099ae0$2a05080a@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Aug 2001, JEEVA wrote: > i just had a doubt - where is IPSec placed in the network stack? Please read RFC 2401, specifically section 3.3. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Aug 3 08:12:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73FCvs19546; Fri, 3 Aug 2001 08:12:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02741 Fri, 3 Aug 2001 10:15:29 -0400 (EDT) Date: Fri, 3 Aug 2001 10:21:49 -0400 (EDT) From: Henry Spencer To: Alex Alten cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development In-Reply-To: <3.0.3.32.20010802234951.00e4eb00@mail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Aug 2001, Alex Alten wrote: > ...Their suggestion to use a process like NIST's for selecting > the AES standard is an excellent one. It's a pity they did not suggest > it a decade ago. However it should be considered seriously not only > for the replacement of IKE, but possibly also for the modification or > simplification of the entire IPsec protocol suite... I think this is throwing the baby out with the bathwater. While the packet-level parts (ESP etc.) do have some flaws, most of those can be fixed simply by taking a big black pen and crossing out superfluous parts of the existing specs (e.g., all of RFC 2402). While there is room for some debate about exactly which parts should be crossed out (e.g., there are people who still think AH is useful), I think there would be little or no support for redesigning the surviving parts. So a design competition does not seem very useful in this area. Moreover, *this* is the area where there is massive investment in silicon, solder traces, etc. Just deleting features does not, by and large, invalidate that investment. IKE is the disaster area. The rest of IPsec could use some judicious featurectomies, but is not badly broken. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Aug 3 12:32:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73JWps28192; Fri, 3 Aug 2001 12:32:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03847 Fri, 3 Aug 2001 14:18:36 -0400 (EDT) Message-Id: <3.0.3.32.20010803112414.00eadaa0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 03 Aug 2001 11:24:14 -0700 To: Henry Spencer From: Alex Alten Subject: Re: Position statement on IKE development Cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: References: <3.0.3.32.20010802234951.00e4eb00@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Several people have asked me for the urls of the paper's analyzing IPsec and IKE. These are the ones I found searching the web last night. A Cryptographic Evaluation of IPsec by Niels Ferguson and Bruce Schneier http://www.counterpane.com/ipsec.pdf Analysis of the Internet Key Exchange Protocol Using the NRL Protocol Analyzer by Catherine Meadows http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/1999/1999meadows-IEE E99.ps IKE/ISAKMP Considered Dangerous by William Simpson draft-simpson-danger-isakmp-01.txt http://www.alternic.org/drafts/drafts-s-t/draft-simpson-danger-isakmp-01.html BTW Henry, The issue is not that parts of IPsec are superfluous. The question is if IKE is broken then is IPsec also broken? - Alex At 10:21 AM 8/3/2001 -0400, Henry Spencer wrote: >On Thu, 2 Aug 2001, Alex Alten wrote: >> ...Their suggestion to use a process like NIST's for selecting >> the AES standard is an excellent one. It's a pity they did not suggest >> it a decade ago. However it should be considered seriously not only >> for the replacement of IKE, but possibly also for the modification or >> simplification of the entire IPsec protocol suite... > >I think this is throwing the baby out with the bathwater. > >While the packet-level parts (ESP etc.) do have some flaws, most of those >can be fixed simply by taking a big black pen and crossing out superfluous >parts of the existing specs (e.g., all of RFC 2402). While there is room >for some debate about exactly which parts should be crossed out (e.g., >there are people who still think AH is useful), I think there would be >little or no support for redesigning the surviving parts. So a design >competition does not seem very useful in this area. Moreover, *this* is >the area where there is massive investment in silicon, solder traces, etc. >Just deleting features does not, by and large, invalidate that investment. > >IKE is the disaster area. The rest of IPsec could use some judicious >featurectomies, but is not badly broken. > > Henry Spencer > henry@spsystems.net > > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Fri Aug 3 12:32:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73JWqs28200; Fri, 3 Aug 2001 12:32:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03919 Fri, 3 Aug 2001 14:40:22 -0400 (EDT) Message-Id: <200108031847.OAA06613@bcn.East.Sun.COM> Date: Fri, 3 Aug 2001 14:47:15 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Another paper analyzing IKE To: henry@spsystems.net, Alten@home.com Cc: mleech@nortelnetworks.com, msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7C6ZlrC1Nr0L0ACd3hyYAA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Analysis of the IPsec Key Exchange Standard, by Radia Perlman and Charlie Kaufman http://sec.femto.org/wetice-2001/papers/radia-paper.pdf (It's also summarized in an internet draft "code-preserving simplifications and improvements to IKE" which is pointed to from the IPsec web page). Radia From owner-ipsec@lists.tislabs.com Fri Aug 3 12:32:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73JWvs28219; Fri, 3 Aug 2001 12:32:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03839 Fri, 3 Aug 2001 14:14:31 -0400 (EDT) Message-ID: <23051C9F9BABD411A7850002B30847992587BA@delta.allegrosys.com> From: Bora Akyol To: "'Henry Spencer'" Cc: ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Position statement on IKE development Date: Fri, 3 Aug 2001 10:48:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As a newcomer to IPSec field (but not to the IETF) one of the things that continues the amaze me is the deliberate effort that has been made to create a wall between IKE and IPSEC. IKE is written such that it is a general protocol that can negotiate SAs for protocols other than IP such as AppleTalk, IPX, ... Yet the primary (and possibly only use) of IKE is for negotiating IPSEC SAs (in addition to the IKE SA). The IPSEC DOI (unfortunately) is also written in a pretty generic manner and does very little to aid a developer writing IKE software from scratch. For example, what exactly IKE can negotiate with respect to IP selector fields and ranges is pretty much left to the interpretation of the developers. IMHO, IPSEC SA negotiation also is the biggest cause of headaches in interoperability problems between different implementations. Which I believe was what Henry was alluding to below. Therefore, I would suggest that any effort in replacing IKE also consider replacing/rewriting portions of IPSEC DOI such that: 1) Text is clear and one could write easily working code from it. 2) The IPSEC SA negotiation within IKE is well-defined and not open to interpretation. 3) All error cases are documented and handling is clearly specified. 4) Some references added to the text to at least outline what to do when negotiating behind a NAT/firewall and refer to relevant RFCs/drafts. As far as I am concerned, IKE is the moral equivalent of a signaling protocol that establishes connections (IPSEC SAs in IKE case) and should be specified in enough detail as such. I have seen similar problems while developing MPLS code with the MPLS specs but as we were writing software while the drafts were still drafts, most of the complaints did get addressed before they became RFCS. Also note that I am making these suggestions with a constructive desire. Regards, Bora ps. I would be willing to volunteer in such an effort as I described above. |-----Original Message----- |From: Henry Spencer [mailto:henry@spsystems.net] |Sent: Friday, August 03, 2001 7:22 AM |To: Alex Alten |Cc: Marcus Leech; msec@securemulticast.org; ietf-ipsra@vpnc.org; |ipsec-policy@vpnc.org; ipsec@lists.tislabs.com |Subject: Re: Position statement on IKE development | | |On Thu, 2 Aug 2001, Alex Alten wrote: |> ...Their suggestion to use a process like NIST's for selecting |> the AES standard is an excellent one. It's a pity they did |not suggest |> it a decade ago. However it should be considered seriously not only |> for the replacement of IKE, but possibly also for the modification or |> simplification of the entire IPsec protocol suite... | |I think this is throwing the baby out with the bathwater. | |While the packet-level parts (ESP etc.) do have some flaws, |most of those |can be fixed simply by taking a big black pen and crossing out |superfluous |parts of the existing specs (e.g., all of RFC 2402). While |there is room |for some debate about exactly which parts should be crossed out (e.g., |there are people who still think AH is useful), I think there would be |little or no support for redesigning the surviving parts. So a design |competition does not seem very useful in this area. Moreover, |*this* is |the area where there is massive investment in silicon, solder |traces, etc. |Just deleting features does not, by and large, invalidate that |investment. | |IKE is the disaster area. The rest of IPsec could use some judicious |featurectomies, but is not badly broken. | | Henry Spencer | |henry@spsystems.net | | From owner-ipsec@lists.tislabs.com Fri Aug 3 12:37:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73Jbts28329; Fri, 3 Aug 2001 12:37:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04276 Fri, 3 Aug 2001 14:51:57 -0400 (EDT) Message-Id: <200108031857.f73IviJ20038@thunk.east.sun.com> From: Bill Sommerfeld To: Bora Akyol cc: "'Henry Spencer'" , ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development In-reply-to: Your message of "Fri, 03 Aug 2001 10:48:58 PDT." <23051C9F9BABD411A7850002B30847992587BA@delta.allegrosys.com> Reply-to: sommerfeld@East.Sun.COM Date: Fri, 03 Aug 2001 14:57:44 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > As a newcomer to IPSec field (but not to the IETF) one of the things that > continues the amaze me is the deliberate effort that has been made to create > a wall between IKE and IPSEC. Well, this is a good thing -- it means that if you get IKE wrong, it can be replaced without having to toss the rest of the architecture. The solaris implementation is structured specifically to allow for this; we're extending PF_KEY and adding a PF_POLICY to allow for a strong separation of concerns between packet protection policy, packet protection mechanisms, and key management. This is one of the reasons why we (me and my fellow implementors here) don't want any ipsra authentication/cert provisioning protocols running on port 500.. > Therefore, I would suggest that any effort in replacing IKE also consider > replacing/rewriting portions of IPSEC DOI ... Last I heard, the son-of-ike plan was to merge the DOI into the key mgmt document. I think we also need a better-defined interface between 2401 and the KM protocol... - Bill From owner-ipsec@lists.tislabs.com Fri Aug 3 13:15:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73KFbs01803; Fri, 3 Aug 2001 13:15:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04466 Fri, 3 Aug 2001 15:35:33 -0400 (EDT) Date: Fri, 3 Aug 2001 15:41:57 -0400 (EDT) From: Henry Spencer To: Alex Alten cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development In-Reply-To: <3.0.3.32.20010803112414.00eadaa0@mail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Aug 2001, Alex Alten wrote: > BTW Henry, > The issue is not that parts of IPsec are superfluous. > The question is if IKE is broken then is IPsec also broken? That depends somewhat on exactly what you mean by "IPsec", which is why I specifically referred to "the packet-level parts". I don't think there is much wrong with the packet-level stuff except for a few too many useless options and alternatives. The key-management ugliness doesn't seem to me to have spilled over into the packet level (at least partly because the packet-level work was nearly finished before key management came to the fore). Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Aug 3 13:24:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73KODs02512; Fri, 3 Aug 2001 13:24:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04450 Fri, 3 Aug 2001 15:22:44 -0400 (EDT) Date: Fri, 3 Aug 2001 15:29:09 -0400 (EDT) From: Henry Spencer To: IP Security List cc: ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org Subject: Re: Position statement on IKE development In-Reply-To: <200108031857.f73IviJ20038@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Aug 2001, Bill Sommerfeld wrote: > > Therefore, I would suggest that any effort in replacing IKE also consider > > replacing/rewriting portions of IPSEC DOI ... > > Last I heard, the son-of-ike plan was to merge the DOI into the key > mgmt document. Realistically, there's no meaningful distinction between IKE and the DOI. In fact, the separation between the two documents is a real nuisance when one is looking for obscure details. They need to be considered as a unit. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Aug 3 14:12:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73LC1s03897; Fri, 3 Aug 2001 14:12:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04501 Fri, 3 Aug 2001 16:14:52 -0400 (EDT) Message-Id: <3.0.3.32.20010803132027.00eae6b0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 03 Aug 2001 13:20:27 -0700 To: Henry Spencer From: Alex Alten Subject: Re: Position statement on IKE development Cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: References: <3.0.3.32.20010803112414.00eadaa0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Unfortunately what you and I think probably doesn't matter. What matters is that end user customers will hear that IPsec's IKE is broken, and they will then ask themselves the question, is all of IPsec also broken? It's anyone's guess as to how this will play out in the VPN markets, etc. My own personal question is why the IPsec working group did not have a thorough cryptanalysis done by professionals, say by an outfit like ISSI, before the standards were issued? - Alex At 03:41 PM 8/3/2001 -0400, Henry Spencer wrote: >On Fri, 3 Aug 2001, Alex Alten wrote: >> BTW Henry, >> The issue is not that parts of IPsec are superfluous. >> The question is if IKE is broken then is IPsec also broken? > >That depends somewhat on exactly what you mean by "IPsec", which is why I >specifically referred to "the packet-level parts". I don't think there is >much wrong with the packet-level stuff except for a few too many useless >options and alternatives. The key-management ugliness doesn't seem to me >to have spilled over into the packet level (at least partly because the >packet-level work was nearly finished before key management came to the >fore). > > Henry Spencer > henry@spsystems.net > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Fri Aug 3 14:28:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73LSjs04231; Fri, 3 Aug 2001 14:28:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04516 Fri, 3 Aug 2001 16:30:34 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA41@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Marcus Leech'" , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Position statement on IKE development Date: Fri, 3 Aug 2001 13:37:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11C5C.14D9EDC0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11C5C.14D9EDC0 Content-Type: text/plain; charset="iso-8859-1" I have a different set of concerns, IPSEC is not being used in cases where it should have been the answer. In particular the IEEE 802.11b WEP fiasco could have been averted if the designers had not been discouraged by the complexity of IPSEC. Another issue is why can't I buy a printer that is IPSEC enabled? I believe that the biggest problem with IPSEC is that the search for a certain view of perfect security has lead to a standard that many have bypassed altogether as too demanding. Perfect Forward Secrecy is great, but I would rather have a secure means of connecting to my printer than the possibility of a perfectly secure means in ten years time. End to end security is a good thing, but in many applications the overhead of negotiating trust relationships end to end is just too high. How am I expected to configure the end to end security on an embedded device with no console. Oh I use a web browser to connect to it, yes very end to end. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Marcus Leech [mailto:mleech@nortelnetworks.com] > Sent: Thursday, August 02, 2001 9:34 PM > To: msec@securemulticast.org; ietf-ipsra@vpnc.org; > ipsec-policy@vpnc.org; ipsec@lists.tislabs.com > Subject: Position statement on IKE development > > > I'm sending the attached ASCII TEXT document on behalf of myself, Jeff > Schiller, and > Steve Bellovin, to clarify our position with respect to IKE > development. It is our hope > that it will clarify, to some extent, some fuzziness in > this area that > has evolved over > the last year or so. > ------_=_NextPart_000_01C11C5C.14D9EDC0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C11C5C.14D9EDC0-- From owner-ipsec@lists.tislabs.com Fri Aug 3 15:05:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73M5ps05879; Fri, 3 Aug 2001 15:05:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04585 Fri, 3 Aug 2001 17:11:46 -0400 (EDT) To: "Hallam-Baker, Phillip" Cc: "'Marcus Leech'" , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development References: <2F3EC696EAEED311BB2D009027C3F4F40154CA41@vhqpostal.verisign.com> From: Derek Atkins Date: 03 Aug 2001 17:18:11 -0400 In-Reply-To: "Hallam-Baker, Phillip"'s message of "Fri, 3 Aug 2001 13:37:15 -0700" Message-ID: Lines: 88 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think certificate management (and distribution) within IKE is the biggest problem of all. I want to talk to the host/printer/network device at address 1.2.3.4. How do I get it's public key, and why do I want to trust it? PFS is _EASY_ compared to that. An ephemeral DH exchange solves PFS. But how do I authenticate? Better, how do I authenticate on a GLOBAL scale? Now _THAT_ is the hard problem (IMHO). -derek "Hallam-Baker, Phillip" writes: > I have a different set of concerns, IPSEC is not being used in cases where > it should have been the answer. > > In particular the IEEE 802.11b WEP fiasco could have been averted if the > designers had not been discouraged by the complexity of IPSEC. > > Another issue is why can't I buy a printer that is IPSEC enabled? > > I believe that the biggest problem with IPSEC is that the search for a > certain view of perfect security has lead to a standard that many have > bypassed altogether as too demanding. > > Perfect Forward Secrecy is great, but I would rather have a secure means of > connecting to my printer than the possibility of a perfectly secure means in > ten years time. > > End to end security is a good thing, but in many applications the overhead > of negotiating trust relationships end to end is just too high. How am I > expected to configure the end to end security on an embedded device with no > console. Oh I use a web browser to connect to it, yes very end to end. > > Phill > > > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > > -----Original Message----- > > From: Marcus Leech [mailto:mleech@nortelnetworks.com] > > Sent: Thursday, August 02, 2001 9:34 PM > > To: msec@securemulticast.org; ietf-ipsra@vpnc.org; > > ipsec-policy@vpnc.org; ipsec@lists.tislabs.com > > Subject: Position statement on IKE development > > > > > > I'm sending the attached ASCII TEXT document on behalf of myself, Jeff > > Schiller, and > > Steve Bellovin, to clarify our position with respect to IKE > > development. It is our hope > > that it will clarify, to some extent, some fuzziness in > > this area that > > has evolved over > > the last year or so. > > > > > ------_=_NextPart_000_01C11C5C.14D9EDC0 > Content-Type: application/octet-stream; > name="Phillip Hallam-Baker (E-mail).vcf" > Content-Disposition: attachment; > filename="Phillip Hallam-Baker (E-mail).vcf" > > BEGIN:VCARD > VERSION:2.1 > N:Hallam-Baker;Phillip > FN:Phillip Hallam-Baker (E-mail) > ORG:VeriSign > TITLE:Principal Consultant > TEL;WORK;VOICE:(781) 245-6996 x227 > EMAIL;PREF;INTERNET:hallam@verisign.com > REV:20010214T163732Z > END:VCARD > > ------_=_NextPart_000_01C11C5C.14D9EDC0-- -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Aug 3 15:34:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73MYas06489; Fri, 3 Aug 2001 15:34:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04610 Fri, 3 Aug 2001 17:38:55 -0400 (EDT) Message-Id: <200108032145.f73Lj5J21336@thunk.east.sun.com> From: Bill Sommerfeld To: Alex Alten cc: "Marcus Leech" , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development In-reply-to: Your message of "Thu, 02 Aug 2001 22:04:54 PDT." <3.0.3.32.20010802220454.00fc0530@mail> Reply-to: sommerfeld@East.Sun.COM Date: Fri, 03 Aug 2001 17:45:05 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Let's hold an international design competition to select a key > management protocol for IPSec in a manner similar to how NIST did > the AES selection (although I hope it takes less than 5 years). > Once we get to a final 5, then let's cryptanalyze them and select > the best one. In this manner hopefully we can avoid a 2nd debacle. the worst of IKE's problems are not in the cryptography. Besides the general complexity of encoding, there's also the matter of robustness in the face of retransmissions, as well as loss of peer state. Not to mention flash crowds and flooding attacks.. From owner-ipsec@lists.tislabs.com Fri Aug 3 15:40:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73MePs06744; Fri, 3 Aug 2001 15:40:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04640 Fri, 3 Aug 2001 17:54:57 -0400 (EDT) Message-Id: <200108032159.f73Lwxd01332@dharkins@lounge.orgatty.lounge.org> To: Alex Alten Cc: Henry Spencer , Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development In-Reply-To: Your message of "Fri, 03 Aug 2001 11:24:14 PDT." <3.0.3.32.20010803112414.00eadaa0@mail> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1329.996875939.1@lounge.org> Date: Fri, 03 Aug 2001 14:58:59 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 03 Aug 2001 11:24:14 PDT you wrote > > BTW Henry, > > The issue is not that parts of IPsec are superfluous. > > The question is if IKE is broken then is IPsec also broken? > > - Alex No, of course not. And you are assuming that IKE is broken. What has been noted by all the analysis mentiond so far is that IKE is too complex to know whether it is broken or not. The effort is to make it less complex, get rid of unnecessary and unused options, get rid of the inconsistent and sometimes contradictory verbage between the 3 RFCs, and make it a specification of a key management protocol for IPsec and IPsec only instead of the current instantiation (RFC2407) of a protocol framework (RFC2409) of a generic language (RFC2408). Dan. From owner-ipsec@lists.tislabs.com Fri Aug 3 15:44:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73Mids06809; Fri, 3 Aug 2001 15:44:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04647 Fri, 3 Aug 2001 17:55:21 -0400 (EDT) Message-Id: <4.3.2.7.0.20010803164227.01c2fab0@STPNTMX03.sctc.com> X-Sender: smith@STPNTMX03.sctc.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Aug 2001 16:58:09 -0500 To: Alex Alten From: Rick Smith at Secure Computing Subject: Re: Position statement on IKE development Cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <3.0.3.32.20010803132027.00eae6b0@mail> References: <3.0.3.32.20010803112414.00eadaa0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:20 PM 8/3/2001, Alex Alten wrote: >Unfortunately what you and I think probably doesn't matter. What matters >is that end user customers will hear that IPsec's IKE is broken, and they >will then ask themselves the question, is all of IPsec also broken? It's >anyone's guess as to how this will play out in the VPN markets, etc. It's not as if VPN customers have a well-recognized alternative with a less tarnished reputation. If anything, this simply illustrates how much pioneering work has gone into IKE. >My own personal question is why the IPsec working group did not have a >thorough cryptanalysis done by professionals, say by an outfit like ISSI, >before the standards were issued? Some weaknesses emerge only after you've actually built and deployed a protocol. Such flaws may be in the implementation, but some may be faulty assumptions about how the protocol will work in a practical deployment. It's especially hard to predict problems when the protocol is the foundation of a fairly new class of products, like VPN gateways, since there's not enough well-known prior art to base the analytical models on. Rick. smith@securecomputing.com From owner-ipsec@lists.tislabs.com Fri Aug 3 15:57:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73Mv5s06977; Fri, 3 Aug 2001 15:57:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04685 Fri, 3 Aug 2001 18:11:56 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPSec performance statistics Date: Fri, 3 Aug 2001 15:20:03 -0700 Message-ID: <4EBB5C35607E7F48B4AE162D956666EF339147@guam.corp.axcelerant.com> Thread-Topic: IPSec performance statistics Thread-Index: AcEcN9hqgG0w6q6MQ22IAhzbgs6SewAMjruw From: "Christopher Gripp" To: "Michael Richardson" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA04682 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, I have seen 300+ simultaneous connections renegotiatiate within 30 seconds after a reboot with only 10-20 dropped packets. This was on a RedCreek 7150 terminating Personal Ravlin II's. Christopher S. Gripp Systems Engineer Axcelerant -----Original Message----- From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: Thursday, August 02, 2001 4:30 PM To: sommerfeld@East.Sun.COM Cc: ipsec@lists.tislabs.com Subject: Re: IPSec performance statistics >>>>> "Bill" == Bill Sommerfeld writes: Bill> Main mode + quick mode + first-user-traffic winds up being about 5 Bill> round trips, so network latency winds up being a dominant factor in Bill> how long it takes to get things flowing.. so long as there is enough CPU leftover, of course. I'd be interested to know how long it takes before 1000 road warriors are able to function again after rebooting the gateway :-) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Aug 3 16:15:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73NFQs07505; Fri, 3 Aug 2001 16:15:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04731 Fri, 3 Aug 2001 18:23:48 -0400 (EDT) Message-Id: <3.0.3.32.20010803152924.00ed6b10@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 03 Aug 2001 15:29:24 -0700 To: Dan Harkins From: Alex Alten Subject: Re: Position statement on IKE development Cc: Henry Spencer , Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <200108032159.f73Lwxd01332@dharkins@lounge.orgatty.lounge.o rg> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Quoting Marcus, Jeff and Steve: "The Security Area Directors have asked the IPSEC working group to come up with a replacement for IKE. This work is underway and is known in the community as "Son of IKE". " "If IKE is vulnerable, we must all share a burden of responsibility for allowing it to get to the state it is in and we must all work together to correct the problems." OK. IKE is not technically broken. But it sure sounds like someone is worried. Otherwise why bother with a replacement for IKE? It's rather ironic that the 802.11 wireless key management was broken just recently as well. - Alex At 02:58 PM 8/3/2001 -0700, Dan Harkins wrote: >On Fri, 03 Aug 2001 11:24:14 PDT you wrote >> >> BTW Henry, >> >> The issue is not that parts of IPsec are superfluous. >> >> The question is if IKE is broken then is IPsec also broken? >> >> - Alex > >No, of course not. > >And you are assuming that IKE is broken. What has been noted by all the >analysis mentiond so far is that IKE is too complex to know whether it >is broken or not. The effort is to make it less complex, get rid of >unnecessary and unused options, get rid of the inconsistent and sometimes >contradictory verbage between the 3 RFCs, and make it a specification of >a key management protocol for IPsec and IPsec only instead of the current >instantiation (RFC2407) of a protocol framework (RFC2409) of a generic >language (RFC2408). > > Dan. > > > > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Fri Aug 3 16:15:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73NFvs07519; Fri, 3 Aug 2001 16:15:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04751 Fri, 3 Aug 2001 18:30:15 -0400 (EDT) Message-Id: <200108032235.f73MZDd01426@dharkins@lounge.orgatty.lounge.org> To: Henry Spencer Cc: IP Security List , ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org Subject: Re: Position statement on IKE development In-Reply-To: Your message of "Fri, 03 Aug 2001 15:29:09 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1423.996878113.1@lounge.org> Date: Fri, 03 Aug 2001 15:35:13 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I discussed this in Minneapolis. The plan is to combine ISAKMP, IKE, and the IPsec DOI into a single draft describing a key management protocol for IPsec. The intent, as well-meaning as it was, was to have a generic language (ISAKMP) in which to describe a key management protocol and there could be many key management protocols with IKE as just one of them. IKE, then, was supposed to be a generic key exchange protocol which could create "SAs" for multiple services, of which IPsec (specified in the DOI) was just one. But IKE is the only thing that used ISAKMP and the other two DOI documents-- OSPF and RIP-- died a quiet death. The benefit of having this artificial layering is nil and the cost (the nuisance factor you mention, the conflicting verbage, the unnecessary repetition of things, the incredible complexity it causes) is high so it is being done away with. There should be only one thing that listens on UDP port 500 and that is a key management protocol for IPsec which should be described in a (relatively) short and concise draft. I'm working on it. Dan. On Fri, 03 Aug 2001 15:29:09 EDT Henry Spencer wrote > On Fri, 3 Aug 2001, Bill Sommerfeld wrote: > > > Therefore, I would suggest that any effort in replacing IKE also consider > > > replacing/rewriting portions of IPSEC DOI ... > > > > Last I heard, the son-of-ike plan was to merge the DOI into the key > > mgmt document. > > Realistically, there's no meaningful distinction between IKE and the DOI. > In fact, the separation between the two documents is a real nuisance when > one is looking for obscure details. They need to be considered as a unit. > > Henry Spencer > henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Aug 3 16:44:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73Ni6s07813; Fri, 3 Aug 2001 16:44:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04812 Fri, 3 Aug 2001 18:52:29 -0400 (EDT) Message-Id: <200108032257.f73MvCd01488@dharkins@lounge.orgatty.lounge.org> To: alten@tristrata.com Cc: ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development In-Reply-To: Your message of "Fri, 03 Aug 2001 15:29:24 PDT." <3.0.3.32.20010803152924.00ed6b10@mail> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1485.996879432.1@lounge.org> Date: Fri, 03 Aug 2001 15:57:12 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Nothing like what happened to 802.11 has happened to IKE so don't say "as well". It's unfortunate that this position statement gives an opportunity for vendors which sell non-IPsec network security products to spread FUD. We should all be worried about IKE because, as I said, it is complex. There is way too much complexity to just establish IPsec SAs and that complexity naturally makes people worried. That issue is being addressed. Dan. On Fri, 03 Aug 2001 15:29:24 PDT you wrote > > Quoting Marcus, Jeff and Steve: > > "The Security Area Directors have asked the IPSEC working group to come > up with a replacement for IKE. This work is underway and is known in > the community as "Son of IKE". " > > "If IKE is vulnerable, we must all share a burden of responsibility for > allowing it to get to the state it is in and we must all work together > to correct the problems." > > OK. IKE is not technically broken. But it sure sounds like someone > is worried. Otherwise why bother with a replacement for IKE? > > It's rather ironic that the 802.11 wireless key management was broken > just recently as well. > > - Alex > > At 02:58 PM 8/3/2001 -0700, Dan Harkins wrote: > >On Fri, 03 Aug 2001 11:24:14 PDT you wrote > >> > >> BTW Henry, > >> > >> The issue is not that parts of IPsec are superfluous. > >> > >> The question is if IKE is broken then is IPsec also broken? > >> > >> - Alex > > > >No, of course not. > > > >And you are assuming that IKE is broken. What has been noted by all the > >analysis mentiond so far is that IKE is too complex to know whether it > >is broken or not. The effort is to make it less complex, get rid of > >unnecessary and unused options, get rid of the inconsistent and sometimes > >contradictory verbage between the 3 RFCs, and make it a specification of > >a key management protocol for IPsec and IPsec only instead of the current > >instantiation (RFC2407) of a protocol framework (RFC2409) of a generic > >language (RFC2408). > > > > Dan. > > > > > > > > > > > -- > > Alex Alten > > Alten@Home.Com > > From owner-ipsec@lists.tislabs.com Fri Aug 3 16:44:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73NiFs07826; Fri, 3 Aug 2001 16:44:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04782 Fri, 3 Aug 2001 18:50:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20010803155109.04464d58@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Aug 2001 15:56:02 -0700 To: Alex Alten From: Mark Baugher Subject: Re: Position statement on IKE development Cc: msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <3.0.3.32.20010802220454.00fc0530@mail> References: <3B69FF7B.85CF61@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ferguson and Schneier suggested the same thing as an alternative to design-by-committee, which they suggested was the source of problems with IPsec and IKE. When I read this, I did not think it was a viable solution because the IPsec and IKE requirements were so much more complex than AES. I don't think their criticisms of IKE were ever addressed on this list though the points about AH and ESP were as I recall. Mark At 10:04 PM 8/2/2001 -0700, Alex Alten wrote: >Dear Marcus, Jeff and Steve, > >May I make a suggestion given the seriousness of this? > >Let's hold an international design competition to select a key >management protocol for IPSec in a manner similar to how NIST did >the AES selection (although I hope it takes less than 5 years). >Once we get to a final 5, then let's cryptanalyze them and select >the best one. In this manner hopefully we can avoid a 2nd debacle. > >Sincerely, > >- Alex Alten > > >At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote: > >I'm sending the attached ASCII TEXT document on behalf of myself, Jeff > >Schiller, and > > Steve Bellovin, to clarify our position with respect to IKE > >development. It is our hope > > that it will clarify, to some extent, some fuzziness in this area that > >has evolved over > > the last year or so.In the several years since the standardization of >the IPSEC protocols > >(ESP, AH, and ISAKMP/IKE), there have come to light several security > >problems with the protocols, most notably the key-agreement protocol, > >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and > >Simpson, have shown that the security problems in IKE stem directly > >from its complexity. It seems only a matter of time before more > >analyses show more serious security issues in the protocol design that > >stem directly from its complexity. It seems also, only a matter of > >time, before serious *implementation* problems become apparent, again > >due to the complex nature of the protocol, and the complex > >implementation that must surely follow. > >... > > > > > > >Marcus Leech (IESG) > >Jeff Schiller (IESG) > >Steve Bellovin (IAB) > > >-- > >Alex Alten > >Alten@Home.Com From owner-ipsec@lists.tislabs.com Fri Aug 3 18:52:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f741qds09393; Fri, 3 Aug 2001 18:52:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04964 Fri, 3 Aug 2001 20:57:57 -0400 (EDT) To: Alex Alten Cc: msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-reply-to: Alten's message of Fri, 03 Aug 2001 15:29:24 MST. <3.0.3.32.20010803152924.00ed6b10@mail> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Position statement on IKE development From: itojun@iijlab.net Date: Sat, 04 Aug 2001 10:03:20 +0900 Message-ID: <6530.996887000@itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (stripped off some of the explicit cc:s) just checking: does "ongoing work on Son of IKE" mean this draft, or something else? draft-ietf-ipsec-improveike-00.txt itojun From owner-ipsec@lists.tislabs.com Sat Aug 4 00:36:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f747als29105; Sat, 4 Aug 2001 00:36:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA05245 Sat, 4 Aug 2001 02:08:42 -0400 (EDT) Date: Fri, 3 Aug 2001 23:01:44 -0700 (PDT) From: Bernard Aboba To: Bill Sommerfeld cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development In-Reply-To: <200108032145.f73Lj5J21336@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Let's hold an international design competition to select a key > management protocol for IPSec in a manner similar to how NIST did > the AES selection (although I hope it takes less than 5 years). > Once we get to a final 5, then let's cryptanalyze them and select > the best one. In this manner hopefully we can avoid a 2nd debacle. > In practice, such a competition is being held every day in the offices of customers. The problem is that the contenders are proprietary versions of IKE (IKE's evil sisters), that there is no cryptanalysis available, and that the decision criteria and selection are not openly discussed. I can state from experience that the "Cinderella IKE" that we now seek to shelter rarely wins these private beauty contests against the evil sisters. This is in part, because it is not a good match to customer requirements such as the need for NAT friendliness and a viable shared-secret authentication mode. It seems to me that unless we can find a "glass slipper" for Cinderella IKE, that it will languish as the evil sisters grow stronger and more popular. While we might not like this outcome, or feel that it is "right", the evidence is to strong to ignore. Cinderella IKE just isn't being invited to the ball. From owner-ipsec@lists.tislabs.com Sat Aug 4 07:13:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74EDgs16458; Sat, 4 Aug 2001 07:13:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05487 Sat, 4 Aug 2001 09:07:05 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Henry Spencer Cc: Alex Alten , Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Aug 2001 09:12:51 -0400 Message-Id: <20010804131251.B07AF7B5B@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Henry Spe ncer writes: > >On Thu, 2 Aug 2001, Alex Alten wrote: >> ...Their suggestion to use a process like NIST's for selecting >> the AES standard is an excellent one. It's a pity they did not suggest >> it a decade ago. However it should be considered seriously not only >> for the replacement of IKE, but possibly also for the modification or >> simplification of the entire IPsec protocol suite... > >I think this is throwing the baby out with the bathwater. > >While the packet-level parts (ESP etc.) do have some flaws, most of those >can be fixed simply by taking a big black pen and crossing out superfluous >parts of the existing specs (e.g., all of RFC 2402). While there is room >for some debate about exactly which parts should be crossed out (e.g., >there are people who still think AH is useful), I think there would be >little or no support for redesigning the surviving parts. So a design >competition does not seem very useful in this area. Moreover, *this* is >the area where there is massive investment in silicon, solder traces, etc. >Just deleting features does not, by and large, invalidate that investment. > >IKE is the disaster area. The rest of IPsec could use some judicious >featurectomies, but is not badly broken. Agreed. And large parts of the Schneier/Ferguson analysis of the packet-level parts are just plain wrong. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Sat Aug 4 15:42:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74MgTs28450; Sat, 4 Aug 2001 15:42:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05893 Sat, 4 Aug 2001 17:36:46 -0400 (EDT) Message-Id: <3.0.3.32.20010804144227.00ebdb30@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sat, 04 Aug 2001 14:42:27 -0700 To: "Steven M. Bellovin" , Henry Spencer From: Alex Alten Subject: Re: Position statement on IKE development Cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <20010804131251.B07AF7B5B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:12 AM 8/4/2001 -0400, Steven M. Bellovin wrote: >In message , Henry Spe >ncer writes: >> >>On Thu, 2 Aug 2001, Alex Alten wrote: >>> ...Their suggestion to use a process like NIST's for selecting >>> the AES standard is an excellent one. It's a pity they did not suggest >>> it a decade ago. However it should be considered seriously not only >>> for the replacement of IKE, but possibly also for the modification or >>> simplification of the entire IPsec protocol suite... >> >>I think this is throwing the baby out with the bathwater. >> >>While the packet-level parts (ESP etc.) do have some flaws, most of those >>can be fixed simply by taking a big black pen and crossing out superfluous >>parts of the existing specs (e.g., all of RFC 2402). While there is room >>for some debate about exactly which parts should be crossed out (e.g., >>there are people who still think AH is useful), I think there would be >>little or no support for redesigning the surviving parts. So a design >>competition does not seem very useful in this area. Moreover, *this* is >>the area where there is massive investment in silicon, solder traces, etc. >>Just deleting features does not, by and large, invalidate that investment. >> >>IKE is the disaster area. The rest of IPsec could use some judicious >>featurectomies, but is not badly broken. > >Agreed. And large parts of the Schneier/Ferguson analysis of the >packet-level parts are just plain wrong. > Steve, with all due respect, you, Jeff and Marcus stated the following. "In the several years since the standardization of the IPSEC protocols (ESP, AH, and ISAKMP/IKE), there have come to light several security problems with the protocols, most notably the key-agreement protocol, IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and Simpson, have shown that the security problems in IKE stem directly from its complexity." If IKE is no longer considered viable because of it's complexity, then I am concerned that the other protocols of IPsec are also at risk. This is not my concern alone, others have expressed it to me as well. At this point, to restore confidence in the security of the design I would hope that the IETF will retain the services of a quality cryptanalysis consulting firm and publish the results. To do otherwise will be to risk the discrediting of the entire IPsec standard. Sincerely, - Alex -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Sat Aug 4 16:38:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74Nc4s29077; Sat, 4 Aug 2001 16:38:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05941 Sat, 4 Aug 2001 18:55:30 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Alex Alten Cc: Henry Spencer , Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Aug 2001 00:00:25 +0100 Message-Id: <20010804230025.A59117B5B@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3.0.3.32.20010804144227.00ebdb30@mail>, Alex Alten writes: >> >>Agreed. And large parts of the Schneier/Ferguson analysis of the >>packet-level parts are just plain wrong. >> > > >Steve, with all due respect, you, Jeff and Marcus stated the following. > >"In the several years since the standardization of the IPSEC protocols >(ESP, AH, and ISAKMP/IKE), there have come to light several security >problems with the protocols, most notably the key-agreement protocol, >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and >Simpson, have shown that the security problems in IKE stem directly >from its complexity." > >If IKE is no longer considered viable because of it's complexity, then >I am concerned that the other protocols of IPsec are also at risk. This >is not my concern alone, others have expressed it to me as well. > >At this point, to restore confidence in the security of the design I >would hope that the IETF will retain the services of a quality >cryptanalysis consulting firm and publish the results. To do otherwise >will be to risk the discrediting of the entire IPsec standard. Frankly, a lot of very competent folks did look at the cryptography. WIth all due modesty, I published two papers on the subject myself, and I wasn't the only one. In fact, that's one of the reasons why IPsec took so long -- the result of those analyses is why RFCs 1825-29 were replaced by 2401 et al. -- because we found and fixed a fair number of problems. The flaws in the Schneier/Ferguson analysis are because they don't understand the networking context. I sent Bruce a long, detailed note about that before he ever published the analysis. You say "retain the services of a quality cryptanalysis consulting firm". Apart from the point that there aren't that many -- and I and others know most of the likely players in the field -- the question is whether or not they understand the networking context. I have no particular reason to think that the results would be any better than what we have now. Is IPsec perfect? No, of course not. I'd like to get rid of AH, for example, not because it doesn't work -- it does -- but because it adds complexity to implementations without (to me) doing anything useful. There are a few other minor things I'd have done differently. But I have a great deal of confidence in the correctness of the packet-level transforms. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Sat Aug 4 16:59:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74NxBs29298; Sat, 4 Aug 2001 16:59:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA05926 Sat, 4 Aug 2001 18:48:10 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Position statement on IKE development Date: 4 Aug 2001 22:52:02 GMT Organization: University of California, Berkeley Lines: 18 Distribution: isaac Message-ID: <9khuai$1hi$1@abraham.cs.berkeley.edu> References: <20010804131251.B07AF7B5B@berkshire.research.att.com> <3.0.3.32.20010804144227.00ebdb30@mail> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 996965522 1586 128.32.45.153 (4 Aug 2001 22:52:02 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 4 Aug 2001 22:52:02 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten wrote: >If IKE is no longer considered viable because of it's complexity, then >I am concerned that the other protocols of IPsec are also at risk. Why? The packet-level parts of IPsec are much less complex (and, partially as a result, have received more scrutiny, as far as I can tell). >At this point, to restore confidence in the security of the design I >would hope that the IETF will retain the services of a quality >cryptanalysis consulting firm and publish the results. To do otherwise >will be to risk the discrediting of the entire IPsec standard. I think this is probably unnecessary. The main thing that deters analysis from the academics (from the anecdotes I've heard) is the complexity of IKE. If this improves, my guess is that you're likely to receive better cryptanalysis from the community as a whole than you'd get from a consulting firm. From owner-ipsec@lists.tislabs.com Sat Aug 4 23:45:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f756jJs12334; Sat, 4 Aug 2001 23:45:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06156 Sun, 5 Aug 2001 01:43:07 -0400 (EDT) To: Barbara Fraser , "Theodore Ts'o" Cc: ipsec@lists.tislabs.com Subject: ipsec mailing list archive X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Sun, 05 Aug 2001 14:49:36 +0900 Message-Id: <20010805054937.EDB8E7BB@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk there are two email archives listed on ipsec wg webpage: http://www.ietf.org/html.charters/ipsec-charter.html unfortunately, both of those do not work. could you please find another one and list it onto the webpage? ftp://ftp.tis.com/pub/lists/ipsec - no ftp.tis.com any more? ftp.ans.net/pub/archive/ipsec - the archive is ancient with google, i found a couple of these. i dunno which is better than the others. http://www.vpnc.org/ietf-ipsec/ http://www.sandelman.ottawa.on.ca/ipsec/ http://www.cs.arizona.edu/xkernel/www/ipsec/ itojun From owner-ipsec@lists.tislabs.com Sun Aug 5 05:40:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f75Ce7s06237; Sun, 5 Aug 2001 05:40:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06311 Sun, 5 Aug 2001 07:43:30 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.12991.222510.889533@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 04:49:19 -0700 (PDT) To: Dan Harkins Cc: Henry Spencer , IP Security List , ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org Subject: Re: Position statement on IKE development In-Reply-To: <200108032235.f73MZDd01426@dharkins@lounge.orgatty.lounge.org> References: <200108032235.f73MZDd01426@dharkins@lounge.orgatty.lounge.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > I discussed this in Minneapolis. The plan is to combine ISAKMP, IKE, > and the IPsec DOI into a single draft describing a key management > protocol for IPsec. > > The intent, as well-meaning as it was, was to have a generic language > (ISAKMP) in which to describe a key management protocol and there could > be many key management protocols with IKE as just one of them. IKE, then, > was supposed to be a generic key exchange protocol which could create > "SAs" for multiple services, of which IPsec (specified in the DOI) was > just one. But IKE is the only thing that used ISAKMP and the other two > DOI documents-- OSPF and RIP-- died a quiet death. Not entirely correct. KINK is using ISAKMP payloads (sa, id, nonce, ke, notify, delete, ie quick mode). IMO, the logical split here is between authentication and IPsec SA establishment. The former is *always* a far harder problem than the latter. Mike From owner-ipsec@lists.tislabs.com Sun Aug 5 05:40:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f75Ce8s06249; Sun, 5 Aug 2001 05:40:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06295 Sun, 5 Aug 2001 07:34:07 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15213.12426.278709.314071@thomasm-u1.cisco.com> Date: Sun, 5 Aug 2001 04:39:54 -0700 (PDT) To: Henry Spencer Cc: IP Security List , ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org Subject: Re: Position statement on IKE development In-Reply-To: References: <200108031857.f73IviJ20038@thunk.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Speaking as an implementor of KINK, it would be nice if there were a split of anything to make a clean split between main mode and quick mode. As far as I can tell, quick mode is far less broken and far more reusable by any number of key distribution protocols than main mode. Mike Henry Spencer writes: > On Fri, 3 Aug 2001, Bill Sommerfeld wrote: > > > Therefore, I would suggest that any effort in replacing IKE also consider > > > replacing/rewriting portions of IPSEC DOI ... > > > > Last I heard, the son-of-ike plan was to merge the DOI into the key > > mgmt document. > > Realistically, there's no meaningful distinction between IKE and the DOI. > In fact, the separation between the two documents is a real nuisance when > one is looking for obscure details. They need to be considered as a unit. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Sun Aug 5 12:54:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f75JsVs16330; Sun, 5 Aug 2001 12:54:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06666 Sun, 5 Aug 2001 14:54:35 -0400 (EDT) Message-Id: <3.0.3.32.20010805120024.01051bf0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 05 Aug 2001 12:00:24 -0700 To: "Steven M. Bellovin" From: Alex Alten Subject: Re: Position statement on IKE development Cc: Henry Spencer , Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <20010804230025.A59117B5B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:00 AM 8/5/2001 +0100, Steven M. Bellovin wrote: >In message <3.0.3.32.20010804144227.00ebdb30@mail>, Alex Alten writes: > > >>> >>>Agreed. And large parts of the Schneier/Ferguson analysis of the >>>packet-level parts are just plain wrong. >>> >> >> >>Steve, with all due respect, you, Jeff and Marcus stated the following. >> >>"In the several years since the standardization of the IPSEC protocols >>(ESP, AH, and ISAKMP/IKE), there have come to light several security >>problems with the protocols, most notably the key-agreement protocol, >>IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and >>Simpson, have shown that the security problems in IKE stem directly >>from its complexity." >> >>If IKE is no longer considered viable because of it's complexity, then >>I am concerned that the other protocols of IPsec are also at risk. This >>is not my concern alone, others have expressed it to me as well. >> >>At this point, to restore confidence in the security of the design I >>would hope that the IETF will retain the services of a quality >>cryptanalysis consulting firm and publish the results. To do otherwise >>will be to risk the discrediting of the entire IPsec standard. > >Frankly, a lot of very competent folks did look at the cryptography. >WIth all due modesty, I published two papers on the subject myself, and >I wasn't the only one. In fact, that's one of the reasons why IPsec >took so long -- the result of those analyses is why RFCs 1825-29 were >replaced by 2401 et al. -- because we found and fixed a fair number of >problems. The flaws in the Schneier/Ferguson analysis are >because they don't understand the networking context. I sent Bruce a >long, detailed note about that before he ever published the analysis. > >You say "retain the services of a quality cryptanalysis consulting firm". >Apart from the point that there aren't that many -- and I and others >know most of the likely players in the field -- the question is whether >or not they understand the networking context. I have no particular >reason to think that the results would be any better than what we have >now. > >Is IPsec perfect? No, of course not. I'd like to get rid of AH, for >example, not because it doesn't work -- it does -- but because it adds >complexity to implementations without (to me) doing anything useful. >There are a few other minor things I'd have done differently. But I >have a great deal of confidence in the correctness of the packet-level >transforms. > Dr. Steven Bellovin, I have the greatest respect for your design and analysis capabilities in both networking and cryptography. However at this point in time, besides the Ferguson & Schneier analysis, and in a sense older papers by yourself, Dr. Rogaway and possibly others, I have yet to come across a comprehensive, thorough analysis of the 2401 set of RFCs. I don't think that this is something that can be done properly through academia, at least not as a free, unfocused effort. It really requires a focused effort, with clear, practical analysis objectives laid out. That is why I suggest using a good consulting firm, preferably one that does similar type of work on a regular basis. I appreciate your personal assurances that it is a sound design. However I think it is critical that an unbiased, reputable third party report on the core suite of protocols. I understand your concern that they might not understand the underlying network context. But I would expect that you and others would be appropriate guides for the analysis. As you should well know, unbiased peer review is critical in the design of any security system. We, as designers, tend to be blind to our own mistakes. It is a rather humbling profession for any security system designer. Therefore I ask the IAB/IETF to strongly consider sponsering a thorough analysis of the 2401 set of RFC's. As a member of the Internet Society I feel it is our responsibility and duty to the Internet community to ensure, as best as we can, the integrity and soundness of the design. At the same time, I would hope that the IAB/IETF will come up with a criteria for selecting the replacement for IKE, rather than trying to do it all in-house again. While understanding the misgivings others have expressed, I still feel that a competition along the same lines that NIST used for AES selection, would be the best approach. The internal workings of a block cipher are probably just as complex as the external workings of a key management protocol. Arguements against a NIST-like selection approach using complexity as a reason seem to be fallacious to me. Sincerely, Alex Alten -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Sun Aug 5 13:03:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f75K3ms16455; Sun, 5 Aug 2001 13:03:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06697 Sun, 5 Aug 2001 15:22:51 -0400 (EDT) X-Sender: mundy@217.33.140.133 (Unverified) Message-Id: In-Reply-To: <20010805054937.EDB8E7BB@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 5 Aug 2001 20:29:16 +0100 To: Jun-ichiro itojun Hagino From: Russ Mundy Subject: Re: ipsec mailing list archive Cc: Barbara Fraser , "Theodore Ts'o" , ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We had a domain name change/transition a couple of years ago from tis.com to tislabs.com. It was announced on all the ietf lists we support at the time but I never check the full set of working group web sites to see if they all picked up the name change. I just checked the old zone name and, I agree, that it doesn't work (at least from the London IETF site). The current name for the site with ALL of the archives is: ftp://ftp.tislabs.com/pub/lists/ipsec I'll see if I can find out whether or not the 'old' name should still be functioning. Russ NAI Labs (aka, owner/operator of tislabs.com) At 2:49 PM +0900 8/5/01, Jun-ichiro itojun Hagino wrote: > there are two email archives listed on ipsec wg webpage: > http://www.ietf.org/html.charters/ipsec-charter.html > > unfortunately, both of those do not work. could you please find > another one and list it onto the webpage? > ftp://ftp.tis.com/pub/lists/ipsec - no ftp.tis.com any more? > ftp.ans.net/pub/archive/ipsec - the archive is ancient > > with google, i found a couple of these. i dunno which is better than > the others. > http://www.vpnc.org/ietf-ipsec/ > http://www.sandelman.ottawa.on.ca/ipsec/ > http://www.cs.arizona.edu/xkernel/www/ipsec/ > >itojun From owner-ipsec@lists.tislabs.com Sun Aug 5 20:25:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f763Pjs21155; Sun, 5 Aug 2001 20:25:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06924 Sun, 5 Aug 2001 22:06:06 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Alex Alten'" , "'Marcus Leech'" , Subject: RE: Position statement on IKE development Date: Sun, 5 Aug 2001 21:59:56 -0400 Message-Id: <000001c11e1c$313810c0$0b9321d9@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3.0.3.32.20010802234951.00e4eb00@mail> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Okay, the first thing to do is **DON'T PANIC**. The opinion in this document is not new. In fact, this moratorium on IKE development has been in place for more than a year already, as I specifically remember Ted talking about it at the Adelaide meeting. The fact that the opinion of the ADs has suddenly been put in writing and posted to the mailing list is no reason to get excited. What does concern me is the effect that this moratorium has had on the WG. Instead of encouraging work on simplifying IKE, it has merely stifled the ongoing work on features that we simply must have. NAT traversal is clearly not an optional feature. Development of a NAT traversal protocol will continue with or without the IESG's blessing, as will user authentication and dead peer detection. If all development must stop until IKE is simplified, then how are we to add these essential new features? Must there be an IKEv3 a year from now to add all the features that have already been developed? I would also like to ask why, if the enclosed opinion is in fact shared by all 3 authors, then how is it that one of them recently co-authored a draft for adding SCTP support to IKE? --- In technical circles, just as in politics, the pendulum swings one way and then it swings back again. No matter which way it is travelling, it inevitably swings too far. In our zeal to criticize IKE/Isakmp for its generic approach, we have assumed there is some kind of magic pixie dust that we can sprinkle on IKE to make it simpler. Rewriting the documents may make IKE easier to understand, but it won't change the bits on the wire or the underlying protocol. Designing related protocols to not share any code may reduce the complexity of either protocol taken alone, but it will probably increase the complexity of the system as a whole. I agree with Mike that the separation of Main Mode from Quick Mode was a good design decision for IKE. I also feel that the separation of ISAKMP from IKE was a good decision. I would much rather see a rewritten IKE document and a separate, simplified ISAKMP document (which only defines the payload formats and such) than a new, fully merged IKE spec. Counterintuitively, "simplicity" is a difficult concept to apply and understand. A shorter RFC does not necessarily make a simpler protocol. Simplicity can come from adding things as well as removing them. In particular, adding restrictions can greatly simplify a protocol. I am worried that if we try to make Son of IKE too terse then the lack of restrictions will make the protocol vague. It has been my observation that the single biggest problem area for IKEv1 has been rekeying. The IKE RFC remains curiously silent on this topic, except to state the SAs are "uncorrelated". The lack of sufficient rules for how to use the Certificate Request payload has also been a source of trouble. --- If you want to consider some real, bits-on-the-wire type simplifications to IKE then take a look at our draft-improveike document. Also look at the revised hash document and the IKE anti-replay document. These last two are ideas for simplifying IKE by taking security properties which were formerly solved individually for each mode, and defining a solution which solves the problem for all modes, a simplification. Not all of the things we suggest are simplifications; some of them are merely suggestions to improve the protocol. But then again, not all of the papers that Marcus cites are really commenting on complexity of IKE. The paper by Simpson doesn't talk about the complexity of IKE at all. In fact, all it says is that IKE is succeptible to a certain kind of DoS attack. The paper by Ferguson/Schneier certainly talks about complexity, but I think that many people are too star-struck by who the co-author is to consider that he obviously isn't very familiar with the intimate details of IKE. In fact, some of his comments are rather schitzophrenic, in the sense that he interlaces suggestions for simplifying Main Mode with suggestions for reducing the length of the exchange, a short-sighted idea which would almost certainly introduce some new DoS attacks. If we are going to redesign IKE then let us do so, but it would help if the charter was defined so that people actually had an incentive to implement the new, simplified IKE. Many of the proposed suggestions have been wild, unsupported assertions such as: (A) let's have a contest and redesign everything from scratch (clearly not from an implementer), (B) related protocols X and Y shouldn't share code (great as long as you don't have to implement both X and Y), (C) Merging all the documents together will somehow automagically fix IKE (only if we agree on conventions for things like rekeying). I also wonder why IKE gets all the blame when the PKI-related protocols we use with IKE are easily as complex, if not more complex. My apologies for not replying earlier, but I have been on vacation until today. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten > Sent: Friday, August 03, 2001 2:50 AM > To: Marcus Leech; msec@securemulticast.org; ietf-ipsra@vpnc.org; > ipsec-policy@vpnc.org; ipsec@lists.tislabs.com > Subject: Re: Position statement on IKE development > > > > After just reading the papers by Meadows, Schneier/Ferguson and > Simpson, I now have serious doubts that IPsec delivers the security > required by the Internet community. > > This is a very serious issue. > > To make a mistake of this caliber when so many firms have committed > large amounts of resources for software, board, ASIC and chip designs, > implementations and manufactures is a terrible thing. > > I agree with Schneier & Ferguson. A security protocol/system cannot be > designed by a large committee, unlike many other successful insecure > protocols. Their suggestion to use a process like NIST's for selecting > the AES standard is an excellent one. It's a pity they did not suggest > it a decade ago. However it should be considered seriously not only > for the replacement of IKE, but possibly also for the modification or > simplification of the entire IPsec protocol suite. (I hesitate to say > the replacement of IPSEC given the tremendous repercussions of doing > so.) > > - Alex > > > At 10:04 PM 8/2/2001 -0700, Alex Alten wrote: > > > >Dear Marcus, Jeff and Steve, > > > >May I make a suggestion given the seriousness of this? > > > >Let's hold an international design competition to select a key > >management protocol for IPSec in a manner similar to how NIST did > >the AES selection (although I hope it takes less than 5 years). > >Once we get to a final 5, then let's cryptanalyze them and select > >the best one. In this manner hopefully we can avoid a 2nd debacle. > > > >Sincerely, > > > >- Alex Alten > > > > > >At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote: > >>I'm sending the attached ASCII TEXT document on behalf of > myself, Jeff > >>Schiller, and > >> Steve Bellovin, to clarify our position with respect to IKE > >>development. It is our hope > >> that it will clarify, to some extent, some fuzziness in > this area that > >>has evolved over > >> the last year or so.In the several years since the > standardization of > >the IPSEC protocols > >>(ESP, AH, and ISAKMP/IKE), there have come to light several security > >>problems with the protocols, most notably the key-agreement > protocol, > >>IKE. Formal and semi-formal analyses by Meadows, Schneier > et al, and > >>Simpson, have shown that the security problems in IKE stem directly > >>from its complexity. It seems only a matter of time before more > >>analyses show more serious security issues in the protocol > design that > >>stem directly from its complexity. It seems also, only a matter of > >>time, before serious *implementation* problems become > apparent, again > >>due to the complex nature of the protocol, and the complex > >>implementation that must surely follow. > > > >... > > > >> > >> > >>Marcus Leech (IESG) > >>Jeff Schiller (IESG) > >>Steve Bellovin (IAB) > >> > >-- > > > >Alex Alten > > > >Alten@Home.Com > > > > > > > -- > > Alex Alten > > Alten@Home.Com > > > From owner-ipsec@lists.tislabs.com Mon Aug 6 01:08:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7688qs14525; Mon, 6 Aug 2001 01:08:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA07419 Mon, 6 Aug 2001 02:46:04 -0400 (EDT) To: akshay.singh@analog.com Cc: snap-users@kame.net, ipsec@lists.tislabs.com Subject: Re: (KAME-snap 5215) ESP Encryption Key In-Reply-To: Your message of "Sat, 4 Aug 2001 15:55:32 -0700" <001901c11d38$92593b20$c78b4789@pctest1> References: <001901c11d38$92593b20$c78b4789@pctest1> X-Mailer: Cue version 0.6 (010413-1707/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010806155248Q.sakane@kame.net> Date: Mon, 06 Aug 2001 15:52:48 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 17 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I have a question related to esp encryption key , > I am using 3des so I set my keys as > case 1: > { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, > 0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02, > 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03} > Here problem is this If I use the keys as > case 2: > { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, > 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, > 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01} > the encrypted results are same in case 1 and case 2. Can any one tell why it is > same even I am using different keys ? i'm not sure what the platform you are using. at least, these key cannot be installed into the kernel based kame stack. kame stack says "esp_cbc_mature 3des-cbc: weak key was passed", From owner-ipsec@lists.tislabs.com Mon Aug 6 01:22:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f768M5s15225; Mon, 6 Aug 2001 01:22:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA07523 Mon, 6 Aug 2001 03:20:34 -0400 (EDT) Message-Id: <200108060726.f767Qas00663@dharkins@lounge.orgatty.lounge.org> To: Michael Thomas Cc: IP Security List , ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org Subject: Re: Position statement on IKE development In-Reply-To: Your message of "Sun, 05 Aug 2001 04:49:19 PDT." <15213.12991.222510.889533@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <660.997082796.1@lounge.org> Date: Mon, 06 Aug 2001 00:26:36 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I stand corrected... well sort of. KINK doesn't really re-use quick mode since certain things were dropped like PFS and the whole commit bit stuff. So it's really quick-mode-lite. And it doesn't use UDP port 500 so it's not really ISAKMP after all. And I don't even think it uses the ISAKMP header. It also defines as many (if not more) new payloads as it uses from ISAKMP. So all in all, KINK is not really doing quick mode nor is it using ISAKMP. Why don't you just define your protocol in full? I don't believe you'll be sued for cutting-and-pasting payloads from RFC2408. Dan. On Sun, 05 Aug 2001 04:49:19 PDT you wrote > Dan Harkins writes: > > I discussed this in Minneapolis. The plan is to combine ISAKMP, IKE, > > and the IPsec DOI into a single draft describing a key management > > protocol for IPsec. > > > > The intent, as well-meaning as it was, was to have a generic language > > (ISAKMP) in which to describe a key management protocol and there could > > be many key management protocols with IKE as just one of them. IKE, then, > > was supposed to be a generic key exchange protocol which could create > > "SAs" for multiple services, of which IPsec (specified in the DOI) was > > just one. But IKE is the only thing that used ISAKMP and the other two > > DOI documents-- OSPF and RIP-- died a quiet death. > > Not entirely correct. KINK is using ISAKMP payloads > (sa, id, nonce, ke, notify, delete, ie quick mode). > IMO, the logical split here is between authentication > and IPsec SA establishment. The former is *always* > a far harder problem than the latter. > > Mike > From owner-ipsec@lists.tislabs.com Mon Aug 6 02:44:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f769ipN21969; Mon, 6 Aug 2001 02:44:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA07581 Mon, 6 Aug 2001 04:35:05 -0400 (EDT) Date: Mon, 6 Aug 2001 04:41:27 -0400 From: Theodore Tso To: Andrew Krywaniuk Cc: "'Alex Alten'" , "'Marcus Leech'" , ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development Message-ID: <20010806044127.B577@thunk.org> References: <3.0.3.32.20010802234951.00e4eb00@mail> <000001c11e1c$313810c0$0b9321d9@andrewk3.ca.newbridge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <000001c11e1c$313810c0$0b9321d9@andrewk3.ca.newbridge.com>; from andrew.krywaniuk@alcatel.com on Sun, Aug 05, 2001 at 09:59:56PM -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, Aug 05, 2001 at 09:59:56PM -0400, Andrew Krywaniuk wrote: > Okay, the first thing to do is **DON'T PANIC**. > > The opinion in this document is not new. In fact, this moratorium on IKE > development has been in place for more than a year already, as I > specifically remember Ted talking about it at the Adelaide meeting. The fact > that the opinion of the ADs has suddenly been put in writing and posted to > the mailing list is no reason to get excited. Indeed. Nothing really has changed here. My understanding is that the note from the IESG/IAB this is more of a reminder more than anything else. It was explaining the reasons for the moratorium, Specifically, we do have permission to go ahead with making interim modifications to IKE, which need badly fixing in the short term: specifically in the NAT/Firewall traversal and support for SCTP. But all other changes are to be shunted to "son of IKE", and even there the focus is on making the protocol work, and be simpler and easier to understand/analyze, and not add the kitchen sink in terms of feature. As far as user authentication and dead peer detection, part of the problem with those items is that there has *not* been consensus, and in fact there's been a fair amount of controversy, about what's the best way to handle these items. People have sketched out solutions for user authentication that don't require changes to IKE, and that work is properly scoped to the IPSRA working group (and not "son of ike"). Dead peer recovery probably will be within in the scope of "son of ike", but here again there has been controversy about how is the best way of solving the problem. One advantage about "son of ike" allowing protocol changes (but likely requiring that the changes be "implementation preserving"), is that there may be more latitude to solve this particular proble right, instead of kludging around things. I will note that there have been many different proposed solutions to solving this particular problem, including polling/heartbeat mechanisms, authenticated birth/death certificates, etc. - Ted From owner-ipsec@lists.tislabs.com Mon Aug 6 02:46:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f769kmN22019; Mon, 6 Aug 2001 02:46:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA07612 Mon, 6 Aug 2001 04:50:07 -0400 (EDT) Date: Mon, 6 Aug 2001 06:01:07 -0400 From: Richard Guy Briggs To: Shoichi Sakane Cc: akshay.singh@analog.com, snap-users@kame.net, ipsec@lists.tislabs.com Subject: Re: (KAME-snap 5215) ESP Encryption Key Message-ID: <20010806060107.A30359@grendel.conscoop.ottawa.on.ca> References: <001901c11d38$92593b20$c78b4789@pctest1> <20010806155248Q.sakane@kame.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010806155248Q.sakane@kame.net>; from sakane@kame.net on Mon, Aug 06, 2001 at 03:52:48PM +0900 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Aug 06, 2001 at 03:52:48PM +0900, Shoichi Sakane wrote: > > I have a question related to esp encryption key , > > I am using 3des so I set my keys as > > case 1: > > { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, > > 0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02, > > 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03} > > Here problem is this If I use the keys as > > case 2: > > { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, > > 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, > > 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01} > > the encrypted results are same in case 1 and case 2. Can any one tell why it is > > same even I am using different keys ? I found a bug and provided a fix, in OpenBSD, at least two years ago, which looked exactly like this. The problem was in the userspace manual keying utility. I assume it was fixed long ago. > i'm not sure what the platform you are using. > at least, these key cannot be installed into the kernel based kame stack. > kame stack says "esp_cbc_mature 3des-cbc: weak key was passed", slainte mhath, RGB ...just back from the American Solar Challenge , a cross-continental solar vehicle competition on historic Route 66. Now in Europe for 3 weeks..., presently at IETF. -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: From owner-ipsec@lists.tislabs.com Mon Aug 6 04:45:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76BjtN00153; Mon, 6 Aug 2001 04:45:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07817 Mon, 6 Aug 2001 06:47:58 -0400 (EDT) Message-ID: <003001c11e66$ba4b9ea0$ae0510ac@roc.com> Reply-To: "lokesh" From: "lokesh" To: Subject: Information needed on AND and OR SB's Date: Mon, 6 Aug 2001 16:28:21 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C11E94.CED76420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C11E94.CED76420 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I need Information on "AND SB" (AND Security Bundle) and "OR SB" (OR Security Bundles). which are used in multiple levels of security Bundle Applications. Can = any one tell me where I can get Documents on these subjects? Thanks In Advance, Lokesh. ------=_NextPart_000_002D_01C11E94.CED76420 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all,
I need Information on "AND SB" (AND = Security=20 Bundle)
and "OR SB" (OR Security = Bundles).
which are used in multiple levels of = security=20 Bundle Applications. Can any one tell me where I can get Documents on = these=20 subjects?
Thanks In Advance,
Lokesh.
------=_NextPart_000_002D_01C11E94.CED76420-- From owner-ipsec@lists.tislabs.com Mon Aug 6 05:17:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76CHkN00577; Mon, 6 Aug 2001 05:17:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07876 Mon, 6 Aug 2001 07:29:06 -0400 (EDT) Reply-To: From: "Judah Hauser" To: Date: Sat, 4 Aug 2001 01:02:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Sir, I have a linksys BEFSR81 Router all hooked up but have a mjor issue im hoping you can help me with. I dial into my adsl provider using VPN+PPTP. I am able to connect with no problems, but only on the main computer thats dialing. I can actually dial on any of the computers, but only on at a time. I heard this is a known bug because of some ipsec issue. are you familiar with this problem? Basically what I need to know is if their is some fix for this or do I need to buy a different brand? Do you expect support for - Unlimited PPTP & IPsec client passthru sessions? Thanks, Judah Hauser HS Worldwide Enterprises Inc Email: jh@hsworldwide.com jhauser@tlite.co.il WWW.HSWORLDWIDE.COM From owner-ipsec@lists.tislabs.com Mon Aug 6 05:27:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76CR1N00761; Mon, 6 Aug 2001 05:27:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07891 Mon, 6 Aug 2001 07:41:38 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: isakmp cookies field X-Mailer: Cue version 0.6 (010413-1707/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010806204824B.sakane@kame.net> Date: Mon, 06 Aug 2001 20:48:24 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk could anybody tell me what the benefit of the isakmp cookie field is ? i think the cookie indicates just isakmp spi. does it have any function to prevent from dos attack ? From owner-ipsec@lists.tislabs.com Mon Aug 6 05:51:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76CpJN01382; Mon, 6 Aug 2001 05:51:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07836 Mon, 6 Aug 2001 07:01:17 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15214.31358.903185.187715@thomasm-u1.cisco.com> Date: Mon, 6 Aug 2001 04:07:42 -0700 (PDT) To: Dan Harkins Cc: Michael Thomas , IP Security List , ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org Subject: Re: Position statement on IKE development In-Reply-To: <200108060726.f767Qas00663@dharkins@lounge.orgatty.lounge.org> References: <15213.12991.222510.889533@thomasm-u1.cisco.com> <200108060726.f767Qas00663@dharkins@lounge.orgatty.lounge.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins writes: > I stand corrected... well sort of. > > KINK doesn't really re-use quick mode since certain things were > dropped like PFS and the whole commit bit stuff. So it's really > quick-mode-lite. And it doesn't use UDP port 500 so it's not really > ISAKMP after all. And I don't even think it uses the ISAKMP header. > It also defines as many (if not more) new payloads as it uses > from ISAKMP. > > So all in all, KINK is not really doing quick mode nor is it > using ISAKMP. Actually, PFS was added back in. I guess it depends on what is meant by "using" and "really". It's I'd say about 90% code preserving which was really the main desire. > Why don't you just define your protocol in full? I don't believe you'll > be sued for cutting-and-pasting payloads from RFC2408. It was a possibility, but the consensus was to just reference quick mode in 2409. I think it will be interesting to see if the profile we did is sufficiently clear. If not, cut and paste may be the reasonable course of action. Mike From owner-ipsec@lists.tislabs.com Mon Aug 6 06:17:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76DH9N01982; Mon, 6 Aug 2001 06:17:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07927 Mon, 6 Aug 2001 08:08:08 -0400 (EDT) Message-Id: <200108050240.f752eaw06850@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development In-reply-to: Your message of "04 Aug 2001 22:52:02 GMT." <9khuai$1hi$1@abraham.cs.berkeley.edu> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 04 Aug 2001 22:40:35 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "David" == David Wagner writes: David> I think this is probably unnecessary. The main thing that deters David> analysis from the academics (from the anecdotes I've heard) is the David> complexity of IKE. If this improves, my guess is that you're David> likely to receive better cryptanalysis from the community as a David> whole than you'd get from a consulting firm. Is IKE really that complex? Or rather, could be be much simpler and still get the job done? This is really a different question from: is IKE poorly documented? I think that we all agree that the document could be a lot better. I still think that this is really the first step. Clean up the document(s), and doing nothing to the specification, and then decide what to chop. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Aug 6 06:31:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76DVcN02232; Mon, 6 Aug 2001 06:31:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08113 Mon, 6 Aug 2001 08:43:10 -0400 (EDT) To: Shoichi Sakane Cc: ipsec@lists.tislabs.com Subject: Re: isakmp cookies field References: <20010806204824B.sakane@kame.net> From: Derek Atkins Date: 06 Aug 2001 08:50:05 -0400 In-Reply-To: Shoichi Sakane's message of "Mon, 06 Aug 2001 20:48:24 +0900" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It provides ISAKMP session identification and peer reachability. -derek Shoichi Sakane writes: > could anybody tell me what the benefit of the isakmp cookie field is ? > i think the cookie indicates just isakmp spi. does it have any function > to prevent from dos attack ? -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Aug 6 07:08:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76E8gN03729; Mon, 6 Aug 2001 07:08:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07918 Mon, 6 Aug 2001 08:07:08 -0400 (EDT) Message-ID: <001901c11d38$92593b20$c78b4789@pctest1> Reply-To: "akshay" From: "akshay" To: , Subject: ESP Encryption Key Date: Sat, 4 Aug 2001 15:55:32 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C11CFD.E4209A10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C11CFD.E4209A10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , I have a question related to esp encryption key , I am using 3des so I set my keys as=20 case 1: { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, 0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02, 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03} Here problem is this If I use the keys as=20 case 2: { 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01} the encrypted results are same in case 1 and case 2. Can any one tell = why it is same even I am using different keys ? Further when I call des_key_sched function with first key i.e = {0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01} the value of my des_key_schedule variable is all 0 , why so ? cannt I = select key like this . Cheers!! akshay =20 ------=_NextPart_000_0016_01C11CFD.E4209A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , I have a question related to esp = encryption key=20 , I am using 3des so I set my keys as = case 1: {=20 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, =20 0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02, =20 0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x03} Here problem is this If I use the keys = as=20 case 2: {=20 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01, 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01} the encrypted results are same in case 1 and case 2. Can any one = tell why=20 it is same even I am using different keys ? Further when I call des_key_sched function with first key i.e=20 {0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01} the value of my des_key_schedule variable is all 0 , why so ? = cannt I=20 select key like this . Cheers!! akshay ------=_NextPart_000_0016_01C11CFD.E4209A10-- From owner-ipsec@lists.tislabs.com Mon Aug 6 07:57:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76EvGN06935; Mon, 6 Aug 2001 07:57:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08262 Mon, 6 Aug 2001 09:54:38 -0400 (EDT) Message-ID: <005001c11e80$c6984680$ae0510ac@roc.com> Reply-To: "lokesh" From: "lokesh" To: "Shoichi Sakane" Cc: References: <20010806204824B.sakane@kame.net> Subject: Re: isakmp cookies field Date: Mon, 6 Aug 2001 19:34:51 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > could anybody tell me what the benefit of the isakmp cookie field is ? > i think the cookie indicates just isakmp spi. does it have any function > to prevent from dos attack ? using cookies is the feature of Oakley algorithm(used by ISAKMP) these cookies are used to thwart clogging attacks. in this attack, the opponent forges the src address of a legitimate user and sends a public DH key to victim, the victim then performs the modular exponentiation to compute secret key, Repeated messages of this type can clog the victims system with useless work, thus exhausting cpu resource to perform modular exponentiation. The technique of cookie exchange requires that each side send a pseudo-random number , the cookie , in the initial message, which other side acknowledges This acknowledgement must be repeated in the first message of DH key exchange. If src address is forged , the opponent gets no answer, thus an opponent can only force user to generate acknowledgements and not to perform the DH modular exponentiation. ISAKMP mandates that cookie generation must satisfy three basic requirements. 1. The cookie must depend on specific parties. 2. It must not be possible for anyone otherthan issueing entity to generate cookies that will be accepted by that entity, that is, cookie generation should be based on some local secret. 3. cookie generation and verification methods must be fast to thwart attacks intended to sabotage the processor resources.. From owner-ipsec@lists.tislabs.com Mon Aug 6 08:01:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76F1wN07061; Mon, 6 Aug 2001 08:01:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08279 Mon, 6 Aug 2001 10:03:18 -0400 (EDT) Message-ID: <8B204D152222D51182B70001028841372024CC@postmaster.cryptek.com> From: "Aronson, David" To: "'Shoichi Sakane'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: isakmp cookies field Date: Mon, 6 Aug 2001 10:34:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > could anybody tell me what the benefit of the isakmp cookie > field is ? > i think the cookie indicates just isakmp spi. does it have > any function > to prevent from dos attack ? Yes, exactly. See RFC 2048 (ISAKMP), section 2.5.3 (Anti-Clogging Token ("Cookie") Creation), on pages 20-21. -- Dave Aronson, Sysop of free public Fidonet BBS Air 'n Sun, +1-703-319-0714. Opinions all MINE, not by Cryptek/NRA/SCA/Mensa/HWG/LPUSA/CAUCE/FedGov/God! See my web site, at http://listen.to/davearonson (last updated 2001-06-27). Device-driver proggers: see http://www.cryptek.com and send me your resume! From owner-ipsec@lists.tislabs.com Mon Aug 6 08:33:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76FX7N08222; Mon, 6 Aug 2001 08:33:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08357 Mon, 6 Aug 2001 10:42:11 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: RE: isakmp cookies field In-Reply-To: Your message of "Mon, 6 Aug 2001 10:34:44 -0400 " <8B204D152222D51182B70001028841372024CC@postmaster.cryptek.com> References: <8B204D152222D51182B70001028841372024CC@postmaster.cryptek.com> X-Mailer: Cue version 0.6 (010413-1707/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010806234819O.sakane@kame.net> Date: Mon, 06 Aug 2001 23:48:19 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 16 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > could anybody tell me what the benefit of the isakmp cookie > > field is ? > > i think the cookie indicates just isakmp spi. does it have > > any function > > to prevent from dos attack ? > Yes, exactly. See RFC 2048 (ISAKMP), section 2.5.3 (Anti-Clogging Token > ("Cookie") Creation), on pages 20-21. of course, i've read this document. but i think this cookie creation couldn't prevent from dos or mitm attack. if nodes which would start to communicate knew the local secret information, yes, the cookie function could prevent from the attack. but the local secret information is known by the entity that creates a cookie. Or does nodes have to share any local secret information before the isakmp negotiation is started. From owner-ipsec@lists.tislabs.com Mon Aug 6 08:45:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76FjPN10253; Mon, 6 Aug 2001 08:45:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08435 Mon, 6 Aug 2001 11:06:06 -0400 (EDT) Date: Mon, 6 Aug 2001 18:07:31 +0300 (EET DST) From: Markus Stenberg X-X-Sender: To: Subject: NAT-T drafts in 51st IETF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the WG chairs' request, I'm posting this note also here: The NAT-T drafts are, as far as the authors are concerned, mostly done. Nobody in the WG disagreed. But the part that really needs noting is this: - the AH portion won't work quite (as described in the UDP encapsulation draft) - the WG was polled about whether or not we really need AH support - ~two dozen+ people had read the draft - NOBODY wanted to retain AH support (and by my informal polls, nobody was going to bother to implement support anyway because it was defined as 'MAY' be supported) - therefore, unless there is some urgent argument for retaining of the AH support in the drafts, the AH support'll disappear and the drafts may enter last call if no arguments against it are raised here. -Markus From owner-ipsec@lists.tislabs.com Mon Aug 6 08:58:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76FwnN12494; Mon, 6 Aug 2001 08:58:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08449 Mon, 6 Aug 2001 11:07:51 -0400 (EDT) To: Shoichi Sakane Cc: ipsec@lists.tislabs.com Subject: Re: isakmp cookies field References: <8B204D152222D51182B70001028841372024CC@postmaster.cryptek.com> <20010806234819O.sakane@kame.net> From: Derek Atkins Date: 06 Aug 2001 11:14:44 -0400 In-Reply-To: Shoichi Sakane's message of "Mon, 06 Aug 2001 23:48:19 +0900" Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Cookies provide you reachability, which implies that the initiator is actually interested in an IKE exchange, and is actually at the specified IP address (or at least somewhere along the route to that peer address). This prevents a DoS attack where the attacker sends out a forged IP Address, because the responder does no real work until message 3 (and the attacker wont receive message 2 which contains the server cookie). Cookies do not prevent an attacker from attempting DoS from their own IP Address.. However, then you at least have the IP address of the host causing problems, and you can just block it or rate-limit it. -derek Shoichi Sakane writes: > if nodes which would start to communicate knew the local secret information, > yes, the cookie function could prevent from the attack. but the local > secret information is known by the entity that creates a cookie. > Or does nodes have to share any local secret information before the > isakmp negotiation is started. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Aug 6 08:58:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76FwrN12517; Mon, 6 Aug 2001 08:58:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08410 Mon, 6 Aug 2001 11:01:04 -0400 (EDT) Message-Id: <200108061450.f76EofM05322@road.xisp.net> To: design@lists-freeswan.org cc: wes@hardakers.net, ipsec@lists.tislabs.com Subject: Wes Hardaker: opportunistic encryption deployment problems Date: Mon, 06 Aug 2001 15:50:41 +0100 From: Hugh Daniel Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I just spoke about the FreeS/WAN's teams Opportunistic Encryption design using IKE/IPsec at IETF and am already getting email on the subject. The conversation will now be split between our list and the IETF ipsec list (look at the headers below). Such is life. To answer Mr. Hardaker, we understand the problem with requiring the data be in the reverse DNS space and considering a forward space solution, but there are many folks who have no control over even their forward space. At some point one has to just give up and tell folks to get it together and control there own resources. On the subject of NAT: If your NAT on the net your NOT on the net. That's what I personally say at least. ||ugh Daniel hugh@freeswan.org Systems Testing & Project mis-Management The Linux FreeS/WAN Project http://www.freeswan.org -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: For the matching public key, finger the Reply-To: address. iQCVAwUBO26usVZpdJR7FBQRAQF6QgP7BhFHok49P/UZcsw61EEUEeITH74DArkM FyaNWCbCGtySAK2SRiV6k/8weXairJuLb5xTT62Siq/+JTWAlxGPmsa9AuKnAJvY 98nVKG066UcqyRu7/rS2fhP8lRpFHtY3a3TgkLevICPg4rl9vM2Hburs28DMx+rw 7gxta46ZRFI= =6D6I -----END PGP SIGNATURE----- ------- Forwarded Message Return-Path: wes@hardakers.net Delivery-Date: Mon Aug 6 07:33:39 2001 Return-Path: Received: from wanderer.hardakers.net (root@host217-33-137-141.ietf.ignite.net [217.33.137.141]) by ecotone.toad.com (8.8.7/8.8.7) with ESMTP id HAA04408 for ; Mon, 6 Aug 2001 07:33:38 -0700 Received: (from hardaker@localhost) by wanderer.hardakers.net (8.11.2/8.11.2) id f76EYs108296; Mon, 6 Aug 2001 07:34:54 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Hugh Daniel Cc: ipsec@lists.tislabs.com Subject: opportunistic encryption deployment problems From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: Mon, 06 Aug 2001 07:34:54 -0700 Message-ID: Lines: 24 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 3 problems I see with the deployment of opportunistic encryption: 1) your method of obtaining information is by reverse DNS lookup, which will provide problems with people who can't control their reverse DNS bindings. As an example, I don't have control over the subnet mapped to my house and can not insert information into the controlling DNS server (and can not convince them to redirect to me). 2) your method of obtaining information is by reverse DNS lookup, which will provide problems with people behind NATs. Until IPv6 is (if) widely deployed, this will continue to be a growing problem. Sure, if you can convince your NAT provider to do encryption to and from both sides of the NAT, you may be able to get around this but it certainly would take an effort to get this done. 3) The wider and wider spread use of things like web and other proxies will provide similar problems seen in #2. - -- Wes Hardaker NAI Labs Network Associates ------- End of Forwarded Message From owner-ipsec@lists.tislabs.com Mon Aug 6 09:16:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76GGkN13049; Mon, 6 Aug 2001 09:16:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08331 Mon, 6 Aug 2001 10:30:01 -0400 (EDT) X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Hugh Daniel Cc: ipsec@lists.tislabs.com Subject: opportunistic encryption deployment problems From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: Mon, 06 Aug 2001 07:34:54 -0700 Message-ID: Lines: 24 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 3 problems I see with the deployment of opportunistic encryption: 1) your method of obtaining information is by reverse DNS lookup, which will provide problems with people who can't control their reverse DNS bindings. As an example, I don't have control over the subnet mapped to my house and can not insert information into the controlling DNS server (and can not convince them to redirect to me). 2) your method of obtaining information is by reverse DNS lookup, which will provide problems with people behind NATs. Until IPv6 is (if) widely deployed, this will continue to be a growing problem. Sure, if you can convince your NAT provider to do encryption to and from both sides of the NAT, you may be able to get around this but it certainly would take an effort to get this done. 3) The wider and wider spread use of things like web and other proxies will provide similar problems seen in #2. -- Wes Hardaker NAI Labs Network Associates From owner-ipsec@lists.tislabs.com Mon Aug 6 09:16:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76GGrN13061; Mon, 6 Aug 2001 09:16:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08528 Mon, 6 Aug 2001 11:26:31 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA42@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Derek Atkins'" , "Hallam-Baker, Phillip" Cc: "'Marcus Leech'" , ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Position statement on IKE development Date: Mon, 6 Aug 2001 08:32:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11E8D.12D55F40" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11E8D.12D55F40 Content-Type: text/plain; charset="iso-8859-1" Derek, My point is not that PFS is bad, but that the imposition of a particular set of design priorities led to the very important properties of usability and deployability to be left out. The problem is as you say the means by which the keys are ultimately authenticated. It is not the cryptography. This is a complex task which is expensive to manage if the semantics of the trust network are complex and management takes place in devices at the periphery of the network. One solution is the SSL solution where the trust semantics are made very simple. Unfortunately people don't seem to like that solution, even though it is the only large scale open PKI that we have people using every day for real business. If people want to have a complex set of trust semantics than the only way to deploy the system is to provide a mechanism that allows the trust path processing to be delegated to a trust service - see XKMS [www.xmltrustcenter.org]. I would also like to be able to delegate the process of key agreement. This is because key agreement is an expensive operation that expensive database engines and routers have no business doing and because high end crypto hardware is expensive. That said there are a set of simplifications to IKE that could be achieved immediately: 1) Just decide what type of public key encryption you are going to use, encryption or signature. There is certainly an ongoing need for algorithm replacement, but allowing each party to chose from encryption/signature simply quadruples the work with zero added security. At this point we have two public key signature algorithms in general use and one encryption. So I would pick the signature, all things being equal. 2) Separate the credential download. In most cases Alice has Bob's certificate cached from a previous interaction. If Alice is trying to talk to Bob and does not have a credential then she should either (1) make a credential request of Bob or (2) receive the credential in an error message from Bob. 3) Get rid of the negotiation assumption generally. At this point we have 1 working digest function, 2 acceptable symmetric ciphers, 1 key agreement and 2 public key algorithms. Alice should start with the assumption that Bob is going to accept what she sends (after all she probably has the information cached). If that is a false assumption then Bob can send her an error message saying (I don't do X). 4) If you want to have the documents reviewed by the cryptography field generally PRESENT THEM TYPESET. This is the 3rd millenium, we don't use teletypes any more. Trying to read a crypto protocol with subscripts is bad enough. Reading K_X, K_AB_X etc is a turn off for anyone. I don't know of a single cryptographer who can't afford a bit mapped screen. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Friday, August 03, 2001 5:18 PM > To: Hallam-Baker, Phillip > Cc: 'Marcus Leech'; msec@securemulticast.org; ietf-ipsra@vpnc.org; > ipsec-policy@vpnc.org; ipsec@lists.tislabs.com > Subject: Re: Position statement on IKE development > > > I think certificate management (and distribution) within IKE is the > biggest problem of all. I want to talk to the host/printer/network > device at address 1.2.3.4. How do I get it's public key, and why do I > want to trust it? > > PFS is _EASY_ compared to that. An ephemeral DH exchange solves PFS. > But how do I authenticate? Better, how do I authenticate on a GLOBAL > scale? Now _THAT_ is the hard problem (IMHO). > > -derek > > "Hallam-Baker, Phillip" writes: > > > I have a different set of concerns, IPSEC is not being used > in cases where > > it should have been the answer. > > > > In particular the IEEE 802.11b WEP fiasco could have been > averted if the > > designers had not been discouraged by the complexity of IPSEC. > > > > Another issue is why can't I buy a printer that is IPSEC enabled? > > > > I believe that the biggest problem with IPSEC is that the > search for a > > certain view of perfect security has lead to a standard > that many have > > bypassed altogether as too demanding. > > > > Perfect Forward Secrecy is great, but I would rather have a > secure means of > > connecting to my printer than the possibility of a > perfectly secure means in > > ten years time. > > > > End to end security is a good thing, but in many > applications the overhead > > of negotiating trust relationships end to end is just too > high. How am I > > expected to configure the end to end security on an > embedded device with no > > console. Oh I use a web browser to connect to it, yes very > end to end. > > > > Phill > > > > > > > > Phillip Hallam-Baker FBCS C.Eng. > > Principal Scientist > > VeriSign Inc. > > pbaker@verisign.com > > 781 245 6996 x227 > > > > > > > -----Original Message----- > > > From: Marcus Leech [mailto:mleech@nortelnetworks.com] > > > Sent: Thursday, August 02, 2001 9:34 PM > > > To: msec@securemulticast.org; ietf-ipsra@vpnc.org; > > > ipsec-policy@vpnc.org; ipsec@lists.tislabs.com > > > Subject: Position statement on IKE development > > > > > > > > > I'm sending the attached ASCII TEXT document on behalf of > myself, Jeff > > > Schiller, and > > > Steve Bellovin, to clarify our position with respect to IKE > > > development. It is our hope > > > that it will clarify, to some extent, some fuzziness in > > > this area that > > > has evolved over > > > the last year or so. > > > > > > > > > ------_=_NextPart_000_01C11C5C.14D9EDC0 > > Content-Type: application/octet-stream; > > name="Phillip Hallam-Baker (E-mail).vcf" > > Content-Disposition: attachment; > > filename="Phillip Hallam-Baker (E-mail).vcf" > > > > BEGIN:VCARD > > VERSION:2.1 > > N:Hallam-Baker;Phillip > > FN:Phillip Hallam-Baker (E-mail) > > ORG:VeriSign > > TITLE:Principal Consultant > > TEL;WORK;VOICE:(781) 245-6996 x227 > > EMAIL;PREF;INTERNET:hallam@verisign.com > > REV:20010214T163732Z > > END:VCARD > > > > ------_=_NextPart_000_01C11C5C.14D9EDC0-- > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > <> ------_=_NextPart_000_01C11E8D.12D55F40 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C11E8D.12D55F40-- From owner-ipsec@lists.tislabs.com Mon Aug 6 09:29:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76GTQN13247; Mon, 6 Aug 2001 09:29:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08566 Mon, 6 Aug 2001 11:41:13 -0400 (EDT) Message-Id: <200108061520.f76FKRK11964@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: ipsec@lists.tislabs.com Subject: Phase 1 IDs ("son of IKE") Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Aug 2001 11:20:27 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted suggested I bring this up to the list: Currently, the Responder in a Phase 1 (Main Mode) exchange picks the identity to use based on the Initiator's IP address or Phase 1 ID, or uses some default value (like the address of the interface the Phase 1 exchange occurs). What I'd like to suggest is that the Initiator be allowed to send a Responder Phase 1 ID payload, which the Responder will use as a hint as to what ID to use itself; the Responder can ignore this hint, at the risk of the exchange not being completed. The extra code to support this is fairly small (in the order of 50 lines, in OpenBSD isakmpd). This change allows for per-user authentication on IKE, and makes much simpler Phase 1 negotiations where a) the Initiator and Responder roles change over time (because of unbalanced Phase 1 SA expirations), *and* b) the Phase 1 ID used by the Initiator is not the same as that used when it acts as a Responder. Anyway, I'll say the same thing tomorrow at the WG meeting --- just wanted to give some warning :-) -Angelos From owner-ipsec@lists.tislabs.com Mon Aug 6 11:21:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76ILRN15229; Mon, 6 Aug 2001 11:21:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08777 Mon, 6 Aug 2001 13:33:52 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA47@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Steven M. Bellovin'" , Alex Alten Cc: Henry Spencer , Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Position statement on IKE development Date: Mon, 6 Aug 2001 10:39:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11E9E.C9E18270" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11E9E.C9E18270 Content-Type: text/plain; charset="iso-8859-1" A couple of points: 1) You state that Bruce and co had failled to understand the network context. This is one of my concerns as people present IKE as a general purpose solution to all key agreement problems - including the key agreement for XML based Web services I have been working on. The argument keeps being thrown up 'use what exists and is tested', yet the protocol is of necessity tied to its context. It is not possible to pick up ISAKMP/IKE and apply it to another appliction, I have tried. Yet others are going to insist upon doing so. I believe that the current multilayered, 'everything is negotiable' negotiating mechanism is a liability even for its stated goal. It encourages people to try to use ISAKMP for purposes which it just does not support. 2) The current problems with NAT occur because IPSEC is being used in a network context it was never designed for. The IPSEC authentication mechanisms are designed to bind a key to an IP address. In the case of a user behind a NAT box that fails for obvious reasons. The question to be asked then is does this shift in the networking context affect the underlying security assumptions? The meta-question is, do we have a framework that allows questions such as these to be addressed? This is the problem that really bit the 802.11b team, their scheme is broken for two reasons, first the person who analysed the security appears to have assumed a block cipher would be used and not a stream cipher, second the design goals are fundamentally incomplete. The problem is not PRIVACY, but authenticating the user to stop the sacked employee in the car park surfing the ex-employer's intranet. Also any conception of privacy that includes Louis Freeh having to be able to read all my packets if he is granted access to the same network as me is somewhat strange to say the least... It may be a feature of ethernet, in a wireless network with an encryption layer it is a bug. 3) At this point we do not have a engineering approach to security protocol analysis. The nearest I have seen to an analytical approach is the work Phil Rogaway and Mihi Belhare have been doing on algorithms. Putting out a tender for security protocol analysis would be pointless if all we got as a result was a further set of experts reviewing the specs in the same ad hoc 'can we see holes' fashion. In the early days of bridge building the 'build it, see if it will fall down' algorithm was employed. Today most people (makers of wobbly bridges in London appart) believe in the 'use design principles that prevent failure' approach. Unfortunately we don't have the design principles (yet). Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Saturday, August 04, 2001 7:00 PM > To: Alex Alten > Cc: Henry Spencer; Marcus Leech; msec@securemulticast.org; > ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org; ipsec@lists.tislabs.com > Subject: Re: Position statement on IKE development > > > In message <3.0.3.32.20010804144227.00ebdb30@mail>, Alex Alten writes: > > > >> > >>Agreed. And large parts of the Schneier/Ferguson analysis of the > >>packet-level parts are just plain wrong. > >> > > > > > >Steve, with all due respect, you, Jeff and Marcus stated the > following. > > > >"In the several years since the standardization of the IPSEC > protocols > >(ESP, AH, and ISAKMP/IKE), there have come to light several security > >problems with the protocols, most notably the key-agreement protocol, > >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and > >Simpson, have shown that the security problems in IKE stem directly > >from its complexity." > > > >If IKE is no longer considered viable because of it's > complexity, then > >I am concerned that the other protocols of IPsec are also at > risk. This > >is not my concern alone, others have expressed it to me as well. > > > >At this point, to restore confidence in the security of the design I > >would hope that the IETF will retain the services of a quality > >cryptanalysis consulting firm and publish the results. To > do otherwise > >will be to risk the discrediting of the entire IPsec standard. > > Frankly, a lot of very competent folks did look at the cryptography. > WIth all due modesty, I published two papers on the subject > myself, and > I wasn't the only one. In fact, that's one of the reasons why IPsec > took so long -- the result of those analyses is why RFCs 1825-29 were > replaced by 2401 et al. -- because we found and fixed a fair > number of > problems. The flaws in the Schneier/Ferguson analysis are > because they don't understand the networking context. I sent Bruce a > long, detailed note about that before he ever published the analysis. > > You say "retain the services of a quality cryptanalysis > consulting firm". > Apart from the point that there aren't that many -- and I and others > know most of the likely players in the field -- the question > is whether > or not they understand the networking context. I have no particular > reason to think that the results would be any better than > what we have > now. > > Is IPsec perfect? No, of course not. I'd like to get rid of AH, for > example, not because it doesn't work -- it does -- but > because it adds > complexity to implementations without (to me) doing anything useful. > There are a few other minor things I'd have done differently. But I > have a great deal of confidence in the correctness of the > packet-level > transforms. > > --Steve Bellovin, http://www.research.att.com/~smb > > ------_=_NextPart_000_01C11E9E.C9E18270 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C11E9E.C9E18270-- From owner-ipsec@lists.tislabs.com Mon Aug 6 11:21:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76ILXN15251; Mon, 6 Aug 2001 11:21:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08794 Mon, 6 Aug 2001 13:36:57 -0400 (EDT) Message-ID: <8B204D152222D51182B70001028841372024CD@postmaster.cryptek.com> From: "Aronson, David" To: "'Shoichi Sakane'" Cc: ipsec@lists.tislabs.com Subject: RE: isakmp cookies field Date: Mon, 6 Aug 2001 14:08:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shoichi Sakane [mailto:sakane@kame.net] writes: > of course, i've read this document. but i think this cookie creation > couldn't prevent from dos or mitm attack. I dunno, you may be right, I'm rather new to IKE/ISAKMP/etc., was just quoting the RFC, and haven't the time right now to devote to a fuller analysis. Can you trace out a situation in which a DoS or MitM attack would succeed despite the cookies? (Even assuming that they are generated according to the RFC's recommendation, or any later that may have superseded it.) If you're wrong, I'm sure someone will speak up about how the cookies would prevent it.... -- Dave Aronson, Sysop of free public Fidonet BBS Air 'n Sun, +1-703-319-0714. Opinions all MINE, not by Cryptek/NRA/SCA/Mensa/HWG/LPUSA/CAUCE/FedGov/God! See my web site, at http://listen.to/davearonson (last updated 2001-06-27). Device-driver proggers: see http://www.cryptek.com and send me your resume! From owner-ipsec@lists.tislabs.com Mon Aug 6 11:21:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76ILZN15266; Mon, 6 Aug 2001 11:21:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08755 Mon, 6 Aug 2001 13:24:28 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA46@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Hugh Daniel'" , design@lists-freeswan.org Cc: wes@hardakers.net, ipsec@lists.tislabs.com Subject: RE: Wes Hardaker: opportunistic encryption deployment problems Date: Mon, 6 Aug 2001 10:30:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11E9D.8BC4BDF0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11E9D.8BC4BDF0 Content-Type: text/plain; charset="iso-8859-1" > At some point one has to just give up and tell folks to get it > together and control there own resources. OK, in my town high speed Internet is only available from one monopoly supplier, AT&T broadband. Absent an act of Congress to force AT&T to run their net the way you think they should, my only option is to start digging up the city streets myself with a back hoe. My situation is not unusual, it is the norm and will continue to be the norm unless someone works out how to make DSL work in practice. The Web grew because it adapted to the network configuration as it was and not how the designers thought it should be. If you can't cope with reality then that is your design problem and NOT someone else's deployment problem. > On the subject of NAT: If your NAT on the net your NOT on the net. > That's what I personally say at least. Without NAT the Internet would be dead of IP address exhaustion. To start making pejorative comments about a scheme that is the main means of conserving a scarce resource is unhelpful to say the least. Equally there are many good reasons to conceal an IP address for security purposes. I use NAT at my house, I don't want the structure of the internal net to be revealled to the outside world. I want to know that there the only servers in the network are the ones that I have set aside for that purpose and maintain accordingly. I don't want to be spending my time applying the latest inane patches to every machine. Schemes that can't cope with NAT should be outlawed until IPv6 is deployable and deployed. Somehow the 'let them eat cake' attitude of the net-affluent reminds me of a guy down in Washington. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 ------_=_NextPart_000_01C11E9D.8BC4BDF0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C11E9D.8BC4BDF0-- From owner-ipsec@lists.tislabs.com Mon Aug 6 12:41:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76JfNN16828; Mon, 6 Aug 2001 12:41:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08876 Mon, 6 Aug 2001 14:34:14 -0400 (EDT) Message-Id: <200108061717.f76HH5p25519@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: ipsec mailing list archive In-reply-to: Your message of "Sun, 05 Aug 2001 14:49:36 +0900." <20010805054937.EDB8E7BB@starfruit.itojun.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 06 Aug 2001 13:17:05 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Jun-ichiro" == Jun-ichiro itojun Hagino writes: Jun-ichiro> unfortunately, both of those do not work. could you please Jun-ichiro> find another one and list it onto the webpage? Jun-ichiro> ftp://ftp.tis.com/pub/lists/ipsec - no ftp.tis.com any more? Should be tislabs.com now. Jun-ichiro> with google, i found a couple of these. i dunno which is Jun-ichiro> better than the others. http://www.vpnc.org/ietf-ipsec/ Jun-ichiro> http://www.sandelman.ottawa.on.ca/ipsec/ I think that both Paul and my archives are current. Mine tends to be 1/2 month out at times since I pull the archives from ftp.tislabs.com instead of having an address subscribed. I recommend Paul's archives, since he probably has better connectivity than I. Jun-ichiro> http://www.cs.arizona.edu/xkernel/www/ipsec/ I can't speak for this one. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Mon Aug 6 12:41:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76JfcN16855; Mon, 6 Aug 2001 12:41:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08897 Mon, 6 Aug 2001 14:45:49 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA49@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" Cc: ipsec@lists.tislabs.com Subject: Cookies only make you fat Date: Mon, 6 Aug 2001 11:50:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11EA8.ABEE1350" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11EA8.ABEE1350 Content-Type: text/plain; charset="iso-8859-1" I just read Radia and Charlie's paper on IPSEC. I agree with the points they make there against the IPSEC cookies. I now believe that cookies do nothing but make the clients fat. First consider the reason for having the cookies, to avoid the need to maintain state in the server during the negotiation. But the negotiation only takes multiple round trips because it overloads the protocol with multiple functions (credential exchange) and attempts to conceal the identities of the participants (poorly as it happens). If the key agreement was a single round trip we would not require cookies. Mutual agreement of a key is possible in one round trip. Key agreement is not mutual authentication. It is slightly less. The criteria for a mutual key agreement is that at the end of the protocol the two parties have knowledge of the same shared token bound to the same context data if and only if they are the parties that authenticated themselves with the specified credentials. In mutual authentication there is the additional requirement that the two parties know the status of the other. But that is not our requirement here, all that is required is that Alice only gets the correct token if and only if she is Alice. In XKASS we use a single round trip, I hope to get the paper out by the end of the week. The other reason the key agreement is so long is because there is a half baked attempt at concealling the identity of the principals. I use the term 'half-baked' in the technical sense, the scheme conceals some but not all of the characteristics of the parties. Some observations: 1) True anonymous/anonymous contact in which neither party has any knowledge of the other in advance is impossible (unless someone implements randomcast routing in which your packets are sent off to a randomly chosen Internet address). One party is going to have to be listening on a specific port of a specific IP address somewhere. 2) If we assume that it is the responder whose credentials are 'known' in some sense then the people who really, really want to have unobservable communications can achieve them by simply issuing the clients with books of disposable, one time use credentials [note that OnSite is sold on a 'per seat basis' not 'per certificacte' any more so please don't ascribe unfair reasons to the suggestion]. 3) Alternatively assume that when Alice reauthenticates that she uses her old expired SA (or similar data thrown up for the purpose during the exchange) to encrypt the exchange. That would limit the identity leakage gap to the first contact. I strongly suspect that is sufficient for many purposes, or at least enough to serve. 4) The same information leaks out in the IP address in any case, so unless we are going across a true Chaumian network or we are using the Starbucks coffee house 802.11b alternative... Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 ------_=_NextPart_000_01C11EA8.ABEE1350 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C11EA8.ABEE1350-- From owner-ipsec@lists.tislabs.com Mon Aug 6 13:20:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76KKRN17450; Mon, 6 Aug 2001 13:20:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09036 Mon, 6 Aug 2001 15:25:50 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE7838128231@ROC-76-204.nai.com> From: "Mason, David" To: "'Marcus Leech'" , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Cc: "'jis@mit.edu'" Subject: RE: Position statement on IKE development Date: Mon, 6 Aug 2001 12:28:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is it true that the NAT traversal IKE and IPsec changes have been exempted from the moratorium? -dave From owner-ipsec@lists.tislabs.com Mon Aug 6 13:24:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76KOqN17512; Mon, 6 Aug 2001 13:24:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09048 Mon, 6 Aug 2001 15:26:25 -0400 (EDT) Message-Id: <200108061932.f76JW4u66072@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Hugh Daniel cc: design@lists-freeswan.org, wes@hardakers.net, ipsec@lists.tislabs.com Subject: Re: Wes Hardaker: opportunistic encryption deployment problems In-reply-to: Your message of Mon, 06 Aug 2001 15:50:41 BST. <200108061450.f76EofM05322@road.xisp.net> Date: Mon, 06 Aug 2001 21:32:04 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: To answer Mr. Hardaker, we understand the problem with requiring the data be in the reverse DNS space and considering a forward space solution, but there are many folks who have no control over even their forward space. Wes Hardaker's orginal (partial) message: 3 problems I see with the deployment of opportunistic encryption: 1) your method of obtaining information is by reverse DNS lookup, which will provide problems with people who can't control their reverse DNS bindings. As an example, I don't have control over the subnet mapped to my house and can not insert information into the controlling DNS server (and can not convince them to redirect to me). => first you should complain at your provider provider. I don't know the rules for ARIN but in Europe RIPE rules are clear: someone can get some address space only if it manages the reverse map and delegates it with parts of its address space. Of course RFC 2317 is not easy so even this kind of rules doesn't provide always a solution... Second point, when DNSSEC will be deployed it should be available for reverse maps first because today reverse maps are broken , nobody shall rely on them so they are free for experiments or an "all or nothing" use (DNSSEC should become a part of the "all" in this view). Don't forget direct maps are for NICs/RIRs clients and reverse maps are for operators/ISPs which should have the technical skill and a very different relationship with NICs/RIRs. Concretly, there are some deployment efforts from various NICs/RIRs and we can expect some results one day. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Aug 6 14:44:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76Li3N18700; Mon, 6 Aug 2001 14:44:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09307 Mon, 6 Aug 2001 16:49:01 -0400 (EDT) From: mcnelson@mindspring.com Date: Mon, 06 Aug 2001 16:56:02 -0400 To: pbaker@verisign.com Cc: ipsec@lists.tislabs.com Subject: Re: RE: Position statement on IKE development Message-ID: X-Originating-IP: 208.37.68.36 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Unfortunately the notion that IPsec should simply \"bind a key to an IP address\" was rejected repeatedly throughout the history of the IPsec WG. There are alternative protocols that have been built that demonstrate that one can provide a useful and appropriate encryption service in the IP layer and that such a system can be keyed and managed in a simple scalable way. Trying to key and manage all kinds of relationships many of which are conceptually challenging when viewed from the IP layer, is felt by many to be at the core of IPsec\'s complexity. As far as testing is concerned, it would be interesting to see an IPsec protected network set up as a challenge to the general networking public with a sizable cash price offered for the first 10 breakins. Mitch Nelson \"Hallam-Baker, Phillip\" wrote: > A couple of points: 1) You state that Bruce and co had failled to understand the network context. This is one of my concerns as people present IKE as a general purpose solution to all key agreement problems - including the key agreement for XML based Web services I have been working on. The argument keeps being thrown up \'use what exists and is tested\', yet the protocol is of necessity tied to its context. It is not possible to pick up ISAKMP/IKE and apply it to another appliction, I have tried. Yet others are going to insist upon doing so. I believe that the current multilayered, \'everything is negotiable\' negotiating mechanism is a liability even for its stated goal. It encourages people to try to use ISAKMP for purposes which it just does not support. 2) The current problems with NAT occur because IPSEC is being used in a network context it was never designed for. The IPSEC authentication mechanisms are designed to bind a key to an IP address. In the case of a user behind a NAT box that fails for obvious reasons. The question to be asked then is does this shift in the networking context affect the underlying security assumptions? The meta-question is, do we have a framework that allows questions such as these to be addressed? This is the problem that really bit the 802.11b team, their scheme is broken for two reasons, first the person who analysed the security appears to have assumed a block cipher would be used and not a stream cipher, second the design goals are fundamentally incomplete. The problem is not PRIVACY, but authenticating the user to stop the sacked employee in the car park surfing the ex-employer\'s intranet. Also any conception of privacy that includes Louis Freeh having to be able to read all my packets if he is granted access to the same network as me is somewhat strange to say the least... It may be a feature of ethernet, in a wireless network with an encryption layer it is a bug. 3) At this point we do not have a engineering approach to security protocol analysis. The nearest I have seen to an analytical approach is the work Phil Rogaway and Mihi Belhare have been doing on algorithms. Putting out a tender for security protocol analysis would be pointless if all we got as a result was a further set of experts reviewing the specs in the same ad hoc \'can we see holes\' fashion. In the early days of bridge building the \'build it, see if it will fall down\' algorithm was employed. Today most people (makers of wobbly bridges in London appart) believe in the \'use design principles that prevent failure\' approach. Unfortunately we don\'t have the design principles (yet). Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Saturday, August 04, 2001 7:00 PM > To: Alex Alten > Cc: Henry Spencer; Marcus Leech; msec@securemulticast.org; > ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org; ipsec@lists.tislabs.com > Subject: Re: Position statement on IKE development > > > In message , Alex Alten writes: > > > >> > >>Agreed. And large parts of the Schneier/Ferguson analysis of the > >>packet-level parts are just plain wrong. > >> > > > > > >Steve, with all due respect, you, Jeff and Marcus stated the > following. > > > >\"In the several years since the standardization of the IPSEC > protocols > >(ESP, AH, and ISAKMP/IKE), there have come to light several security > >problems with the protocols, most notably the key-agreement protocol, > >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and > >Simpson, have shown that the security problems in IKE stem directly > >from its complexity.\" > > > >If IKE is no longer considered viable because of it\'s > complexity, then > >I am concerned that the other protocols of IPsec are also at > risk. This > >is not my concern alone, others have expressed it to me as well. > > > >At this point, to restore confidence in the security of the design I > >would hope that the IETF will retain the services of a quality > >cryptanalysis consulting firm and publish the results. To > do otherwise > >will be to risk the discrediting of the entire IPsec standard. > > Frankly, a lot of very competent folks did look at the cryptography. > WIth all due modesty, I published two papers on the subject > myself, and > I wasn\'t the only one. In fact, that\'s one of the reasons why IPsec > took so long -- the result of those analyses is why RFCs 1825-29 were > replaced by 2401 et al. -- because we found and fixed a fair > number of > problems. The flaws in the Schneier/Ferguson analysis are > because they don\'t understand the networking context. I sent Bruce a > long, detailed note about that before he ever published the analysis. > > You say \"retain the services of a quality cryptanalysis > consulting firm\". > Apart from the point that there aren\'t that many -- and I and others > know most of the likely players in the field -- the question > is whether > or not they understand the networking context. I have no particular > reason to think that the results would be any better than > what we have > now. > > Is IPsec perfect? No, of course not. I\'d like to get rid of AH, for > example, not because it doesn\'t work -- it does -- but > because it adds > complexity to implementations without (to me) doing anything useful. > There are a few other minor things I\'d have done differently. But I > have a great deal of confidence in the correctness of the > packet-level > transforms. > > --Steve Bellovin, http://www.research.att.com/~smb > > From owner-ipsec@lists.tislabs.com Mon Aug 6 14:44:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76Li8N18712; Mon, 6 Aug 2001 14:44:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09335 Mon, 6 Aug 2001 17:04:06 -0400 (EDT) Message-ID: <3B6F07DC.F3A37A39@storm.ca> Date: Mon, 06 Aug 2001 17:10:52 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: opportunistic encryption deployment problems References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wes Hardaker wrote: > > 3 problems I see with the deployment of opportunistic encryption: > > 1) your method of obtaining information is by reverse DNS lookup, > which will provide problems with people who can't control their > reverse DNS bindings. As an example, I don't have control over the > subnet mapped to my house and can not insert information into the > controlling DNS server (and can not convince them to redirect to > me). Yes, but what alternatives are there, short of giving up on DNS and mandating that anyone wanting to do opportunistic encryption must have a particular type of PKI infrastructure in place? What is really wanted is support in the DNS for inverse queries, as Henry says in a document that preceeded the ID: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/opportunism.spec > Inverse queries, an obscure DNS feature from the distant past, > in theory can be used to ask a DNS server to reverse that > lookup, giving the name that produced the address. > This is not the same as a reverse lookup, and the difference can > matter a great deal in cases where a host does not control > its reverse map (e.g., when the host's IP address is dynamically > assigned). Unfortunately, inverse queries were never widely > implemented and are now considered obsolete. I suppose we could be trying to convince DNS implementors to support them, but it seems unlikely we could do that. Even if we succeeded, we'd still need a fallback mechanism for the situations where such support wasn't in place. Putting keys in the forward maps has some nice consequences, but also some serious problems. It goes a long way toward solving the problem for people with dynamic addresses. All we need to do is persuade the providers of dynamic DNS services to include keys. Well, not quite all. We have to work out how they can do that securely, and persuade them to implement secure DNS, and get things signed and ... It may also make connection setup faster. In the current design, the sequence is often: client does forward lookup to get IP address client builds and sends packet gateway interecepts packet gateway does reverse lookup to get key gateway starts negotiation If we could change it to: client does forward lookup to get IP address gateway gets key as a byproduct gateway starts negotiation that would involve less delay. However, short of requiring that every IPsec gateway run a DNS daemon, that clients all use that as their DNS server, and that the daemon be modified for some extra functionality (roughly equivalent to inverse queries), this does not work. Even if the responding DNS delivers key information from a forward map in response to client queries, the gateway has no way to get that info. All it sees is a packet with an IP address. It can get key info from a reverse map in one lookup. If the info is in a forward map, it needs two lookups and there can be complications with multiple names. Just taking the overhead hit and telling it do the two lookups doesn't work. In the situation you mention -- dynamic address and no control over the reverse map -- the reverse does not point to the name we want used in the subsequent forward lookup. Even in cases where it does give the right answer, the extra overhead of two lookups is a problem. Opportunistic must be fast; there are user packets waiting for the connection to be set up or declared unavailable. If we do specify a DNS daemon on the gateway and arrange for it, on doing a lookup for a client, to get a key if possible and pass it (how?) to IPsec, we still have problems. Clients will sometimes use addresses without first looking up the names, so we need another mechanism for that case. Also, it is by no means clear that requiring a DNS server on the gateway will fit into local security policies. From owner-ipsec@lists.tislabs.com Mon Aug 6 14:49:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76LnSN18765; Mon, 6 Aug 2001 14:49:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09341 Mon, 6 Aug 2001 17:04:20 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA4B@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Francis Dupont'" , Hugh Daniel Cc: wes@hardakers.net, ipsec@lists.tislabs.com Subject: RE: Wes Hardaker: opportunistic encryption deployment problems Date: Mon, 6 Aug 2001 14:07:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11EBB.BD0518B0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11EBB.BD0518B0 Content-Type: text/plain; charset="iso-8859-1" > => first you should complain at your provider provider. I don't know > the rules for ARIN but in Europe RIPE rules are clear: someone can get > some address space only if it manages the reverse map and delegates > it with parts of its address space. Of course RFC 2317 is not easy > so even this kind of rules doesn't provide always a solution... Support for reverse DNS lookup for current purposes (limited debugging) should not be conflated into support for a dependable service with arbitrary extensions added in to support specific applications. In particular reverse DNS is not much use when the target does not have a DNS address. This is the case for the vast majority of DCHP hosted home Internet hookups. I *like* my 10Mb/s cable modem into my house, particularly since I am the only person on my loop. If you want people to use your technology best design it arround their constraints. > Second point, when DNSSEC will be deployed it should be available > for reverse maps first because today reverse maps are broken , nobody > shall rely on them so they are free for experiments or an "all or > nothing" use (DNSSEC should become a part of the "all" in this view). > Don't forget direct maps are for NICs/RIRs clients and reverse maps > are for operators/ISPs which should have the technical skill and > a very different relationship with NICs/RIRs. > Concretly, there are some deployment efforts from various NICs/RIRs > and we can expect some results one day. I would not rely on any outcome being achieved as a byproduct of DNSSEC. DNSSEC has too many deployment obstacles of its own making to overcome without being given the task of putting other parts of the world to right on the way. Persuading people to use a new DNS system that requires more public key operations than SET to validate a single domain name is challenging enough without making its use dependent on reverse DNS being deployed. Phill ------_=_NextPart_000_01C11EBB.BD0518B0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C11EBB.BD0518B0-- From owner-ipsec@lists.tislabs.com Mon Aug 6 15:35:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76MZXN19298; Mon, 6 Aug 2001 15:35:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09510 Mon, 6 Aug 2001 17:55:16 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA4C@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'mcnelson@mindspring.com'" , "Hallam-Baker, Phillip" Cc: ipsec@lists.tislabs.com Subject: IKE must have no Heirs Date: Mon, 6 Aug 2001 15:02:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11EC3.70947CC0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11EC3.70947CC0 Content-Type: text/plain; charset="iso-8859-1" > Unfortunately the notion that IPsec should simply \"bind > a key to an IP address\" was rejected repeatedly throughout > the history of the IPsec WG. This is why I think we have to stop talking about 'son of IKE' as if the problem was in the 7 years and 9 months of trying to implement the requirements and not the 3 months of requirements capture. If a WG takes 8 years to come up with a solution it indicates a broken set of requirements. In the time that we have been waiting for IPSEC and DNSSEC to deploy we have deployed one generation of PKIX/X509.v3 based PKI and have started deployment of a second generation architecture to replace it. We can move quickly when there is clarity in the requirements. The first people to complain about the complexity of IKE were told 'we have been working on this for a year, it is too late to start again'. The next lot were told 'we have been working on this for two years, we can't wait another two'. The 'we have spent so long digging the well here we will not try digging elsewhere, even though others have struck water there' argument is self re-inforcing but does nothing but perpetuate the original broken assumptions. If the argument for the status quo is strong today 'it would take 8 years to replace IKE', just think how strong it will be in 2009 - 'it has taken 16 years to get this far, we will all be retired before your redesign is complete'. The DNSSEC group have been making a similar argument for years concerning the specious 'requirement' for non-repudiable responses. Despite the fact that non-repudiation is worthless without infrastructure to archive the messages no client will ever implement, the DNSSEC spec makes a fetish of it to the extent that each field in each message has its own signature. The combination of the non-repudiation requirement and the backwards compatibility requirement cannot be met except at unacceptable cost. The problem is not the demand for additional features, the problem is that they have to be addressed as 'additional'. IKE/ISAKMP spent their entire complexity budget on a negotiation framework for variation in features that are not core, not essential while ignoring real world problems such as NAT that are core. >From here there are two routes forward. We could specify a reduced IKE, eliminating all but 2 of the current 8 modes, simplifying the negotiation, knife AH... to result in a simpler draft that we can be confident would get a broad review. I think that would have been an excellent idea three years ago, I think that it is too late after the interop tests have been performed. All that would come out is a description of a profile of the current spec that resulted in one configuration that was secure. But implementations would still be constrained by the existing legacy base which would drag deployments back into the mire of unexamined code paths and unanticipated interactions. The second is to burn the current drafts and start from scratch with a fresh port number. If any change is made that breaks backwards compatibility then this might as well be what you do. In short the phrase 'Son of IKE' is part of the problem, not the solution. IKE must have no heirs, it is time for a new dynasty to take the throne. Phill ------_=_NextPart_000_01C11EC3.70947CC0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C11EC3.70947CC0-- From owner-ipsec@lists.tislabs.com Mon Aug 6 16:26:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76NQPN20162; Mon, 6 Aug 2001 16:26:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09624 Mon, 6 Aug 2001 18:43:52 -0400 (EDT) Message-ID: <3B6F1F2F.A28C6371@hns.com> Date: Mon, 06 Aug 2001 18:50:23 -0400 From: borderlt X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re draft-kaufman-ipsec-improveike-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Re getting rid of aggressive mode... Sigh! I can see the reasoning behind wanting to simplify down to only one mode. But, not offering the option for fewer messages will affect deployment of IPsec for links with high latency. We are starting to see a lot demand for the use of IPsec over satellite links with the usual corresponding optimization questions. And, identity hiding is not important for the cases where this has come up... John From owner-ipsec@lists.tislabs.com Mon Aug 6 17:06:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7706BN20699; Mon, 6 Aug 2001 17:06:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09746 Mon, 6 Aug 2001 19:22:40 -0400 (EDT) Date: Mon, 6 Aug 2001 16:29:03 -0700 (PDT) From: Jan Vilhuber To: borderlt cc: ipsec@lists.tislabs.com Subject: Re: Re draft-kaufman-ipsec-improveike-00.txt In-Reply-To: <3B6F1F2F.A28C6371@hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I see this argument a lot, and I've also used it in the past. My current thinking is: There's several routing protocols, not just one. They are sort of tailored to an certain network-topology, and one routing-protocol doesn't necessarily work in all topologies. We should look at a keying protocol in the same way. I suggest we work on more than one keying mechanism. Each one should be simple and should be tailored to one type of environment (the VPN space is afterall very different from the core-network environment). Different people will have different requirements, too. The answer to 'which keying protocol should I use' is no longer simple then, and requires one to think about the situation we're using it in, and what we want from it. So be it. It's not like users have to think about this stuff: It's what network admins do. They already have to deal with 'which routing protocol should I use'. We can then generate more than one rather simple keying mechanisms, that may or may not overlap slightly, but have strengths in different areas. Flames to /dev/null, constructive criticism encouraged. I am, of course, not a network admin, so those that have this job may well tell me this is a non-starter. Of course you should realize that we are already doing this: KINK is a keying protocol tailored to certain requirements. It doesn't try to be everything to all people. We probably need only one or two more to cover the other current requirements people have of a keying protocol. jan On Mon, 6 Aug 2001, borderlt wrote: > > Re getting rid of aggressive mode... Sigh! I can see the reasoning > behind wanting to simplify down to only one mode. But, not offering the > option for fewer messages will affect deployment of IPsec for links with high > latency. We are starting to see a lot demand for the use of IPsec over > satellite links with the usual corresponding optimization questions. And, > identity hiding is not important for the cases where this has come up... > > > John > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Aug 6 18:01:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77119N21526; Mon, 6 Aug 2001 18:01:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09870 Mon, 6 Aug 2001 20:10:37 -0400 (EDT) Date: Mon, 6 Aug 2001 16:15:05 -0700 (PDT) Message-Id: <200108062315.QAA09683@potomac.incog.com> From: ford@apollo.incog.com (Mike "Ford" Ditto) To: angelos@coredump.cis.upenn.edu CC: ipsec@lists.tislabs.com@potomac.incog.com In-reply-to: <200108061520.f76FKRK11964@nyarlathotep.keromytis.org> (angelos@coredump.cis.upenn.edu) Subject: Re: Phase 1 IDs ("son of IKE") Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: "Angelos D. Keromytis" > > Currently, the Responder in a Phase 1 (Main Mode) exchange picks the identity > to use based on the Initiator's IP address or Phase 1 ID, or uses some default > value (like the address of the interface the Phase 1 exchange occurs). The responder could conceivably use any information available, such as the proposed Phase I protection suite or the time of day. > What I'd like to suggest is that the Initiator be allowed to send a Responder > Phase 1 ID payload, which the Responder will use as a hint as to what ID to > use itself; the Responder can ignore this hint, at the risk of the exchange > not being completed. The extra code to support this is fairly small (in the > order of 50 lines, in OpenBSD isakmpd). This is an interesting suggestion. The current IKE scheme is the equivalent of calling a telephone number and saying "Hi, this is Mike, may I please speak to someone there?" and when the responder says "This is Joe," hanging up because you really wanted to talk to Bob. If you had just asked for Bob in the first place, the responder could have handed the phone to Bob. One problem is that the initiator's policy may not express the desired/allowed remote identity in a simple form that can be conveyed to the responder. For example, the initiator's policy may allow a connection with any remote identity that has a certificate signed by a particular CA, or with any of a long list of remote identities, or with a particular value of O= and OU= name components, but any CN= name component. The possibilities vary depending on the flexibility of the initiator's policy language. Even in the case of a single intended remote identity, it's possible that the initiator might use an alternate name for that identity that is not recognized by the responder, but still be able to recognize and accept the name that the responder would use in the absence of any "hint". But if the identity hint was used as an abstract name, rather than the exact identity that the responder is expected to use, it could be used as a kind of generic "scope" or "role" identifier. For example, if the initiator sends a hint of "internal-vpn.my.org", then a responder with many local identities could be configured to choose the identity that is appropriate for use as a gateway to the internal VPN when it sees that particular hint; for other hints it could be configured to use a more public identity. -=] Ford [=- From owner-ipsec@lists.tislabs.com Mon Aug 6 18:16:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f771GoN21884; Mon, 6 Aug 2001 18:16:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09961 Mon, 6 Aug 2001 20:38:39 -0400 (EDT) Message-Id: <200108070041.f770f1J23253@thunk.east.sun.com> From: Bill Sommerfeld To: "Horn, Mike" cc: "'Theodore Tso'" , Andrew Krywaniuk , "'Alex Alten'" , "'Marcus Leech'" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Position statement on IKE development In-reply-to: Your message of "Mon, 06 Aug 2001 18:03:08 MDT." Reply-to: sommerfeld@East.Sun.COM Date: Mon, 06 Aug 2001 20:41:01 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > One of the reasons various user authentication schemes have not been > considered (CRACK for instance) is the moratorium on changes to IKE. > Unfortunately the IPSRA WG is very dependent on IKE. The IPSRA WG is not at all dependant on IKE; it's really all about protocols to turn legacy authentication into certificates.. - Bill From owner-ipsec@lists.tislabs.com Tue Aug 7 00:07:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7777RN08247; Tue, 7 Aug 2001 00:07:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA10480 Tue, 7 Aug 2001 02:01:05 -0400 (EDT) Date: Mon, 6 Aug 2001 23:07:06 -0700 (PDT) From: Kory Hamzeh To: "Hallam-Baker, Phillip" cc: "'mcnelson@mindspring.com'" , ipsec@lists.tislabs.com Subject: Re: IKE must have no Heirs In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40154CA4C@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well said. I agree with you 100%. Throw is out and let's start from scratch with something more reasonable and realistic. Kory On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote: > > > Unfortunately the notion that IPsec should simply \"bind > > a key to an IP address\" was rejected repeatedly throughout > > the history of the IPsec WG. > > This is why I think we have to stop talking about 'son of IKE' > as if the problem was in the 7 years and 9 months of trying to > implement the requirements and not the 3 months of requirements > capture. > > [ ..... ] > > From here there are two routes forward. We could specify a reduced > IKE, eliminating all but 2 of the current 8 modes, simplifying the > negotiation, knife AH... to result in a simpler draft that we can be > confident would get a broad review. I think that would have been an > excellent idea three years ago, I think that it is too late after > the interop tests have been performed. All that would come out > is a description of a profile of the current spec that resulted > in one configuration that was secure. But implementations would > still be constrained by the existing legacy base which would > drag deployments back into the mire of unexamined code paths and > unanticipated interactions. > > The second is to burn the current drafts and start from scratch > with a fresh port number. If any change is made that breaks > backwards compatibility then this might as well be what you do. > > In short the phrase 'Son of IKE' is part of the problem, not > the solution. IKE must have no heirs, it is time for a new dynasty > to take the throne. > > > Phill > > From owner-ipsec@lists.tislabs.com Tue Aug 7 01:14:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f778E9N15741; Tue, 7 Aug 2001 01:14:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA10645 Tue, 7 Aug 2001 03:22:20 -0400 (EDT) Message-Id: <3.0.3.32.20010807002820.010a77f8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 07 Aug 2001 00:28:20 -0700 To: Kory Hamzeh , "Hallam-Baker, Phillip" From: Alex Alten Subject: Re: IKE must have no Heirs Cc: "'mcnelson@mindspring.com'" , ipsec@lists.tislabs.com In-Reply-To: References: <2F3EC696EAEED311BB2D009027C3F4F40154CA4C@vhqpostal.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I second the motion. And also propose no port number (i.e. do the new one over raw IP). - Alex At 11:07 PM 8/6/2001 -0700, Kory Hamzeh wrote: > >Well said. I agree with you 100%. Throw is out and let's start from >scratch with something more reasonable and realistic. > >Kory > > >On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote: > >> >> > Unfortunately the notion that IPsec should simply \"bind >> > a key to an IP address\" was rejected repeatedly throughout >> > the history of the IPsec WG. >> >> This is why I think we have to stop talking about 'son of IKE' >> as if the problem was in the 7 years and 9 months of trying to >> implement the requirements and not the 3 months of requirements >> capture. >> >> [ ..... ] >> >> From here there are two routes forward. We could specify a reduced >> IKE, eliminating all but 2 of the current 8 modes, simplifying the >> negotiation, knife AH... to result in a simpler draft that we can be >> confident would get a broad review. I think that would have been an >> excellent idea three years ago, I think that it is too late after >> the interop tests have been performed. All that would come out >> is a description of a profile of the current spec that resulted >> in one configuration that was secure. But implementations would >> still be constrained by the existing legacy base which would >> drag deployments back into the mire of unexamined code paths and >> unanticipated interactions. >> >> The second is to burn the current drafts and start from scratch >> with a fresh port number. If any change is made that breaks >> backwards compatibility then this might as well be what you do. >> >> In short the phrase 'Son of IKE' is part of the problem, not >> the solution. IKE must have no heirs, it is time for a new dynasty >> to take the throne. >> >> >> Phill >> >> > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Tue Aug 7 02:01:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7791kN21486; Tue, 7 Aug 2001 02:01:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10834 Tue, 7 Aug 2001 04:07:49 -0400 (EDT) Message-Id: <200108070812.f778Cfu67935@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hallam-Baker, Phillip" cc: Hugh Daniel , wes@hardakers.net, ipsec@lists.tislabs.com Subject: Re: Wes Hardaker: opportunistic encryption deployment problems In-reply-to: Your message of Mon, 06 Aug 2001 14:07:02 PDT. <2F3EC696EAEED311BB2D009027C3F4F40154CA4B@vhqpostal.verisign.com> Date: Tue, 07 Aug 2001 10:12:41 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > => first you should complain at your provider provider. I don't know > the rules for ARIN but in Europe RIPE rules are clear: someone can get > some address space only if it manages the reverse map and delegates > it with parts of its address space. Of course RFC 2317 is not easy > so even this kind of rules doesn't provide always a solution... Support for reverse DNS lookup for current purposes (limited debugging) should not be conflated into support for a dependable service with arbitrary extensions added in to support specific applications. In particular reverse DNS is not much use when the target does not have a DNS address. => DNS name. This is the case for the vast majority of DCHP hosted home Internet hookups. => my answer was about a fixed subnet, not a dynamic single address. I *like* my 10Mb/s cable modem into my house, particularly since I am the only person on my loop. If you want people to use your technology best design it arround their constraints. => you don't use the Internet itself, you use an online service connected to the Internet. Or explain how you can run a server at home... Obviously you are out of the topics. (PS: I know you are not responsible of this situation, the shame is for your monopolistic ISP :-). > Second point, when DNSSEC will be deployed it should be available > for reverse maps first because today reverse maps are broken , nobody > shall rely on them so they are free for experiments or an "all or > nothing" use (DNSSEC should become a part of the "all" in this view). > Don't forget direct maps are for NICs/RIRs clients and reverse maps > are for operators/ISPs which should have the technical skill and > a very different relationship with NICs/RIRs. > Concretly, there are some deployment efforts from various NICs/RIRs > and we can expect some results one day. I would not rely on any outcome being achieved as a byproduct of DNSSEC. => you can believe in DNSSEC or not, or would like to believe in it in the future (my case). I've just said that DNSSEC deployment efforts should be for reverse maps... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Aug 7 02:15:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f779FUN22373; Tue, 7 Aug 2001 02:15:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10859 Tue, 7 Aug 2001 04:19:04 -0400 (EDT) Message-ID: From: Chris Trobridge To: Alex Alten Cc: ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs Date: Tue, 7 Aug 2001 09:22:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Alex Alten [mailto:Alten@home.com] > Sent: 07 August 2001 08:28 > To: Kory Hamzeh; Hallam-Baker, Phillip > Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > Subject: Re: IKE must have no Heirs > > > > I second the motion. And also propose no port number (i.e. do the new > one over raw IP). > > - Alex What would that achieve? (communicating over raw IP) Chris ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Tue Aug 7 03:10:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77AASN24716; Tue, 7 Aug 2001 03:10:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA10978 Tue, 7 Aug 2001 04:59:54 -0400 (EDT) Message-Id: <3.0.3.32.20010807020559.00d89980@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 07 Aug 2001 02:05:59 -0700 To: Chris Trobridge From: Alex Alten Subject: RE: IKE must have no Heirs Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Think about it. Do you do OSPF over IP and then BGP over UDP? The same applies to IPSEC and key management. - Alex At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > >> -----Original Message----- >> From: Alex Alten [mailto:Alten@home.com] >> Sent: 07 August 2001 08:28 >> To: Kory Hamzeh; Hallam-Baker, Phillip >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com >> Subject: Re: IKE must have no Heirs >> >> >> >> I second the motion. And also propose no port number (i.e. do the new >> one over raw IP). >> >> - Alex > >What would that achieve? (communicating over raw IP) > >Chris > > >--------------------------------------------------------------------------- -------------------------------------- >The information contained in this message is confidential and is intended >for the addressee(s) only. If you have received this message in error or >there are any problems please notify the originator immediately. The >unauthorized use, disclosure, copying or alteration of this message is >strictly forbidden. Baltimore Technologies plc will not be liable for direct, >special, indirect or consequential damages arising from alteration of the >contents of this message by a third party or as a result of any virus being >passed on. > >In addition, certain Marketing collateral may be added from time to time to >promote Baltimore Technologies products, services, Global e-Security or >appearance at trade shows and conferences. > >This footnote confirms that this email message has been swept by >Baltimore MIMEsweeper for Content Security threats, including >computer viruses. > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Tue Aug 7 05:30:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77CUmN01331; Tue, 7 Aug 2001 05:30:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA11374 Tue, 7 Aug 2001 07:17:44 -0400 (EDT) Subject: Re: isakmp cookies field To: Shoichi Sakane Cc: ipsec@lists.tislabs.com From: Niels Provos In-Reply-To: Shoichi Sakane, Mon, 06 Aug 2001 20:48:24 +0900 Date: Tue, 07 Aug 2001 07:24:48 -0400 Message-Id: <20010807112448.6FB72207C1@citi.umich.edu> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20010806204824B.sakane@kame.net>, Shoichi Sakane writes: >could anybody tell me what the benefit of the isakmp cookie field is ? >i think the cookie indicates just isakmp spi. does it have any function >to prevent from dos attack ? It does not prevent simple resource starvation attacks. You might want to read Bill Simpson's "IKE/ISAKMP considered harmful" about that. You can find the article at http://www.usenix.org/publications/login/1999-12/features/harmful.html Greetings, Niels. From owner-ipsec@lists.tislabs.com Tue Aug 7 06:06:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77D6NN02020; Tue, 7 Aug 2001 06:06:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11500 Tue, 7 Aug 2001 08:12:54 -0400 (EDT) Message-ID: <3B6EF26D.E8A2C7D0@pgp.com> Date: Mon, 06 Aug 2001 12:39:25 -0700 From: Will Price Reply-To: wprice@pgp.com X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Mason, David" CC: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com, "'jis@mit.edu'" Subject: Re: Position statement on IKE development References: <8894CA1F87A5D411BD24009027EE7838128231@ROC-76-204.nai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes. See Ted's message from yesterday. "Mason, David" wrote: > > Is it true that the NAT traversal IKE and IPsec changes have been exempted > from the moratorium? > -dave -- From owner-ipsec@lists.tislabs.com Tue Aug 7 06:37:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DbUN02695; Tue, 7 Aug 2001 06:37:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11539 Tue, 7 Aug 2001 08:31:55 -0400 (EDT) Message-ID: <001501c11f3e$58ade7b0$4e8d21d9@sfanninglaptop> From: "Scott Fanning" To: "Chris Trobridge" , "Alex Alten" Cc: References: <3.0.3.32.20010807020559.00d89980@mail> Subject: Re: IKE must have no Heirs Date: Tue, 7 Aug 2001 05:41:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, what do we propose to those that are using IKE right now (like customers). Oops, sorry, its too complex. Maybe next time? I suggest that we look at the documents that describe the improvements, and ask the implementors (the ones confused by the complexity) how the standards body can work to make their job easier (A clearly defined state machine would be nice, with less SHOULDs' and more MUSTs). Also, any changes should keep in mind an easy transition to "Son of Ike" so that deploying the less complex version of IKE, does not create more complexity. Scott ----- Original Message ----- From: "Alex Alten" To: "Chris Trobridge" Cc: Sent: Tuesday, August 07, 2001 2:05 AM Subject: RE: IKE must have no Heirs > Think about it. Do you do OSPF over IP and then BGP over UDP? > The same applies to IPSEC and key management. > > - Alex > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > >> -----Original Message----- > >> From: Alex Alten [mailto:Alten@home.com] > >> Sent: 07 August 2001 08:28 > >> To: Kory Hamzeh; Hallam-Baker, Phillip > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > >> Subject: Re: IKE must have no Heirs > >> > >> > >> > >> I second the motion. And also propose no port number (i.e. do the new > >> one over raw IP). > >> > >> - Alex > > > >What would that achieve? (communicating over raw IP) > > > >Chris > > > > > >--------------------------------------------------------------------------- > -------------------------------------- > >The information contained in this message is confidential and is intended > >for the addressee(s) only. If you have received this message in error or > >there are any problems please notify the originator immediately. The > >unauthorized use, disclosure, copying or alteration of this message is > >strictly forbidden. Baltimore Technologies plc will not be liable for > direct, > >special, indirect or consequential damages arising from alteration of the > >contents of this message by a third party or as a result of any virus being > >passed on. > > > >In addition, certain Marketing collateral may be added from time to time to > >promote Baltimore Technologies products, services, Global e-Security or > >appearance at trade shows and conferences. > > > >This footnote confirms that this email message has been swept by > >Baltimore MIMEsweeper for Content Security threats, including > >computer viruses. > > > > > -- > > Alex Alten > > Alten@Home.Com > > From owner-ipsec@lists.tislabs.com Tue Aug 7 06:41:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77Df6N02747; Tue, 7 Aug 2001 06:41:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11651 Tue, 7 Aug 2001 09:03:04 -0400 (EDT) Message-Id: <200108061957.f76JvkH01351@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Phase 1 IDs ("son of IKE") In-reply-to: Your message of "Mon, 06 Aug 2001 11:20:27 EDT." <200108061520.f76FKRK11964@nyarlathotep.keromytis.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 06 Aug 2001 15:57:46 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Angelos" == Angelos D Keromytis writes: Angelos> What I'd like to suggest is that the Initiator be allowed to Angelos> send a Responder Phase 1 ID payload, which the Responder will Angelos> use as a hint as to what ID to use itself; the Responder can Angelos> ignore this hint, at the risk of the exchange not being Angelos> completed. The extra code to support this is fairly small (in Angelos> the order of 50 lines, in OpenBSD isakmpd). A la Host: header in HTTP? I.e. "this is the ID which *I* thought I was contacting" Angelos> This change allows for per-user authentication on IKE, and makes I'm not sure that I follow this completely. You mean, individual users can "respond" (via PF_* stuff...) Angelos> much simpler Phase 1 negotiations where a) the Initiator and Angelos> Responder roles change over time (because of unbalanced Phase 1 Angelos> SA expirations), *and* b) the Phase 1 ID used by the Initiator Angelos> is not the same as that used when it acts as a Responder. It seems to make sense to me. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO272uYqHRg3pndX9AQH21AP8CWerhFalJXFRgGmQutZ7PXWsCm3ncxRm 831gKb0XB6H9DXQfM6hF+aJvAyhed5QrDZBFgmoM+zvKGcVS2awC3vbNU/oxI9Ed /MOyRIdECgcNklXRLru3cXZOT5+qp4HTbMn9OgT7Ei2gkqADh4tQpWdknOKKTtfX eV1lf1lGZBw= =A+66 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 7 06:52:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DqXN02975; Tue, 7 Aug 2001 06:52:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11692 Tue, 7 Aug 2001 09:09:06 -0400 (EDT) Message-ID: <3B6FAE9C.4010606@piuha.net> Date: Tue, 07 Aug 2001 12:02:20 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber Cc: borderlt , ipsec@lists.tislabs.com Subject: Re: Re draft-kaufman-ipsec-improveike-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > I suggest we work on more than one keying mechanism. Each one should be > simple and should be tailored to one type of environment (the VPN space is > afterall very different from the core-network environment). Different people > will have different requirements, too. I support this idea. A particular example comes to my mind: cellular systems for instance typically have long delay times and propably want to make the tradeoff of less roundtrips against e.g. PFS/identity protection/some DoS holes. In some environments, some of the lost features would be your most important ones. Conflicts like this will lead to an incredible shouting contest when Son-of-IKE is being designed. It is important to understand that there are conflicting requirements. (On the other hand, I'm not fully convinced that completely separate protocols are needed. Starting from scratch, it might be possible to have a cleaner design that separates various protocol functionalities better. For instance, servers that are under a DoS attack might respond to all key management requests that "no, you have to run the DoS-preventing-puzzle-solving-protocol first".) Jari From owner-ipsec@lists.tislabs.com Tue Aug 7 06:53:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DrKN02997; Tue, 7 Aug 2001 06:53:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11660 Tue, 7 Aug 2001 09:04:04 -0400 (EDT) Message-ID: <3B6F0D5D.9F4990F4@datatekcorp.com> Date: Mon, 06 Aug 2001 17:34:22 -0400 From: "Dr. Mitchell C. Nelson" Reply-To: mcnelson@datatekcorp.com Organization: Datatek Applications, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pbaker@verisign.com, ipsec@lists.tislabs.com Subject: [Fwd: Position statement on IKE development] Content-Type: multipart/mixed; boundary="------------12200DC44185399836774F4F" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------12200DC44185399836774F4F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Regarding design principles and communications security, I think that indeed we do have the principles or at least the taxonomy and an approach, as embodied in x.800. But there seem to be very few in the network security industry who have read it and appreciate it. mcnelson@mindspring.com wrote: > Unfortunately the notion that IPsec should simply \"bind > a key to an IP address\" was rejected repeatedly throughout > the history of the IPsec WG. There are alternative > protocols that have been built that demonstrate that one > can provide a useful and appropriate encryption service > in the IP layer and that such a system can be keyed and > managed in a simple scalable way. > > Trying to key and manage all kinds of relationships many > of which are conceptually challenging when viewed from > the IP layer, is felt by many to be at the core of IPsec\'s > complexity. > > As far as testing is concerned, it would be interesting > to see an IPsec protected network set up as a challenge > to the general networking public with a sizable cash > price offered for the first 10 breakins. > > Mitch Nelson > > \"Hallam-Baker, Phillip\" wrote: > > A couple of points: > 1) You state that Bruce and co had failled to understand the network > context. This is one of my concerns as people present IKE as a general > purpose solution to all key agreement problems - including the key agreement > for XML based Web services I have been working on. > > The argument keeps being thrown up \'use what exists and is tested\', yet the > protocol is of necessity tied to its context. It is not possible to pick up > ISAKMP/IKE and apply it to another appliction, I have tried. Yet others are > going to insist upon doing so. > > I believe that the current multilayered, \'everything is negotiable\' > negotiating mechanism is a liability even for its stated goal. It encourages > people to try to use ISAKMP for purposes which it just does not support. > > 2) The current problems with NAT occur because IPSEC is being used in a > network context it was never designed for. The IPSEC authentication > mechanisms are designed to bind a key to an IP address. In the case of a > user behind a NAT box that fails for obvious reasons. > > The question to be asked then is does this shift in the networking context > affect the underlying security assumptions? > > The meta-question is, do we have a framework that allows questions such as > these to be addressed? > > This is the problem that really bit the 802.11b team, their scheme is broken > for two reasons, first the person who analysed the security appears to have > assumed a block cipher would be used and not a stream cipher, second the > design goals are fundamentally incomplete. The problem is not PRIVACY, but > authenticating the user to stop the sacked employee in the car park surfing > the ex-employer\'s intranet. Also any conception of privacy that includes > Louis Freeh having to be able to read all my packets if he is granted access > to the same network as me is somewhat strange to say the least... It may be > a feature of ethernet, in a wireless network with an encryption layer it is > a bug. > > 3) At this point we do not have a engineering approach to security protocol > analysis. The nearest I have seen to an analytical approach is the work Phil > Rogaway and Mihi Belhare have been doing on algorithms. > > Putting out a tender for security protocol analysis would be pointless if > all we got as a result was a further set of experts reviewing the specs in > the same ad hoc \'can we see holes\' fashion. > > In the early days of bridge building the \'build it, see if it will fall > down\' algorithm was employed. Today most people (makers of wobbly bridges in > London appart) believe in the \'use design principles that prevent failure\' > approach. Unfortunately we don\'t have the design principles (yet). > > Phill > > Phillip Hallam-Baker FBCS C.Eng. > Principal Scientist > VeriSign Inc. > pbaker@verisign.com > 781 245 6996 x227 > > > -----Original Message----- > > From: Steven M. Bellovin [mailto:smb@research.att.com] > > Sent: Saturday, August 04, 2001 7:00 PM > > To: Alex Alten > > Cc: Henry Spencer; Marcus Leech; msec@securemulticast.org; > > ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org; ipsec@lists.tislabs.com > > Subject: Re: Position statement on IKE development > > > > > > In message , Alex Alten writes: > > > > > > >> > > >>Agreed. And large parts of the Schneier/Ferguson analysis of the > > >>packet-level parts are just plain wrong. > > >> > > > > > > > > >Steve, with all due respect, you, Jeff and Marcus stated the > > following. > > > > > >\"In the several years since the standardization of the IPSEC > > protocols > > >(ESP, AH, and ISAKMP/IKE), there have come to light several security > > >problems with the protocols, most notably the key-agreement protocol, > > >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and > > >Simpson, have shown that the security problems in IKE stem directly > > >from its complexity.\" > > > > > >If IKE is no longer considered viable because of it\'s > > complexity, then > > >I am concerned that the other protocols of IPsec are also at > > risk. This > > >is not my concern alone, others have expressed it to me as well. > > > > > >At this point, to restore confidence in the security of the design I > > >would hope that the IETF will retain the services of a quality > > >cryptanalysis consulting firm and publish the results. To > > do otherwise > > >will be to risk the discrediting of the entire IPsec standard. > > > > Frankly, a lot of very competent folks did look at the cryptography. > > WIth all due modesty, I published two papers on the subject > > myself, and > > I wasn\'t the only one. In fact, that\'s one of the reasons why IPsec > > took so long -- the result of those analyses is why RFCs 1825-29 were > > replaced by 2401 et al. -- because we found and fixed a fair > > number of > > problems. The flaws in the Schneier/Ferguson analysis are > > because they don\'t understand the networking context. I sent Bruce a > > long, detailed note about that before he ever published the analysis. > > > > You say \"retain the services of a quality cryptanalysis > > consulting firm\". > > Apart from the point that there aren\'t that many -- and I and others > > know most of the likely players in the field -- the question > > is whether > > or not they understand the networking context. I have no particular > > reason to think that the results would be any better than > > what we have > > now. > > > > Is IPsec perfect? No, of course not. I\'d like to get rid of AH, for > > example, not because it doesn\'t work -- it does -- but > > because it adds > > complexity to implementations without (to me) doing anything useful. > > There are a few other minor things I\'d have done differently. But I > > have a great deal of confidence in the correctness of the > > packet-level > > transforms. > > > > --Steve Bellovin, http://www.research.att.com/~smb > > > > --------------12200DC44185399836774F4F Content-Type: message/rfc822 Content-Disposition: inline Received: HReceived: from micro4.icsnet.net (micro4.icsnet.net [205.136.35.54]) by busmail3.icsnet.net (ics mailserver) with ESMTP id QAA25925 for ; Mon, 6 Aug 2001 16:54:45 -0400 (EDT) From: mcnelson@mindspring.com Received: HReceived: from micro4.icsnet.net (localhost [127.0.0.1]) by micro4.icsnet.net (ics mailserver) with ESMTP id QAA10529 for ; Mon, 6 Aug 2001 16:56:04 -0400 (EDT) Received: HReceived: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by micro4.icsnet.net (ics mailserver) with ESMTP id QAA10519 for ; Mon, 6 Aug 2001 16:56:03 -0400 (EDT) Received: from smui05.slb.mindspring.net (smui05.slb.mindspring.net [199.174.114.91]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id QAA21677; Mon, 6 Aug 2001 16:56:02 -0400 (EDT) Received: by smui05.slb.mindspring.net id QAA0000024627; Mon, 6 Aug 2001 16:56:02 -0400 (EDT) Date: Mon, 06 Aug 2001 16:56:02 -0400 To: pbaker@verisign.com Cc: ipsec@lists.tislabs.com Subject: Re: RE: Position statement on IKE development Sender: mcnelson@mindspring.com Message-ID: X-Originating-IP: 208.37.68.36 Content-Type: text X-Mozilla-Status2: 00000000 MIME-Version: 1.0 Unfortunately the notion that IPsec should simply \"bind a key to an IP address\" was rejected repeatedly throughout the history of the IPsec WG. There are alternative protocols that have been built that demonstrate that one can provide a useful and appropriate encryption service in the IP layer and that such a system can be keyed and managed in a simple scalable way. Trying to key and manage all kinds of relationships many of which are conceptually challenging when viewed from the IP layer, is felt by many to be at the core of IPsec\'s complexity. As far as testing is concerned, it would be interesting to see an IPsec protected network set up as a challenge to the general networking public with a sizable cash price offered for the first 10 breakins. Mitch Nelson \"Hallam-Baker, Phillip\" wrote: > A couple of points: 1) You state that Bruce and co had failled to understand the network context. This is one of my concerns as people present IKE as a general purpose solution to all key agreement problems - including the key agreement for XML based Web services I have been working on. The argument keeps being thrown up \'use what exists and is tested\', yet the protocol is of necessity tied to its context. It is not possible to pick up ISAKMP/IKE and apply it to another appliction, I have tried. Yet others are going to insist upon doing so. I believe that the current multilayered, \'everything is negotiable\' negotiating mechanism is a liability even for its stated goal. It encourages people to try to use ISAKMP for purposes which it just does not support. 2) The current problems with NAT occur because IPSEC is being used in a network context it was never designed for. The IPSEC authentication mechanisms are designed to bind a key to an IP address. In the case of a user behind a NAT box that fails for obvious reasons. The question to be asked then is does this shift in the networking context affect the underlying security assumptions? The meta-question is, do we have a framework that allows questions such as these to be addressed? This is the problem that really bit the 802.11b team, their scheme is broken for two reasons, first the person who analysed the security appears to have assumed a block cipher would be used and not a stream cipher, second the design goals are fundamentally incomplete. The problem is not PRIVACY, but authenticating the user to stop the sacked employee in the car park surfing the ex-employer\'s intranet. Also any conception of privacy that includes Louis Freeh having to be able to read all my packets if he is granted access to the same network as me is somewhat strange to say the least... It may be a feature of ethernet, in a wireless network with an encryption layer it is a bug. 3) At this point we do not have a engineering approach to security protocol analysis. The nearest I have seen to an analytical approach is the work Phil Rogaway and Mihi Belhare have been doing on algorithms. Putting out a tender for security protocol analysis would be pointless if all we got as a result was a further set of experts reviewing the specs in the same ad hoc \'can we see holes\' fashion. In the early days of bridge building the \'build it, see if it will fall down\' algorithm was employed. Today most people (makers of wobbly bridges in London appart) believe in the \'use design principles that prevent failure\' approach. Unfortunately we don\'t have the design principles (yet). Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Saturday, August 04, 2001 7:00 PM > To: Alex Alten > Cc: Henry Spencer; Marcus Leech; msec@securemulticast.org; > ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org; ipsec@lists.tislabs.com > Subject: Re: Position statement on IKE development > > > In message , Alex Alten writes: > > > >> > >>Agreed. And large parts of the Schneier/Ferguson analysis of the > >>packet-level parts are just plain wrong. > >> > > > > > >Steve, with all due respect, you, Jeff and Marcus stated the > following. > > > >\"In the several years since the standardization of the IPSEC > protocols > >(ESP, AH, and ISAKMP/IKE), there have come to light several security > >problems with the protocols, most notably the key-agreement protocol, > >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and > >Simpson, have shown that the security problems in IKE stem directly > >from its complexity.\" > > > >If IKE is no longer considered viable because of it\'s > complexity, then > >I am concerned that the other protocols of IPsec are also at > risk. This > >is not my concern alone, others have expressed it to me as well. > > > >At this point, to restore confidence in the security of the design I > >would hope that the IETF will retain the services of a quality > >cryptanalysis consulting firm and publish the results. To > do otherwise > >will be to risk the discrediting of the entire IPsec standard. > > Frankly, a lot of very competent folks did look at the cryptography. > WIth all due modesty, I published two papers on the subject > myself, and > I wasn\'t the only one. In fact, that\'s one of the reasons why IPsec > took so long -- the result of those analyses is why RFCs 1825-29 were > replaced by 2401 et al. -- because we found and fixed a fair > number of > problems. The flaws in the Schneier/Ferguson analysis are > because they don\'t understand the networking context. I sent Bruce a > long, detailed note about that before he ever published the analysis. > > You say \"retain the services of a quality cryptanalysis > consulting firm\". > Apart from the point that there aren\'t that many -- and I and others > know most of the likely players in the field -- the question > is whether > or not they understand the networking context. I have no particular > reason to think that the results would be any better than > what we have > now. > > Is IPsec perfect? No, of course not. I\'d like to get rid of AH, for > example, not because it doesn\'t work -- it does -- but > because it adds > complexity to implementations without (to me) doing anything useful. > There are a few other minor things I\'d have done differently. But I > have a great deal of confidence in the correctness of the > packet-level > transforms. > > --Steve Bellovin, http://www.research.att.com/~smb > > --------------12200DC44185399836774F4F-- From owner-ipsec@lists.tislabs.com Tue Aug 7 06:54:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77Ds4N03024; Tue, 7 Aug 2001 06:54:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11716 Tue, 7 Aug 2001 09:12:06 -0400 (EDT) Date: 7 Aug 2001 09:11:34 -0000 Message-ID: <20010807091134.24970.qmail@mailweb29.rediffmail.com> MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" Subject: problems in manual keying From: "tsbalaji1993@rediffmail.com" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi all while working in openbsd, we enabled ah and esp by sysctl -w net.inet.esp.enable =1 sysctl -w net.inet.ah.enable =1 then we setup SA as follows on host 192.168.7.151 ipsecadm new esp -spi 1000 -src 192.168.7.151 -dst 192.168.7.152 -forcetunnel -enc 3des -auth sha1 -key 5555555555555555555555555555555555555555 -authkey 7777777777777777777777777777777777777777 ipsecadm new esp -spi 1001 -src 192.168.7.152 -dst 192.168.7.151 -forcetunnel -enc 3des -auth sha1 -key 5555555555555555555555555555555555555555 -authkey 7777777777777777777777777777777777777777 On host 192.168.7.152 ipsecadm new esp -spi 1001 -src 192.168.7.152 -dst 192.168.7.151 -forcetunnel -enc 3des -auth sha1 -key 5555555555555555555555555555555555555555 -authkey 7777777777777777777777777777777777777777 ipsecadm new esp -spi 1000 -src 192.168.7.151 -dst 192.168.7.152 -forcetunnel -enc 3des -auth sha1 -key 5555555555555555555555555555555555555555 -authkey 7777777777777777777777777777777777777777 for flow we tried On host 192.168.7.151 ipsecadm flow -proto esp -dst 192.168.7.152 -spi 1000 -addr 192.168.7.151 255.255.255.255 192.168.7.152 255.255.255.255 on host 192.168.7.152 ipsecadm flow -proto esp -dst 192.168.7.151 -spi 1001 -addr 192.168.7.152 255.255.255.255 192.168.7.151 255.255.255.255 but since "-spi depreciated" error came we tried on host 192.168.7.151 ipsecadm flow -proto esp -dst 192.168.7.152 -addr 192.168.7.151 255.255.255.255 192.168.7.152 255.255.255.255 - out -require on host 192.168.7.152 ipsecadm flow -proto esp -dst 192.168.7.151 -addr 192.168.7.152 255.255.255.255 192.168.7.151 255.255.255.255 -in -require but after this PING is tried and Tcpdump is used to capture the packets. but only " echo request" packets are coming but not "echo reply " packets. how to rectify the error. what is wrong.?? with love balaji _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm From owner-ipsec@lists.tislabs.com Tue Aug 7 06:54:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DsAN03047; Tue, 7 Aug 2001 06:54:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11681 Tue, 7 Aug 2001 09:07:06 -0400 (EDT) Message-Id: <200108070821.f778LRR18797@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: ford@apollo.incog.com (Mike "Ford" Ditto) Cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 IDs ("son of IKE") In-reply-to: Your message of "Mon, 06 Aug 2001 16:15:05 PDT." <200108062315.QAA09683@potomac.incog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Aug 2001 04:21:27 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200108062315.QAA09683@potomac.incog.com>, Mike "Ford" Ditto writes: > >The responder could conceivably use any information available, such as >the proposed Phase I protection suite or the time of day. What I meant was that the Responder cannot know what the Initiator had in mind. >One problem is that the initiator's policy may not express the >desired/allowed remote identity in a simple form that can be conveyed to >the responder. For example, the initiator's policy may allow a >connection with any remote identity that has a certificate signed by a >particular CA, This particular case is possible by sending the appropriate CERTREQ message. >But if the identity hint was used as an abstract name, rather than the >exact identity that the responder is expected to use, it could be used >as a kind of generic "scope" or "role" identifier. For example, if the >initiator sends a hint of "internal-vpn.my.org", then a responder with >many local identities could be configured to choose the identity that is >appropriate for use as a gateway to the internal VPN when it sees that >particular hint; for other hints it could be configured to use a more >public identity. My concern with this is that it's more complicated than the simple case of "here's what I'd like you to use", both in terms of semantics, effort that has to go in specs, and code. In any case, as I said the Responder is free to ignore the hint and use some other Phase 1 ID (which the Initiator may or may not like). Furthermore, the Responder, given the hint and the Initiator's ID, has enough information to in fact reverse the roles and act as an Initiator with the appropriate Phase 1 ID for itself. Finally, the "pick the right role" can, at least partly, be done by examining just the Initiator's Phase 1 ID. What I suggest is really useful for per-user keying, less so for host/user-to-host. -Angelos From owner-ipsec@lists.tislabs.com Tue Aug 7 07:16:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77EGhN03632; Tue, 7 Aug 2001 07:16:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11515 Tue, 7 Aug 2001 08:18:12 -0400 (EDT) To: "Mason, David" Cc: "'Marcus Leech'" , ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com, "'jis@mit.edu'" Subject: Re: Position statement on IKE development References: <8894CA1F87A5D411BD24009027EE7838128231@ROC-76-204.nai.com> From: Derek Atkins Date: 07 Aug 2001 08:25:03 -0400 In-Reply-To: "Mason, David"'s message of "Mon, 6 Aug 2001 12:28:04 -0700" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk They never were included in the moratorium. -derek "Mason, David" writes: > Is it true that the NAT traversal IKE and IPsec changes have been exempted > from the moratorium? > -dave -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Aug 7 08:38:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77Fc9N22835; Tue, 7 Aug 2001 08:38:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12005 Tue, 7 Aug 2001 10:18:56 -0400 (EDT) From: Bill Manning Message-Id: <200108071425.f77EPrl19554@zed.isi.edu> Subject: Re: Wes Hardaker: opportunistic encryption deployment problems To: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Tue, 7 Aug 2001 07:25:53 -0700 (PDT) Cc: pbaker@verisign.com (Hallam-Baker Phillip), hugh@road.xisp.net (Hugh Daniel), wes@hardakers.net, ipsec@lists.tislabs.com In-Reply-To: <200108070812.f778Cfu67935@givry.rennes.enst-bretagne.fr> from "Francis Dupont" at Aug 07, 2001 10:12:41 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One point. Instead of TXT records for stuffing bits into, there is the CERT record which was designed for just such stuff. Well, two points. If folks want to kick the tyres on such a beast, I've a couple of servers w/ signed in-addr.arpa zones. -- --bill From owner-ipsec@lists.tislabs.com Tue Aug 7 08:38:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77FcCN22908; Tue, 7 Aug 2001 08:38:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11988 Tue, 7 Aug 2001 10:17:28 -0400 (EDT) Message-Id: <200108071423.f77ENEg00553@dharkins@lounge.orgatty.lounge.org> To: Alex Alten Cc: Kory Hamzeh , "Hallam-Baker, Phillip" , "'mcnelson@mindspring.com'" , ipsec@lists.tislabs.com Subject: Re: IKE must have no Heirs In-Reply-To: Your message of "Tue, 07 Aug 2001 00:28:20 PDT." <3.0.3.32.20010807002820.010a77f8@mail> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <550.997194194.1@lounge.org> Date: Tue, 07 Aug 2001 07:23:14 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It was called SKIP. I suggest you guys familiarize yourselves with this WG. Dan. On Tue, 07 Aug 2001 00:28:20 PDT you wrote > > I second the motion. And also propose no port number (i.e. do the new > one over raw IP). > > - Alex > > At 11:07 PM 8/6/2001 -0700, Kory Hamzeh wrote: > > > >Well said. I agree with you 100%. Throw is out and let's start from > >scratch with something more reasonable and realistic. > > > >Kory > > > > > >On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote: > > > >> > >> > Unfortunately the notion that IPsec should simply \"bind > >> > a key to an IP address\" was rejected repeatedly throughout > >> > the history of the IPsec WG. > >> > >> This is why I think we have to stop talking about 'son of IKE' > >> as if the problem was in the 7 years and 9 months of trying to > >> implement the requirements and not the 3 months of requirements > >> capture. > >> > >> [ ..... ] > >> > >> From here there are two routes forward. We could specify a reduced > >> IKE, eliminating all but 2 of the current 8 modes, simplifying the > >> negotiation, knife AH... to result in a simpler draft that we can be > >> confident would get a broad review. I think that would have been an > >> excellent idea three years ago, I think that it is too late after > >> the interop tests have been performed. All that would come out > >> is a description of a profile of the current spec that resulted > >> in one configuration that was secure. But implementations would > >> still be constrained by the existing legacy base which would > >> drag deployments back into the mire of unexamined code paths and > >> unanticipated interactions. > >> > >> The second is to burn the current drafts and start from scratch > >> with a fresh port number. If any change is made that breaks > >> backwards compatibility then this might as well be what you do. > >> > >> In short the phrase 'Son of IKE' is part of the problem, not > >> the solution. IKE must have no heirs, it is time for a new dynasty > >> to take the throne. > >> > >> > >> Phill > >> > >> > > > > > -- > > Alex Alten > > Alten@Home.Com > > From owner-ipsec@lists.tislabs.com Tue Aug 7 08:57:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77FvNN03449; Tue, 7 Aug 2001 08:57:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12154 Tue, 7 Aug 2001 11:13:19 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15215.65528.400728.281853@thomasm-u1.cisco.com> Date: Tue, 7 Aug 2001 07:49:28 -0700 (PDT) To: Alex Alten Cc: Chris Trobridge , ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs In-Reply-To: <3.0.3.32.20010807020559.00d89980@mail> References: <3.0.3.32.20010807020559.00d89980@mail> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten writes: > Think about it. Do you do OSPF over IP and then BGP over UDP? > The same applies to IPSEC and key management. OK, I thought about it. I still don't get it. Mike > > - Alex > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > >> -----Original Message----- > >> From: Alex Alten [mailto:Alten@home.com] > >> Sent: 07 August 2001 08:28 > >> To: Kory Hamzeh; Hallam-Baker, Phillip > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > >> Subject: Re: IKE must have no Heirs > >> > >> > >> > >> I second the motion. And also propose no port number (i.e. do the new > >> one over raw IP). > >> > >> - Alex > > > >What would that achieve? (communicating over raw IP) > > > >Chris > > > > > >--------------------------------------------------------------------------- > -------------------------------------- > >The information contained in this message is confidential and is intended > >for the addressee(s) only. If you have received this message in error or > >there are any problems please notify the originator immediately. The > >unauthorized use, disclosure, copying or alteration of this message is > >strictly forbidden. Baltimore Technologies plc will not be liable for > direct, > >special, indirect or consequential damages arising from alteration of the > >contents of this message by a third party or as a result of any virus being > >passed on. > > > >In addition, certain Marketing collateral may be added from time to time to > >promote Baltimore Technologies products, services, Global e-Security or > >appearance at trade shows and conferences. > > > >This footnote confirms that this email message has been swept by > >Baltimore MIMEsweeper for Content Security threats, including > >computer viruses. > > > > > -- > > Alex Alten > > Alten@Home.Com > > From owner-ipsec@lists.tislabs.com Tue Aug 7 09:57:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77GvLN04920; Tue, 7 Aug 2001 09:57:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12327 Tue, 7 Aug 2001 11:51:06 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA51@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dan Harkins'" , Alex Alten Cc: Kory Hamzeh , "Hallam-Baker, Phillip" , "'mcnelson@mindspring.com'" , ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs Date: Tue, 7 Aug 2001 08:56:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11F59.93D58940" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11F59.93D58940 Content-Type: text/plain; charset="iso-8859-1" Dan, It has been somewhat difficult for anyone in the IETF security area in the past dacade not to become familliar with the internal machinations of the IPSEC group. I would like something no more complex than SKIP that used RSA or DSA. In 1995 SKIP would have been the right move. At this point to go forward there has to at least be compatibility with the keying material that is already distributed. I would also like to see a more analytical approach to demonstrating the correctness and security of the protocol. Something that was at least simple enough to be the subject of a proof. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Tuesday, August 07, 2001 10:23 AM > To: Alex Alten > Cc: Kory Hamzeh; Hallam-Baker, Phillip; 'mcnelson@mindspring.com'; > ipsec@lists.tislabs.com > Subject: Re: IKE must have no Heirs > > > It was called SKIP. I suggest you guys familiarize yourselves with > this WG. > > Dan. > > On Tue, 07 Aug 2001 00:28:20 PDT you wrote > > > > I second the motion. And also propose no port number (i.e. > do the new > > one over raw IP). > > > > - Alex > > > > At 11:07 PM 8/6/2001 -0700, Kory Hamzeh wrote: > > > > > >Well said. I agree with you 100%. Throw is out and let's start from > > >scratch with something more reasonable and realistic. > > > > > >Kory > > > > > > > > >On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote: > > > > > >> > > >> > Unfortunately the notion that IPsec should simply \"bind > > >> > a key to an IP address\" was rejected repeatedly throughout > > >> > the history of the IPsec WG. > > >> > > >> This is why I think we have to stop talking about 'son of IKE' > > >> as if the problem was in the 7 years and 9 months of trying to > > >> implement the requirements and not the 3 months of requirements > > >> capture. > > >> > > >> [ ..... ] > > >> > > >> From here there are two routes forward. We could specify > a reduced > > >> IKE, eliminating all but 2 of the current 8 modes, > simplifying the > > >> negotiation, knife AH... to result in a simpler draft > that we can be > > >> confident would get a broad review. I think that would > have been an > > >> excellent idea three years ago, I think that it is too late after > > >> the interop tests have been performed. All that would come out > > >> is a description of a profile of the current spec that resulted > > >> in one configuration that was secure. But implementations would > > >> still be constrained by the existing legacy base which would > > >> drag deployments back into the mire of unexamined code paths and > > >> unanticipated interactions. > > >> > > >> The second is to burn the current drafts and start from scratch > > >> with a fresh port number. If any change is made that breaks > > >> backwards compatibility then this might as well be what you do. > > >> > > >> In short the phrase 'Son of IKE' is part of the problem, not > > >> the solution. IKE must have no heirs, it is time for a > new dynasty > > >> to take the throne. > > >> > > >> > > >> Phill > > >> > > >> > > > > > > > > -- > > > > Alex Alten > > > > Alten@Home.Com > > > > > ------_=_NextPart_000_01C11F59.93D58940 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C11F59.93D58940-- From owner-ipsec@lists.tislabs.com Tue Aug 7 10:17:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77HH6N05536; Tue, 7 Aug 2001 10:17:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12442 Tue, 7 Aug 2001 12:21:39 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15216.5899.191140.121446@thomasm-u1.cisco.com> Date: Tue, 7 Aug 2001 09:27:55 -0700 (PDT) To: Bill Manning Cc: Francis.Dupont@enst-bretagne.fr (Francis Dupont), pbaker@verisign.com (Hallam-Baker Phillip), hugh@road.xisp.net (Hugh Daniel), wes@hardakers.net, ipsec@lists.tislabs.com Subject: Re: Wes Hardaker: opportunistic encryption deployment problems In-Reply-To: <200108071425.f77EPrl19554@zed.isi.edu> References: <200108070812.f778Cfu67935@givry.rennes.enst-bretagne.fr> <200108071425.f77EPrl19554@zed.isi.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I guess I have to ask a really dumb question. Given the likelihood of DNSSEC any time soon, why don't we just ignore any pretense of authentication with opportunistic encryption and just accept the MITM attack inherent with ephemeral DH exchanges? Also: it seems to me that expecting a secure DNS isn't actually opportunistic at all: it's trying to assert a different source of (sometimes strong) identity, which obviously runs afoul of the mythical global PKI, which leads back to point one. I think there's some utility to crypto which accepts MITM as better than nothing at all which is the current reality. Mike Bill Manning writes: > > One point. Instead of TXT records for stuffing bits into, there is the CERT record > which was designed for just such stuff. > Well, two points. If folks want to kick the tyres on such a beast, I've a couple > of servers w/ signed in-addr.arpa zones. > > > -- > --bill From owner-ipsec@lists.tislabs.com Tue Aug 7 10:23:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77HNIN05649; Tue, 7 Aug 2001 10:23:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12459 Tue, 7 Aug 2001 12:30:34 -0400 (EDT) Date: Tue, 7 Aug 2001 09:36:31 -0700 (PDT) From: Kory Hamzeh To: Dan Harkins cc: Alex Alten , "Hallam-Baker, Phillip" , "'mcnelson@mindspring.com'" , ipsec@lists.tislabs.com Subject: Re: IKE must have no Heirs In-Reply-To: <200108071423.f77ENEg00553@dharkins@lounge.orgatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This will be my second (and last) e-mail on this thread because their are too many egos involved here. As an implementor of IPSEC & IKE, I can testify that IKE is confusion, convoluted, overly complicated,, and has security holes. There are papers written on this subject by people much more intelligent than myself who have come to the same conclusion. Kory On Tue, 7 Aug 2001, Dan Harkins wrote: > It was called SKIP. I suggest you guys familiarize yourselves with > this WG. > > Dan. > > On Tue, 07 Aug 2001 00:28:20 PDT you wrote > > > > I second the motion. And also propose no port number (i.e. do the new > > one over raw IP). > > > > - Alex > > > > At 11:07 PM 8/6/2001 -0700, Kory Hamzeh wrote: > > > > > >Well said. I agree with you 100%. Throw is out and let's start from > > >scratch with something more reasonable and realistic. > > > > > >Kory > > > > > > > > >On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote: > > > > > >> > > >> > Unfortunately the notion that IPsec should simply \"bind > > >> > a key to an IP address\" was rejected repeatedly throughout > > >> > the history of the IPsec WG. > > >> > > >> This is why I think we have to stop talking about 'son of IKE' > > >> as if the problem was in the 7 years and 9 months of trying to > > >> implement the requirements and not the 3 months of requirements > > >> capture. > > >> > > >> [ ..... ] > > >> > > >> From here there are two routes forward. We could specify a reduced > > >> IKE, eliminating all but 2 of the current 8 modes, simplifying the > > >> negotiation, knife AH... to result in a simpler draft that we can be > > >> confident would get a broad review. I think that would have been an > > >> excellent idea three years ago, I think that it is too late after > > >> the interop tests have been performed. All that would come out > > >> is a description of a profile of the current spec that resulted > > >> in one configuration that was secure. But implementations would > > >> still be constrained by the existing legacy base which would > > >> drag deployments back into the mire of unexamined code paths and > > >> unanticipated interactions. > > >> > > >> The second is to burn the current drafts and start from scratch > > >> with a fresh port number. If any change is made that breaks > > >> backwards compatibility then this might as well be what you do. > > >> > > >> In short the phrase 'Son of IKE' is part of the problem, not > > >> the solution. IKE must have no heirs, it is time for a new dynasty > > >> to take the throne. From owner-ipsec@lists.tislabs.com Tue Aug 7 11:32:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77IWBN07164; Tue, 7 Aug 2001 11:32:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12696 Tue, 7 Aug 2001 13:39:23 -0400 (EDT) Message-ID: From: "Horn, Mike" To: "'Alex Alten'" , Chris Trobridge Cc: ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs Date: Tue, 7 Aug 2001 10:38:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually that is a poor example, there is no built-in protocol dependency for BGP to use OSPF. And BGP does use TCP (port 179) for communication vs. OSPF using a protocol number (89). IPsec currently has a strong dependency on IKE. I do agree that from a network administration and debugging standpoint it would be nice if both IPsec and IKE shared a common protocol number. This would help to simplify firewall configurations, etc. Mike Horn > -----Original Message----- > From: Alex Alten [mailto:Alten@home.com] > Sent: Tuesday, August 07, 2001 3:06 AM > To: Chris Trobridge > Cc: ipsec@lists.tislabs.com > Subject: RE: IKE must have no Heirs > > > Think about it. Do you do OSPF over IP and then BGP over UDP? > The same applies to IPSEC and key management. > > - Alex > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > >> -----Original Message----- > >> From: Alex Alten [mailto:Alten@home.com] > >> Sent: 07 August 2001 08:28 > >> To: Kory Hamzeh; Hallam-Baker, Phillip > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > >> Subject: Re: IKE must have no Heirs > >> > >> > >> > >> I second the motion. And also propose no port number (i.e. > do the new > >> one over raw IP). > >> > >> - Alex > > > >What would that achieve? (communicating over raw IP) > > > >Chris > > > > > >------------------------------------------------------------- > -------------- > -------------------------------------- > >The information contained in this message is confidential > and is intended > >for the addressee(s) only. If you have received this > message in error or > >there are any problems please notify the originator > immediately. The > >unauthorized use, disclosure, copying or alteration of this > message is > >strictly forbidden. Baltimore Technologies plc will not be liable for > direct, > >special, indirect or consequential damages arising from > alteration of the > >contents of this message by a third party or as a result of > any virus being > >passed on. > > > >In addition, certain Marketing collateral may be added from > time to time to > >promote Baltimore Technologies products, services, Global > e-Security or > >appearance at trade shows and conferences. > > > >This footnote confirms that this email message has been swept by > >Baltimore MIMEsweeper for Content Security threats, including > >computer viruses. > > > > > -- > > Alex Alten > > Alten@Home.Com > > From owner-ipsec@lists.tislabs.com Tue Aug 7 11:35:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77IZVN07208; Tue, 7 Aug 2001 11:35:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12712 Tue, 7 Aug 2001 13:40:24 -0400 (EDT) Message-ID: From: "Horn, Mike" To: "'Scott Fanning'" , Chris Trobridge , Alex Alten Cc: ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs Date: Tue, 7 Aug 2001 10:54:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > So, what do we propose to those that are using IKE right now (like > customers). Oops, sorry, its too complex. Maybe next time? > This is precisely why many vendors will probably not move to a simplified IKE implementation that adds no new features. Once the vendors have been through the pain of getting the interoperability issues resolved, why would they attempt to cut out major sections of working code? IMHO, the only group that a simplified IKE implementation helps is vendors looking to deploy their first implementation of IKE. If the simplified IKE also added some critical new features which many vendors have already deployed proprietary solutions for (NAT traversal, user authentication, keepalives, etc.) then vendors might have some motivation to re-code existing implemenations with a new standardized version. > I suggest that we look at the documents that describe the > improvements, and > ask the implementors (the ones confused by the complexity) > how the standards > body can work to make their job easier (A clearly defined > state machine > would be nice, with less SHOULDs' and more MUSTs). > > Also, any changes should keep in mind an easy transition to > "Son of Ike" so > that deploying the less complex version of IKE, does not create more > complexity. > I think users will only deploy Son of IKE if it solves all the open requirements, not if it just simplifies IKE and adds a single feature like NAT traversal. There seems to be a big rift between what the IPSEC and IPSRA WGs are doing, and what the vendors are doing on their own. Mike Horn > Scott > ----- Original Message ----- > From: "Alex Alten" > To: "Chris Trobridge" > Cc: > Sent: Tuesday, August 07, 2001 2:05 AM > Subject: RE: IKE must have no Heirs > > > > Think about it. Do you do OSPF over IP and then BGP over UDP? > > The same applies to IPSEC and key management. > > > > - Alex > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > > > > >> -----Original Message----- > > >> From: Alex Alten [mailto:Alten@home.com] > > >> Sent: 07 August 2001 08:28 > > >> To: Kory Hamzeh; Hallam-Baker, Phillip > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > > >> Subject: Re: IKE must have no Heirs > > >> > > >> > > >> > > >> I second the motion. And also propose no port number > (i.e. do the new > > >> one over raw IP). > > >> > > >> - Alex > > > > > >What would that achieve? (communicating over raw IP) > > > > > >Chris > > > > > > > > > >------------------------------------------------------------- > -------------- > > -------------------------------------- > > >The information contained in this message is confidential > and is intended > > >for the addressee(s) only. If you have received this > message in error or > > >there are any problems please notify the originator > immediately. The > > >unauthorized use, disclosure, copying or alteration of > this message is > > >strictly forbidden. Baltimore Technologies plc will not be > liable for > > direct, > > >special, indirect or consequential damages arising from > alteration of the > > >contents of this message by a third party or as a result > of any virus > being > > >passed on. > > > > > >In addition, certain Marketing collateral may be added > from time to time > to > > >promote Baltimore Technologies products, services, Global > e-Security or > > >appearance at trade shows and conferences. > > > > > >This footnote confirms that this email message has been swept by > > >Baltimore MIMEsweeper for Content Security threats, including > > >computer viruses. > > > > > > > > -- > > > > Alex Alten > > > > Alten@Home.Com > > > > > From owner-ipsec@lists.tislabs.com Tue Aug 7 11:45:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77IjoN07388; Tue, 7 Aug 2001 11:45:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12697 Tue, 7 Aug 2001 13:39:29 -0400 (EDT) Message-ID: From: "Horn, Mike" To: "'sommerfeld@east.sun.com'" Cc: "'Theodore Tso'" , Andrew Krywaniuk , "'Alex Alten'" , "'Marcus Leech'" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Position statement on IKE development Date: Tue, 7 Aug 2001 10:06:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Having everyone eventually migrate to certificates would be nice from a theoretical viewpoint, but the reality is that there are VPN customers who will _never_ move to a certificate based infrastructure. As a VPN service provider, we see plenty of small customers who simply want their VPN authentication proxied to their existing RADIUS/NT/etc server(s). This is why it's critical to have a long term user authentication mechanism for IPsec. Mike Horn > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Monday, August 06, 2001 6:41 PM > To: Horn, Mike > Cc: 'Theodore Tso'; Andrew Krywaniuk; 'Alex Alten'; 'Marcus Leech'; > ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org > Subject: Re: Position statement on IKE development > > > > One of the reasons various user authentication schemes have not been > > considered (CRACK for instance) is the moratorium on changes to IKE. > > Unfortunately the IPSRA WG is very dependent on IKE. > > The IPSRA WG is not at all dependant on IKE; it's really all about > protocols to turn legacy authentication into certificates.. > > - Bill > From owner-ipsec@lists.tislabs.com Tue Aug 7 12:15:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77JFfN08016; Tue, 7 Aug 2001 12:15:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12900 Tue, 7 Aug 2001 14:32:15 -0400 (EDT) Date: Tue, 7 Aug 2001 12:49:05 -0600 From: Shane Amante To: "Horn, Mike" Cc: "'Theodore Tso'" , Andrew Krywaniuk , "'Alex Alten'" , "'Marcus Leech'" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Position statement on IKE development Message-ID: <20010807124904.A3681@traveller.amante.org> Mail-Followup-To: "Horn, Mike" , 'Theodore Tso' , Andrew Krywaniuk , 'Alex Alten' , 'Marcus Leech' , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mhorn@virtela.net on Mon, Aug 06, 2001 at 06:03:08PM -0600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Aug 06, 2001 at 06:03:08PM -0600, Horn, Mike wrote: [-- snip --] > Perhaps a new requirements draft needs to be started, so that Son of IKE > does not suffer the same fate as IKE. IMHO, I think trying to make Son of > IKE "implementation preserving" is going to take Son of IKE down a very > familiar and ugly path. Starting out with a new port assignment, and > building from the ground up might be the only answer. There are obviously a > lot of lessons that have been learned the hard way which should serve to > greatly improve both the security and reduce the complexity of a next > generation key exchange protocol designed specifically for IPsec. Speaking from an operator's viewpoint, I have to agree with Mike and other posters in support of jumping over 'son-of-IKE' and, instead, launching a new initiative for a 'next-generation' IKE that is based on a clearly defined set of *requirements* from the operator and implementor community. In fact, starting with *requirements draft* BEFORE 'son-of-IKE' would be immensely helpful in gathering consensus on whether it is even worth it to do 'son-of-IKE' or just jump over it and start from scratch. As a good friend and colleague says: "You've got to define a target before you can aim at it; otherwise, you'll never hit anything." Right now, I have a hard time seeing how painting some broad strokes of: a) simplify IKE; and, b) possibly add these other arbitrary "enhancements" will lead to anything but delaying the inevitable opening up the can-of-worms that is re-vamping IKE from the ground up so it has extensibility and future-proofing. The bottom-line is the current proposals on the table really only addresses two thirds of the problems I see in the real-world today. Specifically, 1) simplification of IKE; and, 2) NAT-traversal. What it doesn't address is: 3) remote-access/legacy-authentication issues, which in all fairness, has been stated "will be worked on later" while IPSRA is also valiantly attempting to come up with a solution today. Ultimately, it boils down to the fact that, as an operator, I'd much rather see a comprehensive solution developed that addresses all three concerns than have to deploy 'son-of-IKE' and then, some time later, either 'son-of-IKE++' or 'next-gen-IKE' that finally captures all of my customer's needs. Anyway, just my $0.02 ... -shane From owner-ipsec@lists.tislabs.com Tue Aug 7 12:39:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77JdVN08421; Tue, 7 Aug 2001 12:39:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13049 Tue, 7 Aug 2001 14:57:55 -0400 (EDT) Date: Tue, 7 Aug 2001 15:04:12 -0400 (EDT) From: Henry Spencer To: Wes Hardaker cc: Hugh Daniel , ipsec@lists.tislabs.com Subject: Re: opportunistic encryption deployment problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 6 Aug 2001, Wes Hardaker wrote: > 3 problems I see with the deployment of opportunistic encryption: > 1) your method of obtaining information is by reverse DNS lookup, > which will provide problems with people who can't control their > reverse DNS bindings... Agreed. We have some ideas on handling that, but the feedback we're getting is that it's an even bigger problem than we thought. Sigh. The central difficulty is that at the time we need to figure out who to negotiate with and how to authenticate them, we have *no* information other than the IP address of the ultimate destination. It's hard to avoid starting with a reverse lookup in that situation. Trying to finesse this by setting up a new tree parallel to the current inet-addr.arpa reverse tree doesn't seem to really solve anything, alas -- if you follow through all the implications (e.g., how do you decide who is allowed to update parts of that tree?), you find you have just re-invented inet-addr.arpa, duplicating all its overheads without actually solving any of its problems. At least, that's the way it looked when I analyzed this option a while back. The one possible way out of this is that 99.9% of the time, that IP address was itself obtained by a very recent DNS lookup of a name, and so it would be workable to associate the information with that name instead. Trouble is, there's no way to ask a DNS server for that! We need to be able to ask "what name did you recently map into address a.b.c.d, and what else did you learn in that lookup?" (since DNSSEC-aware name servers try to return KEY records along with A records). There sort of is a way to do that -- inverse queries -- but it is excessively general, and as a result nobody implements it and it's increasingly considered obsolete. > 2) your method of obtaining information is by reverse DNS lookup, > which will provide problems with people behind NATs. Indeed so... but those people are going to have some difficulty using IPsec anyway, since IPsec does not get along well with NAT. Also, NAT is just plain evil, "a botch and a blemish". That aside, we do have some notions about how to handle this, although I don't think they made it into the -01 draft (which was done in great haste). It's somewhat the same situation as a Road Warrior, which can be using an IP address it does not "own". The answer is that (a) it must originate the call, since there is no way to call in to it, (b) it must supply enough information via ID payloads to point the other end to DNS entries for it, and (c) the NAT machinery has to be sufficiently aware of the situation to NAT things properly. (Given (c), it is basically the same as Road Warrior.) This is not ideal, but with an atrocity like NAT obstructing your network access, there is inherently no graceful way. > 3) The wider and wider spread use of things like web and other proxies > will provide similar problems seen in #2. Such "stupid packet tricks" do indeed interfere with your use of the Internet. Fortunately, encryption prevents most of them anyway, so widespread opportunistic encryption will make them obsolete. (The proxy may intercept your HTTP packets if they go out as plaintext, but there's not much it can do when they're hidden inside encrypted ESP packets.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Aug 7 12:40:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77JeKN08453; Tue, 7 Aug 2001 12:40:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12961 Tue, 7 Aug 2001 14:46:08 -0400 (EDT) Message-Id: <4.3.2.7.0.20010807132741.00b8d318@STPNTMX03.sctc.com> X-Sender: smith@STPNTMX03.sctc.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 13:49:00 -0500 To: Alex Alten , Kory Hamzeh , "Hallam-Baker, Phillip" From: Rick Smith at Secure Computing Subject: Re: IKE must have no Heirs Cc: "'mcnelson@mindspring.com'" , ipsec@lists.tislabs.com In-Reply-To: <3.0.3.32.20010807002820.010a77f8@mail> References: <2F3EC696EAEED311BB2D009027C3F4F40154CA4C@vhqpostal.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 02:28 AM 8/7/2001, Alex Alten wrote: >I second the motion. And also propose no port number (i.e. do the new >one over raw IP). There is a benefit to this approach if, in some future universe, we ever try to implement a protocol stack using least privilege to maximize security assurance. It gives us an easy way of putting all parts of IPsec within the same trust boundary and of keeping it better separated from other protocol processing. Otherwise you are stuck with a uniform level of trust for all of the software in the protocol stack, crypto and non-crypto, including the mechanism that binds ports to processes. I know, this isn't a problem today because protocol stacks run in kernel mode and therefore we (have no other choice but to) "trust" the entire protocol stack. It is, of course, feasible to ignore the issues of incremental trust and/or build additional mechanisms to bring together what is built asunder. But it seems cleaner, design-wise, to keep the key management close to the code that actually uses the resulting keys. Rick. smith@securecomputing.com From owner-ipsec@lists.tislabs.com Tue Aug 7 13:23:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77KNZN09111; Tue, 7 Aug 2001 13:23:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13224 Tue, 7 Aug 2001 15:33:32 -0400 (EDT) Date: Tue, 7 Aug 2001 13:51:17 -0600 From: Shane Amante To: "Horn, Mike" Cc: "'Shane Amante'" , "'Theodore Tso'" , Andrew Krywaniuk , "'Alex Alten'" , "'Marcus Leech'" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: Position statement on IKE development Message-ID: <20010807135117.A3844@traveller.amante.org> Mail-Followup-To: "Horn, Mike" , 'Shane Amante' , 'Theodore Tso' , Andrew Krywaniuk , 'Alex Alten' , 'Marcus Leech' , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mhorn@virtela.net on Tue, Aug 07, 2001 at 01:01:34PM -0600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On the one hand, I agree with Paul that these aren't part of the base IKE spec (as it stands today) and, unfortunately, there's nothing IPSRA will be able to do to address them. So, are we to assume that the IPSEC WG is responsible for these things? Judging from the "IKE Position Statement" and follow-up e-mails, it sounds as if item #1 are to be addressed immediately, while #3 is to be addressed, possibly, later in 'son-of-IKE'. However, that leaves item #2, which I agree with you, should be standardized in IPSec and IS NOT only "an application issue". So, I have to ask: who is keeping track of these, and other requirements, at what point they will be addressed and where is it all documented? It seems to me to be good common, and engineering, sense to put in a draft all the requirements for what we want out of a 'son-of-IKE' and 'next-gen-IKE'. Then, we can compare the two requirements docs side-by-side and judge which proposal meets the needs of the community best. -shane On Tue, Aug 07, 2001 at 01:01:34PM -0600, Horn, Mike wrote: > > > > Speaking from an operator's viewpoint, I have to agree with Mike and > > other posters in support of jumping over 'son-of-IKE' and, instead, > > launching a new initiative for a 'next-generation' IKE that is based > > on a clearly defined set of *requirements* from the operator and > > implementor community. In fact, starting with *requirements draft* > > BEFORE 'son-of-IKE' would be immensely helpful in gathering consensus > > on whether it is even worth it to do 'son-of-IKE' or just jump over it > > and start from scratch. > > I tried to get additional requirements added to the IPSRA requirements > document, but I was told things like keepalives were out of scope due to the > "no changes to IKE" requirements. These are some of the replies I got from > Paul Hoffman when I suggested additions to the requirements draft. > > Mike Horn: 1) The IRAS and IRAC SHOULD support NAT traversal. > Paul Hoffman: We don't yet have a standard for that. > Mike Horn: 2) The IRAC SHOULD support redundant gateways. > Paul Hoffman: This is an application issue, not a protocol issue. > Mike Horn: 3) The IRAS and IRAC SHOULD support a keepalive or make dead > mechanism. > Paul Hoffman: We don't yet have a standard for that. > > I thought the point of a requirements draft was to clearly define the things > that need solutions, not how to use existing solutions. > > Mike Horn From owner-ipsec@lists.tislabs.com Tue Aug 7 13:34:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77KYIN10539; Tue, 7 Aug 2001 13:34:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13298 Tue, 7 Aug 2001 15:52:23 -0400 (EDT) Message-ID: From: "Horn, Mike" To: "'Shane Amante'" Cc: "'Theodore Tso'" , Andrew Krywaniuk , "'Alex Alten'" , "'Marcus Leech'" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Position statement on IKE development Date: Tue, 7 Aug 2001 13:01:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Speaking from an operator's viewpoint, I have to agree with Mike and > other posters in support of jumping over 'son-of-IKE' and, instead, > launching a new initiative for a 'next-generation' IKE that is based > on a clearly defined set of *requirements* from the operator and > implementor community. In fact, starting with *requirements draft* > BEFORE 'son-of-IKE' would be immensely helpful in gathering consensus > on whether it is even worth it to do 'son-of-IKE' or just jump over it > and start from scratch. I tried to get additional requirements added to the IPSRA requirements document, but I was told things like keepalives were out of scope due to the "no changes to IKE" requirements. These are some of the replies I got from Paul Hoffman when I suggested additions to the requirements draft. Mike Horn: 1) The IRAS and IRAC SHOULD support NAT traversal. Paul Hoffman: We don't yet have a standard for that. Mike Horn: 2) The IRAC SHOULD support redundant gateways. Paul Hoffman: This is an application issue, not a protocol issue. Mike Horn: 3) The IRAS and IRAC SHOULD support a keepalive or make dead mechanism. Paul Hoffman: We don't yet have a standard for that. I thought the point of a requirements draft was to clearly define the things that need solutions, not how to use existing solutions. Mike Horn From owner-ipsec@lists.tislabs.com Tue Aug 7 13:39:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77KdKN10587; Tue, 7 Aug 2001 13:39:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13331 Tue, 7 Aug 2001 16:02:13 -0400 (EDT) Date: Tue, 7 Aug 2001 16:08:03 -0400 (EDT) From: Henry Spencer To: "Hallam-Baker, Phillip" cc: Hugh Daniel , ipsec@lists.tislabs.com Subject: RE: Wes Hardaker: opportunistic encryption deployment problems In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40154CA4B@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote: > In particular reverse DNS is not much use when the target does not > have a DNS address. This is the case for the vast majority of DCHP > hosted home Internet hookups. Remember that with continuous connectivity, your provider gains nothing by not assigning you a permanent address -- there is no longer any possibility of sharing a small pool of addresses among a large number of users. Not all providers have figured this out yet, but it's coming. (Most of Toronto's ADSL providers will give you a static IP address for a small extra fee.) Getting stuff into the reverse map is more challenging, admittedly, especially if you're dealing with a big stupid provider. > I would not rely on any outcome being achieved as a byproduct of > DNSSEC... In other words, we can't ever rely on DNS being secure? Come now. Admittedly, there are obstacles between here and there, but it is still the right solution for a number of problems. Solving its remaining difficulties is a better investment of time than inventing half-baked alternatives. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Aug 7 13:44:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77KiNN10661; Tue, 7 Aug 2001 13:44:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13350 Tue, 7 Aug 2001 16:06:22 -0400 (EDT) Date: Tue, 7 Aug 2001 16:12:28 -0400 (EDT) From: Henry Spencer To: Bill Manning cc: Hugh Daniel , ipsec@lists.tislabs.com, FreeS/WAN Design Issues Subject: Re: Wes Hardaker: opportunistic encryption deployment problems In-Reply-To: <200108071425.f77EPrl19554@zed.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 Aug 2001, Bill Manning wrote: > One point. Instead of TXT records for stuffing bits into, there is > the CERT record which was designed for just such stuff. Well, for small values of "designed". :-) CERT itself is fine; the problem is that the stuff inside it is X.509, which we have been resisting getting involved with. We chose TXT because we simply wanted to convey a gateway address and a key, and we wanted to parse it with 10 lines of code, not 10,000. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Aug 7 13:53:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77Kr2N10785; Tue, 7 Aug 2001 13:53:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13414 Tue, 7 Aug 2001 16:14:10 -0400 (EDT) Date: Tue, 7 Aug 2001 16:20:21 -0400 (EDT) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com, FreeS/WAN Design Issues Subject: Re: Wes Hardaker: opportunistic encryption deployment problems In-Reply-To: <15216.5899.191140.121446@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 Aug 2001, Michael Thomas wrote: > I guess I have to ask a really dumb question. Given the > likelihood of DNSSEC any time soon, why don't we just > ignore any pretense of authentication with opportunistic > encryption and just accept the MITM attack inherent with > ephemeral DH exchanges? We thought about that, but decided that some authentication was better than none, especially since it would upgrade transparently to full authentication. It's one thing to accept security loopholes as a temporary measure, and another to define a protocol that will always have security loopholes. > Also: it seems to me that expecting > a secure DNS isn't actually opportunistic at all: it's > trying to assert a different source of (sometimes strong) identity... This basically boils down to what you think "opportunistic" means. We don't see it as meaning "will talk to anybody, no setup necessary" but rather "will talk to anybody who's set up for it". Some amount of setup is clearly necessary anyway; we'd have liked to be able to talk to an IPsec-capable host that's unaware of opportunistic encryption, but it isn't possible. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Aug 7 14:57:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77LveN11754; Tue, 7 Aug 2001 14:57:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13557 Tue, 7 Aug 2001 17:00:19 -0400 (EDT) Date: Tue, 7 Aug 2001 14:07:37 -0700 (PDT) Message-Id: <200108072107.OAA10431@potomac.incog.com> From: Mike Ditto To: angelos@coredump.cis.upenn.edu CC: ipsec@lists.tislabs.com In-reply-to: <200108070821.f778LRR18797@nyarlathotep.keromytis.org> (angelos@coredump.cis.upenn.edu) Subject: Re: Phase 1 IDs ("son of IKE") Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: "Angelos D. Keromytis" > > >But if the identity hint was used as an abstract name, rather than the > >exact identity that the responder is expected to use, it could be used > >as a kind of generic "scope" or "role" identifier. > > My concern with this is that it's more complicated than the simple case of > "here's what I'd like you to use", both in terms of semantics, effort that > has to go in specs, and code. I don't think it's more complicated. Instead of saying "the responder must ignore the hint or use it as the value of the subsequent IDir payload," you say "the responder may use the hint in an implementation-defined way to influence its selection of its own identity." It would be important that the initiator have two distinct policy parameters: one to specify what remote identities will be accepted from the responder (regardless of whether it chooses to use the hint) and another to specify the hint to be sent. This is because, as I said, the initiator's policy language for specifying acceptable remote identities may not have a simple representation as an ISAKMP identification payload. -=] Mike [=- From owner-ipsec@lists.tislabs.com Tue Aug 7 15:00:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77M07N11803; Tue, 7 Aug 2001 15:00:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13614 Tue, 7 Aug 2001 17:23:55 -0400 (EDT) To: "Horn, Mike" Cc: "'Alex Alten'" , Chris Trobridge , ipsec@lists.tislabs.com Subject: Re: IKE must have no Heirs References: From: Derek Atkins Date: 07 Aug 2001 17:30:13 -0400 In-Reply-To: "Horn, Mike"'s message of "Tue, 7 Aug 2001 10:38:08 -0600" Message-ID: Lines: 101 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is no IPsec (ESP/AH) dependency on IKE. You can key manually (which does not use IKE). There is the KINK work, is different than IKE. There is no reason to turn IKE into it's own IP Protocol. Using UDP/500 works just fine, and making it's own protocol wont accomplish anything. -derek "Horn, Mike" writes: > Actually that is a poor example, there is no built-in protocol dependency > for BGP to use OSPF. And BGP does use TCP (port 179) for communication vs. > OSPF using a protocol number (89). IPsec currently has a strong dependency > on IKE. I do agree that from a network administration and debugging > standpoint it would be nice if both IPsec and IKE shared a common protocol > number. This would help to simplify firewall configurations, etc. > > Mike Horn > > > -----Original Message----- > > From: Alex Alten [mailto:Alten@home.com] > > Sent: Tuesday, August 07, 2001 3:06 AM > > To: Chris Trobridge > > Cc: ipsec@lists.tislabs.com > > Subject: RE: IKE must have no Heirs > > > > > > Think about it. Do you do OSPF over IP and then BGP over UDP? > > The same applies to IPSEC and key management. > > > > - Alex > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > > > > >> -----Original Message----- > > >> From: Alex Alten [mailto:Alten@home.com] > > >> Sent: 07 August 2001 08:28 > > >> To: Kory Hamzeh; Hallam-Baker, Phillip > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > > >> Subject: Re: IKE must have no Heirs > > >> > > >> > > >> > > >> I second the motion. And also propose no port number (i.e. > > do the new > > >> one over raw IP). > > >> > > >> - Alex > > > > > >What would that achieve? (communicating over raw IP) > > > > > >Chris > > > > > > > > >------------------------------------------------------------- > > -------------- > > -------------------------------------- > > >The information contained in this message is confidential > > and is intended > > >for the addressee(s) only. If you have received this > > message in error or > > >there are any problems please notify the originator > > immediately. The > > >unauthorized use, disclosure, copying or alteration of this > > message is > > >strictly forbidden. Baltimore Technologies plc will not be liable for > > direct, > > >special, indirect or consequential damages arising from > > alteration of the > > >contents of this message by a third party or as a result of > > any virus being > > >passed on. > > > > > >In addition, certain Marketing collateral may be added from > > time to time to > > >promote Baltimore Technologies products, services, Global > > e-Security or > > >appearance at trade shows and conferences. > > > > > >This footnote confirms that this email message has been swept by > > >Baltimore MIMEsweeper for Content Security threats, including > > >computer viruses. > > > > > > > > -- > > > > Alex Alten > > > > Alten@Home.Com > > > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Aug 7 15:01:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77M18N11830; Tue, 7 Aug 2001 15:01:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13622 Tue, 7 Aug 2001 17:26:37 -0400 (EDT) Message-ID: <3B705EAF.211B0942@storm.ca> Date: Tue, 07 Aug 2001 17:33:35 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Position statement on IKE development References: <3B69FF7B.85CF61@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I suspect if I knew more of the history, I wouldn't have to ask, but I seem to see a contradiction below. Marcus Leech wrote: > ... Formal and semi-formal analyses by Meadows, Schneier et al, and > Simpson, have shown that the security problems in IKE stem directly > from its complexity. ... > > We are concerned that trying to reuse too much of the IKE > code base in new protocols ... > will lead to more complex (and hence vulnerable) implementations. > We suggest that implementors resist this temptation, ... This makes sense. > The Security Area Directors have asked the IPSEC working group to come > up with a replacement for IKE. This work is underway and is known in > the community as "Son of IKE". ... So why are we working on "Son of IKE", which is presumably a new protocol and presumably re-uses much of IKE? Presumably there are good reasons we don't just say IKE was a mistake and switch to Simpson et al's simpler Photuris protocol. What are they? From owner-ipsec@lists.tislabs.com Tue Aug 7 15:45:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77MjkN12746; Tue, 7 Aug 2001 15:45:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13881 Tue, 7 Aug 2001 18:07:06 -0400 (EDT) Date: Tue, 7 Aug 2001 15:13:02 -0700 (PDT) From: Jan Vilhuber To: "Horn, Mike" cc: "'Alex Alten'" , Chris Trobridge , ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 Aug 2001, Horn, Mike wrote: > Actually that is a poor example, there is no built-in protocol dependency > for BGP to use OSPF. And BGP does use TCP (port 179) for communication vs. > OSPF using a protocol number (89). IPsec currently has a strong dependency > on IKE. I'm not sure I agree at all. IPSec wants keys. Where it gets these from, it doesn't really care. There's KINK and manual keying for example. Different keying protocols can be used (assuming they exist) and different keying protocols can have different features and security definitions (one's more secure against DOS/DDOS, another has less messages, another provides Identity protection at the expense of more messages, etc). I'm not proposing 10 new protocols, but I DO propose 2-3, as required by the non-overlapping requirements that have gotten us IKE. IPSec couldn't care less where it got the keys from. jan > I do agree that from a network administration and debugging > standpoint it would be nice if both IPsec and IKE shared a common protocol > number. This would help to simplify firewall configurations, etc. > > Mike Horn > > > -----Original Message----- > > From: Alex Alten [mailto:Alten@home.com] > > Sent: Tuesday, August 07, 2001 3:06 AM > > To: Chris Trobridge > > Cc: ipsec@lists.tislabs.com > > Subject: RE: IKE must have no Heirs > > > > > > Think about it. Do you do OSPF over IP and then BGP over UDP? > > The same applies to IPSEC and key management. > > > > - Alex > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > > > > >> -----Original Message----- > > >> From: Alex Alten [mailto:Alten@home.com] > > >> Sent: 07 August 2001 08:28 > > >> To: Kory Hamzeh; Hallam-Baker, Phillip > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > > >> Subject: Re: IKE must have no Heirs > > >> > > >> > > >> > > >> I second the motion. And also propose no port number (i.e. > > do the new > > >> one over raw IP). > > >> > > >> - Alex > > > > > >What would that achieve? (communicating over raw IP) > > > > > >Chris > > > > > > > > >------------------------------------------------------------- > > -------------- > > -------------------------------------- > > >The information contained in this message is confidential > > and is intended > > >for the addressee(s) only. If you have received this > > message in error or > > >there are any problems please notify the originator > > immediately. The > > >unauthorized use, disclosure, copying or alteration of this > > message is > > >strictly forbidden. Baltimore Technologies plc will not be liable for > > direct, > > >special, indirect or consequential damages arising from > > alteration of the > > >contents of this message by a third party or as a result of > > any virus being > > >passed on. > > > > > >In addition, certain Marketing collateral may be added from > > time to time to > > >promote Baltimore Technologies products, services, Global > > e-Security or > > >appearance at trade shows and conferences. > > > > > >This footnote confirms that this email message has been swept by > > >Baltimore MIMEsweeper for Content Security threats, including > > >computer viruses. > > > > > > > > -- > > > > Alex Alten > > > > Alten@Home.Com > > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Aug 7 16:09:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77N93N13478; Tue, 7 Aug 2001 16:09:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13915 Tue, 7 Aug 2001 18:23:54 -0400 (EDT) To: "Horn, Mike" Cc: ipsec@lists.tislabs.com Subject: Re: IKE must have no Heirs References: From: Derek Atkins Date: 07 Aug 2001 18:30:53 -0400 In-Reply-To: "Horn, Mike"'s message of "Tue, 7 Aug 2001 15:42:48 -0600" Message-ID: Lines: 141 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note the 'ipsec' has TWO protocol numbers... One for ESP and one for AH. What do _YOU_ mean? -derek "Horn, Mike" writes: > Again speaking from service provider experience, manual keys are not a > scalable option. Some sort of key exchange protocol is definitely required, > right now that means IKE. As for using a single IP protocol number for both > IKE and IPsec, I was merely stating this would reduce the number of > ports/protocols I have to request firewall administrators to allow. From an > operational perspective, dealing with IPsec devices behind firewalls can be > very painful. I will let this thread die, since the IPSEC and IPSRA working > groups face much bigger challenges then determining if IKE and IPsec should > share a protocol number. > > Mike Horn > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > Sent: Tuesday, August 07, 2001 3:30 PM > > To: Horn, Mike > > Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com > > Subject: Re: IKE must have no Heirs > > > > > > There is no IPsec (ESP/AH) dependency on IKE. You can key manually > > (which does not use IKE). There is the KINK work, is different than > > IKE. > > > > There is no reason to turn IKE into it's own IP Protocol. Using > > UDP/500 works just fine, and making it's own protocol wont accomplish > > anything. > > > > -derek > > > > "Horn, Mike" writes: > > > > > Actually that is a poor example, there is no built-in > > protocol dependency > > > for BGP to use OSPF. And BGP does use TCP (port 179) for > > communication vs. > > > OSPF using a protocol number (89). IPsec currently has a > > strong dependency > > > on IKE. I do agree that from a network administration and debugging > > > standpoint it would be nice if both IPsec and IKE shared a > > common protocol > > > number. This would help to simplify firewall configurations, etc. > > > > > > Mike Horn > > > > > > > -----Original Message----- > > > > From: Alex Alten [mailto:Alten@home.com] > > > > Sent: Tuesday, August 07, 2001 3:06 AM > > > > To: Chris Trobridge > > > > Cc: ipsec@lists.tislabs.com > > > > Subject: RE: IKE must have no Heirs > > > > > > > > > > > > Think about it. Do you do OSPF over IP and then BGP over UDP? > > > > The same applies to IPSEC and key management. > > > > > > > > - Alex > > > > > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Alex Alten [mailto:Alten@home.com] > > > > >> Sent: 07 August 2001 08:28 > > > > >> To: Kory Hamzeh; Hallam-Baker, Phillip > > > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > > > > >> Subject: Re: IKE must have no Heirs > > > > >> > > > > >> > > > > >> > > > > >> I second the motion. And also propose no port number (i.e. > > > > do the new > > > > >> one over raw IP). > > > > >> > > > > >> - Alex > > > > > > > > > >What would that achieve? (communicating over raw IP) > > > > > > > > > >Chris > > > > > > > > > > > > > > >------------------------------------------------------------- > > > > -------------- > > > > -------------------------------------- > > > > >The information contained in this message is confidential > > > > and is intended > > > > >for the addressee(s) only. If you have received this > > > > message in error or > > > > >there are any problems please notify the originator > > > > immediately. The > > > > >unauthorized use, disclosure, copying or alteration of this > > > > message is > > > > >strictly forbidden. Baltimore Technologies plc will not > > be liable for > > > > direct, > > > > >special, indirect or consequential damages arising from > > > > alteration of the > > > > >contents of this message by a third party or as a result of > > > > any virus being > > > > >passed on. > > > > > > > > > >In addition, certain Marketing collateral may be added from > > > > time to time to > > > > >promote Baltimore Technologies products, services, Global > > > > e-Security or > > > > >appearance at trade shows and conferences. > > > > > > > > > >This footnote confirms that this email message has been > > swept by > > > > >Baltimore MIMEsweeper for Content Security threats, including > > > > >computer viruses. > > > > > > > > > > > > > > -- > > > > > > > > Alex Alten > > > > > > > > Alten@Home.Com > > > > > > > > > > > > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Aug 7 16:23:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77NNsN13806; Tue, 7 Aug 2001 16:23:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13963 Tue, 7 Aug 2001 18:47:41 -0400 (EDT) To: "Horn, Mike" Cc: ipsec@lists.tislabs.com Subject: Re: IKE must have no Heirs References: From: Derek Atkins Date: 07 Aug 2001 18:54:44 -0400 In-Reply-To: "Horn, Mike"'s message of "Tue, 7 Aug 2001 16:48:00 -0600" Message-ID: Lines: 213 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First, all the world is not VPN. Second, there are alternate keying protocols (KINK, for example) Third, trying to move IKE to IP_PROTO 50 would not only be WRONG, it would also be HARD Fourth, moving IKE to IP_PROTO 50 would make NAT traversal EVEN HARDER than it already is. You clearly don't understand the problems. -derek "Horn, Mike" writes: > First, my only goal for being involved in this thread is that I think from > an operational standpoint the current state of IKE/IPsec is broken. There > are a LOT of features that have been added by various vendors in a > proprietary fashion to address these shortcomings. I think that the whole > VPN user community would benefit if the WG could come to some agreement and > produce a protocol (or set of protocols) to address the VPN user communities > needs. > > That being said, I thought there was general consensus that AH has not > proven to be useful, so I didn't include it in my original email. If you > know of _any_ service provider that is using AH for customer VPN's I would > be interested to hear who. Again, I'm simply stating that IF IKE is > replaced by something else, the WG should consider using the IPsec ESP > protocol number. > > I agree Jan's point that all IPsec requires is keys. Right now, the only > thing to my knowledge that is standardized for automated key exchange for > use by IPsec is IKE. If that is not fixable to meet the communities stated > requirements, then something new needs to be developed to fill this gap. > > I think that the lack of standardization for things like user > authentication, has definitely impacted the user community's acceptance of > IPsec. > > Mike Horn > > > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > Sent: Tuesday, August 07, 2001 4:31 PM > > To: Horn, Mike > > Cc: ipsec@lists.tislabs.com > > Subject: Re: IKE must have no Heirs > > > > > > Note the 'ipsec' has TWO protocol numbers... One for ESP and one for > > AH. What do _YOU_ mean? > > > > -derek > > > > "Horn, Mike" writes: > > > > > Again speaking from service provider experience, manual > > keys are not a > > > scalable option. Some sort of key exchange protocol is > > definitely required, > > > right now that means IKE. As for using a single IP > > protocol number for both > > > IKE and IPsec, I was merely stating this would reduce the number of > > > ports/protocols I have to request firewall administrators > > to allow. From an > > > operational perspective, dealing with IPsec devices behind > > firewalls can be > > > very painful. I will let this thread die, since the IPSEC > > and IPSRA working > > > groups face much bigger challenges then determining if IKE > > and IPsec should > > > share a protocol number. > > > > > > Mike Horn > > > > > > > -----Original Message----- > > > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > > > Sent: Tuesday, August 07, 2001 3:30 PM > > > > To: Horn, Mike > > > > Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com > > > > Subject: Re: IKE must have no Heirs > > > > > > > > > > > > There is no IPsec (ESP/AH) dependency on IKE. You can > > key manually > > > > (which does not use IKE). There is the KINK work, is > > different than > > > > IKE. > > > > > > > > There is no reason to turn IKE into it's own IP Protocol. Using > > > > UDP/500 works just fine, and making it's own protocol > > wont accomplish > > > > anything. > > > > > > > > -derek > > > > > > > > "Horn, Mike" writes: > > > > > > > > > Actually that is a poor example, there is no built-in > > > > protocol dependency > > > > > for BGP to use OSPF. And BGP does use TCP (port 179) for > > > > communication vs. > > > > > OSPF using a protocol number (89). IPsec currently has a > > > > strong dependency > > > > > on IKE. I do agree that from a network administration > > and debugging > > > > > standpoint it would be nice if both IPsec and IKE shared a > > > > common protocol > > > > > number. This would help to simplify firewall > > configurations, etc. > > > > > > > > > > Mike Horn > > > > > > > > > > > -----Original Message----- > > > > > > From: Alex Alten [mailto:Alten@home.com] > > > > > > Sent: Tuesday, August 07, 2001 3:06 AM > > > > > > To: Chris Trobridge > > > > > > Cc: ipsec@lists.tislabs.com > > > > > > Subject: RE: IKE must have no Heirs > > > > > > > > > > > > > > > > > > Think about it. Do you do OSPF over IP and then BGP > > over UDP? > > > > > > The same applies to IPSEC and key management. > > > > > > > > > > > > - Alex > > > > > > > > > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: Alex Alten [mailto:Alten@home.com] > > > > > > >> Sent: 07 August 2001 08:28 > > > > > > >> To: Kory Hamzeh; Hallam-Baker, Phillip > > > > > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > > > > > > >> Subject: Re: IKE must have no Heirs > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> I second the motion. And also propose no port > > number (i.e. > > > > > > do the new > > > > > > >> one over raw IP). > > > > > > >> > > > > > > >> - Alex > > > > > > > > > > > > > >What would that achieve? (communicating over raw IP) > > > > > > > > > > > > > >Chris > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------------- > > > > > > -------------- > > > > > > -------------------------------------- > > > > > > >The information contained in this message is confidential > > > > > > and is intended > > > > > > >for the addressee(s) only. If you have received this > > > > > > message in error or > > > > > > >there are any problems please notify the originator > > > > > > immediately. The > > > > > > >unauthorized use, disclosure, copying or alteration of this > > > > > > message is > > > > > > >strictly forbidden. Baltimore Technologies plc will not > > > > be liable for > > > > > > direct, > > > > > > >special, indirect or consequential damages arising from > > > > > > alteration of the > > > > > > >contents of this message by a third party or as a result of > > > > > > any virus being > > > > > > >passed on. > > > > > > > > > > > > > >In addition, certain Marketing collateral may be added from > > > > > > time to time to > > > > > > >promote Baltimore Technologies products, services, Global > > > > > > e-Security or > > > > > > >appearance at trade shows and conferences. > > > > > > > > > > > > > >This footnote confirms that this email message has been > > > > swept by > > > > > > >Baltimore MIMEsweeper for Content Security threats, > > including > > > > > > >computer viruses. > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Alex Alten > > > > > > > > > > > > Alten@Home.Com > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > > Member, MIT Student Information Processing Board (SIPB) > > > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > > > warlord@MIT.EDU PGP key available > > > > > > > > -- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Aug 7 19:42:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f782gwN23496; Tue, 7 Aug 2001 19:42:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14621 Tue, 7 Aug 2001 21:26:54 -0400 (EDT) Message-ID: <3B709706.4D051BE5@storm.ca> Date: Tue, 07 Aug 2001 21:33:58 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Simplifying IKE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Leech, Schiller and Bellovin (LSB?) document mentions: > the goal: to produce a more secure, simpler, and more robust version of IKE. I thought it might be useful to inventory some proposed simplifications. Of course I'll toss in my own opinions while I'm at it, but my goal is less to get them accepted than to provoke discussion. >From the Schneier and Ferguson analysis we get: > 1: eliminate transport mode It would be possible to eliminate tunnel mode instead, and just use IP-in-IP over transport where required, but it seems simpler to treat transport as a degenerate tunnel instead. Either mode can do everything we need, so we need only one mode. My vote is for tunnel. > 2. eliminate the AH protocol > 3. modify ESP to always authenticate; only encryption should be optional Fine by me, but I vaguely recall some arguments that IPv6 and/or mobile IP actually need AH. Could anyone who needs it speak up again? If it turns out there are really good reasons to keep AH, then I'd say the simplification is: 2a: eliminate ESP authentication 3a: require AH on all packets. No choice, no null mode. An IPsec connection authenticates all packets, period. > 4. modify ESP to ensure it authenticates all data used in the deciphering of the payload This is the only recommendation in this paper based on a direct security flaw, with a proposed attack to demonstrate it. There are others in the Simpson paper. I'd say these are the most urgent criticisms, definite entries on the requirements list for Son of IKE. ( By the way did "Ike" Eisenhower have a son, and should we rename the protocol? ) > 5. Remove the weak key elimination requirement. ... algorithms that have large classes of weak keys ... should simply not be used. Of these, 1, 2, 3 and 5 are straightforward. Methinks these changes should just go straight into the draft text for "Son", unless strong objections are raised by this post. Number 4 is a design task. Volunteers? Is there an existing draft I've missed? Then there are possible simplifications not recommended in the Schneier and Ferguson paper. We currently have MUST do main mode, SHOULD do aggressive mode, and there's been discussion of a third mode. Could we cut it to one mode? There are too many optional items. Can we drop the commit bit? Can we drop some (or even all?) of the optional notify messages? Or perhaps make them required and authenticated, and therefore more useful? PFS is currently optional. Why not require it? In general, review optional items with the intent of dropping as many as possible and making any really useful ones mandatory. This would eliminate quite few interoperation problems. Manually-keyed connections and auto-keyed connections using pre-shared keys for authentication are currently required. Could we drop either or both, given that public key authentication has serious advantages over them? Some discussion of the advantages is at: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/config.html#choose To do this, we would have to specify support for at least one public key technique as a MUST. I'd say RSA was the obvious possibility, and we should have only the one MUST for simplicity. We should also specify a common format for transfer of public key information -- preferably by pointing to an existing spec, rather than re-inventing -- and require everyone to import and export keys in that format, whatever they choose to use internally. That way two implementations that need to interoperate can get each others' keys. For ciphers, we currently have DES and null encryption as the only MUSTs, although we should all know DES is inadequate. 3DES is a SHOULD, although it is dreadfully slow compared to either the CAST and Blowfish generation of ciphers or to AES. I'd like to see AES as the only MUST, with null encryption and 3DES as SHOULDs. From owner-ipsec@lists.tislabs.com Tue Aug 7 20:35:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f783Z9N24244; Tue, 7 Aug 2001 20:35:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14732 Tue, 7 Aug 2001 22:40:48 -0400 (EDT) Date: Tue, 7 Aug 2001 22:47:10 -0400 (EDT) From: Henry Spencer To: Jan Vilhuber cc: IP Security List , Design@lists.freeswan.org Subject: Re: [Design] Re: opportunistic encryption deployment problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 Aug 2001, Jan Vilhuber wrote: > [moving to the design list, instead of the ipsec list, as this is a general > freeswan design question] Uh, no, it's a *protocol* design issue. We hope that FreeS/WAN will not be the only implementation of opportunistic encryption, which is why we submitted it as an IETF draft, and why discussion probably should be cc'ed to the ipsec list. > > using an IP address it does not "own". The answer is that (a) it must > > originate the call, since there is no way to call in to it, (b) it must > > supply enough information via ID payloads > > But this is impossible in main-mode (without fixing it as per improveike > draft)... How so? The difficulty in main mode is with shared-secret authentication. Opportunistic uses RSA-signature authentication, which doesn't have the same design botch. ID payloads work just fine with signature authentication. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Aug 7 21:41:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f784fKN25041; Tue, 7 Aug 2001 21:41:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14861 Tue, 7 Aug 2001 23:39:39 -0400 (EDT) Date: Tue, 7 Aug 2001 23:45:23 -0400 (EDT) From: Henry Spencer To: Jari Arkko cc: borderlt , ipsec@lists.tislabs.com Subject: Re: Re draft-kaufman-ipsec-improveike-00.txt In-Reply-To: <3B6FAE9C.4010606@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 Aug 2001, Jari Arkko wrote: > > I suggest we work on more than one keying mechanism... > > [agreement] It is important to understand > that there are conflicting requirements. I suggest that we should make one good general-purpose protocol work well (today's IKE does not satisfy this desire in a number of ways) before we start considering a plethora of specialized variants. If dim memory serves, there were many cries about how TCP would not meet everyone's needs, and how there were conflicting requirements, and etc. etc. etc... but in fact TCP really does meet *most* people's needs, even if it is not precisely optimal in many cases. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Aug 7 21:41:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f784fNN25053; Tue, 7 Aug 2001 21:41:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14826 Tue, 7 Aug 2001 23:23:52 -0400 (EDT) Date: Tue, 7 Aug 2001 23:30:24 -0400 (EDT) From: Henry Spencer To: "Horn, Mike" cc: ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 Aug 2001, Horn, Mike wrote: > I think users will only deploy Son of IKE if it solves all the open > requirements, not if it just simplifies IKE and adds a single feature like > NAT traversal. There seems to be a big rift between what the IPSEC and > IPSRA WGs are doing, and what the vendors are doing on their own. The intent, as I understand it, is not that Son of IKE solve all mankind's problems (or even all of IPsec's), but rather that it solve some of *IKE's* current problems, and be a more tractable (smaller and more readily understood) base for future work. It's the first step, not the last one. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Aug 7 21:42:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f784gUN25078; Tue, 7 Aug 2001 21:42:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14752 Tue, 7 Aug 2001 22:51:37 -0400 (EDT) Date: Tue, 7 Aug 2001 19:57:35 -0700 (PDT) From: Jan Vilhuber To: Henry Spencer cc: IP Security List , Design@lists.freeswan.org Subject: Re: [Design] Re: opportunistic encryption deployment problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Oh.. you're right. I stand corrected. Duh... jan On Tue, 7 Aug 2001, Henry Spencer wrote: > On Tue, 7 Aug 2001, Jan Vilhuber wrote: > > [moving to the design list, instead of the ipsec list, as this is a general > > freeswan design question] > > Uh, no, it's a *protocol* design issue. We hope that FreeS/WAN will not > be the only implementation of opportunistic encryption, which is why we > submitted it as an IETF draft, and why discussion probably should be cc'ed > to the ipsec list. > > > > using an IP address it does not "own". The answer is that (a) it must > > > originate the call, since there is no way to call in to it, (b) it must > > > supply enough information via ID payloads > > > > But this is impossible in main-mode (without fixing it as per improveike > > draft)... > > How so? The difficulty in main mode is with shared-secret authentication. > Opportunistic uses RSA-signature authentication, which doesn't have the > same design botch. ID payloads work just fine with signature > authentication. > > Henry Spencer > henry@spsystems.net > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Aug 7 22:06:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7856DN25357; Tue, 7 Aug 2001 22:06:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14679 Tue, 7 Aug 2001 22:12:11 -0400 (EDT) Message-Id: <200108080219.f782JIp00242@kebe.east.sun.com> Subject: Re: Simplifying IKE In-Reply-To: <3B709706.4D051BE5@storm.ca> from Sandy Harris at "Aug 7, 2001 09:33:58 pm" To: Sandy Harris Date: Tue, 7 Aug 2001 22:19:18 -0400 (EDT) CC: ipsec@lists.tislabs.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >From the Schneier and Ferguson analysis we get: > > > 1: eliminate transport mode > > It would be possible to eliminate tunnel mode instead, and just use IP-in-IP > over transport where required, but it seems simpler to treat transport as a > degenerate tunnel instead. Either mode can do everything we need, so we need > only one mode. My vote is for tunnel. I respectfully disagree. If we require tunnel mode everywhere, we run the risk of further impacting performance by an additional 20(v4) to 40(v6) bytes of MTU shrinkage. If you consider tunnels as "transport with next-header == IP/IPv6", then you can get all of your tunnel-mode functionality back by indicating a richer selector set for next-header/protocol == IP/IPv6. It's not tough to picture things this way. Here's a table if we eliminate the tunnel mode distinction: Protocol Selector set -------- ------------ TCP outer IP addresses, port numbers UDP outer IP addresses, port numbers ICMP outer IP addresses, code, type IP/IPv6 outer IP addresses, inner IP addresses, plus selector set from inner IP protocol that doesn't include IP addresses. (If inner IP proto == IP, stop with inner IP addresses.) Most of the VPN/router vendors I've seen like the ability to protect different flows across the tunnel differently. My tunnel implementation (which treats tunnel mode like a case of transport mode) doesn't distinguish flows right now, but there's nothing stopping me from doing that in the future. > > 2. eliminate the AH protocol > > 3. modify ESP to always authenticate; only encryption should be > optional > > Fine by me, but I vaguely recall some arguments that IPv6 and/or mobile > IP actually need AH. Could anyone who needs it speak up again? > > If it turns out there are really good reasons to keep AH, then I'd say the > simplification is: > > 2a: eliminate ESP authentication > 3a: require AH on all packets. No choice, no null mode. An IPsec connection > authenticates all packets, period. Choice 3a was the original intent of the SIPP security architecture (which became the 182x series of IPsec RFCs). The biggest complainers about AH I've seen include: 1.) Hardware people who didn't think you could build AH in hardware. (There are worked counter-examples.) 2.) People who thought AH processing rules were convoluted. Now #2 folks may have a point, but simplifying AH rules _may_ help there. The biggest motivator behind AH was to allow an authenticated source route. Now as Steve Bellovin has pointed out, unless you can configure a hop-by-hop key, the middle can send that packet anywhere it wants before it reaches the end. I wish there were some ISP/ops types on this list (maybe there are and I'm just being an airhead). I believe the source route header is primarily used to see what paths are broken in a network - using the process of elimination. Using AH (or ESP authentication) insures that the packet came from where it claims to have come from. THAT is why AH was developed, but ESP authentication can provide a source-routed packet with similar properties. > > 4. modify ESP to ensure it authenticates all data used in the deciphering > of the payload > > This is the only recommendation in this paper based on a direct security > flaw, with a proposed attack to demonstrate it. There are others in the > Simpson paper. And if you use Choice 3a above, you get this for free - AH covers the whole ESP datagram, SPI/IV/etc. > I'd say these are the most urgent criticisms, definite entries on the > requirements list for Son of IKE. None of what you mentioned so far, BTW, deals with IKE. It all deals with IPsec's basic on-the-wire protocols, none of which were really talked about in the Security AD's note. > > 5. Remove the weak key elimination requirement. ... algorithms that > have large classes of weak keys ... should simply not be used. No need to change specs to fix this - just issue a BCP/standard on algorithm choices. > Then there are possible simplifications not recommended in the Schneier > and Ferguson paper. NOW we're in IKE territory... > We currently have MUST do main mode, SHOULD do aggressive mode, and > there's been discussion of a third mode. Could we cut it to one mode? That works for me! > There are too many optional items. > > Can we drop the commit bit? Who uses it? > Can we drop some (or even all?) of the optional notify messages? > Or perhaps make them required and authenticated, and therefore > more useful? Hear hear! > PFS is currently optional. Why not require it? Agreed. > Manually-keyed connections and auto-keyed connections using pre-shared > keys for authentication are currently required. Could we drop either > or both, given that public key authentication has serious advantages > over them? Some discussion of the advantages is at: > http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/config.html#choose Strongly disagree on manual keying. Many outfits use "keying by {Marine guard, bodybuilder, steganography}". Also a manual keying interface can allow better automated KM systems to be built (Shameless plug: RFC 2367). > We should also specify a common format for transfer of public key > information -- preferably by pointing to an existing spec, rather > than re-inventing -- and require everyone to import and export keys > in that format, whatever they choose to use internally. That way two > implementations that need to interoperate can get each others' keys. Now you're tackling PKI problems. I don't envy you the task, especially given we have a PKIX group that's probably better equipped to handle this. > For ciphers, we currently have DES and null encryption as the only > MUSTs, although we should all know DES is inadequate. 3DES is a > SHOULD, although it is dreadfully slow compared to either the CAST > and Blowfish generation of ciphers or to AES. > > I'd like to see AES as the only MUST, with null encryption and 3DES > as SHOULDs. Works for me. But what about hashes? Dan From owner-ipsec@lists.tislabs.com Tue Aug 7 22:57:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f785vfN27327; Tue, 7 Aug 2001 22:57:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA15104 Wed, 8 Aug 2001 00:52:18 -0400 (EDT) Date: Wed, 8 Aug 2001 10:30:35 +0530 (IST) From: Puja Puri To: ipsec@lists.tislabs.com Subject: Packet Interceptor Implementation for IPSec Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am into implementation of IPSec under linux and as a part of it I need to develop a packet interceptor which takes packets from the network adapter and passes it to the IPSec (Bump in the Stack implementation). I am new in this field and I am stuck at the packet interceptor implementation ; since i do not want to hamper with the tcp/ip code but wanna develop a insertable module into the kernel. Can anyone please help me?? What mechanism for this can be used and how to go about it?? Puja Puri Member of Technical Staff Networking and Internet Software Group C-DAC Pune From owner-ipsec@lists.tislabs.com Tue Aug 7 22:58:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f785wPN27346; Tue, 7 Aug 2001 22:58:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA15096 Wed, 8 Aug 2001 00:50:35 -0400 (EDT) Date: Tue, 7 Aug 2001 23:04:52 -0600 From: Shane Amante To: Sandy Harris Cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE Message-ID: <20010807230452.A4676@traveller.amante.org> Mail-Followup-To: Sandy Harris , ipsec@lists.tislabs.com References: <3B709706.4D051BE5@storm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B709706.4D051BE5@storm.ca>; from sandy@storm.ca on Tue, Aug 07, 2001 at 09:33:58PM -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Aug 07, 2001 at 09:33:58PM -0400, Sandy Harris wrote: [-- snip --] > I'd say these are the most urgent criticisms, definite entries on the > requirements list for Son of IKE. > > ( By the way did "Ike" Eisenhower have a son, and should we rename the > protocol? ) According to the 3rd paragraph of this Web page: http://www.ibiblio.org/lia/president/EisenhowerLibrary/_General_Materials/DDE_Biography.html ... President Eisenhower named his first son "Doud Dwight". So, how about calling son-of-IKE, just "Doud" (pronounced Dude?) from now on? :-) -shane From owner-ipsec@lists.tislabs.com Wed Aug 8 01:15:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f788FIN19548; Wed, 8 Aug 2001 01:15:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15622 Wed, 8 Aug 2001 03:14:36 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Simplifying IKE Date: 8 Aug 2001 07:18:29 GMT Organization: University of California, Berkeley Lines: 13 Distribution: isaac Message-ID: <9kqp45$pqf$1@abraham.cs.berkeley.edu> References: <3B709706.4D051BE5@storm.ca> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 997255109 26447 128.32.45.153 (8 Aug 2001 07:18:29 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 8 Aug 2001 07:18:29 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sandy Harris wrote: >The Leech, Schiller and Bellovin (LSB?) document mentions: >> the goal: to produce a more secure, simpler, and more robust version of IKE. > >From the Schneier and Ferguson analysis we get: >> 1: eliminate transport mode >> 2. eliminate the AH protocol >> 3. modify ESP to always authenticate [...] >> 4. modify ESP to ensure it authenticates all data [...] What do any of those have to do with IKE? Those are all about the packet-level format, which has very little to do with IKE, as far as I can see. From owner-ipsec@lists.tislabs.com Wed Aug 8 01:16:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f788G6N19698; Wed, 8 Aug 2001 01:16:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15651 Wed, 8 Aug 2001 03:23:58 -0400 (EDT) To: ipsec@lists.tislabs.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: son of IKE From: Jun-ichiro itojun Hagino Date: Wed, 08 Aug 2001 16:30:52 +0900 Message-Id: <20010808073052.806CF7BA@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk just curious - is there any chance for Photuris? itojun From owner-ipsec@lists.tislabs.com Wed Aug 8 02:22:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f789MqN28325; Wed, 8 Aug 2001 02:22:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA15774 Wed, 8 Aug 2001 04:21:28 -0400 (EDT) Message-ID: <3B70F758.92D93CDB@isi.edu> Date: Wed, 08 Aug 2001 01:24:56 -0700 From: Joe Touch X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sandy Harris CC: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE References: <3B709706.4D051BE5@storm.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sandy Harris wrote: > > The Leech, Schiller and Bellovin (LSB?) document mentions: > > > the goal: to produce a more secure, simpler, and more robust version of IKE. > > I thought it might be useful to inventory some proposed simplifications. Of > course I'll toss in my own opinions while I'm at it, but my goal is less to > get them accepted than to provoke discussion. > > >From the Schneier and Ferguson analysis we get: > > > 1: eliminate transport mode > > It would be possible to eliminate tunnel mode instead, and just use IP-in-IP > over transport where required, but it seems simpler to treat transport as a > degenerate tunnel instead. Either mode can do everything we need, so we need > only one mode. My vote is for tunnel. We address this issue in (the currently recently-expired, but in update) draft-touch-ipsec-vpn-01.txt There is one difference between the two ways of doing tunnel: 1) tunnel mode keys before routing occurs, requiring sychronization between key databases and routing databases when dynamic routing is used to determine keyed path, e.g., for VPNs that use dynamic routing with IPsec'd virtual links 2) transport mode + IPIP encapsulation routes before keying this allows VPNs with dynamic routing using existing routing software --- Tunnel-mode everywhere means an additional 20-40 bytes of overhead everywhere as well, as Dan indicates in his later post. Finally, tunnel mode requires replication of tunneling capability, already part of multicast and mobile IP. While we aren't advocating the removal of tunnel mode per se, our draft describes how transport mode is the more complete and less costly subset. Though, as others have indicated, these are wire-protocol issues rather than IKE (or simpler-IKE) issues. Joe From owner-ipsec@lists.tislabs.com Wed Aug 8 02:25:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f789PMN28380; Wed, 8 Aug 2001 02:25:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA15914 Wed, 8 Aug 2001 04:45:43 -0400 (EDT) From: "Geoffrey Huang" To: Subject: (More) immediate changes to help interop problems? Date: Wed, 8 Aug 2001 01:57:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi there, So I've seen many messages concerning long-term development for the next IKE, but what happened to discussion on fixing some shortcomings that immediately affect interoperability? Andrew K. mentioned a few yesterday during his presentation, but off the top of my head, I can think of a few ambiguities: - Rekeying/Ph. 1 Responder Lifetime - Unreliable Delete/Notifies - Optional Cert Request Payload - Some way to detect dead peers/stale SAs I'm just thinking of issues in currently deployed scenarios... -g From owner-ipsec@lists.tislabs.com Wed Aug 8 02:41:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f789fwN28797; Wed, 8 Aug 2001 02:41:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15968 Wed, 8 Aug 2001 05:02:55 -0400 (EDT) Message-ID: From: Chris Trobridge To: ipsec@lists.tislabs.com Subject: RE: Simplifying IKE Date: Wed, 8 Aug 2001 07:59:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have to admit I started in the "keep tunnelling - los transport" camp, but with more experience I would definitely prefer transport mode + IP-in-IP. This makes gateways and end-to-end cases identical. It also separates routing issues associated with tunnelling from IPSEC. I'd also like to see all IPSEC traffic between two hosts carried by just one SA. I can't see any value in using multiple SAs between to hosts. IPSEC should be just providing a secure pipe between two hosts - what goes through it is better regulated by a firewall. There is an argument that you might want to use different strengths of crypto for performance reasons but there is generally a focus on performing one type of encryption really well rather than supporting multiple types. I'm less keen on AH and would lose it if at all possible. Authenticated ESP provides authentication, integrity and anti-replay of the IP payload - what do you care if the IP header has been tampered with? (what is missing from ESP auth - just the destination IP address?). Per-hop use of SAs currently appears limited as keys are typically only shared by the end-points. I would like to see things like null encryption and specific algorithms not being MUST (or even plaintext bypass). My main reason for this is that you can reject these by policy anyway but that exclusion from build is required for products that go through tough security evaluations. Chris > From the Schneier and Ferguson analysis we get: > > > 1: eliminate transport mode > > It would be possible to eliminate tunnel mode instead, and > just use IP-in-IP > over transport where required, but it seems simpler to treat > transport as a > degenerate tunnel instead. Either mode can do everything we > need, so we need > only one mode. My vote is for tunnel. > > > 2. eliminate the AH protocol > > 3. modify ESP to always authenticate; only encryption should be > optional > > Fine by me, but I vaguely recall some arguments that IPv6 > and/or mobile > IP actually need AH. Could anyone who needs it speak up again? > > If it turns out there are really good reasons to keep AH, > then I'd say the > simplification is: > > 2a: eliminate ESP authentication > 3a: require AH on all packets. No choice, no null mode. An > IPsec connection > authenticates all packets, period. > > > 4. modify ESP to ensure it authenticates all data used in > the deciphering > of the payload > > This is the only recommendation in this paper based on a > direct security > flaw, with a proposed attack to demonstrate it. There are > others in the > Simpson paper. > > I'd say these are the most urgent criticisms, definite entries on the > requirements list for Son of IKE. > > ( By the way did "Ike" Eisenhower have a son, and should we rename the > protocol? ) > > > 5. Remove the weak key elimination requirement. ... algorithms that > have large classes of weak keys ... should simply not be used. > > Of these, 1, 2, 3 and 5 are straightforward. Methinks these changes > should just go straight into the draft text for "Son", unless strong > objections are raised by this post. > > Number 4 is a design task. Volunteers? Is there an existing draft I've > missed? > > Then there are possible simplifications not recommended in > the Schneier > and Ferguson paper. > > We currently have MUST do main mode, SHOULD do aggressive mode, and > there's been discussion of a third mode. Could we cut it to one mode? > > There are too many optional items. > > Can we drop the commit bit? > > Can we drop some (or even all?) of the optional notify messages? > Or perhaps make them required and authenticated, and therefore > more useful? > > PFS is currently optional. Why not require it? > > In general, review optional items with the intent of dropping as many > as possible and making any really useful ones mandatory. This would > eliminate quite few interoperation problems. > > Manually-keyed connections and auto-keyed connections using pre-shared > keys for authentication are currently required. Could we drop either > or both, given that public key authentication has serious advantages > over them? Some discussion of the advantages is at: > http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/confi g.html#choose To do this, we would have to specify support for at least one public key technique as a MUST. I'd say RSA was the obvious possibility, and we should have only the one MUST for simplicity. We should also specify a common format for transfer of public key information -- preferably by pointing to an existing spec, rather than re-inventing -- and require everyone to import and export keys in that format, whatever they choose to use internally. That way two implementations that need to interoperate can get each others' keys. For ciphers, we currently have DES and null encryption as the only MUSTs, although we should all know DES is inadequate. 3DES is a SHOULD, although it is dreadfully slow compared to either the CAST and Blowfish generation of ciphers or to AES. I'd like to see AES as the only MUST, with null encryption and 3DES as SHOULDs. ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Wed Aug 8 02:46:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f789kTN28875; Wed, 8 Aug 2001 02:46:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15992 Wed, 8 Aug 2001 05:06:19 -0400 (EDT) From: Bill Manning Message-Id: <200108080913.f789DNM20119@zed.isi.edu> Subject: Re: Wes Hardaker: opportunistic encryption deployment problems To: henry@spsystems.net (Henry Spencer) Date: Wed, 8 Aug 2001 02:13:23 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), hugh@road.xisp.net (Hugh Daniel), ipsec@lists.tislabs.com, design@lists.freeswan.org (FreeS/WAN Design Issues) In-Reply-To: from "Henry Spencer" at Aug 07, 2001 04:12:28 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk % % On Tue, 7 Aug 2001, Bill Manning wrote: % > One point. Instead of TXT records for stuffing bits into, there is % > the CERT record which was designed for just such stuff. % % Well, for small values of "designed". :-) CERT itself is fine; the problem % is that the stuff inside it is X.509, which we have been resisting getting % involved with. Not really. CERT can contain a number of different CERT types, at least that is what I have been told. % We chose TXT because we simply wanted to convey a gateway address and a % key, and we wanted to parse it with 10 lines of code, not 10,000. $DEITY help you when you grab a random TXT record... :) % % Henry Spencer % henry@spsystems.net % -- --bill From owner-ipsec@lists.tislabs.com Wed Aug 8 02:50:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f789oXN28942; Wed, 8 Aug 2001 02:50:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA16044 Wed, 8 Aug 2001 05:11:59 -0400 (EDT) Message-ID: <3B710406.1175A60@F-Secure.com> Date: Wed, 08 Aug 2001 12:19:02 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan McDonald CC: Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE References: <200108080219.f782JIp00242@kebe.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan McDonald wrote: > > > >From the Schneier and Ferguson analysis we get: > > > > > 1: eliminate transport mode IPsec changes don't simplify IKE, at least not to any extent that would help anyone, and should not be considered. > > > 2. eliminate the AH protocol AH is useless, so yes, although it doesn't really simplify IKE. > > > 3. modify ESP to always authenticate; only encryption should be > > optional I don't care. Our product will refuse to do ESP without authentication in any case. > > We currently have MUST do main mode, SHOULD do aggressive mode, and > > there's been discussion of a third mode. Could we cut it to one mode? > > That works for me! > > > There are too many optional items. > > > > Can we drop the commit bit? > > Who uses it? I guess someone in past figured out that running IKE on satellite lines is necessary, so they decided to optimize as much as possible. The result was that both aggressive mode and quick mode both have three messages. The problem with three messages is that the initiator will often start sending actual traffic too soon, or quick mode packets, before the responder is ready. Thus the need for packet buffers, commit bit, whatever. This optimization causes design complications that I'd very much prefer to get rid of. Thus my preference would be to have a four packet phase 1 (base mode) and a four packet quick mode. The other reason I prefer base mode is that the responder can select the proper policy based on the first packet. If main mode had the possibility to send a group identity in packet one and actual identity in packet five, I wouldn't object to just having main mode, since it does have an even number of packets. > > > Can we drop some (or even all?) of the optional notify messages? > > Or perhaps make them required and authenticated, and therefore > > more useful? > > Hear hear! It would be good to specify exactly when they are to be sent. > > > PFS is currently optional. Why not require it? > > Agreed. It's useless, so it should be thrown out. Just reduce phase 1 lifetime or use a larger DH/elliptic group in phase 1. And specify re-keying exactly. > > > Manually-keyed connections and auto-keyed connections using pre-shared > > keys for authentication are currently required. Could we drop either > > or both, given that public key authentication has serious advantages > > over them? Some discussion of the advantages is at: > > http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/config.html#choose > > Strongly disagree on manual keying. Many outfits use "keying by {Marine > guard, bodybuilder, steganography}". Also a manual keying interface can > allow better automated KM systems to be built (Shameless plug: RFC 2367). Manual keying is useless. Preshared keying is useful in some cases. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Wed Aug 8 03:24:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78AOHN02156; Wed, 8 Aug 2001 03:24:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA16174 Wed, 8 Aug 2001 05:39:56 -0400 (EDT) Message-Id: <5.1.0.14.2.20010808104236.01e5c210@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 08 Aug 2001 10:44:31 +0100 To: Bill Manning , henry@spsystems.net (Henry Spencer) From: Robert Moskowitz Subject: Re: Wes Hardaker: opportunistic encryption deployment problems Cc: bmanning@ISI.EDU (Bill Manning), hugh@road.xisp.net (Hugh Daniel), ipsec@lists.tislabs.com, design@lists.freeswan.org (FreeS/WAN Design Issues) In-Reply-To: <200108080913.f789DNM20119@zed.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 02:13 AM 8/8/2001 -0700, Bill Manning wrote: >% We chose TXT because we simply wanted to convey a gateway address and a >% key, and we wanted to parse it with 10 lines of code, not 10,000. > > $DEITY help you when you grab a random TXT record... :) What about the OPT record? RFC 2671 Then you get IANA to assign an OPT attribute. But clearly, check out CERT first. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Wed Aug 8 04:25:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78BP3N06695; Wed, 8 Aug 2001 04:25:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA16402 Wed, 8 Aug 2001 06:43:38 -0400 (EDT) Date: Wed, 8 Aug 2001 06:50:26 -0400 From: Theodore Tso To: ipsec@lists.tislabs.com, saag@mit.edu Subject: NIST Modes of Operation Papers On-Line Message-ID: <20010808065026.B7491@thunk.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.3.15i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The papers for the upcoming NIST Modes of Operation workshop are now available. Folks who are interested in new modes for AES may find this of interest. - Ted -- --vkogqOf2sHV7VnPd Content-Type: message/rfc822 Content-Disposition: inline >From tytso Tue Aug 7 16:14:01 2001 Return-Path: Received: from po14.mit.edu [18.7.21.72] by localhost with IMAP (fetchmail-5.8.14) for tytso@localhost (single-drop); Tue, 07 Aug 2001 16:14:01 -0400 (EDT) Received: from fort-point-station.mit.edu by po14.mit.edu (8.9.2/4.7) id NAA14890; Tue, 7 Aug 2001 13:02:35 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA25488 for ; Tue, 7 Aug 2001 13:02:35 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f77GoiJ27798 for ; Tue, 7 Aug 2001 09:51:07 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f77Gqec06958 for ; Tue, 7 Aug 2001 09:52:41 -0700 (PDT) Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38]) by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f77GqEr12035 for ; Tue, 7 Aug 2001 09:52:14 -0700 (PDT) Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Tue, 07 Aug 2001 09:48:52 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id JAA06811 for ; Tue, 7 Aug 2001 09:48:58 -0700 (PDT) Received: from ltjtardo (dhcpe2-sj1-067 [10.16.75.67]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id JAA15684 for ; Tue, 7 Aug 2001 09:48:58 -0700 ( PDT) From: "Joseph Tardo" To: iscsi-security@external.cisco.com Subject: NIST Modes of Operation Papers On-Line Date: Tue, 7 Aug 2001 09:48:57 -0700 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: X-WSS-ID: 176EC47E36034-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Bernard: Here is the URL. --Joe http://csrc.nist.gov/encryption/modes/proposedmodes/index.html --vkogqOf2sHV7VnPd-- From owner-ipsec@lists.tislabs.com Wed Aug 8 05:33:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78CX2N12380; Wed, 8 Aug 2001 05:33:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16534 Wed, 8 Aug 2001 07:45:19 -0400 (EDT) Date: Wed, 8 Aug 2001 07:51:45 -0400 (EDT) From: Henry Spencer To: Robert Moskowitz cc: Bill Manning , Hugh Daniel , ipsec@lists.tislabs.com, FreeS/WAN Design Issues Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems In-Reply-To: <5.1.0.14.2.20010808104236.01e5c210@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Aug 2001, Robert Moskowitz wrote: > What about the OPT record? > RFC 2671 OPT is not really intended to go in a DNS database at all -- it's a way of sneaking extensibility into DNS's poorly-designed protocol. Moreover, RFC 2671 specifically forbids caching it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Aug 8 05:37:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78Cb8N12450; Wed, 8 Aug 2001 05:37:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16589 Wed, 8 Aug 2001 07:54:14 -0400 (EDT) Date: Wed, 8 Aug 2001 14:01:59 +0200 (Israel Standard Time) From: Arne Ansper To: Chris Trobridge cc: Subject: RE: Simplifying IKE In-Reply-To: Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-info: Headers changed by Barricade Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'd also like to see all IPSEC traffic between two hosts carried by just one > SA. I can't see any value in using multiple SAs between to hosts. IPSEC there is. and it's not related to security at all. suppose you have slow internet connection that is used only for VPN traffic. your access router has no way to distinguish between different sessions inside your VPN so it will put all the packets into same queue. if somebody is moving large file using ftp your telnet connection will be very very slow. without encryption the routers will put packets from separate sessions (defined by src&dst IP, protocol and ports) into seprate queues (cisco calls them classes IIRC) and even if you are downloading some huge file your telnet session is still usable. with encryption the SPI is the only parameter that can be used to classify the packets. if you are using a single SA between two hosts it's impossible for routers to distinguish between packets from different sessions and the interactive applications suffer really bad. arne From owner-ipsec@lists.tislabs.com Wed Aug 8 05:38:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78CcrN12502; Wed, 8 Aug 2001 05:38:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16614 Wed, 8 Aug 2001 08:01:05 -0400 (EDT) From: Steve.Robinson@psti.com Subject: Re: Simplifying IKE To: Sandy Harris Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 8 Aug 2001 08:12:19 -0400 X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at 08/08/2001 01:12:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few comments: 2a: eliminate ESP authentication 3a: require AH on all packets. No choice, no null mode. An IPsec connection authenticates all packets, period. 4. modify ESP to ensure it authenticates all data used in the deciphering of the payload STEVE: One of the fundamental goals of the Ferguson and Schneider paper was to see the simplification of IPsec. I think that unless justification can be found by the IPv6/mobile camp, we should push forward to eliminate AH altogether and not try to come up with compromise solutions. Also, I think that there is going to be a LOT of resistance to making any modifications to ESP. Look at the chaos that is the IKE group. I've followed this thread in amazement, watching it degenerate and wondering if anything remotely useful will come of the constant bickering. Attempting to make any modifications to ESP, no matter how small or trivial, will probably cause a similar nonproductive uproar. Perhaps the better idea is to scrap the name ESP and move ahead with a new alternative with a new protocol number that we could call the IP Authenticating, Encapsulating Packet Security (AEPS -- or something like that, just different from ESP). This alternative would take ESP and alter it, so that IP header compression can be added, and the tail section (padding, authentication data and all) can be moved to the AEPS header to make implementing it that much easier. This would allow vendors, during a transition period, to be backwards compatible with existing IPsec implementations that support ESP as is, while still moving forward with the new standard. I'd also propose that we allow the diehard faction that says IPsec MUST be completely backwards compatible to have their way. When negotiating an SA, simply do not allow the negotiation of AH, or transport mode in any future implementations. Eventually, the standard will move towards what people are doing and eventually, the simplified model, with only AEPS will become the standard and AH and ESP can be obsoleted (well, it would be nice if this would work, I can dream, can't I? ;-). To do this, we would have to specify support for at least one public key technique as a MUST. I'd say RSA was the obvious possibility, and we should have only the one MUST for simplicity. STEVE: I agree with you on this, but in practice, unless a PKI standard is settled on, my boss is not going to approve of me implementing a proprietary solution unless a consensus is reached in the IPsec community first. My gut feeling is that it isn't gonna happen unless the work at the NIST on PKI suddenly becomes accepted as a standard. I'd like to see AES as the only MUST, with null encryption and 3DES as SHOULDs. STEVE: I'd like this as well, but AES in what modes and key sizes/block rounds? What makes the most sense in the networking environment that we are working in? Is there any work currently being done to study what mode/key size/block size combinations are cryptographically sound, but degrade performance the least? From owner-ipsec@lists.tislabs.com Wed Aug 8 05:44:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78CieN13335; Wed, 8 Aug 2001 05:44:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16671 Wed, 8 Aug 2001 08:10:10 -0400 (EDT) Message-ID: From: Chris Trobridge To: Arne Ansper Cc: ipsec@lists.tislabs.com Subject: RE: Simplifying IKE Date: Wed, 8 Aug 2001 13:13:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is always TOS. Packet length, even? How can you use the SPI to sort traffic? This assumes the access router knows which SPI corresponds to which traffic. Actually classifying traffic after applying ESP is a major hasssle for ISPs. OTOH, they don't often understand the security consequences of leaking the sort of info classification uses - which is often into the application layer! Chris > > I'd also like to see all IPSEC traffic between two hosts > carried by just one > > SA. I can't see any value in using multiple SAs between to > hosts. IPSEC > > there is. and it's not related to security at all. > > suppose you have slow internet connection that is used only for VPN > traffic. your access router has no way to distinguish between > different > sessions inside your VPN so it will put all the packets into > same queue. > if somebody is moving large file using ftp your telnet > connection will be > very very slow. > > without encryption the routers will put packets from separate sessions > (defined by src&dst IP, protocol and ports) into seprate queues (cisco > calls them classes IIRC) and even if you are downloading some > huge file > your telnet session is still usable. > > with encryption the SPI is the only parameter that can be > used to classify > the packets. if you are using a single SA between two hosts it's > impossible for routers to distinguish between packets from different > sessions and the interactive applications suffer really bad. > > arne ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Wed Aug 8 06:15:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78DFmN14140; Wed, 8 Aug 2001 06:15:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16755 Wed, 8 Aug 2001 08:34:15 -0400 (EDT) Message-ID: <005701c12008$11168400$4e8d21d9@sfanninglaptop> From: "Scott Fanning" To: "Geoffrey Huang" , References: Subject: Re: (More) immediate changes to help interop problems? Date: Wed, 8 Aug 2001 05:45:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree. I also would like to see the commit bit gone (not many people support it anyway, nor do it right). I think the fact we still have bakeoffs to test IKE interop, tells us that we need to simplify what we have. At one IETF, I was sure I heard a call and a straw vote for IKE reved to V2, with the new hash, and additional changes. I would like to fix those things we can fix now, allowing current users to continue to use IKE, while we debate a new, and improved key exchange, My 2 cents Scott ----- Original Message ----- From: "Geoffrey Huang" To: Sent: Wednesday, August 08, 2001 1:57 AM Subject: (More) immediate changes to help interop problems? > Hi there, > > So I've seen many messages concerning long-term development for the next > IKE, but what happened to discussion on fixing some shortcomings that > immediately affect interoperability? Andrew K. mentioned a few yesterday > during his presentation, but off the top of my head, I can think of a few > ambiguities: > > - Rekeying/Ph. 1 Responder Lifetime > - Unreliable Delete/Notifies > - Optional Cert Request Payload > - Some way to detect dead peers/stale SAs > > I'm just thinking of issues in currently deployed scenarios... > > -g > From owner-ipsec@lists.tislabs.com Wed Aug 8 06:40:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78DeoN14663; Wed, 8 Aug 2001 06:40:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16834 Wed, 8 Aug 2001 08:52:50 -0400 (EDT) Message-ID: <3B7136EA.A8B1AE7C@isi.edu> Date: Wed, 08 Aug 2001 05:56:10 -0700 From: Joe Touch X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve.Robinson@psti.com CC: Sandy Harris , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: Simplifying IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve.Robinson@psti.com wrote: > > A few comments: > > 2a: eliminate ESP authentication > 3a: require AH on all packets. No choice, no null mode. An IPsec connection > authenticates all packets, period. Null mode is useful, if only for debugging and performance measurement. Jor From owner-ipsec@lists.tislabs.com Wed Aug 8 06:46:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78DkbN14816; Wed, 8 Aug 2001 06:46:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16780 Wed, 8 Aug 2001 08:41:54 -0400 (EDT) Message-Id: <200108081248.f78CmLu72505@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Dan McDonald cc: Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of Tue, 07 Aug 2001 22:19:18 EDT. <200108080219.f782JIp00242@kebe.east.sun.com> Date: Wed, 08 Aug 2001 14:48:21 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > 2a: eliminate ESP authentication > 3a: require AH on all packets. No choice, no null mode. An IPsec > connection authenticates all packets, period. Choice 3a was the original intent of the SIPP security architecture (which became the 182x series of IPsec RFCs).... The biggest motivator behind AH was to allow an authenticated source route. Now as Steve Bellovin has pointed out, unless you can configure a hop-by-hop key, the middle can send that packet anywhere it wants before it reaches the end. I wish there were some ISP/ops types on this list (maybe there are and I'm just being an airhead). I believe the source route header is primarily used to see what paths are broken in a network - using the process of elimination. Using AH (or ESP authentication) insures that the packet came from where it claims to have come from. THAT is why AH was developed, but ESP authentication can provide a source-routed packet with similar properties. => (about the last statement) how? ESP authentication doesn't cover headers. Regards Francis.Dupont@enst-bretagne.fr PS: I am not in favor to reduce IPsec to VPNs, the thing which will happen if we remove AH then transport mode... From owner-ipsec@lists.tislabs.com Wed Aug 8 06:51:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78DpmN14920; Wed, 8 Aug 2001 06:51:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16880 Wed, 8 Aug 2001 09:09:27 -0400 (EDT) Message-Id: <200108072105.f77L5dV29951@coredump.cis.upenn.edu> To: Mike Ditto Cc: ipsec@lists.tislabs.com Subject: Re: Phase 1 IDs ("son of IKE") In-reply-to: Your message of "Tue, 07 Aug 2001 14:07:37 PDT." <200108072107.OAA10431@potomac.incog.com> Date: Tue, 07 Aug 2001 17:05:39 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200108072107.OAA10431@potomac.incog.com>, Mike Ditto writes: > >I don't think it's more complicated. Instead of saying "the responder >must ignore the hint or use it as the value of the subsequent IDir >payload," you say "the responder may use the hint in an >implementation-defined way to influence its selection of its own >identity." Oh, I see. That'd be fine. -Angelos From owner-ipsec@lists.tislabs.com Wed Aug 8 07:02:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78E2tN15248; Wed, 8 Aug 2001 07:02:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16929 Wed, 8 Aug 2001 09:12:28 -0400 (EDT) Message-ID: From: "Horn, Mike" To: "'Derek Atkins'" Cc: ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs Date: Tue, 7 Aug 2001 17:19:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, Want to keep this friendly, but obviously I don't agree with your points. You have a vested interest in KINK, I have a vested interest in IPsec VPNs. This influences both of our views. I noticed you didn't respond to my question about AH... > > First, all the world is not VPN. see above. > Second, there are alternate keying protocols (KINK, for example) Has KINK produced any _standards_ other than the requirements (RFC 3129)? How many IPsec vendors currently offer production support for KINK? > Third, trying to move IKE to IP_PROTO 50 would not only be WRONG, > it would also be HARD I am not saying that IKE should be moved to IP_PROTO 50. If you read my email, "Again, I'm simply stating that **IF** IKE is replaced by something else, the WG should consider using the IPsec ESP protocol number." I agree that moving existing implementations of IKE to 50 would be HARD (you don't explain why it would be wrong). > Fourth, moving IKE to IP_PROTO 50 would make NAT traversal EVEN HARDER > than it already is. Need to think about this further. One of the proposed solutions is to use UDP encapsulation, but this is based on the fact that *currently* IPsec typically uses IKE on port 500 and ESP on protocol 50. If the IPsec architecture were changed other solutions might offer themselves. How does KINK propose to solve NAT traversal? > > You clearly don't understand the problems. Everyone has a right to their own opinions, even the clueless... > > -derek > > "Horn, Mike" writes: > > > First, my only goal for being involved in this thread is > that I think from > > an operational standpoint the current state of IKE/IPsec is > broken. There > > are a LOT of features that have been added by various vendors in a > > proprietary fashion to address these shortcomings. I think > that the whole > > VPN user community would benefit if the WG could come to > some agreement and > > produce a protocol (or set of protocols) to address the VPN > user communities > > needs. > > > > That being said, I thought there was general consensus that > AH has not > > proven to be useful, so I didn't include it in my original > email. If you > > know of _any_ service provider that is using AH for > customer VPN's I would > > be interested to hear who. Again, I'm simply stating that IF IKE is > > replaced by something else, the WG should consider using > the IPsec ESP > > protocol number. > > > > I agree Jan's point that all IPsec requires is keys. Right > now, the only > > thing to my knowledge that is standardized for automated > key exchange for > > use by IPsec is IKE. If that is not fixable to meet the > communities stated > > requirements, then something new needs to be developed to > fill this gap. > > > > I think that the lack of standardization for things like user > > authentication, has definitely impacted the user > community's acceptance of > > IPsec. > > > > Mike Horn > > > > > > > > > -----Original Message----- > > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > > Sent: Tuesday, August 07, 2001 4:31 PM > > > To: Horn, Mike > > > Cc: ipsec@lists.tislabs.com > > > Subject: Re: IKE must have no Heirs > > > > > > > > > Note the 'ipsec' has TWO protocol numbers... One for ESP > and one for > > > AH. What do _YOU_ mean? > > > > > > -derek > > > > > > "Horn, Mike" writes: > > > > > > > Again speaking from service provider experience, manual > > > keys are not a > > > > scalable option. Some sort of key exchange protocol is > > > definitely required, > > > > right now that means IKE. As for using a single IP > > > protocol number for both > > > > IKE and IPsec, I was merely stating this would reduce > the number of > > > > ports/protocols I have to request firewall administrators > > > to allow. From an > > > > operational perspective, dealing with IPsec devices behind > > > firewalls can be > > > > very painful. I will let this thread die, since the IPSEC > > > and IPSRA working > > > > groups face much bigger challenges then determining if IKE > > > and IPsec should > > > > share a protocol number. > > > > > > > > Mike Horn > > > > > > > > > -----Original Message----- > > > > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > > > > Sent: Tuesday, August 07, 2001 3:30 PM > > > > > To: Horn, Mike > > > > > Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com > > > > > Subject: Re: IKE must have no Heirs > > > > > > > > > > > > > > > There is no IPsec (ESP/AH) dependency on IKE. You can > > > key manually > > > > > (which does not use IKE). There is the KINK work, is > > > different than > > > > > IKE. > > > > > > > > > > There is no reason to turn IKE into it's own IP > Protocol. Using > > > > > UDP/500 works just fine, and making it's own protocol > > > wont accomplish > > > > > anything. > > > > > > > > > > -derek > > > > > > > > > > "Horn, Mike" writes: > > > > > > > > > > > Actually that is a poor example, there is no built-in > > > > > protocol dependency > > > > > > for BGP to use OSPF. And BGP does use TCP (port 179) for > > > > > communication vs. > > > > > > OSPF using a protocol number (89). IPsec currently has a > > > > > strong dependency > > > > > > on IKE. I do agree that from a network administration > > > and debugging > > > > > > standpoint it would be nice if both IPsec and IKE shared a > > > > > common protocol > > > > > > number. This would help to simplify firewall > > > configurations, etc. > > > > > > > > > > > > Mike Horn > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Alex Alten [mailto:Alten@home.com] > > > > > > > Sent: Tuesday, August 07, 2001 3:06 AM > > > > > > > To: Chris Trobridge > > > > > > > Cc: ipsec@lists.tislabs.com > > > > > > > Subject: RE: IKE must have no Heirs > > > > > > > > > > > > > > > > > > > > > Think about it. Do you do OSPF over IP and then BGP > > > over UDP? > > > > > > > The same applies to IPSEC and key management. > > > > > > > > > > > > > > - Alex > > > > > > > > > > > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > > >> From: Alex Alten [mailto:Alten@home.com] > > > > > > > >> Sent: 07 August 2001 08:28 > > > > > > > >> To: Kory Hamzeh; Hallam-Baker, Phillip > > > > > > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > > > > > > > >> Subject: Re: IKE must have no Heirs > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> I second the motion. And also propose no port > > > number (i.e. > > > > > > > do the new > > > > > > > >> one over raw IP). > > > > > > > >> > > > > > > > >> - Alex > > > > > > > > > > > > > > > >What would that achieve? (communicating over raw IP) > > > > > > > > > > > > > > > >Chris > > > > > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------------- > > > > > > > -------------- > > > > > > > -------------------------------------- > > > > > > > >The information contained in this message is > confidential > > > > > > > and is intended > > > > > > > >for the addressee(s) only. If you have received this > > > > > > > message in error or > > > > > > > >there are any problems please notify the originator > > > > > > > immediately. The > > > > > > > >unauthorized use, disclosure, copying or > alteration of this > > > > > > > message is > > > > > > > >strictly forbidden. Baltimore Technologies plc will not > > > > > be liable for > > > > > > > direct, > > > > > > > >special, indirect or consequential damages arising from > > > > > > > alteration of the > > > > > > > >contents of this message by a third party or as > a result of > > > > > > > any virus being > > > > > > > >passed on. > > > > > > > > > > > > > > > >In addition, certain Marketing collateral may > be added from > > > > > > > time to time to > > > > > > > >promote Baltimore Technologies products, > services, Global > > > > > > > e-Security or > > > > > > > >appearance at trade shows and conferences. > > > > > > > > > > > > > > > >This footnote confirms that this email message has been > > > > > swept by > > > > > > > >Baltimore MIMEsweeper for Content Security threats, > > > including > > > > > > > >computer viruses. > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Alex Alten > > > > > > > > > > > > > > Alten@Home.Com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media > Laboratory > > > > > Member, MIT Student Information Processing > Board (SIPB) > > > > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA > N1NWH > > > > > warlord@MIT.EDU PGP key > available > > > > > > > > > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > > warlord@MIT.EDU PGP key available > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > From owner-ipsec@lists.tislabs.com Wed Aug 8 07:15:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78EFGN15561; Wed, 8 Aug 2001 07:15:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16899 Wed, 8 Aug 2001 09:10:28 -0400 (EDT) Message-ID: From: "Horn, Mike" To: "'Derek Atkins'" Cc: ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs Date: Tue, 7 Aug 2001 16:48:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First, my only goal for being involved in this thread is that I think from an operational standpoint the current state of IKE/IPsec is broken. There are a LOT of features that have been added by various vendors in a proprietary fashion to address these shortcomings. I think that the whole VPN user community would benefit if the WG could come to some agreement and produce a protocol (or set of protocols) to address the VPN user communities needs. That being said, I thought there was general consensus that AH has not proven to be useful, so I didn't include it in my original email. If you know of _any_ service provider that is using AH for customer VPN's I would be interested to hear who. Again, I'm simply stating that IF IKE is replaced by something else, the WG should consider using the IPsec ESP protocol number. I agree Jan's point that all IPsec requires is keys. Right now, the only thing to my knowledge that is standardized for automated key exchange for use by IPsec is IKE. If that is not fixable to meet the communities stated requirements, then something new needs to be developed to fill this gap. I think that the lack of standardization for things like user authentication, has definitely impacted the user community's acceptance of IPsec. Mike Horn > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Tuesday, August 07, 2001 4:31 PM > To: Horn, Mike > Cc: ipsec@lists.tislabs.com > Subject: Re: IKE must have no Heirs > > > Note the 'ipsec' has TWO protocol numbers... One for ESP and one for > AH. What do _YOU_ mean? > > -derek > > "Horn, Mike" writes: > > > Again speaking from service provider experience, manual > keys are not a > > scalable option. Some sort of key exchange protocol is > definitely required, > > right now that means IKE. As for using a single IP > protocol number for both > > IKE and IPsec, I was merely stating this would reduce the number of > > ports/protocols I have to request firewall administrators > to allow. From an > > operational perspective, dealing with IPsec devices behind > firewalls can be > > very painful. I will let this thread die, since the IPSEC > and IPSRA working > > groups face much bigger challenges then determining if IKE > and IPsec should > > share a protocol number. > > > > Mike Horn > > > > > -----Original Message----- > > > From: Derek Atkins [mailto:warlord@MIT.EDU] > > > Sent: Tuesday, August 07, 2001 3:30 PM > > > To: Horn, Mike > > > Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com > > > Subject: Re: IKE must have no Heirs > > > > > > > > > There is no IPsec (ESP/AH) dependency on IKE. You can > key manually > > > (which does not use IKE). There is the KINK work, is > different than > > > IKE. > > > > > > There is no reason to turn IKE into it's own IP Protocol. Using > > > UDP/500 works just fine, and making it's own protocol > wont accomplish > > > anything. > > > > > > -derek > > > > > > "Horn, Mike" writes: > > > > > > > Actually that is a poor example, there is no built-in > > > protocol dependency > > > > for BGP to use OSPF. And BGP does use TCP (port 179) for > > > communication vs. > > > > OSPF using a protocol number (89). IPsec currently has a > > > strong dependency > > > > on IKE. I do agree that from a network administration > and debugging > > > > standpoint it would be nice if both IPsec and IKE shared a > > > common protocol > > > > number. This would help to simplify firewall > configurations, etc. > > > > > > > > Mike Horn > > > > > > > > > -----Original Message----- > > > > > From: Alex Alten [mailto:Alten@home.com] > > > > > Sent: Tuesday, August 07, 2001 3:06 AM > > > > > To: Chris Trobridge > > > > > Cc: ipsec@lists.tislabs.com > > > > > Subject: RE: IKE must have no Heirs > > > > > > > > > > > > > > > Think about it. Do you do OSPF over IP and then BGP > over UDP? > > > > > The same applies to IPSEC and key management. > > > > > > > > > > - Alex > > > > > > > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Alex Alten [mailto:Alten@home.com] > > > > > >> Sent: 07 August 2001 08:28 > > > > > >> To: Kory Hamzeh; Hallam-Baker, Phillip > > > > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > > > > > >> Subject: Re: IKE must have no Heirs > > > > > >> > > > > > >> > > > > > >> > > > > > >> I second the motion. And also propose no port > number (i.e. > > > > > do the new > > > > > >> one over raw IP). > > > > > >> > > > > > >> - Alex > > > > > > > > > > > >What would that achieve? (communicating over raw IP) > > > > > > > > > > > >Chris > > > > > > > > > > > > > > > > > > >------------------------------------------------------------- > > > > > -------------- > > > > > -------------------------------------- > > > > > >The information contained in this message is confidential > > > > > and is intended > > > > > >for the addressee(s) only. If you have received this > > > > > message in error or > > > > > >there are any problems please notify the originator > > > > > immediately. The > > > > > >unauthorized use, disclosure, copying or alteration of this > > > > > message is > > > > > >strictly forbidden. Baltimore Technologies plc will not > > > be liable for > > > > > direct, > > > > > >special, indirect or consequential damages arising from > > > > > alteration of the > > > > > >contents of this message by a third party or as a result of > > > > > any virus being > > > > > >passed on. > > > > > > > > > > > >In addition, certain Marketing collateral may be added from > > > > > time to time to > > > > > >promote Baltimore Technologies products, services, Global > > > > > e-Security or > > > > > >appearance at trade shows and conferences. > > > > > > > > > > > >This footnote confirms that this email message has been > > > swept by > > > > > >Baltimore MIMEsweeper for Content Security threats, > including > > > > > >computer viruses. > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Alex Alten > > > > > > > > > > Alten@Home.Com > > > > > > > > > > > > > > > > > > > > -- > > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > > Member, MIT Student Information Processing Board (SIPB) > > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > > warlord@MIT.EDU PGP key available > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > From owner-ipsec@lists.tislabs.com Wed Aug 8 07:18:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78EIKN15654; Wed, 8 Aug 2001 07:18:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17042 Wed, 8 Aug 2001 09:30:44 -0400 (EDT) Message-ID: <3B713FC8.8AF53557@isi.edu> Date: Wed, 08 Aug 2001 06:34:00 -0700 From: Joe Touch X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve.Robinson@psti.com CC: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, Sandy Harris Subject: Re: Simplifying IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve.Robinson@psti.com wrote: > > Hi Joe, > > Please look a little closer, all my comments are prefaced by "STEVE:" Apologies for my misattribution. > I have no problems > with including NULL mode, but what I don't want to see is a situation where > we are using ESP for one thing on a packet and AH for another, simply for > what I perceive as political reasons. I'd much prefer to use a single > protocol and simplify our efforts. A simpler protocol would be great. I would like to retain NULL mode for any particular component, though, in the design. Limtations in how they are used for real data can be enforced in the attribute sets exchanged. Joe From owner-ipsec@lists.tislabs.com Wed Aug 8 07:27:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78ERTN15842; Wed, 8 Aug 2001 07:27:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16898 Wed, 8 Aug 2001 09:10:28 -0400 (EDT) Message-ID: From: "Horn, Mike" To: "'Derek Atkins'" Cc: ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs Date: Tue, 7 Aug 2001 15:42:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Again speaking from service provider experience, manual keys are not a scalable option. Some sort of key exchange protocol is definitely required, right now that means IKE. As for using a single IP protocol number for both IKE and IPsec, I was merely stating this would reduce the number of ports/protocols I have to request firewall administrators to allow. From an operational perspective, dealing with IPsec devices behind firewalls can be very painful. I will let this thread die, since the IPSEC and IPSRA working groups face much bigger challenges then determining if IKE and IPsec should share a protocol number. Mike Horn > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Tuesday, August 07, 2001 3:30 PM > To: Horn, Mike > Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com > Subject: Re: IKE must have no Heirs > > > There is no IPsec (ESP/AH) dependency on IKE. You can key manually > (which does not use IKE). There is the KINK work, is different than > IKE. > > There is no reason to turn IKE into it's own IP Protocol. Using > UDP/500 works just fine, and making it's own protocol wont accomplish > anything. > > -derek > > "Horn, Mike" writes: > > > Actually that is a poor example, there is no built-in > protocol dependency > > for BGP to use OSPF. And BGP does use TCP (port 179) for > communication vs. > > OSPF using a protocol number (89). IPsec currently has a > strong dependency > > on IKE. I do agree that from a network administration and debugging > > standpoint it would be nice if both IPsec and IKE shared a > common protocol > > number. This would help to simplify firewall configurations, etc. > > > > Mike Horn > > > > > -----Original Message----- > > > From: Alex Alten [mailto:Alten@home.com] > > > Sent: Tuesday, August 07, 2001 3:06 AM > > > To: Chris Trobridge > > > Cc: ipsec@lists.tislabs.com > > > Subject: RE: IKE must have no Heirs > > > > > > > > > Think about it. Do you do OSPF over IP and then BGP over UDP? > > > The same applies to IPSEC and key management. > > > > > > - Alex > > > > > > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote: > > > > > > > > > > > >> -----Original Message----- > > > >> From: Alex Alten [mailto:Alten@home.com] > > > >> Sent: 07 August 2001 08:28 > > > >> To: Kory Hamzeh; Hallam-Baker, Phillip > > > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > > > >> Subject: Re: IKE must have no Heirs > > > >> > > > >> > > > >> > > > >> I second the motion. And also propose no port number (i.e. > > > do the new > > > >> one over raw IP). > > > >> > > > >> - Alex > > > > > > > >What would that achieve? (communicating over raw IP) > > > > > > > >Chris > > > > > > > > > > > >------------------------------------------------------------- > > > -------------- > > > -------------------------------------- > > > >The information contained in this message is confidential > > > and is intended > > > >for the addressee(s) only. If you have received this > > > message in error or > > > >there are any problems please notify the originator > > > immediately. The > > > >unauthorized use, disclosure, copying or alteration of this > > > message is > > > >strictly forbidden. Baltimore Technologies plc will not > be liable for > > > direct, > > > >special, indirect or consequential damages arising from > > > alteration of the > > > >contents of this message by a third party or as a result of > > > any virus being > > > >passed on. > > > > > > > >In addition, certain Marketing collateral may be added from > > > time to time to > > > >promote Baltimore Technologies products, services, Global > > > e-Security or > > > >appearance at trade shows and conferences. > > > > > > > >This footnote confirms that this email message has been > swept by > > > >Baltimore MIMEsweeper for Content Security threats, including > > > >computer viruses. > > > > > > > > > > > -- > > > > > > Alex Alten > > > > > > Alten@Home.Com > > > > > > > > > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > From owner-ipsec@lists.tislabs.com Wed Aug 8 07:54:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78EsRN16503; Wed, 8 Aug 2001 07:54:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17192 Wed, 8 Aug 2001 09:54:17 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "Horn, Mike" Cc: ipsec@lists.tislabs.com Subject: Re: IKE must have no Heirs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 15:00:47 +0100 Message-Id: <20010808140047.194A37B4B@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Horn, Mike" writes: >Again speaking from service provider experience, manual keys are not a >scalable option. Some sort of key exchange protocol is definitely required, >right now that means IKE. As for using a single IP protocol number for both >IKE and IPsec, I was merely stating this would reduce the number of >ports/protocols I have to request firewall administrators to allow. From an >operational perspective, dealing with IPsec devices behind firewalls can be >very painful. In fact, overloading protocol or port numbers is a major problem for firewalls -- you don't know exactly what you're letting through. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Wed Aug 8 08:02:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78F2JN16701; Wed, 8 Aug 2001 08:02:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17293 Wed, 8 Aug 2001 10:19:52 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15217.19461.896582.163323@thomasm-u1.cisco.com> Date: Wed, 8 Aug 2001 07:26:13 -0700 (PDT) To: Francis Dupont Cc: Dan McDonald , Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <200108081248.f78CmLu72505@givry.rennes.enst-bretagne.fr> References: <200108080219.f782JIp00242@kebe.east.sun.com> <200108081248.f78CmLu72505@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > PS: I am not in favor to reduce IPsec to VPNs, the thing which will happen > if we remove AH then transport mode... Francis, I'm not in favor of VPN only IPsec either, but I don't understand removal of AH would be a step in that direction. The very existence of AH, I think, is at the root of a lot of the misunderstanding that happened with MIPv6. It may not have eliminated all of the misuses of IPsec, but it seems like a pretty vivid example of how more options == more confusion of how they all work (or don't work as the case were). Mike From owner-ipsec@lists.tislabs.com Wed Aug 8 08:07:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78F7cN16873; Wed, 8 Aug 2001 08:07:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17300 Wed, 8 Aug 2001 10:19:55 -0400 (EDT) Date: Wed, 08 Aug 2001 06:58:51 -0700 From: Derrell Piper To: Ari Huttunen cc: Dan McDonald , Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE Message-ID: <461410.997253930@el-air-1.electric-loft.org> In-Reply-To: <3B710406.1175A60@F-Secure.com> References: <200108080219.f782JIp00242@kebe.east.sun.com> <3B710406.1175A60@F-Secure.com> X-Mailer: Mulberry/2.1.0b3 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The other property that commit-bit processing buys you is that the third message of QM is now protected by the IKE retransmit timer and thus QM is guaranteed to complete enough for both sides to generate IPsec SA's, even when the last message (the ISAKMP Notify "CONNECTED") is lost. If you don't use commit-bit processing, the last message of QM can be dropped and this leaves you in the particularly bad state where one side has SA's and the other doesn't. Personally, I would rather burn a full network exchange to ensure that my really expensive key agreement protocol actually completes instead of having to just hope that the network didn't drop my last packet, which is what you're betting on today when you don't use the commit-bit. Derrell --On Wednesday, August 8, 2001 12:19 PM +0300 Ari Huttunen wrote: >> > Can we drop the commit bit? >> >> Who uses it? > > I guess someone in past figured out that running IKE on satellite lines > is necessary, so they decided to optimize as much as possible. The result > was that both aggressive mode and quick mode both have three messages. > The problem with three messages is that the initiator will often start > sending actual traffic too soon, or quick mode packets, before the > responder is ready. Thus the need for packet buffers, commit bit, > whatever. This optimization causes design complications that I'd very > much prefer to get rid of. > > Thus my preference would be to have a four packet phase 1 (base mode) and > a four packet quick mode. > > The other reason I prefer base mode is that the responder can select the > proper policy based on the first packet. > > If main mode had the possibility to send a group identity in packet one > and actual identity in packet five, I wouldn't object to just having main > mode, since it does have an even number of packets. From owner-ipsec@lists.tislabs.com Wed Aug 8 08:10:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FAhN16984; Wed, 8 Aug 2001 08:10:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17004 Wed, 8 Aug 2001 09:24:45 -0400 (EDT) From: Steve.Robinson@psti.com Subject: Re: Simplifying IKE To: Joe Touch Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, Sandy Harris X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 8 Aug 2001 09:36:01 -0400 X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at 08/08/2001 02:36:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Joe, Please look a little closer, all my comments are prefaced by "STEVE:" I cut the other sections from Sandy's original e-mail. I have no problems with including NULL mode, but what I don't want to see is a situation where we are using ESP for one thing on a packet and AH for another, simply for what I perceive as political reasons. I'd much prefer to use a single protocol and simplify our efforts. Take Care, Steve Joe Touch cc: Sandy Harris , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com 08/08/01 Subject: Re: Simplifying IKE 08:56 AM Steve.Robinson@psti.com wrote: > > A few comments: > > 2a: eliminate ESP authentication > 3a: require AH on all packets. No choice, no null mode. An IPsec connection > authenticates all packets, period. Null mode is useful, if only for debugging and performance measurement. Jor From owner-ipsec@lists.tislabs.com Wed Aug 8 08:14:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FEwN17175; Wed, 8 Aug 2001 08:14:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17419 Wed, 8 Aug 2001 10:34:47 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA5B@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Steve.Robinson@psti.com'" , Sandy Harris Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: RE: Simplifying IKE Date: Wed, 8 Aug 2001 07:41:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C12018.3B48B850" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C12018.3B48B850 Content-Type: text/plain; charset="iso-8859-1" > STEVE: I agree with you on this, but in practice, unless a > PKI standard is > settled on, my boss is not going to approve of me implementing a > proprietary solution unless a consensus is reached in the > IPsec community > first. My gut feeling is that it isn't gonna happen unless > the work at the > NIST on PKI suddenly becomes accepted as a standard. Why not simply plug into XKMS? All IPSEC cares about is the delivery of authenticated, validated keys. It should not need to know if the PKI is based on X509/PKIX, PGP, SPKI or YAPKI. Phill ------_=_NextPart_000_01C12018.3B48B850 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C12018.3B48B850-- From owner-ipsec@lists.tislabs.com Wed Aug 8 08:17:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FHaN17250; Wed, 8 Aug 2001 08:17:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17385 Wed, 8 Aug 2001 10:32:21 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15217.20193.161145.884054@thomasm-u1.cisco.com> Date: Wed, 8 Aug 2001 07:38:25 -0700 (PDT) To: "Horn, Mike" Cc: "'Derek Atkins'" , ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Horn, Mike writes: > Derek, > > Want to keep this friendly, but obviously I don't agree with your points. > You have a vested interest in KINK, I have a vested interest in IPsec VPNs. > This influences both of our views. I noticed you didn't respond to my > question about AH... > > > > > First, all the world is not VPN. > > see above. > > > Second, there are alternate keying protocols (KINK, for example) > > Has KINK produced any _standards_ other than the requirements (RFC 3129)? > How many IPsec vendors currently offer production support for KINK? KINK is considerably farther ahead than SOI(lent-green?). We should be able to go to last call soon after this meeting. Many of Radia's improve-ike suggestions are part of the KINK base spec. To give an idea of complexity, it took me about 1 month of 2/3's time to implement almost all of the requirements of the spec, and I expect that it will take a similar amount of time to clean it up to a feature complete status. So we're not talking about major development time here. If nothing else, I'm hoping that KINK will serve as a test of many of Radia's improvements to see if they actually do help with interoperability, etc. Mike From owner-ipsec@lists.tislabs.com Wed Aug 8 08:33:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FXkN17982; Wed, 8 Aug 2001 08:33:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17526 Wed, 8 Aug 2001 10:49:16 -0400 (EDT) Date: Wed, 8 Aug 2001 10:55:41 -0400 (EDT) From: Henry Spencer To: Francis Dupont cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <200108081248.f78CmLu72505@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Aug 2001, Francis Dupont wrote: > ...I believe the source route header is primarily used to see > what paths are broken in a network - using the process of elimination. Actually, the source route header is increasingly frequently ignored (or considered grounds for dropping the packet) by implementations, because of its utility for various forms of attack. > PS: I am not in favor to reduce IPsec to VPNs, the thing which will happen > if we remove AH then transport mode... Can you explain that statement? ESP tunnels can do everything AH or transport mode can do, although sometimes at very slightly greater cost. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Aug 8 08:45:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FjjN20216; Wed, 8 Aug 2001 08:45:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17564 Wed, 8 Aug 2001 11:00:19 -0400 (EDT) Message-ID: <20010808150724.14839.qmail@web4602.mail.yahoo.com> Date: Wed, 8 Aug 2001 08:07:24 -0700 (PDT) From: shiwen chen Subject: Preserve client IP Address with IPSec To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Could anyone please help me with the following questions? when a IPsec client is accessing to an Intranet host, is it possible to preserve the original IP source address of the client? so that the intranet host will be able to read the client's original IP. Thanks SC __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-ipsec@lists.tislabs.com Wed Aug 8 08:45:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78FjlN20234; Wed, 8 Aug 2001 08:45:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17573 Wed, 8 Aug 2001 11:01:12 -0400 (EDT) Message-Id: <200108081456.f78EudA01495@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Re draft-kaufman-ipsec-improveike-00.txt In-reply-to: Your message of "Tue, 07 Aug 2001 23:45:23 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Aug 2001 10:56:39 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Henry" == Henry Spencer writes: Henry> If dim memory serves, there were many cries about how TCP would not meet Henry> everyone's needs, and how there were conflicting requirements, and etc. Henry> etc. etc... but in fact TCP really does meet *most* people's needs, even Henry> if it is not precisely optimal in many cases. At this point, if we switch from UDP, it should be to SCTP. During the original debate SCTP did not exist. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Aug 8 08:46:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78Fk1N20285; Wed, 8 Aug 2001 08:46:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17580 Wed, 8 Aug 2001 11:01:28 -0400 (EDT) Date: Wed, 8 Aug 2001 11:08:00 -0400 (EDT) From: Henry Spencer To: Arne Ansper cc: ipsec@lists.tislabs.com Subject: RE: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Aug 2001, Arne Ansper wrote: > suppose you have slow internet connection that is used only for VPN > traffic. your access router has no way to distinguish between different > sessions inside your VPN so it will put all the packets into same queue. Surely this is what TOS is for. (Note that RFC 2401 calls for TOS to be copied into the outer header, although I'm told that there is now consensus that this ought to be configurable.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Aug 8 09:38:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78GcoN23201; Wed, 8 Aug 2001 09:38:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17828 Wed, 8 Aug 2001 11:54:44 -0400 (EDT) Message-Id: <200108081601.f78G11u73217@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Dan McDonald , Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of Wed, 08 Aug 2001 07:26:13 PDT. <15217.19461.896582.163323@thomasm-u1.cisco.com> Date: Wed, 08 Aug 2001 18:01:01 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Francis Dupont writes: > PS: I am not in favor to reduce IPsec to VPNs, the thing which will > happen if we remove AH then transport mode... Francis, I'm not in favor of VPN only IPsec either, => but VPNs are the current market so if we remove everything not used today only VPN stuff will remain. AH seems to be the first victim of the "simplifying IKE" process and transport mode will be the second (even if this has near nothing to do with the IKE issue and transport mode is more primitive than tunnel mode: tunnel mode is used in VPNs so it cannot be removed). IMHO this is just "remove everything we don't like or don't use" but the net result can be a VPN only IPsec. but I don't understand removal of AH would be a step in that direction. => reread all the not IKE stuff in this thread... The very existence of AH, I think, is at the root of a lot of the misunderstanding that happened with MIPv6. => I disagree, the purpose of AH is the protection of payload and headers (something ESP should not do because there already is AH) and for a signaling protocol like MIPv6 AH is both simpler and cheaper] to use. The trouble of IPsec with MIPv6 is more IKE (the thing we are supposed to simplify): obviously to run IKE phases 1 & 2 in order to protect BUs (sometime a single small packet) is overkilling It may not have eliminated all of the misuses of IPsec, => misuses = other uses than VPNs (:-) ? (note you can seriously answer) but it seems like a pretty vivid example of how more options == more confusion of how they all work (or don't work as the case were). => I disagree: AH for MIPv6 works, this is not deployable (because of global PKI/authorization issue) and nor efficient (as concrete tests have shown). And I believe we'll still see IPsec and MIPv6 together in the future because IPsec only provides a good security service in the network layer (i.e. not everywhere but somewhere). Regards Francis.Dupont@enst-bretagne.fr PS: what the MIPv6 misadventure has shown too is that there is a place for more than one keying protocol. From owner-ipsec@lists.tislabs.com Wed Aug 8 09:41:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78Gf5N23244; Wed, 8 Aug 2001 09:41:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17852 Wed, 8 Aug 2001 12:00:25 -0400 (EDT) Message-ID: From: Chris Trobridge To: Rick Smith at Secure Computing Cc: ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs Date: Wed, 8 Aug 2001 17:04:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That's an interesting idea. I think one of the reasons for putting IKE in user space might have been because it is so much more complicated than the ESP/AH - it's much safer to keep it out of the kernel! Chris > -----Original Message----- > From: Rick Smith at Secure Computing > [mailto:rick_smith@securecomputing.com] > Sent: 07 August 2001 19:49 > To: Alex Alten; Kory Hamzeh; Hallam-Baker, Phillip > Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com > Subject: Re: IKE must have no Heirs > > > At 02:28 AM 8/7/2001, Alex Alten wrote: > > >I second the motion. And also propose no port number (i.e. do the new > >one over raw IP). > > There is a benefit to this approach if, in some future > universe, we ever > try to implement a protocol stack using least privilege to maximize > security assurance. It gives us an easy way of putting all > parts of IPsec > within the same trust boundary and of keeping it better > separated from > other protocol processing. > > Otherwise you are stuck with a uniform level of trust for all of the > software in the protocol stack, crypto and non-crypto, including the > mechanism that binds ports to processes. I know, this isn't a > problem today > because protocol stacks run in kernel mode and therefore we > (have no other > choice but to) "trust" the entire protocol stack. > > It is, of course, feasible to ignore the issues of > incremental trust and/or > build additional mechanisms to bring together what is built > asunder. But it > seems cleaner, design-wise, to keep the key management close > to the code > that actually uses the resulting keys. > > Rick. > smith@securecomputing.com > ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Wed Aug 8 10:01:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78H1hN23546; Wed, 8 Aug 2001 10:01:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17887 Wed, 8 Aug 2001 12:18:46 -0400 (EDT) Message-Id: <200108081624.f78GOhu73295@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Henry Spencer cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of Wed, 08 Aug 2001 10:55:41 EDT. Date: Wed, 08 Aug 2001 18:24:43 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: On Wed, 8 Aug 2001, Francis Dupont wrote: > ...I believe the source route header is primarily used to see > what paths are broken in a network - using the process of elimination. => you haven't quoted me but the message I answered to... Actually, the source route header is increasingly frequently ignored (or considered grounds for dropping the packet) by implementations, because of its utility for various forms of attack. => I agree but the reason seems to be more the lack of 3 addresses filtering in common routers used as (very) poor man firewalls + FUD about source routing. I believe we can consider source routing as not available on the IPv4 Internet (IPv6 tries to fix that so the game is still played for it). > PS: I am not in favor to reduce IPsec to VPNs, the thing which will happen > if we remove AH then transport mode... Can you explain that statement? => read my answer to Michael Thomas for my arguments/fears. ESP tunnels can do everything AH or transport mode can do, although sometimes at very slightly greater cost. => yes but as you have written there is a cost. And from the routing point of view to replace tunnel mode by transport mode with IP-in-IP (yes, I know they are not the same thing) has many advantages. Regards Francis.Dupont@enst-bretagne.fr PS: as a champion of the tunnel mode, can you help me in order to have RFC 2401 5.1.2.1 footnote 3 (including its note) correctly implemented. Of course for dual stack implementations it should be nice to get (as specified by RFC 2401 too) mixed IP version tunnels. (this seems more useful than to reopen the AH hater thread again) From owner-ipsec@lists.tislabs.com Wed Aug 8 10:07:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78H7MN23664; Wed, 8 Aug 2001 10:07:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17916 Wed, 8 Aug 2001 12:29:11 -0400 (EDT) Date: Wed, 8 Aug 2001 12:35:37 -0400 (EDT) From: Henry Spencer To: Francis Dupont cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <200108081624.f78GOhu73295@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Aug 2001, Francis Dupont wrote: > > PS: I am not in favor to reduce IPsec to VPNs, the thing which will happen > > if we remove AH then transport mode... > > Can you explain that statement? > > => read my answer to Michael Thomas for my arguments/fears. I read your answer, and I fear I am no wiser. You still haven't explained why dumping AH and transport mode would "reduce IPsec to VPNs", perhaps because it is not clear what you mean by "VPNs" or what your envisioned non-"VPN" applications for IPsec are (and why they can't be done with ESP tunnels). > ESP tunnels can do everything AH or transport mode can do, > although sometimes at very slightly greater cost. > > => yes but as you have written there is a cost. Quite so, however my claim is that it is very seldom a significant cost. We commonly accept general-purpose mechanisms whose costs are slightly higher than necessary for any particular application, for the sake of generality and simplicity. Numbers matter; a claim that the costs of simplification are unacceptable needs to be justified numerically. > And from the routing > point of view to replace tunnel mode by transport mode with IP-in-IP > (yes, I know they are not the same thing) has many advantages. My feeling is that many of the purported advantages are actually accidents of particular implementations, not fundamental to the protocols. > PS: as a champion of the tunnel mode, can you help me in order to > have RFC 2401 5.1.2.1 footnote 3 (including its note) correctly > implemented. I'm certainly interested in helping: I don't immediately see what help you are asking for... Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Aug 8 10:16:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78HGFN23973; Wed, 8 Aug 2001 10:16:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17970 Wed, 8 Aug 2001 12:41:01 -0400 (EDT) Message-ID: <8DCFE693DDFFD111AC4100A0C9B8DB9405DF1F7C@hdsmsx33.hd.intel.com> From: "Eissa, Mohamed" To: ipsec@lists.tislabs.com Subject: Matching ID with cetificate's subjectName and subjectAltName Date: Wed, 8 Aug 2001 09:40:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, The "PKIX profile for IKE" draft mentioned that the ID used in IKE negotiation, must match with the subjectName or SubjectAltName within the peer certificate. Can someone please help me to understand the risk involved with not doing this match during MAIN/AGGR modes? Mohamed Eissa Intel of Canada From owner-ipsec@lists.tislabs.com Wed Aug 8 10:31:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78HVJN24256; Wed, 8 Aug 2001 10:31:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17995 Wed, 8 Aug 2001 12:48:17 -0400 (EDT) Message-ID: <49B96FCC784BC54F9675A6B558C3464E328F05@MAIL.NetOctave.com> From: David Blaker To: Steve.Robinson@psti.com, Joe Touch Cc: ipsec@lists.tislabs.com Subject: RE: Simplifying IKE Date: Wed, 8 Aug 2001 12:51:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please be aware that from a hardware point of view, and I suspect also from a software point of view, processing 2 SAs per packet will definitely degrade the performance, as opposed to including both authentication and encryption in a single SA a la ESP. This is because of the extra lookups and repeated packet processing, as opposed to the cryptography. David Blaker, CTO NetOctave, Inc. P.O. Box 14824 Research Triangle Park, NC 27709 Phone (919) 463-9903 x.206 / Fax (919) 463-9905 email mailto:dblaker@netoctave.com website http://www.netoctave.com -----Original Message----- From: Steve.Robinson@psti.com [mailto:Steve.Robinson@psti.com] Sent: Wednesday, August 08, 2001 9:36 AM To: Joe Touch Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com; Sandy Harris Subject: Re: Simplifying IKE Hi Joe, Please look a little closer, all my comments are prefaced by "STEVE:" I cut the other sections from Sandy's original e-mail. I have no problems with including NULL mode, but what I don't want to see is a situation where we are using ESP for one thing on a packet and AH for another, simply for what I perceive as political reasons. I'd much prefer to use a single protocol and simplify our efforts. Take Care, Steve Joe Touch cc: Sandy Harris , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com 08/08/01 Subject: Re: Simplifying IKE 08:56 AM Steve.Robinson@psti.com wrote: > > A few comments: > > 2a: eliminate ESP authentication > 3a: require AH on all packets. No choice, no null mode. An IPsec connection > authenticates all packets, period. Null mode is useful, if only for debugging and performance measurement. Jor From owner-ipsec@lists.tislabs.com Wed Aug 8 10:40:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78HeON24467; Wed, 8 Aug 2001 10:40:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18068 Wed, 8 Aug 2001 13:01:05 -0400 (EDT) Message-Id: <200108081707.f78H77u73516@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Henry Spencer cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of Wed, 08 Aug 2001 12:35:37 EDT. Date: Wed, 08 Aug 2001 19:07:07 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I read your answer, and I fear I am no wiser. You still haven't explained why dumping AH and transport mode would "reduce IPsec to VPNs" => assume that you have a IPsec implementation with AH, ESP, even IPCOMP, transport and tunnel modes, a IKE you know how to configure (:-), ... So the only application where you'd like to use ESP in tunnel mode is VPNs, for end-to-end transport mode is easier/cheaper, if you need authentication only AH is easier/cheaper and give more. because it is not clear what you mean by "VPNs" => protection (confidentiality first) of traffic between two points with at least one of the two ends being a SG. or what your envisioned non-"VPN" applications for IPsec are => an example: protect a BGP session between two routers (authentication is enough, network layer is mandatory because of fake TCP RSTs). (and why they can't be done with ESP tunnels). => I didn't say that, everything can be done with ESP tunnels but with more complexity and higher cost. > ESP tunnels can do everything AH or transport mode can do, > although sometimes at very slightly greater cost. > > => yes but as you have written there is a cost. Quite so, however my claim is that it is very seldom a significant cost. We commonly accept general-purpose mechanisms whose costs are slightly higher than necessary for any particular application, for the sake of generality and simplicity. Numbers matter; a claim that the costs of simplification are unacceptable needs to be justified numerically. => it seems you'd like to apply the market argument: the market is VPNs so keep only the ESP in tunnel mode. I understand that but I don't like it. > PS: as a champion of the tunnel mode, can you help me in order to > have RFC 2401 5.1.2.1 footnote 3 (including its note) correctly > implemented. I'm certainly interested in helping: I don't immediately see what help you are asking for... => too many implementations check when they should not (I like to get a MUST NOT here) the outer source address for ESP tunnels. The reason seems to be security, if there is a real issue the RFC must be fixed ASAP, if there is none the implementations must be fixed ASAP. If we keep only ESP in tunnel mode I'd like to get it correctly implemented... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Aug 8 10:59:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78HxAN24777; Wed, 8 Aug 2001 10:59:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18124 Wed, 8 Aug 2001 13:14:26 -0400 (EDT) Message-Id: <3.0.5.32.20010808191436.035bdb60@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 08 Aug 2001 19:14:36 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Matching ID with cetificate's subjectName and subjectAltName In-Reply-To: <8DCFE693DDFFD111AC4100A0C9B8DB9405DF1F7C@hdsmsx33.hd.intel .com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA18097 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:40 08.08.01 -0700, Eissa, Mohamed wrote: >Hi, > >The "PKIX profile for IKE" draft mentioned that the ID used in IKE >negotiation, must match with the subjectName or SubjectAltName within the >peer certificate. > >Can someone please help me to understand the risk involved with not doing >this match during MAIN/AGGR modes? > >Mohamed Eissa >Intel of Canada > Risk? The protocol is simply useless if you don't check it. Example: You contact server 192.168.22.9. Now, the server sends a certificate with DN = "C=US, O=corp". The certificate is still valid and the signature check succeeds. Now. What good this is? Anybody with a valid certificate can the hook of the server 192.168.22.9 and place his own there, and you won't notice. He won't have the private key of the server, but that does not matter. He puts his _own_ private key and cert there. You won't notice because you accept all certificates. So, the main goal, making sure that the server is really the server you expect it to be, can't be reached. => A client must know which certificate to expect. Solution (1): You tell the client which certificate the server will use. The full DN. letter by letter. Solution (2): You put the IP address (or dns) into the certificate. The client will check that the cert actually contains the ID it's expecting. Solution (1) is subjectName, solution (2) is SubjectAltName. The IKE ID simply tells the client which (server) cert to use. It points to a certificate. After all, the client could ignore all certs sent by the server, take the IKE ID and ask LDAP for a cert. Again: The client contacts server 192.168.22.9. The server answeres with IKE ID 192.168.22.9. The client is happy with that. The client also receives one or several certs. It looks for the one with SubjectAltName 192.168.22.9 and checks the signature with it. Jörn From owner-ipsec@lists.tislabs.com Wed Aug 8 11:28:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78ISVN25321; Wed, 8 Aug 2001 11:28:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18175 Wed, 8 Aug 2001 13:43:07 -0400 (EDT) Message-Id: <200108081749.f78HmtR00738@dharkins@lounge.orgatty.lounge.org> To: Ari Huttunen Cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Your message of "Wed, 08 Aug 2001 12:19:02 +0300." <3B710406.1175A60@F-Secure.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <735.997292935.1@lounge.org> Date: Wed, 08 Aug 2001 10:48:55 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My tentative text on the subject is to get rid of the commit bit and have a 3 message exchange. The problem with the existing 3 message exchanage (w/o the commit bit being used) is that the Responder will not instantiate her SAs until receipt of the 3rd message from the Initiator to avoid a resource consumption attack but the Initiator will instantiate his SAs upon receipt of the 2nd message from the Responder. This results in a race between the first few IPsec-protected packets and the final message. If the former win they get dropped. My proposal is that the Responder instantiate the SAs when she sends the 2nd message back to the Initiator. She will be setting a timer to deal with non-receipt of the 3rd message and if the timer fires RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed and she can delete these SAs from her SADB. In addition to this text there is new text instructing implementations to deal with receipt of an offer to create an IPsec SA with a SPI that is currently in use as an error, and new text instructing the Initiator to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in case it is dropped and he receives a retransmitted 2nd message from the Responder. This is much simpler than what we have and solves the race problem. What it does, though, is allow for some resources to be temporarily consumed due to the replay of an old message. I don't view this as that big of a problem though since it is temporary (RETRANSMIT_TIME * RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in the SADB) and the number of possible packets that can be replayed is limited and bounded by the life of the IKE SA. Thoughts? Dan. On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > Dan McDonald wrote: > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > Can we drop the commit bit? > > > > Who uses it? > > I guess someone in past figured out that running IKE on satellite lines > is necessary, so they decided to optimize as much as possible. The result > was that both aggressive mode and quick mode both have three messages. > The problem with three messages is that the initiator will often start sendin >g > actual traffic too soon, or quick mode packets, before the responder is ready >. Thus > the need for packet buffers, commit bit, whatever. This optimization causes d >esign > complications that I'd very much prefer to get rid of. From owner-ipsec@lists.tislabs.com Wed Aug 8 11:37:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78IbqN25529; Wed, 8 Aug 2001 11:37:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18210 Wed, 8 Aug 2001 13:56:49 -0400 (EDT) Message-Id: <200108081802.f78I2XR00772@dharkins@lounge.orgatty.lounge.org> To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Your message of "Wed, 08 Aug 2001 18:01:01 +0200." <200108081601.f78G11u73217@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <769.997293753.1@lounge.org> Date: Wed, 08 Aug 2001 11:02:33 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 08 Aug 2001 18:01:01 +0200 you wrote > > The very existence of AH, I think, is at the root of > a lot of the misunderstanding that happened with MIPv6. > > => I disagree, the purpose of AH is the protection of payload > and headers (something ESP should not do because there already is AH) > and for a signaling protocol like MIPv6 AH is both simpler and cheaper] > to use. The trouble of IPsec with MIPv6 is more IKE (the thing we are > supposed to simplify): obviously to run IKE phases 1 & 2 in order > to protect BUs (sometime a single small packet) is overkilling Well, not really, and none of the simplifications being proposed or planned for IKE would help MIPv6. The problem with MIPv6 is that the Binding Update is a destination option which they would like authenticated. But there is no way for an IPsec selector to be defined to identify certain types of destination options. The choice is to authenticate _everything_ which they don't want to do or authenticate _nothing_ which they can't do. This has nothing to do with IKE. While the overkill of a phase 1 and phase 2 to merely authenticate a single Binding Update is a problem the other, larger problem is that there is no global PKI to deal with authentication. Even a protocol (SKIP for instance) which could handle the key establishment in a single message-- definitely not overkill-- would not work because there is no global PKI to support it. Dan. From owner-ipsec@lists.tislabs.com Wed Aug 8 12:17:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78JHeN26381; Wed, 8 Aug 2001 12:17:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18343 Wed, 8 Aug 2001 14:29:45 -0400 (EDT) Message-Id: <200108081835.f78IZhJ09105@thunk.east.sun.com> From: Bill Sommerfeld To: Francis Dupont cc: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of "Wed, 08 Aug 2001 19:07:07 +0200." <200108081707.f78H77u73516@givry.rennes.enst-bretagne.fr> Reply-to: sommerfeld@East.Sun.COM Date: Wed, 08 Aug 2001 14:35:42 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk AH or not-AH has nothing to do with VPN or end-to-end IPsec use. As Steve Bellovin has pointed out on numerous occasions, the IP header in transport-mode ESP can be "authenticated" merely by doing a compare of the source and destination addresses against static state in the SA... - Bill From owner-ipsec@lists.tislabs.com Wed Aug 8 12:42:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78JgZN26786; Wed, 8 Aug 2001 12:42:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19375 Wed, 8 Aug 2001 14:46:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Simplifying IKE Date: Wed, 8 Aug 2001 11:52:09 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1A4E8D6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Simplifying IKE thread-index: AcEgNK10eOnzsdKdSGWr8JBshP/ougABZ55w From: "Brian Swander" To: "Dan Harkins" , "Ari Huttunen" Cc: X-OriginalArrivalTime: 08 Aug 2001 18:52:10.0429 (UTC) FILETIME=[3AC5DED0:01C1203B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA19372 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd prefer to keep the commit bit. Otherwise the responder is forced to add SAs before the final QM hash from the initiator is processed, opening the responder up to adding potentially suspect SAs into the system. I am not so concerned with the resources in an attack, but more worried about an attacker potentially getting an SA into the system that could be exploited. I don't see how this could be done today (all I can see is the obvious replay attack Dan is talking about), but that doesn't mean that such an exploit doesn't exist. So, I am much more comfortable with the one extra packet and the assurance that everything is ok with the negotiation before SAs are added. Of course, if someone has a proof that the security can't be violated by adding the responder SAs early, then I'd agree to eliminating the commit bit (except for backwards compatibility, when we'd still need to support it). bs -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org] Sent: Wednesday, August 08, 2001 10:49 AM To: Ari Huttunen Cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE My tentative text on the subject is to get rid of the commit bit and have a 3 message exchange. The problem with the existing 3 message exchanage (w/o the commit bit being used) is that the Responder will not instantiate her SAs until receipt of the 3rd message from the Initiator to avoid a resource consumption attack but the Initiator will instantiate his SAs upon receipt of the 2nd message from the Responder. This results in a race between the first few IPsec-protected packets and the final message. If the former win they get dropped. My proposal is that the Responder instantiate the SAs when she sends the 2nd message back to the Initiator. She will be setting a timer to deal with non-receipt of the 3rd message and if the timer fires RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed and she can delete these SAs from her SADB. In addition to this text there is new text instructing implementations to deal with receipt of an offer to create an IPsec SA with a SPI that is currently in use as an error, and new text instructing the Initiator to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in case it is dropped and he receives a retransmitted 2nd message from the Responder. This is much simpler than what we have and solves the race problem. What it does, though, is allow for some resources to be temporarily consumed due to the replay of an old message. I don't view this as that big of a problem though since it is temporary (RETRANSMIT_TIME * RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in the SADB) and the number of possible packets that can be replayed is limited and bounded by the life of the IKE SA. Thoughts? Dan. On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > Dan McDonald wrote: > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > Can we drop the commit bit? > > > > Who uses it? > > I guess someone in past figured out that running IKE on satellite lines > is necessary, so they decided to optimize as much as possible. The result > was that both aggressive mode and quick mode both have three messages. > The problem with three messages is that the initiator will often start sendin >g > actual traffic too soon, or quick mode packets, before the responder is ready >. Thus > the need for packet buffers, commit bit, whatever. This optimization causes d >esign > complications that I'd very much prefer to get rid of. From owner-ipsec@lists.tislabs.com Wed Aug 8 13:39:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78KdTN27875; Wed, 8 Aug 2001 13:39:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19812 Wed, 8 Aug 2001 15:54:57 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: How to get ID: "PKIX profile for IKE" ? From: Ryu Inada Message-Id: <200108090502.HFC54360.VSZ@fujixerox.co.jp> X-Mailer: Winbiff [Version 2.33PL2] X-Accept-Language: ja,en Date: Thu, 9 Aug 2001 05:02:13 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. Does anyone know how to get ID:"PKIX profile for IKE" ? I could not found IETF's ID archives. Thanks. Ryu Inada -- Ryu Inada ryu@fujixerox.co.jp From owner-ipsec@lists.tislabs.com Wed Aug 8 13:39:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78KdTN27882; Wed, 8 Aug 2001 13:39:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19736 Wed, 8 Aug 2001 15:45:48 -0400 (EDT) Message-Id: <200108081939.f78JdWr11860@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of "Wed, 08 Aug 2001 11:02:33 PDT." <200108081802.f78I2XR00772@dharkins@lounge.orgatty.lounge.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Aug 2001 15:39:32 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan Harkins writes: Dan> The problem with MIPv6 is that the Binding Update is a destination Dan> option which they would like authenticated. But there is no way for Dan> an IPsec selector to be defined to identify certain types of destination Dan> options. The choice is to authenticate _everything_ which they don't Dan> want to do or authenticate _nothing_ which they can't do. This has Dan> nothing to do with IKE. Well, there is no standard way. Within a unified stack, (not BITW or BITS) the packets with the binding update can easily be marked for IPsec processor via out-of-band means (i.e. in the control structure). Dan> While the overkill of a phase 1 and phase 2 to merely authenticate a Dan> single Binding Update is a problem the other, larger problem is that Dan> there is no global PKI to deal with authentication. Even a protocol This is the same problem that Opportunistic Encryption struggles with. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO3GVc4qHRg3pndX9AQGT1QQA1xP5VcoQ3wMAOb4hHteJ5QAox9/NO40U c1i3FNop74RouKJrvHZ4iwMmxNNiB1ZlCOA11JdD1+JnoLSU39+jIkAumMBbbqcA hfHnecU1f4N2B5tfWkgKzqmGsL/fjYBZJaBx4cBBlsUbqb6efHtjVm7DdC1ChWRE egwFZSM0mWo= =r74V -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Aug 8 13:39:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78KdXN27899; Wed, 8 Aug 2001 13:39:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19753 Wed, 8 Aug 2001 15:49:05 -0400 (EDT) To: sommerfeld@East.Sun.COM Cc: Francis Dupont , Henry Spencer , ipsec@lists.tislabs.com In-reply-to: sommerfeld's message of Wed, 08 Aug 2001 14:35:42 -0400. <200108081835.f78IZhJ09105@thunk.east.sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Simplifying IKE From: Jun-ichiro itojun Hagino Date: Thu, 09 Aug 2001 04:55:49 +0900 Message-Id: <20010808195549.596F27BB@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >AH or not-AH has nothing to do with VPN or end-to-end IPsec use. > >As Steve Bellovin has pointed out on numerous occasions, the IP header >in transport-mode ESP can be "authenticated" merely by doing a compare >of the source and destination addresses against static state in the >SA... if you think about extension headers/IP options, IMHO the above statement is not correct. AH is needed for a good reason. what bothering me in IPsec spec is that it includes tunnel mode. IPsec specification should only talk about transport mode, and tunnel mode should be "IPsec transport mode + some sort of tunnelling". there are a lot of (really, a lot of) tunnelling specifications around so you have no problem referring those. also, "bundle" should be dropped from RFC2401 as the concept of "bundle" conflicts with the way AH and ESP are defined - they are independent protocol, and can easily be handled/negotiated completely separately. btw - are we really going to simplify IPsec too, not just IKE? if not, we should stop talking about IPsec mods. itojun From owner-ipsec@lists.tislabs.com Wed Aug 8 13:50:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78KoRN28144; Wed, 8 Aug 2001 13:50:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19868 Wed, 8 Aug 2001 16:08:47 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Your message of "Wed, 08 Aug 2001 14:35:42 -0400" <200108081835.f78IZhJ09105@thunk.east.sun.com> References: <200108081835.f78IZhJ09105@thunk.east.sun.com> X-Mailer: Cue version 0.6 (010413-1707/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010809051536G.sakane@kame.net> Date: Thu, 09 Aug 2001 05:15:36 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > As Steve Bellovin has pointed out on numerous occasions, the IP header > in transport-mode ESP can be "authenticated" merely by doing a compare > of the source and destination addresses against static state in the > SA... but we need to survey whether there is really no ip extention header to be protected or not, don't we ?. From owner-ipsec@lists.tislabs.com Wed Aug 8 14:11:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78LB3N28461; Wed, 8 Aug 2001 14:11:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19933 Wed, 8 Aug 2001 16:23:09 -0400 (EDT) From: "sankar ramamoorthi" To: "Dan Harkins" , "Ari Huttunen" Cc: Subject: RE: Simplifying IKE Date: Wed, 8 Aug 2001 13:31:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200108081749.f78HmtR00738@dharkins@lounge.orgatty.lounge.org> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Wednesday, August 08, 2001 10:49 AM > To: Ari Huttunen > Cc: ipsec@lists.tislabs.com > Subject: Re: Simplifying IKE > > > My tentative text on the subject is to get rid of the commit bit and > have a 3 message exchange. The problem with the existing 3 message > exchanage (w/o the commit bit being used) is that the Responder will not > instantiate her SAs until receipt of the 3rd message from the Initiator > to avoid a resource consumption attack but the Initiator will instantiate > his SAs upon receipt of the 2nd message from the Responder. This results > in a race between the first few IPsec-protected packets and the final > message. If the former win they get dropped. > > My proposal is that the Responder instantiate the SAs when she sends > the 2nd message back to the Initiator. She will be setting a timer to > deal with non-receipt of the 3rd message and if the timer fires > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > and she can delete these SAs from her SADB. What happens if the initiator starts sending data before the responder receives the third message? Will the ipsec packet from initiator be processed since responder has established the SA on receipt of the second message? If so, can the responder treat succesful processing of the data packet as succesful authentication of the initiator and mark the SA as valid(basically treat the condition same as processing a successful third message). Personally I prefer a 4 packet exchange model for QM. > > In addition to this text there is new text instructing implementations > to deal with receipt of an offer to create an IPsec SA with a SPI that > is currently in use as an error, and new text instructing the Initiator > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in case > it is dropped and he receives a retransmitted 2nd message from the > Responder. > > This is much simpler than what we have and solves the race problem. > What it does, though, is allow for some resources to be temporarily > consumed due to the replay of an old message. I don't view this as that > big of a problem though since it is temporary (RETRANSMIT_TIME * > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in > the SADB) and the number of possible packets that can be replayed is > limited and bounded by the life of the IKE SA. > > Thoughts? > > Dan. > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > > > Dan McDonald wrote: > > > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > > > Can we drop the commit bit? > > > > > > Who uses it? > > > > I guess someone in past figured out that running IKE on satellite lines > > is necessary, so they decided to optimize as much as possible. > The result > > was that both aggressive mode and quick mode both have three messages. > > The problem with three messages is that the initiator will > often start sendin > >g > > actual traffic too soon, or quick mode packets, before the > responder is ready > >. Thus > > the need for packet buffers, commit bit, whatever. This > optimization causes d > >esign > > complications that I'd very much prefer to get rid of. > From owner-ipsec@lists.tislabs.com Wed Aug 8 14:12:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78LCON28580; Wed, 8 Aug 2001 14:12:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19918 Wed, 8 Aug 2001 16:17:52 -0400 (EDT) To: "Brian Swander" Cc: "Dan Harkins" , "Ari Huttunen" , ipsec@lists.tislabs.com In-reply-to: briansw's message of Wed, 08 Aug 2001 11:52:09 MST. <2E33960095B58E40A4D3345AB9F65EC1A4E8D6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Simplifying IKE From: Jun-ichiro itojun Hagino Date: Thu, 09 Aug 2001 05:24:25 +0900 Message-Id: <20010808202425.525497BB@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I'd prefer to keep the commit bit. Otherwise the responder is forced to >add SAs before the final QM hash from the initiator is processed, >opening the responder up to adding potentially suspect SAs into the >system. regarding to commit bit processing, we should really look again about 3-phase commit protocol as discussed in distributed database textbooks, and follow their suggestions. it's very wrong for both ends to go unsynchronized on packet losses. itojun From owner-ipsec@lists.tislabs.com Wed Aug 8 14:39:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78LdBN11024; Wed, 8 Aug 2001 14:39:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20029 Wed, 8 Aug 2001 16:53:13 -0400 (EDT) Date: Wed, 8 Aug 2001 13:59:37 -0700 (PDT) From: Jan Vilhuber To: sankar ramamoorthi cc: Dan Harkins , Ari Huttunen , ipsec@lists.tislabs.com Subject: RE: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Aug 2001, sankar ramamoorthi wrote: > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > > Sent: Wednesday, August 08, 2001 10:49 AM > > To: Ari Huttunen > > Cc: ipsec@lists.tislabs.com > > Subject: Re: Simplifying IKE > > > > > > My tentative text on the subject is to get rid of the commit bit and > > have a 3 message exchange. The problem with the existing 3 message > > exchanage (w/o the commit bit being used) is that the Responder will not > > instantiate her SAs until receipt of the 3rd message from the Initiator > > to avoid a resource consumption attack but the Initiator will instantiate > > his SAs upon receipt of the 2nd message from the Responder. This results > > in a race between the first few IPsec-protected packets and the final > > message. If the former win they get dropped. > > > > My proposal is that the Responder instantiate the SAs when she sends > > the 2nd message back to the Initiator. She will be setting a timer to > > deal with non-receipt of the 3rd message and if the timer fires > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > > and she can delete these SAs from her SADB. > > What happens if the initiator starts sending data before the responder > receives the third message? > > Will the ipsec packet from initiator be processed since responder has > established the SA on receipt of the second message? If so, can the > responder treat succesful processing of the data packet as succesful > authentication of the initiator and mark the SA as valid(basically > treat the condition same as processing a successful third message). > > Personally I prefer a 4 packet exchange model for QM. > Or figure out a way to address the replay issues, and drop the 3rd message, making a 2 message exchange. I favor an even number of messages. Whether that's 2 or 4 I don't MUCH care (2 would be preferable if we can figure out how). An odd number of messages leads to kludges concerning how and when to install resources and timers to detect the lack of 3rd message, and so forth. If need be, I'm all for 4 messages, as well. jan > > > > In addition to this text there is new text instructing implementations > > to deal with receipt of an offer to create an IPsec SA with a SPI that > > is currently in use as an error, and new text instructing the Initiator > > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in case > > it is dropped and he receives a retransmitted 2nd message from the > > Responder. > > > > This is much simpler than what we have and solves the race problem. > > What it does, though, is allow for some resources to be temporarily > > consumed due to the replay of an old message. I don't view this as that > > big of a problem though since it is temporary (RETRANSMIT_TIME * > > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in > > the SADB) and the number of possible packets that can be replayed is > > limited and bounded by the life of the IKE SA. > > > > Thoughts? > > > > Dan. > > > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > > > > > Dan McDonald wrote: > > > > > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > > > > > Can we drop the commit bit? > > > > > > > > Who uses it? > > > > > > I guess someone in past figured out that running IKE on satellite lines > > > is necessary, so they decided to optimize as much as possible. > > The result > > > was that both aggressive mode and quick mode both have three messages. > > > The problem with three messages is that the initiator will > > often start sendin > > >g > > > actual traffic too soon, or quick mode packets, before the > > responder is ready > > >. Thus > > > the need for packet buffers, commit bit, whatever. This > > optimization causes d > > >esign > > > complications that I'd very much prefer to get rid of. > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Aug 8 14:53:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78LrPN20911; Wed, 8 Aug 2001 14:53:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20017 Wed, 8 Aug 2001 16:51:59 -0400 (EDT) Date: Wed, 8 Aug 2001 13:57:15 -0700 (PDT) From: Jan Vilhuber To: Brian Swander cc: Dan Harkins , Ari Huttunen , ipsec@lists.tislabs.com Subject: RE: Simplifying IKE In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1A4E8D6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Aug 2001, Brian Swander wrote: > I'd prefer to keep the commit bit. Otherwise the responder is forced to > add SAs before the final QM hash from the initiator is processed, > opening the responder up to adding potentially suspect SAs into the > system. > I'd actually prefer to formalize the concept that the commit-bit is trying to address: 1) Either expand quick mode to 4 messages. That's unambiguous, and leads to better interop. A commit bit is really a kludge. 2) If you think about it, the 3rd message is only needed to prevent replay attacks of old messages. If we addressed this some other way (say a timestamp field, but that has obvious other problems), then we could drop the 3rd message, and have 2, which is again 'good (tm)'. Dan also outlined some other ways to address this problem, and while they work, I don't much care for them, since they're really work-arounds to the problem above. It would be preferable to address the replay attacks in some other way (if possible) and do away with the 3rd message, or bite the bullet and create a 4th message as an ACK to make the exchange as unambiguous as possible. I point out that KINK manages to use 2 messages, which are (used to be) essentially a quick mode exchange. It uses kerberos to handle the replay attacks, which involves timestamps. There are surely other ways of addressing the replay issue, like a counter or something else. If we could use two messages for quick mode, that would solve all this commit-bit versus 'when to install the resources' issues.... jan > I am not so concerned with the resources in an attack, but more worried > about an attacker potentially getting an SA into the system that could > be exploited. I don't see how this could be done today (all I can see > is the obvious replay attack Dan is talking about), but that doesn't > mean that such an exploit doesn't exist. So, I am much more comfortable > with the one extra packet and the assurance that everything is ok with > the negotiation before SAs are added. > > Of course, if someone has a proof that the security can't be violated by > adding the responder SAs early, then I'd agree to eliminating the commit > bit (except for backwards compatibility, when we'd still need to support > it). > > bs > > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Wednesday, August 08, 2001 10:49 AM > To: Ari Huttunen > Cc: ipsec@lists.tislabs.com > Subject: Re: Simplifying IKE > > My tentative text on the subject is to get rid of the commit bit and > have a 3 message exchange. The problem with the existing 3 message > exchanage (w/o the commit bit being used) is that the Responder will not > instantiate her SAs until receipt of the 3rd message from the Initiator > to avoid a resource consumption attack but the Initiator will > instantiate > his SAs upon receipt of the 2nd message from the Responder. This results > in a race between the first few IPsec-protected packets and the final > message. If the former win they get dropped. > > My proposal is that the Responder instantiate the SAs when she sends > the 2nd message back to the Initiator. She will be setting a timer to > deal with non-receipt of the 3rd message and if the timer fires > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > and she can delete these SAs from her SADB. > > In addition to this text there is new text instructing implementations > to deal with receipt of an offer to create an IPsec SA with a SPI that > is currently in use as an error, and new text instructing the Initiator > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in > case > it is dropped and he receives a retransmitted 2nd message from the > Responder. > > This is much simpler than what we have and solves the race problem. > What it does, though, is allow for some resources to be temporarily > consumed due to the replay of an old message. I don't view this as that > big of a problem though since it is temporary (RETRANSMIT_TIME * > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in > the SADB) and the number of possible packets that can be replayed is > limited and bounded by the life of the IKE SA. > > Thoughts? > > Dan. > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > > > Dan McDonald wrote: > > > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > > > Can we drop the commit bit? > > > > > > Who uses it? > > > > I guess someone in past figured out that running IKE on satellite > lines > > is necessary, so they decided to optimize as much as possible. The > result > > was that both aggressive mode and quick mode both have three messages. > > The problem with three messages is that the initiator will often start > sendin > >g > > actual traffic too soon, or quick mode packets, before the responder > is ready > >. Thus > > the need for packet buffers, commit bit, whatever. This optimization > causes d > >esign > > complications that I'd very much prefer to get rid of. > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Aug 8 15:18:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78MIwN21541; Wed, 8 Aug 2001 15:18:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20171 Wed, 8 Aug 2001 17:33:19 -0400 (EDT) From: "Scott G. Kelly" To: Derrell Piper Cc: Ari Huttunen , Dan McDonald , Sandy Harris , ipsec@lists.tislabs.com Message-ID: <3B71B1E3.C618C83A@redcreek.com> Date: Wed, 08 Aug 2001 14:40:51 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Simplifying IKE References: <200108080219.f782JIp00242@kebe.east.sun.com> <3B710406.1175A60@F-Secure.com> <461410.997253930@el-air-1.electric-loft.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Derrell - if you remove commit bit, you must add a mandatory fourth qm message (which would be fine with me). Scott Derrell Piper wrote: > > The other property that commit-bit processing buys you is that the third > message of QM is now protected by the IKE retransmit timer and thus QM is > guaranteed to complete enough for both sides to generate IPsec SA's, even > when the last message (the ISAKMP Notify "CONNECTED") is lost. If you > don't use commit-bit processing, the last message of QM can be dropped and > this leaves you in the particularly bad state where one side has SA's and > the other doesn't. > > Personally, I would rather burn a full network exchange to ensure that my > really expensive key agreement protocol actually completes instead of > having to just hope that the network didn't drop my last packet, which is > what you're betting on today when you don't use the commit-bit. > > Derrell > > --On Wednesday, August 8, 2001 12:19 PM +0300 Ari Huttunen > wrote: > > >> > Can we drop the commit bit? > >> > >> Who uses it? > > > > I guess someone in past figured out that running IKE on satellite lines > > is necessary, so they decided to optimize as much as possible. The result > > was that both aggressive mode and quick mode both have three messages. > > The problem with three messages is that the initiator will often start > > sending actual traffic too soon, or quick mode packets, before the > > responder is ready. Thus the need for packet buffers, commit bit, > > whatever. This optimization causes design complications that I'd very > > much prefer to get rid of. > > > > Thus my preference would be to have a four packet phase 1 (base mode) and > > a four packet quick mode. > > > > The other reason I prefer base mode is that the responder can select the > > proper policy based on the first packet. > > > > If main mode had the possibility to send a group identity in packet one > > and actual identity in packet five, I wouldn't object to just having main > > mode, since it does have an even number of packets. From owner-ipsec@lists.tislabs.com Wed Aug 8 16:30:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78NU7N24901; Wed, 8 Aug 2001 16:30:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20336 Wed, 8 Aug 2001 18:40:57 -0400 (EDT) Message-ID: From: "Treleaven, Russell" To: ipsec@lists.tislabs.com Subject: pki alt-subject and unstructured name Date: Wed, 8 Aug 2001 15:47:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am trying to locate the authoritative document regarding alt-subject and unstructured name fields in x509 certificates. What I'm trying to find out is how they are used to map enrollment requests from one scep server to multiple ca's? Sincerely, Russell Treleaven Intel Canada From owner-ipsec@lists.tislabs.com Wed Aug 8 19:22:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f792MHN27319; Wed, 8 Aug 2001 19:22:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20741 Wed, 8 Aug 2001 21:25:40 -0400 (EDT) Message-Id: <200108090131.f791VhT00646@dharkins@lounge.orgatty.lounge.org> To: "sankar ramamoorthi" Cc: "Ari Huttunen" , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Your message of "Wed, 08 Aug 2001 13:31:43 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <643.997320703.1@lounge.org> Date: Wed, 08 Aug 2001 18:31:43 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 08 Aug 2001 13:31:43 PDT you wrote > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > > Sent: Wednesday, August 08, 2001 10:49 AM > > To: Ari Huttunen > > Cc: ipsec@lists.tislabs.com > > Subject: Re: Simplifying IKE > > > > > > My tentative text on the subject is to get rid of the commit bit and > > have a 3 message exchange. The problem with the existing 3 message > > exchanage (w/o the commit bit being used) is that the Responder will not > > instantiate her SAs until receipt of the 3rd message from the Initiator > > to avoid a resource consumption attack but the Initiator will instantiate > > his SAs upon receipt of the 2nd message from the Responder. This results > > in a race between the first few IPsec-protected packets and the final > > message. If the former win they get dropped. > > > > My proposal is that the Responder instantiate the SAs when she sends > > the 2nd message back to the Initiator. She will be setting a timer to > > deal with non-receipt of the 3rd message and if the timer fires > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > > and she can delete these SAs from her SADB. > > What happens if the initiator starts sending data before the responder > receives the third message? Nothing. That's the whole idea. > Will the ipsec packet from initiator be processed since responder has > established the SA on receipt of the second message? If so, can the > responder treat succesful processing of the data packet as succesful > authentication of the initiator and mark the SA as valid(basically > treat the condition same as processing a successful third message). I prefer not to make such a linkage (between the IPsec processing engine and the key management system) since there is still a message that IKE must process and receipt of that message will dictate whether the SAs stay or go. > Personally I prefer a 4 packet exchange model for QM. What shortcoming in the scheme I described is solved with a 4 packet exchange? Dan. From owner-ipsec@lists.tislabs.com Wed Aug 8 19:32:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f792WnN27457; Wed, 8 Aug 2001 19:32:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20713 Wed, 8 Aug 2001 21:19:39 -0400 (EDT) Message-Id: <200108090125.f791PcT00595@dharkins@lounge.orgatty.lounge.org> To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Your message of "Wed, 08 Aug 2001 15:39:32 EDT." <200108081939.f78JdWr11860@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <592.997320338.1@lounge.org> Date: Wed, 08 Aug 2001 18:25:38 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 08 Aug 2001 15:39:32 EDT you wrote > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Dan" == Dan Harkins writes: > Dan> The problem with MIPv6 is that the Binding Update is a destination > Dan> option which they would like authenticated. But there is no way for > Dan> an IPsec selector to be defined to identify certain types of destin >ation > Dan> options. The choice is to authenticate _everything_ which they don' >t > Dan> want to do or authenticate _nothing_ which they can't do. This has > Dan> nothing to do with IKE. > > Well, there is no standard way. > > Within a unified stack, (not BITW or BITS) the packets with the binding > update can easily be marked for IPsec processor via out-of-band means > (i.e. in the control structure). Then the problem is on the other end. The selector either says every packet _MUST_ be IPsec-protected or else it _MUST NOT_ be IPsec-protected. Either way, if some packets--those with Binding Updates-- are received with IPsec protection and others-- those without Binding Updates-- are not then we're going to have a problem. Dan. From owner-ipsec@lists.tislabs.com Wed Aug 8 19:34:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f792Y0N27476; Wed, 8 Aug 2001 19:34:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20779 Wed, 8 Aug 2001 21:36:55 -0400 (EDT) Message-Id: <200108090142.f791glT00666@dharkins@lounge.orgatty.lounge.org> To: Jan Vilhuber Cc: Brian Swander , Ari Huttunen , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Your message of "Wed, 08 Aug 2001 13:57:15 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <663.997321367.1@lounge.org> Date: Wed, 08 Aug 2001 18:42:47 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why is one mandated processing of packets a solution and another a "work around"? If the "work around" solves the problem in one less message then why isn't that preferable? Wouldn't adding a timestamp to the exchange be a "kludge"? Or a "work around"? The only reason the Responder doesn't instantiate the SAs after sending the 2nd message today is because of concerns about a resource consumption attack. I feel those concerns are small due to the small time in which the bogus SAs would be in the SADB, the inability of an attacker to use them (due to the inability of a 3rd party to know SKEYID state), and the small (and quantifiable) number of messages that can possibly be exchanged. Instantiate them and delete them if the 3rd message is never received! So we have very few messages which can be replayed and a well-defined method of dealing with the cases in which they are replayed. Why is that not satisfactory? What is the problem with this that is solved by adding a 4th message? Dan. On Wed, 08 Aug 2001 13:57:15 PDT you wrote > I'd actually prefer to formalize the concept that the commit-bit is trying to > address: > > 1) Either expand quick mode to 4 messages. That's unambiguous, and leads to > better interop. A commit bit is really a kludge. > > 2) If you think about it, the 3rd message is only needed to prevent replay > attacks of old messages. If we addressed this some other way (say a timestamp > field, but that has obvious other problems), then we could drop the 3rd > message, and have 2, which is again 'good (tm)'. > > Dan also outlined some other ways to address this problem, and while they > work, I don't much care for them, since they're really work-arounds to the > problem above. It would be preferable to address the replay attacks in some > other way (if possible) and do away with the 3rd message, or bite the bullet > and create a 4th message as an ACK to make the exchange as unambiguous as > possible. > > I point out that KINK manages to use 2 messages, which are (used to be) > essentially a quick mode exchange. It uses kerberos to handle the replay > attacks, which involves timestamps. There are surely other ways of addressing > the replay issue, like a counter or something else. If we could use two > messages for quick mode, that would solve all this commit-bit versus 'when to > install the resources' issues.... > > jan > > > > > I am not so concerned with the resources in an attack, but more worried > > about an attacker potentially getting an SA into the system that could > > be exploited. I don't see how this could be done today (all I can see > > is the obvious replay attack Dan is talking about), but that doesn't > > mean that such an exploit doesn't exist. So, I am much more comfortable > > with the one extra packet and the assurance that everything is ok with > > the negotiation before SAs are added. > > > > Of course, if someone has a proof that the security can't be violated by > > adding the responder SAs early, then I'd agree to eliminating the commit > > bit (except for backwards compatibility, when we'd still need to support > > it). > > > > bs > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@lounge.org] > > Sent: Wednesday, August 08, 2001 10:49 AM > > To: Ari Huttunen > > Cc: ipsec@lists.tislabs.com > > Subject: Re: Simplifying IKE > > > > My tentative text on the subject is to get rid of the commit bit and > > have a 3 message exchange. The problem with the existing 3 message > > exchanage (w/o the commit bit being used) is that the Responder will not > > instantiate her SAs until receipt of the 3rd message from the Initiator > > to avoid a resource consumption attack but the Initiator will > > instantiate > > his SAs upon receipt of the 2nd message from the Responder. This results > > in a race between the first few IPsec-protected packets and the final > > message. If the former win they get dropped. > > > > My proposal is that the Responder instantiate the SAs when she sends > > the 2nd message back to the Initiator. She will be setting a timer to > > deal with non-receipt of the 3rd message and if the timer fires > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > > and she can delete these SAs from her SADB. > > > > In addition to this text there is new text instructing implementations > > to deal with receipt of an offer to create an IPsec SA with a SPI that > > is currently in use as an error, and new text instructing the Initiator > > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in > > case > > it is dropped and he receives a retransmitted 2nd message from the > > Responder. > > > > This is much simpler than what we have and solves the race problem. > > What it does, though, is allow for some resources to be temporarily > > consumed due to the replay of an old message. I don't view this as that > > big of a problem though since it is temporary (RETRANSMIT_TIME * > > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in > > the SADB) and the number of possible packets that can be replayed is > > limited and bounded by the life of the IKE SA. > > > > Thoughts? > > > > Dan. > > > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > > > > > Dan McDonald wrote: > > > > > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > > > > > Can we drop the commit bit? > > > > > > > > Who uses it? > > > > > > I guess someone in past figured out that running IKE on satellite > > lines > > > is necessary, so they decided to optimize as much as possible. The > > result > > > was that both aggressive mode and quick mode both have three messages. > > > The problem with three messages is that the initiator will often start > > sendin > > >g > > > actual traffic too soon, or quick mode packets, before the responder > > is ready > > >. Thus > > > the need for packet buffers, commit bit, whatever. This optimization > > causes d > > >esign > > > complications that I'd very much prefer to get rid of. > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Wed Aug 8 19:54:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f792sSN27876; Wed, 8 Aug 2001 19:54:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20847 Wed, 8 Aug 2001 21:57:50 -0400 (EDT) From: "sankar ramamoorthi" To: "Dan Harkins" Cc: "Ari Huttunen" , Subject: RE: Simplifying IKE Date: Wed, 8 Aug 2001 19:04:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200108090131.f791VhT00646@dharkins@lounge.orgatty.lounge.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Wednesday, August 08, 2001 6:32 PM > To: sankar ramamoorthi > Cc: Ari Huttunen; ipsec@lists.tislabs.com > Subject: Re: Simplifying IKE > > > On Wed, 08 Aug 2001 13:31:43 PDT you wrote > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > > > Sent: Wednesday, August 08, 2001 10:49 AM > > > To: Ari Huttunen > > > Cc: ipsec@lists.tislabs.com > > > Subject: Re: Simplifying IKE > > > > > > > > > My tentative text on the subject is to get rid of the commit bit and > > > have a 3 message exchange. The problem with the existing 3 message > > > exchanage (w/o the commit bit being used) is that the > Responder will not > > > instantiate her SAs until receipt of the 3rd message from the > Initiator > > > to avoid a resource consumption attack but the Initiator will > instantiate > > > his SAs upon receipt of the 2nd message from the Responder. > This results > > > in a race between the first few IPsec-protected packets and the final > > > message. If the former win they get dropped. > > > > > > My proposal is that the Responder instantiate the SAs when she sends > > > the 2nd message back to the Initiator. She will be setting a timer to > > > deal with non-receipt of the 3rd message and if the timer fires > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > > > and she can delete these SAs from her SADB. > > > > What happens if the initiator starts sending data before the responder > > receives the third message? > > Nothing. That's the whole idea. which means in the worst case packets from the sender will be dropped for the duration (RETRANSMIT_TIMER_LIMIT * round-trip-time). This leads to an ambiguous state where the packets may or not be dropped by the responder. It is also possible that if initiator is sending data at a high rate, it could affect the responder from retransmitting message2 and getting message3. With a 4 packet exhange scheme, each party knows for sure the other side has the SA established before sending data. The state transitions seem to be much cleaner here. Both solutions require that the COMFORT_LEVEL_TIME is set be greater than equal to (RETRANSMIT_TIMER_LIMIT * round-trip-time) to ensure the initiator keeps the state around long enough for the responder to move from processed-message1-state to processed-message3-state (or processed-message2-state to processed-message4-state in the case of 4 packet exchange). > > > Will the ipsec packet from initiator be processed since responder has > > established the SA on receipt of the second message? If so, can the > > responder treat succesful processing of the data packet as succesful > > authentication of the initiator and mark the SA as valid(basically > > treat the condition same as processing a successful third message). > > I prefer not to make such a linkage (between the IPsec processing engine > and the key management system) since there is still a message > that IKE must > process and receipt of that message will dictate whether the SAs stay > or go. > I agree - this was just an idea that I threw around to see if it is possible to come up with a 2 message solution. > > Personally I prefer a 4 packet exchange model for QM. > > What shortcoming in the scheme I described is solved with a 4 packet > exchange? > see above. > Dan. > From owner-ipsec@lists.tislabs.com Wed Aug 8 19:57:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f792vtN28302; Wed, 8 Aug 2001 19:57:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20848 Wed, 8 Aug 2001 21:57:51 -0400 (EDT) Date: Wed, 8 Aug 2001 19:04:14 -0700 (PDT) From: Jan Vilhuber To: Dan Harkins cc: Brian Swander , Ari Huttunen , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <200108090142.f791glT00666@dharkins@lounge.orgatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Aug 2001, Dan Harkins wrote: > Why is one mandated processing of packets a solution and another a > "work around"? If the "work around" solves the problem in one less > message then why isn't that preferable? Wouldn't adding a timestamp to > the exchange be a "kludge"? Or a "work around"? > As you say, both work. One strikes me as more aesthetically pleasing, or cleaner, i.e. a 4th message is part of the protocol, and you don't need much verbiage to tell people how to handle the sync between IKE and ipsec in a 3 message scenario. It's therefore much cleaner and offers better chances of passing interop (the more verbiage to explain something, the more you give people to argue what was meant by the verbiage). > The only reason the Responder doesn't instantiate the SAs after sending > the 2nd message today is because of concerns about a resource consumption > attack. I feel those concerns are small due to the small time in which > the bogus SAs would be in the SADB, the inability of an attacker to use > them (due to the inability of a 3rd party to know SKEYID state), and the > small (and quantifiable) number of messages that can possibly be exchanged. > Instantiate them and delete them if the 3rd message is never received! > Or wait for a 4th message to confirm. I grant you they are almost the same. > So we have very few messages which can be replayed and a well-defined > method of dealing with the cases in which they are replayed. Why is that > not satisfactory? What is the problem with this that is solved by adding > a 4th message? > It's an explicit ACK, rather than relying on implicit behaviour of lacking the 3rd message. It just strikes me as cleaner. it's all software. We can implement almost anything in software. Question is how. And obviously different people have different ideas of 'cleanliness' and different definition of 'obvious' (as we can tell from dangling SA and continuous channel fiascos). Telling IPSec to instantiate a single SA, and then later possibly revoking it, just doesn't seem as clean to me. I'd rather only tell ipsec to go ahead and do its thing when IKE is completely 100% sure that we're done. I also realize that KINK does what you propose. I didn't much like it there, either. So be it. The very fact that it has to be explained, rather than having a protocol definition, makes me nervous. But if it can be explained very simply, and you are confident that people won't find things they claim were open to interpretation (what do you mean I shouldn't delete my IPSec Sa's when the IKE SA that created them dies?! Duh...), then I'm OK with it. To put it a different way: Define the protocol, and when the protocol has unambiguously finished, THEN (and only then) tell ipsec to proceed. This doesn't leave things open to interpretation of exactly when one SA should be instantiated and when the next should be instantiated, and so on. Maybe I'm just being pedantic. Being pedantic should be a good thing right now, so we don't repeat the past with son-of-IKE (did we decide it's 'doud', pronounced 'dude'?? ;) Different folks, different strokes... jan > Dan. > > On Wed, 08 Aug 2001 13:57:15 PDT you wrote > > I'd actually prefer to formalize the concept that the commit-bit is trying to > > address: > > > > 1) Either expand quick mode to 4 messages. That's unambiguous, and leads to > > better interop. A commit bit is really a kludge. > > > > 2) If you think about it, the 3rd message is only needed to prevent replay > > attacks of old messages. If we addressed this some other way (say a timestamp > > field, but that has obvious other problems), then we could drop the 3rd > > message, and have 2, which is again 'good (tm)'. > > > > Dan also outlined some other ways to address this problem, and while they > > work, I don't much care for them, since they're really work-arounds to the > > problem above. It would be preferable to address the replay attacks in some > > other way (if possible) and do away with the 3rd message, or bite the bullet > > and create a 4th message as an ACK to make the exchange as unambiguous as > > possible. > > > > I point out that KINK manages to use 2 messages, which are (used to be) > > essentially a quick mode exchange. It uses kerberos to handle the replay > > attacks, which involves timestamps. There are surely other ways of addressing > > the replay issue, like a counter or something else. If we could use two > > messages for quick mode, that would solve all this commit-bit versus 'when to > > install the resources' issues.... > > > > jan > > > > > > > > > I am not so concerned with the resources in an attack, but more worried > > > about an attacker potentially getting an SA into the system that could > > > be exploited. I don't see how this could be done today (all I can see > > > is the obvious replay attack Dan is talking about), but that doesn't > > > mean that such an exploit doesn't exist. So, I am much more comfortable > > > with the one extra packet and the assurance that everything is ok with > > > the negotiation before SAs are added. > > > > > > Of course, if someone has a proof that the security can't be violated by > > > adding the responder SAs early, then I'd agree to eliminating the commit > > > bit (except for backwards compatibility, when we'd still need to support > > > it). > > > > > > bs > > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@lounge.org] > > > Sent: Wednesday, August 08, 2001 10:49 AM > > > To: Ari Huttunen > > > Cc: ipsec@lists.tislabs.com > > > Subject: Re: Simplifying IKE > > > > > > My tentative text on the subject is to get rid of the commit bit and > > > have a 3 message exchange. The problem with the existing 3 message > > > exchanage (w/o the commit bit being used) is that the Responder will not > > > instantiate her SAs until receipt of the 3rd message from the Initiator > > > to avoid a resource consumption attack but the Initiator will > > > instantiate > > > his SAs upon receipt of the 2nd message from the Responder. This results > > > in a race between the first few IPsec-protected packets and the final > > > message. If the former win they get dropped. > > > > > > My proposal is that the Responder instantiate the SAs when she sends > > > the 2nd message back to the Initiator. She will be setting a timer to > > > deal with non-receipt of the 3rd message and if the timer fires > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > > > and she can delete these SAs from her SADB. > > > > > > In addition to this text there is new text instructing implementations > > > to deal with receipt of an offer to create an IPsec SA with a SPI that > > > is currently in use as an error, and new text instructing the Initiator > > > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in > > > case > > > it is dropped and he receives a retransmitted 2nd message from the > > > Responder. > > > > > > This is much simpler than what we have and solves the race problem. > > > What it does, though, is allow for some resources to be temporarily > > > consumed due to the replay of an old message. I don't view this as that > > > big of a problem though since it is temporary (RETRANSMIT_TIME * > > > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in > > > the SADB) and the number of possible packets that can be replayed is > > > limited and bounded by the life of the IKE SA. > > > > > > Thoughts? > > > > > > Dan. > > > > > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > > > > > > > Dan McDonald wrote: > > > > > > > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > > > > > > > Can we drop the commit bit? > > > > > > > > > > Who uses it? > > > > > > > > I guess someone in past figured out that running IKE on satellite > > > lines > > > > is necessary, so they decided to optimize as much as possible. The > > > result > > > > was that both aggressive mode and quick mode both have three messages. > > > > The problem with three messages is that the initiator will often start > > > sendin > > > >g > > > > actual traffic too soon, or quick mode packets, before the responder > > > is ready > > > >. Thus > > > > the need for packet buffers, commit bit, whatever. This optimization > > > causes d > > > >esign > > > > complications that I'd very much prefer to get rid of. > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Aug 8 20:16:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f793G6N28663; Wed, 8 Aug 2001 20:16:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20891 Wed, 8 Aug 2001 22:11:23 -0400 (EDT) Date: Wed, 8 Aug 2001 19:17:52 -0700 (PDT) From: Jan Vilhuber To: Dan Harkins cc: Brian Swander , Ari Huttunen , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk P.S. I really would prefer a 2 message version, if some smart cookie out there can figure out how to guard against replay attacks. That would be the coolest... jan On Wed, 8 Aug 2001, Jan Vilhuber wrote: > On Wed, 8 Aug 2001, Dan Harkins wrote: > > > Why is one mandated processing of packets a solution and another a > > "work around"? If the "work around" solves the problem in one less > > message then why isn't that preferable? Wouldn't adding a timestamp to > > the exchange be a "kludge"? Or a "work around"? > > > As you say, both work. One strikes me as more aesthetically pleasing, or > cleaner, i.e. a 4th message is part of the protocol, and you don't need much > verbiage to tell people how to handle the sync between IKE and ipsec in a 3 > message scenario. It's therefore much cleaner and offers better chances of > passing interop (the more verbiage to explain something, the more you give > people to argue what was meant by the verbiage). > > > The only reason the Responder doesn't instantiate the SAs after sending > > the 2nd message today is because of concerns about a resource consumption > > attack. I feel those concerns are small due to the small time in which > > the bogus SAs would be in the SADB, the inability of an attacker to use > > them (due to the inability of a 3rd party to know SKEYID state), and the > > small (and quantifiable) number of messages that can possibly be exchanged. > > Instantiate them and delete them if the 3rd message is never received! > > > > Or wait for a 4th message to confirm. I grant you they are almost the same. > > > So we have very few messages which can be replayed and a well-defined > > method of dealing with the cases in which they are replayed. Why is that > > not satisfactory? What is the problem with this that is solved by adding > > a 4th message? > > > It's an explicit ACK, rather than relying on implicit behaviour of lacking > the 3rd message. It just strikes me as cleaner. it's all software. We can > implement almost anything in software. Question is how. And obviously > different people have different ideas of 'cleanliness' and different > definition of 'obvious' (as we can tell from dangling SA and continuous > channel fiascos). > > Telling IPSec to instantiate a single SA, and then later possibly revoking > it, just doesn't seem as clean to me. I'd rather only tell ipsec to go ahead > and do its thing when IKE is completely 100% sure that we're done. > > I also realize that KINK does what you propose. I didn't much like it there, > either. So be it. The very fact that it has to be explained, rather than > having a protocol definition, makes me nervous. But if it can be explained > very simply, and you are confident that people won't find things they claim > were open to interpretation (what do you mean I shouldn't delete my IPSec > Sa's when the IKE SA that created them dies?! Duh...), then I'm OK with it. > > To put it a different way: Define the protocol, and when the protocol has > unambiguously finished, THEN (and only then) tell ipsec to proceed. This > doesn't leave things open to interpretation of exactly when one SA should be > instantiated and when the next should be instantiated, and so on. Maybe I'm > just being pedantic. Being pedantic should be a good thing right now, so we > don't repeat the past with son-of-IKE (did we decide it's 'doud', pronounced > 'dude'?? ;) > > Different folks, different strokes... > jan > > > > > > > Dan. > > > > On Wed, 08 Aug 2001 13:57:15 PDT you wrote > > > I'd actually prefer to formalize the concept that the commit-bit is trying to > > > address: > > > > > > 1) Either expand quick mode to 4 messages. That's unambiguous, and leads to > > > better interop. A commit bit is really a kludge. > > > > > > 2) If you think about it, the 3rd message is only needed to prevent replay > > > attacks of old messages. If we addressed this some other way (say a timestamp > > > field, but that has obvious other problems), then we could drop the 3rd > > > message, and have 2, which is again 'good (tm)'. > > > > > > Dan also outlined some other ways to address this problem, and while they > > > work, I don't much care for them, since they're really work-arounds to the > > > problem above. It would be preferable to address the replay attacks in some > > > other way (if possible) and do away with the 3rd message, or bite the bullet > > > and create a 4th message as an ACK to make the exchange as unambiguous as > > > possible. > > > > > > I point out that KINK manages to use 2 messages, which are (used to be) > > > essentially a quick mode exchange. It uses kerberos to handle the replay > > > attacks, which involves timestamps. There are surely other ways of addressing > > > the replay issue, like a counter or something else. If we could use two > > > messages for quick mode, that would solve all this commit-bit versus 'when to > > > install the resources' issues.... > > > > > > jan > > > > > > > > > > > > > I am not so concerned with the resources in an attack, but more worried > > > > about an attacker potentially getting an SA into the system that could > > > > be exploited. I don't see how this could be done today (all I can see > > > > is the obvious replay attack Dan is talking about), but that doesn't > > > > mean that such an exploit doesn't exist. So, I am much more comfortable > > > > with the one extra packet and the assurance that everything is ok with > > > > the negotiation before SAs are added. > > > > > > > > Of course, if someone has a proof that the security can't be violated by > > > > adding the responder SAs early, then I'd agree to eliminating the commit > > > > bit (except for backwards compatibility, when we'd still need to support > > > > it). > > > > > > > > bs > > > > > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@lounge.org] > > > > Sent: Wednesday, August 08, 2001 10:49 AM > > > > To: Ari Huttunen > > > > Cc: ipsec@lists.tislabs.com > > > > Subject: Re: Simplifying IKE > > > > > > > > My tentative text on the subject is to get rid of the commit bit and > > > > have a 3 message exchange. The problem with the existing 3 message > > > > exchanage (w/o the commit bit being used) is that the Responder will not > > > > instantiate her SAs until receipt of the 3rd message from the Initiator > > > > to avoid a resource consumption attack but the Initiator will > > > > instantiate > > > > his SAs upon receipt of the 2nd message from the Responder. This results > > > > in a race between the first few IPsec-protected packets and the final > > > > message. If the former win they get dropped. > > > > > > > > My proposal is that the Responder instantiate the SAs when she sends > > > > the 2nd message back to the Initiator. She will be setting a timer to > > > > deal with non-receipt of the 3rd message and if the timer fires > > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > > > > and she can delete these SAs from her SADB. > > > > > > > > In addition to this text there is new text instructing implementations > > > > to deal with receipt of an offer to create an IPsec SA with a SPI that > > > > is currently in use as an error, and new text instructing the Initiator > > > > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in > > > > case > > > > it is dropped and he receives a retransmitted 2nd message from the > > > > Responder. > > > > > > > > This is much simpler than what we have and solves the race problem. > > > > What it does, though, is allow for some resources to be temporarily > > > > consumed due to the replay of an old message. I don't view this as that > > > > big of a problem though since it is temporary (RETRANSMIT_TIME * > > > > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in > > > > the SADB) and the number of possible packets that can be replayed is > > > > limited and bounded by the life of the IKE SA. > > > > > > > > Thoughts? > > > > > > > > Dan. > > > > > > > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > > > > > > > > > Dan McDonald wrote: > > > > > > > > > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > > > > > > > > > Can we drop the commit bit? > > > > > > > > > > > > Who uses it? > > > > > > > > > > I guess someone in past figured out that running IKE on satellite > > > > lines > > > > > is necessary, so they decided to optimize as much as possible. The > > > > result > > > > > was that both aggressive mode and quick mode both have three messages. > > > > > The problem with three messages is that the initiator will often start > > > > sendin > > > > >g > > > > > actual traffic too soon, or quick mode packets, before the responder > > > > is ready > > > > >. Thus > > > > > the need for packet buffers, commit bit, whatever. This optimization > > > > causes d > > > > >esign > > > > > complications that I'd very much prefer to get rid of. > > > > > > > > > > -- > > > Jan Vilhuber vilhuber@cisco.com > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Aug 9 01:41:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f798fcN26635; Thu, 9 Aug 2001 01:41:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21993 Thu, 9 Aug 2001 03:54:12 -0400 (EDT) Message-Id: <200108090800.f7980D700535@dharkins@lounge.orgatty.lounge.org> To: "sankar ramamoorthi" Cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Your message of "Wed, 08 Aug 2001 19:04:25 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <532.997344013.1@lounge.org> Date: Thu, 09 Aug 2001 01:00:13 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm obviously explaining myself poorly and that's not a good way to start of this discussion.... On Wed, 08 Aug 2001 19:04:25 PDT you wrote > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@lounge.org] > > Sent: Wednesday, August 08, 2001 6:32 PM > > To: sankar ramamoorthi > > Cc: Ari Huttunen; ipsec@lists.tislabs.com > > Subject: Re: Simplifying IKE > > > > > > On Wed, 08 Aug 2001 13:31:43 PDT you wrote > > > > -----Original Message----- > > > > From: owner-ipsec@lists.tislabs.com > > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > > > > Sent: Wednesday, August 08, 2001 10:49 AM > > > > To: Ari Huttunen > > > > Cc: ipsec@lists.tislabs.com > > > > Subject: Re: Simplifying IKE > > > > > > > > > > > > My tentative text on the subject is to get rid of the commit bit and > > > > have a 3 message exchange. The problem with the existing 3 message > > > > exchanage (w/o the commit bit being used) is that the > > Responder will not > > > > instantiate her SAs until receipt of the 3rd message from the > > Initiator > > > > to avoid a resource consumption attack but the Initiator will > > instantiate > > > > his SAs upon receipt of the 2nd message from the Responder. > > This results > > > > in a race between the first few IPsec-protected packets and the final > > > > message. If the former win they get dropped. > > > > > > > > My proposal is that the Responder instantiate the SAs when she sends > > > > the 2nd message back to the Initiator. She will be setting a timer to > > > > deal with non-receipt of the 3rd message and if the timer fires > > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > > > > and she can delete these SAs from her SADB. > > > > > > What happens if the initiator starts sending data before the responder > > > receives the third message? > > > > Nothing. That's the whole idea. > > which means in the worst case packets from the sender will be dropped for > the duration (RETRANSMIT_TIMER_LIMIT * round-trip-time). No, they are not dropped in any case. They are properly received because the Responder has instantiated the SAs before she sends the 2nd message. > This leads to an ambiguous state where the packets may or not be dropped > by the responder. It is also possible that if initiator is sending data > at a high rate, it could affect the responder from retransmitting message2 > and getting message3. No it doesn't matter how fast the Initiator sends packets (assuming you mean IPsec-protected packets) because the Responder will have properly instantiated SAs _before_ the Initiator has. By the time the Initiator has all the information to instantiate his own SAs the Responder will already have instantiated hers. No packet loss. > With a 4 packet exhange scheme, each party knows for sure the other side > has the SA established before sending data. The state transitions seem > to be much cleaner here. I think you're misunderstanding what I'm proposing. If the Responder instantiates her SAs when she sends the 2nd message then what's the problem? How does this not work? The Responder has SAs ready before the Initiator does so there is no packet loss. > > > Will the ipsec packet from initiator be processed since responder has > > > established the SA on receipt of the second message? If so, can the > > > responder treat succesful processing of the data packet as succesful > > > authentication of the initiator and mark the SA as valid(basically > > > treat the condition same as processing a successful third message). > > > > I prefer not to make such a linkage (between the IPsec processing engine > > and the key management system) since there is still a message > > that IKE must > > process and receipt of that message will dictate whether the SAs stay > > or go. > > > > I agree - this was just an idea that I threw around to see if > it is possible to come up with a 2 message solution. If you can come up with a 2 message solution I think we will all be happy. Please do so; I cannot come up with one that is simpler than the 3 message one I'm proposing. > > > Personally I prefer a 4 packet exchange model for QM. > > > > What shortcoming in the scheme I described is solved with a 4 packet > > exchange? > > > > see above. I don't see a shortcoming above. Can you describe to me a situation that will not work with what I propose but will work with a 4 message exchange? Dan. From owner-ipsec@lists.tislabs.com Thu Aug 9 01:41:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f798ffN26647; Thu, 9 Aug 2001 01:41:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21633 Thu, 9 Aug 2001 03:28:13 -0400 (EDT) Message-ID: <20010809073520.51370.qmail@web12304.mail.yahoo.com> Date: Thu, 9 Aug 2001 00:35:20 -0700 (PDT) From: Eva Jencusova Subject: Hash and Prf in IKE To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I have one problem with IKE, in RFC 2409 in section 3.2 is written: "prf(key, msg) is the keyed pseudo-random function-- often a keyed hash function" And in section 5: "Four different authentication methods are allowed with either Main Mode or Aggressive Mode-- digital signature, two forms of authentication with public key encryption, or pre-shared key. The value SKEYID is computed seperately for each authentication method. For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R)" - and here is the my problem problem prf function is used to generate HASH_I and HASH_R as a a keyed hash function and nowhere in the document I found what "hash(Ni_b|Nr_b)" means. Can anybody tell me? Thans, Eva Jencusova __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Aug 9 01:42:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f798gYN26666; Thu, 9 Aug 2001 01:42:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21639 Thu, 9 Aug 2001 03:31:10 -0400 (EDT) Message-ID: <00c401c120a6$e7688050$4e8d21d9@sfanninglaptop> From: "Scott Fanning" To: "Treleaven, Russell" , References: Subject: Re: pki alt-subject and unstructured name Date: Thu, 9 Aug 2001 00:42:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think the PKIX mailing list would be the place for that answer. Scott ----- Original Message ----- From: "Treleaven, Russell" To: Sent: Wednesday, August 08, 2001 3:47 PM Subject: pki alt-subject and unstructured name > Hi, > > I am trying to locate the authoritative document regarding alt-subject and > unstructured name fields in x509 certificates. > > What I'm trying to find out is how they are used to map enrollment requests > from one scep server to multiple ca's? > > Sincerely, > > Russell Treleaven > Intel Canada From owner-ipsec@lists.tislabs.com Thu Aug 9 03:27:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79ARAN03811; Thu, 9 Aug 2001 03:27:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA22602 Thu, 9 Aug 2001 05:39:47 -0400 (EDT) Message-Id: <200108090946.f799kJu76577@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Dan Harkins cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of Wed, 08 Aug 2001 11:02:33 PDT. <200108081802.f78I2XR00772@dharkins@lounge.orgatty.lounge.org> Date: Thu, 09 Aug 2001 11:46:19 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > ... The trouble of IPsec with MIPv6 is more IKE (the thing we are > supposed to simplify): obviously to run IKE phases 1 & 2 in order > to protect BUs (sometime a single small packet) is overkilling Well, not really, and none of the simplifications being proposed or planned for IKE would help MIPv6. => I disagree, it should help at least for other cases than the "random" correspondent, for instance for the mobile node to home agent home registration. The problem with MIPv6 is that the Binding Update is a destination option which they would like authenticated. => I believe you don't like piggybacking. I agree and it seems many of us too (cf. the thread about it in the mobileip mailing list). Just assume we have got the head of piggybacking... But there is no way for an IPsec selector to be defined to identify certain types of destination options. The choice is to authenticate _everything_ which they don't want to do or authenticate _nothing_ which they can't do. This has nothing to do with IKE. => if we may not hack a bit the definition of selectors (a thing which we have to fix for ICMPv6) we can put BUs in a payload (a new protocol or if we believe this is too expensive UDP with a well know port). This is an implementation detail, not a basic issue. While the overkill of a phase 1 and phase 2 to merely authenticate a single Binding Update is a problem the other, larger problem is that there is no global PKI to deal with authentication. => I agree but this is not a IPsec problem, i.e. if we need strong authentication and authorization then this can work only with a global PKI. Even a protocol (SKIP for instance) which could handle the key establishment in a single message-- definitely not overkill-- would not work because there is no global PKI to support it. => this shows this issue is out of the scope of IPsec, i.e. MIPv6 has a problem with the authentication/authorization requirement, not with IPsec itself. Unfortunately this disables quick but not dirty solutions like "just sign BUs"... But as I've said there are other contexts than the "random" correspondent so there is still in interest in the IPsec/MIPv6 discussion. Regards Francis.Dupont@enst-bretagne.fr PS: there are real advantages to be able to secure (with ESP in tunnel mode) the home agent to mobile node tunnel. HIP is a good candidate, the son of IKE (or others) will be compared with HIP for this task. Tests have shown that IKE has abyssal performance in this case but is the best available tool (for the security point of view). From owner-ipsec@lists.tislabs.com Thu Aug 9 03:27:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79ARAN03812; Thu, 9 Aug 2001 03:27:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA22624 Thu, 9 Aug 2001 05:46:41 -0400 (EDT) Message-ID: <3B725DA2.F1C63038@F-Secure.com> Date: Thu, 09 Aug 2001 12:53:38 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Jan Vilhuber , Brian Swander , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE References: <200108090142.f791glT00666@dharkins@lounge.orgatty.lounge.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > Why is one mandated processing of packets a solution and another a > "work around"? If the "work around" solves the problem in one less > message then why isn't that preferable? Wouldn't adding a timestamp to > the exchange be a "kludge"? Or a "work around"? > > The only reason the Responder doesn't instantiate the SAs after sending > the 2nd message today is because of concerns about a resource consumption > attack. I feel those concerns are small due to the small time in which > the bogus SAs would be in the SADB, the inability of an attacker to use > them (due to the inability of a 3rd party to know SKEYID state), and the > small (and quantifiable) number of messages that can possibly be exchanged. > Instantiate them and delete them if the 3rd message is never received! > > So we have very few messages which can be replayed and a well-defined > method of dealing with the cases in which they are replayed. Why is that > not satisfactory? What is the problem with this that is solved by adding > a 4th message? > > Dan. It would seem that both of these methods work, and I'd be relatively happy with either one of them. I would prefer 4 messages, because it feels cleaner. How about doing it this way: there are people on this list who verify protocols using formal methods and one main gripe we have is that IKE has been too hard to fully verify.. So.. Those people decide which alternative is easier to formally verify and we pick that one. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Aug 9 03:36:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79AaqN04756; Thu, 9 Aug 2001 03:36:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA22651 Thu, 9 Aug 2001 05:57:48 -0400 (EDT) Message-Id: <200108091003.f79A3iu76648@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sommerfeld@East.Sun.COM cc: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of Wed, 08 Aug 2001 14:35:42 EDT. <200108081835.f78IZhJ09105@thunk.east.sun.com> Date: Thu, 09 Aug 2001 12:03:44 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: AH or not-AH has nothing to do with VPN or end-to-end IPsec use. => the sub-thread is more about ESP tunnel mode vs. others. VPNs don't need AH at all, even you can do AH in tunnel mode this just adds bits for no benefit. Tunnel mode for end-to-end IPsec adds bits and removes some properties (cf your next statement). As Steve Bellovin has pointed out on numerous occasions, the IP header in transport-mode ESP can be "authenticated" merely by doing a compare of the source and destination addresses against static state in the SA... => this "authentication" by side effect is mandatory according to RFC 2401 5.2.1 step 2 but: - it doesn't work with tunnel mode - it covers only the source address, not enough for interesting cases like MIPv6 BUs (where both the care-of and the home addresses (two source addresses) have to be protected). I believe this is why AH is useful only for IPv6 (IPv4 options are not used/usable: no need to protect them). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Aug 9 03:55:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79AteN05635; Thu, 9 Aug 2001 03:55:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22711 Thu, 9 Aug 2001 06:15:41 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Geoffrey Huang'" , Subject: RE: (More) immediate changes to help interop problems? Date: Thu, 9 Aug 2001 11:10:04 +0100 Message-Id: <001401c120bc$02802ea0$a79321d9@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > So I've seen many messages concerning long-term development > for the next > IKE, but what happened to discussion on fixing some shortcomings that > immediately affect interoperability? Andrew K. mentioned a > few yesterday > during his presentation, but off the top of my head, I can > think of a few > ambiguities: > > - Rekeying/Ph. 1 Responder Lifetime > - Unreliable Delete/Notifies > - Optional Cert Request Payload > - Some way to detect dead peers/stale SAs > > I'm just thinking of issues in currently deployed scenarios... Didn't I mention all of the above in my presentation? (I know it wasn't in great depth, but we didn't make great use of our alloted time.) Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Thu Aug 9 04:19:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79BJFN06214; Thu, 9 Aug 2001 04:19:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22770 Thu, 9 Aug 2001 06:34:40 -0400 (EDT) From: "Geoffrey Huang" To: , Subject: RE: (More) immediate changes to help interop problems? Date: Thu, 9 Aug 2001 03:45:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <001401c120bc$02802ea0$a79321d9@andrewk3.ca.newbridge.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > So I've seen many messages concerning long-term development > > for the next > > IKE, but what happened to discussion on fixing some shortcomings that > > immediately affect interoperability? Andrew K. mentioned a > > few yesterday > > during his presentation, but off the top of my head, I can > > think of a few > > ambiguities: > > > > - Rekeying/Ph. 1 Responder Lifetime > > - Unreliable Delete/Notifies > > - Optional Cert Request Payload > > - Some way to detect dead peers/stale SAs > > > > I'm just thinking of issues in currently deployed scenarios... > > Didn't I mention all of the above in my presentation? (I know it wasn't in > great depth, but we didn't make great use of our alloted time.) You certainly did, as I mention above -- I'm just wondering why the discussion about this hasn't continued... -g > Andrew > ------------------------------------------- > Upon closer inspection, I saw that the line > dividing black from white was in fact a shade > of grey. As I drew nearer still, the grey area > grew larger. And then I was enlightened. > > From owner-ipsec@lists.tislabs.com Thu Aug 9 04:32:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79BWvN06524; Thu, 9 Aug 2001 04:32:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22797 Thu, 9 Aug 2001 06:43:00 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15218.27317.608127.580477@thomasm-u1.cisco.com> Date: Thu, 9 Aug 2001 03:49:25 -0700 (PDT) To: Francis Dupont Cc: Michael Thomas , Dan McDonald , Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <200108081601.f78G11u73217@givry.rennes.enst-bretagne.fr> References: <15217.19461.896582.163323@thomasm-u1.cisco.com> <200108081601.f78G11u73217@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > => but VPNs are the current market so if we remove everything not used > today only VPN stuff will remain. AH seems to be the first victim of > the "simplifying IKE" process and transport mode will be the second > (even if this has near nothing to do with the IKE issue and transport > mode is more primitive than tunnel mode: tunnel mode is used in VPNs > so it cannot be removed). IMHO this is just "remove everything we > don't like or don't use" but the net result can be a VPN only IPsec. This seems rather alarmist. I'm pretty convinced that most of the people who would like to see AH nuked aren't in favor of a VPN-only IPsec. In fact, I don't recall hearing anybody on this list make that suggestion. > => I disagree, the purpose of AH is the protection of payload > and headers (something ESP should not do because there already is AH) > and for a signaling protocol like MIPv6 AH is both simpler and cheaper] ESP-NULL shouldn't be any more expensive than AH. In fact, it should be cheaper since it just calls the hashing algorithm over a single block rather than having to deal with the bits and dregs that AH needs to omit. > to use. The trouble of IPsec with MIPv6 is more IKE (the thing we are > supposed to simplify): obviously to run IKE phases 1 & 2 in order > to protect BUs (sometime a single small packet) is overkilling That assumes you only care about BU's... > but it seems like a pretty vivid example of how more > options == more confusion of how they all work (or > don't work as the case were). > > => I disagree: AH for MIPv6 works, this is not deployable > (because of global PKI/authorization issue) and nor efficient > (as concrete tests have shown). And I believe we'll still see > IPsec and MIPv6 together in the future because IPsec only > provides a good security service in the network layer > (i.e. not everywhere but somewhere). ESP could work for BU's as well; I wrote a draft that describes how. I have yet to see something concrete that AH actually provides that ESP cannot. BTW: we don't need to burn a new protocol number for BU's to get it to work with IPsec: we could just make it a UDP packet. Mike From owner-ipsec@lists.tislabs.com Thu Aug 9 05:11:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79CB8N12339; Thu, 9 Aug 2001 05:11:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22962 Thu, 9 Aug 2001 07:27:17 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Jan Vilhuber'" Cc: Subject: RE: Simplifying IKE Date: Thu, 9 Aug 2001 12:25:06 +0100 Message-Id: <001601c120c6$13a309f0$a79321d9@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Guarding against replay attacks is easy. Just use draft-ietf-ipsec-antireplay-00.txt. I can see a rationale for 2, 3, or 4 message exchanges. It's just an engineering tradeoff. As soon as we start using the above draft, we can stop worrying about replayed messages. Therefore, the only thing to worry about is lost packets. Tim Jenkins pointed out a long time ago that you can't solve a packet loss problem by extending the exchange. There will always be a new last packet, and the last packet can't be ACK'ed, only NACK'ed. However, there is some value in delaying use of the SA until the peer has added in in order to avoid spurious INVALID-SPI messages that the peer might generate (although I might add that even these can be avoided if the IKE process pre-notifies the IPsec process of which SPIs are currently pending negotiation. However, if we add the replay protection and eliminate PFS then I don't see any particular reason why we couldn't make quick mode only 2 packets. If, over my strenuous objections, we still wanted to support PFS then a 3rd message would be required. And a 4th message if you want to make the exchange even (although I don't personally see the value of this argument). I have listed avoiding INVALID-SPI messages as the main reason for delaying use of the SA. Another would be avoiding the (small) wasted bandwidth of occasionally sending a message that the peer can't decrypt yet. Having the router drop the first packet of a flow is a common scenario on the Internet already; TCP will retransmit the packet soon enough. There is no reason to get paranoid about the ocasional lost packet here and there. If the peer had buffer space, it could save the message and decrypt it later. Delaying the use of the SA until the peer has ACK'ed doesn't fix the problem; it only potentially allows you to shift the storage buffer from the receiver to the sender. (If we snuff out the replay problem as I suggest then there is no possibility of a state-clogging attack, so it doesn't really matter which side has the buffer.) Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > Sent: Thursday, August 09, 2001 3:18 AM > To: Dan Harkins > Cc: Brian Swander; Ari Huttunen; ipsec@lists.tislabs.com > Subject: Re: Simplifying IKE > > > P.S. I really would prefer a 2 message version, if some smart > cookie out > there can figure out how to guard against replay attacks. > That would be the > coolest... > > jan > > > > On Wed, 8 Aug 2001, Jan Vilhuber wrote: > > > On Wed, 8 Aug 2001, Dan Harkins wrote: > > > > > Why is one mandated processing of packets a solution > and another a > > > "work around"? If the "work around" solves the problem in one less > > > message then why isn't that preferable? Wouldn't adding a > timestamp to > > > the exchange be a "kludge"? Or a "work around"? > > > > > As you say, both work. One strikes me as more aesthetically > pleasing, or > > cleaner, i.e. a 4th message is part of the protocol, and > you don't need much > > verbiage to tell people how to handle the sync between IKE > and ipsec in a 3 > > message scenario. It's therefore much cleaner and offers > better chances of > > passing interop (the more verbiage to explain something, > the more you give > > people to argue what was meant by the verbiage). > > > > > The only reason the Responder doesn't instantiate the > SAs after sending > > > the 2nd message today is because of concerns about a > resource consumption > > > attack. I feel those concerns are small due to the small > time in which > > > the bogus SAs would be in the SADB, the inability of an > attacker to use > > > them (due to the inability of a 3rd party to know SKEYID > state), and the > > > small (and quantifiable) number of messages that can > possibly be exchanged. > > > Instantiate them and delete them if the 3rd message is > never received! > > > > > > > Or wait for a 4th message to confirm. I grant you they are > almost the same. > > > > > So we have very few messages which can be replayed and > a well-defined > > > method of dealing with the cases in which they are > replayed. Why is that > > > not satisfactory? What is the problem with this that is > solved by adding > > > a 4th message? > > > > > It's an explicit ACK, rather than relying on implicit > behaviour of lacking > > the 3rd message. It just strikes me as cleaner. it's all > software. We can > > implement almost anything in software. Question is how. And > obviously > > different people have different ideas of 'cleanliness' and different > > definition of 'obvious' (as we can tell from dangling SA > and continuous > > channel fiascos). > > > > Telling IPSec to instantiate a single SA, and then later > possibly revoking > > it, just doesn't seem as clean to me. I'd rather only tell > ipsec to go ahead > > and do its thing when IKE is completely 100% sure that we're done. > > > > I also realize that KINK does what you propose. I didn't > much like it there, > > either. So be it. The very fact that it has to be > explained, rather than > > having a protocol definition, makes me nervous. But if it > can be explained > > very simply, and you are confident that people won't find > things they claim > > were open to interpretation (what do you mean I shouldn't > delete my IPSec > > Sa's when the IKE SA that created them dies?! Duh...), then > I'm OK with it. > > > > To put it a different way: Define the protocol, and when > the protocol has > > unambiguously finished, THEN (and only then) tell ipsec to > proceed. This > > doesn't leave things open to interpretation of exactly when > one SA should be > > instantiated and when the next should be instantiated, and > so on. Maybe I'm > > just being pedantic. Being pedantic should be a good thing > right now, so we > > don't repeat the past with son-of-IKE (did we decide it's > 'doud', pronounced > > 'dude'?? ;) > > > > Different folks, different strokes... > > jan > > > > > > > > > > > > > Dan. > > > > > > On Wed, 08 Aug 2001 13:57:15 PDT you wrote > > > > I'd actually prefer to formalize the concept that the > commit-bit is trying to > > > > address: > > > > > > > > 1) Either expand quick mode to 4 messages. That's > unambiguous, and leads to > > > > better interop. A commit bit is really a kludge. > > > > > > > > 2) If you think about it, the 3rd message is only > needed to prevent replay > > > > attacks of old messages. If we addressed this some > other way (say a timestamp > > > > field, but that has obvious other problems), then we > could drop the 3rd > > > > message, and have 2, which is again 'good (tm)'. > > > > > > > > Dan also outlined some other ways to address this > problem, and while they > > > > work, I don't much care for them, since they're really > work-arounds to the > > > > problem above. It would be preferable to address the > replay attacks in some > > > > other way (if possible) and do away with the 3rd > message, or bite the bullet > > > > and create a 4th message as an ACK to make the exchange > as unambiguous as > > > > possible. > > > > > > > > I point out that KINK manages to use 2 messages, which > are (used to be) > > > > essentially a quick mode exchange. It uses kerberos to > handle the replay > > > > attacks, which involves timestamps. There are surely > other ways of addressing > > > > the replay issue, like a counter or something else. If > we could use two > > > > messages for quick mode, that would solve all this > commit-bit versus 'when to > > > > install the resources' issues.... > > > > > > > > jan > > > > > > > > > > > > > > > > > I am not so concerned with the resources in an > attack, but more worried > > > > > about an attacker potentially getting an SA into the > system that could > > > > > be exploited. I don't see how this could be done > today (all I can see > > > > > is the obvious replay attack Dan is talking about), > but that doesn't > > > > > mean that such an exploit doesn't exist. So, I am > much more comfortable > > > > > with the one extra packet and the assurance that > everything is ok with > > > > > the negotiation before SAs are added. > > > > > > > > > > Of course, if someone has a proof that the security > can't be violated by > > > > > adding the responder SAs early, then I'd agree to > eliminating the commit > > > > > bit (except for backwards compatibility, when we'd > still need to support > > > > > it). > > > > > > > > > > bs > > > > > > > > > > -----Original Message----- > > > > > From: Dan Harkins [mailto:dharkins@lounge.org] > > > > > Sent: Wednesday, August 08, 2001 10:49 AM > > > > > To: Ari Huttunen > > > > > Cc: ipsec@lists.tislabs.com > > > > > Subject: Re: Simplifying IKE > > > > > > > > > > My tentative text on the subject is to get rid of > the commit bit and > > > > > have a 3 message exchange. The problem with the > existing 3 message > > > > > exchanage (w/o the commit bit being used) is that the > Responder will not > > > > > instantiate her SAs until receipt of the 3rd message > from the Initiator > > > > > to avoid a resource consumption attack but the Initiator will > > > > > instantiate > > > > > his SAs upon receipt of the 2nd message from the > Responder. This results > > > > > in a race between the first few IPsec-protected > packets and the final > > > > > message. If the former win they get dropped. > > > > > > > > > > My proposal is that the Responder instantiate the > SAs when she sends > > > > > the 2nd message back to the Initiator. She will be > setting a timer to > > > > > deal with non-receipt of the 3rd message and if the > timer fires > > > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared > to have failed > > > > > and she can delete these SAs from her SADB. > > > > > > > > > > In addition to this text there is new text > instructing implementations > > > > > to deal with receipt of an offer to create an IPsec > SA with a SPI that > > > > > is currently in use as an error, and new text > instructing the Initiator > > > > > to hold on to the 3rd phase 2 message for some > COMFORT_LEVEL_TIME in > > > > > case > > > > > it is dropped and he receives a retransmitted 2nd > message from the > > > > > Responder. > > > > > > > > > > This is much simpler than what we have and solves > the race problem. > > > > > What it does, though, is allow for some resources to > be temporarily > > > > > consumed due to the replay of an old message. I don't > view this as that > > > > > big of a problem though since it is temporary > (RETRANSMIT_TIME * > > > > > RETRANSMIT_TIMER_LIMIT = total seconds these bogus > SAs would stay in > > > > > the SADB) and the number of possible packets that can > be replayed is > > > > > limited and bounded by the life of the IKE SA. > > > > > > > > > > Thoughts? > > > > > > > > > > Dan. > > > > > > > > > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > > > > > > > > > > > Dan McDonald wrote: > > > > > > > > > > > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > > > > > > > > > > > Can we drop the commit bit? > > > > > > > > > > > > > > Who uses it? > > > > > > > > > > > > I guess someone in past figured out that running > IKE on satellite > > > > > lines > > > > > > is necessary, so they decided to optimize as much > as possible. The > > > > > result > > > > > > was that both aggressive mode and quick mode both > have three messages. > > > > > > The problem with three messages is that the > initiator will often start > > > > > sendin > > > > > >g > > > > > > actual traffic too soon, or quick mode packets, > before the responder > > > > > is ready > > > > > >. Thus > > > > > > the need for packet buffers, commit bit, whatever. > This optimization > > > > > causes d > > > > > >esign > > > > > > complications that I'd very much prefer to get rid of. > > > > > > > > > > > > > -- > > > > Jan Vilhuber > vilhuber@cisco.com > > > > Cisco Systems, San Jose > (408) 527-0847 > > > > > > > > > > > -- > > Jan Vilhuber > vilhuber@cisco.com > > Cisco Systems, San Jose > (408) 527-0847 > > > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > From owner-ipsec@lists.tislabs.com Thu Aug 9 05:12:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79CClN13205; Thu, 9 Aug 2001 05:12:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22986 Thu, 9 Aug 2001 07:32:33 -0400 (EDT) From: "Lars Eggert" To: Subject: RE: Simplifying IKE Date: Thu, 9 Aug 2001 12:34:07 -0000 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200108091003.f79A3iu76648@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; boundary="----=_NextPart_000_0036_01C120CF.93FCEC70"; micalg=SHA1; protocol="application/x-pkcs7-signature" Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C120CF.93FCEC70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > As Steve Bellovin has pointed out on numerous occasions, the IP header > in transport-mode ESP can be "authenticated" merely by doing a compare > of the source and destination addresses against static state in the > SA... > > => this "authentication" by side effect is mandatory according to RFC > 2401 5.2.1 step 2 but: > - it doesn't work with tunnel mode I'm probably missing something obvious, but why doesn't comparing the SA against the (two) IP headers work for tunnel mode? Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California ------=_NextPart_000_0036_01C120CF.93FCEC70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF9DCCAtgw ggJBoAMCAQICAwMjBTANBgkqhkiG9w0BAQQFADCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAx OTk5LjkuMTYwHhcNMDAwODI0MjAzMDA4WhcNMDEwODI0MjAzMDA4WjBUMQ8wDQYDVQQEEwZFZ2dl cnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MRwwGgYJKoZIhvcNAQkBFg1s YXJzZUBpc2kuZWR1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPXJ9w2zneu+G7DyBIO+vb 7+yc/wZ25hjvHtaQl3K9zBviiKk2lZgiQwY/bXhm/UquC+e0Zob6N66AAZC3SfrhW6yBwjNDpANG 2cyB1ANMCRVJDZ4tFJCRr6cA/HpIUomDv1YQQeaApAEy1l0wFi1i/+ZM5ymbuNMlWD7tbqfThQID AQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMBgGA1Ud EQQRMA+BDWxhcnNlQGlzaS5lZHUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQCLrl8z+NIJo+FGgD0lblfYWS1IWETnOQikVU+m /fcZY882udywrXcd9mazQHWs3La9TtSEUj++wlCAEnJ9+QsWAwKOne5Fm8EGMYPWrjKMM7nJ8wyO q6oGlm1GnmineVN3TV9oDnxkIHmzEJvQ5FLG9dHy1z0Mk7QkilAgtrq8gDCCAxQwggJ9oAMCAQIC AQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsT H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQswCQYDVQQGEwJaQTEVMBMGA1UE CBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0w GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGc I3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc 9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8C AwEAAaM3MDUwEgYDVR0TAQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH 58ayDjANBgkqhkiG9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKl N9idtxcoVgWL3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLk XJeu/H6syg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAq4wggKqAgEBMIGcMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAyMFMAkGBSsOAwIaBQCgggFnMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDgwOTEyMzQwNVowIwYJKoZI hvcNAQkEMRYEFJXi3mG1xK0G2gPR+sl7A3yv2jntMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIGtBgkrBgEEAYI3EAQxgZ8wgZwwgZQxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMTk5 OS45LjE2AgMDIwUwDQYJKoZIhvcNAQEBBQAEgYBWSmILxu1I77JL7yaoSQsmq9he0XPBAuqqDvm4 HMTQCoSbWH8uPbR1hLywRhGAjXKNDhd5k3KxQt46duL8vRH4qX9p6kn0bVtCobQO/ocp3GQ1N1Z5 iqbEbz5/nBIv214EsD4kZYUzC7XIf1aXNMpZBso0e56bjbYeKsYZiYGDQwAAAAAAAA== ------=_NextPart_000_0036_01C120CF.93FCEC70-- From owner-ipsec@lists.tislabs.com Thu Aug 9 05:18:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79CIDN14167; Thu, 9 Aug 2001 05:18:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23008 Thu, 9 Aug 2001 07:37:38 -0400 (EDT) Message-ID: <008e01c120c8$3ce25b20$700110ac@roc.com> Reply-To: "jyothi" From: "jyothi" To: Subject: Position of certificate payload in IKE Aggressive Mode as Initiator Date: Thu, 9 Aug 2001 17:11:31 +0530 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Kindly clarify the following doubt. Scenario : IKE Phase 1 Negotiation (Aggressive Mode) authenticated with signatures As an Initiator, can the certificate payload be sent in first message or is it mandatory to be sent in third message only. In the subsection Certificate Payload of section ISAKMP Payloads contained in RFC 2408, the following statement is present. "The Certificate Payload MUST be accepted at any point during an exchange". I understand from this statement that the responder has to accept Certificate payload either in first message or third message, which in turn provides the base for the assunption that initiator can send the certificate payload in first msg or third msg. thanks sankar From owner-ipsec@lists.tislabs.com Thu Aug 9 05:49:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79CnvN15347; Thu, 9 Aug 2001 05:49:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23053 Thu, 9 Aug 2001 07:47:47 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Dan McDonald'" , "'Sandy Harris'" Cc: Subject: RE: Simplifying IKE Date: Thu, 9 Aug 2001 12:45:38 +0100 Message-Id: <001801c120c8$eb0361e0$a79321d9@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <200108080219.f782JIp00242@kebe.east.sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > 4. modify ESP to ensure it authenticates all data used in > the deciphering > > of the payload > > > > This is the only recommendation in this paper based on a > direct security > > flaw, with a proposed attack to demonstrate it. There are > others in the > > Simpson paper. > > And if you use Choice 3a above, you get this for free - AH > covers the whole > ESP datagram, SPI/IV/etc. If my memory serves me correctly, Ferguson/Schneier were actually suggesting that 1. encryption be applied AFTER authentication or, failing that, that 2. the encryption/decryption key be included in the data which is hashed This is to prevent an esoteric attack they describe which is infeasible and wouldn't cause any damage anyway. That is not a compelling reason to redesign ESP. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Thu Aug 9 05:50:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79Co0N15356; Thu, 9 Aug 2001 05:50:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23052 Thu, 9 Aug 2001 07:47:46 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Dan Harkins'" Cc: Subject: RE: Simplifying IKE Date: Thu, 9 Aug 2001 12:33:52 +0100 Message-Id: <001701c120c8$e7b659c0$a79321d9@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <200108081749.f78HmtR00738@dharkins@lounge.orgatty.lounge.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In addition to this text there is [...] > new text instructing the > Initiator > to hold on to the 3rd phase 2 message for some > COMFORT_LEVEL_TIME in case > it is dropped and he receives a retransmitted 2nd message from the > Responder. > > This is much simpler than what we have and solves the race problem. > What it does, though, is allow for some resources to be temporarily > consumed due to the replay of an old message. I don't view > this as that > big of a problem though since it is temporary (RETRANSMIT_TIME * > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in > the SADB) and the number of possible packets that can be replayed is > limited and bounded by the life of the IKE SA. This is in fact what my implementation has been doing for quite some time. I had never thought that this "new behaviour" was disallowed by the existing RFCs. It seemed like the logical thing to do... But as I pointed out in another message, the replay problem should still be quenched at the source by providing a counter. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Wednesday, August 08, 2001 6:49 PM > To: Ari Huttunen > Cc: ipsec@lists.tislabs.com > Subject: Re: Simplifying IKE > > > My tentative text on the subject is to get rid of the commit bit and > have a 3 message exchange. The problem with the existing 3 message > exchanage (w/o the commit bit being used) is that the > Responder will not > instantiate her SAs until receipt of the 3rd message from the > Initiator > to avoid a resource consumption attack but the Initiator will > instantiate > his SAs upon receipt of the 2nd message from the Responder. > This results > in a race between the first few IPsec-protected packets and the final > message. If the former win they get dropped. > > My proposal is that the Responder instantiate the SAs when she sends > the 2nd message back to the Initiator. She will be setting a timer to > deal with non-receipt of the 3rd message and if the timer fires > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > and she can delete these SAs from her SADB. > > In addition to this text there is new text instructing > implementations > to deal with receipt of an offer to create an IPsec SA with a SPI that > is currently in use as an error, and new text instructing the > Initiator > to hold on to the 3rd phase 2 message for some > COMFORT_LEVEL_TIME in case > it is dropped and he receives a retransmitted 2nd message from the > Responder. > > This is much simpler than what we have and solves the race problem. > What it does, though, is allow for some resources to be temporarily > consumed due to the replay of an old message. I don't view > this as that > big of a problem though since it is temporary (RETRANSMIT_TIME * > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in > the SADB) and the number of possible packets that can be replayed is > limited and bounded by the life of the IKE SA. > > Thoughts? > > Dan. > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > > > Dan McDonald wrote: > > > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > > > Can we drop the commit bit? > > > > > > Who uses it? > > > > I guess someone in past figured out that running IKE on > satellite lines > > is necessary, so they decided to optimize as much as > possible. The result > > was that both aggressive mode and quick mode both have > three messages. > > The problem with three messages is that the initiator will > often start sendin > >g > > actual traffic too soon, or quick mode packets, before the > responder is ready > >. Thus > > the need for packet buffers, commit bit, whatever. This > optimization causes d > >esign > > complications that I'd very much prefer to get rid of. > > From owner-ipsec@lists.tislabs.com Thu Aug 9 06:13:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DD2N15942; Thu, 9 Aug 2001 06:13:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23151 Thu, 9 Aug 2001 08:27:55 -0400 (EDT) Message-ID: <3B72846A.4010300@kolumbus.fi> Date: Thu, 09 Aug 2001 15:39:06 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber Cc: sankar ramamoorthi , Dan Harkins , Ari Huttunen , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > making a 2 message exchange. I favor an even number of messages. Whether > that's 2 or 4 I don't MUCH care (2 would be preferable if we can figure out > how). I'd just like to repeat my preference for the minimal number of messages even in this context. When these things are used over cellular links with relatively long delays, additional messages really affect the delays before you can start work. Jari From owner-ipsec@lists.tislabs.com Thu Aug 9 06:22:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DMVN16135; Thu, 9 Aug 2001 06:22:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23168 Thu, 9 Aug 2001 08:32:49 -0400 (EDT) Message-ID: <001f01c120d0$5fc05090$0101a8c0@mv.lucent.com> From: "David W. Faucher" To: "Jan Vilhuber" Cc: References: Subject: Re: Simplifying IKE Date: Thu, 9 Aug 2001 07:35:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe that using the Message ID field as a counter has already been suggested, and in this case should work to prevent replay attacks. ----- Original Message ----- From: "Jan Vilhuber" To: "Dan Harkins" Cc: "Brian Swander" ; "Ari Huttunen" ; Sent: Wednesday, August 08, 2001 9:17 PM Subject: Re: Simplifying IKE > P.S. I really would prefer a 2 message version, if some smart cookie out > there can figure out how to guard against replay attacks. That would be the > coolest... > > jan > > > > On Wed, 8 Aug 2001, Jan Vilhuber wrote: > > > On Wed, 8 Aug 2001, Dan Harkins wrote: > > > > > Why is one mandated processing of packets a solution and another a > > > "work around"? If the "work around" solves the problem in one less > > > message then why isn't that preferable? Wouldn't adding a timestamp to > > > the exchange be a "kludge"? Or a "work around"? > > > > > As you say, both work. One strikes me as more aesthetically pleasing, or > > cleaner, i.e. a 4th message is part of the protocol, and you don't need much > > verbiage to tell people how to handle the sync between IKE and ipsec in a 3 > > message scenario. It's therefore much cleaner and offers better chances of > > passing interop (the more verbiage to explain something, the more you give > > people to argue what was meant by the verbiage). > > > > > The only reason the Responder doesn't instantiate the SAs after sending > > > the 2nd message today is because of concerns about a resource consumption > > > attack. I feel those concerns are small due to the small time in which > > > the bogus SAs would be in the SADB, the inability of an attacker to use > > > them (due to the inability of a 3rd party to know SKEYID state), and the > > > small (and quantifiable) number of messages that can possibly be exchanged. > > > Instantiate them and delete them if the 3rd message is never received! > > > > > > > Or wait for a 4th message to confirm. I grant you they are almost the same. > > > > > So we have very few messages which can be replayed and a well-defined > > > method of dealing with the cases in which they are replayed. Why is that > > > not satisfactory? What is the problem with this that is solved by adding > > > a 4th message? > > > > > It's an explicit ACK, rather than relying on implicit behaviour of lacking > > the 3rd message. It just strikes me as cleaner. it's all software. We can > > implement almost anything in software. Question is how. And obviously > > different people have different ideas of 'cleanliness' and different > > definition of 'obvious' (as we can tell from dangling SA and continuous > > channel fiascos). > > > > Telling IPSec to instantiate a single SA, and then later possibly revoking > > it, just doesn't seem as clean to me. I'd rather only tell ipsec to go ahead > > and do its thing when IKE is completely 100% sure that we're done. > > > > I also realize that KINK does what you propose. I didn't much like it there, > > either. So be it. The very fact that it has to be explained, rather than > > having a protocol definition, makes me nervous. But if it can be explained > > very simply, and you are confident that people won't find things they claim > > were open to interpretation (what do you mean I shouldn't delete my IPSec > > Sa's when the IKE SA that created them dies?! Duh...), then I'm OK with it. > > > > To put it a different way: Define the protocol, and when the protocol has > > unambiguously finished, THEN (and only then) tell ipsec to proceed. This > > doesn't leave things open to interpretation of exactly when one SA should be > > instantiated and when the next should be instantiated, and so on. Maybe I'm > > just being pedantic. Being pedantic should be a good thing right now, so we > > don't repeat the past with son-of-IKE (did we decide it's 'doud', pronounced > > 'dude'?? ;) > > > > Different folks, different strokes... > > jan > > > > > > > > > > > > > Dan. > > > > > > On Wed, 08 Aug 2001 13:57:15 PDT you wrote > > > > I'd actually prefer to formalize the concept that the commit-bit is trying to > > > > address: > > > > > > > > 1) Either expand quick mode to 4 messages. That's unambiguous, and leads to > > > > better interop. A commit bit is really a kludge. > > > > > > > > 2) If you think about it, the 3rd message is only needed to prevent replay > > > > attacks of old messages. If we addressed this some other way (say a timestamp > > > > field, but that has obvious other problems), then we could drop the 3rd > > > > message, and have 2, which is again 'good (tm)'. > > > > > > > > Dan also outlined some other ways to address this problem, and while they > > > > work, I don't much care for them, since they're really work-arounds to the > > > > problem above. It would be preferable to address the replay attacks in some > > > > other way (if possible) and do away with the 3rd message, or bite the bullet > > > > and create a 4th message as an ACK to make the exchange as unambiguous as > > > > possible. > > > > > > > > I point out that KINK manages to use 2 messages, which are (used to be) > > > > essentially a quick mode exchange. It uses kerberos to handle the replay > > > > attacks, which involves timestamps. There are surely other ways of addressing > > > > the replay issue, like a counter or something else. If we could use two > > > > messages for quick mode, that would solve all this commit-bit versus 'when to > > > > install the resources' issues.... > > > > > > > > jan > > > > > > > > > > > > > > > > > I am not so concerned with the resources in an attack, but more worried > > > > > about an attacker potentially getting an SA into the system that could > > > > > be exploited. I don't see how this could be done today (all I can see > > > > > is the obvious replay attack Dan is talking about), but that doesn't > > > > > mean that such an exploit doesn't exist. So, I am much more comfortable > > > > > with the one extra packet and the assurance that everything is ok with > > > > > the negotiation before SAs are added. > > > > > > > > > > Of course, if someone has a proof that the security can't be violated by > > > > > adding the responder SAs early, then I'd agree to eliminating the commit > > > > > bit (except for backwards compatibility, when we'd still need to support > > > > > it). > > > > > > > > > > bs > > > > > > > > > > -----Original Message----- > > > > > From: Dan Harkins [mailto:dharkins@lounge.org] > > > > > Sent: Wednesday, August 08, 2001 10:49 AM > > > > > To: Ari Huttunen > > > > > Cc: ipsec@lists.tislabs.com > > > > > Subject: Re: Simplifying IKE > > > > > > > > > > My tentative text on the subject is to get rid of the commit bit and > > > > > have a 3 message exchange. The problem with the existing 3 message > > > > > exchanage (w/o the commit bit being used) is that the Responder will not > > > > > instantiate her SAs until receipt of the 3rd message from the Initiator > > > > > to avoid a resource consumption attack but the Initiator will > > > > > instantiate > > > > > his SAs upon receipt of the 2nd message from the Responder. This results > > > > > in a race between the first few IPsec-protected packets and the final > > > > > message. If the former win they get dropped. > > > > > > > > > > My proposal is that the Responder instantiate the SAs when she sends > > > > > the 2nd message back to the Initiator. She will be setting a timer to > > > > > deal with non-receipt of the 3rd message and if the timer fires > > > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to have failed > > > > > and she can delete these SAs from her SADB. > > > > > > > > > > In addition to this text there is new text instructing implementations > > > > > to deal with receipt of an offer to create an IPsec SA with a SPI that > > > > > is currently in use as an error, and new text instructing the Initiator > > > > > to hold on to the 3rd phase 2 message for some COMFORT_LEVEL_TIME in > > > > > case > > > > > it is dropped and he receives a retransmitted 2nd message from the > > > > > Responder. > > > > > > > > > > This is much simpler than what we have and solves the race problem. > > > > > What it does, though, is allow for some resources to be temporarily > > > > > consumed due to the replay of an old message. I don't view this as that > > > > > big of a problem though since it is temporary (RETRANSMIT_TIME * > > > > > RETRANSMIT_TIMER_LIMIT = total seconds these bogus SAs would stay in > > > > > the SADB) and the number of possible packets that can be replayed is > > > > > limited and bounded by the life of the IKE SA. > > > > > > > > > > Thoughts? > > > > > > > > > > Dan. > > > > > > > > > > On Wed, 08 Aug 2001 12:19:02 +0300 you wrote > > > > > > > > > > > > Dan McDonald wrote: > > > > > > > > > > > > > > > >From the Schneier and Ferguson analysis we get: > > > > > > > > > > > > > > > > Can we drop the commit bit? > > > > > > > > > > > > > > Who uses it? > > > > > > > > > > > > I guess someone in past figured out that running IKE on satellite > > > > > lines > > > > > > is necessary, so they decided to optimize as much as possible. The > > > > > result > > > > > > was that both aggressive mode and quick mode both have three messages. > > > > > > The problem with three messages is that the initiator will often start > > > > > sendin > > > > > >g > > > > > > actual traffic too soon, or quick mode packets, before the responder > > > > > is ready > > > > > >. Thus > > > > > > the need for packet buffers, commit bit, whatever. This optimization > > > > > causes d > > > > > >esign > > > > > > complications that I'd very much prefer to get rid of. > > > > > > > > > > > > > -- > > > > Jan Vilhuber vilhuber@cisco.com > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Thu Aug 9 06:41:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DfaN16520; Thu, 9 Aug 2001 06:41:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23260 Thu, 9 Aug 2001 08:56:04 -0400 (EDT) Message-ID: <00a401c120d4$1c09e290$4e8d21d9@sfanninglaptop> From: "Scott Fanning" To: "Jari Arkko" , "Jan Vilhuber" Cc: "sankar ramamoorthi" , "Dan Harkins" , "Ari Huttunen" , References: <3B72846A.4010300@kolumbus.fi> Subject: Re: Simplifying IKE Date: Thu, 9 Aug 2001 06:06:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This might go to Cheryl Madsons point that this protocol (SOI, IKEv2, whatever) may not be for everyone. KINK seems to have gone to great lengths to address the transmission issues. I would prefer a 2 or 4 number exchange. I would like the initiator to know when to send traffic that can be usefully used by both parties as opposed to being dropped. That may be worse that one extra message. That seemed to be the motivation of the dreaded COMMIT bit, but I would not recommend making it optional. >From Dan The only reason the Responder doesn't instantiate the SAs after sending the 2nd message today is because of concerns about a resource consumption attack. I feel those concerns are small due to the small time in which the bogus SAs would be in the SADB, the inability of an attacker to use them (due to the inability of a 3rd party to know SKEYID state), and the small (and quantifiable) number of messages that can possibly be exchanged. Instantiate them and delete them if the 3rd message is never received! To Dans point about 3 messages would only allow an SA to consume memory for a short period of time, I am more concerned with tunnels per second consuming memory. There may be cases where you could use too much memory as a result of that, then just establishing one SA at a time. In that case, especially in memory constrained devices, I would want to remove a much resources usage as possible. Scott ----- Original Message ----- From: "Jari Arkko" To: "Jan Vilhuber" Cc: "sankar ramamoorthi" ; "Dan Harkins" ; "Ari Huttunen" ; Sent: Thursday, August 09, 2001 5:39 AM Subject: Re: Simplifying IKE > > > Jan Vilhuber wrote: > > > > > making a 2 message exchange. I favor an even number of messages. Whether > > that's 2 or 4 I don't MUCH care (2 would be preferable if we can figure out > > how). > > I'd just like to repeat my preference for the minimal number of messages > even in this context. When these things are used over cellular links with > relatively long delays, additional messages really affect the delays before > you can start work. > > Jari > From owner-ipsec@lists.tislabs.com Thu Aug 9 06:48:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DmTN16680; Thu, 9 Aug 2001 06:48:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23306 Thu, 9 Aug 2001 09:05:16 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: DRAFT: ipsec charter update From: tytso@mit.edu Phone: (781) 391-3464 Message-Id: Date: Thu, 09 Aug 2001 09:10:59 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IPSEC wg chairs met with Marcus Leech today, and after discussions and consultation with him, we have developed the following draft update to the IPSEC working group charter. Contained in this proposed update is a timeline for the IKE V2 work which was discussed at the IPSEC meeting earlier week in London. We welcome comments and suggestions on improving the revised working group charter. We would like to submit this charter to the IESG for consideration by the end of August, so we would appreciate receiving comments within the next two weeks. Barbara Fraser Theodore Ts'o IPSEC wg chairs IP Security Protocol (ipsec) Last Modified: 09-Aug-01 Chair(s): Barbara Fraser Theodore Ts'o Security Area Director(s): Jeffrey Schiller Marcus Leech Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:ipsec@lists.tislabs.com to Subscribe: ipsec-request@lists.tislabs.com Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec Description of Working Group: ============================= Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The IPSEC working group will restrict itself to the following short-term work items to improve the existing key management protocol (IKE): 1) Changes to IKE to support NAT/Firewall traversal 2) Changes to IKE to support SCTP 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and a fast AES mode suitable for use in hardware encryptors 4) IKE MIB documents 5) Sequence number extensions to ESP to support an expanded sequence number space. 6) Clarification and standardization of rekeying procedures in IKE. The working group will also update IKE to reflect implementation experience, new requirements, and protocol analysis of the existing protocol. The requirements for IKE V2 will be revised and updated as the first step in this process. Goals and Milestones: ===================== Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and requirements for IPsec and IKE for use with SCTP, to working group last call. Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE MIBs, and SCTP support for considerations as Draft Standards. Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE re-keying completed. Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE re-keying to working group last call. Dec 01 Internet-Draft on IKE v2 Requirements to working group last call Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted to the working group. Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE rekeying for consideration as Draft Standards. Apr 02 Discuss and select the IKE v2 design from candidate approaches. Sep 02 IKE v2 Internet-Drafts to working group last call Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as Proposed Standards. From owner-ipsec@lists.tislabs.com Thu Aug 9 06:57:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DvfN16843; Thu, 9 Aug 2001 06:57:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23331 Thu, 9 Aug 2001 09:16:49 -0400 (EDT) Message-ID: <001201c1205b$3e86f7f0$50b12304@ffb5b> From: "jshukla" To: "Francis Dupont" , "Henry Spencer" Cc: References: <200108081624.f78GOhu73295@givry.rennes.enst-bretagne.fr> Subject: Re: Simplifying IKE Date: Wed, 8 Aug 2001 15:41:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Francis Dupont" To: "Henry Spencer" Cc: Sent: Wednesday, August 08, 2001 9:24 AM Subject: Re: Simplifying IKE > > In your previous mail you wrote: > > On Wed, 8 Aug 2001, Francis Dupont wrote: > > ...I believe the source route header is primarily used to see > > what paths are broken in a network - using the process of elimination. > > => you haven't quoted me but the message I answered to... > > Actually, the source route header is increasingly frequently ignored (or > considered grounds for dropping the packet) by implementations, because of > its utility for various forms of attack. > Doesn't MIPv6 use the source route header to solve the triangle routing problem? regards, Jayant From owner-ipsec@lists.tislabs.com Thu Aug 9 06:59:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79DxFN16890; Thu, 9 Aug 2001 06:59:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23325 Thu, 9 Aug 2001 09:15:48 -0400 (EDT) Date: Thu, 9 Aug 2001 09:22:10 -0400 (EDT) From: Henry Spencer To: "David W. Faucher" cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <001f01c120d0$5fc05090$0101a8c0@mv.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Aug 2001, David W. Faucher wrote: > I believe that using the Message ID field as a counter > has already been suggested, and in this case should work > to prevent replay attacks. Simply remembering message IDs also works; we've done this. (Indeed, the current RFCs can be read as requiring it, although the wording is obscure and that reading is disputed.) But the counter approach is definitely superior. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Aug 9 07:42:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79EgFN17854; Thu, 9 Aug 2001 07:42:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23643 Thu, 9 Aug 2001 09:59:05 -0400 (EDT) From: Steve.Robinson@psti.com Subject: RE: Simplifying IKE To: Cc: "'Dan McDonald'" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, "'Sandy Harris'" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 9 Aug 2001 10:10:14 -0400 X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at 08/09/2001 03:10:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, While I certainly agree that the attack described in the Ferguson/Schneier paper on ESP was esoteric, I disagree on your conclusion that no damage will be done. Let's assume that no attack is occurring. What if the system administrator enters the section of the key used for decryption incorrectly? Authentication will work correctly, but right now, there is no verification mechanism in place to assure that the plaintext is not garbage, and once you pass garbage up to the upper layers, the behaviour is system specific and unknown -- it could range from catastrophic to no damage at all. Authenticating the text after decryption assures that the correct plaintext is passed to the upper layers. If the current order is only maintained to ward off DoS, then I'd suggest that the argument is weak, since DoS can only be minimized, not eliminated. Steve "Andrew Krywaniuk" , "'Sandy Harris'" catel.com> Sent by: cc: owner-ipsec@lists.ti Subject: RE: Simplifying IKE slabs.com 08/09/01 07:45 AM Please respond to andrew.krywaniuk > > > 4. modify ESP to ensure it authenticates all data used in > the deciphering > > of the payload > > > > This is the only recommendation in this paper based on a > direct security > > flaw, with a proposed attack to demonstrate it. There are > others in the > > Simpson paper. > > And if you use Choice 3a above, you get this for free - AH > covers the whole > ESP datagram, SPI/IV/etc. If my memory serves me correctly, Ferguson/Schneier were actually suggesting that 1. encryption be applied AFTER authentication or, failing that, that 2. the encryption/decryption key be included in the data which is hashed This is to prevent an esoteric attack they describe which is infeasible and wouldn't cause any damage anyway. That is not a compelling reason to redesign ESP. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Thu Aug 9 08:28:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79FS6N21163; Thu, 9 Aug 2001 08:28:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23766 Thu, 9 Aug 2001 10:34:28 -0400 (EDT) From: "Geoffrey Huang" To: , Subject: RE: DRAFT: ipsec charter update Date: Thu, 9 Aug 2001 07:44:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The IPSEC wg chairs met with Marcus Leech today, and after discussions > and consultation with him, we have developed the following draft update > to the IPSEC working group charter. > > Contained in this proposed update is a timeline for the IKE V2 work > which was discussed at the IPSEC meeting earlier week in London. We > welcome comments and suggestions on improving the revised working group > charter. We would like to submit this charter to the IESG for > consideration by the end of August, so we would appreciate receiving > comments within the next two weeks. > > Barbara Fraser > Theodore Ts'o > IPSEC wg chairs > > > IP Security Protocol (ipsec) > > Last Modified: 09-Aug-01 > > Chair(s): > Barbara Fraser > Theodore Ts'o > > Security Area Director(s): > Jeffrey Schiller > Marcus Leech > > Security Area Advisor: > Jeffrey Schiller > > Mailing Lists: > General Discussion:ipsec@lists.tislabs.com > to Subscribe: ipsec-request@lists.tislabs.com > Archive: ftp://ftp.tis.com/pub/lists/ipsec OR > ftp.ans.net/pub/archive/ipsec > > Description of Working Group: > ============================= > > Rapid advances in communication technology have accentuated the need for > security in the Internet. The IP Security Protocol Working Group > (IPSEC) will develop mechanisms to protect client protocols of IP. A > security protocol in the network layer will be developed to provide > cryptographic security services that will flexibly support combinations > of authentication, integrity, access control, and confidentiality. > > The IPSEC working group will restrict itself to the following short-term > work items to improve the existing key management protocol (IKE): > > 1) Changes to IKE to support NAT/Firewall traversal > > 2) Changes to IKE to support SCTP > > 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and > a fast AES mode suitable for use in hardware encryptors > > 4) IKE MIB documents > > 5) Sequence number extensions to ESP to support an expanded sequence > number space. > > 6) Clarification and standardization of rekeying procedures in IKE. I think there's more at issue than just rekeying. There are other ambiguities that also need addressing: when to send a cert_req payload, unacknowledged notifications, phase 1 lifetime etc. (I sent a mail on this previously, and Andrew K. mentioned it in his presentation). -g > The working group will also update IKE to reflect implementation > experience, new requirements, and protocol analysis of the existing > protocol. The requirements for IKE V2 will be revised and updated as > the first step in this process. > > Goals and Milestones: > ===================== > > Aug 01 Internet Drafts on NAT and Firewall traversal, IKE > MIBs, and > requirements for IPsec and IKE for use with SCTP, to working > group last call. > > Sep 01 Submit revised Internet-Drafts of NAT and Firewall > traversal, IKE > MIBs, and SCTP support for considerations as Draft Standards. > > Oct 01 Internet-Drafts on sequence number expansion in > IKE, and IKE > re-keying completed. > > Dec 01 Internet-Drafts on AES/SHA-2, sequence number > expansion, and IKE > re-keying to working group last call. > > Dec 01 Internet-Draft on IKE v2 Requirements to working > group last call > > Dec 01 Internet-Drafts describing candidate IKE v2 > approaches submitted > to the working group. > > Feb 01 Submit revised Internet-Drafts on AES/SHA-2, > sequence number > expansion, and IKE rekeying for consideration as Draft Standards. > > Apr 02 Discuss and select the IKE v2 design from candidate > approaches. > > Sep 02 IKE v2 Internet-Drafts to working group last call > > Dec 02 Submit IKE v2 Internet-Drafts to the IESG for > consideration as > Proposed Standards. > > > > > From owner-ipsec@lists.tislabs.com Thu Aug 9 08:42:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79FgZN23274; Thu, 9 Aug 2001 08:42:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23893 Thu, 9 Aug 2001 10:56:29 -0400 (EDT) Message-Id: <200108091502.f79F2ou77622@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Lars Eggert" cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of Thu, 09 Aug 2001 12:34:07 -0000. Date: Thu, 09 Aug 2001 17:02:49 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > => this "authentication" by side effect is mandatory according to RFC > 2401 5.2.1 step 2 but: > - it doesn't work with tunnel mode I'm probably missing something obvious, but why doesn't comparing the SA against the (two) IP headers work for tunnel mode? => RFC 2401 specifies that only the inner addresses must be checked in tunnel mode (inbound processing rules, 5.2.1). The outer destination is used for SA lookup so must be right, the outer source should not be checked (5.1.2.1 footnote 3 note). Many implementations incorrectly implement an outer source address check in tunnel mode and this does not work well with mobility/multihoming/NAT/... Regards Francis.Dupont@enst-bretagne.fr PS: the outer/inner header stuff for SADB and SPD is the only difference from the security point of view between tunnel mode and transport + IPinIP for ESP (AH tunnel mode is different but not used). From owner-ipsec@lists.tislabs.com Thu Aug 9 08:57:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79FvfN25538; Thu, 9 Aug 2001 08:57:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23965 Thu, 9 Aug 2001 11:05:20 -0400 (EDT) From: "sankar ramamoorthi" To: "Dan Harkins" Cc: Subject: RE: Simplifying IKE Date: Thu, 9 Aug 2001 08:11:57 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200108090800.f7980D700535@dharkins@lounge.orgatty.lounge.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Thursday, August 09, 2001 1:00 AM > To: sankar ramamoorthi > Cc: ipsec@lists.tislabs.com > Subject: Re: Simplifying IKE > > > I'm obviously explaining myself poorly and that's not a good way > to start of this discussion.... > > On Wed, 08 Aug 2001 19:04:25 PDT you wrote > > > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@lounge.org] > > > Sent: Wednesday, August 08, 2001 6:32 PM > > > To: sankar ramamoorthi > > > Cc: Ari Huttunen; ipsec@lists.tislabs.com > > > Subject: Re: Simplifying IKE > > > > > > > > > On Wed, 08 Aug 2001 13:31:43 PDT you wrote > > > > > -----Original Message----- > > > > > From: owner-ipsec@lists.tislabs.com > > > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > > > > > Sent: Wednesday, August 08, 2001 10:49 AM > > > > > To: Ari Huttunen > > > > > Cc: ipsec@lists.tislabs.com > > > > > Subject: Re: Simplifying IKE > > > > > > > > > > > > > > > My tentative text on the subject is to get rid of the > commit bit and > > > > > have a 3 message exchange. The problem with the existing 3 message > > > > > exchanage (w/o the commit bit being used) is that the > > > Responder will not > > > > > instantiate her SAs until receipt of the 3rd message from the > > > Initiator > > > > > to avoid a resource consumption attack but the Initiator will > > > instantiate > > > > > his SAs upon receipt of the 2nd message from the Responder. > > > This results > > > > > in a race between the first few IPsec-protected packets > and the final > > > > > message. If the former win they get dropped. > > > > > > > > > > My proposal is that the Responder instantiate the SAs > when she sends > > > > > the 2nd message back to the Initiator. She will be > setting a timer to > > > > > deal with non-receipt of the 3rd message and if the timer fires > > > > > RETRANSMIT_TIMER_LIMIT times the exchange is declared to > have failed > > > > > and she can delete these SAs from her SADB. > > > > > > > > What happens if the initiator starts sending data before > the responder > > > > receives the third message? > > > > > > Nothing. That's the whole idea. > > > > which means in the worst case packets from the sender will be > dropped for > > the duration (RETRANSMIT_TIMER_LIMIT * round-trip-time). > > No, they are not dropped in any case. They are properly received because > the Responder has instantiated the SAs before she sends the 2nd message. > Got it. I misunderstood this part. Does it mean the bogus SAs even though they are short-lived can receive packets? This is the part that bothers me. If packets can be received on the bogus SA, what prevents some one to replay data packets through the bogus SA (If QM message 1 can be replayed then it is possible for ipsec packets from a previous session to be replayed as well). Such packets will then be accepted as valid packets. Does it not open up a security hole? What am I missing? > > This leads to an ambiguous state where the packets may or not be dropped > > by the responder. It is also possible that if initiator is sending data > > at a high rate, it could affect the responder from > retransmitting message2 > > and getting message3. > > No it doesn't matter how fast the Initiator sends packets (assuming you > mean IPsec-protected packets) because the Responder will have properly > instantiated SAs _before_ the Initiator has. By the time the Initiator > has all the information to instantiate his own SAs the Responder will > already have instantiated hers. No packet loss. So for this short duration all SA(including bogus SAs) are treated equal ie: the responder assumes the SAs are properly instantiated even though the third message is not received yet. > > > With a 4 packet exhange scheme, each party knows for sure the other side > > has the SA established before sending data. The state transitions seem > > to be much cleaner here. > > I think you're misunderstanding what I'm proposing. If the Responder > instantiates her SAs when she sends the 2nd message then what's the > problem? How does this not work? The Responder has SAs ready before > the Initiator does so there is no packet loss. > > > > > Will the ipsec packet from initiator be processed since > responder has > > > > established the SA on receipt of the second message? If so, can the > > > > responder treat succesful processing of the data packet as succesful > > > > authentication of the initiator and mark the SA as valid(basically > > > > treat the condition same as processing a successful third message). > > > > > > I prefer not to make such a linkage (between the IPsec > processing engine > > > and the key management system) since there is still a message > > > that IKE must > > > process and receipt of that message will dictate whether the SAs stay > > > or go. > > > > > > > I agree - this was just an idea that I threw around to see if > > it is possible to come up with a 2 message solution. > > If you can come up with a 2 message solution I think we will all be > happy. Please do so; I cannot come up with one that is simpler than the > 3 message one I'm proposing. > > > > > Personally I prefer a 4 packet exchange model for QM. > > > > > > What shortcoming in the scheme I described is solved with a 4 packet > > > exchange? > > > > > > > see above. > > I don't see a shortcoming above. Can you describe to me a situation that > will not work with what I propose but will work with a 4 message exchange? > > Dan. > From owner-ipsec@lists.tislabs.com Thu Aug 9 14:30:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79LUmN03328; Thu, 9 Aug 2001 14:30:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24059 Thu, 9 Aug 2001 11:25:20 -0400 (EDT) Message-Id: <200108091531.f79FVku77722@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "jshukla" cc: "Henry Spencer" , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of Wed, 08 Aug 2001 15:41:19 PDT. <001201c1205b$3e86f7f0$50b12304@ffb5b> Date: Thu, 09 Aug 2001 17:31:46 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Doesn't MIPv6 use the source route header to solve the triangle routing problem? => yes but the discussion was about the IPv4 source routing which is beyond repair. Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Aug 9 14:52:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79Lq5N03722; Thu, 9 Aug 2001 14:52:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24121 Thu, 9 Aug 2001 11:43:18 -0400 (EDT) Message-Id: <200108091549.f79Fnfu77810@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve.Robinson@psti.com cc: andrew.krywaniuk@alcatel.com, "'Dan McDonald'" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, "'Sandy Harris'" Subject: Re: Simplifying IKE In-reply-to: Your message of Thu, 09 Aug 2001 10:10:14 EDT. Date: Thu, 09 Aug 2001 17:49:41 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: While I certainly agree that the attack described in the Ferguson/Schneier paper on ESP was esoteric, I disagree on your conclusion that no damage will be done. Let's assume that no attack is occurring. What if the system administrator enters the section of the key used for decryption incorrectly? Authentication will work correctly, but right now, there is no verification mechanism in place to assure that the plaintext is not garbage, and once you pass garbage up to the upper layers, the behaviour is system specific and unknown -- it could range from catastrophic to no damage at all. => I don't buy this argument: upper layers are reading to eat garbage because garbage can occur on lower layer transmisson errors. They usually use a checksum for that. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Aug 9 14:52:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79Lq8N03734; Thu, 9 Aug 2001 14:52:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24130 Thu, 9 Aug 2001 11:46:02 -0400 (EDT) Date: Thu, 9 Aug 2001 09:52:33 -0600 From: Shane Amante To: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE Message-ID: <20010809095233.A2618@ns1.amante.org> Mail-Followup-To: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Another advantage for adopting a 2-message exchange is large-delay satellite links. In particular, consumer satellite broadband companies, such as Starband and other companies on the horizon, are using GEO satellites which have a substantial delay of > ~500ms RTT, just to get across the satellite link. Note, thatdoesn't necessarily include RTT time from the ground-station through the terrestrial Internet to the ultimate destination. Also, Dan, have you defined and/or suggested a value of the RETRANSMIT_TIMER_LIMIT? I would suggest that it has to either: a) be hard-coded relatively high to accomodate large-delay satellite/cellular links; or, b) be set at some reasonable default, but optionally configurable by the end-user so they may set it higher or lower depending on their particular application. Does this sound reasonable? -shane Jan Vilhuber wrote: > > making a 2 message exchange. I favor an even number of messages. Whether > > that's 2 or 4 I don't MUCH care (2 would be preferable if we can figure out > > how). > > I'd just like to repeat my preference for the minimal number of messages > even in this context. When these things are used over cellular links with > relatively long delays, additional messages really affect the delays before > you can start work. > > Jari From owner-ipsec@lists.tislabs.com Thu Aug 9 15:13:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79MDiN04050; Thu, 9 Aug 2001 15:13:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24361 Thu, 9 Aug 2001 17:35:29 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15218.49481.508600.823194@thomasm-u1.cisco.com> Date: Thu, 9 Aug 2001 09:58:49 -0700 (PDT) To: daw@mozart.cs.berkeley.edu (David Wagner) Cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE Newsgroups: isaac.lists.ipsec In-Reply-To: <9kqp45$pqf$1@abraham.cs.berkeley.edu> References: <3B709706.4D051BE5@storm.ca> <9kqp45$pqf$1@abraham.cs.berkeley.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk They aren't directly related, but their existence definitely increase complexity of IKE. Unless we completely change code bases, that may well be water under the bridge for IKE though. MIke David Wagner writes: > Sandy Harris wrote: > >The Leech, Schiller and Bellovin (LSB?) document mentions: > >> the goal: to produce a more secure, simpler, and more robust version of IKE. > > > >From the Schneier and Ferguson analysis we get: > >> 1: eliminate transport mode > >> 2. eliminate the AH protocol > >> 3. modify ESP to always authenticate [...] > >> 4. modify ESP to ensure it authenticates all data [...] > > What do any of those have to do with IKE? Those are all about > the packet-level format, which has very little to do with IKE, as > far as I can see. From owner-ipsec@lists.tislabs.com Thu Aug 9 15:18:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79MIlN04170; Thu, 9 Aug 2001 15:18:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24324 Thu, 9 Aug 2001 17:20:28 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15218.49850.736269.868270@thomasm-u1.cisco.com> Date: Thu, 9 Aug 2001 10:04:58 -0700 (PDT) To: Ari Huttunen Cc: Dan McDonald , Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <3B710406.1175A60@F-Secure.com> References: <200108080219.f782JIp00242@kebe.east.sun.com> <3B710406.1175A60@F-Secure.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen writes: > Thus my preference would be to have a four packet phase 1 (base mode) and > a four packet quick mode. Gad. Doesn't anybody care about link up times??? There a lots of things which are quite sensitive (user experiencewise) to startup delay. Just this amount of signaling would be enough to dissuade anybody from casually using IKE for, oh say, transport mode, and would be pretty sucky for everything else too. As Jari points out, there are plenty of link layers that punish you for these kinds of excesses. Also: it needs to be said that the when security flies in the face usability, it is well documented which one is jettisoned... Mike From owner-ipsec@lists.tislabs.com Thu Aug 9 17:26:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A0QjN06193; Thu, 9 Aug 2001 17:26:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24678 Thu, 9 Aug 2001 19:46:06 -0400 (EDT) Message-Id: <200108092352.f79NqSJ20568@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: Ari Huttunen , Dan McDonald , Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of "Thu, 09 Aug 2001 10:04:58 PDT." <15218.49850.736269.868270@thomasm-u1.cisco.com> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 09 Aug 2001 19:52:28 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Ari Huttunen writes: > > Thus my preference would be to have a four packet phase 1 (base mode) and > > a four packet quick mode. > > Gad. Doesn't anybody care about link up times??? Smooshing phase 1 and phase 2 together begins to look very attractive when quick mode isn't very (quick). - Bill From owner-ipsec@lists.tislabs.com Thu Aug 9 18:34:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A1YEN07196; Thu, 9 Aug 2001 18:34:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24884 Thu, 9 Aug 2001 20:54:23 -0400 (EDT) Date: Thu, 9 Aug 2001 18:00:53 -0700 (PDT) From: Jan Vilhuber To: Bill Sommerfeld cc: Michael Thomas , Ari Huttunen , Dan McDonald , Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <200108092352.f79NqSJ20568@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Aug 2001, Bill Sommerfeld wrote: > > Ari Huttunen writes: > > > Thus my preference would be to have a four packet phase 1 (base mode) and > > > a four packet quick mode. > > > > Gad. Doesn't anybody care about link up times??? > > Smooshing phase 1 and phase 2 together begins to look very attractive > when quick mode isn't very (quick). > In the above example it's still half of a full exchange. I find that acceptable for some applications (by no means all). If you want faster setup times, we'll need another protocol (or use KINK and install kerberos; depends on your customers' needs). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Aug 9 18:37:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A1bgN07231; Thu, 9 Aug 2001 18:37:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24870 Thu, 9 Aug 2001 20:52:52 -0400 (EDT) Date: Thu, 9 Aug 2001 17:59:22 -0700 (PDT) From: Jan Vilhuber To: Michael Thomas cc: Ari Huttunen , Dan McDonald , Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <15218.49850.736269.868270@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Aug 2001, Michael Thomas wrote: > Ari Huttunen writes: > > Thus my preference would be to have a four packet phase 1 (base mode) and > > a four packet quick mode. > > Gad. Doesn't anybody care about link up times??? There > a lots of things which are quite sensitive > (user experiencewise) to startup delay. One should point out that main-mode and quick-mode together comprise 6+3 messages (== 9. Make that 10, if you use the commit-bit). You'd actually save a message (two actually, if you compare apples to apples) by doing base-mode (4) and a 4 message quick mode. You'd also gain (arguably) some stability in the protocol. Of course a 2 message exchange would be even better. No arguments there. Am I correct in assuming that people agree there's a 2 message exchange by using some counter mechanism (proposed by Andrew K, I believe), but only if there's no PFS (and why is that? Can someone explain? All relevant payloads seem to be in QM1 and QM2 even with PFS)? Also, we should start to realize that trying to create a single keying protocol that solves ALL problems is not worthwhile (we've done this in IKE and it's caused major confusion). If you want shorter setup times, there should be a different keying protocol for that (say KINK, or something else we would have to design, if people don't want to use kerberos). It's either a single protocol with lots of options and knobs to tune behaviour, or multiple fairly fixed and well-defined protocols that are suited for different tasks... There's no 'one-size fits all' keying protocol. Or rather, there is: it's called IKE. jan P.S. I can live with Dan's 3 message exchange IFF it's so well defined that there's nothing left to the imagination of coders (nothing optional, all assumptions spelled out including pseudo-code that says in which order to do things; yes, one could assume we're all adults and don't need such excessive hand-holding, but the past has shown that's not true at all; the pseudo code approach is used in the kerberos rfc's, and no one seems to mind overly)... > Just > this amount of signaling would be enough to > dissuade anybody from casually using IKE for, > oh say, transport mode, and would be pretty > sucky for everything else too. As Jari points > out, there are plenty of link layers that > punish you for these kinds of excesses. > > Also: it needs to be said that the when > security flies in the face usability, it is > well documented which one is jettisoned... > > Mike > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Aug 9 19:09:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A29YN07810; Thu, 9 Aug 2001 19:09:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24947 Thu, 9 Aug 2001 21:32:59 -0400 (EDT) Date: Thu, 9 Aug 2001 21:39:18 -0400 (EDT) From: Henry Spencer To: Jan Vilhuber cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Aug 2001, Jan Vilhuber wrote: > It's either a single protocol with lots of options and knobs to tune > behaviour, or multiple fairly fixed and well-defined protocols that are > suited for different tasks... There's no 'one-size fits all' keying protocol. That may be true, but it is not a self-evident fact. And often it suffices for a protocol to be "one size fits almost all". Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Aug 9 19:28:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A2S7N08074; Thu, 9 Aug 2001 19:28:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25001 Thu, 9 Aug 2001 21:47:22 -0400 (EDT) Date: Thu, 9 Aug 2001 18:53:26 -0700 (PDT) From: Jan Vilhuber To: Henry Spencer cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Aug 2001, Henry Spencer wrote: > On Thu, 9 Aug 2001, Jan Vilhuber wrote: > > It's either a single protocol with lots of options and knobs to tune > > behaviour, or multiple fairly fixed and well-defined protocols that are > > suited for different tasks... There's no 'one-size fits all' keying protocol. > > That may be true, but it is not a self-evident fact. Hm.. I think it is. The fact that both main mode and aggressive mode exist, is proof that there's (at least) two camps that needed to be satisfied in IKE. One camp wants more security and versatility (negotiation, if you can call it that), and another camp wants more speed and is willing to sacrifice identity protection and negotiation. The existence of KINK is another proof. There's obviously people that need extremely fast and light-weight keying, which KINK (again arguably) provides (for certain scenarios). Personally, I consider that incontrovertible evidence, if not proof. > And often it > suffices for a protocol to be "one size fits almost all". > That doesn't really contradict what I said, of course. If you can get a good fit for 90%, then you still need a separate protocol for the other 10% (if they have a strong enough case, which I would argue they have and point at the KINK WG again). I believe (and again KINK is evidence) that there ISN'T a fit for 90%. More like 60/40. All this back and forth in this WG is yet another piece of evidence that there's no one-size-fits all (or even almost all). Some want AH, others want to get rid of it. Some want main mode, other want aggressive mode. Ad nauseum... I'm not advocating we do them in parallel. Let's define some requirements that simplifies as much as possible, agree on what can be left out to acheive that, and send people that don't agree off to write their own requirements (can't the WG chairs appoint sub-committee's to explore and recommend? Maybe we should do that). I think it's actually crucial we spell out what the camps are and what they need. We currently (I claim) have NO good requirements to go off and revise IKE, since we don't really know what we're optimizing it for. Do we want maximum security? Or fast setup? Unless someone shows me an exchange that combines both, I'm going to continue to claim that those two are mutually exclusive (I'd be happy to be proven wrong). As long as that dichotomy exists (amongst others), we'll need two protocols (or one that can do both... whoops... we already did that once). Or maybe we just point over to KINK and say "there's your fast setup" and deal only with the one that does maximum security? Fine by me. But we need to spell it out, so we can all start working in the same direction... jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Aug 9 19:40:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A2eTN08232; Thu, 9 Aug 2001 19:40:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25031 Thu, 9 Aug 2001 22:01:10 -0400 (EDT) Date: Thu, 9 Aug 2001 22:07:29 -0400 (EDT) From: Henry Spencer To: Jan Vilhuber cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Aug 2001, Jan Vilhuber wrote: > > > ...There's no 'one-size fits all' keying protocol. > > That may be true, but it is not a self-evident fact. > > Hm.. I think it is. The fact that both main mode and aggressive mode exist, > is proof that there's (at least) two camps that needed to be satisfied in > IKE. One camp wants more security and versatility (negotiation, if you can > call it that), and another camp wants more speed and is willing to sacrifice > identity protection and negotiation. Not quite. What you have established is that some people *think* there is a need for two approaches. That doesn't make it true! Especially since that design work was, to a large extent, done in advance of real live implementation experience. > The existence of KINK is another proof. There's obviously people that need > extremely fast and light-weight keying, which KINK (again arguably) provides > (for certain scenarios). Again, there are people who *think* they need better keying performance, but that doesn't make it true. (There were a lot of people who thought they needed better data-transfer protocol performance than TCP/IP could deliver. They put a lot of work into "lightweight" alternatives, most of which are dead and forgotten, superseded by TCP/IP.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Aug 9 19:46:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A2jxN08327; Thu, 9 Aug 2001 19:45:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25048 Thu, 9 Aug 2001 22:12:07 -0400 (EDT) Date: Thu, 9 Aug 2001 19:18:10 -0700 (PDT) From: Jan Vilhuber To: Henry Spencer cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hm.. Not sure where to go with this discussion. What's the difference between people (and not just one or two) *thinking* they need something, and it being true that they need it? If there's enough of them, then it becomes true. We don't really NEED this internet thing at all, really. I'd be just as happy sitting in a cave and grooving with a pict... If you want to go convince the aggressive mode (or whatever you want to call it... low number of messages/low setup-time/whatever) camp that they don't REALLY need it, be my guest. I could argue in reverse saying that just because you don't think they need it doesn't make it true that they don't need it. It's a rather pointless argument. Fact is that there's a camp that (thinks they) needs fewer messages at the expense of some features (and some security). Let's hold a straw-poll to count the percentages... Who calls for such a thing? The chairs? Let's count. I'm trying to figure out what people want, afterall. If no one cares about speedy setup times, then let's axe aggressive mode and be done with it. I'm actually OK with that. I suspect plenty of people won't. They think they need it, you think they don't. Fine. They still exist, and there's enough of them to not just be blown off because you don't think they're right... jan On Thu, 9 Aug 2001, Henry Spencer wrote: > On Thu, 9 Aug 2001, Jan Vilhuber wrote: > > > > ...There's no 'one-size fits all' keying protocol. > > > That may be true, but it is not a self-evident fact. > > > > Hm.. I think it is. The fact that both main mode and aggressive mode exist, > > is proof that there's (at least) two camps that needed to be satisfied in > > IKE. One camp wants more security and versatility (negotiation, if you can > > call it that), and another camp wants more speed and is willing to sacrifice > > identity protection and negotiation. > > Not quite. What you have established is that some people *think* there is > a need for two approaches. That doesn't make it true! Especially since > that design work was, to a large extent, done in advance of real live > implementation experience. > > > The existence of KINK is another proof. There's obviously people that need > > extremely fast and light-weight keying, which KINK (again arguably) provides > > (for certain scenarios). > > Again, there are people who *think* they need better keying performance, > but that doesn't make it true. (There were a lot of people who thought > they needed better data-transfer protocol performance than TCP/IP could > deliver. They put a lot of work into "lightweight" alternatives, most of > which are dead and forgotten, superseded by TCP/IP.) > > Henry Spencer > henry@spsystems.net > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Aug 9 19:56:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A2uDN08447; Thu, 9 Aug 2001 19:56:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25091 Thu, 9 Aug 2001 22:22:34 -0400 (EDT) Date: Thu, 9 Aug 2001 22:28:52 -0400 (EDT) From: Henry Spencer To: Jan Vilhuber cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Aug 2001, Jan Vilhuber wrote: > Hm.. Not sure where to go with this discussion. What's the difference between > people (and not just one or two) *thinking* they need something, and it being > true that they need it? If there's enough of them, then it becomes true. No; belief and reality *are* different. The way you tell the difference is to design and build a decent-but-not-all-things-to-all-people solution, and listen to see if the outraged screams and angry grumbling slowly die away. You can't settle this on mailing lists or in front of blackboards. As long as your design is just paper, people will find a thousand reasons why it's not good enough or why it needs 57 more options. Actual code and operational experience is needed to show them wrong. That's the way the IETF is supposed to do things, remember! We should be aiming for a simple, clean, middle-of-the-road solution with few options. After that's *in service* for a while, then is the time to take a hard look at whether anything else is needed. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Aug 9 20:01:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A311N08516; Thu, 9 Aug 2001 20:01:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25108 Thu, 9 Aug 2001 22:27:00 -0400 (EDT) Date: Thu, 9 Aug 2001 19:33:03 -0700 (PDT) From: Jan Vilhuber To: Henry Spencer cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Aug 2001, Henry Spencer wrote: > On Thu, 9 Aug 2001, Jan Vilhuber wrote: > > Hm.. Not sure where to go with this discussion. What's the difference between > > people (and not just one or two) *thinking* they need something, and it being > > true that they need it? If there's enough of them, then it becomes true. > > No; belief and reality *are* different. Fine. That's absolutely true. But you're arguing YOUR belief against someone else's. Let's hold a strawpoll and see if there's two (or more) camps or not. If there's sufficient people in whatever camps we identity, we send them off into sub-committees to hammer out their requirements. I don't much like making a middle-of-the-road protocols. We just had one. It's what we're arguing about. I don't think (belief again) that you'll ever satisfy the two camps (I suspect, believe, pray, that there's only two). Let's bite the bullet, realize thee ARE more than one camp, and that a middle-of-the-road approach won't solve this problem. Stand up and be counted. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Aug 9 20:01:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A31AN08530; Thu, 9 Aug 2001 20:01:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25121 Thu, 9 Aug 2001 22:28:39 -0400 (EDT) Date: Thu, 9 Aug 2001 22:34:57 -0400 (EDT) From: Henry Spencer To: Jan Vilhuber cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Aug 2001, Jan Vilhuber wrote: > I don't much like making a middle-of-the-road protocols. We just had one. No, we had a cover-the-whole-road-with-a-thousand-vague-options protocol. It's not the same thing. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Aug 9 20:07:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A37GN08593; Thu, 9 Aug 2001 20:07:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25145 Thu, 9 Aug 2001 22:35:23 -0400 (EDT) Date: Thu, 9 Aug 2001 19:41:55 -0700 (PDT) From: Jan Vilhuber To: Henry Spencer cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 9 Aug 2001, Henry Spencer wrote: > On Thu, 9 Aug 2001, Jan Vilhuber wrote: > > I don't much like making a middle-of-the-road protocols. We just had one. > > No, we had a cover-the-whole-road-with-a-thousand-vague-options protocol. > It's not the same thing. > Sigh.. I believe we're actually arguing more or less the same thing, but with differing degrees. You're saying satisfy 90%. Personally, I wonder if there IS a 90% in the ipsec WG. I've yet to see more than, say (making this up now for dramatic effect) 20% of the people agree on any particular thing. I say let's figure out the camps, and write a protocol that satisfies ONE of the camps (and later we'll write another that satisfies the other, if they decide there's still a need to do so). A straw-poll should quickly show if there's a 90% that agree on something in this group. If, so, we'll obviously do what you propose. If not, we'll wind up doing what I propose (in some way). As for middle-of-the-road, I fear that it'll be so-so at everything, and not very good at anything at all (design by committee. It's one of the few things I DID agree with in the Schneier paper). That'll just prompt people to ignore it altogether and write their own. I much prefer to write out the requirements fairly (but not too, and there's the rub) narrow, and write the darn protocol. People will then know what it's good for and what it's NOT good for, and hopefully not come whining about 'oh no.. not IKE' again (you can't imagine how many meetings and discussions I've heard that). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Aug 9 23:28:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7A6S9N18318; Thu, 9 Aug 2001 23:28:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA25466 Fri, 10 Aug 2001 01:34:11 -0400 (EDT) Message-Id: <3.0.3.32.20010809223922.00dbaea0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 09 Aug 2001 22:39:22 -0700 To: tytso@mit.edu, ipsec@lists.tislabs.com From: Alex Alten Subject: Re: DRAFT: ipsec charter update In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Barbara & Theodore, Is there a requirements doc for IKE V2? What are the acceptance criteria? Will there be a security analysis before Last Call by a reputable group of cryptographers, etc? - Alex At 09:10 AM 8/9/2001 -0400, tytso@mit.edu wrote: > >The IPSEC wg chairs met with Marcus Leech today, and after discussions >and consultation with him, we have developed the following draft update >to the IPSEC working group charter. > >Contained in this proposed update is a timeline for the IKE V2 work >which was discussed at the IPSEC meeting earlier week in London. We >welcome comments and suggestions on improving the revised working group >charter. We would like to submit this charter to the IESG for >consideration by the end of August, so we would appreciate receiving >comments within the next two weeks. > > Barbara Fraser > Theodore Ts'o > IPSEC wg chairs > > >IP Security Protocol (ipsec) > >Last Modified: 09-Aug-01 > >Chair(s): > Barbara Fraser > Theodore Ts'o > >Security Area Director(s): > Jeffrey Schiller > Marcus Leech > >Security Area Advisor: > Jeffrey Schiller > >Mailing Lists: > General Discussion:ipsec@lists.tislabs.com > to Subscribe: ipsec-request@lists.tislabs.com > Archive: ftp://ftp.tis.com/pub/lists/ipsec OR > ftp.ans.net/pub/archive/ipsec > >Description of Working Group: >============================= > >Rapid advances in communication technology have accentuated the need for >security in the Internet. The IP Security Protocol Working Group >(IPSEC) will develop mechanisms to protect client protocols of IP. A >security protocol in the network layer will be developed to provide >cryptographic security services that will flexibly support combinations >of authentication, integrity, access control, and confidentiality. > >The IPSEC working group will restrict itself to the following short-term >work items to improve the existing key management protocol (IKE): > >1) Changes to IKE to support NAT/Firewall traversal > >2) Changes to IKE to support SCTP > >3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and > a fast AES mode suitable for use in hardware encryptors > >4) IKE MIB documents > >5) Sequence number extensions to ESP to support an expanded sequence > number space. > >6) Clarification and standardization of rekeying procedures in IKE. > >The working group will also update IKE to reflect implementation >experience, new requirements, and protocol analysis of the existing >protocol. The requirements for IKE V2 will be revised and updated as >the first step in this process. > >Goals and Milestones: >===================== > >Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and > requirements for IPsec and IKE for use with SCTP, to working > group last call. > >Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE > MIBs, and SCTP support for considerations as Draft Standards. > >Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE > re-keying completed. > >Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE > re-keying to working group last call. > >Dec 01 Internet-Draft on IKE v2 Requirements to working group last call > >Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted > to the working group. > >Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number > expansion, and IKE rekeying for consideration as Draft Standards. > >Apr 02 Discuss and select the IKE v2 design from candidate approaches. > >Sep 02 IKE v2 Internet-Drafts to working group last call > >Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as > Proposed Standards. > > > > > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Fri Aug 10 03:30:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AAUfN13347; Fri, 10 Aug 2001 03:30:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26018 Fri, 10 Aug 2001 05:55:24 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15219.45309.512663.854766@thomasm-u1.cisco.com> Date: Fri, 10 Aug 2001 03:01:33 -0700 (PDT) To: Henry Spencer Cc: Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Thu, 9 Aug 2001, Jan Vilhuber wrote: > > Hm.. Not sure where to go with this discussion. What's the difference between > > people (and not just one or two) *thinking* they need something, and it being > > true that they need it? If there's enough of them, then it becomes true. > > No; belief and reality *are* different. The way you tell the difference > is to design and build a decent-but-not-all-things-to-all-people solution, > and listen to see if the outraged screams and angry grumbling slowly die > away. Ah, the beloved OS vendor to the masses stance. Glad to know where you stand. Mike From owner-ipsec@lists.tislabs.com Fri Aug 10 03:30:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AAUgN13355; Fri, 10 Aug 2001 03:30:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25991 Fri, 10 Aug 2001 05:36:55 -0400 (EDT) Message-Id: <200108100942.f7A9gsu80466@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Horn, Mike" cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of Thu, 09 Aug 2001 21:38:01 MDT. Date: Fri, 10 Aug 2001 11:42:54 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: => note I am not the authors of the AH for IPv4 source routing idea (which was given as a *historical* suggested main use of AH). So don't blame me if your poll shows AH is not used for that (I'll be very surprised if you get another answer :-). PS: don't blame Dan McDonald (the real author) too because he made very clear in his mail that the idea was an "old motivator". BTW to forward Dan's whole message to ISP/ops (i.e. NANOG) is still interesting because if the IPv4 source routing is dead this is not (yet?) the case for the IPv6 one. There are "ISP/ops" types on this list. I do not know of anyone using AH for securing source-routed packets being used for debugging. In fact I know of very few people using AH for *anything*. I have forwarded the question to the NANOG (North American Network Operators Group). I will summarize replies and forward to the IPSEC mailing list. => please do this for the complete original message. Also, I think that keeping transport mode is important. One common VPN application for transport mode is securing IP in IP tunnels (see draft-touch-ipsec-vpn-01.txt). => I believe there will be more opposition to remove transport mode than AH. BTW the current task (and the name of the thread) is to clean up IKE only (and we can say it needs this :-). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Aug 10 03:30:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AAUiN13371; Fri, 10 Aug 2001 03:30:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26010 Fri, 10 Aug 2001 05:53:54 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15219.45210.406744.263294@thomasm-u1.cisco.com> Date: Fri, 10 Aug 2001 02:59:54 -0700 (PDT) To: Henry Spencer Cc: Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > > The existence of KINK is another proof. There's obviously people that need > > extremely fast and light-weight keying, which KINK (again arguably) provides > > (for certain scenarios). > > Again, there are people who *think* they need better keying performance, > but that doesn't make it true. (There were a lot of people who thought > they needed better data-transfer protocol performance than TCP/IP could > deliver. They put a lot of work into "lightweight" alternatives, most of > which are dead and forgotten, superseded by TCP/IP.) I don't know how much proof you need. An eight exchange setup with the requisite public key operations would make IKE an unsuitable alternative for end to end keying for, say, SIP traffic where people have built in expectations of post dial delay. In fact, even a two message exchange with cheap symmetric keying is problematic; there's a lot of other baggage than just key agreement when you're trying to set up a call. Mike From owner-ipsec@lists.tislabs.com Fri Aug 10 04:09:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AB9sN14809; Fri, 10 Aug 2001 04:09:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26207 Fri, 10 Aug 2001 06:32:55 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15219.47586.613484.396301@thomasm-u1.cisco.com> Date: Fri, 10 Aug 2001 03:39:30 -0700 (PDT) To: Jan Vilhuber Cc: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On thing that might help to show that there really is a division in the problem space is that VPN's generally compete with the time it takes a modem to train -- ie, they are replacing dial and its expectations which has a lot of head room for fat. It's hard to imagine how you coujld make a VPN startup worse than that. On the other hand, we have transport like uses which have the expectation that anything you add beyond SYN/SYN-ACK/ACK is unwanted overhead (or less). Many thing are already piling on with just-one-more-exchangeitus, and security (along with signaled QoS) deliver us pretty quickly to hell by way of handbasket. So, I really don't have a very good opinion on how to make the engineering tradeoffs, but it seems as long as there is transport mode IPsec, this sort of debate is going to go on. [and to the fans of killing transport, do tell what the viable alternative is to IPsec, and please don't say TLS since it doesn't work with UDP] Mike Jan Vilhuber writes: > On Thu, 9 Aug 2001, Henry Spencer wrote: > > > On Thu, 9 Aug 2001, Jan Vilhuber wrote: > > > It's either a single protocol with lots of options and knobs to tune > > > behaviour, or multiple fairly fixed and well-defined protocols that are > > > suited for different tasks... There's no 'one-size fits all' keying protocol. > > > > That may be true, but it is not a self-evident fact. > > Hm.. I think it is. The fact that both main mode and aggressive mode exist, > is proof that there's (at least) two camps that needed to be satisfied in > IKE. One camp wants more security and versatility (negotiation, if you can > call it that), and another camp wants more speed and is willing to sacrifice > identity protection and negotiation. > > The existence of KINK is another proof. There's obviously people that need > extremely fast and light-weight keying, which KINK (again arguably) provides > (for certain scenarios). > > Personally, I consider that incontrovertible evidence, if not proof. > > > > And often it > > suffices for a protocol to be "one size fits almost all". > > > That doesn't really contradict what I said, of course. If you can get a good > fit for 90%, then you still need a separate protocol for the other 10% (if > they have a strong enough case, which I would argue they have and point at > the KINK WG again). I believe (and again KINK is evidence) that there ISN'T a > fit for 90%. More like 60/40. > > All this back and forth in this WG is yet another piece of evidence that > there's no one-size-fits all (or even almost all). Some want AH, others want > to get rid of it. Some want main mode, other want aggressive mode. Ad > nauseum... > > I'm not advocating we do them in parallel. Let's define some requirements > that simplifies as much as possible, agree on what can be left out to acheive > that, and send people that don't agree off to write their own requirements > (can't the WG chairs appoint sub-committee's to explore and recommend? Maybe > we should do that). > > I think it's actually crucial we spell out what the camps are and what they > need. We currently (I claim) have NO good requirements to go off and revise > IKE, since we don't really know what we're optimizing it for. Do we want > maximum security? Or fast setup? Unless someone shows me an exchange that > combines both, I'm going to continue to claim that those two are mutually > exclusive (I'd be happy to be proven wrong). As long as that dichotomy exists > (amongst others), we'll need two protocols (or one that can do both... > whoops... we already did that once). > > Or maybe we just point over to KINK and say "there's your fast setup" and > deal only with the one that does maximum security? Fine by me. But we need to > spell it out, so we can all start working in the same direction... > > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Fri Aug 10 06:00:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AD0QN19432; Fri, 10 Aug 2001 06:00:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26404 Fri, 10 Aug 2001 08:11:25 -0400 (EDT) From: Steve.Robinson@psti.com Subject: Re: Simplifying IKE To: Francis Dupont Cc: andrew.krywaniuk@alcatel.com, "'Dan McDonald'" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, "'Sandy Harris'" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 10 Aug 2001 08:22:32 -0400 X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at 08/10/2001 01:23:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont cc: andrew.krywaniuk@alcatel.com, "'Dan McDonald'" Sent by: , ipsec@lists.tislabs.com, owner-ipsec@lists.tisla owner-ipsec@lists.tislabs.com, "'Sandy Harris'" bs.com Subject: Re: Simplifying IKE 08/09/01 11:49 AM In your previous mail you wrote: While I certainly agree that the attack described in the Ferguson/Schneier paper on ESP was esoteric, I disagree on your conclusion that no damage will be done. Let's assume that no attack is occurring. What if the system administrator enters the section of the key used for decryption incorrectly? Authentication will work correctly, but right now, there is no verification mechanism in place to assure that the plaintext is not garbage, and once you pass garbage up to the upper layers, the behaviour is system specific and unknown -- it could range from catastrophic to no damage at all. => I don't buy this argument: upper layers are reading to eat garbage because garbage can occur on lower layer transmisson errors. They usually use a checksum for that. STEVE: Yes, checksums, when used, will catch the garbage. But I still like to follow the ideals of robust programming and not rely on the upper layer for catching what could be a bad design in the lower layers. I like the principals behind object oriented design, in that the lower layers shouldn't know what the upper layers are doing, and visa versa -- so each layer should do what it can to make sure that the data received is not garbage, and if the need is there, to make sure that the data it is passing up to the next layer isn't garbage either. Knowledge of upper layer behaviour, in my mind, violates the principals of separating layer behaviour. I also realize that in practice this is not always possible. However, I believe that this reason alone is NOT good enough to justify modification of an established protocol. My personal preference is for the eventual simplification of IPsec by having a single security protocol. >From what I have seen historically from this thread, it is probably better to establish a new protocol that will obsolete AH and ESP some time down the road, rather than attempt modification of either of the two established protocols we have. Anyway, I won't comment further on this, it is kinda off topic, and I know the working group is currently concentrating it's efforts on IKE modifications. Take Care, steve.robinson@psti.com Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Aug 10 06:22:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ADM3N20020; Fri, 10 Aug 2001 06:22:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26436 Fri, 10 Aug 2001 08:42:38 -0400 (EDT) Date: Thu, 09 Aug 2001 18:17:12 -0700 From: Derrell Piper To: sommerfeld@East.Sun.COM, Michael Thomas cc: Ari Huttunen , Dan McDonald , Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE Message-ID: <976979.997381032@el-air-2.electric-loft.org> In-Reply-To: <200108092352.f79NqSJ20568@thunk.east.sun.com> References: <200108092352.f79NqSJ20568@thunk.east.sun.com> X-Mailer: Mulberry/2.1.0b3 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk QM with PFS has never really been all that "quick". However, it seems a valuable attribute that the relatively long-lived Phase 1 IKE SA's allow for seamless Phase 2 rekeying (when done right). This would be much harder if there were just one single negotiation. Derrell --On Thursday, August 9, 2001 7:52 PM -0400 Bill Sommerfeld wrote: >> Ari Huttunen writes: >> > Thus my preference would be to have a four packet phase 1 (base mode) >> > and a four packet quick mode. >> >> Gad. Doesn't anybody care about link up times??? > > Smooshing phase 1 and phase 2 together begins to look very attractive > when quick mode isn't very (quick). > > - Bill > > From owner-ipsec@lists.tislabs.com Fri Aug 10 07:07:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AE7EN21443; Fri, 10 Aug 2001 07:07:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26497 Fri, 10 Aug 2001 09:15:42 -0400 (EDT) Message-ID: From: "Horn, Mike" To: "'tytso@mit.edu'" , ipsec@lists.tislabs.com Subject: RE: DRAFT: ipsec charter update Date: Thu, 9 Aug 2001 22:31:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think this is definitely a step in the right direction, but it seems in direct conflict with the position statement that was just sent out by Marcus Leech. Does this have approval from the IESG and IAB? Also, how does this fit in with the work going on to simplify IKE? Are things like removing AH, aggresive mode, etc. still open for discussion? Again, it's great to see the working group moving forward to provide standardized solutions for known problems. Mike Horn > -----Original Message----- > From: tytso@mit.edu [mailto:tytso@mit.edu] > Sent: Thursday, August 09, 2001 7:11 AM > To: ipsec@lists.tislabs.com > Subject: DRAFT: ipsec charter update > > > > The IPSEC wg chairs met with Marcus Leech today, and after discussions > and consultation with him, we have developed the following > draft update > to the IPSEC working group charter. > > Contained in this proposed update is a timeline for the IKE V2 work > which was discussed at the IPSEC meeting earlier week in London. We > welcome comments and suggestions on improving the revised > working group > charter. We would like to submit this charter to the IESG for > consideration by the end of August, so we would appreciate receiving > comments within the next two weeks. > > Barbara Fraser > Theodore Ts'o > IPSEC wg chairs > > > IP Security Protocol (ipsec) > > Last Modified: 09-Aug-01 > > Chair(s): > Barbara Fraser > Theodore Ts'o > > Security Area Director(s): > Jeffrey Schiller > Marcus Leech > > Security Area Advisor: > Jeffrey Schiller > > Mailing Lists: > General Discussion:ipsec@lists.tislabs.com > to Subscribe: ipsec-request@lists.tislabs.com > Archive: ftp://ftp.tis.com/pub/lists/ipsec OR > ftp.ans.net/pub/archive/ipsec > > Description of Working Group: > ============================= > > Rapid advances in communication technology have accentuated > the need for > security in the Internet. The IP Security Protocol Working Group > (IPSEC) will develop mechanisms to protect client protocols of IP. A > security protocol in the network layer will be developed to provide > cryptographic security services that will flexibly support > combinations > of authentication, integrity, access control, and confidentiality. > > The IPSEC working group will restrict itself to the following > short-term > work items to improve the existing key management protocol (IKE): > > 1) Changes to IKE to support NAT/Firewall traversal > > 2) Changes to IKE to support SCTP > > 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and > a fast AES mode suitable for use in hardware encryptors > > 4) IKE MIB documents > > 5) Sequence number extensions to ESP to support an expanded sequence > number space. > > 6) Clarification and standardization of rekeying procedures in IKE. > > The working group will also update IKE to reflect implementation > experience, new requirements, and protocol analysis of the existing > protocol. The requirements for IKE V2 will be revised and updated as > the first step in this process. > > Goals and Milestones: > ===================== > > Aug 01 Internet Drafts on NAT and Firewall traversal, > IKE MIBs, and > requirements for IPsec and IKE for use with SCTP, to working > group last call. > > Sep 01 Submit revised Internet-Drafts of NAT and > Firewall traversal, IKE > MIBs, and SCTP support for considerations as Draft Standards. > > Oct 01 Internet-Drafts on sequence number expansion in > IKE, and IKE > re-keying completed. > > Dec 01 Internet-Drafts on AES/SHA-2, sequence number > expansion, and IKE > re-keying to working group last call. > > Dec 01 Internet-Draft on IKE v2 Requirements to > working group last call > > Dec 01 Internet-Drafts describing candidate IKE v2 > approaches submitted > to the working group. > > Feb 01 Submit revised Internet-Drafts on AES/SHA-2, > sequence number > expansion, and IKE rekeying for consideration as Draft > Standards. > > Apr 02 Discuss and select the IKE v2 design from > candidate approaches. > > Sep 02 IKE v2 Internet-Drafts to working group last call > > Dec 02 Submit IKE v2 Internet-Drafts to the IESG for > consideration as > Proposed Standards. > > > > From owner-ipsec@lists.tislabs.com Fri Aug 10 07:08:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AE8hN21506; Fri, 10 Aug 2001 07:08:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26503 Fri, 10 Aug 2001 09:16:43 -0400 (EDT) Reply-To: From: "JEEVA" To: Subject: openBSD testing doubts Date: Fri, 10 Aug 2001 12:43:03 +0530 Message-Id: <000001c1216b$e6ab7c60$2a05080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Disposition-Notification-To: "JEEVA" Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, we are working in openBSD2.9 ipsec code. we first tested for manual key between two hosts . In Host A: sysctl -w net.inet.esp.enable=1 sysctl -w net.inet.esp.enable=1 ipsecadm new esp -spi 1000 -src HostA -dst HostB -forcetunnel enc 3des -auth sha1 -key 7762d8707255d974168cbb1d274f8bed4cbd3364dd -authkey 6a20367e21c66e5a40739db293cfef2a4e6659f ipsecadm new esp -spi 1001 -src HostB -dst HostA -forcetunnel enc 3des -auth sha1 -key 7762d8707255d974168cbb1d274f8bed4cbd3364dd -authkey 6a20367e21c66e5a40739db293cfef2a4e6659f ipsecadm flow -proto esp -dst HostB -addr HostA 255.255.255.255 HostB 255.255.255.255 -in -require upto this working fine. but when i try to enter ipsecadm flow -proto esp -dst HostB -addr HostA 255.255.255.255 HostB 255.255.255.255 -out -require it's giving Sendto : not permitted error in runtime. so, i deleted this line , i kept only inbound flow in HostA Host B: sysctl -w net.inet.esp.enable=1 sysctl -w net.inet.esp.enable=1 ipsecadm new esp -spi 1001 -src HostB -dst HostA -forcetunnel enc 3des -auth sha1 -key 7762d8707255d974168cbb1d274f8bed4cbd3364dd -authkey 6a20367e21c66e5a40739db293cfef2a4e6659f ipsecadm new esp -spi 1000 -src HostB -dst HostA -forcetunnel enc 3des -auth sha1 -key 7762d8707255d974168cbb1d274f8bed4cbd3364dd -authkey 6a20367e21c66e5a40739db293cfef2a4e6659f ipsecadm flow -proto esp -dst HostA -addr HostA 255.255.255.255 HostB 255.255.255.255 -in -require upto this working fine. but when i try to enter ipsecadm flow -proto esp -dst HostA -addr HostA 255.255.255.255 HostB 255.255.255.255 -out -require it's giving Sendto : not permitted error in runtime. so, i deleted this line , i kept only inbound flow in HostA After this: i checked both hosts with ping and tcpdump it's giving icmp_request icmp_reply then i kept different keys(enc and auth key) and tested between both hosts. again its giving icmp_request icmp_reply i checked with both Hosts by using netstat -rn it's giving correct SA details in both sides. but i checked with netstat -ss -p esp it's giving only esp: not giving any details . i donno how actually we have to findout whether manual keying is working or not. Note: here i kept ipf.filter=NO in /etc/rc.conf and i enabled forwarded capacity also(sysctl -w inet.net.forwarded.enable=1) expecting ur reply, thanks, jeeva From owner-ipsec@lists.tislabs.com Fri Aug 10 07:10:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AEAVN21574; Fri, 10 Aug 2001 07:10:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26486 Fri, 10 Aug 2001 09:14:42 -0400 (EDT) Message-ID: From: "Horn, Mike" To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: RE: Simplifying IKE Date: Thu, 9 Aug 2001 21:38:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis, There are "ISP/ops" types on this list. I do not know of anyone using AH for securing source-routed packets being used for debugging. In fact I know of very few people using AH for *anything*. I have forwarded the question to the NANOG (North American Network Operators Group). I will summarize replies and forward to the IPSEC mailing list. Also, I think that keeping transport mode is important. One common VPN application for transport mode is securing IP in IP tunnels (see draft-touch-ipsec-vpn-01.txt). Mike Horn > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Wednesday, August 08, 2001 6:48 AM > To: Dan McDonald > Cc: Sandy Harris; ipsec@lists.tislabs.com > Subject: Re: Simplifying IKE > > > In your previous mail you wrote: > > > 2a: eliminate ESP authentication > > 3a: require AH on all packets. No choice, no null mode. An IPsec > > connection authenticates all packets, period. > > Choice 3a was the original intent of the SIPP security > architecture (which > became the 182x series of IPsec RFCs).... > > The biggest motivator behind AH was to allow an > authenticated source route. > Now as Steve Bellovin has pointed out, unless you can > configure a hop-by-hop > key, the middle can send that packet anywhere it wants > before it reaches the > end. > > I wish there were some ISP/ops types on this list (maybe > there are and I'm > just being an airhead). I believe the source route header > is primarily used > to see what paths are broken in a network - using the > process of elimination. > Using AH (or ESP authentication) insures that the packet > came from where it > claims to have come from. THAT is why AH was developed, but ESP > authentication can provide a source-routed packet with > similar properties. > > => (about the last statement) how? ESP authentication doesn't > cover headers. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: I am not in favor to reduce IPsec to VPNs, the thing > which will happen > if we remove AH then transport mode... > From owner-ipsec@lists.tislabs.com Fri Aug 10 07:10:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AEAWN21585; Fri, 10 Aug 2001 07:10:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26509 Fri, 10 Aug 2001 09:17:43 -0400 (EDT) From: Ghislaine Labouret To: ipsec@lists.tislabs.com Subject: Re: DRAFT: ipsec charter update Date: Fri, 10 Aug 2001 11:18:32 +0100 Organization: HSC (Herve Schauer Consultants) References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20010810101741.65ED510E8D@itesec.hsc.fr> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 09 Aug 2001 09:10:59 -0400, tytso@mit.edu wrote: > The IPSEC working group will restrict itself to the following short-term > work items to improve the existing key management protocol (IKE): As JI pointed out yesterday during SAAG, there are two work areas: IPsec transforms and key management. If we keep them in the same group, I think the charter should clearly mention those two areas and not just IKE. Especially since (1) the work items list includes transforms-level items and (2) architecture and transforms evolutions have been subject to discussions on the list recently (SA identification, death to AH...). Also, if we want to head toward two groups, starting to list the work items for each might prove useful. Sincerely, -- Ghislaine Labouret, Network security consultant Hervé Schauer Consultants (HSC) - http://www.hsc.fr/ Phone (+33)-141-409-700 - Fax (+33)-141-409-709 From owner-ipsec@lists.tislabs.com Fri Aug 10 07:17:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AEH7N21900; Fri, 10 Aug 2001 07:17:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26638 Fri, 10 Aug 2001 09:34:21 -0400 (EDT) Message-ID: From: Chris Trobridge To: ipsec@lists.tislabs.com Cc: Derrell Piper Subject: RE: Simplifying IKE Date: Fri, 10 Aug 2001 14:37:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This assumes that the phase 1 does live longer than phase 2. Quite apart from implementations killing off the phase 1 before the renogitation, it may well be policy that the phase 1 SA has a similar life to the pase 2 SA. Chris > QM with PFS has never really been all that "quick". However, > it seems a > valuable attribute that the relatively long-lived Phase 1 IKE > SA's allow > for seamless Phase 2 rekeying (when done right). This would > be much harder > if there were just one single negotiation. > > Derrell > > --On Thursday, August 9, 2001 7:52 PM -0400 Bill Sommerfeld > wrote: > > >> Ari Huttunen writes: > >> > Thus my preference would be to have a four packet > phase 1 (base mode) > >> > and a four packet quick mode. > >> > >> Gad. Doesn't anybody care about link up times??? > > > > Smooshing phase 1 and phase 2 together begins to look very > attractive > > when quick mode isn't very (quick). > > > > - Bill > > > > > > > > > > This footnote confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Fri Aug 10 08:33:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AFX9N06456; Fri, 10 Aug 2001 08:33:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26828 Fri, 10 Aug 2001 10:30:43 -0400 (EDT) Date: Fri, 10 Aug 2001 16:37:46 +0200 (MET DST) From: Hakan Olsson To: JEEVA Cc: Subject: Re: openBSD testing doubts In-Reply-To: <000001c1216b$e6ab7c60$2a05080a@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First, this is not the place for questions such as this. Try the misc@openbsd.org list. Second, start by reading vpn(8), then look at /usr/share/ipsec/rc.vpn. You should find what you're looking for there. /H -- Hĺkan Olsson (+46) 708 437 337 Carlstedt Research Unix, Networking, Security (+46) 31 701 4264 & Technology AB From owner-ipsec@lists.tislabs.com Fri Aug 10 08:49:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AFnlN11629; Fri, 10 Aug 2001 08:49:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26966 Fri, 10 Aug 2001 11:06:50 -0400 (EDT) Message-ID: <9A4F653B0A375841AC75A8D17712B9C9011964CC@sottmxs04.entrust.com> From: Andrew Codrington To: "'ipsec@lists.tislabs.com'" Subject: Entrust CA services for Espoo IPSec interop event Date: Fri, 10 Aug 2001 11:13:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C121AE.FB87C650" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C121AE.FB87C650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the purposes of the August 2001 Espoo, FI IPSec interoperability = testing event, Entrust has set up 3 Certification Authorities.=20 Configuration and enrollment instructions are provided here: http://204.101.128.45 =20 Two are cross-certified, using RSA keys, and the third is using DSA = keys. PKCS#10 and SCEP enrollment requests are granted automatically.=20 Please contact IPSecBakeoff2001@entrust.com for PKIX-CMP enrollment reference numbers = and authentication codes if you are testing a PKIX-CMP implementation or = using Entrust Toolkits.=20 =20 Best regards, Andrew -- Andrew Codrington Product Manager, VPN Solutions andrew.codrington@entrust.com Phone: (613) 270-3422 Fax: (613) 270-2505 Cell: (613) 262-5264 =20 Entrust=AE Securing the Internet =20 ------_=_NextPart_001_01C121AE.FB87C650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

For the purposes of the August 2001 = Espoo, FI IPSec interoperability testing event, Entrust has set up 3 = Certification Authorities.

Configuration and enrollment instructions = are provided here:

http://204.101.128.45=

 

Two are cross-certified, using RSA keys, = and the third is using DSA keys.

PKCS#10 and SCEP enrollment requests are = granted automatically. =

Please contact IPSecBakeo= ff2001@entrust.com for PKIX-CMP enrollment reference numbers and = authentication codes if you are testing a PKIX-CMP implementation or using Entrust = Toolkits. =

 

=

Best regards,

Andrew

--=

<= font color=3Dblack>Andrew = Codrington=

Product Manager, = VPN Solutions=

andrew.codrington@entrust.com=

Phone: (613) = 270-3422=

Fax: (613) = 270-2505=

Cell: (613) = 262-5264=

 =

Entrust=AE=

Securing the = Internet=

 =

------_=_NextPart_001_01C121AE.FB87C650-- From owner-ipsec@lists.tislabs.com Fri Aug 10 09:42:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AGgoN18132; Fri, 10 Aug 2001 09:42:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27067 Fri, 10 Aug 2001 11:52:05 -0400 (EDT) From: mcnelson@mindspring.com Date: Fri, 10 Aug 2001 11:59:13 -0400 To: tytso@mit.edu Cc: ipsec@lists.tislabs.com Subject: Re: DRAFT: ipsec charter update Message-ID: X-Originating-IP: 208.37.68.36 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Barbara and Theodore, How is "client protocol of IP" defined? Usually one thinks of the legitimate, sensible and/or meaningful clients of a security service as being the n+1 layer entities (see x.800). I feel that it is very likely that herein lies the root cause of the problem and that if so, no amount of ad-hoc improvement within the current paradigm is going to make it go away. If we want simplicity and effectiveness we should focus our attention narrowly on the simple paradigm of n layer mechanisms that implement services for n+1 layer entities. The charter as stated seems to only further the basic underlying difficulties. The now legacy approach has led to a nearly decade long effort and the apparent need of a 12 inch high stack of paper to describe how to encrypt an IP datagram. Let's try something new. Regards, Mitch Nelson Dr. Mitchell C. Nelson Director, Software Services Datatek Applications, Inc. tytso@mit.edu wrote: > The IPSEC wg chairs met with Marcus Leech today, and after discussions and consultation with him, we have developed the following draft update to the IPSEC working group charter. Contained in this proposed update is a timeline for the IKE V2 work which was discussed at the IPSEC meeting earlier week in London. We welcome comments and suggestions on improving the revised working group charter. We would like to submit this charter to the IESG for consideration by the end of August, so we would appreciate receiving comments within the next two weeks. Barbara Fraser Theodore Ts'o IPSEC wg chairs IP Security Protocol (ipsec) Last Modified: 09-Aug-01 Chair(s): Barbara Fraser Theodore Ts'o Security Area Director(s): Jeffrey Schiller Marcus Leech Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:ipsec@lists.tislabs.com to Subscribe: ipsec-request@lists.tislabs.com Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec Description of Working Group: ============================= Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The IPSEC working group will restrict itself to the following short-term work items to improve the existing key management protocol (IKE): 1) Changes to IKE to support NAT/Firewall traversal 2) Changes to IKE to support SCTP 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and a fast AES mode suitable for use in hardware encryptors 4) IKE MIB documents 5) Sequence number extensions to ESP to support an expanded sequence number space. 6) Clarification and standardization of rekeying procedures in IKE. The working group will also update IKE to reflect implementation experience, new requirements, and protocol analysis of the existing protocol. The requirements for IKE V2 will be revised and updated as the first step in this process. Goals and Milestones: ===================== Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and requirements for IPsec and IKE for use with SCTP, to working group last call. Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE MIBs, and SCTP support for considerations as Draft Standards. Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE re-keying completed. Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE re-keying to working group last call. Dec 01 Internet-Draft on IKE v2 Requirements to working group last call Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted to the working group. Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE rekeying for consideration as Draft Standards. Apr 02 Discuss and select the IKE v2 design from candidate approaches. Sep 02 IKE v2 Internet-Drafts to working group last call Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as Proposed Standards. From owner-ipsec@lists.tislabs.com Fri Aug 10 10:29:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AHT6N19307; Fri, 10 Aug 2001 10:29:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27134 Fri, 10 Aug 2001 12:41:10 -0400 (EDT) Date: Fri, 10 Aug 2001 12:25:49 -0400 (EDT) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <15219.45309.512663.854766@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 10 Aug 2001, Michael Thomas wrote: > > No; belief and reality *are* different. The way you tell the difference > > is to design and build a decent-but-not-all-things-to-all-people solution, > > and listen to see if the outraged screams and angry grumbling slowly die > > away. > > Ah, the beloved OS vendor to the masses stance. No, actually, the Unix/TCP-IP/C stance. Build a decent general-purpose solution, and most of the people who were complaining about needing custom solutions will discover that general-purpose solutions really are good enough for them after all. Of course, if instead you build a crappy general-purpose solution, this will just reinforce their belief that they need custom solutions. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Aug 10 11:23:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AINNN20508; Fri, 10 Aug 2001 11:23:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27255 Fri, 10 Aug 2001 13:32:33 -0400 (EDT) Message-Id: <4.3.2.7.1.20010810102631.00c99af0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Aug 2001 10:35:41 -0700 To: "jyothi" , From: Ramana Yarlagadda Subject: Re: Position of certificate payload in IKE Aggressive Mode as Initiator Cc: kalyan_bade@yahoo.com In-Reply-To: <008e01c120c8$3ce25b20$700110ac@roc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jyothi At 05:11 PM 8/9/01 +0530, jyothi wrote: >Hi, > Kindly clarify the following doubt. > > Scenario : IKE Phase 1 Negotiation (Aggressive Mode) authenticated >with signatures > As an Initiator, can the certificate payload be sent in first message >or is it mandatory to be sent in third message only. In the subsection >Certificate Payload of section ISAKMP Payloads contained in RFC 2408, the >following statement is present. "The Certificate Payload MUST be accepted at >any point during an exchange". I understand from this statement that the >responder has to accept Certificate payload either in first message or third >message, which in turn provides the base for the assunption that initiator >can send the certificate payload in first msg or third msg. I think NO, looking at the section 5.1. -cheers -ramana From owner-ipsec@lists.tislabs.com Fri Aug 10 13:44:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AKikN23500; Fri, 10 Aug 2001 13:44:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27437 Fri, 10 Aug 2001 15:33:52 -0400 (EDT) Message-ID: <3B7439E1.5040404@kolumbus.fi> Date: Fri, 10 Aug 2001 22:45:37 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer Cc: Jan Vilhuber , ipsec@lists.tislabs.com Subject: Scope for the new keying protocol [Was: Simplifying IKE] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > That may be true, but it is not a self-evident fact. And often it > suffices for a protocol to be "one size fits almost all". Indeed true. I'm just afraid that we end up with a definition of "almost all" that includes DSL geeks but excludes a billion mobile users... Jari From owner-ipsec@lists.tislabs.com Fri Aug 10 13:44:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AKimN23515; Fri, 10 Aug 2001 13:44:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27456 Fri, 10 Aug 2001 15:52:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20010810125636.042051a8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Aug 2001 12:57:47 -0700 To: ipsec@lists.tislabs.com From: Mark Baugher Subject: Re: DRAFT: ipsec charter update In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Barbara and Theodore, > >How is "client protocol of IP" defined? Maybe this is a nit, but why "client protocol" and not "host protocol?" Mark >Usually one thinks of the legitimate, sensible and/or meaningful clients >of a security service as being the n+1 layer entities (see x.800). > >I feel that it is very likely that herein lies the root cause of the >problem and that if so, no amount of ad-hoc improvement within the current >paradigm is going to make it go away. > >If we want simplicity and effectiveness we should focus our attention >narrowly on the simple paradigm of n layer mechanisms that implement >services for n+1 layer entities. > >The charter as stated seems to only further the basic underlying >difficulties. The now legacy approach has led to a nearly decade long >effort and the apparent need of a 12 inch high stack of paper to describe >how to encrypt an IP datagram. > >Let's try something new. > >Regards, >Mitch Nelson > > >Dr. Mitchell C. Nelson >Director, Software Services >Datatek Applications, Inc. > > > > > >tytso@mit.edu wrote: > > The IPSEC wg chairs met with Marcus Leech today, and after discussions >and consultation with him, we have developed the following draft update >to the IPSEC working group charter. > >Contained in this proposed update is a timeline for the IKE V2 work >which was discussed at the IPSEC meeting earlier week in London. We >welcome comments and suggestions on improving the revised working group >charter. We would like to submit this charter to the IESG for >consideration by the end of August, so we would appreciate receiving >comments within the next two weeks. > > Barbara Fraser > Theodore Ts'o > IPSEC wg chairs > > >IP Security Protocol (ipsec) > >Last Modified: 09-Aug-01 > >Chair(s): > Barbara Fraser > Theodore Ts'o > >Security Area Director(s): > Jeffrey Schiller > Marcus Leech > >Security Area Advisor: > Jeffrey Schiller > >Mailing Lists: > General Discussion:ipsec@lists.tislabs.com > to Subscribe: ipsec-request@lists.tislabs.com > Archive: ftp://ftp.tis.com/pub/lists/ipsec OR > ftp.ans.net/pub/archive/ipsec > >Description of Working Group: >============================= > >Rapid advances in communication technology have accentuated the need for >security in the Internet. The IP Security Protocol Working Group >(IPSEC) will develop mechanisms to protect client protocols of IP. A >security protocol in the network layer will be developed to provide >cryptographic security services that will flexibly support combinations >of authentication, integrity, access control, and confidentiality. > >The IPSEC working group will restrict itself to the following short-term >work items to improve the existing key management protocol (IKE): > >1) Changes to IKE to support NAT/Firewall traversal > >2) Changes to IKE to support SCTP > >3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and > a fast AES mode suitable for use in hardware encryptors > >4) IKE MIB documents > >5) Sequence number extensions to ESP to support an expanded sequence > number space. > >6) Clarification and standardization of rekeying procedures in IKE. > >The working group will also update IKE to reflect implementation >experience, new requirements, and protocol analysis of the existing >protocol. The requirements for IKE V2 will be revised and updated as >the first step in this process. > >Goals and Milestones: >===================== > >Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and > requirements for IPsec and IKE for use with SCTP, to working > group last call. > >Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE > MIBs, and SCTP support for considerations as Draft Standards. > >Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE > re-keying completed. > >Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE > re-keying to working group last call. > >Dec 01 Internet-Draft on IKE v2 Requirements to working group last call > >Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted > to the working group. > >Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number > expansion, and IKE rekeying for consideration as Draft Standards. > >Apr 02 Discuss and select the IKE v2 design from candidate approaches. > >Sep 02 IKE v2 Internet-Drafts to working group last call > >Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as > Proposed Standards. From owner-ipsec@lists.tislabs.com Sat Aug 11 13:50:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BKohN29702; Sat, 11 Aug 2001 13:50:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29300 Sat, 11 Aug 2001 15:29:56 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15221.35105.650068.940786@thomasm-u1.cisco.com> Date: Sat, 11 Aug 2001 12:36:01 -0700 (PDT) To: Chris Trobridge Cc: Arne Ansper , ipsec@lists.tislabs.com Subject: RE: Simplifying IKE In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC 2207 allows you to select RSVP flows based on the SPI. Mike Chris Trobridge writes: > There is always TOS. Packet length, even? > > How can you use the SPI to sort traffic? This assumes the access router > knows which SPI corresponds to which traffic. > > Actually classifying traffic after applying ESP is a major hasssle for ISPs. > OTOH, they don't often understand the security consequences of leaking the > sort of info classification uses - which is often into the application > layer! > > Chris > > > > I'd also like to see all IPSEC traffic between two hosts > > carried by just one > > > SA. I can't see any value in using multiple SAs between to > > hosts. IPSEC > > > > there is. and it's not related to security at all. > > > > suppose you have slow internet connection that is used only for VPN > > traffic. your access router has no way to distinguish between > > different > > sessions inside your VPN so it will put all the packets into > > same queue. > > if somebody is moving large file using ftp your telnet > > connection will be > > very very slow. > > > > without encryption the routers will put packets from separate sessions > > (defined by src&dst IP, protocol and ports) into seprate queues (cisco > > calls them classes IIRC) and even if you are downloading some > > huge file > > your telnet session is still usable. > > > > with encryption the SPI is the only parameter that can be > > used to classify > > the packets. if you are using a single SA between two hosts it's > > impossible for routers to distinguish between packets from different > > sessions and the interactive applications suffer really bad. > > > > arne > > > ----------------------------------------------------------------------------------------------------------------- > The information contained in this message is confidential and is intended > for the addressee(s) only. If you have received this message in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this message is > strictly forbidden. Baltimore Technologies plc will not be liable for direct, > special, indirect or consequential damages arising from alteration of the > contents of this message by a third party or as a result of any virus being > passed on. > > In addition, certain Marketing collateral may be added from time to time to > promote Baltimore Technologies products, services, Global e-Security or > appearance at trade shows and conferences. > > This footnote confirms that this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including > computer viruses. > From owner-ipsec@lists.tislabs.com Sat Aug 11 13:50:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BKouN29717; Sat, 11 Aug 2001 13:50:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29358 Sat, 11 Aug 2001 16:08:06 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15221.37384.191416.901953@thomasm-u1.cisco.com> Date: Sat, 11 Aug 2001 13:14:00 -0700 (PDT) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com, FreeS/WAN Design Issues Subject: Re: Wes Hardaker: opportunistic encryption deployment problems In-Reply-To: References: <15216.5899.191140.121446@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Tue, 7 Aug 2001, Michael Thomas wrote: > > I guess I have to ask a really dumb question. Given the > > likelihood of DNSSEC any time soon, why don't we just > > ignore any pretense of authentication with opportunistic > > encryption and just accept the MITM attack inherent with > > ephemeral DH exchanges? > > We thought about that, but decided that some authentication was better > than none, especially since it would upgrade transparently to full > authentication. It's one thing to accept security loopholes as a > temporary measure, and another to define a protocol that will always have > security loopholes. Well... How is this especially different than just using self-signed certificates and having a wide open policy? I don't think there's anything protocolwise that even needs to be done there. Clearly you can upgrade that by using rooted certs in the future as well. I guess what bothers me is that you are expecting to use DNS as a directory service for certs which it wasn't really intended for thus making an already complicated situation even more complicated, but not changing the fundamental situation (PKI are hard). > > > Also: it seems to me that expecting > > a secure DNS isn't actually opportunistic at all: it's > > trying to assert a different source of (sometimes strong) identity... > > This basically boils down to what you think "opportunistic" means. We > don't see it as meaning "will talk to anybody, no setup necessary" but > rather "will talk to anybody who's set up for it". Some amount of setup > is clearly necessary anyway; we'd have liked to be able to talk to an > IPsec-capable host that's unaware of opportunistic encryption, but it > isn't possible. I guess that I view that there's probably an 80/20 rule here which is being missed: *most* people aren't going to go to the lengths of creating an active MITM attack to snoop on boring old every day conversations. Thus encrypting everything -- by accepting MITM attacks where there is no pragmatic alternative -- will kill off all of the passive snooping. Given the advent of wireless and the worthlessness of certain L2's so-called security, this is not an academic issue. Trying to insert an upgrade path back to the mythical global PKI rather misses the point: if there were such a beast, we could should be able to use IKE as-is (or at least we ought to be able to envision how to do that). Also: I think the MIP experience sez that we ought to consider whether we'd want such a PKI even if it were possible. Mike From owner-ipsec@lists.tislabs.com Sat Aug 11 14:33:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BLXFN01522; Sat, 11 Aug 2001 14:33:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29403 Sat, 11 Aug 2001 16:50:04 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15221.39915.19720.320652@thomasm-u1.cisco.com> Date: Sat, 11 Aug 2001 13:56:11 -0700 (PDT) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: References: <15219.45309.512663.854766@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Fri, 10 Aug 2001, Michael Thomas wrote: > > > No; belief and reality *are* different. The way you tell the difference > > > is to design and build a decent-but-not-all-things-to-all-people solution, > > > and listen to see if the outraged screams and angry grumbling slowly die > > > away. > > > > Ah, the beloved OS vendor to the masses stance. > > No, actually, the Unix/TCP-IP/C stance. Build a decent general-purpose > solution, and most of the people who were complaining about needing custom > solutions will discover that general-purpose solutions really are good > enough for them after all. > > Of course, if instead you build a crappy general-purpose solution, this > will just reinforce their belief that they need custom solutions. The general unix philosophy is to build small building blocks which can be bolted together too instead of overarching "solutions" (what was the problem again?). Not directly related here, but I think that what needs to be kept in mind here is that assumptions about VPN-like scenarios and their timing requirements are not necessarily good ones. Ideally, we'd have a base level exchange which is lightweight which can be used in conjunction with something else if the base mechanism doesn't provide all the required functionality. This way, the people who don't care about the extended functionality don't get it shoved down their throats. And I'd say an 8 message exchange just to talk to your opportunistically encrypted name-the-application-service is pretty obnoxiously overweight (talk about slow-start!). Mike From owner-ipsec@lists.tislabs.com Sat Aug 11 15:21:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BMLbN02301; Sat, 11 Aug 2001 15:21:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29493 Sat, 11 Aug 2001 17:29:33 -0400 (EDT) Date: Sat, 11 Aug 2001 17:33:53 -0400 (EDT) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: <15221.39915.19720.320652@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 11 Aug 2001, Michael Thomas wrote: > > No, actually, the Unix/TCP-IP/C stance. Build a decent general-purpose > > solution, and most of the people who were complaining about needing custom > > solutions will discover that general-purpose solutions really are good > > enough... > > The general unix philosophy is to build small building > blocks which can be bolted together too instead of > overarching "solutions" (what was the problem again?). That's *part* of the general Unix philosophy, but not all of it. Where problems looked diverse and flexibility seemed needed, then yes, building blocks and tools for combining them were provided. But when a single good compromise solution seemed possible, that solution was implemented and no alternatives, variations, or options were provided. For example, Unix offered exactly one filesystem user interface, and a very simple one it was too. This radical simplification (by the standards of the time) did wonders for the building-block philosophy at higher levels, because there was little room for incompatible views about what a file looked like. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sat Aug 11 15:48:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BMm9N02635; Sat, 11 Aug 2001 15:48:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29550 Sat, 11 Aug 2001 18:04:19 -0400 (EDT) Message-ID: <3B75AD92.E10C9445@storm.ca> Date: Sat, 11 Aug 2001 18:11:30 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Is base mode dead? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk With all the discussion of simplifying IKE, main mode vs. aggressive, the commit bit, ... I thought it was time I had a look at 'base mode'. I cannot find either an draft or an RFC. Is it dead? From owner-ipsec@lists.tislabs.com Sat Aug 11 18:41:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7C1f9N05670; Sat, 11 Aug 2001 18:41:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29754 Sat, 11 Aug 2001 20:39:55 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15221.53705.987014.155031@thomasm-u1.cisco.com> Date: Sat, 11 Aug 2001 17:46:01 -0700 (PDT) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: References: <15221.39915.19720.320652@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All of this is rather tangential to what is really at hand, of course. I notice that you haven't responded to the issue I brought up about the suitability of IKE in situations where user expectations haven't been set by near-infinite modem training times. Mike Henry Spencer writes: > On Sat, 11 Aug 2001, Michael Thomas wrote: > > > No, actually, the Unix/TCP-IP/C stance. Build a decent general-purpose > > > solution, and most of the people who were complaining about needing custom > > > solutions will discover that general-purpose solutions really are good > > > enough... > > > > The general unix philosophy is to build small building > > blocks which can be bolted together too instead of > > overarching "solutions" (what was the problem again?). > > That's *part* of the general Unix philosophy, but not all of it. > > Where problems looked diverse and flexibility seemed needed, then yes, > building blocks and tools for combining them were provided. > > But when a single good compromise solution seemed possible, that solution > was implemented and no alternatives, variations, or options were provided. > For example, Unix offered exactly one filesystem user interface, and a > very simple one it was too. This radical simplification (by the standards > of the time) did wonders for the building-block philosophy at higher > levels, because there was little room for incompatible views about what a > file looked like. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Sun Aug 12 03:11:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CAB5N07723; Sun, 12 Aug 2001 03:11:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00343 Sun, 12 Aug 2001 05:16:02 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Derrell Piper'" , Cc: Subject: RE: Simplifying IKE Date: Sun, 12 Aug 2001 10:04:52 +0100 Message-Id: <001801c1230f$3ca480e0$7a31788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <976979.997381032@el-air-2.electric-loft.org> Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is why I have never liked the PFS option. One of the main purposes of quick mode is to thwart traffic analysis on ESP data without greatly slowing down the protocol. That's why it's called "quick". The normal thing to do is to use quick mode w/o PFS and the ultra-paranoid thing to do is to do more frequent phase 1 rekeys. I can't think of a realistic threat model that PFS solves. (Michael Richardson did once point one out to me in which an 'ethical law-enforcement agency' forces you to reveal your keys, but they are ethically prevented from using those keys to impersonate you.) Of all the security vulnerabilities I have seen in the design of security protocols, a large percentage of them came about solely through the process of optimization. If we truly want to have a simple and analyzable protocol, we have to realize that simplicity does not come merely from reducing options; it also comes from being conservative in our assumptions and from clearly separating the protocol into independent stages. A lot of people who complain about the complexity of IKE have also been tacking on optimizations as part of their solutions. Whenever we try to optimize the protocol, we have to accept that this is a design tradeoff and security flaws may result. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell Piper > Sent: Friday, August 10, 2001 2:17 AM > To: sommerfeld@East.Sun.COM; Michael Thomas > Cc: Ari Huttunen; Dan McDonald; Sandy Harris; ipsec@lists.tislabs.com > Subject: Re: Simplifying IKE > > > QM with PFS has never really been all that "quick". However, > it seems a > valuable attribute that the relatively long-lived Phase 1 IKE > SA's allow > for seamless Phase 2 rekeying (when done right). This would > be much harder > if there were just one single negotiation. > > Derrell > > --On Thursday, August 9, 2001 7:52 PM -0400 Bill Sommerfeld > wrote: > > >> Ari Huttunen writes: > >> > Thus my preference would be to have a four packet > phase 1 (base mode) > >> > and a four packet quick mode. > >> > >> Gad. Doesn't anybody care about link up times??? > > > > Smooshing phase 1 and phase 2 together begins to look very > attractive > > when quick mode isn't very (quick). > > > > - Bill > > > > > > > > From owner-ipsec@lists.tislabs.com Sun Aug 12 03:11:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CABCN07737; Sun, 12 Aug 2001 03:11:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00349 Sun, 12 Aug 2001 05:16:05 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'jyothi'" , Subject: RE: Position of certificate payload in IKE Aggressive Mode as Initiator Date: Sun, 12 Aug 2001 10:10:43 +0100 Message-Id: <001a01c1230f$42458b20$7a31788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <008e01c120c8$3ce25b20$700110ac@roc.com> Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One of the things I talked about in my improveike presentation was simplifying parsing by restricting the messages in which certain payloads can appear. I specifically mentioned certreq and vendorid, but I would suggest that this be applied to the certificate payload as well. Let me put it this way: If you put the certificate in the 3rd message, EVERYONE will handle it. If you put the certificate in the 1st message, many people WILL NOT handle it, and even if they do, you are relying on mostly untested code. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of jyothi > Sent: Thursday, August 09, 2001 12:42 PM > To: ipsec@lists.tislabs.com > Subject: Position of certificate payload in IKE Aggressive Mode as > Initiator > > > Hi, > Kindly clarify the following doubt. > > Scenario : IKE Phase 1 Negotiation (Aggressive Mode) > authenticated > with signatures > As an Initiator, can the certificate payload be sent in > first message > or is it mandatory to be sent in third message only. In the subsection > Certificate Payload of section ISAKMP Payloads contained in > RFC 2408, the > following statement is present. "The Certificate Payload MUST > be accepted at > any point during an exchange". I understand from this > statement that the > responder has to accept Certificate payload either in first > message or third > message, which in turn provides the base for the assunption > that initiator > can send the certificate payload in first msg or third msg. > > thanks > sankar > > From owner-ipsec@lists.tislabs.com Sun Aug 12 03:13:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CADON08572; Sun, 12 Aug 2001 03:13:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00346 Sun, 12 Aug 2001 05:16:03 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: Cc: Subject: RE: Simplifying IKE Date: Sun, 12 Aug 2001 10:09:40 +0100 Message-Id: <001901c1230f$3f8077b0$7a31788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > While I certainly agree that the attack described in the > Ferguson/Schneier > paper on ESP was esoteric, I disagree on your conclusion that > no damage will be done. Let's assume that no attack is > occurring. What if > the system administrator enters the section of the key used > for decryption > incorrectly? IPsec is typically used with negotiated keying. Manual keying is most useful as a hook to allow arbitrary key exchange mechanisms. If you decide to hand enter the keys, you had better be extra careful that the information you type is correct. > Authentication will work correctly, but right > now, there is > no verification mechanism in place to assure that the plaintext is not > garbage, and once you pass garbage up to the upper layers, > the behaviour is > system specific and unknown -- it could range from catastrophic to no > damage at all. This attack does not allow the bad guy to modify only part of a message or to control the content of the corrupted message in any way. And in the situation you bring up, there is no bad guy. Upper layer protocols like TCP and UDP have checksums. Plus, the chance of creating a correctly formatted tunnelled IP packet is infinitesimal. > Authenticating the text after decryption > assures that the > correct plaintext is passed to the upper layers. So does including the key, but without causing the DoS vulnerability. So, to be a bit lawyerly, redesigning ESP is not necessary, and even if it was, you wouldn't need to reverse the order of the transforms. > If the > current order is > only maintained to ward off DoS, then I'd suggest that the > argument is > weak, since DoS can only be minimized, not eliminated. That's one of the problems with DoS... there always seems to be a new vulnerability to be found. However, let's imagine that, some time in the future, encryption is so widely deployed that a host can have a security policy which rejects all packets except ESP and IKE (and maybe some ICMP). Now we have a realistic chance of eliminating DoS simply by making it infeasible with those two protocols. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: Steve.Robinson@psti.com [mailto:Steve.Robinson@psti.com] > Sent: Thursday, August 09, 2001 3:10 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'Dan McDonald'; ipsec@lists.tislabs.com; > owner-ipsec@lists.tislabs.com; 'Sandy Harris' > Subject: RE: Simplifying IKE > > > > Andrew, > > While I certainly agree that the attack described in the > Ferguson/Schneier > paper on ESP was esoteric, I disagree on your conclusion that > no damage will be done. Let's assume that no attack is > occurring. What if > the system administrator enters the section of the key used > for decryption > incorrectly? Authentication will work correctly, but right > now, there is > no verification mechanism in place to assure that the plaintext is not > garbage, and once you pass garbage up to the upper layers, > the behaviour is > system specific and unknown -- it could range from catastrophic to no > damage at all. Authenticating the text after decryption > assures that the > correct plaintext is passed to the upper layers. If the > current order is > only maintained to ward off DoS, then I'd suggest that the > argument is > weak, since DoS can only be minimized, not eliminated. > > Steve > > > > > > > "Andrew Krywaniuk" > > McDonald'" , "'Sandy Harris'" > catel.com> > > > Sent by: cc: > > owner-ipsec@lists.ti Subject: > RE: Simplifying IKE > slabs.com > > > > > > 08/09/01 07:45 AM > > Please respond to > > andrew.krywaniuk > > > > > > > > > > > > > 4. modify ESP to ensure it authenticates all data used in > > the deciphering > > > of the payload > > > > > > This is the only recommendation in this paper based on a > > direct security > > > flaw, with a proposed attack to demonstrate it. There are > > others in the > > > Simpson paper. > > > > And if you use Choice 3a above, you get this for free - AH > > covers the whole > > ESP datagram, SPI/IV/etc. > > > If my memory serves me correctly, Ferguson/Schneier were actually > suggesting > that > > 1. encryption be applied AFTER authentication > > or, failing that, that > > 2. the encryption/decryption key be included in the data > which is hashed > > This is to prevent an esoteric attack they describe which is > infeasible and > wouldn't cause any damage anyway. That is not a compelling reason to > redesign ESP. > > Andrew > ------------------------------------------- > Upon closer inspection, I saw that the line > dividing black from white was in fact a shade > of grey. As I drew nearer still, the grey area > grew larger. And then I was enlightened. > > > > > > From owner-ipsec@lists.tislabs.com Sun Aug 12 03:14:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CAEKN08590; Sun, 12 Aug 2001 03:14:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00353 Sun, 12 Aug 2001 05:16:08 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Geoffrey Huang'" , , Subject: RE: (More) immediate changes to help interop problems? Date: Sun, 12 Aug 2001 10:11:13 +0100 Message-Id: <001b01c1230f$443f5f50$7a31788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I suspect most people are busy with the IETF and (soon) the bakeoff. Most of the discussion on the list seems to be coming from non-IETF participants. I know that I haven't been able to follow the conversation in real-time and I suspect most other people haven't either. Hopefully, the discussion will start up on the list next week when we get back, and we can always discuss this stuff amongst ourselves at the bakeoff. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: Geoffrey Huang [mailto:ghuang@cisco.com] > Sent: Thursday, August 09, 2001 11:46 AM > To: andrew.krywaniuk@alcatel.com; ipsec@lists.tislabs.com > Subject: RE: (More) immediate changes to help interop problems? > > > > > So I've seen many messages concerning long-term development > > > for the next > > > IKE, but what happened to discussion on fixing some > shortcomings that > > > immediately affect interoperability? Andrew K. mentioned a > > > few yesterday > > > during his presentation, but off the top of my head, I can > > > think of a few > > > ambiguities: > > > > > > - Rekeying/Ph. 1 Responder Lifetime > > > - Unreliable Delete/Notifies > > > - Optional Cert Request Payload > > > - Some way to detect dead peers/stale SAs > > > > > > I'm just thinking of issues in currently deployed scenarios... > > > > Didn't I mention all of the above in my presentation? (I > know it wasn't in > > great depth, but we didn't make great use of our alloted time.) > > You certainly did, as I mention above -- I'm just wondering why the > discussion about this hasn't continued... > > -g > > > Andrew > > ------------------------------------------- > > Upon closer inspection, I saw that the line > > dividing black from white was in fact a shade > > of grey. As I drew nearer still, the grey area > > grew larger. And then I was enlightened. > > > > > > From owner-ipsec@lists.tislabs.com Sun Aug 12 03:18:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CAIlN08786; Sun, 12 Aug 2001 03:18:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00339 Sun, 12 Aug 2001 05:15:59 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Scott Fanning'" , Subject: RE: (More) immediate changes to help interop problems? Date: Sat, 11 Aug 2001 22:52:34 +0100 Message-Id: <001301c1230f$350e5d60$7a31788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <005701c12008$11168400$4e8d21d9@sfanninglaptop> Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I agree. I also would like to see the commit bit gone (not many people > support it anyway, nor do it right). > > I think the fact we still have bakeoffs to test IKE interop, > tells us that > we need to simplify what we have. I think you are exaggerating. The fact that we still have bakeoffs shows that we are still *ADDING* features to IKE. I expect to be testing NAT traversal, ECDH, bigger DH groups, maybe revised hash if anyone else has implemented it. The concern over complexity is two things: a) People who say that IKE must contain HIDDEN flaws or implementations must have security holes. b) People who say that IKE is too hard to write by new implementers. I don't know of any 'old' implementation that still needs baking on basic IKE features. Are you saying yours does? :-) > At one IETF, I was sure I heard a call and a straw vote for > IKE reved to V2, > with the new hash, and additional changes. I would like to > fix those things we can fix now > , allowing current users to continue to use > IKE, while we > debate a new, and improved key exchange, You're free to improve your codebase with experimental features/anti-features whenever you want. I've already fixed the hash problem on our gateways. If you want to interoperate, you can use our vendor id. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott Fanning > Sent: Wednesday, August 08, 2001 1:46 PM > To: Geoffrey Huang; ipsec@lists.tislabs.com > Subject: Re: (More) immediate changes to help interop problems? > > > > My 2 cents > Scott > ----- Original Message ----- > From: "Geoffrey Huang" > To: > Sent: Wednesday, August 08, 2001 1:57 AM > Subject: (More) immediate changes to help interop problems? > > > > Hi there, > > > > So I've seen many messages concerning long-term development > for the next > > IKE, but what happened to discussion on fixing some > shortcomings that > > immediately affect interoperability? Andrew K. mentioned a > few yesterday > > during his presentation, but off the top of my head, I can > think of a few > > ambiguities: > > > > - Rekeying/Ph. 1 Responder Lifetime > > - Unreliable Delete/Notifies > > - Optional Cert Request Payload > > - Some way to detect dead peers/stale SAs > > > > I'm just thinking of issues in currently deployed scenarios... > > > > -g > > > > From owner-ipsec@lists.tislabs.com Sun Aug 12 03:18:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CAIqN08816; Sun, 12 Aug 2001 03:18:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00359 Sun, 12 Aug 2001 05:16:36 -0400 (EDT) Message-ID: <001101c12318$2b674520$09a1003e@bilbo> From: "Sara Bitan" To: References: Subject: Re: DRAFT: ipsec charter update Date: Sun, 12 Aug 2001 12:15:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Two issues: 1) The term "client protocols of IP" is not clear. IP is not a server, so other protocols are not clients. I think the term "protocols that run above IP" is more appropriate. 2) I think the following paragraph > The working group will also update IKE to reflect implementation > experience, new requirements, and protocol analysis of the existing > protocol. The requirements for IKE V2 will be revised and updated as > the first step in this process. is too open ended, and bound to cause problems in the future. I think (see another mail), that this work should be moved to a new WG, and that indeed there should be several protocols answering several requirements drafts. Sara. ----- Original Message ----- From: To: Sent: Thursday, August 09, 2001 3:10 PM Subject: DRAFT: ipsec charter update > > The IPSEC wg chairs met with Marcus Leech today, and after discussions > and consultation with him, we have developed the following draft update > to the IPSEC working group charter. > > Contained in this proposed update is a timeline for the IKE V2 work > which was discussed at the IPSEC meeting earlier week in London. We > welcome comments and suggestions on improving the revised working group > charter. We would like to submit this charter to the IESG for > consideration by the end of August, so we would appreciate receiving > comments within the next two weeks. > > Barbara Fraser > Theodore Ts'o > IPSEC wg chairs > > > IP Security Protocol (ipsec) > > Last Modified: 09-Aug-01 > > Chair(s): > Barbara Fraser > Theodore Ts'o > > Security Area Director(s): > Jeffrey Schiller > Marcus Leech > > Security Area Advisor: > Jeffrey Schiller > > Mailing Lists: > General Discussion:ipsec@lists.tislabs.com > to Subscribe: ipsec-request@lists.tislabs.com > Archive: ftp://ftp.tis.com/pub/lists/ipsec OR > ftp.ans.net/pub/archive/ipsec > > Description of Working Group: > ============================= > > Rapid advances in communication technology have accentuated the need for > security in the Internet. The IP Security Protocol Working Group > (IPSEC) will develop mechanisms to protect client protocols of IP. A > security protocol in the network layer will be developed to provide > cryptographic security services that will flexibly support combinations > of authentication, integrity, access control, and confidentiality. > > The IPSEC working group will restrict itself to the following short-term > work items to improve the existing key management protocol (IKE): > > 1) Changes to IKE to support NAT/Firewall traversal > > 2) Changes to IKE to support SCTP > > 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and > a fast AES mode suitable for use in hardware encryptors > > 4) IKE MIB documents > > 5) Sequence number extensions to ESP to support an expanded sequence > number space. > > 6) Clarification and standardization of rekeying procedures in IKE. > > The working group will also update IKE to reflect implementation > experience, new requirements, and protocol analysis of the existing > protocol. The requirements for IKE V2 will be revised and updated as > the first step in this process. > > Goals and Milestones: > ===================== > > Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and > requirements for IPsec and IKE for use with SCTP, to working > group last call. > > Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE > MIBs, and SCTP support for considerations as Draft Standards. > > Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE > re-keying completed. > > Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE > re-keying to working group last call. > > Dec 01 Internet-Draft on IKE v2 Requirements to working group last call > > Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted > to the working group. > > Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number > expansion, and IKE rekeying for consideration as Draft Standards. > > Apr 02 Discuss and select the IKE v2 design from candidate approaches. > > Sep 02 IKE v2 Internet-Drafts to working group last call > > Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as > Proposed Standards. > > > > From owner-ipsec@lists.tislabs.com Sun Aug 12 09:36:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CGahN24273; Sun, 12 Aug 2001 09:36:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00865 Sun, 12 Aug 2001 11:35:15 -0400 (EDT) Message-ID: <002a01c12345$a6f64ec0$2100a8c0@server> From: "Jerry Yao" To: Subject: Multicasting problem Date: Sun, 12 Aug 2001 23:43:15 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C12388.8E5034B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C12388.8E5034B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SXMgYW55Ym9keSB3b3JraW5nIGF0IE11bHRpY2FzdGluZyBwcm9ibGVtLiBJIGNhbid0IGZpbmQg YW55IFJGQyBvciBEcmFmdCBhYm91dCBpdD8NCg== ------=_NextPart_000_001F_01C12388.8E5034B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5JcyBhbnlib2R5IHdvcmtpbmcg YXQgTXVsdGljYXN0aW5nIHByb2JsZW0uIEkgY2FuJ3QgZmluZCBhbnkgDQpSRkMgb3IgRHJhZnQg YWJvdXQgaXQ/PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_001F_01C12388.8E5034B0-- From owner-ipsec@lists.tislabs.com Sun Aug 12 15:12:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CMCXN29970; Sun, 12 Aug 2001 15:12:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01299 Sun, 12 Aug 2001 17:06:16 -0400 (EDT) Message-Id: <200108122112.f7CLCAb00674@dharkins@lounge.orgatty.lounge.org> To: andrew.krywaniuk@alcatel.com Cc: "'Derrell Piper'" , sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-Reply-To: Your message of "Sun, 12 Aug 2001 10:04:52 BST." <001801c1230f$3ca480e0$7a31788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <671.997650729.1@lounge.org> Date: Sun, 12 Aug 2001 14:12:10 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No, the main purpose of quick mode was to be able to amortize the cost of authentication over many SAs. Different SAs can be established to protect different flows as specified by different selectors without having to reauthenticate every time. And SAs for a particular flow can expire and be reestablished, again, without having to reauthenticate. You may not like PFS but it has been a continued requirement in this working group. That is why the SKIP folks had to come up an optional PFS extention. (It is worthwhile to look back at how that Simple protocol became exceedingly complex-- components at IP, ICMP, and UDP, a PFS extension, an algorithm discovery extension, a certificate discovery extension-- in its attempt to satify the requirements from this working group). What is "normal" depends on perspective (as well as hardware acceleration I guess). The Evil Kirk thought it was perfectly normal for Spock to have a goatee. Dan. On Sun, 12 Aug 2001 10:04:52 BST you wrote > This is why I have never liked the PFS option. One of the main purposes of > quick mode is to thwart traffic analysis on ESP data without greatly slowing > down the protocol. That's why it's called "quick". > > The normal thing to do is to use quick mode w/o PFS and the ultra-paranoid > thing to do is to do more frequent phase 1 rekeys. I can't think of a > realistic threat model that PFS solves. (Michael Richardson did once point > one out to me in which an 'ethical law-enforcement agency' forces you to > reveal your keys, but they are ethically prevented from using those keys to > impersonate you.) > > Of all the security vulnerabilities I have seen in the design of security > protocols, a large percentage of them came about solely through the process > of optimization. If we truly want to have a simple and analyzable protocol, > we have to realize that simplicity does not come merely from reducing > options; it also comes from being conservative in our assumptions and from > clearly separating the protocol into independent stages. > > A lot of people who complain about the complexity of IKE have also been > tacking on optimizations as part of their solutions. Whenever we try to > optimize the protocol, we have to accept that this is a design tradeoff and > security flaws may result. > > Andrew > ------------------------------------------- > Upon closer inspection, I saw that the line > dividing black from white was in fact a shade > of grey. As I drew nearer still, the grey area > grew larger. And then I was enlightened. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derrell Piper > > Sent: Friday, August 10, 2001 2:17 AM > > To: sommerfeld@East.Sun.COM; Michael Thomas > > Cc: Ari Huttunen; Dan McDonald; Sandy Harris; ipsec@lists.tislabs.com > > Subject: Re: Simplifying IKE > > > > > > QM with PFS has never really been all that "quick". However, > > it seems a > > valuable attribute that the relatively long-lived Phase 1 IKE > > SA's allow > > for seamless Phase 2 rekeying (when done right). This would > > be much harder > > if there were just one single negotiation. > > > > Derrell > > > > --On Thursday, August 9, 2001 7:52 PM -0400 Bill Sommerfeld > > wrote: > > > > >> Ari Huttunen writes: > > >> > Thus my preference would be to have a four packet > > phase 1 (base mode) > > >> > and a four packet quick mode. > > >> > > >> Gad. Doesn't anybody care about link up times??? > > > > > > Smooshing phase 1 and phase 2 together begins to look very > > attractive > > > when quick mode isn't very (quick). > > > > > > - Bill > > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Sun Aug 12 15:12:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CMCYN29973; Sun, 12 Aug 2001 15:12:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01265 Sun, 12 Aug 2001 17:03:26 -0400 (EDT) Date: Fri, 10 Aug 2001 06:29:11 -0400 From: Theodore Tso To: Alex Alten Cc: tytso@mit.edu, ipsec@lists.tislabs.com Subject: Re: DRAFT: ipsec charter update Message-ID: <20010810062911.C9293@thunk.org> References: <3.0.3.32.20010809223922.00dbaea0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3.0.3.32.20010809223922.00dbaea0@mail>; from Alten@Home.Com on Thu, Aug 09, 2001 at 10:39:22PM -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Aug 09, 2001 at 10:39:22PM -0700, Alex Alten wrote: > Barbara & Theodore, > > Is there a requirements doc for IKE V2? >From the proposed charter (which you included in your e-mail message, so I assume that meant you read it carefully before you responded :-)... >The working group will also update IKE to reflect implementation >experience, new requirements, and protocol analysis of the existing >protocol. The requirements for IKE V2 will be revised and updated as >the first step in this process. > >Dec 01 Internet-Draft on IKE v2 Requirements to working group last call > Will there be a security analysis before Last Call by a reputable group of > cryptographers, etc? I would think this would be very likely, yes. I will note that there is a group of reputable cryptographers who regularly do participate in the ipsec wg, so hopefully this review process will be ongoing during the whole IKE v2 process. - Ted From owner-ipsec@lists.tislabs.com Sun Aug 12 15:12:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7CMCYN29972; Sun, 12 Aug 2001 15:12:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01272 Sun, 12 Aug 2001 17:03:36 -0400 (EDT) Date: Fri, 10 Aug 2001 06:24:53 -0400 From: Theodore Tso To: "Horn, Mike" Cc: "'tytso@mit.edu'" , ipsec@lists.tislabs.com Subject: Re: DRAFT: ipsec charter update Message-ID: <20010810062453.B9293@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: ; from mhorn@virtela.net on Thu, Aug 09, 2001 at 10:31:16PM -0600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Aug 09, 2001 at 10:31:16PM -0600, Horn, Mike wrote: > I think this is definitely a step in the right direction, but it seems in > direct conflict with the position statement that was just sent out by Marcus > Leech. Does this have approval from the IESG and IAB? Also, how does this > fit in with the work going on to simplify IKE? Are things like removing AH, > aggresive mode, etc. still open for discussion? Again, it's great to see > the working group moving forward to provide standardized solutions for known > problems. There's a certain amount of misunderstanding about the the position statement which Marcus, Jeff, and Steve put together. Marcus and Steve (Jeff couldn't make it to London) clarified this at the IPSEC wg meeting on Monday. First of all, IKE is *not* broken, and we're not abandoning development on IKE (as Network World reported in screaming front-page headlines). Secondly, the note was only giving a rationale for the same moratorium has been place for the last year. So things like the NAT/FW traversal, SCTP, etc. were never under the moratorium in the first place. Barbara and I did consult with Marcus before we drafted the charter, and the only one thing on the proposed charter which might be considered new with respect to the moratorium was the rekeying issue, and presumably this is the one thing which might be in danger of being turned down by the IESG/IAB when they consider our proposed new charter. The rekeying clarification was added because there was a number of people who strongly asked for this at the IPSEC meeting. It's not really *changing* IKE, as much as we are specifying a behaviour where the current standards are completely silent. Personally, I think the odds are 50-50 that the question of getting IESG/IAB permission is moot, since we tried to standardize rekeying about a year ago, and the problem was that roughly 50% of the deployed implementations were doing it one way, and the other 50% were doing it the other way, and no one seemed willing to change their implementations. So I'm not sanguine about why we will be successful now when we weren't successful a year ago, but if people want to give it a try, I certainly would be very pleased to be proven wrong. (And as I understand things the current non-standardization doesn't mean that things are *completely* broken, just that interoperability with respect to rekeying is just very, very hard.) - Ted From owner-ipsec@lists.tislabs.com Sun Aug 12 19:24:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7D2O3N04634; Sun, 12 Aug 2001 19:24:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01767 Sun, 12 Aug 2001 21:27:02 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5A2@CORPMX14> To: tytso@mit.edu, ipsec@lists.tislabs.com Subject: RE: DRAFT: ipsec charter update Date: Sun, 12 Aug 2001 21:28:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry for the delayed response, but two comments on the following: > The IPSEC working group will restrict itself to the following short-term > work items to improve the existing key management protocol (IKE): > > 1) Changes to IKE to support NAT/Firewall traversal > > 2) Changes to IKE to support SCTP > > 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and > a fast AES mode suitable for use in hardware encryptors - The third item is not about IKE, hence the WG won't be restricted to IKE (as pointed out by JI and Ghislane). - Please broaden 3) to allow other fast things that may emerge from the upcoming NIST modes workshop (e.g., over in the IP Storage WG, I have a cheering section for UMAC, or something similar). I presume "fast AES mode ..." translates to "counter mode, or something equally hardware-friendly", right? Schedule looks good to me, this looks like any major issues with the drafts in item 3) would be expected to be discussed in Salt Lake City and closed there or shortly thereafter. Thanks, --David (IP Storage [ips] WG co-chair) --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: tytso@mit.edu [mailto:tytso@mit.edu] > Sent: Thursday, August 09, 2001 9:11 AM > To: ipsec@lists.tislabs.com > Subject: DRAFT: ipsec charter update > > > > The IPSEC wg chairs met with Marcus Leech today, and after discussions > and consultation with him, we have developed the following > draft update > to the IPSEC working group charter. > > Contained in this proposed update is a timeline for the IKE V2 work > which was discussed at the IPSEC meeting earlier week in London. We > welcome comments and suggestions on improving the revised > working group > charter. We would like to submit this charter to the IESG for > consideration by the end of August, so we would appreciate receiving > comments within the next two weeks. > > Barbara Fraser > Theodore Ts'o > IPSEC wg chairs > > > IP Security Protocol (ipsec) > > Last Modified: 09-Aug-01 > > Chair(s): > Barbara Fraser > Theodore Ts'o > > Security Area Director(s): > Jeffrey Schiller > Marcus Leech > > Security Area Advisor: > Jeffrey Schiller > > Mailing Lists: > General Discussion:ipsec@lists.tislabs.com > to Subscribe: ipsec-request@lists.tislabs.com > Archive: ftp://ftp.tis.com/pub/lists/ipsec OR > ftp.ans.net/pub/archive/ipsec > > Description of Working Group: > ============================= > > Rapid advances in communication technology have accentuated > the need for > security in the Internet. The IP Security Protocol Working Group > (IPSEC) will develop mechanisms to protect client protocols of IP. A > security protocol in the network layer will be developed to provide > cryptographic security services that will flexibly support > combinations > of authentication, integrity, access control, and confidentiality. > > The IPSEC working group will restrict itself to the following > short-term > work items to improve the existing key management protocol (IKE): > > 1) Changes to IKE to support NAT/Firewall traversal > > 2) Changes to IKE to support SCTP > > 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and > a fast AES mode suitable for use in hardware encryptors > > 4) IKE MIB documents > > 5) Sequence number extensions to ESP to support an expanded sequence > number space. > > 6) Clarification and standardization of rekeying procedures in IKE. > > The working group will also update IKE to reflect implementation > experience, new requirements, and protocol analysis of the existing > protocol. The requirements for IKE V2 will be revised and updated as > the first step in this process. > > Goals and Milestones: > ===================== > > Aug 01 Internet Drafts on NAT and Firewall traversal, > IKE MIBs, and > requirements for IPsec and IKE for use with SCTP, to working > group last call. > > Sep 01 Submit revised Internet-Drafts of NAT and > Firewall traversal, IKE > MIBs, and SCTP support for considerations as Draft Standards. > > Oct 01 Internet-Drafts on sequence number expansion in > IKE, and IKE > re-keying completed. > > Dec 01 Internet-Drafts on AES/SHA-2, sequence number > expansion, and IKE > re-keying to working group last call. > > Dec 01 Internet-Draft on IKE v2 Requirements to > working group last call > > Dec 01 Internet-Drafts describing candidate IKE v2 > approaches submitted > to the working group. > > Feb 01 Submit revised Internet-Drafts on AES/SHA-2, > sequence number > expansion, and IKE rekeying for consideration as Draft > Standards. > > Apr 02 Discuss and select the IKE v2 design from > candidate approaches. > > Sep 02 IKE v2 Internet-Drafts to working group last call > > Dec 02 Submit IKE v2 Internet-Drafts to the IESG for > consideration as > Proposed Standards. > > > > From owner-ipsec@lists.tislabs.com Mon Aug 13 05:46:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DCkoN18662; Mon, 13 Aug 2001 05:46:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA02691 Mon, 13 Aug 2001 07:47:11 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Dan Harkins'" Cc: Subject: RE: Simplifying IKE Date: Mon, 13 Aug 2001 12:44:50 +0100 Message-Id: <000701c123ed$7b19e340$b70be982@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <200108122112.f7CLCAb00674@dharkins@lounge.orgatty.lounge.org> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > This is why I have never liked the PFS option. One of the > main purposes of > > quick mode is to thwart traffic analysis on ESP data > without greatly slowing > > down the protocol. That's why it's called "quick". > No, the main purpose of quick mode was to be able to amortize the > cost of authentication over many SAs. Different SAs can be established > to protect different flows as specified by different selectors without > having to reauthenticate every time. And SAs for a particular flow can > expire and be reestablished, again, without having to reauthenticate. And what is the purpose of having different SAs to protect different flows? (besides thwarting traffic analysis) "Quick" mode is hardly quick if you have to repeat the Diffie-Hellman exchange each time. Why can't quick mode be used to amortize the cost of authentication *AND* forward secrecy over many SAs? > You may not like PFS but it has been a continued requirement in this > working group. That is why the SKIP folks had to come up an optional > PFS extention. Firstly, the problem with SKIP was that it didn't provide any kind of PFS at all. If you cracked the RSA private key you could get all session keys negotiated with that private key. I wasn't following this group that closely back when SKIP was being proposed, but that's my understanding of the problem. Am I wrong? PFS is not optional in IKE because the DH group is not optional in phase 1. All that is optional is whether you do a single level of PFS or two levels of PFS. In fact, if you wanted to be ultra-paranoid we could add a 3rd level of PFS where you refresh the keying material on every packet. How 'bout that? Designing the protocol so that cracking (or, more likely, stealing) a long-term RSA key doesn't compromise all past traffic is a worthwhile feature. Designing the protocol so that cracking a short-lived IKE phase 1 key doesn't reveal the (even more short-lived) phase 2 keys is a less useful and more esoteric feature. It is a shame that this bastard form of forward secrecy came to be known as *the* PFS mode of IKE because it gives people the mistaken impression that IKE w/o QM PFS doesn't have any PFS at all. I suggest that you take some time (as I have done) to consider for each case of {no PFS, PFS in phase 1, PFS in both phase 1 and phase 2} what is the work factor for {the hosts to rekey phase 1, the hosts to rekey phase 2, the attacker to brute force a key} and how much damage is done if {an RSA private key, phase 1 DH key, phase 2 DH key, etc.} is cracked. I have come to the conclusion, as have several others, that QM PFS is not useful in the vast majority of situations as it doesn't make good use of the engineering tradeoffs. When it is "required", the same threats can be addressed by other means such as more frequent phase 1 rekeying or by establishing the phase 1 with a bigger DH modulus. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Mon Aug 13 06:04:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DD4UN19157; Mon, 13 Aug 2001 06:04:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02789 Mon, 13 Aug 2001 08:29:13 -0400 (EDT) Date: Mon, 13 Aug 2001 00:12:15 +0300 (EET DST) From: Markus Stenberg X-X-Sender: To: Sandy Harris cc: "ipsec@lists.tislabs.com" Subject: Re: Is base mode dead? In-Reply-To: <3B75AD92.E10C9445@storm.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 11 Aug 2001, Sandy Harris wrote: > With all the discussion of simplifying IKE, main mode vs. aggressive, > the commit bit, ... I thought it was time I had a look at 'base mode'. > > I cannot find either an draft or an RFC. Is it dead? Draft's from about year ago (I think it expired last christmas or so). It's basically dead, although I suppose it's a shame.. It combines limited DoS protection of MM with identity exposure of aggressive mode (and just 4 messages). I think that if we really go for only one exchange, aggressive mode is not even an option; however, question is, do we want identity hiding or not? It costs one roundtrip. In my ideal world there'd be 2 message QM which could be glued on the base mode so you could have SA's up in 4 messages and still retain IKE SA for fast further SA's. But, YMMV. -Markus From owner-ipsec@lists.tislabs.com Mon Aug 13 06:09:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DD9eN19266; Mon, 13 Aug 2001 06:09:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02779 Mon, 13 Aug 2001 08:28:13 -0400 (EDT) Date: Sun, 12 Aug 2001 11:44:35 -0700 From: Derrell Piper To: ipsec@lists.tislabs.com Subject: RE: Simplifying IKE Message-ID: <66296.997616674@el-air-5.electric-loft.org> In-Reply-To: <001801c1230f$3ca480e0$7a31788a@andrewk3.ca.newbridge.com> References: <001801c1230f$3ca480e0$7a31788a@andrewk3.ca.newbridge.com> X-Mailer: Mulberry/2.1.0b3 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, Normal, of course, is in the eye of the beholder. Nokia has hardware assist for its DH, so the QM PFS in most of our systems (our low end models don't have the chip) is essentially free. Moving forward, I think all vendors will be relying on hardware assist, so this situation only gets better over time. That is, if you think there is no value to Phase 2 PFS, which I don't happen to agree with you on. I would be more inclined to make QM PFS mandatory, if that's viewed as simplifying. However, I think that the optional nature of QM PFS is one of the better defined parts of the IKE protocol and removing this wouldn't buy us much. Derrell --On Sunday, August 12, 2001 10:04 AM +0100 Andrew Krywaniuk wrote: > The normal thing to do is to use quick mode w/o PFS and the ultra-paranoid > thing to do is to do more frequent phase 1 rekeys. I can't think of a > realistic threat model that PFS solves. (Michael Richardson did once point > one out to me in which an 'ethical law-enforcement agency' forces you to > reveal your keys, but they are ethically prevented from using those keys > to impersonate you.) From owner-ipsec@lists.tislabs.com Mon Aug 13 06:13:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DDDjN19512; Mon, 13 Aug 2001 06:13:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02780 Mon, 13 Aug 2001 08:28:14 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Fri, 10 Aug 2001 19:13:05 -0600 From: "Hilarie Orman" To: Subject: Re: DRAFT: ipsec charter update Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id VAA28228 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Comments on the charter: The opening sentence has been true for 30 years and will always be true. All communication technology requires security. IPsec protects the payloads of IP datagrams and enforces policy for client protocols; the notion of "protecting" a protocol is imprecise. Remove any trace of the misconception that confidentiality without integrity is a possible combination of this flexible system. Is "protocol analysis of the existing protocol" the same as "analysis of the existing protocol"? Include elliptic curve methods. Hilarie tytso@mit.edu wrote: > The IPSEC wg chairs met with Marcus Leech today, and after discussions and consultation with him, we have developed the following draft update to the IPSEC working group charter. Contained in this proposed update is a timeline for the IKE V2 work which was discussed at the IPSEC meeting earlier week in London. We welcome comments and suggestions on improving the revised working group charter. We would like to submit this charter to the IESG for consideration by the end of August, so we would appreciate receiving comments within the next two weeks. Barbara Fraser Theodore Ts'o IPSEC wg chairs IP Security Protocol (ipsec) Last Modified: 09-Aug-01 Chair(s): Barbara Fraser Theodore Ts'o Security Area Director(s): Jeffrey Schiller Marcus Leech Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:ipsec@lists.tislabs.com to Subscribe: ipsec-request@lists.tislabs.com Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec Description of Working Group: ============================= Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The IPSEC working group will restrict itself to the following short-term work items to improve the existing key management protocol (IKE): 1) Changes to IKE to support NAT/Firewall traversal 2) Changes to IKE to support SCTP 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and a fast AES mode suitable for use in hardware encryptors 4) IKE MIB documents 5) Sequence number extensions to ESP to support an expanded sequence number space. 6) Clarification and standardization of rekeying procedures in IKE. The working group will also update IKE to reflect implementation experience, new requirements, and protocol analysis of the existing protocol. The requirements for IKE V2 will be revised and updated as the first step in this process. Goals and Milestones: ===================== Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and requirements for IPsec and IKE for use with SCTP, to working group last call. Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE MIBs, and SCTP support for considerations as Draft Standards. Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE re-keying completed. Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE re-keying to working group last call. Dec 01 Internet-Draft on IKE v2 Requirements to working group last call Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted to the working group. Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE rekeying for consideration as Draft Standards. Apr 02 Discuss and select the IKE v2 design from candidate approaches. Sep 02 IKE v2 Internet-Drafts to working group last call Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as Proposed Standards. From owner-ipsec@lists.tislabs.com Mon Aug 13 06:40:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DDesN20239; Mon, 13 Aug 2001 06:40:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03148 Mon, 13 Aug 2001 08:53:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message Subject: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of i-cookie=0 Date: Mon, 13 Aug 2001 06:00:29 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1013F83FF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of i-cookie=0 thread-index: AcEMMgtP9EnjItSDS1GBLrzefl04PwXvaqRQ From: "William Dixon" To: Cc: "Brian Swander" X-OriginalArrivalTime: 13 Aug 2001 13:00:29.0946 (UTC) FILETIME=[EDF86DA0:01C123F7] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is to post my discussion with some of the authors last week and echo my microphone comment during the WG meeting. I haven't had a chance to discuss it with Ari, so Ari and others, comments appreciated. This issue was raised initially by Steve Kent and others during the Minneapolis IETF, lamenting the use of 0x00 8 bytes for every ESP data packet. It comes up again as multiple IPsec keying protocols want to install and execute simultaneously in the same operating system, using a common IPsec UDP-ESP encapsulation API, without paying the penalty of 0x00 8bytes for every UDP-ESP data packet. I'd like to add text to this draft to explain the following, or to make the draft-ipsec-udp-encaps ISAKMP or 2409 IKE-specific: The UDP ESP encapsulation requires 8bytes of 0x00 only when the UDP encapsulation occurs over port 500. The 8 bytes of zero in this case is required to distinguish data (ESP) from control (ISAKMP, IKE, initiator cookie) because it was the only way to accommodate existing IKE implementations that use a 64bit non-zero initiator cookie value, which in particular may have the upper most bits non-zero For non-ISAKMP keying protocols, or for non-IKE at least, the UDP port number for ESP might not be 500. For other and future IPsec keying protocols, the UDP encapsulation of ESP should be more efficient that what the current draft specifies. We have the opportunity to be more efficient on the data encapsulation: IP-UDP-ESP - no leading 0x00 for the data channel If the keying protocol wishes to use UDP-ESP, and multiplex that encapsulation on it's own port, then the keying protocol MUST provide at least a 4byte 0x00 flag which will share the same position of the UDP-ESP SPI. Thus a non-zero SPI means data. A zero SPI means control. This is a bit of a problem for future non-IKE, but ISAKMP-based keying protocols, where the header is always first and thus the initiator cookie is always in the position of the SPI. It would be nice to constrain future ISAKMP implementation initiator cookie values, MUST have upper 4 bytes=0x00. It's not sufficient to put such a comment in the UDP-ESP encapsulation draft because once the protocol uses a non-zero upper 4bytes, they are stuck with backwards compat like we are with IKE when they want to add UDP-ESP. Thus the initiator cookie is always a 64bit value, with upper 32bits =0x00, lower 32bits = random, != 0x00. We lose the full 64bit non-zero value. Does anyone see a problem ? Tero noted that this data/control flag value doesn't even have to be 0x00 - just whatever the keying protocol specifies as a flag. But then it would impact SPI selection, as it could never be something the keying protocol was using as a flag. I'd think for simplicity sake, keying protocols should always make their data/control flag=0x00, since SPIs are/should never be zero. Wm From owner-ipsec@lists.tislabs.com Mon Aug 13 09:29:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DGTkN00762; Mon, 13 Aug 2001 09:29:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03479 Mon, 13 Aug 2001 11:30:46 -0400 (EDT) Message-ID: <20010813153559.65488.qmail@web13906.mail.yahoo.com> Date: Mon, 13 Aug 2001 08:35:59 -0700 (PDT) From: Cisco Chic Subject: IPSec Latency To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, I was wondering if anyone has any information or sites which talk about how to tweak (if this can be done) IPSec tunnls (via keepalives) from a dial up client to a VPN5008? We have a latency of around 800 milliseconds on a network and we are trying to determine what the maximum delay can be in the network to keep the tunnel up via keepalives. How long can the delay be for the keepalives and who sends the keepalives or are the keepalives sent in both directions via remote dial up access. (we are using static routes) I know that a keepalive protocol is used by L2TP in order to allow it to distinguish between a tunnel outage and prolonged periods of tunnel inactivity. We are trying to find out if this can be done for IPSec. We have a open case with cisco tac currently to get more details and have been looking at third party web sites and RFCs. Can't find anything about latency but have found performance issues concerning bw, memory etc. Any information or sites you can direct me to would be great. Thanks!! __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-ipsec@lists.tislabs.com Mon Aug 13 11:07:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DI7rN03405; Mon, 13 Aug 2001 11:07:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03824 Mon, 13 Aug 2001 13:19:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20010813100629.03ce38e8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Aug 2001 10:06:58 -0700 To: "Jerry Yao" From: Mark Baugher Subject: Re: Multicasting problem Cc: In-Reply-To: <002a01c12345$a6f64ec0$2100a8c0@server> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_59234154==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_59234154==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Yes, there's the msec working group in the security area of the IETF. Mark At 11:43 PM 8/12/2001 +0800, Jerry Yao wrote: >Is anybody working at Multicasting problem. I can't find any RFC or Draft >about it? --=====================_59234154==_.ALT Content-Type: text/html; charset="us-ascii" Yes, there's the msec working group in the security area of the IETF.

Mark
At 11:43 PM 8/12/2001 +0800, Jerry Yao wrote:
Is anybody working at Multicasting problem. I can't find any RFC or Draft about it?
--=====================_59234154==_.ALT-- From owner-ipsec@lists.tislabs.com Mon Aug 13 11:08:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DI7xN03419; Mon, 13 Aug 2001 11:07:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03816 Mon, 13 Aug 2001 13:17:18 -0400 (EDT) To: ipsec@lists.tislabs.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: SHA2 in AH/ESP From: Jun-ichiro itojun Hagino Date: Tue, 14 Aug 2001 02:23:46 +0900 Message-Id: <20010813172347.E40307BA@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sorry if it is a well-known topic. draft-ietf-ipsec-ciph-aes-cbc-01.txt refers the following document on the use of SHA-2 (SHA-256/384/512) within AH/ESP/IKE, however, I can't seem to find the document. does anyone have the copy somewhere? what is the name of the i-d? how many bits should we attach to the AH/ESP crypto checksum field? is it acceptable to truncate to align border like 96bit, like we do for SHA1? itojun > [SHA2-2] Frankel, S. and S. Kelly, "The Use of SHA-256, SHA-384, > and SHA-512 within ESP, AH and IKE," Work in progress. From owner-ipsec@lists.tislabs.com Mon Aug 13 11:09:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DI9kN03477; Mon, 13 Aug 2001 11:09:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03755 Mon, 13 Aug 2001 13:02:01 -0400 (EDT) Date: Mon, 13 Aug 2001 13:08:40 -0400 (EDT) From: Henry Spencer To: William Dixon cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0 In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1013F83FF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 13 Aug 2001, William Dixon wrote: > If the keying protocol wishes to use UDP-ESP, and multiplex that > encapsulation on it's own port, then the keying protocol MUST provide at > least a 4byte 0x00 flag which will share the same position of the > UDP-ESP SPI. Thus a non-zero SPI means data. A zero SPI means control. Before attempting to solve this problem, it seems to me that one should first ask whether it is worth solving. Do we need yet another re-invention of the Next Protocol field? That's what this is. We have too many of them already. People often have to add new ports to firewall configurations. Avoiding that seems a feeble justification for all this hassle. Keying protocols and data flow should not share ports, any more than Telnet and FTP do. If it is utterly necessary for UDP-ESP and IKE to share a port -- which I would argue against -- then that should be deemed a special-case exception for historical reasons, and we should avoid promulgating general design principles which encourage repeating this mistake. Indeed, we should explicitly and loudly recommend *against* repeating this mistake. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Aug 13 11:16:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DIGBN03644; Mon, 13 Aug 2001 11:16:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03848 Mon, 13 Aug 2001 13:30:27 -0400 (EDT) To: Henry Spencer Cc: William Dixon , ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0 References: From: Derek Atkins Date: 13 Aug 2001 13:37:01 -0400 In-Reply-To: Henry Spencer's message of "Mon, 13 Aug 2001 13:08:40 -0400 (EDT)" Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For NAT traversal, I think it is eminently ideal for the keying and data streams to share a port.. Otherwise you need twice as many keepalives to keep the NAT mapping happy. Speaking as the chair of KINK, I'd like to make sure that KINK does a similar transposition. I can certainly see carrying ESP within KINK-like UDP messages on the KINK port. -derek Henry Spencer writes: > If it is utterly necessary for UDP-ESP and IKE to share a port -- which I > would argue against -- then that should be deemed a special-case exception > for historical reasons, and we should avoid promulgating general design > principles which encourage repeating this mistake. Indeed, we should > explicitly and loudly recommend *against* repeating this mistake. > > Henry Spencer > henry@spsystems.net > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Aug 13 12:38:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DJccN05441; Mon, 13 Aug 2001 12:38:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04397 Mon, 13 Aug 2001 14:51:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20010813145450.00ac1520@email.nist.gov> X-Sender: sfrankel@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Aug 2001 14:58:22 -0400 To: Jun-ichiro itojun Hagino From: Sheila Frankel Subject: Re: SHA2 in AH/ESP Cc: ipsec@lists.tislabs.com In-Reply-To: <20010813172347.E40307BA@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The document is in the works, but has not yet been published as an Internet Draft. SHA-256 would most likely be truncated to 128 bits. Sheila Frankel At 01:23 PM 8/13/01, you wrote: > sorry if it is a well-known topic. > > draft-ietf-ipsec-ciph-aes-cbc-01.txt refers the following document on > the use of SHA-2 (SHA-256/384/512) within AH/ESP/IKE, however, I > can't > seem to find the document. does anyone have the copy somewhere? > what is the name of the i-d? how many bits should we attach to the > AH/ESP crypto checksum field? is it acceptable to truncate to > align border like 96bit, like we do for SHA1? > >itojun > > > > [SHA2-2] Frankel, S. and S. Kelly, "The Use of SHA-256, SHA-384, > > and SHA-512 within ESP, AH and IKE," Work in progress. From owner-ipsec@lists.tislabs.com Mon Aug 13 13:03:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DK3CN06106; Mon, 13 Aug 2001 13:03:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04568 Mon, 13 Aug 2001 15:23:13 -0400 (EDT) Message-ID: <3B782AC3.FFE8D633@storm.ca> Date: Mon, 13 Aug 2001 15:30:11 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE References: <000701c123ed$7b19e340$b70be982@andrewk3.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > > No, the main purpose of quick mode was to be able to amortize the > > cost of authentication over many SAs. Different SAs can be established > > to protect different flows ... > > And what is the purpose of having different SAs to protect different flows? > (besides thwarting traffic analysis) Far from thwarting traffic analysis, I think that makes it easier. Having multiple SAs between two gateways gives an analyst more data. He or she can look at the data in the header that classifies packets by SA. I discuss this in the FreeS/WAN documentation: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/ipsec.html#traffic.resist Commemnt and criticism solicited. What I suggest there is that to resist (not thwart!) traffic analysis, you want at least: only one tunnel between a pair of hosts all IPSEC data goes down that tunnel any other traffic between the hosts goes down it too (encrypt as much as you possibly can, not just what you think you need to) This still won't stop it completely. For that you'd need to insert dummy traffic to confuse the analyst, and probably take other measures I haven't thought of. From owner-ipsec@lists.tislabs.com Mon Aug 13 15:53:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DMrrN11102; Mon, 13 Aug 2001 15:53:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04940 Mon, 13 Aug 2001 17:47:52 -0400 (EDT) Message-ID: <3B784CA6.2DD8E1FC@F-Secure.com> Date: Tue, 14 Aug 2001 00:54:46 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer CC: William Dixon , ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Mon, 13 Aug 2001, William Dixon wrote: > > If the keying protocol wishes to use UDP-ESP, and multiplex that > > encapsulation on it's own port, then the keying protocol MUST provide at > > least a 4byte 0x00 flag which will share the same position of the > > UDP-ESP SPI. Thus a non-zero SPI means data. A zero SPI means control. > > Before attempting to solve this problem, it seems to me that one should > first ask whether it is worth solving. This is good advice and should be applied to these questions at least: a) Do we really want to make this draft a generic draft, usable by several key management protocols? Or do we want to keep it simple, understandable and IKE-specific? If some other key management protocol needs it, why should this draft / this WG solve the problem? (In particular, KINK would probably be better off writing their own simple document on the matter.) b) What is the actual NEED to save bits on the wire? What are the things we can tinker with to save them? I.e. - We can have separate channels for IKE and ESPUDP, which saves 8 bytes per ESPUDP packet. Then we need NAT-keepalives for both channels. Do these extra keepalives cause more traffic than is saved? I'm not so sure. - If we can change IKE header field order and steal one bit of ESP SPI field, we can also save the 8 bytes per packet, but this is not very practical. (ISAKMP flags field first, cookies starting at byte 5. This might be usable for KINK?) It's also good to remember that UDP header also takes 8 bytes. And 8 bytes of UDP header followed by 8 bytes of zero should compress pretty well at some header compression algorithm. And the checksum is also zero. So, I would prefer not to change this draft if it's not really necessary. There was quite a lot of discussion about these things among the authors, but if this WG wants otherwise, I can of course modify the draft. Yes, I agree completely with the AH-removal choice. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Mon Aug 13 19:27:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E2R7N15944; Mon, 13 Aug 2001 19:27:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05711 Mon, 13 Aug 2001 21:39:57 -0400 (EDT) Message-ID: <20010814014708.45906.qmail@web13808.mail.yahoo.com> Date: Mon, 13 Aug 2001 18:47:08 -0700 (PDT) From: Pyda Srisuresh Subject: Re: DRAFT: ipsec charter update To: tytso@mit.edu, ipsec@lists.tislabs.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would like to see the following changes to IKE included in the charter: * Ability to specify the IPsec SPD description in a flexible manner in Quick mode. Currently, the ID payload is overloaded to carry the SPD semantics in a rather inflexible manner in Quick mode. As such, this has become a deterrent to successful IKE deployment in many instances. regards, suresh --- tytso@mit.edu wrote: > > The IPSEC wg chairs met with Marcus Leech today, and after discussions > and consultation with him, we have developed the following draft update > to the IPSEC working group charter. > > Contained in this proposed update is a timeline for the IKE V2 work > which was discussed at the IPSEC meeting earlier week in London. We > welcome comments and suggestions on improving the revised working group > charter. We would like to submit this charter to the IESG for > consideration by the end of August, so we would appreciate receiving > comments within the next two weeks. > > Barbara Fraser > Theodore Ts'o > IPSEC wg chairs > > > IP Security Protocol (ipsec) > > Last Modified: 09-Aug-01 > > Chair(s): > Barbara Fraser > Theodore Ts'o > > Security Area Director(s): > Jeffrey Schiller > Marcus Leech > > Security Area Advisor: > Jeffrey Schiller > > Mailing Lists: > General Discussion:ipsec@lists.tislabs.com > to Subscribe: ipsec-request@lists.tislabs.com > Archive: ftp://ftp.tis.com/pub/lists/ipsec OR > ftp.ans.net/pub/archive/ipsec > > Description of Working Group: > ============================= > > Rapid advances in communication technology have accentuated the need for > security in the Internet. The IP Security Protocol Working Group > (IPSEC) will develop mechanisms to protect client protocols of IP. A > security protocol in the network layer will be developed to provide > cryptographic security services that will flexibly support combinations > of authentication, integrity, access control, and confidentiality. > > The IPSEC working group will restrict itself to the following short-term > work items to improve the existing key management protocol (IKE): > > 1) Changes to IKE to support NAT/Firewall traversal > > 2) Changes to IKE to support SCTP > > 3) New cipher documents to support AES-CBC, AES-MAC, SHA-2, and > a fast AES mode suitable for use in hardware encryptors > > 4) IKE MIB documents > > 5) Sequence number extensions to ESP to support an expanded sequence > number space. > > 6) Clarification and standardization of rekeying procedures in IKE. > > The working group will also update IKE to reflect implementation > experience, new requirements, and protocol analysis of the existing > protocol. The requirements for IKE V2 will be revised and updated as > the first step in this process. > > Goals and Milestones: > ===================== > > Aug 01 Internet Drafts on NAT and Firewall traversal, IKE MIBs, and > requirements for IPsec and IKE for use with SCTP, to working > group last call. > > Sep 01 Submit revised Internet-Drafts of NAT and Firewall traversal, IKE > MIBs, and SCTP support for considerations as Draft Standards. > > Oct 01 Internet-Drafts on sequence number expansion in IKE, and IKE > re-keying completed. > > Dec 01 Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE > re-keying to working group last call. > > Dec 01 Internet-Draft on IKE v2 Requirements to working group last call > > Dec 01 Internet-Drafts describing candidate IKE v2 approaches submitted > to the working group. > > Feb 01 Submit revised Internet-Drafts on AES/SHA-2, sequence number > expansion, and IKE rekeying for consideration as Draft Standards. > > Apr 02 Discuss and select the IKE v2 design from candidate approaches. > > Sep 02 IKE v2 Internet-Drafts to working group last call > > Dec 02 Submit IKE v2 Internet-Drafts to the IESG for consideration as > Proposed Standards. > > > > ===== __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-ipsec@lists.tislabs.com Tue Aug 14 01:44:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E8ifN25076; Tue, 14 Aug 2001 01:44:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA06349 Tue, 14 Aug 2001 03:43:44 -0400 (EDT) Message-ID: <003901c1249d$86b1a8e0$0300000a@bilbo> From: "Sara Bitan" To: Subject: Traffic handling and key management "divide and coquer" Date: Tue, 14 Aug 2001 10:45:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think that we are at a crucial point where we can make a change that will turn our work to more focused and efficient, and hopefully fruitful. I suggest we use a "divide and conquer" strategic. We should first of all separate IPsec transforms traffic handling (i.e. ESP and AH) and key management work to different WGs (if I understand right, this was raised by JI in the SAAG meeting). This process is already happening as we speak - MSEC and KINK are working on key management protocols that create IPsec SAs, with different requirements. ESP and AH will still be used for traffic handling. If we will do the separation, we will soon be able to tell the industry that the work on the IPsec transforms is done, which I think will be a great advantage. I think we should also allow for several key management protocols, preferably with one framework. This is the only way we will be able to cater for the requirements of "DSL geeks" as well as "billion mobile users" (quoting Jari's words). There are several actions that we need to take for this to happen: 1) Allow working groups other than IPsec to work on key management protocols, this way we could shut down the IPsec WG and keep on working on new key management protocols. As I said this is already happening. 2) Limit IPsec wg to only on the following IKE modifications : NAT traversal, SCTP support and re-keying. The new IKE version should be a minor version including only minor fixes (as outlined in the new suggested charter). 3) Re-assure ourselves that the interface between transforms and key management is clearly defined, and general enough to allow for the addition of new key management protocols, without having to change the transforms. 4) Have a framework protocol for key management - I think it should be based on ISAKMP. There is no need to re-invent transforms and proposals syntax for each new key management protocol. 5) Have different requirements for different key management protocols. With one common requirement - they should all create IPsec SAs. This way we could have one requirements document include Identity protection, and allow for a larger number of messages, and another that has no Identity Protection requirement, and requires a small number of message. We can also have one or several WGs in charge of the key management protocols. Sara. From owner-ipsec@lists.tislabs.com Tue Aug 14 02:22:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E9MkN27064; Tue, 14 Aug 2001 02:22:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA06443 Tue, 14 Aug 2001 04:39:21 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Sandy Harris'" , Cc: , Subject: RE: Simplifying IKE Date: Tue, 14 Aug 2001 09:36:08 +0100 Message-Id: <000b01c1249c$752ac580$0109e982@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <3B782AC3.FFE8D633@storm.ca> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > And what is the purpose of having different SAs to protect > different flows? > > (besides thwarting traffic analysis) > > Far from thwarting traffic analysis, I think that makes it > easier. Having > multiple SAs between two gateways gives an analyst more data. > He or she > can look at the data in the header that classifies packets by SA. Sorry, I meant "traffic analysis" in the more general sense of analyzing anything about the traffic flow, in this case specifically cryptanalysis of the data stream. I originally did this in the ipsec-properties draft as well until someone pointed out that it was vague. Is there a well-defined term for this type of traffic analysis? "Data analysis"? While I am personally in favour of sending all traffic down a single tunnel (in most cases), I did think of one attack which could be thwarted by separating traffic flows: Imagine that an attacker can generate traffic on flow A behind a gateway and read the encrypted traffic on the Internet; he now has the possibility of doing a chosen-plaintext attack. If the gateway sends traffic across multiple SAs, then cryptanalysis of the output stream for flow A will only allow the attacker to crack the key for SA_A (which only protects traffic which was generated by the attacker). Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Tue Aug 14 02:52:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E9q6N00629; Tue, 14 Aug 2001 02:52:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA06528 Tue, 14 Aug 2001 05:06:05 -0400 (EDT) Message-Id: <200108140912.f7E9CY005751@thunk.east.sun.com> From: Bill Sommerfeld To: andrew.krywaniuk@alcatel.com cc: "'Sandy Harris'" , ipsec@lists.tislabs.com, dharkins@lounge.org, Joel.Snyder@Opus1.COM Subject: Re: Simplifying IKE In-reply-to: Your message of "Tue, 14 Aug 2001 09:36:08 BST." <000b01c1249c$752ac580$0109e982@andrewk3.ca.newbridge.com> Reply-to: sommerfeld@East.Sun.COM Date: Tue, 14 Aug 2001 05:12:34 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Sorry, I meant "traffic analysis" in the more general sense of analyzing > anything about the traffic flow, in this case specifically cryptanalysis of > the data stream. most folks using the term "traffic analysis" seems to use it to mean analysis of everything *except* the encryption.. i.e., looking at message size, volume, origins, and miscellanous cleartext identifiers (e.g., ip addresses and SPI's for IPsec). > I originally did this in the ipsec-properties draft as well until > someone pointed out that it was vague. Is there a well-defined term > for this type of traffic analysis? "Data analysis"? cryptanalysis? ;-) sounds like an active chosen-plaintext attack.. - Bill From owner-ipsec@lists.tislabs.com Tue Aug 14 06:12:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EDC4N09901; Tue, 14 Aug 2001 06:12:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06948 Tue, 14 Aug 2001 08:06:01 -0400 (EDT) Message-Id: <200108141213.IAA13485@bcn.East.Sun.COM> Date: Tue, 14 Aug 2001 08:13:07 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: having and eating cake? agressive mode with identity hiding To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MJK2awSgirpJinC+H+yHjg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk After the IPsec meeting, some people mentioned to me that if we'd get rid of one mode, they'd prefer getting rid of main mode and keeping aggressive mode. As it turns out, in the paper from which the internet draft presented at the meeting was based: http://sec.femto.org/wetice-2001/papers/radia-paper.pdf it mentions that we can get identity hiding with the public signature key variant. It would be nice to have a single IKE protocol. Perhaps this slightly modified aggressive mode/identity hiding/public signature keys would be a good choice. The basic idea is: message 1: Alice--->Bob g^a mod p message 2: Bob---->Alice g^b mod p, {"Bob", proof I'm Bob} encrypted with g^ab mod p ;the proof he's Bob consists of a signature on messages 1 and 2, e.g. message 3: Alice---->Bob {"Alice", proof I'm Alice}g^ab mod p I might want to add the OAKLEY-style trick where Bob can respond in message 2 with "I am going to want a stateless cookie, so try again, but this time send cookie c" That way if Bob isn't under attack, he can do the 3 message exchange, and if he is, he responds to cookie-less message 1's with a cookie, and responds to valid cookie-containing message 2's with the rest of the protocol. Radia From owner-ipsec@lists.tislabs.com Tue Aug 14 06:12:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EDC4N09900; Tue, 14 Aug 2001 06:12:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07014 Tue, 14 Aug 2001 08:30:40 -0400 (EDT) Message-Id: <200108141236.f7ECaWu09104@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Henry Spencer , ipsec@lists.tislabs.com, FreeS/WAN Design Issues Subject: Re: Wes Hardaker: opportunistic encryption deployment problems In-reply-to: Your message of Sat, 11 Aug 2001 13:14:00 PDT. <15221.37384.191416.901953@thomasm-u1.cisco.com> Date: Tue, 14 Aug 2001 14:36:32 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Also: I think the MIP experience sez that we ought to consider whether we'd want such a PKI even if it were possible. => we leave the technical domain there... I've never seen a rational argument about this! Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Aug 14 06:19:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EDJaN10041; Tue, 14 Aug 2001 06:19:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07061 Tue, 14 Aug 2001 08:39:12 -0400 (EDT) Message-Id: <200108131313.f7DDDIB21122@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of "Wed, 08 Aug 2001 18:25:38 PDT." <200108090125.f791PcT00595@dharkins@lounge.orgatty.lounge.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 13 Aug 2001 09:13:18 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan Harkins writes: Dan> Then the problem is on the other end. The selector either says every Dan> packet _MUST_ be IPsec-protected or else it _MUST NOT_ be Dan> IPsec-protected. When IPsec is not part of the stack, this is a concern because the policy checks must be done by the IPsec piece rather than having the crypto status noted and checked by upper layers. Dan> Either way, if some packets--those with Binding Updates-- are received with Dan> IPsec protection and others-- those without Binding Updates-- are not then Dan> we're going to have a problem. If the packet has some form of authentication (I'll not prejudge by saying AH), and this is noted in the control structure, then the piece that processes the Binding Update says "okay, it was protected". The TCP layer (or whatever) above it didn't require that the packet was protected (or not), so it goes on. If the system policy required all packets to be authenticated, then TCP would check that. Dan McDonald? Bill Sommerfeld? Itojun? Does this make sense? {Has anyone considered putting IKE message inside of a TCP option? This doesn't help keep the session private, but if the point is to establish keying so that a Binding Update will work, then this saves a bunch of latency. You just can't go fix the triangle before your connection comes up... I keep thinking that MIPv6 is the answer to multi6} ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO3fSbIqHRg3pndX9AQEVGwP6A37XpPsE6EP2SAfMrRCh443NsNCYKGKi JxF2F5U19q8zwesXcbArhTkPENEYJIgSW3evmLnbu3tZkNpE4YBMSbZTLt9dvQyA UdqDwjHER79YJgmwfDNTLSQCc6GCwNLrBsqXcIgYlx5AAnJrp+UattHAL8XbV4vb TddaHJ9BFcA= =1SaI -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 14 07:32:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EEWjN11692; Tue, 14 Aug 2001 07:32:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07370 Tue, 14 Aug 2001 09:43:02 -0400 (EDT) Message-ID: <9D6A470BD38ED311908000805F65B4EC054AF990@rndex50.ottawa.mitel.com> From: "Dilkie, Lee" To: "'andrew.krywaniuk@alcatel.com'" , "'Sandy Harris'" , ipsec@lists.tislabs.com Cc: dharkins@lounge.org, Joel.Snyder@Opus1.COM Subject: RE: Simplifying IKE Date: Tue, 14 Aug 2001 09:49:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Imagine that an attacker can generate traffic on flow A > behind a gateway and > read the encrypted traffic on the Internet; he now has the > possibility of > doing a chosen-plaintext attack. If the gateway sends traffic across > multiple SAs, then cryptanalysis of the output stream for > flow A will only > allow the attacker to crack the key for SA_A (which only > protects traffic > which was generated by the attacker). > > Andrew I'm thinking that an attacker with access to the plaintext side of an IPsec gateway already has far easier attacks than sending a trillion plaintext packets (which I'm sure will go un-noticed) through the gateway and doing an analysis on the results. I think the point is being missed here. It's the complexity of trying to deal with *every* possible security attack that has led to the current mess. It is just not practical to have the IP layer fully responsible for *all* security. Decide what you can do to protect the privacy of communications in a *reasonable* enviroment. Let the upper, application, layer add it's own authentication (and encryption as well if necessary) because that's where those decisions make more sense. Treat security like the onion, as it's supposed to be treated. It's not a failure to punt the problem and say "look, solving that attack is the responsibility of the application, if the consequences are that severe, then the application needs to be secure as well". Think of IPsec as the default "freebee" security that is inherent in the system, if an application needs more, then let them add more. My 2 cents worth, I now return you to your previous programming. Lee Dilkie Mitel Networks 350 Legget Drive Kanata, ON, Canada K2K 2W7 Phone: 1-613-592-5660 "It wasn't easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day." - Homer Simpson (from "The Simpsons") From owner-ipsec@lists.tislabs.com Tue Aug 14 08:41:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EFfnN17086; Tue, 14 Aug 2001 08:41:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07537 Tue, 14 Aug 2001 10:52:59 -0400 (EDT) From: Sheila Frankel To: Radia Perlman Subject: Re: having and eating cake? agressive mode with identity hiding Message-ID: <997801168.3b793cd0c30c8@email.nist.gov> Date: Tue, 14 Aug 2001 10:59:28 -0400 (EDT) Cc: ipsec@lists.tislabs.com References: <200108141213.IAA13485@bcn.East.Sun.COM> In-Reply-To: <200108141213.IAA13485@bcn.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.5 X-Originating-IP: 65.1.246.246 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is one problem that arises from adopting aggressive mode as the single IKE variant. Since "g^a mod p" is sent in message 1, we lose the capability to negotiate the Diffie-Hellman group. Sheila Frankel NIST Quoting Radia Perlman : > It would be nice to have a single IKE protocol. Perhaps this slightly > modified aggressive mode/identity hiding/public signature keys would > be a good choice. > > The basic idea is: > > message 1: > Alice--->Bob > g^a mod p > > message 2: > Bob---->Alice > g^b mod p, {"Bob", proof I'm Bob} encrypted with g^ab mod p > ;the proof he's Bob consists of a signature on messages 1 and 2, > e.g. > > message 3: > Alice---->Bob > {"Alice", proof I'm Alice}g^ab mod p From owner-ipsec@lists.tislabs.com Tue Aug 14 08:47:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EFlgN18100; Tue, 14 Aug 2001 08:47:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07567 Tue, 14 Aug 2001 11:06:34 -0400 (EDT) Message-Id: <200108141513.LAA15508@bcn.East.Sun.COM> Date: Tue, 14 Aug 2001 11:13:45 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: having and eating cake? agressive mode with identity hiding To: Radia.Perlman@sun.com, sheila.frankel@nist.gov Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kADDpooVp04r/8v7mlHM9A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Re: Sheila Frankel's pointing out the loss of ability to negotiate the D-H group. Is it that important to negotiate it rather than having Alice choose? If so, how many groups might Alice be willing to propose? If it's only a handful, then it wouldn't be tragic in the rare case where her choice was unacceptable to Bob for Bob to reply with "unacceptable D-H choice" and Alice to cycle through her choices. Or have Bob reply with his list of acceptable choices. Radia From: Sheila Frankel There is one problem that arises from adopting aggressive mode as the single IKE variant. Since "g^a mod p" is sent in message 1, we lose the capability to negotiate the Diffie-Hellman group. Sheila Frankel NIST From owner-ipsec@lists.tislabs.com Tue Aug 14 08:47:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EFlgN18101; Tue, 14 Aug 2001 08:47:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07586 Tue, 14 Aug 2001 11:10:13 -0400 (EDT) Date: Tue, 14 Aug 2001 11:16:46 -0400 (EDT) From: Henry Spencer To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: RE: Simplifying IKE In-Reply-To: <000b01c1249c$752ac580$0109e982@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 14 Aug 2001, Andrew Krywaniuk wrote: > Sorry, I meant "traffic analysis" in the more general sense of analyzing > anything about the traffic flow, in this case specifically cryptanalysis of > the data stream. That's incorrect; "traffic analysis" is an idiom with a specific meaning in the cryptography world. Schneier, p219: Traffic analysis is the analysis of encrypted messages: where they come from, where they go to, how long they are, when they are sent, how frequent or infrequent they are, whether they coincide with outside events like meetings, and more. A lot of good information is buried in that data, and a cryptanalyst will want to get his hands on it... (When he says "analysis of encrypted messages", he means "without decrypting them"; the context of this is a discussion of how traffic analysis can assist with cryptanalysis.) > ...Is there a well-defined term > for this type of traffic analysis? "Data analysis"? "Cryptanalysis" is usual. That's a very generic term, which includes things like chosen-plaintext attacks. > ...a chosen-plaintext attack. If the gateway sends traffic across > multiple SAs, then cryptanalysis of the output stream for flow A will only > allow the attacker to crack the key for SA_A (which only protects traffic > which was generated by the attacker). If the encryption scheme is vulnerable to chosen-plaintext attacks, it is already too weak to be used for protecting important data. Well-chosen encryption schemes are not vulnerable to (practical) chosen-plaintext attacks, and so this argument falls apart in real life. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Aug 14 09:33:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EGXMN20669; Tue, 14 Aug 2001 09:33:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07628 Tue, 14 Aug 2001 11:20:02 -0400 (EDT) Message-ID: <20010814152715.7635.qmail@web13804.mail.yahoo.com> Date: Tue, 14 Aug 2001 08:27:15 -0700 (PDT) From: Pyda Srisuresh Subject: Re: Traffic handling and key management "divide and coquer" To: Sara Bitan , ipsec@lists.tislabs.com In-Reply-To: <003901c1249d$86b1a8e0$0300000a@bilbo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Sara Bitan wrote: > I think that we are at a crucial point where we can make a change that will > turn our work to more focused and efficient, and hopefully fruitful. I > suggest we use a "divide and conquer" strategic. > We should first of all separate IPsec transforms traffic handling (i.e. ESP > and AH) and key management work to different WGs (if I understand right, > this was raised by JI in the SAAG meeting). I like focused work groups. IPsec WG should be focused on protocols independent of IKE. IKE WG must be focused on delivering the key maangement requirements of IPsec. > This process is already happening as we speak - MSEC and KINK are working on > key management protocols that create IPsec SAs, with different > requirements. ESP and AH will still be used for traffic handling. > If we will do the separation, we will soon be able to tell the industry that > the work on the IPsec transforms is done, which I think will be a great > advantage. > Yes. > I think we should also allow for several key management protocols, > preferably with one framework. > This is the only way we will be able to cater for the requirements of "DSL > geeks" as well as "billion mobile users" (quoting Jari's words). > > There are several actions that we need to take for this to happen: > 1) Allow working groups other than IPsec to work on key management > protocols, this way we could shut down the IPsec WG and keep on working on > new key management protocols. As I said this is already happening. > 2) Limit IPsec wg to only on the following IKE modifications : NAT ^^^^^^^^ I would prefer a name like "IKE WG", that is reflective of the work the WG is focused on. > traversal, SCTP support and re-keying. The new IKE version should be a minor I would also suggest including the ability to specify IPsec SPD in a flexible manner in Quick mode. Above all, the new-IKE should be focused on servicing the IPsec protocols. All of the modificications suggested (NAT traversal, SCTP support, rekeying and support for IPsec SPD) share the common theme of supporting IPsec deployment. Perhaps an RFC focused on IPsec-IKE interaction would be immensely useful. As it stands, IKE is taking center stage due to its complexity. Issues with Ipsec are considered secondary compared to IKE. The roles ought to be reversed. Ipsec deployment is the end goal and as such the eventual focus should be shifted to Ipsec. IKE should facilitate Ipsec, without taking the center stage by itself with its complexity and inability to fully support Ipsec in its deployment. Thanks. <... stuff deleted> > Sara. > regards, suresh __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-ipsec@lists.tislabs.com Tue Aug 14 09:34:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EGYZN20719; Tue, 14 Aug 2001 09:34:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07599 Tue, 14 Aug 2001 11:12:30 -0400 (EDT) Message-Id: <200108141519.AAG12850@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 14 Aug 2001 08:02:13 -0700 To: "Dilkie, Lee" , "'andrew.krywaniuk@alcatel.com'" , "'Sandy Harris'" , ipsec@lists.tislabs.com From: Scott Fluhrer Subject: RE: Simplifying IKE Cc: dharkins@lounge.org, Joel.Snyder@Opus1.COM In-Reply-To: <9D6A470BD38ED311908000805F65B4EC054AF990@rndex50.ottawa.mi tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:49 AM 8/14/01 , Dilkie, Lee wrote: >> Imagine that an attacker can generate traffic on flow A >> behind a gateway and >> read the encrypted traffic on the Internet; he now has the >> possibility of >> doing a chosen-plaintext attack. If the gateway sends traffic across >> multiple SAs, then cryptanalysis of the output stream for >> flow A will only >> allow the attacker to crack the key for SA_A (which only >> protects traffic >> which was generated by the attacker). >> >> Andrew > >I'm thinking that an attacker with access to the plaintext side of an IPsec gateway already has far easier attacks than sending a trillion plaintext packets (which I'm sure will go un-noticed) through the gateway and doing an analysis on the results. Perhaps not. Maybe the attacker is a legitimate user who is authorized to send traffic via the encrypted connection, but cannot listen in on traffic from other authorized users. In that case, the attack scenario is perfectly valid. Of course, the real solution to this attack is to use an encryption algorithm that is secure against a chosen plaintext attack. Since that is an attack model used to analyze ciphers, that is practical. > >I think the point is being missed here. It's the complexity of trying to deal with *every* possible security attack that has led to the current mess. It is just not practical to have the IP layer fully responsible for *all* security. Decide what you can do to protect the privacy of communications in a *reasonable* enviroment. Let the upper, application, layer add it's own authentication (and encryption as well if necessary) because that's where those decisions make more sense. Treat security like the onion, as it's supposed to be treated. It's not a failure to punt the problem and say "look, solving that attack is the responsibility of the application, if the consequences are that severe, then the application needs to be secure as well". Think of IPsec as the default "freebee" security that is inherent in the system, if an application needs more, then let them add more. Actually, (IMHO) it wasn't the huge number of security attacks which lead to the complexity -- it was the large number of requirements. Why isn't main mode acceptable for everything? Well, because some people are concerned (rightly or wrongly) about the additional messages. Why do we have both AH and ESP authentication transforms? Because AH is needed in some case (so I have heard it claimed), and will not work in others (e.g. when NAT is involved). Why do we have the ESP-NULL "encryption" transform? Certainly not to prevent an attack on security. > >My 2 cents worth, I now return you to your previous programming. > >Lee Dilkie > >Mitel Networks >350 Legget Drive >Kanata, ON, Canada >K2K 2W7 > >Phone: 1-613-592-5660 > >"It wasn't easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day." > - Homer Simpson (from "The Simpsons") > From owner-ipsec@lists.tislabs.com Tue Aug 14 10:05:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EH5RN21393; Tue, 14 Aug 2001 10:05:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07704 Tue, 14 Aug 2001 12:14:16 -0400 (EDT) Message-ID: <3B79500C.1367FCD3@storm.ca> Date: Tue, 14 Aug 2001 12:21:32 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Require AH? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dropping AH has been suggested from time to time. The proposal seems to get considerable support, but also some opposition. I'm not entirely clear on reasons for the opposition, but it seems to revolve around things like mobile IP that may need header authentication and arguably don't always need encryption. Currently we have three binary choices. Use AH, use ESP authentication, use ESP encryption. This gives us 8 possibilities: use none, just do normal IP two with duplicate authentication in both AH and ESP (with or without encryption) two ways to do authentication alone (AH or ESP-null) two ways to do encryption + authentication (AH or ESP authentication) one way to encrypt without authentication (ESP with no authentication) The last is a very bad idea and implementations should prohibit it, but I think the current protocol definition allows it. The various lines starting "two ..." all indicate unecessary complications: more options for IKE to negotiate, more combinations to implement and test, more things for the SADB to track. If we dump AH, we get rid of half the options and are left with: use none, just do normal IP one way to do authentication alone, ESP-null one way to do encryption + authentication, ESP one way to encrypt without authentication (ESP with no authentication) The last alternative is unchanged and still a bad idea. We could get rid of by requiring that ESP always authenticate. An alternative would be to require AH on all IPsec connections, giving: use none, just do normal IP one way to do authentication alone, AH one way to do encryption + authentication, AH + ESP This gets rid of that nasty fourth alternative, keeps AH for those that need it, and lets us drop ESP-null. If AH is actually needed, which some people have claimed in previous discussions, then the last strikes me as the best choice. Of course, this was likely discussed back before authentication was added to ESP. Why was it rejected then? From owner-ipsec@lists.tislabs.com Tue Aug 14 10:16:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EHGXN21819; Tue, 14 Aug 2001 10:16:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07740 Tue, 14 Aug 2001 12:33:29 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15225.21556.73706.140436@thomasm-u1.cisco.com> Date: Tue, 14 Aug 2001 09:39:16 -0700 (PDT) To: Radia Perlman - Boston Center for Networking Cc: sheila.frankel@nist.gov, ipsec@lists.tislabs.com Subject: Re: having and eating cake? agressive mode with identity hiding In-Reply-To: <200108141513.LAA15508@bcn.East.Sun.COM> References: <200108141513.LAA15508@bcn.East.Sun.COM> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, I think that one of the optimizations that IKE could use is to take an optimistic approach on many fronts. This is, expect that what you propose will work (ie group 2) but allow the ability to reject that proposal if it's not acceptible. In the vast majority of cases -- assuming some stability in ciphersuites which seems reasonable at this point -- the average case will complete much quicker. The same can be done for DoS protection: if you're not under attack, sending the initiator off to do a return-routability test is fairly useless, and counterproductive. The protocol needs to be able support that test so that the recipient can defend himself if need be, but that should be the exceptional case. Given these two things, and then the ability to squish a quick mode exchange into the final cert exchange (using an optimistic approach too), we should be able to get the average initial main/quick mode exchange to complete in 4 or 5 messages rather than 8 or 9. Mike Radia Perlman - Boston Center for Networking writes: > Re: Sheila Frankel's pointing out the loss of ability to negotiate the D-H > group. > > Is it that important to negotiate it rather than having Alice choose? > If so, how many groups might Alice be willing to propose? If it's > only a handful, then it wouldn't be tragic in the rare case where her choice > was unacceptable to Bob for Bob to reply with "unacceptable D-H choice" > and Alice to cycle through her choices. Or have Bob reply with his list of > acceptable choices. > > Radia > > > > From: Sheila Frankel > > > There is one problem that arises from adopting aggressive mode as the > single IKE > variant. Since "g^a mod p" is sent in message 1, we lose the capability > to > negotiate the Diffie-Hellman group. > > Sheila Frankel > NIST > > From owner-ipsec@lists.tislabs.com Tue Aug 14 10:24:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EHODN21969; Tue, 14 Aug 2001 10:24:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07762 Tue, 14 Aug 2001 12:40:55 -0400 (EDT) To: Michael Richardson Cc: ipsec@lists.tislabs.com In-reply-to: mcr's message of Mon, 13 Aug 2001 09:13:18 -0400. <200108131313.f7DDDIB21122@marajade.sandelman.ottawa.on.ca> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Simplifying IKE From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 01:41:22 +0900 Message-Id: <20010814164122.68A287BA@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> Either way, if some packets--those with Binding Updates-- are received with >> IPsec protection and others-- those without Binding Updates-- are not then >> we're going to have a problem. > If the packet has some form of authentication (I'll not prejudge by saying >AH), and this is noted in the control structure, then the piece that >processes the Binding Update says "okay, it was protected". > The TCP layer (or whatever) above it didn't require that the packet was >protected (or not), so it goes on. If the system policy required all packets >to be authenticated, then TCP would check that. > > Dan McDonald? Bill Sommerfeld? Itojun? > Does this make sense? (not about the ipsec issue... anyway...) The above is basically what we (itojun + Dave Johnson) thought around 09 -> 10 mobile-ip6 spec (when we put more details on IPsec manipulation). there were issues raised at IETF50 about policy lookup in such cases. a point was made that there are implementations that are not flexible enough to permit such a tweak. now I believe that we should avoid piggybacking the binding updates onto normal packets. if we treat them separately, we can decide IPsec policy completely in a independent manner. I believe it okay to use IPsec with mobile-ip6. we don't need to invent a new authentication mechanism. another point made at IETF50 about mobile-ip6 was the lack of PKI infrastructure, which is, a hard problem by itself and noone is going to be able ot solve this. itojun From owner-ipsec@lists.tislabs.com Tue Aug 14 10:47:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EHlqN22630; Tue, 14 Aug 2001 10:47:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07820 Tue, 14 Aug 2001 13:11:09 -0400 (EDT) Message-Id: <200108141718.f7EHISo02668@kebe.east.sun.com> Subject: Re: Require AH? In-Reply-To: <3B79500C.1367FCD3@storm.ca> from Sandy Harris at "Aug 14, 2001 12:21:32 pm" To: Sandy Harris Date: Tue, 14 Aug 2001 13:18:28 -0400 (EDT) CC: ipsec@lists.tislabs.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > An alternative would be to require AH on all IPsec connections, giving: > > use none, just do normal IP > one way to do authentication alone, AH > one way to do encryption + authentication, AH + ESP > > This gets rid of that nasty fourth alternative, keeps AH for those that > need it, and lets us drop ESP-null. I believe this scenario was the original intent of RFCs 1825-1827. I would have no objections to reviving this way of doing things. > If AH is actually needed, which some people have claimed in previous > discussions, then the last strikes me as the best choice. > > Of course, this was likely discussed back before authentication was > added to ESP. Why was it rejected then? Some HW folks didn't think you could do AH in hardware. I've heard other HW folks (but only after the fact) say that you can indeed do AH in hardware. ESP authentication was a knee-jerk reaction to Bellovin's analysis of 1825-1827. He stated the threats of unauthenticated CBC encryption + replay problems. The knee-jerk reaction was to add both of these properties to ESP, without first thinking that requiring a fixed AH with replay protection could do the trick. (Personally I thought that AH in hardware was not difficult, especially with assist from the SW IPsec processing in the form of "exception vectors" that tagged which bytes were to be treated as zero.) Dan From owner-ipsec@lists.tislabs.com Tue Aug 14 10:49:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EHntN22658; Tue, 14 Aug 2001 10:49:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07832 Tue, 14 Aug 2001 13:13:26 -0400 (EDT) Message-Id: <200108141718.f7EHIFu29709@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: Simplifying IKE In-reply-to: Your message of Mon, 13 Aug 2001 09:13:18 EDT. <200108131313.f7DDDIB21122@marajade.sandelman.ottawa.on.ca> Date: Tue, 14 Aug 2001 19:18:15 +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: {Has anyone considered putting IKE message inside of a TCP option? This doesn't help keep the session private, but if the point is to establish keying so that a Binding Update will work, then this saves a bunch of latency. You just can't go fix the triangle before your connection comes up... I keep thinking that MIPv6 is the answer to multi6} => as the context is IPv6 I think an extension header like the destination option header (in final position) is far better for this. But I don't like piggybacking for heavy weight protocols (no clear pro, many cons like ROHC confusion, complexity, SPD ambiguity, etc). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Aug 14 11:01:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EI12N22897; Tue, 14 Aug 2001 11:01:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07808 Tue, 14 Aug 2001 13:08:30 -0400 (EDT) Message-Id: <200108141714.f7EHEOZ00626@dharkins@lounge.orgatty.lounge.org> To: Radia Perlman - Boston Center for Networking Cc: sheila.frankel@nist.gov, ipsec@lists.tislabs.com Subject: Re: having and eating cake? agressive mode with identity hiding In-Reply-To: Your message of "Tue, 14 Aug 2001 11:13:45 EDT." <200108141513.LAA15508@bcn.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <623.997809264.1@lounge.org> Date: Tue, 14 Aug 2001 10:14:24 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is where some deployment experience comes in handy. In real world situations-- outside bakeoffs-- there is rarely any negotiation. Usually both sides are already configured and prepared to speak to each other. And in the rare cases in which they are not there are a couple more messages to the exchange and possibly another exponentiation in a new group, big deal. It seems better to optimize for the 99%-of-the-time case. Dan. On Tue, 14 Aug 2001 11:13:45 EDT you wrote > Re: Sheila Frankel's pointing out the loss of ability to negotiate the D-H > group. > > Is it that important to negotiate it rather than having Alice choose? > If so, how many groups might Alice be willing to propose? If it's > only a handful, then it wouldn't be tragic in the rare case where her choice > was unacceptable to Bob for Bob to reply with "unacceptable D-H choice" > and Alice to cycle through her choices. Or have Bob reply with his list of > acceptable choices. > > Radia > > > > From: Sheila Frankel > > > There is one problem that arises from adopting aggressive mode as the > single IKE > variant. Since "g^a mod p" is sent in message 1, we lose the capability > > to > negotiate the Diffie-Hellman group. > > Sheila Frankel > NIST > > From owner-ipsec@lists.tislabs.com Tue Aug 14 12:22:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EJM2N24763; Tue, 14 Aug 2001 12:22:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08014 Tue, 14 Aug 2001 14:36:39 -0400 (EDT) Date: Tue, 14 Aug 2001 10:29:58 -0700 From: Derrell Piper To: Michael Thomas , Radia Perlman - Boston Center for Networking cc: sheila.frankel@nist.gov, ipsec@lists.tislabs.com Subject: Re: having and eating cake? agressive mode with identity hiding Message-ID: <1799220.997784998@el-air-1.electric-loft.org> In-Reply-To: <15225.21556.73706.140436@thomasm-u1.cisco.com> References: <200108141513.LAA15508@bcn.East.Sun.COM> <15225.21556.73706.140436@thomasm-u1.cisco.com> X-Mailer: Mulberry/2.1.0b3 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Exactly! Dan and I also met yesterday and we believe we have a four message exchange which accomplishes this by eliminating the first message of Main Mode (in the normal case), reducing Phase 2 to two messages (while preserving replay protection), and overlaying Phase 2 on top of the end of Main Mode. As you suggest, the responder would still have the option of requiring a six message exchange either if he did not like the opportunistic protection profile chosen by the initiator or if he decided that he was under a possible DoS attack and wanted to validate the cookie exchange / source peer address. Derrell --On Tuesday, August 14, 2001 9:39 AM -0700 Michael Thomas wrote: > > Yes, I think that one of the optimizations that > IKE could use is to take an optimistic approach on > many fronts. This is, expect that what you propose > will work (ie group 2) but allow the ability to > reject that proposal if it's not acceptible. In > the vast majority of cases -- assuming some > stability in ciphersuites which seems reasonable > at this point -- the average case will complete > much quicker. The same can be done for DoS > protection: if you're not under attack, sending > the initiator off to do a return-routability test > is fairly useless, and counterproductive. The > protocol needs to be able support that test so > that the recipient can defend himself if need be, > but that should be the exceptional case. > > Given these two things, and then the ability to > squish a quick mode exchange into the final cert > exchange (using an optimistic approach too), we > should be able to get the average initial > main/quick mode exchange to complete in 4 or 5 > messages rather than 8 or 9. > > Mike > > Radia Perlman - Boston Center for Networking writes: > > Re: Sheila Frankel's pointing out the loss of ability to negotiate the > D-H > group. > > > > Is it that important to negotiate it rather than having Alice choose? > > If so, how many groups might Alice be willing to propose? If it's > > only a handful, then it wouldn't be tragic in the rare case where her > choice > was unacceptable to Bob for Bob to reply with "unacceptable D-H > choice" > and Alice to cycle through her choices. Or have Bob reply with > his list of > acceptable choices. > > > > Radia > > > > > > > > From: Sheila Frankel > > > > > > There is one problem that arises from adopting aggressive mode as the > > single IKE > > variant. Since "g^a mod p" is sent in message 1, we lose the > capability > to > > negotiate the Diffie-Hellman group. > > > > Sheila Frankel > > NIST > > > > From owner-ipsec@lists.tislabs.com Tue Aug 14 13:53:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EKrEN26651; Tue, 14 Aug 2001 13:53:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08293 Tue, 14 Aug 2001 16:05:01 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15225.34304.65698.908126@thomasm-u1.cisco.com> Date: Tue, 14 Aug 2001 13:11:44 -0700 (PDT) To: ipsec@lists.tislabs.com Subject: deconstructing "simplify" X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems to me that it's worthwhile to come up with a list of what "simplify" means for IPsec, as it's pretty clear that we're not all talking about the same thing when we tag our pet ipsec/ike annoyance with the "simple" good housekeeping seal approval. Here's a strawman of a taxonomy: 1) Document simplification -- lots of people would like a easier way to read and understand the protocols involved. Others have mentioned that the documents are missing, vague, or misleading about various features/modes/etc. 2) Implementation simplification -- many people have voiced concerns that the current protocols are either too complex implementationwise, or provide either too many ways to implement features, or are vague/silent as to how features can be made interoperable. 3) Message count simplification -- many people have expressed that the message count between having a packet to send and sending it on a IPsec protected SA is excessive. 4) State machine simplification -- some people would like to see the IKE state machine far less complicated than it currently is. 5) Option/Mode simplification -- a lot of people have expressed an interest in reducing the number of nobs and dials in the protocols for both IKE and IPsec from a test-coverage security analysis standpoint. 6) Generality simplification -- some (many?) people would like to see IKE pay far less attention to generality in keying than it currently does and pay far more attention to the kind of keying it is actually used for, namely IPsec. Etc. Now people can argue about the relative ranking of these as priorities in the simplification process, and it's pretty clear that simplifications on one axis are going to result in either non-simplification or complexity on another axis, but it might be useful to keep track of what sort of simplification we're talking about as we start to talk about requirements. Mike From owner-ipsec@lists.tislabs.com Tue Aug 14 14:33:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ELXLN27762; Tue, 14 Aug 2001 14:33:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08355 Tue, 14 Aug 2001 16:54:01 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Henry Spencer'" , "'Andrew Krywaniuk'" Cc: Subject: RE: Simplifying IKE Date: Tue, 14 Aug 2001 19:09:59 +0100 Message-Id: <000b01c12503$1514d160$0109e982@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > That's incorrect; "traffic analysis" is an idiom with a > specific meaning > in the cryptography world. Alas, it is no longer possible to speak plain English in this technocratic world :-) > If the encryption scheme is vulnerable to chosen-plaintext > attacks, it is > already too weak to be used for protecting important data. > Well-chosen > encryption schemes are not vulnerable to (practical) chosen-plaintext > attacks, and so this argument falls apart in real life. I don't disagree with this. If you remember, this topic arose from a previous discussion in which I was questioning the importance of having separate SAs (i.e. keys) to protect different flows. I merely mentioned what I felt to be the best counter-argument in order to balance out the discussion somewhat. I agree with Scott that this attack is certainly feasible in many environments, but we think/hope that modern ciphers are strong enough to resist adaptive chosen plaintext attacks. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Tue Aug 14 14:37:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ELbDN27842; Tue, 14 Aug 2001 14:37:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08349 Tue, 14 Aug 2001 16:53:41 -0400 (EDT) Message-ID: <20010814210053.23366.qmail@web4604.mail.yahoo.com> Date: Tue, 14 Aug 2001 14:00:53 -0700 (PDT) From: shiwen chen Subject: VPN subnet mask To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am learning VPN here. Could anybody please tell me why the subnet mask for an VPN client address is "255.255.255.255"? Thanks a lot. Regards, Shiwen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-ipsec@lists.tislabs.com Tue Aug 14 15:01:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EM14N28349; Tue, 14 Aug 2001 15:01:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08386 Tue, 14 Aug 2001 17:14:37 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15225.38446.29432.676809@thomasm-u1.cisco.com> Date: Tue, 14 Aug 2001 14:20:46 -0700 (PDT) To: Henry Spencer Cc: "Hallam-Baker, Phillip" , Hugh Daniel , ipsec@lists.tislabs.com Subject: RE: Wes Hardaker: opportunistic encryption deployment problems In-Reply-To: References: <2F3EC696EAEED311BB2D009027C3F4F40154CA4B@vhqpostal.verisign.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote: > > I would not rely on any outcome being achieved as a byproduct of > > DNSSEC... > > In other words, we can't ever rely on DNS being secure? Come now. > Admittedly, there are obstacles between here and there, but it is still > the right solution for a number of problems. This strikes me as saying that the only obstacle to star travel is the speed of light... Mike From owner-ipsec@lists.tislabs.com Tue Aug 14 16:21:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ENLAN00334; Tue, 14 Aug 2001 16:21:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08487 Tue, 14 Aug 2001 18:32:20 -0400 (EDT) Message-ID: <009701c0f37d$aa484b20$c9ce1dd5@mahdavi> From: "mahdavi" To: "ipsec" Subject: implementing fully hardware version of IPSEC Date: Wed, 13 Jun 2001 00:53:40 +0430 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01C0F3A3.49B6A7E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C0F3A3.49B6A7E0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi freinds. I am to design fully hardware version of IPSEC to gain 2.4 GBPS.=20 Now I am searching similar versions but I cant find any.=20 could you show me some line to follow up.=20 or any of you can guide me ? any suggestion is helpful.=20 Sincerely yours=20 mahdavi=20 ------=_NextPart_000_0090_01C0F3A3.49B6A7E0 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi freinds.
I am to design fully hardware version = of IPSEC to=20 gain 2.4 GBPS.
Now I am searching similar versions but = I cant find=20 any.
could you show me some line to follow = up.=20
or any of you can guide me = ?
 
any suggestion is helpful. =
 
Sincerely yours
mahdavi
------=_NextPart_000_0090_01C0F3A3.49B6A7E0-- From owner-ipsec@lists.tislabs.com Tue Aug 14 16:23:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ENN3N00397; Tue, 14 Aug 2001 16:23:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08496 Tue, 14 Aug 2001 18:35:52 -0400 (EDT) Date: Tue, 14 Aug 2001 18:42:13 -0400 (EDT) From: Henry Spencer To: Jan Vilhuber cc: ipsec@lists.tislabs.com Subject: one vs. many (was Re: Simplifying IKE) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Slightly old mail... catching up.) On Thu, 9 Aug 2001, Jan Vilhuber wrote: > I say let's figure out the camps, and write a protocol that satisfies ONE of > the camps (and later we'll write another that satisfies the other, if they > decide there's still a need to do so). The problem with this is that it *guarantees* that there will be no 90% solution implemented... even if one is technically possible. As witness the latest "having and eating cake" thread, it's imperative to explore 90%-solution possibilities *thoroughly* -- which we have not yet done! -- before giving up on the idea. Giving up on it, and accepting a fragmentation of the user community, is an irrevocable step. Going from one to two protocols, if it later becomes necessary, is much easier than going from two to one, when the possibility later becomes obvious. > A straw-poll should quickly show if there's a 90% that agree on something in > this group. What does "this group" consist of? The ones who feel motivated enough to respond? That's not even a representative sample of the mailing list, let alone of the IPsec user community. > As for middle-of-the-road, I fear that it'll be so-so at everything, and not > very good at anything at all... Just like TCP? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Aug 14 16:24:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ENOWN00423; Tue, 14 Aug 2001 16:24:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08426 Tue, 14 Aug 2001 17:44:24 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696DD@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Michael Thomas'" , Henry Spencer Cc: "Hallam-Baker, Phillip" , Hugh Daniel , ipsec@lists.tislabs.com Subject: RE: Wes Hardaker: opportunistic encryption deployment problems Date: Tue, 14 Aug 2001 14:49:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1250B.06A5ED50" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1250B.06A5ED50 Content-Type: text/plain; charset="iso-8859-1" > Henry Spencer writes: > > On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote: > > > I would not rely on any outcome being achieved as a byproduct of > > > DNSSEC... > > > > In other words, we can't ever rely on DNS being secure? Come now. > > Admittedly, there are obstacles between here and there, > but it is still > > the right solution for a number of problems. > > This strikes me as saying that the only obstacle to > star travel is the speed of light... > > Mike Not quite, light manages to travel from A to B independent of our requirement for interstellar travel. Unfortunately the requirement that people be able to use DNSSEC as the solution to all the worlds security problems has led to a significant and serious increase in the complexity, deployment cost and overhead of DNSSEC. Phill ------_=_NextPart_000_01C1250B.06A5ED50 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1250B.06A5ED50-- From owner-ipsec@lists.tislabs.com Tue Aug 14 18:31:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1VdN03889; Tue, 14 Aug 2001 18:31:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08776 Tue, 14 Aug 2001 20:50:27 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40154CA51@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F40154CA51@vhqpostal.verisign.com> Date: Tue, 14 Aug 2001 20:14:32 -0400 To: "Hallam-Baker, Phillip" From: Stephen Kent Subject: RE: IKE must have no Heirs Cc: "'Dan Harkins'" , Alex Alten , Kory Hamzeh , "Hallam-Baker, Phillip" , "'mcnelson@mindspring.com'" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:56 AM -0700 8/7/01, Hallam-Baker, Phillip wrote: >Dan, > >It has been somewhat difficult for anyone in the IETF security area in the >past dacade not to become familliar with the internal machinations of the >IPSEC group. > >I would like something no more complex than SKIP that used RSA or DSA. > >In 1995 SKIP would have been the right move. At this point to go forward >there has to at least be compatibility with the keying material that is >already distributed. SKIP was a poor choice for any long-lived SA, because SKIP forced every packet to carry SA state information in lieu of exchanging SA establishment messages. Steve From owner-ipsec@lists.tislabs.com Tue Aug 14 18:35:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1ZPN03990; Tue, 14 Aug 2001 18:35:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08759 Tue, 14 Aug 2001 20:50:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <003901c1249d$86b1a8e0$0300000a@bilbo> References: <003901c1249d$86b1a8e0$0300000a@bilbo> Date: Tue, 14 Aug 2001 19:36:29 -0400 To: "Sara Bitan" From: Stephen Kent Subject: Re: Traffic handling and key management "divide and coquer" Cc: Content-Type: multipart/alternative; boundary="============_-1214285465==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1214285465==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sara, i think your suggestion is a reasonable one. We should realize that before we separate the AH/ESP work from key management, we need to establish a clearer set of requirements of what these protocols require in the way of SA management, separate from key management. we have yet to do that. Steve --============_-1214285465==_ma============ Content-Type: text/html; charset="us-ascii" Re: Traffic handling and key management "divide and co
Sara,

i think your suggestion is a reasonable one. We should realize that before we separate the AH/ESP work from key management, we need to establish a clearer set of requirements of what these protocols require in the way of SA management, separate from key management.  we have yet to do that.

Steve
--============_-1214285465==_ma============-- From owner-ipsec@lists.tislabs.com Tue Aug 14 18:35:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1ZPN03991; Tue, 14 Aug 2001 18:35:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08753 Tue, 14 Aug 2001 20:49:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3B709706.4D051BE5@storm.ca> References: <3B709706.4D051BE5@storm.ca> Date: Tue, 14 Aug 2001 19:03:36 -0400 To: Sandy Harris From: Stephen Kent Subject: Re: Simplifying IKE Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:33 PM -0400 8/7/01, Sandy Harris wrote: >The Leech, Schiller and Bellovin (LSB?) document mentions: > >> the goal: to produce a more secure, simpler, and more robust version of IKE. > >I thought it might be useful to inventory some proposed simplifications. Of >course I'll toss in my own opinions while I'm at it, but my goal is less to >get them accepted than to provoke discussion. > >>From the Schneier and Ferguson analysis we get: > >> 1: eliminate transport mode > >It would be possible to eliminate tunnel mode instead, and just use IP-in-IP >over transport where required, but it seems simpler to treat transport as a >degenerate tunnel instead. Either mode can do everything we need, so we need >only one mode. My vote is for tunnel. the two modes are not interchangeable, as discussed in my rebuttal to the paper in question, a year ago. we have advocates for both, and neither group of advocates, so far, has been willing to give up its favorite features for the other. the simplest change would be to give up transport, since tunnel mode can emulate transport, but one incurs added overhead as a result. also, we now have other protocols, most notably L2TP, specifying use of transport mode in their RFCs. > >> 2. eliminate the AH protocol >> 3. modify ESP to always authenticate; only encryption should be > optional > >Fine by me, but I vaguely recall some arguments that IPv6 and/or mobile >IP actually need AH. Could anyone who needs it speak up again? I'm sure you will hear from those folks. > >If it turns out there are really good reasons to keep AH, then I'd say the >simplification is: > >2a: eliminate ESP authentication are you suggesting removing the authentication option from ESP? ESP with null encryption is more efficient than AH in most cases, and if one needs both encryption and authentication, the combined mode use of ESP is much more efficient. this suggests that this suggestion is not very attractive. >3a: require AH on all packets. No choice, no null mode. An IPsec connection > authenticates all packets, period. see comments above as to why this is not a great idea. > >> 4. modify ESP to ensure it authenticates all data used in the deciphering > of the payload > >This is the only recommendation in this paper based on a direct security >flaw, with a proposed attack to demonstrate it. There are others in the >Simpson paper. the proposed attack is based on assumptions about independent keying for AH and ESP (with null auth). IKE won't do this and it is not clear that anyone has ever done this via manual key management. it's easy to warn against this, and retain the option for encrypt-only ESP, which has potential efficiency benefits for situations where upper layer protocols already provide authentication. I'll leave comments on your IKE suggestions to others. Note that since IKE is not the only key management protocol, e.g., KINK will be available at some point too, changes to supported ESP/AH modes are not really within scope for a "simplify IKE" discussion. Steve From owner-ipsec@lists.tislabs.com Tue Aug 14 18:37:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1boN04035; Tue, 14 Aug 2001 18:37:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08770 Tue, 14 Aug 2001 20:50:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 14 Aug 2001 19:09:04 -0400 To: Chris Trobridge From: Stephen Kent Subject: RE: Simplifying IKE Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:59 AM +0100 8/8/01, Chris Trobridge wrote: >I have to admit I started in the "keep tunnelling - los transport" camp, but >with more experience I would definitely prefer transport mode + IP-in-IP. >This makes gateways and end-to-end cases identical. It also separates >routing issues associated with tunnelling from IPSEC. remember that a major difference between tunnel and transport modes is what headers are examined for access control purposes. if one changes to IP-in-IP tunneling above IPsec, it would be important to retain this security facility, which means we still need to know where to look in the stack, ... >I'd also like to see all IPSEC traffic between two hosts carried by just one >SA. I can't see any value in using multiple SAs between to hosts. IPSEC >should be just providing a secure pipe between two hosts - what goes through >it is better regulated by a firewall. There is an argument that you might >want to use different strengths of crypto for performance reasons but there >is generally a focus on performing one type of encryption really well rather >than supporting multiple types. IPsec is not designed to be just an encryption protocol. It provides access control comparable to that of a static, packet filtering firewall, but with per-SA authentication that a firewall, if placed behind an IPsec device, cannot provide. > >I'm less keen on AH and would lose it if at all possible. Authenticated ESP >provides authentication, integrity and anti-replay of the IP payload - what >do you care if the IP header has been tampered with? (what is missing from >ESP auth - just the destination IP address?). Per-hop use of SAs currently >appears limited as keys are typically only shared by the end-points. > >I would like to see things like null encryption and specific algorithms not >being MUST (or even plaintext bypass). My main reason for this is that you >can reject these by policy anyway but that exclusion from build is required >for products that go through tough security evaluations. Null encryption and null authentication are artifices, because IKE had allocated two slots for algorithms for ESP, before we allowed modular security service use. One could do away with these conventions in a reengineered IKE. Steve From owner-ipsec@lists.tislabs.com Tue Aug 14 18:37:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1bsN04047; Tue, 14 Aug 2001 18:37:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08771 Tue, 14 Aug 2001 20:50:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40154CA5B@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F40154CA5B@vhqpostal.verisign.com> Date: Tue, 14 Aug 2001 19:15:28 -0400 To: "Hallam-Baker, Phillip" From: Stephen Kent Subject: RE: Simplifying IKE Cc: "'Steve.Robinson@psti.com'" , Sandy Harris , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:41 AM -0700 8/8/01, Hallam-Baker, Phillip wrote: > > STEVE: I agree with you on this, but in practice, unless a >> PKI standard is >> settled on, my boss is not going to approve of me implementing a >> proprietary solution unless a consensus is reached in the >> IPsec community >> first. My gut feeling is that it isn't gonna happen unless >> the work at the >> NIST on PKI suddenly becomes accepted as a standard. > >Why not simply plug into XKMS? > >All IPSEC cares about is the delivery of authenticated, validated >keys. It should not need to know if the PKI is based on X509/PKIX, >PGP, SPKI or YAPKI. > IPsec cares about IDs bound to keys used for authentication. to the extent that different PKI technologies support different name forms, IPsec needs to be aware of this, as it affects the types of symbolic names we support in the SPD. A recommendation for simplification I have not yet seen is to reduce the range of cert types that IKE supports. Everyone who does certs probably supports X.509. Few products support PGP, SPKI, or DNSSEC, despite these being mentioned in IKE. this would seem like an easy simplification. Steve P.S. Please, Phil, no more XKMS advertisements here, OK? From owner-ipsec@lists.tislabs.com Tue Aug 14 20:34:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F3YbN06169; Tue, 14 Aug 2001 20:34:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA08994 Tue, 14 Aug 2001 22:47:00 -0400 (EDT) From: "Lars Eggert" To: "Stephen Kent" , "Chris Trobridge" , Cc: Subject: RE: Simplifying IKE Date: Tue, 14 Aug 2001 19:53:28 -0800 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0002_01C124FA.C96C0C90" Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C124FA.C96C0C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > At 7:59 AM +0100 8/8/01, Chris Trobridge wrote: > >I have to admit I started in the "keep tunnelling - los > transport" camp, but > >with more experience I would definitely prefer transport mode + IP-in-IP. > >This makes gateways and end-to-end cases identical. It also separates > >routing issues associated with tunnelling from IPSEC. > > remember that a major difference between tunnel and transport modes > is what headers are examined for access control purposes. if one > changes to IP-in-IP tunneling above IPsec, it would be important to > retain this security facility, which means we still need to know > where to look in the stack, ... Yes, transport mode over IPIP tunnels (IIPtran) must conform to RFC2401, section 5.2.1. And we think it can/does - from draft-touch-ipsec-vpn-01.txt: The primary difference is in the subsequent processing of the incoming packet. IPsec tunnel mode does not require a separate rule for accepting packets with the inner header; once they are accepted during the unwrap phase, they are accepted. IIPtran requires that unwrapped packets be further processed by an additional round, which requires that incoming packets with these headers be accepted. As noted in [1], IPsec processing should retain SA use for subsequent IPsec or firewall processing. It should be possible for these incoming packets to be IPIP decapsulated _only_ where the appropriate SA has been used, but as a separate step. The main difference between the two approaches is during outbound processing: With IPsec tunnel mode, the SA determines routing (the inner header determines the SA which prepends the outer header), while with transport mode over IPIP, routing determines the SA (encapsulation comes first, the SA is then determined by the outer header). This seems like a small enough difference; however, the implications reach far. One example is that unmodified routing algorithms work inside IIPtran overlay networks. Another is that IIPtran decouples overlay topology from security: Deploying IPIP tunnels without IPsec yields an insecure overlay; IPsec can simply be turned on for existing overlay topologies by establishing SAs. In a nutshell, IIPtran constructs a "virtual Internet" using IPIP tunnels (and supports most protocols/applications inside it without modifications); and secures links in the "virtual Internet" with transport-mode IPsec. We are preparing an update to draft-touch-ipsec-vpn-01.txt to address further implications of IIPtran that have been encountered recently (such as IKE interactions, found during the KAME implementation of the ID by Itojun-san). Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California ------=_NextPart_000_0002_01C124FA.C96C0C90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF9DCCAtgw ggJBoAMCAQICAwMjBTANBgkqhkiG9w0BAQQFADCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAx OTk5LjkuMTYwHhcNMDAwODI0MjAzMDA4WhcNMDEwODI0MjAzMDA4WjBUMQ8wDQYDVQQEEwZFZ2dl cnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MRwwGgYJKoZIhvcNAQkBFg1s YXJzZUBpc2kuZWR1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPXJ9w2zneu+G7DyBIO+vb 7+yc/wZ25hjvHtaQl3K9zBviiKk2lZgiQwY/bXhm/UquC+e0Zob6N66AAZC3SfrhW6yBwjNDpANG 2cyB1ANMCRVJDZ4tFJCRr6cA/HpIUomDv1YQQeaApAEy1l0wFi1i/+ZM5ymbuNMlWD7tbqfThQID AQABo3cwdTAqBgUrZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMBgGA1Ud EQQRMA+BDWxhcnNlQGlzaS5lZHUwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQCLrl8z+NIJo+FGgD0lblfYWS1IWETnOQikVU+m /fcZY882udywrXcd9mazQHWs3La9TtSEUj++wlCAEnJ9+QsWAwKOne5Fm8EGMYPWrjKMM7nJ8wyO q6oGlm1GnmineVN3TV9oDnxkIHmzEJvQ5FLG9dHy1z0Mk7QkilAgtrq8gDCCAxQwggJ9oAMCAQIC AQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsT H0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBaMIGUMQswCQYDVQQGEwJaQTEVMBMGA1UE CBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0w GwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGc I3LNEkxL937Px/vKciT0QlKsV5Xje2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc 9BF0ALwFLE8JAxcxzPRB1HLGpl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8C AwEAAaM3MDUwEgYDVR0TAQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH 58ayDjANBgkqhkiG9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKl N9idtxcoVgWL3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLk XJeu/H6syg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAswwggLIAgEBMIGcMIGUMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAyMFMAkGBSsOAwIaBQCgggGFMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDgxNTAzNTMyOFowIwYJKoZI hvcNAQkEMRYEFJBJvRNnvVG4gAg99NKwSi9EYnSUMHYGCSqGSIb3DQEJDzFpMGcwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAcGBSsOAwIaMAoGCCqGSIb3DQIFMAoGCCqGSIb3DQIFMIGtBgkrBgEEAYI3EAQxgZ8wgZww gZQxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZp bGxlMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2AgMDIwUwDQYJKoZIhvcNAQEBBQAE gYBKKil71p/7C7hiv1DRKShfwuYmguWLOkuQcRe86+UhefYX0zoOxqB+q0p8N3hGx/sFSuIo5A+L JUjl1+67KlQXexY3fapFR9/InyTvY5Pjf0gdidA7lXPLf/E6NyS/PSjexlQ3XrHGBPx6gzEVgX94 KuKTxZtSdJtT7DmTjjFsrwAAAAAAAA== ------=_NextPart_000_0002_01C124FA.C96C0C90-- From owner-ipsec@lists.tislabs.com Tue Aug 14 23:30:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F6U7N15726; Tue, 14 Aug 2001 23:30:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA09180 Wed, 15 Aug 2001 01:06:55 -0400 (EDT) Date: Wed, 15 Aug 2001 01:13:26 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: having and eating cake? agressive mode with identity hiding In-Reply-To: <200108141213.IAA13485@bcn.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 14 Aug 2001, Radia Perlman - Boston Center for Networking wrote: > It would be nice to have a single IKE protocol. Perhaps this slightly > modified aggressive mode/identity hiding/public signature keys would > be a good choice. Sounds good to me... especially if it has the option of including the start of an IPsec-SA negotiation in message 3. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Aug 15 00:42:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F7gCN26425; Wed, 15 Aug 2001 00:42:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA09311 Wed, 15 Aug 2001 02:43:15 -0400 (EDT) Message-ID: <3B7A1BA8.B59B4DE3@F-Secure.com> Date: Wed, 15 Aug 2001 09:50:16 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Radia Perlman - Boston Center for Networking CC: ipsec@lists.tislabs.com Subject: Re: having and eating cake? agressive mode with identity hiding References: <200108141213.IAA13485@bcn.East.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking wrote: > > After the IPsec meeting, some people mentioned to me that if we'd > get rid of one mode, they'd prefer getting rid of main mode and > keeping aggressive mode. > > As it turns out, in the paper from which the internet draft presented > at the meeting was based: > http://sec.femto.org/wetice-2001/papers/radia-paper.pdf > it mentions that we can get identity hiding with the public signature key > variant. > > It would be nice to have a single IKE protocol. Perhaps this slightly > modified aggressive mode/identity hiding/public signature keys would > be a good choice. > This protocol looks good on identity hiding point of view, but the main 'practical' benefit of AM is that the identity is sent on message one, allowing the responder to select the proper policy based on reception of the first message. Ari > The basic idea is: > > message 1: > Alice--->Bob > g^a mod p > > message 2: > Bob---->Alice > g^b mod p, {"Bob", proof I'm Bob} encrypted with g^ab mod p > ;the proof he's Bob consists of a signature on messages 1 and 2, e.g. > > message 3: > Alice---->Bob > {"Alice", proof I'm Alice}g^ab mod p > > > I might want to add the OAKLEY-style trick where Bob can respond in message > 2 with "I am going to want a stateless cookie, so try again, but this > time send cookie c" That way if Bob isn't under attack, he can do the 3 message > exchange, and if he is, he responds to cookie-less message 1's with a cookie, > and responds to valid cookie-containing message 2's with the rest > of the protocol. > > Radia -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Wed Aug 15 04:38:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FBchN15552; Wed, 15 Aug 2001 04:38:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA09741 Wed, 15 Aug 2001 06:37:07 -0400 (EDT) Message-ID: <9D048F4A422CD411A56500B0D0209C5B02861C0A@NS-CA> From: Jay Ratford To: "'shiwen chen '" , "'ipsec@lists.tislabs.com '" Subject: RE: VPN subnet mask Date: Wed, 15 Aug 2001 03:43:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The 32bit mask designated an "individual host" which is why it is specified in Phase II proxied IDs -----Original Message----- From: shiwen chen To: ipsec@lists.tislabs.com Sent: 8/14/01 2:00 PM Subject: VPN subnet mask Hi, I am learning VPN here. Could anybody please tell me why the subnet mask for an VPN client address is "255.255.255.255"? Thanks a lot. Regards, Shiwen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-ipsec@lists.tislabs.com Wed Aug 15 06:01:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FD1GN19198; Wed, 15 Aug 2001 06:01:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09868 Wed, 15 Aug 2001 08:13:25 -0400 (EDT) Message-ID: <20010815122039.5960.qmail@web4604.mail.yahoo.com> Date: Wed, 15 Aug 2001 05:20:39 -0700 (PDT) From: shiwen chen Subject: RE: VPN subnet mask To: Christopher Gripp , ipsec@lists.tislabs.com Cc: vpn@secruityfocus.com In-Reply-To: <4EBB5C35607E7F48B4AE162D956666EF339182@guam.corp.axcelerant.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks a lot. I have seen three vendors' VPNs are using this 255.255.255.255 mask (including IPSec, PPTP). Remote clients are run with Microsoft Windows 2000. So I think it is quite a conventional way (if not standard) for VPN configurations, isn't it?. Suppose I have an application on remote access client, can I use this information to detect if the local computer is on VPN or not? Regards, Shiwen --- Christopher Gripp wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > That's used to explicitily define that single host. > Without other > info I can't tell you why it is configured that way > on your VPN. > What VPN are you using? What OS are you running, > etc. > > Christopher S. Gripp > Systems Engineer > Axcelerant > > > - -----Original Message----- > From: shiwen chen [mailto:sxc4305@yahoo.com] > Sent: Tuesday, August 14, 2001 2:01 PM > To: ipsec@lists.tislabs.com > Subject: VPN subnet mask > > > Hi, > I am learning VPN here. Could anybody please tell me > why the subnet mask for an VPN client address is > "255.255.255.255"? Thanks a lot. > > Regards, > Shiwen > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute > with Yahoo! > Messenger > http://phonecard.yahoo.com/ > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.5.8 for non-commercial use > > > iQA/AwUBO3mu/2LRPLnfp/zREQJZrwCg/uLeFpKIdgqwSbcm9AGX20aLKPEAoJMb > ardg+mhUBOjrnDDB5qCpfey7 > =Y3K0 > -----END PGP SIGNATURE----- > __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-ipsec@lists.tislabs.com Wed Aug 15 06:12:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FDC9N19602; Wed, 15 Aug 2001 06:12:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09882 Wed, 15 Aug 2001 08:21:07 -0400 (EDT) Date: Wed, 15 Aug 2001 11:26:38 +0200 From: Pawel Krawczyk To: ipsec@lists.tislabs.com Subject: key derived SPI? Message-ID: <20010815112638.C2291@aba.krakow.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.20i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is there anything wrong with deriving IPSec SA data like SPI from the keying material, using one way hash? I thinking of reducing number of parameters needed to automatically setup an IPSec SA between two hosts without IKE. Using this trick I could end up with only password and destination IP address needed to setup the secure channel. So the final SPI generation scheme would be: h0 = SHA1(source IP) [public] h1 = SHA1(destination IP) [public] h2 = SHA1(provided password) [secret] h3 = SHA1(h2) h4 = SHA1(h3) SPI = h0 XOR h1 XOR h4 enc key = h2 auth key = h3 Result SA = ESP(SPI, src IP, dst IP, enc key, auth key) So I use h2 as ESP encryption key, h3 as authentication key and generated SPI to build the ESP SA. This SA is used to send small amount of data and its lifetime is short. Use of h3 for auth is not to provide any possible information about encryption key with authentication ciphertext. The IP addresses are hashed only to minimize chance of SPI conflict with many clients. Is there any problem with this method? -- Pawe„ Krawczyk *** home: security: *** fidonet: 2:486/23 From owner-ipsec@lists.tislabs.com Wed Aug 15 07:29:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FETfN21970; Wed, 15 Aug 2001 07:29:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10134 Wed, 15 Aug 2001 09:47:34 -0400 (EDT) Message-ID: <80B684C5E29FD211AA8000A0C9CDD9190925B301@il0015exch005u.ih.lucent.com> From: "Kopeikin, Roy A (Roy)" To: Derrell Piper , Michael Thomas , Radia Perlman - Boston Center for Networking Cc: sheila.frankel@nist.gov, ipsec@lists.tislabs.com Subject: RE: having and eating cake? agressive mode with identity hiding Date: Wed, 15 Aug 2001 08:54:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derrell, what do you think it is going to take to get something like this approved? This sounds like a good combination towards simplifying. Roy -----Original Message----- From: Derrell Piper [mailto:ddp@cips.nokia.com] Sent: Tuesday, August 14, 2001 12:30 PM To: Michael Thomas; Radia Perlman - Boston Center for Networking Cc: sheila.frankel@nist.gov; ipsec@lists.tislabs.com Subject: Re: having and eating cake? agressive mode with identity hiding Exactly! Dan and I also met yesterday and we believe we have a four message exchange which accomplishes this by eliminating the first message of Main Mode (in the normal case), reducing Phase 2 to two messages (while preserving replay protection), and overlaying Phase 2 on top of the end of Main Mode. As you suggest, the responder would still have the option of requiring a six message exchange either if he did not like the opportunistic protection profile chosen by the initiator or if he decided that he was under a possible DoS attack and wanted to validate the cookie exchange / source peer address. Derrell --On Tuesday, August 14, 2001 9:39 AM -0700 Michael Thomas wrote: > > Yes, I think that one of the optimizations that > IKE could use is to take an optimistic approach on > many fronts. This is, expect that what you propose > will work (ie group 2) but allow the ability to > reject that proposal if it's not acceptible. In > the vast majority of cases -- assuming some > stability in ciphersuites which seems reasonable > at this point -- the average case will complete > much quicker. The same can be done for DoS > protection: if you're not under attack, sending > the initiator off to do a return-routability test > is fairly useless, and counterproductive. The > protocol needs to be able support that test so > that the recipient can defend himself if need be, > but that should be the exceptional case. > > Given these two things, and then the ability to > squish a quick mode exchange into the final cert > exchange (using an optimistic approach too), we > should be able to get the average initial > main/quick mode exchange to complete in 4 or 5 > messages rather than 8 or 9. > > Mike > > Radia Perlman - Boston Center for Networking writes: > > Re: Sheila Frankel's pointing out the loss of ability to negotiate the > D-H > group. > > > > Is it that important to negotiate it rather than having Alice choose? > > If so, how many groups might Alice be willing to propose? If it's > > only a handful, then it wouldn't be tragic in the rare case where her > choice > was unacceptable to Bob for Bob to reply with "unacceptable D-H > choice" > and Alice to cycle through her choices. Or have Bob reply with > his list of > acceptable choices. > > > > Radia > > > > > > > > From: Sheila Frankel > > > > > > There is one problem that arises from adopting aggressive mode as the > > single IKE > > variant. Since "g^a mod p" is sent in message 1, we lose the > capability > to > > negotiate the Diffie-Hellman group. > > > > Sheila Frankel > > NIST > > > > From owner-ipsec@lists.tislabs.com Wed Aug 15 08:19:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FFJcN23980; Wed, 15 Aug 2001 08:19:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10247 Wed, 15 Aug 2001 10:37:39 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15226.35517.701351.186328@thomasm-u1.cisco.com> Date: Wed, 15 Aug 2001 07:44:13 -0700 (PDT) To: Dan McDonald Cc: Sandy Harris , ipsec@lists.tislabs.com Subject: Re: Require AH? In-Reply-To: <200108141718.f7EHISo02668@kebe.east.sun.com> References: <3B79500C.1367FCD3@storm.ca> <200108141718.f7EHISo02668@kebe.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan McDonald writes: > Some HW folks didn't think you could do AH in hardware. I've heard other HW > folks (but only after the fact) say that you can indeed do AH in hardware. I have great confidence that hardware guys can do just about anything you set them out to do. It's only the final transistor count that tells you whether it is worth the effort. > ESP authentication was a knee-jerk reaction to Bellovin's analysis of > 1825-1827. He stated the threats of unauthenticated CBC encryption + replay > problems. The knee-jerk reaction was to add both of these properties to ESP, > without first thinking that requiring a fixed AH with replay protection could > do the trick. Actually, what would make me most happy would be to have a single IPsec extension header which does *everything*. This helps on the code/message compactness front, as well as simplifying the number of SADB entries, different protocols handling, header traversal, etc. It seems to me that if we had modes like gzip-aes-cbc-sha1 for ESP transforms, we could get rid of both AH and IPCOMP. Mike From owner-ipsec@lists.tislabs.com Wed Aug 15 08:48:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FFmxN27240; Wed, 15 Aug 2001 08:48:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10265 Wed, 15 Aug 2001 10:53:27 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696DE@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Stephen Kent'" , "Hallam-Baker, Phillip" Cc: "'Steve.Robinson@psti.com'" , Sandy Harris , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: XKMS and NIH RE: Simplifying IKE Date: Wed, 15 Aug 2001 07:59:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1259A.F2F61790" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1259A.F2F61790 Content-Type: text/plain; charset="iso-8859-1" Steve, You entirely manage to miss the point. You agree that part of the complexity of IPSEC is that it is required to interface to every PKI in the universe for political reasons. Then you make the statesmanlike suggestion that the world standardize on the specification of the working group you have been chairing. It may well make good technical sense. Perhaps you would like to lend your support to Neil Kinnock's proposal to make English the sole administrative language of the European Union whil you are at it? As for 'advertising' the work product of another open standards working group that is appropriate to a working group topic, has substantial commitments from the major PKI vendors, major application vendors and major customers - I will do it at every opportunity thank you very much, whether the specification is one of my own invention or of somebody else. It was the first time that I had raised XKMS on the IPSEC list. It was not off topic, it was in fact entirely on topic. I don't think that the majority of the IETF would agree that Not Invented Here is a good policy. Plenty of IETF working groups make use of the work product of other working groups outside the IETF, BEEP makes use of a W3C specification, PKIX makes use of an ITU standard. Perhaps you could elaborate the reasons why you do not consider XKMS to be a suitable topic for consideration by IPSEC? XKMS is designed to allow simplification of client implementation of PKI. The topic on the table is simplification of IPSEC. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, August 14, 2001 7:15 PM > To: Hallam-Baker, Phillip > Cc: 'Steve.Robinson@psti.com'; Sandy Harris; ipsec@lists.tislabs.com; > owner-ipsec@lists.tislabs.com > Subject: RE: Simplifying IKE > > > At 7:41 AM -0700 8/8/01, Hallam-Baker, Phillip wrote: > > > STEVE: I agree with you on this, but in practice, unless a > >> PKI standard is > >> settled on, my boss is not going to approve of me implementing a > >> proprietary solution unless a consensus is reached in the > >> IPsec community > >> first. My gut feeling is that it isn't gonna happen unless > >> the work at the > >> NIST on PKI suddenly becomes accepted as a standard. > > > >Why not simply plug into XKMS? > > > >All IPSEC cares about is the delivery of authenticated, validated > >keys. It should not need to know if the PKI is based on X509/PKIX, > >PGP, SPKI or YAPKI. > > > IPsec cares about IDs bound to keys used for authentication. to the > extent that different PKI technologies support different name forms, > IPsec needs to be aware of this, as it affects the types of symbolic > names we support in the SPD. > > A recommendation for simplification I have not yet seen is to reduce > the range of cert types that IKE supports. Everyone who does certs > probably supports X.509. Few products support PGP, SPKI, or DNSSEC, > despite these being mentioned in IKE. this would seem like an easy > simplification. > > Steve > > P.S. Please, Phil, no more XKMS advertisements here, OK? > ------_=_NextPart_000_01C1259A.F2F61790 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1259A.F2F61790-- From owner-ipsec@lists.tislabs.com Wed Aug 15 08:50:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FFoIN27409; Wed, 15 Aug 2001 08:50:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10307 Wed, 15 Aug 2001 11:16:00 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696DF@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Stephen Kent'" , "Hallam-Baker, Phillip" Cc: "'Dan Harkins'" , Alex Alten , Kory Hamzeh , "Hallam-Baker, Phillip" , "'mcnelson@mindspring.com'" , ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs Date: Wed, 15 Aug 2001 08:20:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1259D.C7A1D6D0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1259D.C7A1D6D0 Content-Type: text/plain; charset="iso-8859-1" > SKIP was a poor choice for any long-lived SA, because SKIP forced > every packet to carry SA state information in lieu of exchanging SA > establishment messages. I see no reason why that specific problem could not have been fixed. If you have a securely established shared secret that is securely bound to a shared context there should be no per packet state requirement. Phill ------_=_NextPart_000_01C1259D.C7A1D6D0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1259D.C7A1D6D0-- From owner-ipsec@lists.tislabs.com Wed Aug 15 09:01:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FG1NN29270; Wed, 15 Aug 2001 09:01:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10320 Wed, 15 Aug 2001 11:17:57 -0400 (EDT) Date: Wed, 15 Aug 2001 11:24:24 -0400 (EDT) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com, FreeS/WAN Design Issues Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems In-Reply-To: <15221.37384.191416.901953@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 11 Aug 2001, Michael Thomas wrote: > > > [anonymous encryption] > > We thought about that, but decided that some authentication was better > > than none, especially since it would upgrade transparently... > > Well... How is this especially different than just > using self-signed certificates and having a wide open policy? The transparent upgrade to full security is important. As I said before, there's an important difference between temporary and permanent security holes. The nice thing about having DNSSEC verify the provenance of the public keys is that instituting this requires no changes to the protocol *or the protocol software*. Going from self-signed certificates to a certificate signing chain would. Before too very long, it *will* be necessary to secure DNS, whether that is done by the current DNSSEC or by other means. Why duplicate that work in each application? > I guess what bothers me is that you are expecting to > use DNS as a directory service for certs which it > wasn't really intended for... What was DNS "really intended for"? RFC 1034 (emphasis added): - The costs of implementing such a facility dictate that it be generally useful, and not restricted to a single application. We should be able to use names to retrieve host addresses, mailbox data, ***and other as yet undetermined information***. DNS is for retrieving information about names. Using it to obtain public keys or certificates (please distinguish between the two, they are not synonymous) for names seems perfectly reasonable. Which is why DNS now has KEY and CERT records. > ...thus making an already > complicated situation even more complicated, but > not changing the fundamental situation (PKI are hard). I tend to think that today's PKI are harder than necessary, partly because they are trying to reinvent the DNS wheel and doing it badly. As with the messes that arise in application-level encryption, much of this is spurious, arising because we have delayed too long in securing the basic services (IP, DNS). If DNS had been a secure source of KEY records (etc.) all along, people would wonder why all the fuss about PKI. > I guess that I view that there's probably an 80/20 rule > here which is being missed: *most* people aren't going > to go to the lengths of creating an active MITM attack > to snoop on boring old every day conversations. One must distinguish carefully between two different categories of people: the users, and the attackers. It's not unreasonable to aim protocols at 80% of the users, but that means those users should be secure against very nearly 100% of the attackers. It only takes one aggressive attacker to put many users in jeopardy. Most especially and particularly, there are quite a number of countries in the world where you can be 100% sure that the government will be an attacker, *because it already is*. And it has the cooperation, willing or unwilling, of the ISPs... so MITM attacks will not be difficult to mount. This is an important type of attacker. > ...Trying to insert > an upgrade path back to the mythical global PKI rather > misses the point: if there were such a beast, we could > should be able to use IKE as-is... Actually, we *are* proposing to use IKE pretty much as-is (gross though it is). Nothing in opportunistic encryption involves changes to IKE. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Aug 15 09:32:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FGWEN00642; Wed, 15 Aug 2001 09:32:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10375 Wed, 15 Aug 2001 11:48:29 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15226.39731.262640.816040@thomasm-u1.cisco.com> Date: Wed, 15 Aug 2001 08:54:27 -0700 (PDT) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com, FreeS/WAN Design Issues Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems In-Reply-To: References: <15221.37384.191416.901953@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Sat, 11 Aug 2001, Michael Thomas wrote: > > > > [anonymous encryption] > > > We thought about that, but decided that some authentication was better > > > than none, especially since it would upgrade transparently... > > > > Well... How is this especially different than just > > using self-signed certificates and having a wide open policy? > > The transparent upgrade to full security is important. As I said before, > there's an important difference between temporary and permanent security > holes. The nice thing about having DNSSEC verify the provenance of the > public keys is that instituting this requires no changes to the protocol > *or the protocol software*. Going from self-signed certificates to a > certificate signing chain would. Huh? IKE requires that you be able to verify signatures back to a trusted root. There is absolutely no difference whether you get those certs from DNS, IKE, or pony express. The verification process is essentially identical. The only difference I can see is if you want to not use certs and instead rely on naked public keys. I'm dubious about this as there are better thought out ways of doing a centralized key management scheme (namely, kerberos) which is what that amounts to (enrollment being the hard problem). > Before too very long, it *will* be necessary to secure DNS, whether that > is done by the current DNSSEC or by other means. Why duplicate that work > in each application? The implications of secure DNS is a global PKI. The same global PKI that doesn't exist. I have little reason to believe that the PKI fairy will leave one under our pillow any time soon. > One must distinguish carefully between two different categories of people: > the users, and the attackers. It's not unreasonable to aim protocols at > 80% of the users, but that means those users should be secure against very > nearly 100% of the attackers. It only takes one aggressive attacker to > put many users in jeopardy. > Most especially and particularly, there are quite a number of countries in > the world where you can be 100% sure that the government will be an > attacker, *because it already is*. And it has the cooperation, willing or > unwilling, of the ISPs... so MITM attacks will not be difficult to mount. > This is an important type of attacker. I guess I differentiate your average luser script kiddie with attackers who really know what they're doing. Like door locks and other common sense security measures, you can do an adequate job of most of the petty crimes by raising the bar to a sufficient degree of sophistication that the average kiddie is going to go back to making OE bombs instead. The latter category is and has always been far more problematic. In any case, there is already a way to thwart MITM attacks using IKE *today*. There is no need whatsoever to bring DNS into the picture to do that, and indeed DNS obscures the situation, IMO. Instead of making a single self contained complicated system, you now have two extremely complicated systems to analyze. Mike From owner-ipsec@lists.tislabs.com Wed Aug 15 10:30:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FHUfN03242; Wed, 15 Aug 2001 10:30:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10502 Wed, 15 Aug 2001 12:48:25 -0400 (EDT) Message-ID: From: Chris Trobridge To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: RE: Simplifying IKE Date: Wed, 15 Aug 2001 17:55:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think the extreme position is that what IPSEC does best is: i) Establishing keys between two known entities (IKE). ii) Allowing those entities to pass datagram payloads securely between them by providing encryption, authentication and anti-replay defenses. It also provides some tunnelling (VPN) and firewall services that are inferior to the free-standing implementations. IPSEC does not facilitate resilient routing and you're still likely to need a firewall in addition to IPSEC. People have suggested and, I think, implemented stacks where the IPSEC tunnels are treated as interfaces and hence can be accomodated by routing protocols. This also allow a firewall (integrated in the same stack) to make decisions based on the IPSEC tunnel. This would allow the IPSEC, routing protocols and firewalls to concentrate on what they do best. Of course, there would be still a problem of configuring all this securely. This has been discussed here before but, as usual, the discussion flared up and died away without any sort of concensus. As an aside, is there a 'standard' way for an application to request a specific IPSEC policy for its traffic? Chris > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: 15 August 2001 00:09 > To: Chris Trobridge > Cc: ipsec@lists.tislabs.com > Subject: RE: Simplifying IKE > > > At 7:59 AM +0100 8/8/01, Chris Trobridge wrote: > >I have to admit I started in the "keep tunnelling - los > transport" camp, but > >with more experience I would definitely prefer transport > mode + IP-in-IP. > >This makes gateways and end-to-end cases identical. It also > separates > >routing issues associated with tunnelling from IPSEC. > > remember that a major difference between tunnel and transport modes > is what headers are examined for access control purposes. if one > changes to IP-in-IP tunneling above IPsec, it would be important to > retain this security facility, which means we still need to know > where to look in the stack, ... > > >I'd also like to see all IPSEC traffic between two hosts > carried by just one > >SA. I can't see any value in using multiple SAs between to > hosts. IPSEC > >should be just providing a secure pipe between two hosts - > what goes through > >it is better regulated by a firewall. There is an argument > that you might > >want to use different strengths of crypto for performance > reasons but there > >is generally a focus on performing one type of encryption > really well rather > >than supporting multiple types. > > IPsec is not designed to be just an encryption protocol. It provides > access control comparable to that of a static, packet filtering > firewall, but with per-SA authentication that a firewall, if placed > behind an IPsec device, cannot provide. > > > > >I'm less keen on AH and would lose it if at all possible. > Authenticated ESP > >provides authentication, integrity and anti-replay of the IP > payload - what > >do you care if the IP header has been tampered with? (what > is missing from > >ESP auth - just the destination IP address?). Per-hop use > of SAs currently > >appears limited as keys are typically only shared by the end-points. > > > >I would like to see things like null encryption and specific > algorithms not > >being MUST (or even plaintext bypass). My main reason for > this is that you > >can reject these by policy anyway but that exclusion from > build is required > >for products that go through tough security evaluations. > > Null encryption and null authentication are artifices, because IKE > had allocated two slots for algorithms for ESP, before we allowed > modular security service use. One could do away with these > conventions in a reengineered IKE. > > Steve > > > This footnote confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Wed Aug 15 10:48:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FHmAN03902; Wed, 15 Aug 2001 10:48:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10548 Wed, 15 Aug 2001 13:04:03 -0400 (EDT) Message-ID: From: Chris Trobridge To: Michael Thomas Cc: ipsec@lists.tislabs.com Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen t problems Date: Wed, 15 Aug 2001 18:11:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think the problem is not specifically "global PKI" but "global trust infrastructure". It would be useful if IKE could use different trust models, including delegation this to another protocol. However, I think in most cases, binding up your key to an IP address probably isn't that useful, due to ephemeral nature of IP addresses - my impression is that this just gets worse with IPv6. The important thing is that you can authenticate who your peer is - there's no reason why this has to be bound up in an IP address - and that your policy allows to communicate with them. Chris > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 15 August 2001 16:54 > To: Henry Spencer > Cc: Michael Thomas; ipsec@lists.tislabs.com; FreeS/WAN Design Issues > Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption > deployment problems > > > Henry Spencer writes: > > On Sat, 11 Aug 2001, Michael Thomas wrote: > > > > > [anonymous encryption] > > > > We thought about that, but decided that some > authentication was better > > > > than none, especially since it would upgrade transparently... > > > > > > Well... How is this especially different than just > > > using self-signed certificates and having a wide open policy? > > > > The transparent upgrade to full security is important. As > I said before, > > there's an important difference between temporary and > permanent security > > holes. The nice thing about having DNSSEC verify the > provenance of the > > public keys is that instituting this requires no changes > to the protocol > > *or the protocol software*. Going from self-signed > certificates to a > > certificate signing chain would. > > Huh? IKE requires that you be able to verify signatures > back to a trusted root. There is absolutely no difference > whether you get those certs from DNS, IKE, or > pony express. The verification process is > essentially identical. The only difference I > can see is if you want to not use certs and > instead rely on naked public keys. I'm dubious > about this as there are better thought out ways > of doing a centralized key management scheme > (namely, kerberos) which is what that amounts > to (enrollment being the hard problem). > > > Before too very long, it *will* be necessary to secure > DNS, whether that > > is done by the current DNSSEC or by other means. Why > duplicate that work > > in each application? > > The implications of secure DNS is a global > PKI. The same global PKI that doesn't exist. > I have little reason to believe that the > PKI fairy will leave one under our pillow > any time soon. > > > One must distinguish carefully between two different > categories of people: > > the users, and the attackers. It's not unreasonable to > aim protocols at > > 80% of the users, but that means those users should be > secure against very > > nearly 100% of the attackers. It only takes one > aggressive attacker to > > put many users in jeopardy. > > > Most especially and particularly, there are quite a number > of countries in > > the world where you can be 100% sure that the government will be an > > attacker, *because it already is*. And it has the > cooperation, willing or > > unwilling, of the ISPs... so MITM attacks will not be > difficult to mount. > > This is an important type of attacker. > > I guess I differentiate your average luser script > kiddie with attackers who really know what they're > doing. Like door locks and other common sense > security measures, you can do an adequate job of > most of the petty crimes by raising the bar to > a sufficient degree of sophistication that the > average kiddie is going to go back to making > OE bombs instead. The latter category is and has > always been far more problematic. > > In any case, there is already a way to thwart MITM > attacks using IKE *today*. There is no need whatsoever > to bring DNS into the picture to do that, and indeed > DNS obscures the situation, IMO. Instead of making > a single self contained complicated system, you now > have two extremely complicated systems to analyze. > > Mike > > > This footnote confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Wed Aug 15 11:10:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FIAKN05022; Wed, 15 Aug 2001 11:10:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10592 Wed, 15 Aug 2001 13:26:43 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15226.45614.601672.408572@thomasm-u1.cisco.com> Date: Wed, 15 Aug 2001 10:32:30 -0700 (PDT) To: Chris Trobridge Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen t problems In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris Trobridge writes: > I think the problem is not specifically "global PKI" but "global trust > infrastructure". Yes, my sloppy. > It would be useful if IKE could use different trust models, including > delegation this to another protocol. > > However, I think in most cases, binding up your key to an IP address > probably isn't that useful, due to ephemeral nature of IP addresses - my > impression is that this just gets worse with IPv6. I agree, it not very optimal. It's quite possible that I don't understand this very well, but do the two use modes -- tunnel/transport -- really have the same identity semantics? For tunnel mode, you are essentially authenticating/authorizing an incoming interface to be built on the security gateway. That is, a route is established for a prefix. There really aren't any possible consumers (normally, at least, unless you're talking about a degenerate host-host tunnel). I'm not as sure with transport mode. I guess I view this as not so much affecting the routing subsystem so much as affecting the IP datagrams themselves; it may be implemented using the same mechanisms as are used for tunnels, but I don't think it *needs* to be thought of that way. In fact, since transport is a host-host mode, it sort of begs what the identity is used for at all. I've brought up on the list before that it would be nice to have the L3 credentials available for higher layers when in transport mode, (which I still think would be quite useful), but I guess I don't know what the transport identity is providing other than a reliable way of saying, "yes, this is mat@cisco.com". If there's not a policy module which can take action based on that knowledge, it seems like it's just providing a way to keep outsiders out. Maybe this is a useful enough service, but it seems sort of limited... Mike From owner-ipsec@lists.tislabs.com Wed Aug 15 13:26:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FKQvN10869; Wed, 15 Aug 2001 13:26:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10900 Wed, 15 Aug 2001 15:35:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058696DF@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F4058696DF@vhqpostal.verisign.com> Date: Wed, 15 Aug 2001 15:41:12 -0400 To: "Hallam-Baker, Phillip" From: Stephen Kent Subject: RE: IKE must have no Heirs Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:20 AM -0700 8/15/01, Hallam-Baker, Phillip wrote: > > SKIP was a poor choice for any long-lived SA, because SKIP forced >> every packet to carry SA state information in lieu of exchanging SA >> establishment messages. > >I see no reason why that specific problem could not have been fixed. >If you have a securely established shared secret that is securely bound >to a shared context there should be no per packet state requirement. Phil, You seem to be confusing the name of a protocol, and your apparent fondness for it, with the details that define that protocol. I don't recall your participation in IPsec WG activities during the time that the SKIP vs. IKE war took place, so perhaps your understanding of the history here is not so precise. Steve From owner-ipsec@lists.tislabs.com Wed Aug 15 14:03:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FL3qN12291; Wed, 15 Aug 2001 14:03:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11004 Wed, 15 Aug 2001 16:24:10 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696E8@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Stephen Kent'" , "Hallam-Baker, Phillip" Cc: ipsec@lists.tislabs.com Subject: RE: IKE must have no Heirs Date: Wed, 15 Aug 2001 13:30:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C125C9.21A2B4D0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C125C9.21A2B4D0 Content-Type: text/plain; charset="iso-8859-1" Steve, The fact that IPSEC has only gained widespread acceptance in the VPN market and is not being employed for its intended purpose, the fact that five years after the event the group is under an IESG injunction to get its act together suggest to me that those who were immediately responsible for the current situation should not be so openly contemptious and dismissive of those who might have useful ideas on how to remedy the current situation. I do not much care for the history of the internal politics of any IETF group, let alone the personal campaign stories of the combatants in the IKE vs SKIP wars. Nor for that matter am I as you suggest 'fond of SKIP', rather I have an aversion to a specification that introduces nine separate protocols for performing a simple key exchange. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Wednesday, August 15, 2001 3:41 PM > To: Hallam-Baker, Phillip > Cc: ipsec@lists.tislabs.com > Subject: RE: IKE must have no Heirs > > > At 8:20 AM -0700 8/15/01, Hallam-Baker, Phillip wrote: > > > SKIP was a poor choice for any long-lived SA, because SKIP forced > >> every packet to carry SA state information in lieu of > exchanging SA > >> establishment messages. > > > >I see no reason why that specific problem could not have been fixed. > >If you have a securely established shared secret that is > securely bound > >to a shared context there should be no per packet state requirement. > > Phil, > > You seem to be confusing the name of a protocol, and your apparent > fondness for it, with the details that define that protocol. I don't > recall your participation in IPsec WG activities during the time that > the SKIP vs. IKE war took place, so perhaps your understanding of the > history here is not so precise. > > Steve > ------_=_NextPart_000_01C125C9.21A2B4D0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C125C9.21A2B4D0-- From owner-ipsec@lists.tislabs.com Wed Aug 15 18:33:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G1XlN21298; Wed, 15 Aug 2001 18:33:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11271 Wed, 15 Aug 2001 20:25:12 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Sara Bitan'" , Subject: RE: Traffic handling and key management "divide and coquer" Date: Thu, 16 Aug 2001 01:20:48 +0100 Message-Id: <002b01c125e9$a0d89240$0109e982@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <003901c1249d$86b1a8e0$0300000a@bilbo> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I completely agree. I think some people have been much too quick too suggest dumping the entire framework we have developed over several years. Can we finally put what happened to Skip & Photuris behind us and stop schizophrenically shedding protocols? The IPsec WG has never been able to agree on requirements for anything. It seems idealistic and naive to believe that we could start over with a brand new KMP and acheive a different result. Like it or not, IKE was the preordained result of a design by commitee,a political process. The alternative to a committee process is a fascist process. Take your pick. I personally don't like either committees or facism, but I'll take committees any day of the week. Listen to the arguments we've heard on the list recently: Let's "simplify" IKE by reducing the number of messages, making the exchange asymmetrical, optionally adding a cookie exchange when the responder is under DoS, optionally piggybacking phase 2 on phase 1, optionally reducing the message count by allowing optimistic negotiation, optionally telling the initiator to retry the negotiation with different groups, changing phase 1 so it can't be used transparently in MSec, changing phase 2 so it can't be easily leveraged for KINK. Instead of spending another 2 years arguing and developing a new protocol that inevitably falls into the same old traps of optimization vs. simplicity vs. features, I suggest that we do basically what Sara suggests. To steal a comment from Ferguson/Schneier, ISAKMP is a framework for creating security protocols; the problem with IKE is that it also seems like a framework for creating security protocols. Let's have one protocol which is based on IKE MM/QM + improveike for VPN users, and a separate protocol (optimized for low-bandwidth applications) for things like ISCSI. Make them more specific than IKE is right now, but design them on top of ISAKMP so that those of us who need to write all of IKE and MSec and KINK and MPLS-SEC and MAP-DOI and whatever other esoteric usage of IPsec comes along, can at least leverage some of our code. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sara Bitan > Sent: Tuesday, August 14, 2001 9:46 AM > To: ipsec@lists.tislabs.com > Subject: Traffic handling and key management "divide and coquer" > > > I think that we are at a crucial point where we can make a > change that will > turn our work to more focused and efficient, and hopefully fruitful. I > suggest we use a "divide and conquer" strategic. > We should first of all separate IPsec transforms traffic > handling (i.e. ESP > and AH) and key management work to different WGs (if I > understand right, > this was raised by JI in the SAAG meeting). > This process is already happening as we speak - MSEC and KINK > are working on > key management protocols that create IPsec SAs, with different > requirements. ESP and AH will still be used for traffic handling. > If we will do the separation, we will soon be able to tell > the industry that > the work on the IPsec transforms is done, which I think will > be a great > advantage. > > I think we should also allow for several key management protocols, > preferably with one framework. > This is the only way we will be able to cater for the > requirements of "DSL > geeks" as well as "billion mobile users" (quoting Jari's words). > > There are several actions that we need to take for this to happen: > 1) Allow working groups other than IPsec to work on key management > protocols, this way we could shut down the IPsec WG and keep > on working on > new key management protocols. As I said this is already happening. > 2) Limit IPsec wg to only on the following IKE modifications : NAT > traversal, SCTP support and re-keying. The new IKE version > should be a minor > version including only minor fixes (as outlined in the new suggested > charter). > 3) Re-assure ourselves that the interface between transforms and key > management is clearly defined, and general enough to allow > for the addition > of new key management protocols, without having to change the > transforms. > 4) Have a framework protocol for key management - I think it > should be based > on ISAKMP. There is no need to re-invent transforms and > proposals syntax for > each new key management protocol. > 5) Have different requirements for different key management > protocols. With > one common requirement - they should all create IPsec SAs. > This way we could > have one requirements document include Identity protection, > and allow for a > larger number of messages, and another that has no Identity Protection > requirement, and requires a small number of message. We can > also have one or > several WGs in charge of the key management protocols. > > Sara. > From owner-ipsec@lists.tislabs.com Wed Aug 15 19:28:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2SRN22470; Wed, 15 Aug 2001 19:28:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11411 Wed, 15 Aug 2001 21:42:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <15226.45614.601672.408572@thomasm-u1.cisco.com> References: <15226.45614.601672.408572@thomasm-u1.cisco.com> Date: Wed, 15 Aug 2001 17:52:11 -0400 To: Michael Thomas From: Stephen Kent Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen t problems Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:32 AM -0700 8/15/01, Michael Thomas wrote: >Chris Trobridge writes: > > I think the problem is not specifically "global PKI" but "global trust > > infrastructure". > > Yes, my sloppy. > > > It would be useful if IKE could use different trust models, including > > delegation this to another protocol. > > > > However, I think in most cases, binding up your key to an IP address > > probably isn't that useful, due to ephemeral nature of IP addresses - my > > impression is that this just gets worse with IPv6. > > I agree, it not very optimal. It's quite possible that > I don't understand this very well, but do the two > use modes -- tunnel/transport -- really have the same > identity semantics? For tunnel mode, you are essentially > authenticating/authorizing an incoming interface to be > built on the security gateway. That is, a route is > established for a prefix. There really aren't any > possible consumers (normally, at least, unless you're > talking about a degenerate host-host tunnel). > I'm not as sure with transport mode. I guess I > view this as not so much affecting the routing > subsystem so much as affecting the IP datagrams > themselves; it may be implemented using the same > mechanisms as are used for tunnels, but I don't > think it *needs* to be thought of that way. In > fact, since transport is a host-host mode, it > sort of begs what the identity is used for at > all. I've brought up on the list before that > it would be nice to have the L3 credentials > available for higher layers when in transport > mode, (which I still think would be quite > useful), but I guess I don't know what the > transport identity is providing other than > a reliable way of saying, "yes, this is > mat@cisco.com". If there's not a policy module > which can take action based on that knowledge, > it seems like it's just providing a way to keep > outsiders out. Maybe this is a useful enough > service, but it seems sort of limited... > > > Mike Mike, Your understanding is not quite right. First, tunnel mode, while required for an SG, is also applicable to two hosts communicating. Second, IPsec supports authentication of symbolic names, not just IP addresses, which are dynamically bound to IP addresses for the duration of an SA. This is how we support connections from mobile users, for example. The access control model that underlies IPsec is that one uses some means of authenticating a peer, e.g., via binding a signature key to an ID, traceable to a trust anchor, and that the traffic sent from and sent to the authenticated peer is subject to access controls expressed in the SPD. These controls apply not only to allowed IP addresses to/from which traffic may flow, but also protocols and port fields. The motivation for these other selectors is the same as in firewalls, i.e., we can control access to services based on access to well know ports. Once the SA is established, we look at the IP source address(es) asserted by the peer to ensure that it does not try to spoof traffic from other peers with whom we are communicating (especially relevant at an SG). Steve From owner-ipsec@lists.tislabs.com Wed Aug 15 19:28:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2SVN22483; Wed, 15 Aug 2001 19:28:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11454 Wed, 15 Aug 2001 21:43:10 -0400 (EDT) Message-Id: <3.0.3.32.20010815184901.00e75050@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 15 Aug 2001 18:49:01 -0700 To: "Hallam-Baker, Phillip" , "'Stephen Kent'" , "Hallam-Baker, Phillip" From: Alex Alten Subject: RE: IKE must have no Heirs Cc: ipsec@lists.tislabs.com In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058696E8@vhqpostal.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ahh...this takes me back to my fading memories of the Secure SNMP War back in '96, i.e the SNMPv2 WG. :-} - Alex At 01:30 PM 8/15/2001 -0700, Hallam-Baker, Phillip wrote: >Steve, > > The fact that IPSEC has only gained widespread acceptance in the VPN >market and is not being employed for its intended purpose, the fact that >five years after the event the group is under an IESG injunction to get its >act together suggest to me that those who were immediately responsible for >the current situation should not be so openly contemptious and dismissive of >those who might have useful ideas on how to remedy the current situation. > > I do not much care for the history of the internal politics of any >IETF group, let alone the personal campaign stories of the combatants in the >IKE vs SKIP wars. Nor for that matter am I as you suggest 'fond of SKIP', >rather I have an aversion to a specification that introduces nine separate >protocols for performing a simple key exchange. > > Phill > > >Phillip Hallam-Baker FBCS C.Eng. >Principal Scientist >VeriSign Inc. >pbaker@verisign.com >781 245 6996 x227 > > >> -----Original Message----- >> From: Stephen Kent [mailto:kent@bbn.com] >> Sent: Wednesday, August 15, 2001 3:41 PM >> To: Hallam-Baker, Phillip >> Cc: ipsec@lists.tislabs.com >> Subject: RE: IKE must have no Heirs >> >> >> At 8:20 AM -0700 8/15/01, Hallam-Baker, Phillip wrote: >> > > SKIP was a poor choice for any long-lived SA, because SKIP forced >> >> every packet to carry SA state information in lieu of >> exchanging SA >> >> establishment messages. >> > >> >I see no reason why that specific problem could not have been fixed. >> >If you have a securely established shared secret that is >> securely bound >> >to a shared context there should be no per packet state requirement. >> >> Phil, >> >> You seem to be confusing the name of a protocol, and your apparent >> fondness for it, with the details that define that protocol. I don't >> recall your participation in IPsec WG activities during the time that >> the SKIP vs. IKE war took place, so perhaps your understanding of the >> history here is not so precise. >> >> Steve >> > > >Attachment Converted: "d:\eudora\attach\Phillip Hallam-Baker (E-mail)15.vcf" > -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Wed Aug 15 19:28:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2SWN22485; Wed, 15 Aug 2001 19:28:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11442 Wed, 15 Aug 2001 21:42:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 15 Aug 2001 18:36:32 -0400 To: Chris Trobridge From: Stephen Kent Subject: RE: Simplifying IKE Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:55 PM +0100 8/15/01, Chris Trobridge wrote: >I think the extreme position is that what IPSEC does best is: > >i) Establishing keys between two known entities (IKE). >ii) Allowing those entities to pass datagram payloads securely between them >by providing encryption, authentication and anti-replay defenses. > >It also provides some tunnelling (VPN) and firewall services that are >inferior to the free-standing implementations. IPSEC does not facilitate >resilient routing and you're still likely to need a firewall in addition to >IPSEC. we disagree. firewalls typically make access control decisions based on unauthenticated data from packet headers. IPsec makes these decisions based on authenticated identities and mutually enforced constraints on these packet headers. in that regard, the access control services are far superior to what is provided by freestanding firewalls. >People have suggested and, I think, implemented stacks where the IPSEC >tunnels are treated as interfaces and hence can be accomodated by routing >protocols. This also allow a firewall (integrated in the same stack) to >make decisions based on the IPSEC tunnel. one might do this, and so long as the selector features mandated in 2401 are supported, this is a compliant IPsec implementation approach. > >This would allow the IPSEC, routing protocols and firewalls to concentrate >on what they do best. since we disagree on what each does best, we obviously don't agree on your conclusion of what constitutes an appropriate allocation of tasks :-) > >Of course, there would be still a problem of configuring all this securely. > >This has been discussed here before but, as usual, the discussion flared up >and died away without any sort of concensus. > >As an aside, is there a 'standard' way for an application to request a >specific IPSEC policy for its traffic? No. APIs for IPsec have not been standardized. Steve From owner-ipsec@lists.tislabs.com Wed Aug 15 19:28:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2SmN22510; Wed, 15 Aug 2001 19:28:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11448 Wed, 15 Aug 2001 21:42:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 15 Aug 2001 18:52:58 -0400 To: Henry Spencer From: Stephen Kent Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems Cc: ipsec@lists.tislabs.com, FreeS/WAN Design Issues Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry, I agree that the DNS is a reasonable place to store certs, although some DNS experts don't agree with this view. I also agree that a PKI that exactly mirrored the DNS would be a great feature. Unfortunately, this is not what you get from DNSSEC. DNSSEC tries to solve a different problem, and it avoids using cert formats, instead opting for key and sig records. Some of the problems that DNSSEC faces re widespread deployment are a direct result of the set of security services it attempts to provide, relative to DNS queries. Providing certs that bind DNS names to keys would not solve the same set of problems, but would be simpler. We disagree on the merits of opportunistic encryption. For most organizations, the primary threat is one of unauthorized access, not massive passive wiretapping of Internet traffic. Thus encrypting lost of traffic, without providing accompanying access controls, might cause more harm (in the access control dimension) than good, e.g., by making it harder to perform intrusion detection, trace attacks, etc. However, to the extent that FreeS/WAN tries to address a concern to a user community that has a different threat model, one that is more focused on big brother than on hackers, I don't argue with your approach. Steve From owner-ipsec@lists.tislabs.com Wed Aug 15 19:29:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2TCN22534; Wed, 15 Aug 2001 19:29:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11417 Wed, 15 Aug 2001 21:42:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 15 Aug 2001 18:02:09 -0400 To: "Lars Eggert" From: Stephen Kent Subject: RE: Simplifying IKE Cc: , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lars, If we let routing select an SA, vs. the other way around, it might seem that we run a new risk of having a routing algorithm push traffic over the wrong SA. To counter that we would unless we modify the IPsec processing to check for selector appropriateness after mapping traffic to an SA, rather than using selectors to pick the SA. That probably would not work well unless we adopt a de-correlated SPD model, since otherwise one would have to go back to the SPD to check "appropriateness" for each packet. However, I am planning to use that model for the next rev of 2401, so that might not be a problem. Steve From owner-ipsec@lists.tislabs.com Wed Aug 15 19:30:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2UXN22584; Wed, 15 Aug 2001 19:30:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11427 Wed, 15 Aug 2001 21:42:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <15226.35517.701351.186328@thomasm-u1.cisco.com> References: <3B79500C.1367FCD3@storm.ca> <200108141718.f7EHISo02668@kebe.east.sun.com> <15226.35517.701351.186328@thomasm-u1.cisco.com> Date: Wed, 15 Aug 2001 18:44:05 -0400 To: Michael Thomas From: Stephen Kent Subject: Re: Require AH? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:44 AM -0700 8/15/01, Michael Thomas wrote: >Dan McDonald writes: > > Some HW folks didn't think you could do AH in hardware. I've >heard other HW > > folks (but only after the fact) say that you can indeed do AH in hardware. > > I have great confidence that hardware guys can > do just about anything you set them out to do. > It's only the final transistor count that tells > you whether it is worth the effort. > > > ESP authentication was a knee-jerk reaction to Bellovin's analysis of > > 1825-1827. He stated the threats of unauthenticated CBC >encryption + replay > > problems. The knee-jerk reaction was to add both of these >properties to ESP, > > without first thinking that requiring a fixed AH with replay >protection could > > do the trick. > > Actually, what would make me most happy would be to > have a single IPsec extension header which does > *everything*. This helps on the code/message > compactness front, as well as simplifying the > number of SADB entries, different protocols > handling, header traversal, etc. It seems to me > that if we had modes like gzip-aes-cbc-sha1 for > ESP transforms, we could get rid of both AH and > IPCOMP. > > Mike This has been suggested before, and rejected. In large part AH is ugly because it tries to cover the IP header, but there are so many fields that cannot be covered. this makes processing slower than ESP auth only. tunnel mode of auth only ESP addresses essentially all of the IPv4 motivations for having AH. The only open question is what IPv6 requirements are met by AH and not by this mode. So, if we don't find a really good reason to retain AH, there is no good reason to create a new, different protocol to accommodate this combination of features. Also, this sort of new protocol would be more complex than either AH or ESP alone, which raises questions about whether we have achieved anything. One can argue that two protocols, each of which is relatively simple, are better than one protocol that is more complex. Steve From owner-ipsec@lists.tislabs.com Wed Aug 15 19:30:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2UgN22606; Wed, 15 Aug 2001 19:30:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11445 Wed, 15 Aug 2001 21:42:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 15 Aug 2001 21:47:16 -0400 To: Chris Trobridge From: Stephen Kent Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen t problems Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:11 PM +0100 8/15/01, Chris Trobridge wrote: >I think the problem is not specifically "global PKI" but "global trust >infrastructure". I think "trust" is largely an irrelevant term here. If one wants to identify hosts by DNS name, there is an established, strict hierarchy that we all rely on. It's authoritative. It's not a matter of trust. >It would be useful if IKE could use different trust models, including >delegation this to another protocol. IKE defines very little about what one does with its varied set of potential PKI technologies, so I don't think this is a relevant criticism. >However, I think in most cases, binding up your key to an IP address >probably isn't that useful, due to ephemeral nature of IP addresses - my >impression is that this just gets worse with IPv6.\ IP addresses are not the only choice of identifier that IKE (or IPsec) deals with, as I noted in another message. Also, IPv6 is hardly the primary focus of most folks today. So, for those folkks who argue the need to be responsive to current and near term customer needs, IPv4 should be the major focus for now. > >The important thing is that you can authenticate who your peer is - there's >no reason why this has to be bound up in an IP address - and that your >policy allows to communicate with them. > We agree; IPsec and IKE already allow that. But, it's not always enough to discuss authorization merely at the granularity of IP addresses, which is why we have other selectors in the SPD. Steve From owner-ipsec@lists.tislabs.com Wed Aug 15 19:32:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2VxN22652; Wed, 15 Aug 2001 19:31:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11441 Wed, 15 Aug 2001 21:42:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058696DE@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F4058696DE@vhqpostal.verisign.com> Date: Wed, 15 Aug 2001 21:40:57 -0400 To: "Hallam-Baker, Phillip" From: Stephen Kent Subject: Re: XKMS and NIH RE: Simplifying IKE Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Phill, >Steve, > > You entirely manage to miss the point. You agree that part of the >complexity of IPSEC is that it is required to interface to every PKI in the >universe for political reasons. Then you make the statesmanlike suggestion >that the world standardize on the specification of the working group you >have been chairing. It may well make good technical sense. Perhaps you would >like to lend your support to Neil Kinnock's proposal to make English the >sole administrative language of the European Union whil you are at it? There is a difference between by suggesting support for a set of IETF standards (the WG for which I do co-chair) vs. your promoting a VeriSign/Microsoft technology. Perhaps you find this difference too subtle, but I feel confident others on the list can make the distinction. We also disagree on the issue of complexity. IPsec is not required to interface to every PKI in the universe. (Anyway, until Vint gets the interplanetary Internet up and running, there's not much need for extra-global cross certification.) IKE makes syntactic accommodation for a variety of PKI technologies, but the syntactic provisions are just the starting point. IPsec lacks an RFC specifying the harder details of what it really means to support ANY PKI, which is part of why this is one of the least interoperable aspects of IKE implementations. I'm suggesting that we consider focusing on support of the one PKI syntax and semantics that most vendors who do support a PKI in IKE already have selected. This seems like a simplification consistent with the discussion we've been having. I also suggest that we generate an RFC that does fill in the blanks that have resulted in > As for 'advertising' the work product of another open standards >working group that is appropriate to a working group topic, has substantial >commitments from the major PKI vendors, major application vendors and major >customers - I will do it at every opportunity thank you very much, whether >the specification is one of my own invention or of somebody else. What other open standards group? W3C? As it's name suggests, it's more akin to an industry consortium than a standards organization. > It was the first time that I had raised XKMS on the IPSEC list. It >was not off topic, it was in fact entirely on topic. I don't think that the >majority of the IETF would agree that Not Invented Here is a good policy. >Plenty of IETF working groups make use of the work product of other working >groups outside the IETF, BEEP makes use of a W3C specification, PKIX makes >use of an ITU standard. We gave you an opportunity to discuss XKMS in PKIX and the response was not what I would call overwhelming. My guess is that you elected to bring XKMS to W3C because you saw an easier path there, among a group of players not know for extensive security or expertise. BTW, don't compare W3C with the ITU, a treaty organization; it's hardly analogous, and PKIX was chartered explicitly to profile the ITU X.509 work. > Perhaps you could elaborate the reasons why you do not consider XKMS >to be a suitable topic for consideration by IPSEC? > > XKMS is designed to allow simplification of client implementation of >PKI. The topic on the table is simplification of IPSEC. IPsec does not have clients. It is a peer-to-peer protocol. I recall, from your XKMS presentation, something of a client/server flavor, which would be appropriate for SSL, but not necessarily for IPsec. Phill, you have never been a contributor in the IPsec area. Your comments in recent messages illustrate ignorance of the history of WG activities on which you now choose to comment. I don't find that constructive. We're trying to simplify IKE. if you propose support for XKMS as yet another PKI technology, that hardly amounts to simplification. If you suggest it as a replacement for the other technologies, that would call for discarding the PKI support that most vendors (that support PKI in IKE) already implement, which also seems questionable unless you can argue that XKMS is better in all respects. Steve From owner-ipsec@lists.tislabs.com Wed Aug 15 19:45:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2j6N22929; Wed, 15 Aug 2001 19:45:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11545 Wed, 15 Aug 2001 22:03:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F4058696E8@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F4058696E8@vhqpostal.verisign.com> Date: Wed, 15 Aug 2001 22:10:18 -0400 To: "Hallam-Baker, Phillip" From: Stephen Kent Subject: RE: IKE must have no Heirs Cc: "Hallam-Baker, Phillip" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:30 PM -0700 8/15/01, Hallam-Baker, Phillip wrote: >Steve, > > The fact that IPSEC has only gained widespread acceptance in the VPN >market and is not being employed for its intended purpose, the fact that >five years after the event the group is under an IESG injunction to get its >act together suggest to me that those who were immediately responsible for >the current situation should not be so openly contemptious and dismissive of >those who might have useful ideas on how to remedy the current situation. > > I do not much care for the history of the internal politics of any >IETF group, let alone the personal campaign stories of the combatants in the >IKE vs SKIP wars. Nor for that matter am I as you suggest 'fond of SKIP', >rather I have an aversion to a specification that introduces nine separate >protocols for performing a simple key exchange. > > Phill > If you're not familiar with the history, or the details of the protocols in question, then perhaps you ought not offer comments suggesting otherwise. Your messages have the flavor of "you poor kerks in IPsec have made a mess of this, perhaps because I was not here to help. now I'm here to help." I have no trouble being both contemptous and dismissive in your case, because I have endured your "assistance" in PKIX for several years. There at least you had some inkling of what was going on, but none the less managed to produce little in the way of tangible results, i.e., RFCs, whole offering lots of comments. Here, where you have demonstrated even less understanding of the subject matter, it is not at all clear how much help you can render, other than promoting your pet technology. Clear enough Phill? Steve From owner-ipsec@lists.tislabs.com Wed Aug 15 19:48:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G2mdN22993; Wed, 15 Aug 2001 19:48:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11563 Wed, 15 Aug 2001 22:06:34 -0400 (EDT) Message-Id: <3.0.3.32.20010815191218.00e75050@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 15 Aug 2001 19:12:18 -0700 To: , "'Sara Bitan'" , From: Alex Alten Subject: RE: Traffic handling and key management "divide and coquer" In-Reply-To: <002b01c125e9$a0d89240$0109e982@andrewk3.ca.newbridge.com> References: <003901c1249d$86b1a8e0$0300000a@bilbo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:20 AM 8/16/2001 +0100, Andrew Krywaniuk wrote: ... >The IPsec WG has never been able to agree on requirements for anything. It >seems idealistic and naive to believe that we could start over with a brand >new KMP and acheive a different result. Like it or not, IKE was the >preordained result of a design by commitee,a political process. The >alternative to a committee process is a fascist process. Take your pick. I >personally don't like either committees or facism, but I'll take committees >any day of the week. ... There is an alternative to committes or facism, the NIST approach (as in the AES "beauty contest"). Let's lay out the requirements, then hold a "beauty contest", and finally vote in a winner. This way we aren't getting the "design by committee" effect that simply does not work for a security oriented protocol. If you don't believe me, look what has happened to PEM, SNMPSEC, now IKE, and possibly IPSEC itself. DNSSEC may be the only recent success, and that was probably due to the small group involved. Our IETF WG consensus process which works well when designing an insecure protocol standard doesn't work properly when designing a secure protocol standard, at least not with a large group of stongly opinionated engineers. Let's learn from our mistakes and try an approach that seems to work, the NIST one. - Alex -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Thu Aug 16 01:25:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G8PMN23628; Thu, 16 Aug 2001 01:25:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11996 Thu, 16 Aug 2001 03:28:08 -0400 (EDT) Message-ID: From: Chris Trobridge To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: RE: Simplifying IKE Date: Thu, 16 Aug 2001 08:35:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > > we disagree. firewalls typically make access control decisions based > on unauthenticated data from packet headers. IPsec makes these > decisions based on authenticated identities and mutually enforced > constraints on these packet headers. in that regard, the access > control services are far superior to what is provided by freestanding > firewalls. I was assuming you take all these things together. If tunnel SAs are treated as interfaces by the firewall then it can enforce the IPSEC constraints. > >As an aside, is there a 'standard' way for an application to > request a > >specific IPSEC policy for its traffic? > > No. APIs for IPsec have not been standardized. I think this might be one of the reasons why IPSEC hasn't taken off so widely. I wouldn't know how to create a socket with a particular IPSEC policy. SSL managed to fit much better into applications and is widely used - even if some of the fundamentals are not as strong (which also helped it...). Chris ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Thu Aug 16 01:25:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G8PSN23639; Thu, 16 Aug 2001 01:25:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11981 Thu, 16 Aug 2001 03:19:54 -0400 (EDT) Message-ID: From: Chris Trobridge To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen t problems Date: Thu, 16 Aug 2001 08:27:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Stephen Kent [mailto:kent@bbn.com] > At 6:11 PM +0100 8/15/01, Chris Trobridge wrote: > >I think the problem is not specifically "global PKI" but > "global trust > >infrastructure". > > I think "trust" is largely an irrelevant term here. If one wants to > identify hosts by DNS name, there is an established, strict hierarchy > that we all rely on. It's authoritative. It's not a matter of trust. I think we may arguing over language here - I still see this as a hierarchical system of trust. > >It would be useful if IKE could use different trust models, including > >delegation this to another protocol. > > IKE defines very little about what one does with its varied set of > potential PKI technologies, so I don't think this is a relevant > criticism. I may be guilty of confusing what I know is being done with IKE vs what it is capable of. Chris ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Thu Aug 16 04:59:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GBxPN08347; Thu, 16 Aug 2001 04:59:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12345 Thu, 16 Aug 2001 07:19:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.3.32.20010815191218.00e75050@mail> References: <003901c1249d$86b1a8e0$0300000a@bilbo> <3.0.3.32.20010815191218.00e75050@mail> Date: Thu, 16 Aug 2001 07:20:57 -0400 To: Alex Alten From: Stephen Kent Subject: RE: Traffic handling and key management "divide and coquer" Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:12 PM -0700 8/15/01, Alex Alten wrote: >At 01:20 AM 8/16/2001 +0100, Andrew Krywaniuk wrote: >... >>The IPsec WG has never been able to agree on requirements for anything. It >>seems idealistic and naive to believe that we could start over with a brand >>new KMP and acheive a different result. Like it or not, IKE was the >>preordained result of a design by commitee,a political process. The >>alternative to a committee process is a fascist process. Take your pick. I >>personally don't like either committees or facism, but I'll take committees >>any day of the week. >... > >There is an alternative to committes or facism, the NIST approach (as in the >AES "beauty contest"). Let's lay out the requirements, then hold a "beauty >contest", and finally vote in a winner. This way we aren't getting the >"design by committee" effect that simply does not work for a security >oriented protocol. > >If you don't believe me, look what has happened to PEM, SNMPSEC, now IKE, >and possibly IPSEC itself. DNSSEC may be the only recent success, and that >was probably due to the small group involved. Our IETF WG consensus process >which works well when designing an insecure protocol standard doesn't work >properly when designing a secure protocol standard, at least not with a >large group of stongly opinionated engineers. > >Let's learn from our mistakes and try an approach that seems to work, >the NIST one. > Just a couple of observations: NIST didn't have an open vote for AES. A small committee picked the winner. DNSSEC is not being successful by almost any measure. Steve From owner-ipsec@lists.tislabs.com Thu Aug 16 07:40:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GEeON14545; Thu, 16 Aug 2001 07:40:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12943 Thu, 16 Aug 2001 09:34:25 -0400 (EDT) To: Stephen Kent Cc: Henry Spencer , ipsec@lists.tislabs.com, FreeS/WAN Design Issues Subject: Re: [Design] Re: Wes Hardaker: opportunistic encryption deployment problems References: From: Derek Atkins Date: 16 Aug 2001 09:41:34 -0400 In-Reply-To: Stephen Kent's message of "Wed, 15 Aug 2001 18:52:58 -0400" Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > We disagree on the merits of opportunistic encryption. For most > organizations, the primary threat is one of unauthorized access, not > massive passive wiretapping of Internet traffic. Thus encrypting lost > of traffic, without providing accompanying access controls, might > cause more harm (in the access control dimension) than good, e.g., by > making it harder to perform intrusion detection, trace attacks, etc. > However, to the extent that FreeS/WAN tries to address a concern to a > user community that has a different threat model, one that is more > focused on big brother than on hackers, I don't argue with your > approach. This is certainly not MY memory from Cambridge '92, when the concept of IPsec was to provide encryption technology at the network layer for all connections on the Internet. A side effect of the goal was endpoint authentication. Adding access control came even later. > Steve -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Aug 16 08:54:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GFsvN22238; Thu, 16 Aug 2001 08:54:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13225 Thu, 16 Aug 2001 10:50:11 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696EE@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Stephen Kent'" , "Hallam-Baker, Phillip" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: RE: XKMS and NIH RE: Simplifying IKE Date: Thu, 16 Aug 2001 07:57:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C12663.B68F31A0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C12663.B68F31A0 Content-Type: text/plain; charset="iso-8859-1" > There is a difference between by suggesting support for a set of IETF > standards (the WG for which I do co-chair) vs. your promoting a > VeriSign/Microsoft technology. Perhaps you find this difference too > subtle, but I feel confident others on the list can make the > distinction. If you want to start flame wars I suggest that you try alt.flame. The fact is that many if not most successful IETF protocols were designed by a small group and then brought to the IETF for standardization and change control. XKMS simply follows that tried and tested method. It is an open standard and has been submitted to a highly respected standards body backed by the main PKI vendors and several major customers. The choice of W3C was determined by two factors, first XKMS is both built on and designed to extend XML technology specified by W3C, the second is that the consensus amongst the prospective members was that W3C was the preferred forum. I suggest that you bother to find out who is a prospective member of the XKMS group before commenting on their security expertise. Phill ------_=_NextPart_000_01C12663.B68F31A0 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C12663.B68F31A0-- From owner-ipsec@lists.tislabs.com Thu Aug 16 08:57:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GFvmN22809; Thu, 16 Aug 2001 08:57:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13268 Thu, 16 Aug 2001 11:10:12 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696EF@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Stephen Kent'" , "Hallam-Baker, Phillip" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Using XKMS to extend IPSEC PKI support and reduce complexity Date: Thu, 16 Aug 2001 08:16:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C12666.78177F10" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C12666.78177F10 Content-Type: text/plain; charset="iso-8859-1" [This is the substantive response for those who don't want to read my responses to Steve's trolls and ad-hominem, those that do can find them in my other post] > Phill, you have never been a contributor in the IPsec area. Your > comments in recent messages illustrate ignorance of the history of WG > activities on which you now choose to comment. I don't find that > constructive. We're trying to simplify IKE. if you propose support > for XKMS as yet another PKI technology, that hardly amounts to > simplification. If you suggest it as a replacement for the other > technologies, that would call for discarding the PKI support that > most vendors (that support PKI in IKE) already implement, which also > seems questionable unless you can argue that XKMS is better in all > respects. That is not the proposal I made. Suggesting that IPSEC rip out support for PGP and SPKI is a non- starter. The probability of reaching consensus on the point is nil. Even if there were the possibility of consensus I would not support such a proposal. XKMS provides a practical way to achieve two objectives, first to allow IPSEC to be used with the full politically correct set of PKI. Second and more important it means that vendors that currently support very limited X.509 PKI can advance to provide full PKI support without the significant increase in their code base and configuration complexity that would entail. At present IPSEC implementations are being used for the limited purpose of securing VPNs. Many do not support certificate chaining, I do not know of any that support the full PKIX stack. I do not believe that an expensive router has any business performing PKIX path math or public key cryptography. It is like using a Ferrari to deliver milk. Delegating key exchange to another box also makes sense. Phill ------_=_NextPart_000_01C12666.78177F10 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C12666.78177F10-- From owner-ipsec@lists.tislabs.com Thu Aug 16 09:46:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GGkIN24227; Thu, 16 Aug 2001 09:46:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13355 Thu, 16 Aug 2001 11:55:59 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15227.61087.646494.243710@thomasm-u1.cisco.com> Date: Thu, 16 Aug 2001 09:02:39 -0700 (PDT) To: Stephen Kent Cc: Michael Thomas