From owner-ietf-ipsra@mail.vpnc.org Thu Aug 2 22:24:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11967 for ; Thu, 2 Aug 2001 22:24:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f731gMj04101 for ietf-ipsra-bks; Thu, 2 Aug 2001 18:42:22 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f731USs03932; Thu, 2 Aug 2001 18:30:28 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f731Tv911913; Thu, 2 Aug 2001 21:29:58 -0400 (EDT) Received: from rftzy232.ca.nortel.com by zcars04e.ca.nortel.com; Thu, 2 Aug 2001 21:30:17 -0400 Received: from nortelnetworks.com (acart13a.ca.nortel.com [47.129.8.153]) by rftzy232.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NKPL6BZ0; Thu, 2 Aug 2001 21:29:59 -0400 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-Disposition: inline; filename="statement.txt" Content-Transfer-Encoding: 7bit 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-ietf-ipsra@mail.vpnc.org Fri Aug 3 10:22:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16678 for ; Fri, 3 Aug 2001 10:22:08 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f73DdAF15785 for ietf-ipsra-bks; Fri, 3 Aug 2001 06:39:10 -0700 (PDT) Received: from mail.storm.ca (storm.ca [209.87.239.69]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73DYis15703; Fri, 3 Aug 2001 06:34:44 -0700 (PDT) Received: from storm.ca (ppp-209-87-255-11.ottawa.storm.ca [209.87.255.11]) by mail.storm.ca (8.10.2+Sun/8.10.2) with ESMTP id f73DY3r29790; Fri, 3 Aug 2001 09:34:04 -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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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-ietf-ipsra@mail.vpnc.org Fri Aug 3 11:04:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17613 for ; Fri, 3 Aug 2001 11:04:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73EMYF16462 for ietf-ipsra-bks; Fri, 3 Aug 2001 07:22:34 -0700 (PDT) Received: from spsystems.net (spsystems.net [209.47.149.227]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73EMXs16455; Fri, 3 Aug 2001 07:22:33 -0700 (PDT) Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id KAA12706; Fri, 3 Aug 2001 10:21:49 -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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Fri Aug 3 15:38:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25165 for ; Fri, 3 Aug 2001 15:38:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73IlMq27189 for ietf-ipsra-bks; Fri, 3 Aug 2001 11:47:22 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73IlKs27185; Fri, 3 Aug 2001 11:47:20 -0700 (PDT) Received: from bcn.East.Sun.COM ([129.148.75.4]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21270; Fri, 3 Aug 2001 11:47:18 -0700 (PDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA06613; Fri, 3 Aug 2001 14:47:16 -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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Fri Aug 3 15:40:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25266 for ; Fri, 3 Aug 2001 15:40:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73J0TB27546 for ietf-ipsra-bks; Fri, 3 Aug 2001 12:00:29 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73Iwss27505; Fri, 3 Aug 2001 11:58:54 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25769; Fri, 3 Aug 2001 11:58:23 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07856; Fri, 3 Aug 2001 14:58:20 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f73IviJ20038; Fri, 3 Aug 2001 14:57:44 -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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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-ietf-ipsra@mail.vpnc.org Fri Aug 3 16:24:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27670 for ; Fri, 3 Aug 2001 16:24:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73JTnP28115 for ietf-ipsra-bks; Fri, 3 Aug 2001 12:29:49 -0700 (PDT) Received: from spsystems.net (spsystems.net [209.47.149.227]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73JTks28110; Fri, 3 Aug 2001 12:29:48 -0700 (PDT) Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id PAA17040; Fri, 3 Aug 2001 15:29:10 -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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Fri Aug 3 16:31:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28519 for ; Fri, 3 Aug 2001 16:31:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73JgbG28716 for ietf-ipsra-bks; Fri, 3 Aug 2001 12:42:37 -0700 (PDT) Received: from spsystems.net (spsystems.net [209.47.149.227]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73JgZs28712; Fri, 3 Aug 2001 12:42:35 -0700 (PDT) Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id PAA17233; Fri, 3 Aug 2001 15:41:57 -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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Fri Aug 3 17:30:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29579 for ; Fri, 3 Aug 2001 17:30:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73Kfxx02868 for ietf-ipsra-bks; Fri, 3 Aug 2001 13:41:59 -0700 (PDT) Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73KbTs02787; Fri, 3 Aug 2001 13:37:29 -0700 (PDT) Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA02548; Fri, 3 Aug 2001 13:40:23 -0700 (PDT) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2654.89) id ; Fri, 3 Aug 2001 13:37:18 -0700 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Fri Aug 3 18:13:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29972 for ; Fri, 3 Aug 2001 18:13:05 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f73LIpr04038 for ietf-ipsra-bks; Fri, 3 Aug 2001 14:18:51 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73LIns04033; Fri, 3 Aug 2001 14:18:49 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id RAA14976; Fri, 3 Aug 2001 17:18:11 -0400 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Fri Aug 3 18:29:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00113 for ; Fri, 3 Aug 2001 18:29:22 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f73LmNp05478 for ietf-ipsra-bks; Fri, 3 Aug 2001 14:48:23 -0700 (PDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73Ljns05323; Fri, 3 Aug 2001 14:45:49 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25361; Fri, 3 Aug 2001 15:45:40 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09432; Fri, 3 Aug 2001 17:45:41 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f73Lj5J21336; Fri, 3 Aug 2001 17:45:05 -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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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-ietf-ipsra@mail.vpnc.org Fri Aug 3 21:51:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03221 for ; Fri, 3 Aug 2001 21:51:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7413R308701 for ietf-ipsra-bks; Fri, 3 Aug 2001 18:03:27 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7413Ns08697; Fri, 3 Aug 2001 18:03:25 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 22B714B21; Sat, 4 Aug 2001 10:03:20 +0900 (JST) 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (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-ietf-ipsra@mail.vpnc.org Sat Aug 4 02:55:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22932 for ; Sat, 4 Aug 2001 02:55:52 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f746ITK16984 for ietf-ipsra-bks; Fri, 3 Aug 2001 23:18:29 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f746ISs16974 for ; Fri, 3 Aug 2001 23:18:28 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA95692 for ; Fri, 3 Aug 2001 23:08:37 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 3 Aug 2001 23:08:37 -0700 (PDT) From: Bernard Aboba To: ietf-ipsra@vpnc.org Subject: RE: Position statement on IKE development Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I have a different set of concerns, IPSEC is not being used in cases where > it should have been the answer. It is ironic that the major use of IPsec is in VPNs, yet IKE is poorly designed for that use -- it cannot go through NATs, does not support remote access authentication well, etc. Perhaps we will see wider transport mode deployment over time, but as it stands, almost all IPsec deployments are based on non-standard technology, since proprietary additions are required to meet customer requirements. I fully expect the proprietization of IPsec to continue, and in fact, accelerate going forward. > In particular the IEEE 802.11b WEP fiasco could have been averted if the > designers had not been discouraged by the complexity of IPSEC. IEEE 802.11 access points are layer 2 devices that go for as little as $200, powered by processors as insubstantial as 25 Mhz 680x0. Such processors are not capable of handling 3DES at 11 Mbps line rate. So I doubt that IKE/IPsec complexity was much of a factor -- after all, IKE implementations can fit in as little as 200 KB. > Another issue is why can't I buy a printer that is IPSEC enabled? Or SSL/TLS enabled for that matter? I doubt that IKE/IPsec complexity has much to do with this -- such an application might do fine with just shared secret authentication. With much of the cert handling code removed, IKE/IPsec is quite compact. So I think that the problem must reside elsewhere -- such as in the perceived difficulty in configuring such secure devices in the absence of keypads or other input mechanisms. From owner-ietf-ipsra@mail.vpnc.org Sat Aug 4 02:56:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22944 for ; Sat, 4 Aug 2001 02:56:09 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f746C7M15326 for ietf-ipsra-bks; Fri, 3 Aug 2001 23:12:07 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f746C6s15322 for ; Fri, 3 Aug 2001 23:12:06 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA95676; Fri, 3 Aug 2001 23:01:44 -0700 (PDT) (envelope-from aboba@internaut.com) 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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-ietf-ipsra@mail.vpnc.org Sat Aug 4 04:41:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23821 for ; Sat, 4 Aug 2001 04:41:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7480xc01010 for ietf-ipsra-bks; Sat, 4 Aug 2001 01:00:59 -0700 (PDT) Received: from perfero.tnc.virtela.cc ([12.41.66.116]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7480ws01006 for ; Sat, 4 Aug 2001 01:00:58 -0700 (PDT) Received: from posthaus.virtela.cc ([172.16.97.7]) by perfero.tnc.virtela.cc (8.9.3/8.9.3) with ESMTP id AAA07156; Sat, 4 Aug 2001 00:55:48 -0700 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2653.19) id ; Sat, 4 Aug 2001 01:55:49 -0600 Message-ID: From: "Horn, Mike" To: "'Bernard Aboba'" , ietf-ipsra@vpnc.org Subject: RE: Position statement on IKE development Date: Sat, 4 Aug 2001 01:55:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have been saying this for a while to no avail. It seems that the ipsra WG is stuck trying to solve a set of requirements (NAT traversal, keepalives, legacy authentication, etc.) using the current IKE/IPsec architectures which are poorly designed to meet these requirements. I too believe that IKE/IPsec based VPN solutions will continue to be based on proprietary implementations. This is troubling from a VPN service provider perspective, since it limits the mix of vendors that can be used to provide solutions, and it slows the overall market adoption of VPN technology. I'm not sure what the right answer is to solve this problem, but it seems many vendors have solved it by implementing semi-proprietary solutions, like XAUTH/CFGMODE, and then performing interoperability testing at various bakeoffs. Mike Horn > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Saturday, August 04, 2001 12:09 AM > To: ietf-ipsra@vpnc.org > Subject: RE: Position statement on IKE development > > > > > I have a different set of concerns, IPSEC is not being used > in cases where > > it should have been the answer. > > It is ironic that the major use of IPsec is in VPNs, yet IKE is poorly > designed for that use -- it cannot go through NATs, does not support > remote access authentication well, etc. Perhaps we will see wider > transport mode deployment over time, but as it stands, almost > all IPsec > deployments are based on non-standard technology, since proprietary > additions are required to meet customer requirements. I fully > expect the > proprietization of IPsec to continue, and in fact, accelerate going > forward. > > > In particular the IEEE 802.11b WEP fiasco could have been > averted if the > > designers had not been discouraged by the complexity of IPSEC. > > IEEE 802.11 access points are layer 2 devices that go for as > little as $200, powered by processors as insubstantial as 25 Mhz > 680x0. Such processors are not capable of handling 3DES at 11 > Mbps line > rate. So I doubt that IKE/IPsec complexity was much of a > factor -- after > all, IKE implementations can fit in as little as 200 KB. > > > Another issue is why can't I buy a printer that is IPSEC enabled? > > Or SSL/TLS enabled for that matter? I doubt that IKE/IPsec > complexity has > much to do with this -- such an application might do fine > with just shared > secret authentication. With much of the cert handling code removed, > IKE/IPsec is quite compact. So I think that the problem must > reside elsewhere -- such as in the perceived difficulty in configuring > such secure devices in the absence of keypads or other input > mechanisms. > > From owner-ietf-ipsra@mail.vpnc.org Sat Aug 4 04:45:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23857 for ; Sat, 4 Aug 2001 04:45:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f748BHX01792 for ietf-ipsra-bks; Sat, 4 Aug 2001 01:11:17 -0700 (PDT) Received: from perfero.tnc.virtela.cc ([12.41.66.116]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f748BFs01786 for ; Sat, 4 Aug 2001 01:11:15 -0700 (PDT) Received: from posthaus.virtela.cc ([172.16.97.7]) by perfero.tnc.virtela.cc (8.9.3/8.9.3) with ESMTP id BAA07546; Sat, 4 Aug 2001 01:09:17 -0700 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2653.19) id ; Sat, 4 Aug 2001 02:09:17 -0600 Message-ID: From: "Horn, Mike" To: "'Dan Harkins'" , Henry Spencer Cc: ietf-ipsra@vpnc.org Subject: RE: Position statement on IKE development Date: Sat, 4 Aug 2001 02:09: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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan, Is there any plan to make son-of-ike extensible for things like legacy user authentication, keepalives, etc? Or will it just simplify the existing solution? Without adding this new functionality, I think that IKE will still fall short of what user expectations are. Mike > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Friday, August 03, 2001 4:35 PM > To: Henry Spencer > Cc: IP Security List; ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org > Subject: Re: Position statement on IKE development > > > 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-ietf-ipsra@mail.vpnc.org Sat Aug 4 09:59:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26338 for ; Sat, 4 Aug 2001 09:59:00 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f74DDF815827 for ietf-ipsra-bks; Sat, 4 Aug 2001 06:13:15 -0700 (PDT) Received: from berkshire.research.att.com (cust-P5-R2-242.POOL.ESR.CLW.wwc.com [168.151.1.242]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74DDAs15823; Sat, 4 Aug 2001 06:13:11 -0700 (PDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id B07AF7B5B; Sat, 4 Aug 2001 09:12:51 -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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Sat Aug 4 15:20:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00151 for ; Sat, 4 Aug 2001 15:20:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f74IXhR25235 for ietf-ipsra-bks; Sat, 4 Aug 2001 11:33:43 -0700 (PDT) Received: from tailor.sailpix.com (ns1.sailpix.com [155.53.1.250]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74IXgs25231 for ; Sat, 4 Aug 2001 11:33:42 -0700 (PDT) Received: from atty.lounge.org (tycho-205-179-127-183.tychonet.com [205.179.127.183]) by tailor.sailpix.com (Postfix) with ESMTP id 7021254C54; Sat, 4 Aug 2001 11:33:44 -0700 (PDT) Received: from lounge.org (localhost [127.0.0.1]) by dharkins@lounge.orgatty.lounge.org (8.11.0/8.11.0) with ESMTP id f74IWgI00588; Sat, 4 Aug 2001 11:32:49 -0700 (PDT) (envelope-from dharkins@lounge.org) Message-Id: <200108041832.f74IWgI00588@dharkins@lounge.orgatty.lounge.org> To: "Horn, Mike" Cc: ietf-ipsra@vpnc.org Subject: Re: Position statement on IKE development In-Reply-To: Your message of "Sat, 04 Aug 2001 02:09:08 MDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <585.996949962.1@lounge.org> Date: Sat, 04 Aug 2001 11:32:42 -0700 From: Dan Harkins Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It's not going to be any less extensible than it already is but unless there is a massive change of heart by our ADs it will not include legacy user authentication or keepalives or any of the other things that we all think users expect. If you remember, the Position Statement said: "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." I think if you ask Marcus or Jeff they would say that legacy user authentication and keepalives fall into the "second system effect" class of feature. If you also re-read the Position Statement you'll note that the moratorium is temporary until the process of cleaning and simplifying is done. I believe we can revisit things like legacy user authentication when the moratorium is lifted. Dan. On Sat, 04 Aug 2001 02:09:08 MDT you wrote > Dan, > > Is there any plan to make son-of-ike extensible for things like legacy user > authentication, keepalives, etc? Or will it just simplify the existing > solution? Without adding this new functionality, I think that IKE will > still fall short of what user expectations are. > > Mike > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@lounge.org] > > Sent: Friday, August 03, 2001 4:35 PM > > To: Henry Spencer > > Cc: IP Security List; ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org > > Subject: Re: Position statement on IKE development > > > > > > 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-ietf-ipsra@mail.vpnc.org Sat Aug 4 18:27:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01800 for ; Sat, 4 Aug 2001 18:27:57 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f74Lhgn26904 for ietf-ipsra-bks; Sat, 4 Aug 2001 14:43:42 -0700 (PDT) Received: from femail39.sdc1.sfba.home.com (femail39.sdc1.sfba.home.com [24.254.60.33]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74Lhfs26900; Sat, 4 Aug 2001 14:43:41 -0700 (PDT) Received: from c1286160-a ([65.0.174.146]) by femail39.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010804214339.NEBZ2644.femail39.sdc1.sfba.home.com@c1286160-a>; Sat, 4 Aug 2001 14:43:39 -0700 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Sat Aug 4 19:44:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02468 for ; Sat, 4 Aug 2001 19:44:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f74N0ar28626 for ietf-ipsra-bks; Sat, 4 Aug 2001 16:00:36 -0700 (PDT) Received: from berkshire.research.att.com (host217-33-136-177.ietf.ignite.net [217.33.136.177]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74N0Xs28622; Sat, 4 Aug 2001 16:00:34 -0700 (PDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id A59117B5B; Sun, 5 Aug 2001 00:00:25 +0100 (BST) 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Sun Aug 5 08:47:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13497 for ; Sun, 5 Aug 2001 08:47:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f75Bo1205812 for ietf-ipsra-bks; Sun, 5 Aug 2001 04:50:01 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f75Bo0s05808; Sun, 5 Aug 2001 04:50:00 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f75BnOg16602; Sun, 5 Aug 2001 04:49:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABR02404; Sun, 5 Aug 2001 04:49:19 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA14283; Sun, 5 Aug 2001 04:49:19 -0700 (PDT) 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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-ietf-ipsra@mail.vpnc.org Sun Aug 5 09:33:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13912 for ; Sun, 5 Aug 2001 09:33:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f75BecK05720 for ietf-ipsra-bks; Sun, 5 Aug 2001 04:40:38 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f75Bebs05716; Sun, 5 Aug 2001 04:40:37 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f75BeBY17122; Sun, 5 Aug 2001 04:40:11 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABR02396; Sun, 5 Aug 2001 04:39:54 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA14280; Sun, 5 Aug 2001 04:39:54 -0700 (PDT) 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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-ietf-ipsra@mail.vpnc.org Sun Aug 5 15:57:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19919 for ; Sun, 5 Aug 2001 15:57:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f75J1cK15634 for ietf-ipsra-bks; Sun, 5 Aug 2001 12:01:38 -0700 (PDT) Received: from femail25.sdc1.sfba.home.com (femail25.sdc1.sfba.home.com [24.254.60.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f75J1Xs15630; Sun, 5 Aug 2001 12:01:33 -0700 (PDT) Received: from c1286160-a ([65.0.174.146]) by femail25.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010805190131.PVJR18714.femail25.sdc1.sfba.home.com@c1286160-a>; Sun, 5 Aug 2001 12:01:31 -0700 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Mon Aug 6 05:36:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20390 for ; Mon, 6 Aug 2001 05:36:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f767RlY09489 for ietf-ipsra-bks; Mon, 6 Aug 2001 00:27:47 -0700 (PDT) Received: from tailor.sailpix.com (ns1.sailpix.com [155.53.1.250]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f767Rks09481; Mon, 6 Aug 2001 00:27:46 -0700 (PDT) Received: from atty.lounge.org (tycho-205-179-127-183.tychonet.com [205.179.127.183]) by tailor.sailpix.com (Postfix) with ESMTP id 6A64754C7A; Mon, 6 Aug 2001 00:27:35 -0700 (PDT) Received: from lounge.org (localhost [127.0.0.1]) by dharkins@lounge.orgatty.lounge.org (8.11.0/8.11.0) with ESMTP id f767Qas00663; Mon, 6 Aug 2001 00:26:38 -0700 (PDT) (envelope-from dharkins@lounge.org) 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Mon Aug 6 08:47:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22337 for ; Mon, 6 Aug 2001 08:47:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76B7nx28457 for ietf-ipsra-bks; Mon, 6 Aug 2001 04:07:49 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76B7mN28449; Mon, 6 Aug 2001 04:07:48 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f76B7lg15760; Mon, 6 Aug 2001 04:07:47 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABS01737; Mon, 6 Aug 2001 04:07:43 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA14658; Mon, 6 Aug 2001 04:07:43 -0700 (PDT) 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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-ietf-ipsra@mail.vpnc.org Mon Aug 6 13:01:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27625 for ; Mon, 6 Aug 2001 13:01:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76FgYY09810 for ietf-ipsra-bks; Mon, 6 Aug 2001 08:42:34 -0700 (PDT) Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76FXVN08291; Mon, 6 Aug 2001 08:33:31 -0700 (PDT) Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA24898; Mon, 6 Aug 2001 08:36:08 -0700 (PDT) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2654.89) id ; Mon, 6 Aug 2001 08:33:04 -0700 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Mon Aug 6 14:55:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29484 for ; Mon, 6 Aug 2001 14:55:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76HpaR14809 for ietf-ipsra-bks; Mon, 6 Aug 2001 10:51:36 -0700 (PDT) Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76HeqN14584; Mon, 6 Aug 2001 10:40:52 -0700 (PDT) Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA23608; Mon, 6 Aug 2001 10:42:57 -0700 (PDT) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2653.19) id <36LRCK1D>; Mon, 6 Aug 2001 10:39:53 -0700 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Mon Aug 6 16:17:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00816 for ; Mon, 6 Aug 2001 16:17:30 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f76JTmE16583 for ietf-ipsra-bks; Mon, 6 Aug 2001 12:29:48 -0700 (PDT) Received: from relay2.nai.com (relay2.nai.com [161.69.3.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76JTlN16579 for ; Mon, 6 Aug 2001 12:29:47 -0700 (PDT) Received: from scwsout1.nai.com (undef-3-73.nai.com [161.69.3.73] (may be forged)) by relay2.nai.com (8.9.3/8.9.3) with SMTP id OAA08248 for ; Mon, 6 Aug 2001 14:29:44 -0500 (CDT) Received: FROM ca-ex-bridge2.nai.com BY scwsout1.nai.com ; Mon Aug 06 12:29:26 2001 -0700 Received: by SNC-5-31.nai.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 12:29:46 -0700 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is it true that the NAT traversal IKE and IPsec changes have been exempted from the moratorium? -dave From owner-ietf-ipsra@mail.vpnc.org Mon Aug 6 16:21:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00971 for ; Mon, 6 Aug 2001 16:21:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76JdQI16773 for ietf-ipsra-bks; Mon, 6 Aug 2001 12:39:26 -0700 (PDT) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76JdON16769 for ; Mon, 6 Aug 2001 12:39:24 -0700 (PDT) Received: from pgp.com (sncgw.nai.com [161.69.248.229]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GHNVID00.KO0; Mon, 6 Aug 2001 12:30:13 -0700 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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-ietf-ipsra@mail.vpnc.org Mon Aug 6 20:59:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04974 for ; Mon, 6 Aug 2001 20:59:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7704W520676 for ietf-ipsra-bks; Mon, 6 Aug 2001 17:04:32 -0700 (PDT) Received: from perfero.tnc.virtela.cc ([12.41.66.116]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7704UN20670 for ; Mon, 6 Aug 2001 17:04:30 -0700 (PDT) Received: from posthaus.virtela.cc ([172.16.97.7]) by perfero.tnc.virtela.cc (8.9.3/8.9.3) with ESMTP id RAA19234; Mon, 6 Aug 2001 17:03:09 -0700 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 18:03:09 -0600 Message-ID: From: "Horn, Mike" To: "'Theodore Tso'" , Andrew Krywaniuk Cc: "'Alex Alten'" , "'Marcus Leech'" , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: RE: Position statement on IKE development Date: Mon, 6 Aug 2001 18:03: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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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. Can Marcus or Jeff confirm that this is true? If it is true, would NAT/Firewall traversal and SCTP support be amended to the existing IKE framework, or would it be included in a simplified "improvements to IKE" draft? It seems the WG has the contradictory requirement to both simplify and add new features to IKE concurrently. It would be helpful if the IPSEC WG produced a timeline and a plan for what the next steps should be. > 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"). 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. If the IKE specification had a secure, extensible mechanism for adding new features like user authentication and keepalives, then the IPSRA WG would have probably made more progress by now. > 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 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. Mike Horn From owner-ietf-ipsra@mail.vpnc.org Tue Aug 7 00:52:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09552 for ; Tue, 7 Aug 2001 00:52:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7741UE23838 for ietf-ipsra-bks; Mon, 6 Aug 2001 21:01:30 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7741SN23834 for ; Mon, 6 Aug 2001 21:01:28 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02256; Mon, 6 Aug 2001 17:41:38 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA22209; Mon, 6 Aug 2001 20:41:38 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f770f1J23253; Mon, 6 Aug 2001 20:41:01 -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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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-ietf-ipsra@mail.vpnc.org Tue Aug 7 09:10:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02966 for ; Tue, 7 Aug 2001 09:10:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77CPLT01241 for ietf-ipsra-bks; Tue, 7 Aug 2001 05:25:21 -0700 (PDT) Received: from rcn.ihtfp.org (me@host217-33-137-52.ietf.ignite.net [217.33.137.52]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77CPIN01236 for ; Tue, 7 Aug 2001 05:25:18 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id IAA02073; Tue, 7 Aug 2001 08:25:03 -0400 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Tue Aug 7 10:40:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05100 for ; Tue, 7 Aug 2001 10:40:32 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f77DqHL02968 for ietf-ipsra-bks; Tue, 7 Aug 2001 06:52:17 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DqGN02963 for ; Tue, 7 Aug 2001 06:52:16 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA02955; Tue, 7 Aug 2001 06:37:59 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 7 Aug 2001 06:37:59 -0700 (PDT) From: Bernard Aboba To: Bill Sommerfeld cc: "'Marcus Leech'" , ietf-ipsra@vpnc.org Subject: Re: Position statement on IKE development In-Reply-To: <200108070041.f770f1J23253@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The IPSRA WG is not at all dependant on IKE; it's really all about > protocols to turn legacy authentication into certificates.. Unfortunately, in talking to customers, it is difficult to explain why this makes sense. Some sample questions: 1. "Doesn't this require me to install root certs on all the clients, just as if I were moving to PKI?" 2. "Doesn't this require me to install a CA, just as if I were moving to PKI?" 3. "Is my certificate infrastructure able to handle certs of such short duration?" 4. "I've already deployed . Why should I also need to deploy certificate infrastructure?" 5. "Doesn't this assume that my IPsec implementation supports user authentication?" From owner-ietf-ipsra@mail.vpnc.org Tue Aug 7 13:10:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08491 for ; Tue, 7 Aug 2001 13:10:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77G8h503703 for ietf-ipsra-bks; Tue, 7 Aug 2001 09:08:43 -0700 (PDT) Received: from perfero.tnc.virtela.cc ([12.41.66.116]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77G8fN03698 for ; Tue, 7 Aug 2001 09:08:41 -0700 (PDT) Received: from posthaus.virtela.cc ([172.16.97.7]) by perfero.tnc.virtela.cc (8.9.3/8.9.3) with ESMTP id JAA21721; Tue, 7 Aug 2001 09:06:50 -0700 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 10:06:50 -0600 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Tue Aug 7 13:10:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08502 for ; Tue, 7 Aug 2001 13:10:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77GMUg04182 for ietf-ipsra-bks; Tue, 7 Aug 2001 09:22:30 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77GMSN04178 for ; Tue, 7 Aug 2001 09:22:28 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 09:23:25 -0700 Received: from redcreek.com (209.125.38.124 [209.125.38.124]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDY56Q7W; Tue, 7 Aug 2001 09:23:19 -0700 From: "Scott G. Kelly" To: Bernard Aboba Cc: Bill Sommerfeld , "'Marcus Leech'" , ietf-ipsra@vpnc.org Message-ID: <3B7015F0.17C5DC21@redcreek.com> Date: Tue, 07 Aug 2001 09:23:12 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Position statement on IKE development References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Bernard, Bernard Aboba wrote: > > > The IPSRA WG is not at all dependant on IKE; it's really all about > > protocols to turn legacy authentication into certificates.. > > Unfortunately, in talking to customers, it is difficult to explain why > this makes sense. Some sample questions: > > 1. "Doesn't this require me to install root certs on all the clients, just > as if I were moving to PKI?" All clients are required to have root certs (or access to some equivalent verification mechanism) if they are to use anything other than preshared keys for phase 1 authentication anyway. Since preshared keys will not securely scale, there really is no way around this, is there? > 2. "Doesn't this require me to install a CA, just as if I were moving to > PKI?" > > 3. "Is my certificate infrastructure able to handle certs of such short > duration?" The requirement, assuming very short-lived certs, is for a simple RA/CA application which generates the certs, and for the gateway to have access to a verification cert. In the best (most secure case), this "CA" will likely be standalone, but in many cases, I'll bet this "CA" will be transparently added to the security gateway itself. If the certs are sufficiently short-lived (with a lifetime of, say, less than the width of your typical CRL window), the sgw only needs to have a verification cert, i.e. no additional verification infrastructure is needed. This can be made quite simple from the customer's perspective. > 4. "I've already deployed . Why should I also need > to deploy certificate infrastructure?" See above... > 5. "Doesn't this assume that my IPsec implementation supports user > authentication?" I don't understand what you are asking here - we are providing a user authentication mechanism for ipsec remote access here, right? Scott From owner-ietf-ipsra@mail.vpnc.org Tue Aug 7 13:55:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09515 for ; Tue, 7 Aug 2001 13:55:24 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f77H97g05215 for ietf-ipsra-bks; Tue, 7 Aug 2001 10:09:07 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77H96N05211 for ; Tue, 7 Aug 2001 10:09:06 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA03272; Tue, 7 Aug 2001 09:58:40 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 7 Aug 2001 09:58:40 -0700 (PDT) From: Bernard Aboba To: "Scott G. Kelly" cc: Bill Sommerfeld , "'Marcus Leech'" , ietf-ipsra@vpnc.org Subject: Re: Position statement on IKE development In-Reply-To: <3B7015F0.17C5DC21@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > 1. "Doesn't this require me to install root certs on all the clients, just > > as if I were moving to PKI?" > > All clients are required to have root certs (or access to some > equivalent verification mechanism) if they are to use anything other > than preshared keys for phase 1 authentication anyway. Since preshared > keys will not securely scale, there really is no way around this, is > there? > Customers who are not wishing to deploy PKI usually avoid it because of the associated management issues. So requiring them to do many of the same things as would have been required for PKI deployment generates resistance. Most customers I talk to have the expectation that they can deploy VPN scalably without any cert infrastructure at all, either with password or token-card based authentication. > > 3. "Is my certificate infrastructure able to handle certs of such short > > duration?" > > The requirement, assuming very short-lived certs, is for a simple RA/CA > application which generates the certs, and for the gateway to have > access to a verification cert. In the best (most secure case), this "CA" > will likely be standalone, but in many cases, I'll bet this "CA" will be > transparently added to the security gateway itself. If the certs are > sufficiently short-lived (with a lifetime of, say, less than the width > of your typical CRL window), the sgw only needs to have a verification > cert, i.e. no additional verification infrastructure is needed. This can > be made quite simple from the customer's perspective. > Yes, I'd agree that an integrated CA will be much easier for those customers to live with. However, wouldn't they then need to do a "forklift" upgrade to transition to full PKI? If so, there wouldn't be much transition benefit. > > 4. "I've already deployed . Why should I also need > > to deploy certificate infrastructure?" > In terms of market acceptance, token cards are considerably further along than certificates. Many customers already have these token cards in place, and expect to be able to use them without adding another layer of infrastructure and configuration. > > > 5. "Doesn't this assume that my IPsec implementation supports user > > authentication?" > > I don't understand what you are asking here - we are providing a user > authentication mechanism for ipsec remote access here, right? > Presumably, the cert that is being given out is a user certificate -- and therefore there is the expection that the IPsec implementation will support user authentication -- which very few existing implementations do. Or are we authenticating a user identity -- but actually doing machine authentication within IPsec? From owner-ietf-ipsra@mail.vpnc.org Tue Aug 7 15:19:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11389 for ; Tue, 7 Aug 2001 15:19:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77Ibs507248 for ietf-ipsra-bks; Tue, 7 Aug 2001 11:37:54 -0700 (PDT) Received: from traveller.amante.org (dsl081-098-227.den1.dsl.speakeasy.net [64.81.98.227]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77IbqN07243 for ; Tue, 7 Aug 2001 11:37:53 -0700 (PDT) Received: by traveller.amante.org (Postfix, from userid 100) id 4D9855004; Tue, 7 Aug 2001 12:49:05 -0600 (MDT) 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Tue Aug 7 15:52:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11833 for ; Tue, 7 Aug 2001 15:52:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77J7Zd07730 for ietf-ipsra-bks; Tue, 7 Aug 2001 12:07:35 -0700 (PDT) Received: from perfero.tnc.virtela.cc ([12.41.66.116]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77J7XN07726 for ; Tue, 7 Aug 2001 12:07:33 -0700 (PDT) Received: from posthaus.virtela.cc ([172.16.97.7]) by perfero.tnc.virtela.cc (8.9.3/8.9.3) with ESMTP id MAA28853; Tue, 7 Aug 2001 12:01:44 -0700 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 13:01:44 -0600 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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-ietf-ipsra@mail.vpnc.org Tue Aug 7 17:21:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12683 for ; Tue, 7 Aug 2001 17:21:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77Je9r08451 for ietf-ipsra-bks; Tue, 7 Aug 2001 12:40:09 -0700 (PDT) Received: from traveller.amante.org (dsl081-098-227.den1.dsl.speakeasy.net [64.81.98.227]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77Je7N08447 for ; Tue, 7 Aug 2001 12:40:08 -0700 (PDT) Received: by traveller.amante.org (Postfix, from userid 100) id 429C55004; Tue, 7 Aug 2001 13:51:17 -0600 (MDT) 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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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-ietf-ipsra@mail.vpnc.org Tue Aug 7 17:55:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13066 for ; Tue, 7 Aug 2001 17:55:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77Kxls10855 for ietf-ipsra-bks; Tue, 7 Aug 2001 13:59:47 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77KxiN10851 for ; Tue, 7 Aug 2001 13:59:45 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 14:00:35 -0700 Received: from redcreek.com (209.125.38.122 [209.125.38.122]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDY56R6B; Tue, 7 Aug 2001 14:00:31 -0700 From: "Scott G. Kelly" To: Bernard Aboba Cc: Bill Sommerfeld , "'Marcus Leech'" , ietf-ipsra@vpnc.org Message-ID: <3B7056E5.FDBCA8C8@redcreek.com> Date: Tue, 07 Aug 2001 14:00:21 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Position statement on IKE development References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Bernard, Bernard Aboba wrote: > > > > 1. "Doesn't this require me to install root certs on all the clients, just > > > as if I were moving to PKI?" > > > > All clients are required to have root certs (or access to some > > equivalent verification mechanism) if they are to use anything other > > than preshared keys for phase 1 authentication anyway. Since preshared > > keys will not securely scale, there really is no way around this, is > > there? > > > > Customers who are not wishing to deploy PKI usually avoid it because of > the associated management issues. So requiring them to do many of the same > things as would have been required for PKI deployment generates > resistance. Most customers I talk to have the expectation that they can > deploy VPN scalably without any cert infrastructure at all, either with > password or token-card based authentication. How will they scalably authenticate the headend server if they don't use certificates? > > > 3. "Is my certificate infrastructure able to handle certs of such short > > > duration?" > > > > The requirement, assuming very short-lived certs, is for a simple RA/CA > > application which generates the certs, and for the gateway to have > > access to a verification cert. In the best (most secure case), this "CA" > > will likely be standalone, but in many cases, I'll bet this "CA" will be > > transparently added to the security gateway itself. If the certs are > > sufficiently short-lived (with a lifetime of, say, less than the width > > of your typical CRL window), the sgw only needs to have a verification > > cert, i.e. no additional verification infrastructure is needed. This can > > be made quite simple from the customer's perspective. > > > > Yes, I'd agree that an integrated CA will be much easier for those > customers to live with. However, wouldn't they then need to do a > "forklift" upgrade to transition to full PKI? If so, there wouldn't be > much transition benefit. Why would they need a "forklift"? Since the underlying ipsec implementation has PKI capability in either case, only two changes would be required: 1) User certs would be issued based on some other mechanism 2) The verification mechanism for the (new) user certs would require more stringent management (which could actually be in place from the start), since the certs presumably would not be so short-lived. > > > 4. "I've already deployed . Why should I also need > > > to deploy certificate infrastructure?" > > > > In terms of market acceptance, token cards are considerably further along > than certificates. Many customers already have these token cards in place, > and expect to be able to use them without adding another layer of > infrastructure and configuration. If the infrastructure were deployed in the manner I described in the previous email, I think the infrastructure would be for the most part transparent. For those who really can't stomach this, there's always l2tp, right? And for those who really can't stomach l2tp, well... there's always PIC :-) > > > 5. "Doesn't this assume that my IPsec implementation supports user > > > authentication?" > > > > I don't understand what you are asking here - we are providing a user > > authentication mechanism for ipsec remote access here, right? > > > > Presumably, the cert that is being given out is a user certificate -- and > therefore there is the expection that the IPsec implementation will > support user authentication -- which very few existing implementations do. Any ipsec implementation that supports certificate-based identities has the ability to authenticate a user, right? In fact, how could such an implementation (on its own) differentiate between a user and a machine? Isn't this a function of the larger system of irac, iras, private key storage mechanism, enrollment mechanism, etc? > Or are we authenticating a user identity -- but actually doing machine > authentication within IPsec? I guess I don't understand the distinction you are trying to make here. If I generate a certificate based upon user authentication (passphrase, token card, what-have-you), and I take some precautions to limit the exposure of the associated private key, then I think I'm authenticating the user with private key and cert (to an extent which depends on a number of factors, as discussed above). Please elaborate on what you mean by this last sentence. Scott From owner-ietf-ipsra@mail.vpnc.org Wed Aug 8 00:22:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19213 for ; Wed, 8 Aug 2001 00:22:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f783fRx24308 for ietf-ipsra-bks; Tue, 7 Aug 2001 20:41:27 -0700 (PDT) Received: from spsystems.net (spsystems.net [209.47.149.227]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f783fQN24304 for ; Tue, 7 Aug 2001 20:41:26 -0700 (PDT) Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id XAA02822; Tue, 7 Aug 2001 23:41:21 -0400 (EDT) Date: Tue, 7 Aug 2001 23:41:20 -0400 (EDT) From: Henry Spencer To: "Scott G. Kelly" cc: ietf-ipsra@vpnc.org Subject: Re: Position statement on IKE development In-Reply-To: <3B7015F0.17C5DC21@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 7 Aug 2001, Scott G. Kelly wrote: > > 1. "Doesn't this require me to install root certs on all the clients, just > > as if I were moving to PKI?" > > All clients are required to have root certs (or access to some > equivalent verification mechanism) if they are to use anything other > than preshared keys for phase 1 authentication anyway... We haven't found it so. Of course, we have to explain to people over and over again that using RSA public keys does not imply using certificates. (Do certificates scale better than plain public keys? Yeah, probably... but either one is so superior to preshared secrets that the difference is second-order for most users, and public keys are much simpler.) Henry Spencer henry@spsystems.net From owner-ietf-ipsra@mail.vpnc.org Tue Aug 14 14:20:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12275 for ; Tue, 14 Aug 2001 14:20:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7EHcU522519 for ietf-ipsra-bks; Tue, 14 Aug 2001 10:38:30 -0700 (PDT) Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EHcRN22515 for ; Tue, 14 Aug 2001 10:38:28 -0700 (PDT) Received: from bilbo (ras5-p140.hrz.netvision.net.il [62.0.166.140]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with SMTP id UAA12404 for ; Tue, 14 Aug 2001 20:40:59 +0300 (IDT) Message-ID: <003801c124ef$964a25f0$0300000a@bilbo> From: "Sara Bitan" To: Subject: Meeting's minutes Date: Tue, 14 Aug 2001 20:33:14 +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-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit IPSRA Meeting minutes --------------------- Meeting date : 7-Aug-2001 Meeting led by Paul Hoffman. Paul opened the meeting, the whole session will devoted to PIC discussion. Marcus gave a short clarification on the IKE position statement : PIC is not excluded, but should be run on a port other than 500, and PIC implementations should not share code with IKE implementations on the same box. Hugo gave a presentation of PIC. Questions: William Dixon (MS): Is PIC going to support Tero's revised hash? Hugo: The problem that the revised hash is solving doesn't appear in PIC William: Stateless DOS prevention - since there is no DH computation in the first two message Hugo: We don't plan - DOS protection was not part of the requirement. William: Will you include certificate request? The problem is that is might create UDP fragmentation, which from our experience caused problems in IKE implementation: Try to avoid fragmentation. The certificate request shouldn't be long, but the PKCS#12 might include long certificate chain. William : Proposal - add wording saying that messages are not longer than 1500 bytes.If you can avoid fragmentation - than avoid it. William: What about CMC support? Hugo: No Scott (Cisco): Another server increases complexity of the network and architecture Hugo: A separate AS is optional. Scott: That is an RA or an embedded CA Hugo: This architecture is actually the only one possible within the boundaries of the charter Scott: Shouldn't this protocol moved to PKIX since it is an enrollment protocol Hugo : Enrolment protocols are over functional in some aspects, and under functional in other aspects for PIC, and they are to complex for the purpose. Andrew (Alcatel): Lesson from IKE : don't allow arbitrary payloads and arbitrary lengths Question: have you implemented PIC. What are the CPU requirements of PIC Hugo: No. There are some performance issues. But human authentication should be rare. Q: So this is a simplified CA, with CA authentication being EAP Hugo: Right. End of PIC discussion, beginning of general discussion. Marcus : who has implemented DHCP draft ? Scott (RedCreek): RedCreek + I know there one another implementation - but don't remember whose. Moving forward: Six weeks working group last call - till the end September. If we have significant remarks - period will stretch, After that - IETF last call. We don't need two implementation to move proposed draft. We might not have to meet in Salt lake city From owner-ietf-ipsra@mail.vpnc.org Tue Aug 14 15:42:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13714 for ; Tue, 14 Aug 2001 15:42:39 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7EJ4H624202 for ietf-ipsra-bks; Tue, 14 Aug 2001 12:04:17 -0700 (PDT) Received: from tailor.sailpix.com (ns1.sailpix.com [155.53.1.250]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EJ4GN24198 for ; Tue, 14 Aug 2001 12:04:16 -0700 (PDT) Received: from atty.lounge.org (tycho-205-179-127-181.tychonet.com [205.179.127.181]) by tailor.sailpix.com (Postfix) with ESMTP id 189C954C46 for ; Tue, 14 Aug 2001 12:04:17 -0700 (PDT) Received: from lounge.org (localhost [127.0.0.1]) by dharkins@lounge.orgatty.lounge.org (8.11.0/8.11.0) with ESMTP id f7EJ31Z00890 for ; Tue, 14 Aug 2001 12:03:06 -0700 (PDT) (envelope-from dharkins@lounge.org) Message-Id: <200108141903.f7EJ31Z00890@dharkins@lounge.orgatty.lounge.org> To: ietf-ipsra@vpnc.org Subject: Re: Meeting's minutes In-Reply-To: Your message of "Tue, 14 Aug 2001 20:33:14 +0200." <003801c124ef$964a25f0$0300000a@bilbo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <887.997815781.1@lounge.org> Date: Tue, 14 Aug 2001 12:03:01 -0700 From: Dan Harkins Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If a stack can't handle fragmentation and reassembly then it is broken. I don't think protocols should be constrained because someone's stack is broken. Also, the 1500 bytes limit is not realistic anyway because your MTU is not always 1500 bytes-- some wireless cards set it much smaller (about 1/3 of that if memory serves) for performance reasons. If you're having problems with fragmentation then setting a limit of 1500 bytes on a message would not necessarily help you. Better to just fix the stack. Dan. On Tue, 14 Aug 2001 20:33:14 +0200 sarab@cs.technion.ac.il wrote > > IPSRA Meeting minutes > --------------------- > Meeting date : 7-Aug-2001 > Meeting led by Paul Hoffman. > > Hugo gave a presentation of PIC. > Questions: > William Dixon (MS): Is PIC going to support Tero's revised hash? > Hugo: The problem that the revised hash is solving doesn't appear in PIC > William: Stateless DOS prevention - since there is no DH computation in the > first two message > Hugo: We don't plan - DOS protection was not part of the requirement. > William: Will you include certificate request? The problem is that is might > create UDP fragmentation, which from our experience caused problems in IKE > implementation: Try to avoid fragmentation. The certificate request > shouldn't be long, but the PKCS#12 might include long certificate chain. > William : Proposal - add wording saying that messages are not longer than > 1500 bytes.If you can avoid fragmentation - than avoid it. > William: What about CMC support? > Hugo: No From owner-ietf-ipsra@mail.vpnc.org Tue Aug 14 16:17:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14236 for ; Tue, 14 Aug 2001 16:17:51 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7EJdSV25163 for ietf-ipsra-bks; Tue, 14 Aug 2001 12:39:28 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EJdPN25157 for ; Tue, 14 Aug 2001 12:39:26 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id MAA05004; Tue, 14 Aug 2001 12:32:42 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 14 Aug 2001 12:32:42 -0700 (PDT) From: Bernard Aboba To: Dan Harkins cc: ietf-ipsra@vpnc.org Subject: Re: Meeting's minutes In-Reply-To: <200108141903.f7EJ31Z00890@dharkins@lounge.orgatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If a stack can't handle fragmentation and reassembly then it is broken. > I don't think protocols should be constrained because someone's stack > is broken. The problem isn't the host stack. The problem is typically with routers in front of the VPN server. As an example, if you set an access list to allow UDP Port 500, allow IPsec ESP/AH, then Deny ALL ou will typically not see *any* IPsec traffic get through if the certificate payload is large enough. Why? Because IKE will fragment, and the access list, while allowing the first fragment through, will drop all succeeding fragments, since they don't match any of the permit statements in the access list. From owner-ietf-ipsra@mail.vpnc.org Tue Aug 14 17:50:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15748 for ; Tue, 14 Aug 2001 17:50:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7ELJBk27435 for ietf-ipsra-bks; Tue, 14 Aug 2001 14:19:11 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com ([131.107.3.123]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7ELJAN27431 for ; Tue, 14 Aug 2001 14:19:10 -0700 (PDT) Received: from 157.54.1.52 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 14 Aug 2001 14:18:51 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 14 Aug 2001 14:11:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 14 Aug 2001 14:11:03 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 14 Aug 2001 14:10:55 -0700 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: Meeting's minutes Date: Tue, 14 Aug 2001 14:10:54 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10186F096@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Meeting's minutes thread-index: AcEk97Ovgit13FVfQuurgmyh8eW1xAAABc4AAANy4VA= From: "Brian Swander" To: "Dan Harkins" , X-OriginalArrivalTime: 14 Aug 2001 21:10:55.0290 (UTC) FILETIME=[9B4159A0:01C12505] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7ELJAN27432 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit It is not any particular stack in general that we are worried about, but the network in general dropping fragments. For instance, some routers with port filtering enabled will drop all subsequent fragments because they don't want the expense of fragment tracking. I may be wrong, but this is what I thought the Cisco 11.x versions did, which is a very common bit of network infrastructure. It seems like people would want to stop random UDP and fragmentation attacks from flooding their networks, so that configuring routers to do fragment blocking may be common. This is one common scenario that will kill IKE for larger packet sizes. Telling customers to disable fragment blocking will potentially open their networks up to other attacks, and they may not be willing to take that risk. Or perhaps going from fragment blocking to fragment tracking will cause scalability issues on their routers, or force hardware upgrades, etc. All of these concerns are potential barriers to IKE adoption. So, if we can guarantee that IKE traffic will actually get to the peer systems in question, then we can point the finger at that stack if it fails to reassemble. How can we guarantee that the current networks will correctly deliver our IKE fragments? bs -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org] Sent: Tuesday, August 14, 2001 12:03 PM To: ietf-ipsra@vpnc.org Subject: Re: Meeting's minutes If a stack can't handle fragmentation and reassembly then it is broken. I don't think protocols should be constrained because someone's stack is broken. Also, the 1500 bytes limit is not realistic anyway because your MTU is not always 1500 bytes-- some wireless cards set it much smaller (about 1/3 of that if memory serves) for performance reasons. If you're having problems with fragmentation then setting a limit of 1500 bytes on a message would not necessarily help you. Better to just fix the stack. Dan. On Tue, 14 Aug 2001 20:33:14 +0200 sarab@cs.technion.ac.il wrote > > IPSRA Meeting minutes > --------------------- > Meeting date : 7-Aug-2001 > Meeting led by Paul Hoffman. > > Hugo gave a presentation of PIC. > Questions: > William Dixon (MS): Is PIC going to support Tero's revised hash? > Hugo: The problem that the revised hash is solving doesn't appear in PIC > William: Stateless DOS prevention - since there is no DH computation in the > first two message > Hugo: We don't plan - DOS protection was not part of the requirement. > William: Will you include certificate request? The problem is that is might > create UDP fragmentation, which from our experience caused problems in IKE > implementation: Try to avoid fragmentation. The certificate request > shouldn't be long, but the PKCS#12 might include long certificate chain. > William : Proposal - add wording saying that messages are not longer than > 1500 bytes.If you can avoid fragmentation - than avoid it. > William: What about CMC support? > Hugo: No From owner-ietf-ipsra@mail.vpnc.org Wed Aug 15 21:07:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04232 for ; Wed, 15 Aug 2001 21:07:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7G0LdA19054 for ietf-ipsra-bks; Wed, 15 Aug 2001 17:21:39 -0700 (PDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G0LXN19048 for ; Wed, 15 Aug 2001 17:21:33 -0700 (PDT) Received: from gwzpc (sjc-vpn1-145.cisco.com [10.21.96.145]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id RAA00851; Wed, 15 Aug 2001 17:20:59 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Dan Harkins" , "Horn, Mike" Cc: Subject: RE: Position statement on IKE development Date: Wed, 15 Aug 2001 17:17:48 -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.2910.0) In-Reply-To: <200108041832.f74IWgI00588@dharkins@lounge.orgatty.lounge.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dan Harkins [mailto:dharkins@lounge.org] writes: > It's not going to be any less extensible than it already is but unless > there is a massive change of heart by our ADs it will not include legacy > user authentication or keepalives or any of the other things that we all > think users expect. If you remember, the Position Statement said: > > "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." > > I think if you ask Marcus or Jeff they would say that legacy user > authentication and keepalives fall into the "second system effect" > class of feature. Only because the first system was flawed by design: to call legacy authentication a 'bell' or 'whistle' is manifestly silly; but on the other hand, so is designing a PK-based system in a world where PKI is a fond dream... > > If you also re-read the Position Statement you'll note that the > moratorium is temporary until the process of cleaning and simplifying > is done. I believe we can revisit things like legacy user authentication > when the moratorium is lifted. > > Dan. > > On Sat, 04 Aug 2001 02:09:08 MDT you wrote > > Dan, > > > > Is there any plan to make son-of-ike extensible for things like > legacy user > > authentication, keepalives, etc? Or will it just simplify the existing > > solution? Without adding this new functionality, I think that IKE will > > still fall short of what user expectations are. > > > > Mike > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@lounge.org] > > > Sent: Friday, August 03, 2001 4:35 PM > > > To: Henry Spencer > > > Cc: IP Security List; ietf-ipsra@vpnc.org; ipsec-policy@vpnc.org > > > Subject: Re: Position statement on IKE development > > > > > > > > > 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-ietf-ipsra@mail.vpnc.org Fri Aug 17 17:24:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15490 for ; Fri, 17 Aug 2001 17:24:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HKkM406229 for ietf-ipsra-bks; Fri, 17 Aug 2001 13:46:22 -0700 (PDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HKkKN06218 for ; Fri, 17 Aug 2001 13:46:20 -0700 (PDT) Received: by sentry.gw.tislabs.com; id QAA01199; Fri, 17 Aug 2001 16:50:48 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma001177; Fri, 17 Aug 01 16:50:10 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id QAA09548 for ietf-ipsra@vpnc.org; Fri, 17 Aug 2001 16:45:44 -0400 (EDT) Date: Fri, 17 Aug 2001 16:45:44 -0400 (EDT) From: "David M. Balenson" Message-Id: <200108172045.QAA09548@clipper.gw.tislabs.com> To: ietf-ipsra@vpnc.org Subject: CFP: Submission deadline for NDSS'02 extended to Aug 29th Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Due to the unusually large number of requests for an extension, the submissions deadline for NDSS'02 has been extended to Wednesday August 29, 9:00am EST (U.S. east coast time). Paul Van Oorschot and Virgil Gligor Co-Chairs, NDSS'02 C A L L F O R P A P E R S Internet Society's 2002 Network and Distributed System Security Symposium (NDSS'02) Catamaran Resort - San Diego, California February 6-8, 2002 IMPORTANT DATES Paper and panel submissions due August 22, 2001 Author notification October 17, 2001 Final version of papers and panels due November 20, 2001 GOAL: The symposium fosters information exchange among research scientists and practitioners of network and distributed system security services. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation (rather than theory). A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings are published by the Internet Society. GENERAL CHAIR: Clifford Neuman, USC Information Sciences Institute PROGRAM CO-CHAIRS: Paul Van Oorschot, Entrust Technologies Virgil Gligor, University of Maryland TUTORIAL CHAIR: Eric Harder, National Security Agency LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Mahesh Tripunitara, Purdue University PUBLICITY CHAIR: David Balenson, NAI Labs, Network Associates LOGISTICS CHAIR: Terry Weigler, Internet Society PROGRAM COMMITTEE: Steve Bellovin, AT&T Labs Research Dan Boneh, Stanford University Bill Cheswick, Lumeta Corporation Li Gong, Sun Microsystems Peter Gutmann, Univ. of Auckland, N.Z. Charlie Kaufman, Iris Associates Steve Kent, BBN Technologies Markus Kuhn, Univ. of Cambridge, U.K. Douglas Maughan, DARPA Kevin McCurley, IBM Almaden Research Gary McGraw, Cigital Fabian Monrose, Bell Labs Sandra Murphy, Network Associates Radha Poovendran, Univ. of Washington Michael Roe, Microsoft Research, U.K. Christoph Schuba, Sun Microsystems Clay Shields, Purdue University Jonathan Trostle, Cisco Systems Dan Wallach, Rice University OUTSTANDING PAPER AWARD: There will be an Outstanding Paper award. The award will be presented at the symposium to the authors of an outstanding paper, as selected by the Program Committee. SUBMISSIONS: Both technical papers and panel proposals are solicited. Technical papers must include a main body of at most 12 pages, with any additional details in clearly marked appendices for a combined total of at most 20 pages. Technical papers will appear in the proceedings. Panel proposals should be one page and must describe the topic, identify the panel chair, explain the panel format, and list three to four potential panelists. A description of each panel will appear in the proceedings, and may, at the discretion of the panel chair, include written position statements from the panelists. Submissions are solicited in, but not limited to, the following areas: * Integrating security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web. * Intrusion avoidance, detection, and response: systems, experiences and architectures. * Attack-resistant protocols and services. * Network perimeter controls: firewalls, packet filters, application gateways. * Virtual private networks. * Public key infrastructure, key management, certification, and revocation. * Secure electronic commerce: e.g., payment, barter, EDI, notarization, timestamping, endorsement, and licensing. * Supporting security mechanisms and APIs; audit trails; accountability. * Implementation, deployment and management of network security policies. * Intellectual property protection: protocols, schemas, implementations, metering, watermarking, digital rights management. * Fundamental services on network and distributed systems: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing. * Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: teleconferencing and video-conferencing, groupwork, etc. Each submission must contain a separate Submission Overview specifying the submission type (paper or panel), the title or topic, author names with organizational affiliations, and must specify a contact author along with corresponding phone number, FAX number, postal address and email address. Submissions must be received by August 22, 2001, and must be made electronically in either printable PostScript or PDF. Each submission will be acknowledged by e-mail; if acknowledgment is not received within seven days, contact a program co-chair (see above). Authors and panelists will be notified of acceptance by October 17, 2001, and given instructions for preparing the camera-ready copy. The camera-ready copy must be received by November 20, 2001. FURTHER INFORMATION: Official dates, the final call for papers, the advance program, and registration information will be available shortly at http://www.isoc.org/ndss2002. For official submission information, visit http://www.isoc.org/ndss2002/cfp. Internet Society 11150 Sunset Hills Road, Suite 100 Reston, VA 20191 USA Tel: +1 703 326 9880 Fax: +1 703 326 9880 www.isoc.org 4, rue des Falaises CH-1205 Geneva Switzerland Tel: +41 22 807 1444 Fax: +41 22 807 1445 www.isoc.org From owner-ietf-ipsra@mail.vpnc.org Tue Aug 21 13:01:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23921 for ; Tue, 21 Aug 2001 13:01:52 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7LGIUn07097 for ietf-ipsra-bks; Tue, 21 Aug 2001 09:18:30 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LGISN07093 for ; Tue, 21 Aug 2001 09:18:29 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 09:19:31 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RJG8H7CW; Tue, 21 Aug 2001 09:19:16 -0700 From: "Scott G. Kelly" To: Sara Bitan Cc: ietf-ipsra@vpnc.org Message-ID: <3B828A20.48577B3D@redcreek.com> Date: Tue, 21 Aug 2001 09:19:44 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Meeting's minutes References: <003801c124ef$964a25f0$0300000a@bilbo> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sara Bitan wrote: > Marcus : who has implemented DHCP draft ? > Scott (RedCreek): RedCreek + I know there one another implementation - but > don't remember whose. > Actually, I said that NetScreen has stated that they do - see the July 6 post to the ipsec list with msgid <9D048F4A422CD411A56500B0D0209C5B01028C5C@NS-CA> Scott From owner-ietf-ipsra@mail.vpnc.org Tue Aug 21 18:05:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02423 for ; Tue, 21 Aug 2001 18:05:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LLUrk16668 for ietf-ipsra-bks; Tue, 21 Aug 2001 14:30:53 -0700 (PDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LLUqN16664 for ; Tue, 21 Aug 2001 14:30:52 -0700 (PDT) Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21]) by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f7LKfDW30996; Tue, 21 Aug 2001 13:41:21 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 14:25:03 -0700 Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F367A@NS-CA> From: Michael Choung Shieh To: "'Scott G. Kelly'" , Sara Bitan Cc: ietf-ipsra@vpnc.org Subject: RE: Meeting's minutes Date: Tue, 21 Aug 2001 14:25:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry for the confusion. Netscreen do have an implementation to support dhcp relay, which can relay dhcp request from trusted side hosts through ipsec tunnel. However, we don't support the dhcp relay scheme for remote clients as defined in DHCP draft. In the bakeoff, SSH were looking for vendors to test this feature. They may be the one. -------------------------------------------- Michael Shieh NetScreen Technologies, Inc Email: mshieh@netscreen.com -------------------------------------------- -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Tuesday, August 21, 2001 9:20 AM To: Sara Bitan Cc: ietf-ipsra@vpnc.org Subject: Re: Meeting's minutes Sara Bitan wrote: > Marcus : who has implemented DHCP draft ? > Scott (RedCreek): RedCreek + I know there one another implementation - but > don't remember whose. > Actually, I said that NetScreen has stated that they do - see the July 6 post to the ipsec list with msgid <9D048F4A422CD411A56500B0D0209C5B01028C5C@NS-CA> Scott From subs-reminder@vpnc.org Thu Aug 23 22:53:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07601 for ; Thu, 23 Aug 2001 22:53:52 -0400 (EDT) From: subs-reminder@vpnc.org Received: by above.proper.com (8.11.6/8.11.3) id f7O2t7m03012; Thu, 23 Aug 2001 19:55:07 -0700 (PDT) Date: Thu, 23 Aug 2001 19:55:07 -0700 (PDT) Message-Id: <200108240255.f7O2t7m03012@above.proper.com> To: ipsra-archive@ietf.org Subject: [[196848431]] Subscription to ietf-ipsra for ipsra-archive@lists.ietf.org Greetings. This message is a periodic reminder that ipsra-archive@lists.ietf.org is subscribed to the ietf-ipsra mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ipsra mailing list, you do not need to do anything. On the other hand, if you want to unsubscribe from this list, go to the following link: You can also unsubscribe by email. To do so, you can respond to this message and I will unsubscribe you by hand in the next few days. Alternatively, you can send a plain-text message to: ietf-ipsra-request@vpnc.org with the single word unsubscribe in the body of the message. If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-ipsra@mail.vpnc.org Wed Aug 29 07:49:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21189 for ; Wed, 29 Aug 2001 07:49:55 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f7TBKs221890 for ietf-ipsra-bks; Wed, 29 Aug 2001 04:20:54 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TBKpD21886 for ; Wed, 29 Aug 2001 04:20:51 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19903; Wed, 29 Aug 2001 07:19:32 -0400 (EDT) Message-Id: <200108291119.HAA19903@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsra-reqmts-04.txt Date: Wed, 29 Aug 2001 07:19:31 -0400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Remote Access Working Group of the IETF. Title : Requirements for IPsec Remote Access Scenarios Author(s) : S. Kelly, S. Ramamoorthi Filename : draft-ietf-ipsra-reqmts-04.txt Pages : 33 Date : 28-Aug-01 IPsec offers much promise as a secure remote access mechanism. However, there are a significant number of remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsra-reqmts-04.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-ipsra-reqmts-04.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-ipsra-reqmts-04.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: <20010828120820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsra-reqmts-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsra-reqmts-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010828120820.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra@mail.vpnc.org Fri Aug 31 13:47:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11915 for ; Fri, 31 Aug 2001 13:47:51 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f7VHCR323081 for ietf-ipsra-bks; Fri, 31 Aug 2001 10:12:27 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VHCQD23071 for ; Fri, 31 Aug 2001 10:12:26 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA36986 for ; Fri, 31 Aug 2001 10:04:10 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 31 Aug 2001 10:04:10 -0700 (PDT) From: Bernard Aboba To: ietf-ipsra@vpnc.org Subject: PIC and RFC 2510 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: RFC 2510 (and its successor in progress, draft-ietf-pkix-rfc2510bis-04.txt), includes a number of requirements for Public Key Infrastructure Certificate Management Protocols. From page 7 of RFC 2510bis: "5. PKI management protocols must allow the use of different industry-standard cryptographic algorithms, (specifically including RSA, DSA, MD5, SHA-1).... 6. PKI management protocols must not preclude the generation of key pairs by the end-entity concerned..." However, http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-03.txt notes in section A.4: "The protocol as described requires the policies of Client and Server to match regarding credentials. For example, an unrecoverable protocol error results if the Client is unable to produce a private key but the server requires this capability. Several approaches for credential negotiation were considered and rejected for this protocol, in the interest of simplicity. The general case would require negotiation of multiple properties in parallel, for example: - Is the private key generated by the Client or the AS. - What type of certificate is required, in particular which algorithm. - What length of keys is required, for each of the credential's components." It would therefore appear that PIC does not meet the RFC 2510 requirements for certificate management protocols. How do we resolve this? From owner-ietf-ipsra@mail.vpnc.org Fri Aug 31 15:27:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14618 for ; Fri, 31 Aug 2001 15:27:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7VIoU425252 for ietf-ipsra-bks; Fri, 31 Aug 2001 11:50:30 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VIoRD25248; Fri, 31 Aug 2001 11:50:27 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Fri, 31 Aug 2001 11:50:09 -0700 To: Bernard Aboba , ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: Re: PIC and RFC 2510 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:04 AM -0700 8/31/01, Bernard Aboba wrote: >RFC 2510 (and its successor in progress, >draft-ietf-pkix-rfc2510bis-04.txt), includes a number of requirements for >Public Key Infrastructure Certificate Management Protocols. Well, that is one way to look at 2510. Another way is to look at the twisted history of the PKIX Working Group and see that 2510 describes *one* of the standardized certificate management protocols, and that the "requirements" section in fact is a self-justification for the particular protocol. For those of you who love IETF politics (which, of course, is not wholly unrelated to the existence this very Working Group), the "other" certificate management protocol to come out of the PKIX WG is CMC, RFC 2797. The two do essentially the same thing, but using different formats for the messages. The politics of why there are even two different protocols is out of scope for this working group (and should have been out of scope for PKIX, but wasn't). >Several approaches for credential negotiation were considered and rejected >for this protocol, in the interest of simplicity. Right. > The general case would >require negotiation of multiple properties in parallel, for example: > > - Is the private key generated by the Client or the AS. > - What type of certificate is required, in particular which algorithm. > - What length of keys is required, for each of the credential's > components." Smells like IKE. :-) >It would therefore appear that PIC does not meet the RFC 2510 requirements >for certificate management protocols. Right. Remember, this WG even considered getting RFC 2510 (CMP) extended to handle multiple round trip legacy auth as the protocol for this group. We instead chose PIC. > How do we resolve this? No need to resolve anything. PIC is not a generic certificate management protocol: it has a particular function for use in IPsec, and meets a particular requirement ("don't do the legacy authentication where most people want to do it, namely in IKE"). --Paul Hoffman, Director --VPN Consortium