From msec-admin@securemulticast.org Thu Dec 5 06:56:56 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08457 for ; Thu, 5 Dec 2002 06:56:56 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0D64B53803; Thu, 5 Dec 2002 06:57:32 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id EFF1D53720 for ; Thu, 5 Dec 2002 06:55:27 -0500 (EST) Received: (qmail 46418 invoked by uid 3269); 5 Dec 2002 11:55:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46415 invoked from network); 5 Dec 2002 11:55:27 -0000 Received: from mail0.yrp.nttdocomo.co.jp (202.245.184.18) by klesh.pair.com with SMTP; 5 Dec 2002 11:55:27 -0000 Received: from mml.yrp.nttdocomo.co.jp (mml.yrp.nttdocomo.co.jp [172.21.48.50]) by mail0.yrp.nttdocomo.co.jp (8.11.6/YRPHUB0-8820020412) with ESMTP id gB5BtLv20157 for ; Thu, 5 Dec 2002 20:55:22 +0900 (JST) Received: from HUENO-MURAMASA.mml.yrp.nttdocomo.co.jp (mml-pool10.yrp.nttdocomo.co.jp [172.21.1.90]) by mml.yrp.nttdocomo.co.jp (8.9.2/3.7W-mml-990617) with ESMTP id UAA23895 for ; Thu, 5 Dec 2002 20:55:21 +0900 (JST) Message-Id: <4.3.2-J.20021205205312.03295ef0@mml.yrp.nttdocomo.co.jp> X-Sender: hueno@mig-server.yrp.nttdocomo.co.jp X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J To: msec@securemulticast.org From: Hidetoshi Ueno Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MIKEY/GDOI implementations 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 05 Dec 2002 20:55:16 +0900 Dear all, I'm interested in multicast security, and I've just started to investigate MIKEY and GDOI. Let me ask a quick question. Are there any implementations of MIKEY and GDOI? I appreciate your any feedback. Thank you Hidetoshi Ueno NTT DoCoMo, Inc. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Dec 5 11:25:13 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18337 for ; Thu, 5 Dec 2002 11:25:13 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CE04353604; Thu, 5 Dec 2002 11:27:24 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9B104538C5 for ; Thu, 5 Dec 2002 11:22:25 -0500 (EST) Received: (qmail 80863 invoked by uid 3269); 5 Dec 2002 16:22:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80860 invoked from network); 5 Dec 2002 16:22:24 -0000 Received: from halt-in.cisco.com (HELO mailman.cisco.com) (171.70.144.185) by klesh.pair.com with SMTP; 5 Dec 2002 16:22:24 -0000 Received: from [10.21.115.86] by mailman.cisco.com (171.70.144.185) with ESMTP; 05 Dec 2002 01:41:57 +0000 Message-Id: <5.1.1.5.2.20021205082132.042fdf18@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Hidetoshi Ueno From: Mark Baugher Subject: Re: [MSEC] MIKEY/GDOI implementations Cc: msec@securemulticast.org In-Reply-To: <4.3.2-J.20021205205312.03295ef0@mml.yrp.nttdocomo.co.jp> 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 05 Dec 2002 08:22:20 -0800 There's Brian Weis' work: http://www.vovida.org/protocols/downloads/gdoi/ cheers, Mark At 08:55 PM 12/5/2002 +0900, Hidetoshi Ueno wrote: >Dear all, > >I'm interested in multicast security, and I've just started to investigate >MIKEY and GDOI. >Let me ask a quick question. Are there any implementations of MIKEY and GDOI? > >I appreciate your any feedback. > >Thank you > >Hidetoshi Ueno >NTT DoCoMo, Inc. > >_______________________________________________ >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 Dec 5 16:14:47 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00535 for ; Thu, 5 Dec 2002 16:14:45 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9B7CB53643; Thu, 5 Dec 2002 16:16:59 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A9142535F9 for ; Thu, 5 Dec 2002 16:15:58 -0500 (EST) Received: (qmail 28781 invoked by uid 3269); 5 Dec 2002 21:15:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28778 invoked from network); 5 Dec 2002 21:15:58 -0000 Received: from www.elias-on-curve.org (HELO nue002.nue.et-inf.uni-siegen.de) (141.99.152.2) by klesh.pair.com with SMTP; 5 Dec 2002 21:15:58 -0000 Received: from localhost (localhost [127.0.0.1]) by nue002.nue.et-inf.uni-siegen.de (Postfix) with ESMTP id 82B81120034; Thu, 5 Dec 2002 22:39:02 +0100 (CET) Received: from nue.et-inf.uni-siegen.de (linux.nue.et-inf.uni-siegen.de [141.99.152.2]) by nue002.nue.et-inf.uni-siegen.de (Postfix) with ESMTP id 8B0B5120023; Thu, 5 Dec 2002 22:38:42 +0100 (CET) Message-ID: <3DEFC25E.7000003@nue.et-inf.uni-siegen.de> From: Luigi Lo Iacono Reply-To: lo_iacono@nue.et-inf.uni-siegen.de Organization: University of Siegen - FB12 NUE User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Hidetoshi Ueno Cc: msec@securemulticast.org Subject: Re: [MSEC] MIKEY/GDOI implementations References: <4.3.2-J.20021205205312.03295ef0@mml.yrp.nttdocomo.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 05 Dec 2002 22:17:18 +0100 Content-Transfer-Encoding: 7bit You can find a GDOI implementation here: http://www.vovida.org/ Hidetoshi Ueno wrote: > Dear all, > > I'm interested in multicast security, and I've just started to > investigate MIKEY and GDOI. > Let me ask a quick question. Are there any implementations of MIKEY and > GDOI? > > I appreciate your any feedback. > > Thank you > > Hidetoshi Ueno > NTT DoCoMo, Inc. > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > -- Luigi Lo Iacono ------------------------------------------------------- Institute for Data Communications Systems University of Siegen, Germany http://www.nue.et-inf.uni-siegen.de/ ------------------------------------------------------- PGP: 057E 2A17 47B2 4749 1D37 8A07 286E 2238 HTTP: http://www.nue.et-inf.uni-siegen.de/~loiacono/ EMail: mailto:lo_iacono@nue.et-inf.uni-siegen.de Phone: +49 271 740-4354 Fax: +49 271 740-2536 Mobile: +49 177 2442521 ------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Dec 6 10:06:39 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09224 for ; Fri, 6 Dec 2002 10:06:38 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1BF1C539C1; Fri, 6 Dec 2002 10:06:44 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E243D5396A for ; Fri, 6 Dec 2002 10:04:06 -0500 (EST) Received: (qmail 60706 invoked by uid 3269); 6 Dec 2002 15:04:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60703 invoked from network); 6 Dec 2002 15:04:06 -0000 Received: from smtp016.mail.yahoo.com (216.136.174.113) by klesh.pair.com with SMTP; 6 Dec 2002 15:04:06 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Dec 2002 15:04:05 -0000 Message-Id: <5.0.0.25.2.20021206095501.03976628@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: gsec@lists.tislabs.com, msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] List of Group Policy team 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 06 Dec 2002 10:04:02 -0500 Here is a list of people that are working on Group Policy. Hugh Harney hh@sparta.com Sunil Iyengar s.iyengar@eim.surrey.ac.uk Ram Gopal ram.gopal@nokia.com Zen free@itsky.com.cn Thomas Hardjono thardjono@yahoo.com Did I miss anybody? Would you all be open to a teleconference on Thu/12th or Fri/13th next week? (I'll send out a call number) cheers, thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Dec 6 15:55:06 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24019 for ; Fri, 6 Dec 2002 15:55:05 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5442D53853; Fri, 6 Dec 2002 15:57:26 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id EFC0F53894 for ; Fri, 6 Dec 2002 12:41:57 -0500 (EST) Received: (qmail 82710 invoked by uid 3269); 6 Dec 2002 17:41:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82707 invoked from network); 6 Dec 2002 17:41:57 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 6 Dec 2002 17:41:57 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.12.3/8.12.3) with ESMTP id gB6Hfp5d024975; Fri, 6 Dec 2002 11:41:52 -0600 Received: from robin (robin.columbia.sparta.com [157.185.80.228]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id MAA25799; Fri, 6 Dec 2002 12:41:49 -0500 (EST) Message-Id: <4.2.2.20021206123804.0136c2d0@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Thomas Hardjono , gsec@lists.tislabs.com, msec@securemulticast.org From: Hugh Harney In-Reply-To: <5.0.0.25.2.20021206095501.03976628@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: [GSEC] List of Group Policy team 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 06 Dec 2002 12:43:48 -0500 Thomas, In addition to the people you listed. The following people have contacted me to help with group policy. Paul Lambert Patrick McDaniel Also, I've asked Brian Weiss, and Lakshminath Dondeti to participate if they could. I'd like to have a call to kick off this effort next week Friday the 13th. What better day than Friday the 13th to start something? Hugh At 10:04 AM 12/6/02 -0500, Thomas Hardjono wrote: >Here is a list of people that are working on Group Policy. > >Hugh Harney hh@sparta.com >Sunil Iyengar s.iyengar@eim.surrey.ac.uk >Ram Gopal ram.gopal@nokia.com >Zen free@itsky.com.cn >Thomas Hardjono thardjono@yahoo.com > >Did I miss anybody? > >Would you all be open to a teleconference on Thu/12th or Fri/13th next week? >(I'll send out a call number) > >cheers, > >thomas >------ > > > ________________________________________________________ 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 Dec 6 16:25:24 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25486 for ; Fri, 6 Dec 2002 16:25:22 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D25F8538BC; Fri, 6 Dec 2002 16:27:43 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4EE525378C for ; Fri, 6 Dec 2002 13:26:44 -0500 (EST) Received: (qmail 89544 invoked by uid 3269); 6 Dec 2002 18:26:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89541 invoked from network); 6 Dec 2002 18:26:44 -0000 Received: from halt-in.cisco.com (HELO mailman.cisco.com) (171.70.144.185) by klesh.pair.com with SMTP; 6 Dec 2002 18:26:44 -0000 Received: from [128.107.213.146] by mailman.cisco.com (171.70.144.185) with ESMTP; 06 Dec 2002 03:46:57 +0000 Message-ID: <3DF0EBC8.39DF5D93@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Hugh Harney Cc: Thomas Hardjono , gsec@lists.tislabs.com, msec@securemulticast.org References: <4.2.2.20021206123804.0136c2d0@pop.columbia.sparta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: [GSEC] List of Group Policy team 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 06 Dec 2002 10:26:16 -0800 Content-Transfer-Encoding: 7bit Hugh Harney wrote: > > Thomas, > > In addition to the people you listed. The following people have contacted > me to help with group policy. > > Paul Lambert > Patrick McDaniel > > Also, I've asked Brian Weiss, and Lakshminath Dondeti to participate if > they could. And I'm still expecting to do so. Thanks, Brian > I'd like to have a call to kick off this effort next week Friday the 13th. > What better day than Friday the 13th to start something? > > Hugh > > At 10:04 AM 12/6/02 -0500, Thomas Hardjono wrote: > > >Here is a list of people that are working on Group Policy. > > > >Hugh Harney hh@sparta.com > >Sunil Iyengar s.iyengar@eim.surrey.ac.uk > >Ram Gopal ram.gopal@nokia.com > >Zen free@itsky.com.cn > >Thomas Hardjono thardjono@yahoo.com > > > >Did I miss anybody? > > > >Would you all be open to a teleconference on Thu/12th or Fri/13th next week? > >(I'll send out a call number) > > > >cheers, > > > >thomas > >------ > > > > > > > > ________________________________________________________ > Hugh Harney hh@sparta.com 410-381-9400 x203 > ________________________________________________________ -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Dec 6 16:36:32 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25790 for ; Fri, 6 Dec 2002 16:36:31 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 113585391F; Fri, 6 Dec 2002 16:37:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id EBAD1538A1 for ; Fri, 6 Dec 2002 16:34:47 -0500 (EST) Received: (qmail 18436 invoked by uid 3269); 6 Dec 2002 21:34:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18433 invoked from network); 6 Dec 2002 21:34:47 -0000 Received: from smtp011.mail.yahoo.com (216.136.173.31) by klesh.pair.com with SMTP; 6 Dec 2002 21:34:47 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Dec 2002 21:34:46 -0000 Message-Id: <5.0.0.25.2.20021206162847.02c661f0@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: gsec@lists.tislabs.com, msec@securemulticast.org From: Thomas Hardjono Subject: Group Policy list so far --- Re: [MSEC] Re: [GSEC] List of Group Policy team In-Reply-To: <3DF0EBC8.39DF5D93@cisco.com> References: <4.2.2.20021206123804.0136c2d0@pop.columbia.sparta.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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 06 Dec 2002 16:34:44 -0500 Folks, Here is the list so far: Hugh Harney hh@sparta.com Sunil Iyengar s.iyengar@eim.surrey.ac.uk Ram Gopal ram.gopal@nokia.com Zen free@itsky.com.cn Thomas Hardjono thardjono@yahoo.com Brian Weis bew@cisco.com Paul Lambert Patrick McDaniel pdmcdan@pdmcdan.com For the call, everyone seems OK with Friday/13th. Would 10am-Pacific (1pm-East) work for everybody? Background material is at http://www.securemulticast.org/smug-drafts.htm cheers, thomas ------ At 12/6/2002||10:26 AM, Brian Weis wrote: > > >Hugh Harney hh@sparta.com > > >Sunil Iyengar s.iyengar@eim.surrey.ac.uk > > >Ram Gopal ram.gopal@nokia.com > > >Zen free@itsky.com.cn > > >Thomas Hardjono thardjono@yahoo.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Dec 9 12:13:32 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19331 for ; Mon, 9 Dec 2002 12:13:31 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D69EB53717; Mon, 9 Dec 2002 12:15:16 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B48CC53533 for ; Mon, 9 Dec 2002 08:06:14 -0500 (EST) Received: (qmail 1662 invoked by uid 3269); 9 Dec 2002 13:06:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1659 invoked from network); 9 Dec 2002 13:06:14 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 9 Dec 2002 13:06:14 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07347; Mon, 9 Dec 2002 08:03:19 -0500 (EST) Message-Id: <200212091303.IAA07347@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-ipsec-multicast-issues-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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 09 Dec 2002 08:03:19 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : IP Multicast issues with IPsec Author(s) : M. Baugher, T. Hardjono, B. Weis Filename : draft-ietf-msec-ipsec-multicast-issues-00.txt Pages : 8 Date : 2002-12-6 The IPsec Architecture [RFC2401] and IPsec transform RFCs [RFC2402, RFC2406] define certain semantics for use of IPsec with IP multicast traffic. The recent revisions to each of the protocol documents [ESPbis, AHbis] propose changes to those semantics. However, neither the existing nor proposed semantics are sufficiently general such that IPsec can be used to protect the wide variety of IPv4 and IPv6 multicast applications that are expected by the IP multicast community. This document reviews these semantics and proposes changes which would enable IPsec to be generally useful for a wider variety of IPv4 and IPv6 multicast traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-multicast-issues-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-ipsec-multicast-issues-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-ipsec-multicast-issues-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-6141134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-ipsec-multicast-issues-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-ipsec-multicast-issues-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-6141134.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Dec 10 09:16:09 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06788 for ; Tue, 10 Dec 2002 09:16:08 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2A87B53769; Tue, 10 Dec 2002 09:18:32 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9C53753633 for ; Tue, 10 Dec 2002 09:17:44 -0500 (EST) Received: (qmail 96667 invoked by uid 3269); 10 Dec 2002 14:17:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96664 invoked from network); 10 Dec 2002 14:17:43 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 10 Dec 2002 14:17:43 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.12.3/8.12.3) with ESMTP id gBAEHea8012382; Tue, 10 Dec 2002 08:17:41 -0600 Received: from robin (robin.columbia.sparta.com [157.185.80.228]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id JAA12136; Tue, 10 Dec 2002 09:17:37 -0500 (EST) Message-Id: <4.2.2.20021210091812.0142ac80@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Thomas Hardjono , gsec@lists.tislabs.com, msec@securemulticast.org From: Hugh Harney In-Reply-To: <5.0.0.25.2.20021206162847.02c661f0@pop.mail.yahoo.com> References: <3DF0EBC8.39DF5D93@cisco.com> <4.2.2.20021206123804.0136c2d0@pop.columbia.sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: Group Policy list so far - 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 10 Dec 2002 09:19:10 -0500 Thomas, How are we setting the call up? Hugh At 04:34 PM 12/6/02 -0500, Thomas Hardjono wrote: >For the call, everyone seems OK with Friday/13th. >Would 10am-Pacific (1pm-East) work for everybody? > >Background material is at http://www.securemulticast.org/smug-drafts.htm > >cheers, > >thomas >------ ________________________________________________________ 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 Thu Dec 12 10:58:42 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28559 for ; Thu, 12 Dec 2002 10:58:41 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9453953A04; Thu, 12 Dec 2002 11:00:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6B48F53A04 for ; Thu, 12 Dec 2002 10:58:26 -0500 (EST) Received: (qmail 17158 invoked by uid 3269); 12 Dec 2002 15:58:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17151 invoked from network); 12 Dec 2002 15:58:22 -0000 Received: from unknown (HELO itsky.com.cn) (211.153.20.96) by klesh.pair.com with SMTP; 12 Dec 2002 15:58:22 -0000 Received: (smail 5201 invoked by uid 511); 12 Dec 2002 15:14:04 -0000 Received: from unknown (HELO lion) (free@61.48.10.128) by 0 with SMTP; 12 Dec 2002 15:14:04 -0000 From: "zen" To: Thomas Hardjono Cc: "gsec@lists.tislabs.com" , "msec@securemulticast.org" X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: <20021212155826.6B48F53A04@pairlist.net> Subject: [MSEC] Re: Group Policy call details + rough agenda (Dec 13th) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 12 Dec 2002 23:59:35 +0800 Content-Transfer-Encoding: 7bit Thomas, I am very sorry i have some problems in connecting to the conference. I afraid i can't attend the first meeting directly. I will give my think by means of email. Would you please provide the video file of this meeting for download? Thanks for all you have done for the working group! Thanks, Zen >Folks, > >Thanks for participating. Here are the details for our Group Policy call >on Friday Dec 13th. > > Date: Dec 13th 2002 > Time: 10am-Pacific (1pm-East) > Dial-in number: 1.888.742.8686 > Conference ID: 2876813# > International Dial-in: 1.303.928.2600 > >This will be our first call/meeting in a long time about Group Policy. >Thus perhaps we should spend time in open discussions. > >Please find the existing drafts on the SMuG page at SecureMulticast.org >http://www.securemulticast.org/smug-drafts.htm >Please email me if any of the drafts are missing or have a broken link. > >Agenda >------ > > - Overview existing work > - Identify missing pieces and other requirements > - Discussions > - Next steps > > > >cheers, > >thomas >------ >PS. Did I miss anybody on this email? > > > > > > >. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 18 08:05:39 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04834 for ; Wed, 18 Dec 2002 08:05:38 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AD53E53605; Wed, 18 Dec 2002 08:08:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DF372535B3 for ; Wed, 18 Dec 2002 08:06:52 -0500 (EST) Received: (qmail 59551 invoked by uid 3269); 18 Dec 2002 13:06:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59548 invoked from network); 18 Dec 2002 13:06:52 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 18 Dec 2002 13:06:52 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04502; Wed, 18 Dec 2002 08:03:51 -0500 (EST) Message-Id: <200212181303.IAA04502@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-gdoi-07.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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 18 Dec 2002 08:03:51 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : The Group Domain of Interpretation Author(s) : M. Baugher et al. Filename : draft-ietf-msec-gdoi-07.txt Pages : 42 Date : 2002-12-16 This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-gdoi-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-gdoi-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-16123618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gdoi-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gdoi-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-16123618.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 18 11:04:11 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11683 for ; Wed, 18 Dec 2002 11:04:11 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 06FF553687; Wed, 18 Dec 2002 11:06:24 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 18EE353674 for ; Wed, 18 Dec 2002 10:38:06 -0500 (EST) Received: (qmail 80018 invoked by uid 3269); 18 Dec 2002 15:38:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80015 invoked from network); 18 Dec 2002 15:38:06 -0000 Received: from bouncer.telica.com (HELO mailscan.telica.com) (4.19.224.197) by klesh.pair.com with SMTP; 18 Dec 2002 15:38:06 -0000 Received: (from root@localhost) by mailscan.telica.com (8.11.6/8.11.6) id gBIFTD107551; Wed, 18 Dec 2002 10:29:13 -0500 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by mailscan.telica.com (8.11.6/8.11.6) with SMTP id gBIE9JV03238 for ; Wed, 18 Dec 2002 09:09:19 -0500 Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18Oe3p-0006ec-00 for ietf-announce-list@ran.ietf.org; Wed, 18 Dec 2002 08:16:29 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18Odux-0006QP-00 for all-ietf@ran.ietf.org; Wed, 18 Dec 2002 08:07:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04502; Wed, 18 Dec 2002 08:03:51 -0500 (EST) Message-Id: <200212181303.IAA04502@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Precedence: bulk Subject: [MSEC] I-D ACTION:draft-ietf-msec-gdoi-07.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 18 Dec 2002 08:03:51 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : The Group Domain of Interpretation Author(s) : M. Baugher et al. Filename : draft-ietf-msec-gdoi-07.txt Pages : 42 Date : 2002-12-16 This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-gdoi-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-gdoi-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-16123618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gdoi-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gdoi-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-16123618.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Dec 23 09:37:35 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04231 for ; Mon, 23 Dec 2002 09:37:34 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3BA8C535C6; Mon, 23 Dec 2002 09:40:07 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 487E8535BF for ; Mon, 23 Dec 2002 09:39:40 -0500 (EST) Received: (qmail 61020 invoked by uid 3269); 23 Dec 2002 14:39:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61017 invoked from network); 23 Dec 2002 14:39:40 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 23 Dec 2002 14:39:40 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04156; Mon, 23 Dec 2002 09:36:36 -0500 (EST) Message-Id: <200212231436.JAA04156@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-ipsec-multicast-issues-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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 23 Dec 2002 09:36:35 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : IP Multicast issues with IPsec Author(s) : M. Baugher, R. Canetti, T. Hardjono, B. Weis Filename : draft-ietf-msec-ipsec-multicast-issues-01.txt Pages : 10 Date : 2002-12-23 The IPsec Architecture [RFC2401] and IPsec transform RFCs [RFC2402, RFC2406] define certain mechanisms for IP multicast traffic. The recent revisions to each of the protocol documents [ESPbis, AHbis] propose changes to those semantics. However, neither the existing nor proposed semantics are sufficiently general such that IPsec can be used to protect the wide variety of IPv4 and IPv6 multicast applications that are expected by the IP multicast community. In particular, they are not compatible with the needs of the protocols developed in the MSEC WG and for Source Specific Multicast [RFC3376, SSM-ARCH]. This document reviews these semantics and proposes some minor changes, which would enable IPsec to be suitable for these uses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-multicast-issues-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-ipsec-multicast-issues-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-ipsec-multicast-issues-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-23094609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-ipsec-multicast-issues-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-ipsec-multicast-issues-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-23094609.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Dec 23 10:27:37 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06678 for ; Mon, 23 Dec 2002 10:27:37 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0BFDB535F4; Mon, 23 Dec 2002 10:30:10 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 822B053561 for ; Mon, 23 Dec 2002 10:28:01 -0500 (EST) Received: (qmail 66462 invoked by uid 3269); 23 Dec 2002 15:28:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66459 invoked from network); 23 Dec 2002 15:28:01 -0000 Received: from unknown (HELO jupiter.jmi.co.kr) (211.45.79.102) by klesh.pair.com with SMTP; 23 Dec 2002 15:28:01 -0000 Received: (qmail 15616 invoked by uid 525); 24 Dec 2002 00:28:53 +0900 Received: (qmail 15590 invoked from network); 24 Dec 2002 00:28:51 +0900 Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 24 Dec 2002 00:28:51 +0900 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id AAA29899 for ; Tue, 24 Dec 2002 00:31:59 +0900 (KST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18QTp6-0003r4-00 for ietf-announce-list@ran.ietf.org; Mon, 23 Dec 2002 09:44:52 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18QTlc-0003iF-00 for all-ietf@ran.ietf.org; Mon, 23 Dec 2002 09:41:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04156; Mon, 23 Dec 2002 09:36:36 -0500 (EST) Message-Id: <200212231436.JAA04156@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: hangsang@dreamwiz.com Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Precedence: bulk Subject: [MSEC] I-D ACTION:draft-ietf-msec-ipsec-multicast-issues-01.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 23 Dec 2002 09:36:35 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : IP Multicast issues with IPsec Author(s) : M. Baugher, R. Canetti, T. Hardjono, B. Weis Filename : draft-ietf-msec-ipsec-multicast-issues-01.txt Pages : 10 Date : 2002-12-23 The IPsec Architecture [RFC2401] and IPsec transform RFCs [RFC2402, RFC2406] define certain mechanisms for IP multicast traffic. The recent revisions to each of the protocol documents [ESPbis, AHbis] propose changes to those semantics. However, neither the existing nor proposed semantics are sufficiently general such that IPsec can be used to protect the wide variety of IPv4 and IPv6 multicast applications that are expected by the IP multicast community. In particular, they are not compatible with the needs of the protocols developed in the MSEC WG and for Source Specific Multicast [RFC3376, SSM-ARCH]. This document reviews these semantics and proposes some minor changes, which would enable IPsec to be suitable for these uses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-multicast-issues-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-ipsec-multicast-issues-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-ipsec-multicast-issues-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-23094609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-ipsec-multicast-issues-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-ipsec-multicast-issues-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-23094609.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Dec 23 16:15:15 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15367 for ; Mon, 23 Dec 2002 16:15:14 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 46DDD53613; Mon, 23 Dec 2002 16:17:44 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7826D5359C for ; Mon, 23 Dec 2002 16:11:42 -0500 (EST) Received: (qmail 10143 invoked by uid 3269); 23 Dec 2002 21:11:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10139 invoked from network); 23 Dec 2002 21:11:41 -0000 Received: from smtp017.mail.yahoo.com (216.136.174.114) by klesh.pair.com with SMTP; 23 Dec 2002 21:11:41 -0000 Received: from 1cust152.tnt7.bos10.da.uu.net (HELO THARDJONO-LAP.yahoo.com) (thardjono@63.16.3.152 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Dec 2002 21:11:39 -0000 Message-Id: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: ipsec@lists.tislabs.com From: Thomas Hardjono Cc: kent@bbn.com, canetti@watson.ibm.com, mbaugher@cisco.com, bew@cisco.com, msec@securemulticast.org, thardjono@verisign.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Proposed text changes to ESPbis and AHbis for multicast support 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 23 Dec 2002 16:11:34 -0500 The MSEC working group has a number of proposed changes to the text of ESPbis (draft-ietf-ipsec-esp-v3-03.txt) and AHbis (draft-ietf-ipsec-rfc2402bis-01.txt) These proposed changes and its implications to the usability of IPsec in multicast have been rationalized in the following draft: ftp://ftp.ietf.org/internet-drafts/draft-ietf-msec-ipsec-multicast-issues-01.txt The draft explains at length the motivations, though below is a list of the suggested changes. We would like to see some discussion on the IPsec mailing-list regarding these proposed changes. Regards, Thomas/Ran ---------- --------------------------------------------------------------------- ESPbis-change#1: SPI allocation and SA lookup Section 2.1 (Security Parameters Index) specifies exactly how the SPI should be dealt with: For multicast SAs, the SPI (and optionally the protocol ID) in combination with the destination address is used to select an SA. This is because multicast SAs are defined by a multicast controller, not by each IPsec receiver. (See the Security Architecture document for more details) [ESPbis]. We propose this section to be replaced with the following wording: For broadcast, multicast, and anycast SAs, the SPI and protocol ID (ESP) in combination with the destination address is used to select an SA. In some cases, other parameters (such as a source address) MAY be used by a receiver to further identify the correct SA. This is because multicast SAs may be defined by more than one multicast group controller. --------------------------------------------------------------------- ESPbis-change#2: SPI allocation and SA lookup Section 3.4.2 (Security Association Lookup) of [ESPbis] currently states: Upon receipt of a packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the SPI alone (unicast) or SPI combined with destination IP address (multicast). (This process is described in more detail in the Security Architecture document) [ESPbis]. We propose this text be replaced as follows. Upon receipt of a unicast packet containing an ESP Header, the receiver determines the appropriate (unidirectional) SA, based on the SPI alone. (This process is described in more detail in the Security Architecture document.) If the packet is a broadcast, multicast, or anycast packet, there may be more than one SA pointed to by the combination of SPI, security protocol and destination address. This can happen if multiple non-cooperating multicast controllers are present in the network. In this case the receiver MAY use other parameters (such as a source address) to identify the correct SA. Key management MAY indicate (e.g., with an SA attribute) that such processing is necessary in order for a receiver to properly process the ESP packets for a group if that is known a priori. --------------------------------------------------------------------- ESPbis-change#3: Multiple sender SAs and replay protection Section 2.2 (Sequence Number) states: Sharing an SA among multiple senders is deprecated, since there is no general means of synchronizing packet counters among the senders or meaningfully managing a receiver packet counter and window in the context of multiple senders [ESPbis]. We propose the following replacement for the above text in [ESPbis]. For a multi-sender multicast SA, the anti-replay service MUST NOT be used unless key management signals its use. If the anti-replay service is used in this case, each receiver must keep a replay window per sender. --------------------------------------------------------------------- ESPbis-change#4: Integrity vs. Authentication The name associated with the authentication portion of ESP is "Authentication Data". However, [ESPbis] changed the name to "Integrity Check Value". Section 1 says: Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "integrity." (This term is employed because, on a per-packet basis, the computation being performed provides connectionless integrity directly; data origin authentication is provided indirectly as a result of binding the key used to verify the integrity to the identity of the IPsec peer [ESPbis]. We propose the following wording changes to [ESPbis]. 1. The text quoted above from Section 1 should be replaced with: Data origin authentication and connectionless integrity are joint services, hereafter referred to jointly as "authentication." 2. All occurrences of "Integrity-only ESP" should be "Authentication-only ESP". 3. The "Integrity Check Value" field in AH should be named "Authentication Data", and all references to that section should be updated. --------------------------------------------------------------------- AHbis-change#1: SPI allocation and SA lookup Section 2.4 (Security Parameters Index) specifies exactly how the SPI should be dealt with. It is identical to [ESPbis] wording: For multicast SAs, the SPI (and optionally the protocol ID) in combination with the destination address is used to select an SA. This is because multicast SAs are defined by a multicast controller, not by each IPsec receiver. (See the Security Architecture document for more details) [AHbis]. As in the case with [ESPbis], we propose this section to be replaced with the following wording: For broadcast, multicast, and anycast SAs, the SPI and protocol ID (AH) in combination with the destination address is used to select an SA. In some cases other parameters (such as a source address) MAY be used by a receiver to further identify the correct SA. This is because multicast SAs may be defined by more than one multicast group controller. --------------------------------------------------------------------- AHbis-change#2: (appended text) Section 3.4.2 (Security Association Lookup) of [AHbis] also needs to be modified to reflect these semantics. It currently states: Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA, based on the destination IP address, security protocol (AH), and the SPI [AHbis]. No change to this text is necessary. We propose that the following text be appended to it. If the packet is a broadcast, multicast, or anycast packet, there may be more than one SA pointed to by the combination of SPI, security protocol and destination address. This can happen if multiple non-cooperating multicast controllers are present in the network. In this case the receiver MAY use other parameters (such as a source address) to identify the correct SA. Key management MAY indicate (e.g., with an SA attribute) that such processing is necessary in order for a receiver to properly process the AH packets for a group if that is known a priori. --------------------------------------------------------------------- AHbis-change#3: Multiple sender SAs and replay protection Same as ESPbis-change#3 above. --------------------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 25 03:41:58 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14048 for ; Wed, 25 Dec 2002 03:41:57 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 18008535F8; Wed, 25 Dec 2002 03:44:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CE84D53639 for ; Wed, 25 Dec 2002 03:42:06 -0500 (EST) Received: (qmail 28386 invoked by uid 3269); 25 Dec 2002 08:42:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28383 invoked from network); 25 Dec 2002 08:42:06 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 25 Dec 2002 08:42:06 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn3-131.cisco.com [10.21.64.131]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBP8fPjb029432; Wed, 25 Dec 2002 00:41:26 -0800 (PST) Message-Id: <5.1.1.5.2.20021225000045.04b64b30@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Stephen Kent From: Mark Baugher Cc: Thomas Hardjono , ipsec@lists.tislabs.com, canetti@watson.ibm.com, Brian Weis , msec@securemulticast.org In-Reply-To: References: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: Proposed text changes to ESPbis and AHbis for multicast support 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 25 Dec 2002 00:41:23 -0800 Steve, At 04:06 PM 12/24/2002 -0500, Stephen Kent wrote: >Thomas, > >I have read the message and your ID on multicast and IPsec. Here are my >comments: > >>--------------------------------------------------------------------- >>ESPbis-change#1: SPI allocation and SA lookup >> >>Section 2.1 (Security Parameters Index) specifies exactly how the >>SPI should be dealt with: >> >> For multicast SAs, the SPI (and optionally the protocol ID) in >> combination with the destination address is used to select an SA. >> This is because multicast SAs are defined by a multicast >> controller, not by each IPsec receiver. (See the Security >> Architecture document for more details) [ESPbis]. >> >>We propose this section to be replaced with the following wording: >> >> For broadcast, multicast, and anycast SAs, the SPI and protocol >> ID (ESP) in combination with the destination address is used to >> select an SA. In some cases, other parameters (such as a source >> address) MAY be used by a receiver to further identify the >> correct SA. This is because multicast SAs may be defined by more >> than one multicast group controller. > >The text above does not provide a useful, testable specification. It >allows (MAY) a receiver to use a source address and other, undefined >parameters for SA selection, but does not require it. The result is that a >complaint IPsec implementation need not do any of this, which makes for a >weak standard and does nothing for interoperability. We need concrete >specs for developers and this does not provide such specs. It has the >feature of allowing a future implementation to able to claim compliance >with the spec when someone figures out exactly what to do for >multicast/broadcast/anycast, but this does nothing for interoperabilty, >which is a primary goal of RFCs. I agree and think think that the source address, and only the source address, should be a MUST. >At a minimum I think you need to be able to create text of the form "An >IPsec implementation that supports multicast, broadcast, or anycast MUST >..." in order for this to be useful. I get the sense, from the ID you just >published, that the MSEC WG has not yet decided exactly what requirements >need to be imposed and exactly how to deal with these issues, and thus it >seems premature to write the sort of text I suggest is really required. Inclusion of the source address in SA lookup was recommended by IRTF SMuG years ago and nothing has changed in MSEC since that time. >Your ID erroneously states that the revised AH and ESP IDs change the >semantics of SA demuxing and make the lookups "less specific." The changes >we made in the new AH & ESP drafts re what parameters define an SA and >thus are used to demux incoming IPsec packets, are clarifications designed >to reflect what many developers already knew and practiced in their >implementations. The original text over-specified SA demuxing, imposing >parameters (destination address and protocol) that were irrelevant for >unicast SA demuxin. As a result, smart developers realized that they could >manage the SPI space in a way that never made use of these values and they >did so. The changes you suggest for multicast SA demuxing here, i.e., use >of the source address, were NOT supported in the current AH and ESP RFCs >not in 2401 and so the clarifications made in the revised AH and ESP specs >did not adversely affect what you suggest might need to done to better >support multicast SAs. > >Your ID cites two issues re what parameters are used to uniquely identify >(demux) an SA, but seems to confuse the implications of these two issues, >and the text above seems to reflect this confusion. > > Your ID says that an SSM group is defined by a single sender and > a set of receivers. it may use the same multicast address as another, > distinct SSM group, presumably with a different sender but perhaps an > overlapping set of receivers. Hence you infer that using the destination > (multicast) address and an SPI is not sufficient to uniquely identify > (for receivers) an SA for this type of multicast group, because the > senders do not coordinate with one another. This is primarily a group controller issue and not a sender issue as described in section 2.1 of the I-D. >It would seem for this case that use of the sender address plus the >multicast destination address provides a natural means of identifying the >SA, but the ID does not discuss any other options that have been explored >and rejected. For example, what sort of interactions do the sender and >receivers engage in to create this sort of group, how is the key >distributed, and might there be a way to use data from those interactions >to create an SPI that would allow demuxing using the parameters currently >defined? I think the I-D states what it needs to: A group controller maintains the key for the group and the members (senders and receivers) interact with the group controller to establish the group key. A single multicast group can support multiple SSM groups, each can be in a separate administrative domain with a separate group controller. > Separately, the ID discusses the notion that multiple controllers > might be involved inn managing a multicast group (presumably not an SSM > group) and that these controllers might not be able to coordinate to > select a unique SPI (relative to a single multicast address). But if > these controllers coordinate to distribute the single key used for > encrypting/decrypting traffic on a multicast SA, These controllers need not and do not coordinate to do anything. No such protocol exists to my knowledge, at least not in the public domain. >why are they unable to coordinate on assigning a single SPI for a >multicast SA? Thus this latter argument for having to use some parameter >other than the destination address and SPI for SA demuxing is not persuasive. Maybe the I-D is not clear enough. There can be N SSM groups for an IP multicast group and there can be as many as N group controllers operating independently. >I think a better analysis is required here before we impose new/additional >constraints on SA demuxing in IPsec. > >>--------------------------------------------------------------------- >>ESPbis-change#2: SPI allocation and SA lookup >> >>Section 3.4.2 (Security Association Lookup) of [ESPbis] currently states: >> >> Upon receipt of a packet containing an ESP Header, the receiver >> determines the appropriate (unidirectional) SA, based on the SPI >> alone (unicast) or SPI combined with destination IP address >> (multicast). (This process is described in more detail in the >> Security Architecture document) [ESPbis]. >> >>We propose this text be replaced as follows. >> >> Upon receipt of a unicast packet containing an ESP Header, the >> receiver determines the appropriate (unidirectional) SA, based on >> the SPI alone. (This process is described in more detail in the >> Security Architecture document.) >> >> If the packet is a broadcast, multicast, or anycast packet, there >> may be more than one SA pointed to by the combination of SPI, >> security protocol and destination address. This can happen if >> multiple non-cooperating multicast controllers are present in the >> network. In this case the receiver MAY use other parameters (such >> as a source address) to identify the correct SA. Key management >> MAY indicate (e.g., with an SA attribute) that such processing is >> necessary in order for a receiver to properly process the ESP >> packets for a group if that is known a priori. > >The second paragraph begins by redefining what an SA is, and that's not a >great start considering how long we have had a stable definition for an SA. It's a matter of SA lookup. The second paragraph wants to redefine SA lookup, which is the point of the I-D. >Here too, the the lack of specific, testable requirements here makes for a >poor spec. We want to ensure interoperability and MAYs don't cut it. This >is essentially a placeholder that allows a later design to say it is >compliant, but which does not contribute to interoperability. I don't >think this is a good path for IPsec RFCs. If we cannot specify exactly >what values are used by a receiver to identify traffic as belonging to a >specific SA, then a developer cannot produce code or hardware that will >perform the selection. Deferring this to the key management protocol is >not a solution, it is just a level of indirection. This is the same issue as above because the text was copied. >>--------------------------------------------------------------------- >>ESPbis-change#3: Multiple sender SAs and replay protection >> >> >>Section 2.2 (Sequence Number) states: >> >> Sharing an SA among multiple senders is deprecated, since there >> is no general means of synchronizing packet counters among the >> senders or meaningfully managing a receiver packet counter and >> window in the context of multiple senders [ESPbis]. >> >> >>We propose the following replacement for the above text in [ESPbis]. >> >> For a multi-sender multicast SA, the anti-replay service MUST NOT >> be used unless key management signals its use. If the anti-replay >> service is used in this case, each receiver must keep a replay >> window per sender. > >I agree in principle with the intent of this notion, but the sticking >point is that we have not yet agreed on a way to accommodate this >requirement. Your ID states that requiring an SA per sender is unacceptable, Where does it state that? >and alludes to some scenario that motivates this statement, but provide no >details to support the assertion. The text above has the flavor of a >placeholder, rather than a useful spec to guide developers in producing >interoperable implementations. The text imposes a vague requirement >without any supporting analysis of the problems imposed by the requirement. The requirement was stated in a note posted by Bill Fenner to this list last Spring. The replacement text allows multi-sender SAs, it's clear that this is a change from ESPbis, and designates key management as the entity that determines whether or not a replay window is kept in the receiver. >>--------------------------------------------------------------------- >>ESPbis-change#4: Integrity vs. Authentication >> >>The name associated with the authentication portion of ESP is >>"Authentication Data". However, [ESPbis] changed the name to >>"Integrity Check Value". >> >>Section 1 says: >> >> Data origin authentication and connectionless integrity are joint >> services, hereafter referred to jointly as "integrity." (This >> term is employed because, on a per-packet basis, the computation >> being performed provides connectionless integrity directly; data >> origin authentication is provided indirectly as a result of >> binding the key used to verify the integrity to the identity of >> the IPsec peer [ESPbis]. >> >>We propose the following wording changes to [ESPbis]. >> >> 1. The text quoted above from Section 1 should be replaced with: >> >> Data origin authentication and connectionless integrity are joint >> services, hereafter referred to jointly as "authentication." >> >> 2. All occurrences of "Integrity-only ESP" should be >> "Authentication-only ESP". >> >> 3. The "Integrity Check Value" field in AH should be named >> "Authentication Data", and all references to that section should >> be updated. > >We changed the term for good reasons. First, the ICV acronym expands to >"Integrity Check Value" and it has been there since before the previous >set of RFCs. Second, the function really does provide >integrity. Authentication is a side effect that results from knowing the >identity of the holder of the key used to generate the ICV, as noted above. It's not suitable for multicast source authentication. I think this is explained adequately in section 3.3 of the I-D. >Overall, I found that the ID did not provide adequate motivation for most >of the proposed changes, and I recommend that none of the proposed changes >be made at this time. The text needs to be changed so that is >sufficiently detailed to promote the development of interoperable >implementations, something that it does not do as it stands. If such text >is provided, then the IPsec WG needs to review any new requirements for >multicast/broadcast/anycast support, to ensure that they do not impose >unacceptable burdens, e.g., re support of anti-replay for multi-sender >SAs. The IPsec WG chairs need to determine if they wish to delay the >revisions to AH and ESP until both of these criteria are satisfied. I hope you'll work with us to address the issues that you have identified. Mark >Steve _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec