From owner-ipsec-policy@mail.vpnc.org Thu Aug 2 23:40:58 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 XAA16227 for ; Thu, 2 Aug 2001 23:40:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f731UUf03936 for ipsec-policy-bks; Thu, 2 Aug 2001 18:30:30 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Thu Aug 2 23:58:20 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 XAA16693 for ; Thu, 2 Aug 2001 23:58:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732AKO04479 for ipsec-policy-bks; Thu, 2 Aug 2001 19:10:20 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732AIs04470 for ; Thu, 2 Aug 2001 19:10:18 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYI200.8DA for ; Thu, 2 Aug 2001 21:51:38 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5D2700.G1W; Fri, 27 Jul 2001 15:34:55 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id JAA01077; Fri, 27 Jul 2001 09:43:35 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA14577 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 09:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA12882 for ; Fri, 27 Jul 2001 07:07:54 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06681; Fri, 27 Jul 2001 07:07:51 -0400 (EDT) Message-Id: <200107271107.HAA06681@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec-policy@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsp-config-policy-model-03.txt Date: Fri, 27 Jul 2001 07:07:51 -0400 Sender: owner-ipsec-policy@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 Policy Working Group of the IETF. Title : IPsec Configuration Policy Model Author(s) : J. Jason, L. Rafalow, E. Vyncke Filename : draft-ietf-ipsp-config-policy-model-03.txt Pages : 148 Date : 26-Jul-01 This document presents an object-oriented model of IPsec policy designed to: o facilitate agreement about the content and semantics of IPsec policy o enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec- enabled endpoints The schema described in this document models the IKE phase one parameters as described in [IKE] and the IKE phase two parameters for the IPsec Domain of Interpretation as described in [COMP, ESP, AH, DOI]. It is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) [PCIM]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-03.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-ipsp-config-policy-model-03.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-ipsp-config-policy-model-03.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: <20010726170624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsp-config-policy-model-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsp-config-policy-model-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170624.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec-policy@mail.vpnc.org Fri Aug 3 06:09:36 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 GAA11817 for ; Fri, 3 Aug 2001 06:09:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738srr05072 for ipsec-policy-bks; Fri, 3 Aug 2001 01:54:53 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738sqs05066 for ; Fri, 3 Aug 2001 01:54:52 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF4L00.SPE for ; Fri, 3 Aug 2001 03:50:45 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5D2700.G1W; Fri, 27 Jul 2001 15:34:55 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id JAA01077; Fri, 27 Jul 2001 09:43:35 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA14577 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 09:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA12882 for ; Fri, 27 Jul 2001 07:07:54 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06681; Fri, 27 Jul 2001 07:07:51 -0400 (EDT) Message-Id: <200107271107.HAA06681@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec-policy@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsp-config-policy-model-03.txt Date: Fri, 27 Jul 2001 07:07:51 -0400 Sender: owner-ipsec-policy@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 Policy Working Group of the IETF. Title : IPsec Configuration Policy Model Author(s) : J. Jason, L. Rafalow, E. Vyncke Filename : draft-ietf-ipsp-config-policy-model-03.txt Pages : 148 Date : 26-Jul-01 This document presents an object-oriented model of IPsec policy designed to: o facilitate agreement about the content and semantics of IPsec policy o enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec- enabled endpoints The schema described in this document models the IKE phase one parameters as described in [IKE] and the IKE phase two parameters for the IPsec Domain of Interpretation as described in [COMP, ESP, AH, DOI]. It is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) [PCIM]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-03.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-ipsp-config-policy-model-03.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-ipsp-config-policy-model-03.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: <20010726170624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsp-config-policy-model-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsp-config-policy-model-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170624.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec-policy@mail.vpnc.org Fri Aug 3 11:18:20 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 LAA17920 for ; Fri, 3 Aug 2001 11:18:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73DYkY15707 for ipsec-policy-bks; Fri, 3 Aug 2001 06:34:46 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Fri Aug 3 12:26:50 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 MAA19894 for ; Fri, 3 Aug 2001 12:26:50 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f73EPkP16516 for ipsec-policy-bks; Fri, 3 Aug 2001 07:25:46 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Fri Aug 3 17:20: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 RAA29469 for ; Fri, 3 Aug 2001 17:20:12 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f73Iwtq27509 for ipsec-policy-bks; Fri, 3 Aug 2001 11:58:55 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Fri Aug 3 17:25:16 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 RAA29530 for ; Fri, 3 Aug 2001 17:25:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73Iqws27375 for ipsec-policy-bks; Fri, 3 Aug 2001 11:52:58 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Fri Aug 3 17:40: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 RAA29650 for ; Fri, 3 Aug 2001 17:40:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73JYFk28248 for ipsec-policy-bks; Fri, 3 Aug 2001 12:34:15 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Fri Aug 3 17:54: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 RAA29773 for ; Fri, 3 Aug 2001 17:54:11 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f73Jkfg28780 for ipsec-policy-bks; Fri, 3 Aug 2001 12:46:41 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Fri Aug 3 19:03:04 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 TAA00509 for ; Fri, 3 Aug 2001 19:03:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73KbVc02793 for ipsec-policy-bks; Fri, 3 Aug 2001 13:37:31 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Fri Aug 3 19:35:04 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 TAA00964 for ; Fri, 3 Aug 2001 19:35:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73LNV304134 for ipsec-policy-bks; Fri, 3 Aug 2001 14:23:31 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Fri Aug 3 20:01:02 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 UAA01337 for ; Fri, 3 Aug 2001 20:01:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73LjpL05340 for ipsec-policy-bks; Fri, 3 Aug 2001 14:45:51 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Fri Aug 3 23:24:59 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 XAA04811 for ; Fri, 3 Aug 2001 23:24:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7419TC08763 for ipsec-policy-bks; Fri, 3 Aug 2001 18:09:29 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Sat Aug 4 11:06:16 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 LAA27003 for ; Sat, 4 Aug 2001 11:06:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f74DMR115950 for ipsec-policy-bks; Sat, 4 Aug 2001 06:22:27 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Sat Aug 4 19:25:43 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 TAA02360 for ; Sat, 4 Aug 2001 19:25:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f74Lq4627315 for ipsec-policy-bks; Sat, 4 Aug 2001 14:52:04 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Sat Aug 4 20:35: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 UAA02805 for ; Sat, 4 Aug 2001 20:35:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f74N7rk28696 for ipsec-policy-bks; Sat, 4 Aug 2001 16:07:53 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Sun Aug 5 09:24:25 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 JAA13796 for ; Sun, 5 Aug 2001 09:24:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f75BpNM05837 for ipsec-policy-bks; Sun, 5 Aug 2001 04:51:23 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Sun Aug 5 09:33: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 JAA13895 for ; Sun, 5 Aug 2001 09:33:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f75Bv5005868 for ipsec-policy-bks; Sun, 5 Aug 2001 04:57:05 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Sun Aug 5 17:06:16 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 RAA21368 for ; Sun, 5 Aug 2001 17:06:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f75JBJD15783 for ipsec-policy-bks; Sun, 5 Aug 2001 12:11:19 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Mon Aug 6 06:50: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 GAA21155 for ; Mon, 6 Aug 2001 06:50:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f767Y5S10735 for ipsec-policy-bks; Mon, 6 Aug 2001 00:34:05 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Mon Aug 6 09:34: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 JAA23069 for ; Mon, 6 Aug 2001 09:34:30 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f76BBG229117 for ipsec-policy-bks; Mon, 6 Aug 2001 04:11:16 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Mon Aug 6 13:36: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 NAA28239 for ; Mon, 6 Aug 2001 13:35:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76FXWf08299 for ipsec-policy-bks; Mon, 6 Aug 2001 08:33:32 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Mon Aug 6 15:17:18 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 PAA29752 for ; Mon, 6 Aug 2001 15:17:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76HevS14588 for ipsec-policy-bks; Mon, 6 Aug 2001 10:40:57 -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-ipsec-policy@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-ipsec-policy@mail.vpnc.org Wed Aug 8 21:43:02 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 VAA26014 for ; Wed, 8 Aug 2001 21:42:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f790U3325697 for ipsec-policy-bks; Wed, 8 Aug 2001 17:30:03 -0700 (PDT) Received: from sentry.gw.tislabs.com (firewall-user@relay.hq.tis.com [192.94.214.100] (may be forged)) by above.proper.com (8.11.3/8.11.3) with ESMTP id f790U2N25693 for ; Wed, 8 Aug 2001 17:30:02 -0700 (PDT) Received: by sentry.gw.tislabs.com; id UAA02266; Wed, 8 Aug 2001 20:34:25 -0400 (EDT) Received: from test.netsec.tislabs.com(199.171.39.2) by sentry.gw.tislabs.com via smap (V5.5) id xma002253; Wed, 8 Aug 01 20:33:39 -0400 X-Sender: mundy@217.33.140.133 (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Aug 2001 00:28:41 +0100 To: "ipsec-policy@vpnc.org" From: Russ Mundy Subject: Draft Minutes from IPSP WG Mtg at 51st IETF Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT IP Security Policy Working Group Meeting at the 51st IETF 6 August 2001, 0900 - 1130 Co-Chairs: Hilarie Orman (not able to attend meeting) Luis Sanchez Notes: Russ Mundy Approximate Attendance: 147 The meeting was opened by Luis with a comment about the recent email from Marcus Leach related to the complexity of IKE (see Position statement on IKE development, Date: Thu, 02 Aug 2001 21:33:47 -0400). Since the Charter of IPSP essentially does not permit us to make changes to the various IP security and related protocols, our work should not be impacted by this position statement. After this short introduction, we moved right to the following agenda: - Agenda Bashing L. Sanchez 5 minutes - Roadmap L. Sanchez 10 minutes - Configuration Model E. Vyncke 20 minutes - PCIM Dependencies L. Rafalow 20 minutes - PF_Policy B. Sommerfeld - PIB M. Li 25 minutes - MIB W. Hardaker 25 minutes - Wrap-Up L. Sanchez 5 minutes - Configuration Model presentation by Eric Vyncke Eric presented the IPsec Configuration Policy Model (ICPM) which is currently described in . The presentation focused on: the positioning of ICPM vs PCIMe and CIM; changes and non-changes since 50th IETF; and the model status. Eric presented a graphic which illustrated the relationships between the relevant RFCs, the PCIMe, the ICPM, the IPsec PIB and the IPsec MIB as well as how it relates to DMTF modeling efforts (see posted slides for details). Things that were identified as non-changes since the 50th IETF include: filters for ICMP and dynamic protocols lifetime, authors continuing to follow RFC240* and retaining the possibility that models can be extended for proprietary extensions. Items identified as changing since 50th IETF include incorporation of CompoundActions in PCIMe, IPHeaderFilter, PeerGatewayForPreconfiguredAction, and changes to use of MAY/SHOULD/MUST in the document. - The presentation descibed how the inclusion of CompoundPolicyAction fit into the model and a description of how it should add value. An important facet of SARule/CompoundPolicyAction is the ExecutionStrategy which can be Do All, Do Until Success or Do Until Failure. At this point, it looks as though all ICPM functions will have either Do All or Do Until Success since a use for Do Until Failure could not be identified. There were several questions from the audience about the examples were shown for the uses of Do Until Success. Some of the details of the examples need to be changed so they align with the appropriate specifications, e.g., what the transport will negotiate over the tunnel in the Redundant Transport Mode in Tunnel Mode example. Also, additional text needs to be included in the document that will reflect the usages described in the WG. For example, multiple rules or multiple tunnels may be needed in some instances. Additionally, it was noted that the model may not accurately reflect checking of the SPD and that all of the 5-tuple parameters must be covered in the model. - The changes to IPHeaderFilter were described and discussed. The described intent of this additional class is to be able to filter on a single rule. The question was raised as to why the diffserv code point was included. The response was that this would facilitate the use of a single set of software for all policy filtering. The addition of PeerGatewayForPreconfigurationAction was described but there was little discussion about this change. - With respect to the MAY/SHOULD/MUST changes, the model was updated so that all of the MUSTs from RFC-240* MUSTs are now MUSTs in the model. Items from external objects (e.g., CIM) were changed to MAY. - The readability changes included fixing typos and more descriptive text for DoPacketLogging, Use of IKERules and IPsecRules, and IPsec preconfigured key in SharedSecret LimitNegotiation in SARule. - There were a few changes to follow the moving target of PCIMe but otherwise the model appears to be stable. The presentation concluded with the suggestion that after incorporating the changes related to the examples and ensuring that all 5-tuple parameters are covered in the model, the document is ready for Working Group Last Call. - PCIM Dependencies presentation by Lee Rafalow Lee Rafalow lead a discussion in issues related to the Policy Core Information Model Extensions which is commonly called PCIMe. He presented a modified set of slides on PCIMe-02 issues that were prepared by Bob Moore for the Policy Framework Working Group. The modifications high-lighted the items that probably have the most impact on the IPSP Working Group. Any issues from the PCIMe document or slides that are outside the scope of IPSP can be discussed in the Policy Framework Working Group meetings or on their mail list. Lee noted that the Policy Framework Working Group would like to take the PCIMe document to Working Group Last Call right after the London meeting. - Of the PCIMe actions since the Minneapolis meeting, moving the Device-level header filters from the QDDM to PCIMe is the only thing that seems to impact IPSP. - Of the seven open PCIMe issues listed on the slides, four are of particular interest to IPSP. These four are: -- Issues related to IPHeaderFilter -- The "Do Until Failure" ExecutionStrategy -- Evaluation and execution order -- Criticality of extended conditions The details associated with each of these issues are available on the slides from the presentation. The main area of discussed during this presentation was whether or not other capabilities such as permit and block would be considered for IPHeaderFilter. It was also suggested that it might also be wise to include ICMP types in the Policy Framework. It was noted by WG members that the current RFC240* documents do not have any selector that includes features such as permit/block and, since the IPSP charter does not permit us to add to RFC240*, it is more appropriate to raise this in the IPSEC group for their consideration. It was also noted that this set of items could be raised in the Policy Framework WG meeting later in the week or on their mail list. Lee pointed out that he expected that several of the issues impacting IPSP and ICPM will be clarified during the Policy Framework WG meeting on Monday afternoon and he urged interested IPSP WG members to participate in the Policy Framework WG meetings during the IETF. - PF_Policy presentation by Bill Sommerfeld Bill Sommerfeld gave a short presentation on his initial thoughts on PF_Policy. In general, PF_Policy is intended to provide a standard policy management interface to push IPsec policy into TCP/IP/IPsec similar to the way PF_Key functions for IPsec keys. The viewgraph illustrating this should be available in the proceedings. He has not started the ID yet but asked if individuals interested in working on it would contact him at sommerfeld@east.sun.com. Bill expects to have the document available by the 52nd IETF meeting. - PIB presentation by Mi Lee Mi Lee gave a presentation on the current version of the IPSec Policy Information Base . The presentation structure included describing what the IPsec PIB is, what is new in the 03 Draft, what needs to be added to the PIB and an overview of the IPsec PIB. - The IPsec Policy Information Base was described as the approach used by policy servers to distribute IPsec policy to IPsec enabled devices such as gateways, routers, laptops, using the COPS protocol with extensions for provisioning. - The new items in the current (03) version of the Draft include the addition of an interface capability reporting table and associated explanations, clarification of the text associated with multiple action policy, and the addition of replay protections for ESP and AH. - The items remaining to be completed were identified as the capability to handle fall back and the capability to handle pre-configured security associations. - There were minimal discussions or questions raised during the IPsec PIB overview and readers are encouraged to read the Draft for a description of the PIB or see the presentation slides which should be in the proceedings. At the end of the presentation, the Co-chair asked if anyone was implementing the PIB besides Nokia. A WG member said that Intel had been working on it but they did not know if the work was still underway. Another WG member asked if anyone had looked at the PIB with respect to multicast security but no one knew of any work or activity in this area. - MIB presentation by Wes Hardaker Wes Hardaker gave a presentation on the current version of the IPsec Policy Configuration MIB . Wes's presentation was structured to provide an architectural overview of the MIB, a description of the differences from the previous WG meeting, description of the differences between the MIB and the configuration policy model (ICPM), identification of things yet to be done and time for discussion and questions. - The architecture overview of the presentation described the set of MIB tables and their relationship. There are currently 23 tables and 249 objects contained in the MIB. - There have been a large number of changes since the previous WG meeting and previous version of the Draft. An 'eye chart' was presented with about 60 changes that were distilled down to the following seven (more readable) differences: -- The MIB matches the current ICPM more closely but not completely. More work will be needed here due to the continuing changes to the model. -- The MIB now makes use of IPSEC-ISAKMP-IKE-DOI-TC -- The MIB supports group in group -- Filters can be ANDed or ORed (to support CNF/DNF) -- The MIB now supports preconfigured actions tables -- Support is provided for string lists -> tables (e.g., list of transforms in a proposal) -- Miscellaneous problems were submitted to the WG mail list. - Even though there has been quite a bit alignment between the model and the MIB since the last meeting, there are still some differences. -- Packet classification is independent of IPsec/QoS/... since the names are generic. -- Rule actions are specified via RowPointers which allows extensibility and the packet classification system to be used by other external action tables, e.g., vendor, QoS. -- Filter OO objects are combined into one table. -- CNF/DNF is implemented in a more flexible way. - The following items remain to be completed: scheduling of policies; filter types are missing; notifications; and conformance objects. - Several items were identified for discussion including: lists contained in separate tables; are there too many tables; should there be one keys table or should keys be kept in each table. There was essentially no input received from WG members on the discussion items or in other parts of the presentation so work will continue in the current direction. - The static SA portion of a previous version of the MIB has been implemented by NAI Labs. No now spoke up when it was asked if there were any other implementations of the MIB. The Co-chair asked when the code would be released, Wes responded that this would probably be after they have completed implementation on the Linux 2.4 kernel. A WG member asked the amount of energy that it took to implement the MIB. Including the work and re-work needed to track some of the changes to the model, NAI Labs needed about 3.5 people over three months. - Wrap-Up by Luis Sanchez The next steps planned for the Working Group are: - Conduct Working Group Last Call for the following drafts: IPsec Policy Management Roadmap Requirements for IPsec Policy Management IPsec Policy Configuration Model IPsec Policy Information Base - Given successful completion of Working Group Last Call, each of the documents will be submitted to the IESG with a recommendation for advancement to Proposed Standard. - Publish the initial version of the PF_Policy draft - Continue SG Discovery Protocol design - Close the loop on the policy specification and compliance checking - The Working Group needs to evaluate support for multicast security The Co-chair closed the meeting at approximately 1045. From owner-ipsec-policy@mail.vpnc.org Thu Aug 9 04: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 EAA17881 for ; Thu, 9 Aug 2001 04:55:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f797iF721706 for ipsec-policy-bks; Thu, 9 Aug 2001 00:44:15 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.com [193.49.124.32]) by above.proper.com (8.11.3/8.11.3) with SMTP id f797iCN21696 for ; Thu, 9 Aug 2001 00:44:12 -0700 (PDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 09:44:03 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D829DE2A8@lat3721.rd.francetelecom.fr> From: MORAND Pierrick FTRD/DMI/CAE To: "IPSEC-POLICY (E-mail)" Subject: ipSecIfCapsTable PIB-ACCESS value Date: Thu, 9 Aug 2001 09:43:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi ! The PIB-ACCESS clause for the ipSecIfCapsTable has been set to "install" in the last draft-ietf-ipsp-ipsecpib-03.text document. This means that the PDP could modify these values or add new instances. In other word a PDP could modify, as I understand it, the capabilties of an interface type. Shouldn't the value be set to "notify" instead ? Thanks. Pierrick Morand france telecom R&D/DMI/SIR/IPI Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 Email :pierrick.morand@rd.francetelecom.com From owner-ipsec-policy@mail.vpnc.org Thu Aug 16 13:35:54 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 NAA16934 for ; Thu, 16 Aug 2001 13:35:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GG0u923045 for ipsec-policy-bks; Thu, 16 Aug 2001 09:00:56 -0700 (PDT) Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7GG0rN23041 for ; Thu, 16 Aug 2001 09:00:54 -0700 (PDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id f7GG0oq05102 for ; Thu, 16 Aug 2001 18:00:54 +0200 (CEST) Message-ID: <023901c1266c$92eccb00$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP Policy Date: Thu, 16 Aug 2001 18:00:26 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0236_01C1267D.53D7BEA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0236_01C1267D.53D7BEA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The 2001 edition of the IP Policy conference will stand in Paris from = 11 to 14 September : http://www.upperside.fr/ippol2001/ippol2001intro.htm ------=_NextPart_000_0236_01C1267D.53D7BEA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The 2001 edition of the IP Policy conference will = stand=20 in  Paris from 11 to 14 September :
http://www.= upperside.fr/ippol2001/ippol2001intro.htm
------=_NextPart_000_0236_01C1267D.53D7BEA0-- From owner-ipsec-policy@mail.vpnc.org Fri Aug 17 18:02:54 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 SAA15884 for ; Fri, 17 Aug 2001 18:02:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HKeIT06088 for ipsec-policy-bks; Fri, 17 Aug 2001 13:40:18 -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 f7HKeHN06083 for ; Fri, 17 Aug 2001 13:40:17 -0700 (PDT) Received: by sentry.gw.tislabs.com; id QAA00989; Fri, 17 Aug 2001 16:44:45 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma000963; Fri, 17 Aug 01 16:44:28 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id QAA09326 for ipsec-policy@vpnc.org; Fri, 17 Aug 2001 16:40:02 -0400 (EDT) Date: Fri, 17 Aug 2001 16:40:02 -0400 (EDT) From: "David M. Balenson" Message-Id: <200108172040.QAA09326@clipper.gw.tislabs.com> To: ipsec-policy@vpnc.org Subject: CFP: Submission deadline for NDSS'02 extended to Aug 29th Sender: owner-ipsec-policy@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-ipsec-policy@mail.vpnc.org Mon Aug 20 13:29: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 NAA27746 for ; Mon, 20 Aug 2001 13:29:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KFevB21113 for ipsec-policy-bks; Mon, 20 Aug 2001 08:40:57 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KFetN21106 for ; Mon, 20 Aug 2001 08:40:55 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7KFf0i21141 for ; Mon, 20 Aug 2001 10:41:01 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Aug 2001 10:40:55 -0500 content-class: urn:content-classes:message Subject: RE: ipSecIfCapsTable PIB-ACCESS value Date: Mon, 20 Aug 2001 10:38:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: ipSecIfCapsTable PIB-ACCESS value Thread-Index: AcEgrPJhIvefxIyeEdWrxAAIx6S5QwI4NAlg X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Li Man.M (NRC/Boston)" To: "'ext MORAND Pierrick FTRD/DMI/CAE'" , "IPSEC-POLICY (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7KFeuN21107 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Pierrick, Thanks for pointing this out. You are correct. I forgot to change it after cut and paste. Next version will have it changed. Man -----Original Message----- From: ext MORAND Pierrick FTRD/DMI/CAE [mailto:pierrick.morand@rd.francetelecom.com] Sent: August 09, 2001 03:43 AM To: IPSEC-POLICY (E-mail) Subject: ipSecIfCapsTable PIB-ACCESS value Hi ! The PIB-ACCESS clause for the ipSecIfCapsTable has been set to "install" in the last draft-ietf-ipsp-ipsecpib-03.text document. This means that the PDP could modify these values or add new instances. In other word a PDP could modify, as I understand it, the capabilties of an interface type. Shouldn't the value be set to "notify" instead ? Thanks. Pierrick Morand france telecom R&D/DMI/SIR/IPI Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 Email :pierrick.morand@rd.francetelecom.com From owner-ipsec-policy@mail.vpnc.org Wed Aug 22 05:39: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 FAA28351 for ; Wed, 22 Aug 2001 05:38:58 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f7M871719325 for ipsec-policy-bks; Wed, 22 Aug 2001 01:07:01 -0700 (PDT) Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.com [193.49.124.31]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7M86wN19318 for ; Wed, 22 Aug 2001 01:06:59 -0700 (PDT) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 09:48:57 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D829DE2AF@lat3721.rd.francetelecom.fr> From: MORAND Pierrick FTRD/DMI/CAE To: "'Li Man.M (NRC/Boston)'" , "IPSEC-POLICY (E-mail)" Subject: RE: ipSecIfCapsTable PIB-ACCESS value Date: Wed, 22 Aug 2001 09:48:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7M86xN19319 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Man, I have also noted the following in the last version 03 of the draft. ipSecIkeAssociationTable has the {ipSecIkeAssociation 6 } object-id assigned (see page 31) and the ipSecCredentialFieldsTable has the same value (see page 44). Have a nice day. Pierrick -----Message d'origine----- De : Li Man.M (NRC/Boston) [mailto:Man.M.Li@nokia.com] Envoyé : lundi 20 août 2001 17:38 À : 'ext MORAND Pierrick FTRD/DMI/CAE'; IPSEC-POLICY (E-mail) Objet : RE: ipSecIfCapsTable PIB-ACCESS value Hi Pierrick, Thanks for pointing this out. You are correct. I forgot to change it after cut and paste. Next version will have it changed. Man -----Original Message----- From: ext MORAND Pierrick FTRD/DMI/CAE [mailto:pierrick.morand@rd.francetelecom.com] Sent: August 09, 2001 03:43 AM To: IPSEC-POLICY (E-mail) Subject: ipSecIfCapsTable PIB-ACCESS value Hi ! The PIB-ACCESS clause for the ipSecIfCapsTable has been set to "install" in the last draft-ietf-ipsp-ipsecpib-03.text document. This means that the PDP could modify these values or add new instances. In other word a PDP could modify, as I understand it, the capabilties of an interface type. Shouldn't the value be set to "notify" instead ? Thanks. Pierrick Morand france telecom R&D/DMI/SIR/IPI Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 Email :pierrick.morand@rd.francetelecom.com From subs-reminder@vpnc.org Fri Aug 24 06:03: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 GAA27891 for ; Fri, 24 Aug 2001 06:03:29 -0400 (EDT) From: subs-reminder@vpnc.org Received: by above.proper.com (8.11.6/8.11.3) id f7OA4mO16881; Fri, 24 Aug 2001 03:04:48 -0700 (PDT) Date: Fri, 24 Aug 2001 03:04:48 -0700 (PDT) Message-Id: <200108241004.f7OA4mO16881@above.proper.com> To: ipsp-archive@ietf.org Subject: [[824265737]] Subscription to ipsec-policy for ipsp-archive@lists.ietf.org Greetings. This message is a periodic reminder that ipsp-archive@lists.ietf.org is subscribed to the ipsec-policy 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 ipsec-policy 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: ipsec-policy-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-ipsec-policy@mail.vpnc.org Thu Aug 30 06:51:59 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 GAA09216 for ; Thu, 30 Aug 2001 06:51:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7U9s9A19227 for ipsec-policy-bks; Thu, 30 Aug 2001 02:54:09 -0700 (PDT) Received: from smtp5.cluster.oleane.net (smtp5.cluster.oleane.net [195.25.12.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7U9s7D19223 for ; Thu, 30 Aug 2001 02:54:07 -0700 (PDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp5.cluster.oleane.net with SMTP id f7U9s5c77641 for ; Thu, 30 Aug 2001 11:54:05 +0200 (CEST) Message-ID: <009601c13139$99fee400$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPsec interoperability demonstration platform Date: Thu, 30 Aug 2001 11:53:19 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01C1314A.5C844DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0093_01C1314A.5C844DC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable During the 2000 edition of the IPsec Summit, HSC showcased a very = successfull interoperability platform, demonstrating with several = vendors that some VPN functions could interoperate at the gateway level. = During the 2001 edition of the conference next October the experience = will be renewed but with very important technical extensions.=20 The demonstration platform will perform :=20 A) VPN interoperability (gateway to gateway) B) Certificate based authentication (PKI compliance)=20 C) Hybrid IPv4/IPv6 based network=20 The demonstration platform, developped and managed by HSC, is still = welcoming vendors wishing to demonstrate that their IPsec systems are = able to interoperate at the gateway level. Vendors wishing to connect = clients on a distant access mode are also welcome. The demonstrartion network will also integrate a certificate authority = component (PKI)=20 Above all, the network will be able to implement IPv4 and IPv6 tunnels. More details at: http://www.upperside.fr/ipsec2001/ipsec01intro.htm ------=_NextPart_000_0093_01C1314A.5C844DC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
During the 2000 edition of the = IPsec Summit,=20 HSC showcased a very successfull interoperability platform, = demonstrating with=20 several vendors that some VPN functions could interoperate at the = gateway=20 level.=20

During the 2001 edition of the = conference next=20 October the experience will be renewed but with very important technical = extensions.
The demonstration platform will perform :

A) VPN = interoperability (gateway to gateway)
B) Certificate based = authentication=20 (PKI compliance)
C) Hybrid IPv4/IPv6 based network =

The demonstration platform, developped and managed by HSC, = is still=20 welcoming vendors wishing to demonstrate that their IPsec systems are = able to=20 interoperate at the gateway level. Vendors wishing to connect clients on = a=20 distant access mode are also welcome.

The=20 demonstrartion network will also integrate a certificate authority = component=20 (PKI)
Above all, the network will be = able to=20 implement IPv4 and IPv6 tunnels.

More details at:

http://www.up= perside.fr/ipsec2001/ipsec01intro.htm

<= /DIV>
 
------=_NextPart_000_0093_01C1314A.5C844DC0-- From owner-ipsec-policy@mail.vpnc.org Thu Aug 30 14:19: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 OAA24368 for ; Thu, 30 Aug 2001 14:19:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7UHXZB13576 for ipsec-policy-bks; Thu, 30 Aug 2001 10:33:35 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UHXXD13572 for ; Thu, 30 Aug 2001 10:33:33 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7UHYmI13697 for ; Thu, 30 Aug 2001 12:34:49 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 12:33:34 -0500 content-class: urn:content-classes:message Subject: RE: ipSecIfCapsTable PIB-ACCESS value Date: Thu, 30 Aug 2001 12:33:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: ipSecIfCapsTable PIB-ACCESS value Thread-Index: AcEq5OqDQoZm0JbXEdWJUgAIx6TWpQGlLDHA From: "Li Man.M (NRC/Boston)" To: "'ext MORAND Pierrick FTRD/DMI/CAE'" , "Li Man.M (NRC/Boston)" , "IPSEC-POLICY (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7UHXXD13573 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks Pierrick. It will be corrected in the next version. Best regards Man -----Original Message----- From: ext MORAND Pierrick FTRD/DMI/CAE [mailto:pierrick.morand@rd.francetelecom.com] Sent: August 22, 2001 03:48 AM To: 'Li Man.M (NRC/Boston)'; IPSEC-POLICY (E-mail) Subject: RE: ipSecIfCapsTable PIB-ACCESS value Hi Man, I have also noted the following in the last version 03 of the draft. ipSecIkeAssociationTable has the {ipSecIkeAssociation 6 } object-id assigned (see page 31) and the ipSecCredentialFieldsTable has the same value (see page 44). Have a nice day. Pierrick -----Message d'origine----- De : Li Man.M (NRC/Boston) [mailto:Man.M.Li@nokia.com] Envoyé : lundi 20 août 2001 17:38 À : 'ext MORAND Pierrick FTRD/DMI/CAE'; IPSEC-POLICY (E-mail) Objet : RE: ipSecIfCapsTable PIB-ACCESS value Hi Pierrick, Thanks for pointing this out. You are correct. I forgot to change it after cut and paste. Next version will have it changed. Man -----Original Message----- From: ext MORAND Pierrick FTRD/DMI/CAE [mailto:pierrick.morand@rd.francetelecom.com] Sent: August 09, 2001 03:43 AM To: IPSEC-POLICY (E-mail) Subject: ipSecIfCapsTable PIB-ACCESS value Hi ! The PIB-ACCESS clause for the ipSecIfCapsTable has been set to "install" in the last draft-ietf-ipsp-ipsecpib-03.text document. This means that the PDP could modify these values or add new instances. In other word a PDP could modify, as I understand it, the capabilties of an interface type. Shouldn't the value be set to "notify" instead ? Thanks. Pierrick Morand france telecom R&D/DMI/SIR/IPI Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 Email :pierrick.morand@rd.francetelecom.com