From msec-admin@securemulticast.org Wed Aug 1 10:23:33 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05096 for ; Wed, 1 Aug 2001 10:23:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3ADB053544; Wed, 1 Aug 2001 10:24:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1876C5353C for ; Wed, 1 Aug 2001 10:22:38 -0400 (EDT) Received: (qmail 92534 invoked by uid 3269); 1 Aug 2001 14:22:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 92531 invoked from network); 1 Aug 2001 14:22:37 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 1 Aug 2001 14:22:37 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f71ECQg06489; Wed, 1 Aug 2001 10:12:31 -0400 (EDT) Message-Id: <5.0.0.25.2.20010801100403.0190bae0@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Lee Fu-yuan , msec@securemulticast.org From: Thomas Hardjono Subject: Re: [MSEC] Loss of key update message ? In-Reply-To: <20010803225101.A55652@ccbsd7.csie.nctu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 01 Aug 2001 10:12:17 -0400 Lee, This is a very good question. In the SMuG/MSEC work, there was initially a kind of chicken-and-egg problem. That is, secure-multicast needs reliability in key management messages (thus needs a RM protocol), but the reliable-multicast (RM) protocols in turn needed security. Also, although the RM protocols had a general set of security requirements, when it comes to detailed designs, each had additional specific security requirements. In order to proceed, the SMuG/MSEC efforts assumed that unidirectional key management messages from the Key Distributorn would not rely on an RM protocol, but would simply send the message multiple times. This general problem, I think, needs general study in the context of real-world applications. Other related work would be the combination of layered coding (ie. ALC) and layered multicast with key management. Thus, this combines reliability and the in-stream delivery of key management messages. thomas ------ At 8/3/2001||10:51 PM, Lee Fu-yuan wrote: >hi all: > > I am so interested at the key management issues of multicast. > After reading some papers, I found that currently proposed > mechanisms seldom mentioned about packet loss in their schemes. > Is it true that all the currently proposed scheme assume that > a reliable multicast system is deployed ? > In the KeyStone system which is proposed by Chung Kei Wong, forward > error correction is used to reduce the probability of loss of key > update message. Are there any other papers that have discussed the > impact of packet loss ? > > Best regards. > >-- >Lee, Fu-Yuan >Distributed System and Network Security Lab. >Dept. of Comp. Sci. & Info. Eng >Nat'l Chiao Tung Univ. >Hsinchu, Taiwan 30050, ROC >E-Mail: leefy@csie.nctu.edu.tw > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 2 21:49:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08260 for ; Thu, 2 Aug 2001 21:49:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E0B285362C; Thu, 2 Aug 2001 21:50:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id EA2EB5353B for ; Thu, 2 Aug 2001 21:30:56 -0400 (EDT) Received: (qmail 41299 invoked by uid 3269); 3 Aug 2001 01:30:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41296 invoked from network); 3 Aug 2001 01:30:56 -0000 Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157) by klesh.pair.com with SMTP; 3 Aug 2001 01:30:56 -0000 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 f731Tv911909 for ; Thu, 2 Aug 2001 21:29:57 -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> 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 Content-Type: multipart/mixed; boundary="------------700C1CE7C41A16595853A0C3" X-Orig: Subject: [MSEC] Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 02 Aug 2001 21:33:47 -0400 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-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 2 22:45:15 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08261 for ; Thu, 2 Aug 2001 21:49:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 197A153545; Thu, 2 Aug 2001 21:50:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6D51853681 for ; Thu, 2 Aug 2001 10:27:30 -0400 (EDT) Received: (qmail 55488 invoked by uid 3269); 2 Aug 2001 14:27:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55419 invoked from network); 2 Aug 2001 14:27:28 -0000 Received: from penguin-ext.wise.edt.ericsson.se (194.237.142.110) by klesh.pair.com with SMTP; 2 Aug 2001 14:27:28 -0000 Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f72ERNO12221 for ; Thu, 2 Aug 2001 16:27:23 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Aug 02 16:27:21 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 16:27:21 +0200 Message-ID: From: "Elisabetta Carrara (ERA)" To: "'msec@securemulticast.org'" , "'avt@ietf.org'" Cc: "David A. McGrew (E-mail)" , "David Oran (E-mail)" , "Jari Arkko (LMF)" , "Fredrik Lindholm (ERA)" , =?iso-8859-1?Q?Mats_N=E4slund_=28ERA=29_=5Bmats=2Enaslund=40era-t=2Eer?= =?iso-8859-1?Q?icsson=2Ese=5D_=28E-mail=29?= MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] drafts on security for multimedia Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 2 Aug 2001 16:27:15 +0200 Hi we would like to draw the attention on some work we are doing on the issue of security for (conversational) multimedia. A security protocol for RTP (SRTP) is currently working group item in the AVT WG. There are then two new (related) drafts about key management, which will be presented in the MSEC WG, and reported to AVT. You can find the abstracts in the following. Thanks, cheers /Elisabetta ----------------------------------------------------------------------------------------------------------------------- "The Secure Real Time Transport Protocol" Abstract: This document describes the Secure Real Time Transport Protocol (SRTP), a profile of the Real Time Transport Protocol (RTP) which can provide confidentiality, message authentication (in groups, also source origin authentication), replay protection, and implicit header authentication. SRTP can achieve high throughput and low packet expansion by using an additive stream cipher for encryption, a universal hashing based function for message authentication, and an 'implicit' index for sequencing based on the RTP sequence number. Robust and flexible re-keying/access control to media can be achieved through an optional security parameter index (SPI). In addition, SRTP proves to be a suitable protection for heterogeneous environments, i.e. environments including both wired and wireless links. ------------------ "Design Criteria for Multimedia Session Key Management in Heterogeneous Networks" Abstract: For conversational multimedia to take off, many important aspects have still to be fully investigated. The security framework is one of them. While some proposals on how to secure the media traffic have appeared, a key management solution has still to be developed. It should take into account the conversational multimedia type of scenario and an heterogeneous communication environment, in which thin clients are used. Such a scenario will result in a number of challenging requirements. The purpose of this document is to describe the scenario and to list constraints and requirements on a key management scheme for media traffic in conversational multimedia. ---------------- "Key Management for Multimedia Sessions" Abstract: Some work for securing real-time applications have started to appear, and it has also brought the need for a key management infrastructure to support the security protocol. Such key management has to fulfil requirements suitable for conversational multimedia in heterogeneous environment. This document describes a key management scheme that can be used for real-time applications, and shows some examples of how such scheme can be implemented. ----------------------------------------------------------------------------------------------------------- ======================= Elisabetta Carrara Ericsson Research, Sweden +46 850877040 ======================= _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 08:50:01 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14838 for ; Fri, 3 Aug 2001 08:50:00 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0D78F53630; Fri, 3 Aug 2001 08:50:27 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6206B53530 for ; Fri, 3 Aug 2001 08:49:12 -0400 (EDT) Received: (qmail 95308 invoked by uid 3269); 3 Aug 2001 12:49:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95303 invoked from network); 3 Aug 2001 12:49:11 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 3 Aug 2001 12:49:11 -0000 Received: from THARDJONO-LAP.mediaone.net (h0010a4c49f9e.ne.mediaone.net [24.128.44.121]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f73Cn9c12465; Fri, 3 Aug 2001 08:49:09 -0400 (EDT) Message-Id: <5.0.0.25.2.20010803084727.01889698@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: mbaugher@cisco.com, bew@cisco.com, canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 08:48:52 -0400 Folks, Please read. There is a mention of MSEC and GDOI. thomas ------ >MBOX-Line: From owner-ipsec-policy@mail.vpnc.org Fri Aug 03 03:06:30 2001 >X-Yahoo-Forwarded: from thardjono@yahoo.com to thardjono@mediaone.net >X-Track: 11: 40 >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 >To: msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, > ipsec@lists.tislabs.com >Subject: Position statement on IKE development >X-Orig: >Sender: owner-ipsec-policy@mail.vpnc.org >List-Archive: >List-ID: >List-Unsubscribe: > >I'm sending the attached ASCII TEXT document on behalf of myself, Jeff >Schiller, and > Steve Bellovin, to clarify our position with respect to IKE >development. It is our hope > that it will clarify, to some extent, some fuzziness in this area that >has evolved over > the last year or so.In the several years since the standardization of > the IPSEC protocols >(ESP, AH, and ISAKMP/IKE), there have come to light several security >problems with the protocols, most notably the key-agreement protocol, >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and >Simpson, have shown that the security problems in IKE stem directly >from its complexity. It seems only a matter of time before more >analyses show more serious security issues in the protocol design that >stem directly from its complexity. It seems also, only a matter of >time, before serious *implementation* problems become apparent, again >due to the complex nature of the protocol, and the complex >implementation that must surely follow. > >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) _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 19:00:53 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00484 for ; Fri, 3 Aug 2001 19:00:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 352E353640; Fri, 3 Aug 2001 19:00:10 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 378335363D for ; Fri, 3 Aug 2001 18:58:27 -0400 (EDT) Received: (qmail 57520 invoked by uid 3269); 3 Aug 2001 22:58:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57517 invoked from network); 3 Aug 2001 22:58:08 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 3 Aug 2001 22:58:08 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f73MvAY11044; Fri, 3 Aug 2001 15:57:10 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (ams-vpdn-client-10.cisco.com [144.254.46.11]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAN22725; Fri, 3 Aug 2001 15:56:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20010803155109.04464d58@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Alex Alten From: Mark Baugher Cc: msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <3.0.3.32.20010802220454.00fc0530@mail> References: <3B69FF7B.85CF61@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 15:56:02 -0700 Ferguson and Schneier suggested the same thing as an alternative to design-by-committee, which they suggested was the source of problems with IPsec and IKE. When I read this, I did not think it was a viable solution because the IPsec and IKE requirements were so much more complex than AES. I don't think their criticisms of IKE were ever addressed on this list though the points about AH and ESP were as I recall. Mark At 10:04 PM 8/2/2001 -0700, Alex Alten wrote: >Dear Marcus, Jeff and Steve, > >May I make a suggestion given the seriousness of this? > >Let's hold an international design competition to select a key >management protocol for IPSec in a manner similar to how NIST did >the AES selection (although I hope it takes less than 5 years). >Once we get to a final 5, then let's cryptanalyze them and select >the best one. In this manner hopefully we can avoid a 2nd debacle. > >Sincerely, > >- Alex Alten > > >At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote: > >I'm sending the attached ASCII TEXT document on behalf of myself, Jeff > >Schiller, and > > Steve Bellovin, to clarify our position with respect to IKE > >development. It is our hope > > that it will clarify, to some extent, some fuzziness in this area that > >has evolved over > > the last year or so.In the several years since the standardization of >the IPSEC protocols > >(ESP, AH, and ISAKMP/IKE), there have come to light several security > >problems with the protocols, most notably the key-agreement protocol, > >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and > >Simpson, have shown that the security problems in IKE stem directly > >from its complexity. It seems only a matter of time before more > >analyses show more serious security issues in the protocol design that > >stem directly from its complexity. It seems also, only a matter of > >time, before serious *implementation* problems become apparent, again > >due to the complex nature of the protocol, and the complex > >implementation that must surely follow. > >... > > > > > > >Marcus Leech (IESG) > >Jeff Schiller (IESG) > >Steve Bellovin (IAB) > > >-- > >Alex Alten > >Alten@Home.Com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 19:04:44 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00524 for ; Fri, 3 Aug 2001 19:04:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 59EB553646; Fri, 3 Aug 2001 19:04:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id F2CC153663 for ; Fri, 3 Aug 2001 19:02:23 -0400 (EDT) Received: (qmail 57751 invoked by uid 3269); 3 Aug 2001 23:02:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57747 invoked from network); 3 Aug 2001 23:02:18 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 3 Aug 2001 23:02:18 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f73MxsJ01567; Fri, 3 Aug 2001 15:59:57 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (ams-vpdn-client-10.cisco.com [144.254.46.11]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAN22869; Fri, 3 Aug 2001 16:01:37 -0700 (PDT) Message-Id: <4.3.2.7.2.20010803155701.0445ced0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lee Fu-yuan From: Mark Baugher Subject: Re: [MSEC] Loss of key update message ? Cc: msec@securemulticast.org In-Reply-To: <20010803225101.A55652@ccbsd7.csie.nctu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 16:00:48 -0700 Hi This issue had been discussed in the IRTF meetings in the past. I don't think we have done a good job of bringing this discussion into the msec key management documents until recently: The issue of reliable distribution of multicast messages is mentioned in draft-ietf-msec-gkmarch-00.txt only to the extent of requirements that must be satisfied by the "re-key" protocol. There is a draft on the re-key protocol to be submitted under the auspices of msec that will discuss the problem of message loss of key management messages that are sent via multicast. I expect we will see this draft this summer or early fall. Mark At 10:51 PM 8/3/2001 +0800, Lee Fu-yuan wrote: >hi all: > > I am so interested at the key management issues of multicast. > After reading some papers, I found that currently proposed > mechanisms seldom mentioned about packet loss in their schemes. > Is it true that all the currently proposed scheme assume that > a reliable multicast system is deployed ? > In the KeyStone system which is proposed by Chung Kei Wong, forward > error correction is used to reduce the probability of loss of key > update message. Are there any other papers that have discussed the > impact of packet loss ? > > Best regards. > >-- >Lee, Fu-Yuan >Distributed System and Network Security Lab. >Dept. of Comp. Sci. & Info. Eng >Nat'l Chiao Tung Univ. >Hsinchu, Taiwan 30050, ROC >E-Mail: leefy@csie.nctu.edu.tw > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:18:33 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04693 for ; Fri, 3 Aug 2001 23:18:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AA40D53554; Fri, 3 Aug 2001 23:19:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1C75B5361F for ; Fri, 3 Aug 2001 01:06:23 -0400 (EDT) Received: (qmail 60999 invoked by uid 3269); 3 Aug 2001 05:06:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60996 invoked from network); 3 Aug 2001 05:06:22 -0000 Received: from femail48.sdc1.sfba.home.com (24.254.60.42) by klesh.pair.com with SMTP; 3 Aug 2001 05:06:22 -0000 Received: from c1286160-a ([65.0.174.146]) by femail48.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010803050616.GBMZ1457.femail48.sdc1.sfba.home.com@c1286160-a>; Thu, 2 Aug 2001 22:06:16 -0700 Message-Id: <3.0.3.32.20010802220454.00fc0530@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) To: "Marcus Leech" , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com From: Alex Alten In-Reply-To: <3B69FF7B.85CF61@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 02 Aug 2001 22:04:54 -0700 Dear Marcus, Jeff and Steve, May I make a suggestion given the seriousness of this? Let's hold an international design competition to select a key management protocol for IPSec in a manner similar to how NIST did the AES selection (although I hope it takes less than 5 years). Once we get to a final 5, then let's cryptanalyze them and select the best one. In this manner hopefully we can avoid a 2nd debacle. Sincerely, - Alex Alten At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote: >I'm sending the attached ASCII TEXT document on behalf of myself, Jeff >Schiller, and > Steve Bellovin, to clarify our position with respect to IKE >development. It is our hope > that it will clarify, to some extent, some fuzziness in this area that >has evolved over > the last year or so.In the several years since the standardization of the IPSEC protocols >(ESP, AH, and ISAKMP/IKE), there have come to light several security >problems with the protocols, most notably the key-agreement protocol, >IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and >Simpson, have shown that the security problems in IKE stem directly >from its complexity. It seems only a matter of time before more >analyses show more serious security issues in the protocol design that >stem directly from its complexity. It seems also, only a matter of >time, before serious *implementation* problems become apparent, again >due to the complex nature of the protocol, and the complex >implementation that must surely follow. ... > > >Marcus Leech (IESG) >Jeff Schiller (IESG) >Steve Bellovin (IAB) > -- Alex Alten Alten@Home.Com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:18:40 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04703 for ; Fri, 3 Aug 2001 23:18:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EAFC953625; Fri, 3 Aug 2001 23:19:06 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3846B5358B for ; Fri, 3 Aug 2001 02:51:19 -0400 (EDT) Received: (qmail 67668 invoked by uid 3269); 3 Aug 2001 06:51:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67665 invoked from network); 3 Aug 2001 06:51:18 -0000 Received: from femail46.sdc1.sfba.home.com (24.254.60.40) by klesh.pair.com with SMTP; 3 Aug 2001 06:51:18 -0000 Received: from c1286160-a ([65.0.174.146]) by femail46.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010803065112.IUFR16795.femail46.sdc1.sfba.home.com@c1286160-a>; Thu, 2 Aug 2001 23:51:12 -0700 Message-Id: <3.0.3.32.20010802234951.00e4eb00@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) To: "Marcus Leech" , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com From: Alex Alten In-Reply-To: <3.0.3.32.20010802220454.00fc0530@mail> References: <3B69FF7B.85CF61@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 02 Aug 2001 23:49:51 -0700 After just reading the papers by Meadows, Schneier/Ferguson and Simpson, I now have serious doubts that IPsec delivers the security required by the Internet community. This is a very serious issue. To make a mistake of this caliber when so many firms have committed large amounts of resources for software, board, ASIC and chip designs, implementations and manufactures is a terrible thing. I agree with Schneier & Ferguson. A security protocol/system cannot be designed by a large committee, unlike many other successful insecure protocols. Their suggestion to use a process like NIST's for selecting the AES standard is an excellent one. It's a pity they did not suggest it a decade ago. However it should be considered seriously not only for the replacement of IKE, but possibly also for the modification or simplification of the entire IPsec protocol suite. (I hesitate to say the replacement of IPSEC given the tremendous repercussions of doing so.) - Alex At 10:04 PM 8/2/2001 -0700, Alex Alten wrote: > >Dear Marcus, Jeff and Steve, > >May I make a suggestion given the seriousness of this? > >Let's hold an international design competition to select a key >management protocol for IPSec in a manner similar to how NIST did >the AES selection (although I hope it takes less than 5 years). >Once we get to a final 5, then let's cryptanalyze them and select >the best one. In this manner hopefully we can avoid a 2nd debacle. > >Sincerely, > >- Alex Alten > > >At 09:33 PM 8/2/2001 -0400, Marcus Leech wrote: >>I'm sending the attached ASCII TEXT document on behalf of myself, Jeff >>Schiller, and >> Steve Bellovin, to clarify our position with respect to IKE >>development. It is our hope >> that it will clarify, to some extent, some fuzziness in this area that >>has evolved over >> the last year or so.In the several years since the standardization of >the IPSEC protocols >>(ESP, AH, and ISAKMP/IKE), there have come to light several security >>problems with the protocols, most notably the key-agreement protocol, >>IKE. Formal and semi-formal analyses by Meadows, Schneier et al, and >>Simpson, have shown that the security problems in IKE stem directly >>from its complexity. It seems only a matter of time before more >>analyses show more serious security issues in the protocol design that >>stem directly from its complexity. It seems also, only a matter of >>time, before serious *implementation* problems become apparent, again >>due to the complex nature of the protocol, and the complex >>implementation that must surely follow. > >... > >> >> >>Marcus Leech (IESG) >>Jeff Schiller (IESG) >>Steve Bellovin (IAB) >> >-- > >Alex Alten > >Alten@Home.Com > > > -- Alex Alten Alten@Home.Com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:19:18 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04716 for ; Fri, 3 Aug 2001 23:19:17 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2AD8853653; Fri, 3 Aug 2001 23:19:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 63FF653533 for ; Fri, 3 Aug 2001 09:34:40 -0400 (EDT) Received: (qmail 751 invoked by uid 3269); 3 Aug 2001 13:34:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 748 invoked from network); 3 Aug 2001 13:34:39 -0000 Received: from storm.ca (HELO mail.storm.ca) (209.87.239.69) by klesh.pair.com with SMTP; 3 Aug 2001 13:34:39 -0000 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> 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 References: <3B69FF7B.85CF61@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 09:34:33 -0400 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:20:19 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04740 for ; Fri, 3 Aug 2001 23:20:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 166F553662; Fri, 3 Aug 2001 23:19:11 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 8A04A53638 for ; Fri, 3 Aug 2001 10:23:06 -0400 (EDT) Received: (qmail 5537 invoked by uid 3269); 3 Aug 2001 14:23:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5534 invoked from network); 3 Aug 2001 14:23:05 -0000 Received: from spsystems.net (209.47.149.227) by klesh.pair.com with SMTP; 3 Aug 2001 14:23:05 -0000 Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id KAA12706; 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 In-Reply-To: <3.0.3.32.20010802234951.00e4eb00@mail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 3 Aug 2001 10:21:49 -0400 (EDT) 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:21:15 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04754 for ; Fri, 3 Aug 2001 23:21:15 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D395D53666; Fri, 3 Aug 2001 23:19:12 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 19B5653575 for ; Fri, 3 Aug 2001 14:25:36 -0400 (EDT) Received: (qmail 34122 invoked by uid 3269); 3 Aug 2001 18:25:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34119 invoked from network); 3 Aug 2001 18:25:35 -0000 Received: from femail47.sdc1.sfba.home.com (imail@24.254.60.41) by klesh.pair.com with SMTP; 3 Aug 2001 18:25:35 -0000 Received: from c1286160-a ([65.0.174.146]) by femail47.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010803182533.ZDXZ3475.femail47.sdc1.sfba.home.com@c1286160-a>; Fri, 3 Aug 2001 11:25:33 -0700 Message-Id: <3.0.3.32.20010803112414.00eadaa0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) To: Henry Spencer From: Alex Alten Cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: References: <3.0.3.32.20010802234951.00e4eb00@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 11:24:14 -0700 Several people have asked me for the urls of the paper's analyzing IPsec and IKE. These are the ones I found searching the web last night. A Cryptographic Evaluation of IPsec by Niels Ferguson and Bruce Schneier http://www.counterpane.com/ipsec.pdf Analysis of the Internet Key Exchange Protocol Using the NRL Protocol Analyzer by Catherine Meadows http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/1999/1999meadows-IEE E99.ps IKE/ISAKMP Considered Dangerous by William Simpson draft-simpson-danger-isakmp-01.txt http://www.alternic.org/drafts/drafts-s-t/draft-simpson-danger-isakmp-01.html BTW Henry, The issue is not that parts of IPsec are superfluous. The question is if IKE is broken then is IPsec also broken? - Alex At 10:21 AM 8/3/2001 -0400, Henry Spencer wrote: >On Thu, 2 Aug 2001, Alex Alten wrote: >> ...Their suggestion to use a process like NIST's for selecting >> the AES standard is an excellent one. It's a pity they did not suggest >> it a decade ago. However it should be considered seriously not only >> for the replacement of IKE, but possibly also for the modification or >> simplification of the entire IPsec protocol suite... > >I think this is throwing the baby out with the bathwater. > >While the packet-level parts (ESP etc.) do have some flaws, most of those >can be fixed simply by taking a big black pen and crossing out superfluous >parts of the existing specs (e.g., all of RFC 2402). While there is room >for some debate about exactly which parts should be crossed out (e.g., >there are people who still think AH is useful), I think there would be >little or no support for redesigning the surviving parts. So a design >competition does not seem very useful in this area. Moreover, *this* is >the area where there is massive investment in silicon, solder traces, etc. >Just deleting features does not, by and large, invalidate that investment. > >IKE is the disaster area. The rest of IPsec could use some judicious >featurectomies, but is not badly broken. > > Henry Spencer > henry@spsystems.net > > > -- Alex Alten Alten@Home.Com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:22:20 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04771 for ; Fri, 3 Aug 2001 23:22:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C33E55366A; Fri, 3 Aug 2001 23:19:14 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6D33953591 for ; Fri, 3 Aug 2001 14:47:30 -0400 (EDT) Received: (qmail 35896 invoked by uid 3269); 3 Aug 2001 18:47:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35891 invoked from network); 3 Aug 2001 18:47:29 -0000 Received: from mercury.sun.com (192.9.25.1) by klesh.pair.com with SMTP; 3 Aug 2001 18:47:29 -0000 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> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking 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 Subject: [MSEC] Another paper analyzing IKE Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 3 Aug 2001 14:47:15 -0400 (EDT) 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:23:30 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04785 for ; Fri, 3 Aug 2001 23:23:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 163845366E; Fri, 3 Aug 2001 23:19:17 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 36E8F53543 for ; Fri, 3 Aug 2001 15:43:10 -0400 (EDT) Received: (qmail 42501 invoked by uid 3269); 3 Aug 2001 19:43:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 42498 invoked from network); 3 Aug 2001 19:43:09 -0000 Received: from spsystems.net (209.47.149.227) by klesh.pair.com with SMTP; 3 Aug 2001 19:43:09 -0000 Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id PAA17233; 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 In-Reply-To: <3.0.3.32.20010803112414.00eadaa0@mail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 3 Aug 2001 15:41:57 -0400 (EDT) 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:24:28 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04798 for ; Fri, 3 Aug 2001 23:24:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F1E5053672; Fri, 3 Aug 2001 23:19:18 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 056AF5354C for ; Fri, 3 Aug 2001 16:21:52 -0400 (EDT) Received: (qmail 46524 invoked by uid 3269); 3 Aug 2001 20:21:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46521 invoked from network); 3 Aug 2001 20:21:51 -0000 Received: from femail38.sdc1.sfba.home.com (24.254.60.32) by klesh.pair.com with SMTP; 3 Aug 2001 20:21:51 -0000 Received: from c1286160-a ([65.0.174.146]) by femail38.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010803202145.IOVD27925.femail38.sdc1.sfba.home.com@c1286160-a>; Fri, 3 Aug 2001 13:21:45 -0700 Message-Id: <3.0.3.32.20010803132027.00eae6b0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) To: Henry Spencer From: Alex Alten Cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: References: <3.0.3.32.20010803112414.00eadaa0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 13:20:27 -0700 Unfortunately what you and I think probably doesn't matter. What matters is that end user customers will hear that IPsec's IKE is broken, and they will then ask themselves the question, is all of IPsec also broken? It's anyone's guess as to how this will play out in the VPN markets, etc. My own personal question is why the IPsec working group did not have a thorough cryptanalysis done by professionals, say by an outfit like ISSI, before the standards were issued? - Alex At 03:41 PM 8/3/2001 -0400, Henry Spencer wrote: >On Fri, 3 Aug 2001, Alex Alten wrote: >> BTW Henry, >> The issue is not that parts of IPsec are superfluous. >> The question is if IKE is broken then is IPsec also broken? > >That depends somewhat on exactly what you mean by "IPsec", which is why I >specifically referred to "the packet-level parts". I don't think there is >much wrong with the packet-level stuff except for a few too many useless >options and alternatives. The key-management ugliness doesn't seem to me >to have spilled over into the packet level (at least partly because the >packet-level work was nearly finished before key management came to the >fore). > > Henry Spencer > henry@spsystems.net > > -- Alex Alten Alten@Home.Com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:25:17 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04821 for ; Fri, 3 Aug 2001 23:25:17 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D147353676; Fri, 3 Aug 2001 23:19:20 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CA93153556 for ; Fri, 3 Aug 2001 16:37:32 -0400 (EDT) Received: (qmail 47636 invoked by uid 3269); 3 Aug 2001 20:37:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 47633 invoked from network); 3 Aug 2001 20:37:32 -0000 Received: from eagle.verisign.com (208.206.241.105) by klesh.pair.com with SMTP; 3 Aug 2001 20:37:32 -0000 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11C5C.14D9EDC0" Subject: [MSEC] RE: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 3 Aug 2001 13:37:15 -0700 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-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:26:10 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04834 for ; Fri, 3 Aug 2001 23:26:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 901E05367A; Fri, 3 Aug 2001 23:19:22 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A0C84535FC for ; Fri, 3 Aug 2001 17:18:59 -0400 (EDT) Received: (qmail 51224 invoked by uid 3269); 3 Aug 2001 21:18:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51221 invoked from network); 3 Aug 2001 21:18:58 -0000 Received: from orange-tour.ihtfp.org (HELO rcn.ihtfp.org) (me@204.107.200.33) by klesh.pair.com with SMTP; 3 Aug 2001 21:18:58 -0000 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 References: <2F3EC696EAEED311BB2D009027C3F4F40154CA41@vhqpostal.verisign.com> From: Derek Atkins 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 Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: 03 Aug 2001 17:18:11 -0400 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:27:02 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04852 for ; Fri, 3 Aug 2001 23:27:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F3B8F5367E; Fri, 3 Aug 2001 23:19:24 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 28B48535EA for ; Fri, 3 Aug 2001 17:45:53 -0400 (EDT) Received: (qmail 53024 invoked by uid 3269); 3 Aug 2001 21:45:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53021 invoked from network); 3 Aug 2001 21:45:52 -0000 Received: from patan.sun.com (192.18.98.43) by klesh.pair.com with SMTP; 3 Aug 2001 21:45:52 -0000 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 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 Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 17:45:05 -0400 > 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.. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:27:46 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04864 for ; Fri, 3 Aug 2001 23:27:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B498B53682; Fri, 3 Aug 2001 23:19:26 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 73D44535EF for ; Fri, 3 Aug 2001 18:02:02 -0400 (EDT) Received: (qmail 53975 invoked by uid 3269); 3 Aug 2001 22:02:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53972 invoked from network); 3 Aug 2001 22:02:01 -0000 Received: from ns1.sailpix.com (HELO tailor.sailpix.com) (155.53.1.250) by klesh.pair.com with SMTP; 3 Aug 2001 22:02:01 -0000 Received: from atty.lounge.org (tycho-205-179-127-183.tychonet.com [205.179.127.183]) by tailor.sailpix.com (Postfix) with ESMTP id C6E3854C66; Fri, 3 Aug 2001 15:01:54 -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 f73Lwxd01332; Fri, 3 Aug 2001 14:59:27 -0700 (PDT) (envelope-from dharkins@lounge.org) Message-Id: <200108032159.f73Lwxd01332@dharkins@lounge.orgatty.lounge.org> To: Alex Alten Cc: Henry Spencer , Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: Your message of "Fri, 03 Aug 2001 11:24:14 PDT." <3.0.3.32.20010803112414.00eadaa0@mail> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1329.996875939.1@lounge.org> From: Dan Harkins Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 14:58:59 -0700 On Fri, 03 Aug 2001 11:24:14 PDT you wrote > > BTW Henry, > > The issue is not that parts of IPsec are superfluous. > > The question is if IKE is broken then is IPsec also broken? > > - Alex No, of course not. And you are assuming that IKE is broken. What has been noted by all the analysis mentiond so far is that IKE is too complex to know whether it is broken or not. The effort is to make it less complex, get rid of unnecessary and unused options, get rid of the inconsistent and sometimes contradictory verbage between the 3 RFCs, and make it a specification of a key management protocol for IPsec and IPsec only instead of the current instantiation (RFC2407) of a protocol framework (RFC2409) of a generic language (RFC2408). Dan. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:28:46 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04877 for ; Fri, 3 Aug 2001 23:28:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 91F2653686; Fri, 3 Aug 2001 23:19:28 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 808305359D for ; Fri, 3 Aug 2001 18:02:33 -0400 (EDT) Received: (qmail 54023 invoked by uid 3269); 3 Aug 2001 22:02:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54020 invoked from network); 3 Aug 2001 22:02:32 -0000 Received: from beach.securecomputing.com (HELO beach.sctc.com) (192.55.214.50) by klesh.pair.com with SMTP; 3 Aug 2001 22:02:32 -0000 Received: from beach.sctc.com (root@localhost) by beach.sctc.com with ESMTP id f73LgVD11534; Fri, 3 Aug 2001 16:42:31 -0500 (CDT) Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com with ESMTP id f73LgVm11530; Fri, 3 Aug 2001 16:42:31 -0500 (CDT) Received: from phlox.rose-dev (phlox.sctc.com [192.168.12.101]) by sphinx.sctc.com (8.8.8+Sun/8.7.3) with ESMTP id RAA01493; Fri, 3 Aug 2001 17:02:17 -0500 (CDT) Received: from stp2klp82751.securecomputing.com (atddhcp-3.sctc.com [172.17.68.3]) by phlox.rose-dev (8.9.3+Sun/) with ESMTP id RAA20245; Fri, 3 Aug 2001 17:02:18 -0500 (CDT) Message-Id: <4.3.2.7.0.20010803164227.01c2fab0@STPNTMX03.sctc.com> X-Sender: smith@STPNTMX03.sctc.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Alex Alten From: Rick Smith at Secure Computing Cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <3.0.3.32.20010803132027.00eae6b0@mail> References: <3.0.3.32.20010803112414.00eadaa0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 16:58:09 -0500 At 03:20 PM 8/3/2001, Alex Alten wrote: >Unfortunately what you and I think probably doesn't matter. What matters >is that end user customers will hear that IPsec's IKE is broken, and they >will then ask themselves the question, is all of IPsec also broken? It's >anyone's guess as to how this will play out in the VPN markets, etc. It's not as if VPN customers have a well-recognized alternative with a less tarnished reputation. If anything, this simply illustrates how much pioneering work has gone into IKE. >My own personal question is why the IPsec working group did not have a >thorough cryptanalysis done by professionals, say by an outfit like ISSI, >before the standards were issued? Some weaknesses emerge only after you've actually built and deployed a protocol. Such flaws may be in the implementation, but some may be faulty assumptions about how the protocol will work in a practical deployment. It's especially hard to predict problems when the protocol is the foundation of a fairly new class of products, like VPN gateways, since there's not enough well-known prior art to base the analytical models on. Rick. smith@securecomputing.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:29:27 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04889 for ; Fri, 3 Aug 2001 23:29:26 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 610F45368A; Fri, 3 Aug 2001 23:19:30 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C500D5353B for ; Fri, 3 Aug 2001 18:30:48 -0400 (EDT) Received: (qmail 56114 invoked by uid 3269); 3 Aug 2001 22:30:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56111 invoked from network); 3 Aug 2001 22:30:48 -0000 Received: from femail39.sdc1.sfba.home.com (24.254.60.33) by klesh.pair.com with SMTP; 3 Aug 2001 22:30:48 -0000 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 <20010803223041.LSXI2644.femail39.sdc1.sfba.home.com@c1286160-a>; Fri, 3 Aug 2001 15:30:41 -0700 Message-Id: <3.0.3.32.20010803152924.00ed6b10@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) To: Dan Harkins From: Alex Alten Cc: Henry Spencer , Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <200108032159.f73Lwxd01332@dharkins@lounge.orgatty.lounge.o rg> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 15:29:24 -0700 Quoting Marcus, Jeff and Steve: "The Security Area Directors have asked the IPSEC working group to come up with a replacement for IKE. This work is underway and is known in the community as "Son of IKE". " "If IKE is vulnerable, we must all share a burden of responsibility for allowing it to get to the state it is in and we must all work together to correct the problems." OK. IKE is not technically broken. But it sure sounds like someone is worried. Otherwise why bother with a replacement for IKE? It's rather ironic that the 802.11 wireless key management was broken just recently as well. - Alex At 02:58 PM 8/3/2001 -0700, Dan Harkins wrote: >On Fri, 03 Aug 2001 11:24:14 PDT you wrote >> >> BTW Henry, >> >> The issue is not that parts of IPsec are superfluous. >> >> The question is if IKE is broken then is IPsec also broken? >> >> - Alex > >No, of course not. > >And you are assuming that IKE is broken. What has been noted by all the >analysis mentiond so far is that IKE is too complex to know whether it >is broken or not. The effort is to make it less complex, get rid of >unnecessary and unused options, get rid of the inconsistent and sometimes >contradictory verbage between the 3 RFCs, and make it a specification of >a key management protocol for IPsec and IPsec only instead of the current >instantiation (RFC2407) of a protocol framework (RFC2409) of a generic >language (RFC2408). > > Dan. > > > > > -- Alex Alten Alten@Home.Com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 3 23:30:03 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04914 for ; Fri, 3 Aug 2001 23:30:03 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2A1225368E; Fri, 3 Aug 2001 23:19:32 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5072C53570 for ; Fri, 3 Aug 2001 21:03:36 -0400 (EDT) Received: (qmail 69201 invoked by uid 3269); 4 Aug 2001 01:03:35 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69198 invoked from network); 4 Aug 2001 01:03:35 -0000 Received: from coconut.itojun.org (210.160.95.97) by klesh.pair.com with SMTP; 4 Aug 2001 01:03:35 -0000 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 From: itojun@iijlab.net Message-ID: <6530.996887000@itojun.org> Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 04 Aug 2001 10:03:20 +0900 (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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 7 04:43:30 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27879 for ; Tue, 7 Aug 2001 04:43:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B9F4253678; Tue, 7 Aug 2001 04:44:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3A44953545 for ; Sat, 4 Aug 2001 02:12:11 -0400 (EDT) Received: (qmail 93577 invoked by uid 3269); 4 Aug 2001 06:12:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 93574 invoked from network); 4 Aug 2001 06:12:10 -0000 Received: from unknown (HELO internaut.com) (64.38.134.99) by klesh.pair.com with SMTP; 4 Aug 2001 06:12:10 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA95676; Fri, 3 Aug 2001 23:01:44 -0700 (PDT) (envelope-from aboba@internaut.com) From: Bernard Aboba To: Bill Sommerfeld Cc: Marcus Leech , msec@securemulticast.org, ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com In-Reply-To: <200108032145.f73Lj5J21336@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 3 Aug 2001 23:01:44 -0700 (PDT) > Let's hold an international design competition to select a key > management protocol for IPSec in a manner similar to how NIST did > the AES selection (although I hope it takes less than 5 years). > Once we get to a final 5, then let's cryptanalyze them and select > the best one. In this manner hopefully we can avoid a 2nd debacle. > In practice, such a competition is being held every day in the offices of customers. The problem is that the contenders are proprietary versions of IKE (IKE's evil sisters), that there is no cryptanalysis available, and that the decision criteria and selection are not openly discussed. I can state from experience that the "Cinderella IKE" that we now seek to shelter rarely wins these private beauty contests against the evil sisters. This is in part, because it is not a good match to customer requirements such as the need for NAT friendliness and a viable shared-secret authentication mode. It seems to me that unless we can find a "glass slipper" for Cinderella IKE, that it will languish as the evil sisters grow stronger and more popular. While we might not like this outcome, or feel that it is "right", the evidence is to strong to ignore. Cinderella IKE just isn't being invited to the ball. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 7 04:43:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27893 for ; Tue, 7 Aug 2001 04:43:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C8076537F9; Tue, 7 Aug 2001 04:44:06 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0F2DA5354C for ; Sat, 4 Aug 2001 09:40:22 -0400 (EDT) Received: (qmail 22362 invoked by uid 3269); 4 Aug 2001 13:13:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 22359 invoked from network); 4 Aug 2001 13:13:39 -0000 Received: from cust-p5-r2-242.pool.esr.clw.wwc.com (HELO berkshire.research.att.com) (168.151.1.242) by klesh.pair.com with SMTP; 4 Aug 2001 13:13:39 -0000 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20010804131251.B07AF7B5B@berkshire.research.att.com> Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 04 Aug 2001 09:12:51 -0400 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 7 04:45:07 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27943 for ; Tue, 7 Aug 2001 04:45:07 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7EBB153801; Tue, 7 Aug 2001 04:44:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 88E9953545 for ; Sat, 4 Aug 2001 17:43:46 -0400 (EDT) Received: (qmail 51807 invoked by uid 3269); 4 Aug 2001 21:43:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51804 invoked from network); 4 Aug 2001 21:43:46 -0000 Received: from femail39.sdc1.sfba.home.com (24.254.60.33) by klesh.pair.com with SMTP; 4 Aug 2001 21:43:46 -0000 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) To: "Steven M. Bellovin" , Henry Spencer From: Alex Alten 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" Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 04 Aug 2001 14:42:27 -0700 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 7 04:45:57 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27966 for ; Tue, 7 Aug 2001 04:45:56 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6A51A5380A; Tue, 7 Aug 2001 04:44:10 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1BA6353568 for ; Sat, 4 Aug 2001 19:02:06 -0400 (EDT) Received: (qmail 55668 invoked by uid 3269); 4 Aug 2001 23:02:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55665 invoked from network); 4 Aug 2001 23:02:05 -0000 Received: from host217-33-136-177.ietf.ignite.net (HELO berkshire.research.att.com) (217.33.136.177) by klesh.pair.com with SMTP; 4 Aug 2001 23:02:05 -0000 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20010804230025.A59117B5B@berkshire.research.att.com> Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sun, 05 Aug 2001 00:00:25 +0100 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 7 04:46:43 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27994 for ; Tue, 7 Aug 2001 04:46:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 396DA5380E; Tue, 7 Aug 2001 04:44:12 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0DE705354C for ; Sun, 5 Aug 2001 15:01:38 -0400 (EDT) Received: (qmail 60635 invoked by uid 3269); 5 Aug 2001 19:01:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60632 invoked from network); 5 Aug 2001 19:01:37 -0000 Received: from femail25.sdc1.sfba.home.com (24.254.60.15) by klesh.pair.com with SMTP; 5 Aug 2001 19:01:37 -0000 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) To: "Steven M. Bellovin" From: Alex Alten 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" Subject: [MSEC] Re: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sun, 05 Aug 2001 12:00:24 -0700 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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 7 04:47:32 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28006 for ; Tue, 7 Aug 2001 04:47:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EA5F653812; Tue, 7 Aug 2001 04:44:13 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7C69A53537 for ; Mon, 6 Aug 2001 12:04:41 -0400 (EDT) Received: (qmail 69751 invoked by uid 3269); 6 Aug 2001 16:04:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69748 invoked from network); 6 Aug 2001 16:04:40 -0000 Received: from ns0.gdgsc.com (HELO Newman.GSC.GTE.Com) (192.160.62.66) by klesh.pair.com with SMTP; 6 Aug 2001 16:04:40 -0000 Received: from gscex01.ndhm.gsc.gte.com ("port 1246"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V6.0-24 #38231) with ESMTP id <01K6TA3MQ0R8003NTN@Newman.GSC.GTE.Com> for msec@securemulticast.org; Mon, 06 Aug 2001 12:04:29 -0400 (EDT) Received: by gscex01.ndhm.gsc.gte.com with Internet Mail Service (5.5.2653.19) id ; Mon, 06 Aug 2001 12:04:57 -0400 Content-return: allowed From: "Colello, Tony" To: "'msec@securemulticast.org'" Message-id: <2575327B6755D211A0E100805F9FF954082E01B3@ndhmex02.ndhm.gsc.gte.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Subject: [MSEC] (no subject) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 06 Aug 2001 12:04:20 -0400 I tried to subscribe to msec. However, I got the following error which states to inform you: Bug in Mailman version 2.0 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Tony Colello General Dynamics Communication Systems 77 "A" Street Needham, MA 02494-2806 Telephone: 781-455-4909 FAX: 781-455-2042 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 7 04:49:21 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28039 for ; Tue, 7 Aug 2001 04:49:21 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A524653816; Tue, 7 Aug 2001 04:44:15 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id BC02A53708 for ; Mon, 6 Aug 2001 13:40:54 -0400 (EDT) Received: (qmail 83845 invoked by uid 3269); 6 Aug 2001 17:40:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83842 invoked from network); 6 Aug 2001 17:40:54 -0000 Received: from eagle.verisign.com (208.206.241.105) by klesh.pair.com with SMTP; 6 Aug 2001 17:40:54 -0000 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11E9E.C9E18270" Subject: [MSEC] RE: Position statement on IKE development Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 10:39:48 -0700 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-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 10 12:14:38 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07367 for ; Fri, 10 Aug 2001 12:14:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 06C9153B0E; Fri, 10 Aug 2001 12:15:16 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3B25E53AF3 for ; Fri, 10 Aug 2001 12:13:32 -0400 (EDT) Received: (qmail 69759 invoked by uid 3269); 10 Aug 2001 16:13:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69756 invoked from network); 10 Aug 2001 16:13:30 -0000 Received: from magpie.csie.nctu.edu.tw (root@140.113.209.21) by klesh.pair.com with SMTP; 10 Aug 2001 16:13:30 -0000 Received: (from leefy@localhost) by magpie.csie.nctu.edu.tw (8.11.4/8.11.4) id f7AGD8080261 for msec@securemulticast.org; Sat, 11 Aug 2001 00:13:08 +0800 (CST) From: Lee Fu-yuan To: msec@securemulticast.org Message-ID: <20010811001308.A80056@magpie.csie.nctu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [MSEC] rekeying completed ? Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 11 Aug 2001 00:13:08 +0800 hi all: About group rekeying, I have not seen any proposed schemes mentioned about "rekeying complete message" or something like this. But I am so wondering if we can not make sure that all the group members have already rekeyed successfully, how can these protocols guarantee message confidentiality in case that the group member may use old group key. On the contrary, if the communication must be suspended when the rekeying process is in progress, any adversary can stop the communication by isolating certain member(s).(the member can not complete the rekeying operation) How do you think about this problem ? IMHO, the Iolus schems provides better scalability than LKH style protocols since the rekeying operation is confined in local multicast island. But it seems LKH schemes will be adapted into rekeying protocols in this working group. Is there any other disadvantage of Iolus except for its encryption/decrytpion overhead and the trust relationship of internal nodes such Mrouters. Moreover, are there any papers or technical reports discussing about packet loss pattern in MBone, i.e. the loss rate of MBone. Thanks a lot. :) -- Lee, Fu-Yuan Distributed System and Network Security Lab. Dept. of Comp. Sci. & Info. Eng Nat'l Chiao Tung Univ. Hsinchu, Taiwan 30050, ROC E-Mail: leefy@csie.nctu.edu.tw _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 10 16:22:09 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11069 for ; Fri, 10 Aug 2001 16:22:08 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 574CE535A2; Fri, 10 Aug 2001 16:22:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2C05553B55 for ; Fri, 10 Aug 2001 16:20:06 -0400 (EDT) Received: (qmail 92138 invoked by uid 3269); 10 Aug 2001 20:20:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 92135 invoked from network); 10 Aug 2001 20:20:05 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 10 Aug 2001 20:20:05 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7AKJXQ00371; Fri, 10 Aug 2001 13:19:33 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-104.cisco.com [10.21.96.104]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ABA39447; Fri, 10 Aug 2001 13:19:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20010810131459.0422cec0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lee Fu-yuan From: Mark Baugher Subject: Re: [MSEC] rekeying completed ? Cc: msec@securemulticast.org In-Reply-To: <20010811001308.A80056@magpie.csie.nctu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 13:18:40 -0700 At 12:13 AM 8/11/2001 +0800, Lee Fu-yuan wrote: >hi all: Hello to you > About group rekeying, I have not seen any proposed schemes > mentioned about "rekeying complete message" or something > like this. But I am so wondering if we can not make sure > that all the group members have already rekeyed successfully, how > can these protocols guarantee message confidentiality in case that > the group member may use old group key. On the contrary, if the We will have the IETF-51 presentation by Lakshminath posted on a web site very soon that addresses this topic. > communication must be suspended when the rekeying process is in > progress, any adversary can stop the communication by isolating > certain member(s).(the member can not complete the rekeying > operation) How do you think about this problem ? > > > IMHO, the Iolus schems provides better scalability than LKH style > protocols since the rekeying operation is confined in local > multicast island. But it seems LKH schemes will be adapted into > rekeying protocols in this working group. Is there any other > disadvantage of Iolus except for its encryption/decrytpion > overhead and the trust relationship of internal nodes such Mrouters. I contribute my $0.02 to this soon. I just got back from London and practicing triage on my inbox. Cheers, Mark > > > Moreover, are there any papers or technical reports discussing > about packet loss pattern in MBone, i.e. the loss rate of MBone. > > > Thanks a lot. :) > > >-- >Lee, Fu-Yuan >Distributed System and Network Security Lab. >Dept. of Comp. Sci. & Info. Eng >Nat'l Chiao Tung Univ. >Hsinchu, Taiwan 30050, ROC >E-Mail: leefy@csie.nctu.edu.tw > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Aug 11 08:56:11 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06045 for ; Sat, 11 Aug 2001 08:56:11 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3B3EF536E6; Sat, 11 Aug 2001 08:56:25 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9E89453550 for ; Sat, 11 Aug 2001 08:55:54 -0400 (EDT) Received: (qmail 59081 invoked by uid 3269); 11 Aug 2001 12:55:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59078 invoked from network); 11 Aug 2001 12:55:54 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 11 Aug 2001 12:55:54 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f7BCtIe19048; Sat, 11 Aug 2001 08:55:18 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id IAA17702; Sat, 11 Aug 2001 08:55:18 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id IAA25496; Sat, 11 Aug 2001 08:55:17 -0400 From: Ran Canetti Message-Id: <200108111255.IAA25496@ornavella.watson.ibm.com> To: leefy@csie.nctu.edu.tw, msec@securemulticast.org Subject: Re: [MSEC] rekeying completed ? Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 11 Aug 2001 08:55:17 -0400 Fu-yuan, > From: Lee Fu-yuan > > About group rekeying, I have not seen any proposed schemes > mentioned about "rekeying complete message" or something > like this. But I am so wondering if we can not make sure > that all the group members have already rekeyed successfully, how > can these protocols guarantee message confidentiality in case that > the group member may use old group key. On the contrary, if the > communication must be suspended when the rekeying process is in > progress, any adversary can stop the communication by isolating > certain member(s).(the member can not complete the rekeying > operation) How do you think about this problem ? Some of the ways that have been suggested to deal with the problem of reliability of transport of the rekeying messages are: -use standard reliability mechanisms for the reky messages -use some simple "homegrown" reliability mechanisms, such as repeating the rekey messages several times, or some other simple fec mechanisms. -rekey members a bit in advance. that is, start using the new group key only a little while after rekeying the group. this allows for people who didnt get the rekeying messages to get it in a later message. -piggyback the rekey information on the data messages. -use a "stateless" rekeying algorithm. here a member that got out-of-synch can get back in synch by receiving any future rekey message. it does not need to get the entire chain of rekey messages that it may have missed. > > > IMHO, the Iolus schems provides better scalability than LKH style > protocols since the rekeying operation is confined in local > multicast island. But it seems LKH schemes will be adapted into > rekeying protocols in this working group. Is there any other > disadvantage of Iolus except for its encryption/decrytpion > overhead and the trust relationship of internal nodes such Mrouters. having routers decrypt and re-encrypt each data packet is a serious drawback, both from a performance point of view and from a security point of view. this problem seems to me much more serious than the rekey problem. one of the basic premises of msec is to try to keep the security independent from the routing of data packets. Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Aug 11 14:03:29 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07881 for ; Sat, 11 Aug 2001 14:03:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EC4C453714; Sat, 11 Aug 2001 13:58:30 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id BFC9553670 for ; Sat, 11 Aug 2001 13:57:59 -0400 (EDT) Received: (qmail 78619 invoked by uid 3269); 11 Aug 2001 17:57:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78616 invoked from network); 11 Aug 2001 17:57:59 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 11 Aug 2001 17:57:59 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7BHtYD10014; Sat, 11 Aug 2001 10:55:34 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn2-147.cisco.com [10.21.112.147]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ABA50339; Sat, 11 Aug 2001 10:57:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20010811104909.04307c98@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: msec@securemulticast.org From: Mark Baugher Subject: Re: [MSEC] rekeying completed ? Cc: leefy@csie.nctu.edu.tw In-Reply-To: <200108111255.IAA25496@ornavella.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 11 Aug 2001 10:56:31 -0700 At 08:55 AM 8/11/2001 -0400, Ran Canetti wrote: >Fu-yuan, > > > From: Lee Fu-yuan > > > > About group rekeying, I have not seen any proposed schemes > > mentioned about "rekeying complete message" or something > > like this. But I am so wondering if we can not make sure > > that all the group members have already rekeyed successfully, how > > can these protocols guarantee message confidentiality in case that > > the group member may use old group key. On the contrary, if the > > communication must be suspended when the rekeying process is in > > progress, any adversary can stop the communication by isolating > > certain member(s).(the member can not complete the rekeying > > operation) How do you think about this problem ? > >Some of the ways that have been suggested to deal with the problem of >reliability of transport of the rekeying messages are: >-use standard reliability mechanisms for the reky messages >-use some simple "homegrown" reliability mechanisms, such as repeating the >rekey messages several times, or some other simple fec mechanisms. For many applications, even for video on demand, it is a good solution to send a stream of keys concurrently with (but encoded independently from) the data. That way, someone who starts receiving ("tunes to") a particular data stream can start deciphering it within a bounded amount of time. For video on demand, there may be no such tuning or "channel surfing," so the key stream may only need to be sent for some period of time after the commencement of the data stream. KEK- based group key management schemes offer a fast way to start up broadcast or on-demand streams that are encrypted. Mark >-rekey members a bit in advance. that is, start using the new >group key only a little while after rekeying the group. this allows for >people who didnt get the rekeying messages to get it in a later message. >-piggyback the rekey information on the data messages. >-use a "stateless" rekeying algorithm. here a member that got out-of-synch >can get back in synch by receiving any future rekey message. it does not >need to get the entire chain of rekey messages that it may have missed. > > > > > > > IMHO, the Iolus schems provides better scalability than LKH style > > protocols since the rekeying operation is confined in local > > multicast island. But it seems LKH schemes will be adapted into > > rekeying protocols in this working group. Is there any other > > disadvantage of Iolus except for its encryption/decrytpion > > overhead and the trust relationship of internal nodes such Mrouters. > >having routers decrypt and re-encrypt each data packet is a serious >drawback, >both from a performance point of view and from a security point of view. >this problem seems to me much more serious than the rekey problem. >one of the basic premises of msec is to try to keep the security independent >from the routing of data packets. > >Ran > > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 20 09:52:02 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20721 for ; Mon, 20 Aug 2001 09:52:02 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B611E5379B; Mon, 20 Aug 2001 09:50:49 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C789353611 for ; Mon, 20 Aug 2001 09:49:34 -0400 (EDT) Received: (qmail 57687 invoked by uid 3269); 20 Aug 2001 13:49:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57682 invoked from network); 20 Aug 2001 13:49:34 -0000 Received: from softdnserror (HELO M5.sparta.com) (root@157.185.61.1) by klesh.pair.com with SMTP; 20 Aug 2001 13:49:34 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.11.0/8.11.0) with ESMTP id f7KDnR508920; Mon, 20 Aug 2001 08:49:29 -0500 Received: from robin (robin.columbia.sparta.com [157.185.80.228]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id JAA01077; Mon, 20 Aug 2001 09:48:41 -0400 (EDT) Message-Id: <4.2.2.20010820090236.00b1b380@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Lee Fu-yuan , msec@securemulticast.org From: Hugh Harney Subject: Re: [MSEC] rekeying completed ? In-Reply-To: <20010811001308.A80056@magpie.csie.nctu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 20 Aug 2001 09:36:19 -0400 Lee, In discussing the unreliability of the LKH, OFT, OFC rekey action the security relevance is highly dependant on the application. If one is looking at a single source broadcast then the impact of a member not receiving a rekey is the loss of access to the data. This is obviously bad. However, in the case of multiple sources of data the impact of a member not receiving a rekey is possible loss of confidentiality, and loss of access. I'm ignoring the issue of source authentication because it is dependant on the source authentication protocol used. In the case of a single source broadcast (with the data source closely linked with the rekey authority) the failure of group members to receive the key to decrypt the data is a denial of service problem. There are several potential mechanisms to help this situation: more reliable multicast transmission protocols, member initiated rejoins, and application layer actions to improve reliability of the rekey message (multiple sends). The case of multiple sources of data on a group is more problematic. If an adversary managed to isolate a subset of the group and cut that subset off from the group rekeys, the isolated subset would continue to use the old group key. If that old group key were inappropriately disclosed (compromised) the data sources in the isolated subgroup would be disclosing information (encrypting data on a "bad" key). There are a couple of ways to help mitigate this problem in the LKH architecture. First, the cryptographic keys could be given a life span to limit the window of opportunity for transmission on a bad key. Second, a periodic rekey could be sent out, as an expected event, to the group. If a group member does not receive the rekey, that would signal two things - loss of common group key and a potential active attack. The group member that is encrypting data for the group would have to assume that the "old" group key is outdated and stop transmitting on that key. The members would then have to either notify the GC of the loss of cryptographic synch or rejoin the group. Both of these approaches limit the window of vulnerability to an isolation attack, but do not prevent the attack. It seems to me that there is a tradeoff between architecture complexity and risk when discussing LKH vs. Iolus. This tradeoff would be highly application dependant. Hugh At 12:13 AM 8/11/01 +0800, Lee Fu-yuan wrote: >hi all: > > About group rekeying, I have not seen any proposed schemes > mentioned about "rekeying complete message" or something > like this. But I am so wondering if we can not make sure > that all the group members have already rekeyed successfully, how > can these protocols guarantee message confidentiality in case that > the group member may use old group key. On the contrary, if the > communication must be suspended when the rekeying process is in > progress, any adversary can stop the communication by isolating > certain member(s).(the member can not complete the rekeying > operation) How do you think about this problem ? > > > IMHO, the Iolus schems provides better scalability than LKH style > protocols since the rekeying operation is confined in local > multicast island. But it seems LKH schemes will be adapted into > rekeying protocols in this working group. Is there any other > disadvantage of Iolus except for its encryption/decrytpion > overhead and the trust relationship of internal nodes such Mrouters. > > Moreover, are there any papers or technical reports discussing > about packet loss pattern in MBone, i.e. the loss rate of MBone. > > > Thanks a lot. :) > > >-- >Lee, Fu-Yuan >Distributed System and Network Security Lab. >Dept. of Comp. Sci. & Info. Eng >Nat'l Chiao Tung Univ. >Hsinchu, Taiwan 30050, ROC >E-Mail: leefy@csie.nctu.edu.tw > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec ________________________________________________________ Hugh Harney hh@sparta.com 410-381-9400 x203 ________________________________________________________ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 24 08:14:05 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02054 for ; Fri, 24 Aug 2001 08:14:04 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2633F5363A; Fri, 24 Aug 2001 08:14:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E53A8535FD for ; Fri, 24 Aug 2001 08:13:28 -0400 (EDT) Received: (qmail 56279 invoked by uid 3269); 24 Aug 2001 12:13:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56276 invoked from network); 24 Aug 2001 12:13:28 -0000 Received: from znsgs0ja.nortelnetworks.com (HELO znsgs0ja.europe.nortel.com) (47.165.25.40) by klesh.pair.com with SMTP; 24 Aug 2001 12:13:28 -0000 Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7OCCpg02928 for ; Fri, 24 Aug 2001 13:12:52 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Fri, 24 Aug 2001 13:12:31 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 13:12:29 +0100 Message-ID: <7BFD0278CE22D411B1EE0008C7918604027B4082@zjbac004.net.matranortel.com> From: "Nathalie Rivat" To: msec@securemulticast.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12C96.09023260" Subject: [MSEC] draft-irtf-smug-taxonomy-01.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 13:12:25 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12C96.09023260 Content-Type: text/plain; charset="iso-8859-1" Where can I find the document draft-irtf-smug-taxonomy-01.txt ? I tried many servers as well as www.ietf.org/internet-drafts/ (and most of those listed on ftp://ftp.ietf.org/ietf/1shadow-sites.txt) but "URL was not found"... Thanks, Nathalie | Nathalie Rivat | VPN Specialist | Nortel Networks - EMEA ------_=_NextPart_001_01C12C96.09023260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-irtf-smug-taxonomy-01.txt

Where can I = find the document draft-irtf-smug-taxonomy-01.txt ?

I tried many = servers as well as www.ietf.org/internet-drafts/ (and most of those = listed on ftp://ftp.ietf.org/ietf/1shadow-sites.txt) but = "URL was not found"...

Thanks,
Nathalie

| = Nathalie Rivat
| VPN = Specialist
| = Nortel Networks - EMEA

------_=_NextPart_001_01C12C96.09023260-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 24 08:25:14 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02606 for ; Fri, 24 Aug 2001 08:25:13 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1B9205363A; Fri, 24 Aug 2001 08:26:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1E5635363D for ; Fri, 24 Aug 2001 08:24:05 -0400 (EDT) Received: (qmail 57148 invoked by uid 3269); 24 Aug 2001 12:24:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57145 invoked from network); 24 Aug 2001 12:24:04 -0000 Received: from znsgs0ja.nortelnetworks.com (HELO znsgs0ja.europe.nortel.com) (47.165.25.40) by klesh.pair.com with SMTP; 24 Aug 2001 12:24:04 -0000 Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f7OCNXg04825 for ; Fri, 24 Aug 2001 13:23:33 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Fri, 24 Aug 2001 13:23:20 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 13:23:17 +0100 Message-ID: <7BFD0278CE22D411B1EE0008C7918604027B408D@zjbac004.net.matranortel.com> From: "Nathalie Rivat" To: msec@securemulticast.org Subject: RE: [MSEC] draft-irtf-smug-taxonomy-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12C97.8CD6DD60" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 13:23:15 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12C97.8CD6DD60 Content-Type: text/plain; charset="iso-8859-1" Sorry, I have just found it on: http://www.watersprings.org/pub/id/draft-irtf-smug-taxonomy-01.txt Nathalie -----Original Message----- From: Rivat, Nathalie [QPD:5700:EXCH] Sent: Friday, August 24, 2001 2:12 PM To: msec@securemulticast.org Subject: [MSEC] draft-irtf-smug-taxonomy-01.txt Where can I find the document draft-irtf-smug-taxonomy-01.txt ? I tried many servers as well as www.ietf.org/internet-drafts/ (and most of those listed on ftp://ftp.ietf.org/ietf/1shadow-sites.txt ) but "URL was not found"... Thanks, Nathalie | Nathalie Rivat | VPN Specialist | Nortel Networks - EMEA ------_=_NextPart_001_01C12C97.8CD6DD60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-irtf-smug-taxonomy-01.txt
Sorry, I have just found it = on:
http://www.watersprings.org/pub/id/draft-irtf-smug-taxonomy-01.txt
 
Nathalie
-----Original Message-----
From: Rivat, Nathalie=20 [QPD:5700:EXCH]
Sent: Friday, August 24, 2001 2:12 = PM
To:=20 msec@securemulticast.org
Subject: [MSEC]=20 draft-irtf-smug-taxonomy-01.txt

Where can I = find the=20 document draft-irtf-smug-taxonomy-01.txt ?

I tried many = servers as=20 well as www.ietf.org/internet-drafts/ (and most of those listed on ftp://ftp.ietf.org/ie= tf/1shadow-sites.txt)=20 but "URL was not found"...

Thanks,
Nathalie

| = Nathalie=20 Rivat
|=20 VPN Specialist
| Nortel Networks - EMEA =

------_=_NextPart_001_01C12C97.8CD6DD60-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 24 09:27:22 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04521 for ; Fri, 24 Aug 2001 09:27:20 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9E55D53627; Fri, 24 Aug 2001 09:28:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3B8AD5358E for ; Fri, 24 Aug 2001 09:17:51 -0400 (EDT) Received: (qmail 61686 invoked by uid 3269); 24 Aug 2001 13:17:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61683 invoked from network); 24 Aug 2001 13:17:50 -0000 Received: from relay2.nai.com (161.69.3.67) by klesh.pair.com with SMTP; 24 Aug 2001 13:17:50 -0000 Received: from scwsout1.nai.com (undef-3-73.nai.com [161.69.3.73] (may be forged)) by relay2.nai.com (8.9.3/8.9.3) with SMTP id IAA24722 for ; Fri, 24 Aug 2001 08:17:14 -0500 (CDT) Received: FROM ca-ex-bridge2.nai.com BY scwsout1.nai.com ; Fri Aug 24 06:17:20 2001 -0700 Received: by SNC-5-31.nai.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 06:17:36 -0700 Message-ID: From: "Dinsmore, Pete" To: "'Nathalie Rivat'" , msec@securemulticast.org Subject: RE: [MSEC] draft-irtf-smug-taxonomy-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 06:08:14 -0700 It's available on http://www.securemulticast.org/smug-drafts.htm Pete -----Original Message----- From: Nathalie Rivat [mailto:nrivat@nortelnetworks.com] Sent: Friday, August 24, 2001 8:12 AM To: msec@securemulticast.org Subject: [MSEC] draft-irtf-smug-taxonomy-01.txt Where can I find the document draft-irtf-smug-taxonomy-01.txt ? I tried many servers as well as www.ietf.org/internet-drafts/ (and most of those listed on ftp://ftp.ietf.org/ietf/1shadow-sites.txt ) but "URL was not found"... Thanks, Nathalie | Nathalie Rivat | VPN Specialist | Nortel Networks - EMEA _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 24 12:11:13 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08354 for ; Fri, 24 Aug 2001 12:11:13 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2C6565368D; Fri, 24 Aug 2001 12:12:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DFD3153698 for ; Fri, 24 Aug 2001 12:10:05 -0400 (EDT) Received: (qmail 87229 invoked by uid 3269); 24 Aug 2001 16:10:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87224 invoked from network); 24 Aug 2001 16:10:05 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 24 Aug 2001 16:10:05 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7OG9RX04246; Fri, 24 Aug 2001 09:09:27 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn2-198.cisco.com [10.21.112.198]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAG17228; Fri, 24 Aug 2001 09:09:22 -0700 (PDT) Message-Id: <4.3.2.7.2.20010824081134.025f8ab8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: rolf.blom@era.ericsson.se, elisabetta.carrara@era.ericsson.se, fredrik.lindholm@era.ericsson.se, jari.arkko@ericsson.com From: Mark Baugher Cc: msec@securemulticast.org, confctrl@isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] draft-blom-mm-kmgt-00.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 09:08:26 -0700 Hi I re-read draft-blom-mm-kmgt-00.txt and draft-carrara-mm-kmgt-sol-00.txt; I have some comments and questions on the first draft now. Req 4.1 and 4.2 of http://search.ietf.org/internet-drafts/draft-blom-mm-kmgt-00.txt make this work relevant to msec since you're concerned with an integrated key management for pairwise (e.g., unicast) and group (e.g., multicast) applications. msec's been narrowly focused on SSM, but we're aware that group key management may be applied to small groups having many senders, which is what draft-blom-mm-kmgt-00.txt considers. Your draft is timely since an msec requirements draft is in the works and your draft is concerned with requirements. I was confused by sections 2 and 3 since you do not come right out and say that your concern is with "security of the media streams" rather than "call control security." In section 4 you say that you are concerned with end-to-end security of the media stream (i.e., providing keys for SRTP of figure 1). The relationship between call control and media stream security needs more discussion in the draft IMO. In section 5, you claim that having more than one party derive the session key results in additional round trips. This is not the case with an exchange such as the IKE revised public key encryption exchange. IKE is not appropriate to your requirements of section 6 since IKE is two phase and there does not seem to be much need for a two phase key management protocol for multimedia session key management. But I think the revised public-key exchange contradicts your point in section 5.1 (I'd like to hear what Ran has to say since he was a co-inventor of IKE revised public key). I agree with req. 5.1, however, but not for the reason of increasing the round-trip exchanges but because it's the only way to key a group of more than two. I'm not sure about req. 5.2 since I'm not clear on how the large-scale size of a PSTN impinges on end-to-end key establishment for multimedia sessions. Although we may rule out IKE, I'd like to say that req. 5.5 requires an ISAKMP or IKE approach of separating key management from security protocol. I have some more points on section 5, 6 and 7, but I'll stop here for now since the note is already a bit long. thanks, Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 27 01:17:16 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22274 for ; Mon, 27 Aug 2001 01:17:16 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9FCD5536B1; Mon, 27 Aug 2001 01:18:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 536E253636 for ; Mon, 27 Aug 2001 01:17:01 -0400 (EDT) Received: (qmail 30746 invoked by uid 3269); 27 Aug 2001 05:17:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 30743 invoked from network); 27 Aug 2001 05:17:00 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 27 Aug 2001 05:17:00 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f7R5GCe27608; Mon, 27 Aug 2001 01:16:12 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f7R5GBn45090; Mon, 27 Aug 2001 01:16:12 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id BAA38700; Mon, 27 Aug 2001 01:16:11 -0400 From: Ran Canetti Message-Id: <200108270516.BAA38700@ornavella.watson.ibm.com> To: elisabetta.carrara@era.ericsson.se, fredrik.lindholm@era.ericsson.se, jari.arkko@ericsson.com, mbaugher@cisco.com, rolf.blom@era.ericsson.se Subject: Re: [MSEC] draft-blom-mm-kmgt-00.txt Cc: confctrl@isi.edu, msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 27 Aug 2001 01:16:11 -0400 Here are some more remarks I had (in addition to Mark's) on the two drafts that were presented in the msec meeting in London: draft-blom-mm-kmgt-00.txt draft-carrara-mm-kmgt-sol-00.txt (Reminder: In a show of hands following a discussion following the presentation, there seemed to be clear consensus to take up these drafs in msec.) Best, Ran Generally, I liked the clear and concise way in which both drafts were written. the requirements draft is especially an improvement over other key management protocols (both unicast and multicast) where the requirements are not clearly stated. Still, I have a number of questions and remarks: * First, a general remark: Although it is not stated explicitly in the requirements document, all your key-exchange protocols seem to assume that the two parties are time-synchronized and the protocols are based on timestamps for freshness. This indeed simplifies the protocols and reduces the number of rounds. But it puts much trust in the timing mechanism. Is this a concious choice? In particular: -What is the accuracy (or time-window) that you had in mind for the parties to accept a received timestamp as "fresh"? -Do you think that this time window can be both wide enough to allow for reasonable interoperability and narrow enough to avoid attacks? These are serious questions that should be answered per scenario. Note that most other ietf-standardized key exchange protocols (ike,ssl,ssh) dont use a timestamp mechanism. instead they use random nonces for freshness. This makes the protocol more complex (more state, more flows) but it also makes for more robust protocols. * Regarding the requirements draft: 1) There are a couple security concerns that are missing in the requirements document. One is anonymity (ie, identity protection) against a passive eavesdropper. Is this a concern for you? if so, do you want to protect the identity of the initiator? responder? both? A related concern is identity protection against an active attacker that impersonates one of the parties. For instance, assume an attacker impersonates an initiator and interacts with a responder for the sole purpose of obtaining the identity of the responder. a similar attack can be mounted against an initiator. Is this a concern for you? (It is impossible to protect both the initiator and the responder against such an active attack, at least when standard techniques are used. But it's possible to protect one of the two, by making sure that the other party reveals its identity first. Typically, it is better to protect the identity of the client, who is typically the initiator. Are you willing to pay in number of rounds and complexity to satisfy these concerns? 2) I'm confused about your description of the SIP setting, where some intermediaries need to be given access to certain fields in the packets, and the statements that this limits the end-to-end security of the key exchange. I'm not familiar with the workings of the SIP protocol, but does this protocol prevent a completely end-to-end KE protocol where the cryptographic payload is strictly contained in the message fields than need not be accessed by intermediaries? ie, is there an inherent contradiction to end-to-end security or is it just a technicality that can be overcome? * Some remarks regarding the protocols draft: (Other remarks can be postponed to a later stage.) 1) the protocols do not seem to protect against DoS attacks. A standard technique to mitigate the problem is to use a cookie-response mechanism, where the responder makes sure that there is a "real party" out there before it engages in expensive public-key operations or starts to maintain state. the current protocols dont do that - the responder engages in those expensive activities right after receiving the first message (which could be replayed arbitrarily, within the same time unit). Adding the cookie mechanism would result in one more round-trip. (In fact, one more flow may be enough). Did you weigh one against the other? 2) Only one of the protocols (the DH one) provides forward secrecy (PFS). Indeed, the computational cost of this protocol is the highest. Is forward secrecy a concern for you? is it worth the extra cost? this should be discussed. possible outcomes may be to either mandate it (as IKE did) or leave it optional (as SSL did) or decide it is not a concern and leave it out. 3) Pre-shared key mode: Hashing the key k_m in B's response is a bad idea. It ruins the security of the protocol since it potentially provides the attacker with a way to verify whether some guesses regarding the potential value of k_m are correct. A more robust cryptographic practice (and one that can be proven secure) is to first derive a special key k_a from k_m, and then have B send PRF_{k_a}(ID_a || ID_b || T), where PRF is a pseudorandom function, or a MAC function. This way the security of k_m remains intact against such guessing attacks. This remark holds also wrt the public-key encryption mode. 4) PKE mode: the identity of the sender, IDa, must always be included in the encrypted stringin A's message. Otherwise the first message may potentially be replayed by an attacker. 5) Similarly, in the DH exchange, the recipient's identity must be included in the signed text in both flows. Otherwise some spoofing attacks may be possible. 6) The draft whould provide guidelines regarding key lifetimes and the rekeying procedures. When should a key expire? after an amount of data encrypted? time elapsed? combination of both? can that be a parameter decided in the session setup? also, do you enforce one type of rekeying only? note that if no PFS is necessary in the rekeying process then it is possible to rekey without any additional communication. (Each party locally derives a new key from the old one, say using the usual key derivation method.) * Finally, both drafts seem to concentrate on the unicast case and only very briefly sketch the 12M/M2M cases. This is ok, since we have to solve that case first. but please bear in mind that the move to the one-to-many (or even one-to-few) case is a considerable step, which requires a somewhat different appeoach and tools. It does not necessarily have to be much more heavyweight, but it's quite different. In particular, a couple questions that you may want to think about: - Do you want to have a "group membership controller" that is different than the data source? Or do you think of the data source as inherently the same entity as the membership controller? - Do you want to deal with dynamic membership, ie people join and leave during the lifetime of the group, or do you want to deal only with groups where the membership is constant throughout the lifetime of the group? (or alternatively where receivers join but there is no backwards-access-control requirement)? _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 27 10:45:12 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20504 for ; Mon, 27 Aug 2001 10:45:11 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D89AE53633; Mon, 27 Aug 2001 10:46:01 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 18CAC53603 for ; Mon, 27 Aug 2001 10:40:04 -0400 (EDT) Received: (qmail 73208 invoked by uid 3269); 27 Aug 2001 14:40:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73203 invoked from network); 27 Aug 2001 14:40:02 -0000 Received: from albatross-ext.wise.edt.ericsson.se (194.237.142.116) by klesh.pair.com with SMTP; 27 Aug 2001 14:40:02 -0000 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f7REdrK23780 for ; Mon, 27 Aug 2001 16:39:53 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Aug 27 16:39:50 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 16:39:50 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E021620FF@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Ran Canetti'" , "Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, mbaugher@cisco.com, =?iso-8859-1?Q?=27Mats_N=E4slund=27?= , "'Rolf Blom'" Cc: confctrl@isi.edu, msec@securemulticast.org Subject: RE: [MSEC] draft-blom-mm-kmgt-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 27 Aug 2001 16:39:43 +0200 Mark, Ran, Thanks for the comments. I'll try to answer some of your questions and comments by the following statement: * Our main concern is (as Mark pointed out) security of media streams (i.e. SRTP) not the security of the call control such as SIP and RTSP (we understand that we need to clarify the relationship between call control and media security). * One of the design choices has been to use timestamps even though it has limitations. We are aware that we must add clarifications of its use in different scenarios, the security implications etc. We like this approach because it gives us the possibility to let the source "push" down keys very fast and because it gives the possibility to integrate/piggy-back the protocol in the call control, e.g. SIP and RTSP. * For one way authentication our public key scheme needs 1/2 round. This can't be achieved with a scheme that requires mutual party input for the key derivation (such as the revised public key). * We do not mandate forward secrecy due to the computational burden, but we included the DH to be able to provide it as optional. Note that there often exists constrains on call setup time and the delay budget is essentially filled by the transport of bits itself. * It is our intention to separate the key management protocol from the security protocol (even though we right know only have SRTP). DoS Due to the nature of the protocol (i.e. that it is meant to be integrated in e.g. SIP) we do not check the validity of the originator's address. This may however be done by the transporting protocol (I would even recommend this). But if this is not done by the transporting protocol, this will lead (in the worst case) to one signature verification each time a "valid" message arrives. Still, we should probably add this in the security considerations. SIP scenario What we tried to describe in the SIP scenario was that even though it might be technical possible to have an end-to-end protection of the SIP signaling, this will probably not be done in many practical implementations (due to intermediate nodes etc.). Instead of always relying on the security of SIP (or RTSP) we believe that we need our own protection which should be independent of the transport protocol used. ID protection Your points are definitely valid. But our main concern was not to provide anonymity at the extra cost of additional roundtrips. However, some level of identity protection can be given, e.g. in the pre-shared key version. In this case, of course, the two calling parties know the identity by the other (e.g. by using pseudonyms). In the public key case we do provide identity protection by allowing the ID/Certificate to be encrypted (this will however open DoS problems). The initiator's identity will then be protected as well as the responder's (this will of course require that the responder knows what private key to decrypt with). Re-keying Note that we clearly distinguish between re-keying and refresh. The latter being deriving a new key without any extra communication. Life time The fact that the key lifetime etc. may differ depending on the security protocol makes it impossible to specify it in the key management draft. However, we could provide recommendations on a more general level. Note that in SRTP we specify such limits for SRTP and we believe that other security protocols designers should do the same. Groups We had as an application, a multimedia session in which you dynamically may add new streams. To us it is then natural to make the source the membership controller. The others security related comments about what should be included in hashes etc. are of course valid and we need to take these into account, thanks. Once again, thanks for the comments and you are more than welcome to send more. Best Regards, Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 28 17:20:42 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21769 for ; Tue, 28 Aug 2001 17:20:41 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 30C73535BF; Tue, 28 Aug 2001 17:20:37 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E5B5F53547 for ; Tue, 28 Aug 2001 17:14:41 -0400 (EDT) Received: (qmail 45198 invoked by uid 3269); 28 Aug 2001 21:14:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45118 invoked from network); 28 Aug 2001 21:14:27 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 28 Aug 2001 21:14:27 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7SKsmV12328; Tue, 28 Aug 2001 14:08:08 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-55.cisco.com [10.21.96.55]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAN01867; Tue, 28 Aug 2001 13:56:39 -0700 (PDT) Message-Id: <4.3.2.7.2.20010828133429.04341100@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: rolf.blom@era.ericsson.se, elisabetta.carrara@era.ericsson.se, fredrik.lindholm@era.ericsson.se, jari.arkko@ericsson.com From: Mark Baugher Subject: Re: [MSEC] draft-blom-mm-kmgt-00.txt Cc: msec@securemulticast.org, confctrl@isi.edu In-Reply-To: <4.3.2.7.2.20010824081134.025f8ab8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 13:55:37 -0700 Rolf, Elisabetta, Fredrik and Jari, Here are the rest of my comments on the draft. Req 5.6 is unclear to me: SRTP, for example, associates a crypto context (SA) with or just , so in a sense it might be associated/indexed by an IP address. A bigger question probably has to do with what identity is used for the crypto context: Is it a name associated with a public key, a SPKI cert, and X.509 authorization cert, a big number, or what? Does 5.16 contradict 5.6? Does 5.11 require that the key management protocol support upgrade to new transforms and attributes? I think you're looking for a key management framework since 5.5 requires it to support new security protocols. Many of the requirements in 6 are true in general for practically any protocol. They would be more meaningful with thresholds or bounds. Req 7.1 is also very general. You cite cryptographic strength but not the security services that are provided such as authenticity, integrity, confidentiality or what information is protected (Ran mentioned identity protection). I think the Security Considerations section should discuss the threats posed and necessary responses. Mark At 09:08 AM 8/24/2001 -0700, Mark Baugher wrote: >Hi > I re-read draft-blom-mm-kmgt-00.txt and > draft-carrara-mm-kmgt-sol-00.txt; I have some comments and questions on > the first draft now. > > Req 4.1 and 4.2 of > http://search.ietf.org/internet-drafts/draft-blom-mm-kmgt-00.txt make > this work relevant to msec since you're concerned with an integrated key > management for pairwise (e.g., unicast) and group (e.g., multicast) > applications. msec's been narrowly focused on SSM, but we're aware that > group key management may be applied to small groups having many senders, > which is what draft-blom-mm-kmgt-00.txt considers. Your draft is timely > since an msec requirements draft is in the works and your draft is > concerned with requirements. > > I was confused by sections 2 and 3 since you do not come right out and > say that your concern is with "security of the media streams" rather than > "call control security." In section 4 you say that you are concerned > with end-to-end security of the media stream (i.e., providing keys for > SRTP of figure 1). The relationship between call control and media > stream security needs more discussion in the draft IMO. > > In section 5, you claim that having more than one party derive the > session key results in additional round trips. This is not the case with > an exchange such as the IKE revised public key encryption exchange. IKE > is not appropriate to your requirements of section 6 since IKE is two > phase and there does not seem to be much need for a two phase key > management protocol for multimedia session key management. But I think > the revised public-key exchange contradicts your point in section 5.1 > (I'd like to hear what Ran has to say since he was a co-inventor of IKE > revised public key). I agree with req. 5.1, however, but not for the > reason of increasing the round-trip exchanges but because it's the only > way to key a group of more than two. I'm not sure about req. 5.2 since > I'm not clear on how the large-scale size of a PSTN impinges on > end-to-end key establishment for multimedia sessions. Although we may > rule out IKE, I'd like to say that req. 5.5 requires an ISAKMP or IKE > approach of separating key management from security protocol. > >I have some more points on section 5, 6 and 7, but I'll stop here for now >since the note is already a bit long. > >thanks, Mark > > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec