From msec-bounces@securemulticast.org Wed Nov 02 03:55:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXEPH-0003Z4-2Q for msec-archive@megatron.ietf.org; Wed, 02 Nov 2005 03:55:43 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21563 for ; Wed, 2 Nov 2005 03:55:22 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E7A3A8D182; Wed, 2 Nov 2005 03:55:41 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BB6008D17C for ; Wed, 2 Nov 2005 03:55:39 -0500 (EST) Received: (qmail 43285 invoked by uid 3269); 2 Nov 2005 08:55:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 43282 invoked from network); 2 Nov 2005 08:55:39 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 Nov 2005 08:55:39 -0000 Received: from 126.com (bj45-160.i.netease.com [202.108.45.160]) by klesh.pair.com (Postfix) with SMTP id 0115B68352 for ; Wed, 2 Nov 2005 03:55:37 -0500 (EST) Received: from IMAGE-MYCOMPUTER (unknown [202.115.30.190]) by smtp3 (Coremail) with SMTP id GQEhQ+x+aENL30QG.58688S2; Wed, 02 Nov 2005 16:55:23 +0800 (CST) Date: Wed, 2 Nov 2005 16:55:57 +0800 From: "Q.Shevchenko" To: "msec" Organization: UESTC X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20051102085537.0115B68352@klesh.pair.com> Subject: [MSEC] Authentication and IGMP X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1522853222==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============1522853222== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGw6DQoNCkluIHNlY3VyZSBtdWx0aWNhc3QsIGF1dGhlbnRpY2F0aW9uIGlzIG5lZWRl ZCBiZWZvcmUgbWVtYmVyoa9zIGFkZGl0aW9uLiBTbyBJoa9kIGxpa2UgdG8ga25vdywgd2hlbiBk b2VzIGF1dGhlbnRpY2F0aW9uIHRha2UgcGxhY2U/IEJlZm9yZSBvciBhZnRlciBJR01QPyBJIGhh dmUgbm90IHNlZW4gYW55IHN1Y2ggZGVzY3JpcHRpb25zLg0KDQpSZWdhcmRzIQkNCg0KoaGhoaGh oaGhoaGhoaGhoVEuU2hldmNoZW5rbw0KICAgICAgICAgICAgICAgICAgMjAwNS0xMS0yDQo= --===============1522853222== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============1522853222==-- From msec-bounces@securemulticast.org Wed Nov 02 08:37:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIoG-0005PB-IR for msec-archive@megatron.ietf.org; Wed, 02 Nov 2005 08:37:48 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06392 for ; Wed, 2 Nov 2005 08:37:25 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4AD118CF28; Wed, 2 Nov 2005 08:37:47 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B89DD8CC82 for ; Wed, 2 Nov 2005 08:37:45 -0500 (EST) Received: (qmail 94619 invoked by uid 3269); 2 Nov 2005 13:37:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94616 invoked from network); 2 Nov 2005 13:37:45 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 Nov 2005 13:37:45 -0000 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by klesh.pair.com (Postfix) with ESMTP id 407826835B for ; Wed, 2 Nov 2005 08:37:45 -0500 (EST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 02 Nov 2005 05:37:44 -0800 X-IronPort-AV: i="3.97,280,1125903600"; d="scan'208"; a="671218889:sNHT25318652" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA2DbAOP022401; Wed, 2 Nov 2005 05:37:42 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 05:37:32 -0800 Received: from [172.20.9.11] ([10.21.113.26]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Nov 2005 05:37:32 -0800 In-Reply-To: <20051102085537.0115B68352@klesh.pair.com> References: <20051102085537.0115B68352@klesh.pair.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Authentication and IGMP Date: Wed, 2 Nov 2005 05:37:42 -0800 To: "Q.Shevchenko" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 02 Nov 2005 13:37:32.0107 (UTC) FILETIME=[9375C9B0:01C5DFB2] Cc: msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit hi This issue comes up regularly but there is no authorization/authentication security feature for IGMP. It has been considered and failed to get consensus support in the past. Mark On Nov 2, 2005, at 12:55 AM, Q.Shevchenko wrote: > Dear all: > > In secure multicast, authentication is needed before member’s > addition. So I’d like to know, when does authentication take place? > Before or after IGMP? I have not seen any such descriptions. > > Regards! > > 　　　　　　　　Q.Shevchenko > 2005-11-2 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Nov 02 14:53:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXOfl-0001Jm-ML for msec-archive@megatron.ietf.org; Wed, 02 Nov 2005 14:53:25 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05051 for ; Wed, 2 Nov 2005 14:53:01 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6E3DA8D061; Wed, 2 Nov 2005 14:53:20 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 60A528CBEE for ; Wed, 2 Nov 2005 14:53:18 -0500 (EST) Received: (qmail 69852 invoked by uid 3269); 2 Nov 2005 19:53:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69849 invoked from network); 2 Nov 2005 19:53:18 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 Nov 2005 19:53:18 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id EDCC868359 for ; Wed, 2 Nov 2005 14:53:17 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA2JrEqq025003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Nov 2005 11:53:15 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA2JrCAo027068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Nov 2005 11:53:13 -0800 (PST) Message-Id: <6.2.5.6.2.20051102115158.02d428f0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 02 Nov 2005 11:53:14 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti Subject: [MSEC] Presentations X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Please send your presentations at the MSEC meeting in Vancouver to Ran and me as soon as you can so we can make them available for attendees. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 03 14:59:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXlFH-000264-3Q for msec-archive@megatron.ietf.org; Thu, 03 Nov 2005 14:59:35 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23205 for ; Thu, 3 Nov 2005 14:59:11 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AAD1F8CBBC; Thu, 3 Nov 2005 14:59:32 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 54E108C76B for ; Thu, 3 Nov 2005 14:59:30 -0500 (EST) Received: (qmail 33052 invoked by uid 3269); 3 Nov 2005 19:59:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 33049 invoked from network); 3 Nov 2005 19:59:30 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Nov 2005 19:59:30 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 3421668352 for ; Thu, 3 Nov 2005 14:59:30 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA3JxReX017302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2005 11:59:27 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA3JxPx9023425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Nov 2005 11:59:25 -0800 (PST) Message-Id: <6.2.5.6.2.20051103115121.02f25ea0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 03 Nov 2005 11:59:23 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ran Canetti Subject: [MSEC] MSEC Agenda in Vancouver X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Following Brian Weis's suggestion/request for more time to discuss the IPsec extensions work item, here is a revised agenda with time allotments: Please let Ran and I know if you have any further suggestions for modification: * Update on milestones & Recent progress in MSEC (5 mins) * Update on Bootstrapping TESLA (5 mins) * Update on GKDP (5 mins) * Discussion on MIKEY modes (20 mins) * MIKEY-ECC * MIKEY-RSA-R * Any other MIKEY related topics * Discussion on the IPsec Extensions work (20 mins) * MSEC Action items revision and follow-up work (5 mins) The current agenda is here: http://www3.ietf.org/proceedings/05nov/agenda/msec.txt and will be replaced with the above. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 07 20:20:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIA9-0002RD-SH for msec-archive@megatron.ietf.org; Mon, 07 Nov 2005 20:20:38 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28844 for ; Mon, 7 Nov 2005 20:20:11 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7496B8D455; Mon, 7 Nov 2005 20:20:33 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id AB0238D386 for ; Mon, 7 Nov 2005 20:20:31 -0500 (EST) Received: (qmail 89215 invoked by uid 3269); 8 Nov 2005 01:20:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89212 invoked from network); 8 Nov 2005 01:20:31 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Nov 2005 01:20:31 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 4F5BD6836F for ; Mon, 7 Nov 2005 20:20:31 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA81KQpK006989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Nov 2005 17:20:26 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-134.qualcomm.com [10.50.65.134]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA81KBZP003108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Nov 2005 17:20:24 -0800 (PST) Message-Id: <6.2.5.6.2.20051107171251.0385fd70@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 07 Nov 2005 17:16:15 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti Subject: [MSEC] Need note-takers X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, If you are at the Vancouver meeting and don't plan to present anything, please, please volunteer to take minutes. We are expecting discussions on 2 topics and would like to document the discussion for consensus on the list. It's only for 1 hour, so shouldn't be too much of a burden. Thanks in advance. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Nov 08 14:09:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYqu-000234-OQ for msec-archive@megatron.ietf.org; Tue, 08 Nov 2005 14:09:52 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26539 for ; Tue, 8 Nov 2005 14:09:25 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D3FE18C948; Tue, 8 Nov 2005 14:09:51 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B168A8C8A9 for ; Tue, 8 Nov 2005 14:09:50 -0500 (EST) Received: (qmail 80599 invoked by uid 3269); 8 Nov 2005 19:09:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80596 invoked from network); 8 Nov 2005 19:09:50 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Nov 2005 19:09:50 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 4E33F6836F for ; Tue, 8 Nov 2005 14:09:50 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA8J9kpK022789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Nov 2005 11:09:47 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-241.qualcomm.com [10.50.64.241]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA8J9h7K003012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Nov 2005 11:09:44 -0800 (PST) Message-Id: <6.2.5.6.2.20051108110554.04195ea8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 08 Nov 2005 11:09:42 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti Subject: [MSEC] http://securemulticast.org/IETF-64/msec-ietf-64.htm X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, I have uploaded the presentations I have received so far to the securemulticast.org site. I am supposed to upload all this stuff to the IETF proceedings page, but I forgot my password to that site (again). We use it infrequently; I thought I cached that key, but can't find it now. Please do note that the presentations may change before the meeting, but they are posted for the benefit of (among other things) early review. Please send any comments to the list. This is a great opportunity for folks not here in Vancouver to take an active part in the discussions at the meeting. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Nov 08 16:16:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZapF-0001h7-Ma for msec-archive@megatron.ietf.org; Tue, 08 Nov 2005 16:16:17 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06184 for ; Tue, 8 Nov 2005 16:15:49 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 64F098CAD2; Tue, 8 Nov 2005 16:16:16 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 753FC8C8AB for ; Tue, 8 Nov 2005 16:16:15 -0500 (EST) Received: (qmail 98829 invoked by uid 3269); 8 Nov 2005 21:16:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98826 invoked from network); 8 Nov 2005 21:16:15 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Nov 2005 21:16:15 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id 4813F68377 for ; Tue, 8 Nov 2005 16:16:15 -0500 (EST) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jA8LHw5S023839; Tue, 8 Nov 2005 16:18:02 -0500 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jA8LG1n135684; Tue, 8 Nov 2005 16:16:01 -0500 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jA8LG0N149412; Tue, 8 Nov 2005 16:16:00 -0500 Received: from prf.watson.ibm.com (prf.watson.ibm.com [9.2.16.112]) by mgsmtp00.watson.ibm.com (8.12.11/8.12.11/2005/09/01) with ESMTP id jA8MFft2009805; Tue, 8 Nov 2005 17:15:41 -0500 Received: from localhost (canetti@localhost) by prf.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id jA8LFxA31970; Tue, 8 Nov 2005 16:15:59 -0500 Date: Tue, 8 Nov 2005 16:15:58 -0500 (EST) From: canetti To: Lakshminath Dondeti In-Reply-To: <6.2.5.6.2.20051108110554.04195ea8@qualcomm.com> Message-ID: References: <6.2.5.6.2.20051108110554.04195ea8@qualcomm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: msec@securemulticast.org Subject: [MSEC] Re: http://securemulticast.org/IETF-64/msec-ietf-64.htm X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi LAkshminath, I think that in the end I'll call you tonite from my home phone, 617 277 4281. what naumber should i call? thx, Ran _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Nov 08 16:24:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZaxX-0003JV-Mp for msec-archive@megatron.ietf.org; Tue, 08 Nov 2005 16:24:51 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06713 for ; Tue, 8 Nov 2005 16:24:24 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C0B368CBBA; Tue, 8 Nov 2005 16:24:50 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B74998C983 for ; Tue, 8 Nov 2005 16:24:48 -0500 (EST) Received: (qmail 145 invoked by uid 3269); 8 Nov 2005 21:24:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 142 invoked from network); 8 Nov 2005 21:24:48 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Nov 2005 21:24:48 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 691736836F for ; Tue, 8 Nov 2005 16:24:48 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA8LOb3M032262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Nov 2005 13:24:43 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-66-40.qualcomm.com [10.50.66.40]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA8LO1vB021973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Nov 2005 13:24:15 -0800 (PST) Message-Id: <6.2.5.6.2.20051108132248.04074898@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 08 Nov 2005 13:23:54 -0800 To: canetti From: Lakshminath Dondeti In-Reply-To: References: <6.2.5.6.2.20051108110554.04195ea8@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: msec@securemulticast.org Subject: [MSEC] Re: http://securemulticast.org/IETF-64/msec-ietf-64.htm X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org 858.334.9671 I think we will be in jabber too, if only I can find a scribe :-). regards, Lakshminath At 01:15 PM 11/8/2005, canetti wrote: >Hi LAkshminath, I think that in the end I'll call you tonite from my home >phone, 617 277 4281. what naumber should i call? > >thx, > >Ran _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Nov 08 19:42:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZe2M-00065x-P0 for msec-archive@megatron.ietf.org; Tue, 08 Nov 2005 19:42:02 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28952 for ; Tue, 8 Nov 2005 19:41:35 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 726EA8CBAA; Tue, 8 Nov 2005 19:42:01 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 5B1778CB3D for ; Tue, 8 Nov 2005 19:42:00 -0500 (EST) Received: (qmail 25169 invoked by uid 3269); 9 Nov 2005 00:42:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25166 invoked from network); 9 Nov 2005 00:42:00 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 9 Nov 2005 00:42:00 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 14D7468374 for ; Tue, 8 Nov 2005 19:42:00 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA90fupK024476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Nov 2005 16:41:56 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-66-167.qualcomm.com [10.50.66.167]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jA90fpvB028443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Nov 2005 16:41:54 -0800 (PST) Message-Id: <6.2.5.6.2.20051108164006.03be07f0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 08 Nov 2005 16:41:51 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti Subject: [MSEC] Updated agenda and 1 more presentation on MIKEY uploaded X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, Please note that I have added an item to the agenda and uploaded a presentation from Bob M. http://www.securemulticast.org/IETF-64/msec-ietf-64.htm http://www.securemulticast.org/IETF-64/MSEC-SAML%20assisted%20Diffie-Hellman-01.ppt Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Nov 09 19:30:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea0Kw-0007GU-Kf for msec-archive@megatron.ietf.org; Wed, 09 Nov 2005 19:30:42 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21843 for ; Wed, 9 Nov 2005 19:30:15 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 669E98C89B; Wed, 9 Nov 2005 19:30:41 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id A206F8C135 for ; Wed, 9 Nov 2005 19:30:40 -0500 (EST) Received: (qmail 8650 invoked by uid 3269); 10 Nov 2005 00:30:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8647 invoked from network); 10 Nov 2005 00:30:40 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 10 Nov 2005 00:30:40 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 4A3BF68377 for ; Wed, 9 Nov 2005 19:30:40 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAA0Ub3M006613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Nov 2005 16:30:37 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-34.qualcomm.com [10.50.64.34]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAA0UYvB005335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Nov 2005 16:30:35 -0800 (PST) Message-Id: <6.2.5.6.2.20051109162503.03bfac48@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 09 Nov 2005 16:30:34 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti Subject: [MSEC] Draft minutes X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org All, Thanks to Steffen Fries we have the following draft minutes. I edited them and so any mistakes are mine. Please take the time to review them. I would like to post these around noon tomorrow. If you need more time, please let me know. thanks. http://www.securemulticast.org/IETF-64/minutes.txt A couple (there are more; I will list them in the meeting summary) of action items from the meeting are as follows: 1. Start a discussion on the scope of the IPsec extensions work; once that is done, Brian and his co-editors will prepare -01- of that document and we will circulate to the IPSEC list. (Brian to follow-up) 2. Start a discussion on the MIKEY modes. (to follow-up) regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 10 10:49:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEgN-0000r8-IJ for msec-archive@megatron.ietf.org; Thu, 10 Nov 2005 10:49:47 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11772 for ; Thu, 10 Nov 2005 10:49:18 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6CF268CB1C; Thu, 10 Nov 2005 10:44:07 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 74A958C66A for ; Thu, 10 Nov 2005 10:44:06 -0500 (EST) Received: (qmail 71013 invoked by uid 3269); 10 Nov 2005 15:44:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71010 invoked from network); 10 Nov 2005 15:44:06 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 10 Nov 2005 15:44:06 -0000 Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by klesh.pair.com (Postfix) with SMTP id 407BC6836F for ; Thu, 10 Nov 2005 10:44:06 -0500 (EST) Received: (qmail 56586 invoked from network); 10 Nov 2005 10:44:03 -0500 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 10 Nov 2005 10:44:03 -0500 Received: (qmail 24209 invoked from network); 10 Nov 2005 10:44:02 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 10 Nov 2005 10:44:02 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id jAAFYZ611374; Thu, 10 Nov 2005 10:34:35 -0500 Date: Thu, 10 Nov 2005 10:34:35 -0500 (EST) From: George Gross To: Lakshminath Dondeti Subject: Re: [MSEC] Draft minutes In-Reply-To: <6.2.5.6.2.20051109162503.03bfac48@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi Lakshminath, I have one correction, and a question.... The small correction regards a sentence describing Brian's update on the IPsec extensions work in the last bullet item above Issue 1. The current text says: "for a small number of senders, it might be ok to just have as many GSAs as there are senders..." I think that what you meant to say instead was: "for a small number of senders, it might be ok to just have as many IPsec data SAs as there are senders..." since in this context we are talking about having one GSA and an array of IPsec data SA, each data SA having a distinct anti-replay state per sender but all sharing the same group key. In other words, we do _not_ want to imply that a Group Member must execute a join group registration exchange for N groups, each with its own GSA, simply because the application has N senders. This latter approach would not be transparent to the application. As a separate question, could someone please clarify for my benefit more about what was said in the context of the meeting minutes about Issue 1 where Russ is quoted as saying: "Russ: 2401bis gets through the entire architecture without touching IKE. Why do you think you can't do the same thing." Would it be accurate to say that if the MSEC IPsec extensions document defined a conceptual interface between the GKMP and the IPsec subsystem (as discussed in Issue 4) then the document would suffiently independent from the GKMP, and therefore the document would be following in the spirit of RFC2401-bis? hth, George On Wed, 9 Nov 2005, Lakshminath Dondeti wrote: > All, > > Thanks to Steffen Fries we have the following draft minutes. I > edited them and so any mistakes are mine. Please take the time to > review them. I would like to post these around noon tomorrow. If > you need more time, please let me know. thanks. > > http://www.securemulticast.org/IETF-64/minutes.txt > > A couple (there are more; I will list them in the meeting summary) of > action items from the meeting are as follows: > > 1. Start a discussion on the scope of the IPsec extensions work; once > that is done, Brian and his co-editors will prepare -01- of that > document and we will circulate to the IPSEC list. (Brian to follow-up) > > 2. Start a discussion on the MIKEY modes. (to follow-up) > > regards, > Lakshminath > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 10 14:12:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHq4-0007Xm-Sv for msec-archive@megatron.ietf.org; Thu, 10 Nov 2005 14:12:01 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27357 for ; Thu, 10 Nov 2005 14:11:32 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C6D938C924; Thu, 10 Nov 2005 14:11:59 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 24B5A8C3CB for ; Thu, 10 Nov 2005 14:11:59 -0500 (EST) Received: (qmail 3018 invoked by uid 3269); 10 Nov 2005 19:11:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3015 invoked from network); 10 Nov 2005 19:11:59 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 10 Nov 2005 19:11:59 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id E16416836F for ; Thu, 10 Nov 2005 14:11:58 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAAJBlpK000402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Nov 2005 11:11:48 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-137.qualcomm.com [10.50.65.137]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAAJBRZL012627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Nov 2005 11:11:42 -0800 (PST) Message-Id: <6.2.5.6.2.20051110103304.03e34358@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Nov 2005 11:03:58 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SEC ADs , Russ Housley Subject: [MSEC] MSEC summary (please review and send comments) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org MSEC progress: We successfully moved 1 more document, srtp-tesla, into the Q Secure group policy work is in AD review, Bootstrapping TESLA is IETF LC and a MIKEY newtype-keyid draft is with another SDO Current major discussions: We have two major threads of work in the group: msec-ipsec-extensions mikey-modes We also have a few work items in progress (GKDP and TESLA spec) and expect may be another. If all goes well, we may be done by this time next year. Next steps: Two mailing list discussions to follow: * Brian Weis to initiate/continue the discussion on the MSEC IPsec extensions work in the list Prepare a -01- after that discussion, along with his co-authors, with the plan to submit it to the IPSEC list for discussion * The chairs plan to initiate a discussion on the various MIKEY modes and their relative usefulness, assess consensus and decide on the next steps in that area. Another AI: (Update Milestones) regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 10 14:44:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaILX-0002ep-6w for msec-archive@megatron.ietf.org; Thu, 10 Nov 2005 14:44:31 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29535 for ; Thu, 10 Nov 2005 14:44:03 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 926168CB5C; Thu, 10 Nov 2005 14:44:30 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 523188CCC4 for ; Thu, 10 Nov 2005 14:44:29 -0500 (EST) Received: (qmail 6981 invoked by uid 3269); 10 Nov 2005 19:44:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6978 invoked from network); 10 Nov 2005 19:44:29 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 10 Nov 2005 19:44:29 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id E942368374 for ; Thu, 10 Nov 2005 14:44:28 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAAJiOpK003694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Nov 2005 11:44:25 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-193.qualcomm.com [10.50.65.193]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAAJiLvB028138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Nov 2005 11:44:22 -0800 (PST) Message-Id: <6.2.5.6.2.20051110113648.041cb868@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 10 Nov 2005 11:44:21 -0800 To: George Gross From: Lakshminath Dondeti Subject: Re: [MSEC] Draft minutes In-Reply-To: References: <6.2.5.6.2.20051109162503.03bfac48@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi George, I replaced GSA with IPsec SA; that was my intent earlier and thanks for catching it. On the clarification, we'll discuss it in detail very soon. regards, Lakshminath At 07:34 AM 11/10/2005, George Gross wrote: >Hi Lakshminath, > >I have one correction, and a question.... > >The small correction regards a sentence describing Brian's update on the >IPsec extensions work in the last bullet item above Issue 1. The current >text says: > >"for a small number of senders, it might be ok to just have > as many GSAs as there are senders..." > >I think that what you meant to say instead was: > >"for a small number of senders, it might be ok to just have > as many IPsec data SAs as there are senders..." > >since in this context we are talking about having one GSA and an array of >IPsec data SA, each data SA having a distinct anti-replay state per sender >but all sharing the same group key. In other words, we do _not_ want to >imply that a Group Member must execute a join group registration exchange >for N groups, each with its own GSA, simply because the application has N >senders. This latter approach would not be transparent to the application. > >As a separate question, could someone please clarify for my benefit more >about what was said in the context of the meeting minutes about Issue 1 >where Russ is quoted as saying: > >"Russ: 2401bis gets through the entire architecture without touching >IKE. Why do you think you can't do the same thing." > >Would it be accurate to say that if the MSEC IPsec extensions document >defined a conceptual interface between the GKMP and the IPsec subsystem >(as discussed in Issue 4) then the document would suffiently independent >from the GKMP, and therefore the document would be following in the spirit >of RFC2401-bis? > >hth, > George > >On Wed, 9 Nov 2005, Lakshminath Dondeti wrote: > > > All, > > > > Thanks to Steffen Fries we have the following draft minutes. I > > edited them and so any mistakes are mine. Please take the time to > > review them. I would like to post these around noon tomorrow. If > > you need more time, please let me know. thanks. > > > > http://www.securemulticast.org/IETF-64/minutes.txt > > > > A couple (there are more; I will list them in the meeting summary) of > > action items from the meeting are as follows: > > > > 1. Start a discussion on the scope of the IPsec extensions work; once > > that is done, Brian and his co-editors will prepare -01- of that > > document and we will circulate to the IPSEC list. (Brian to follow-up) > > > > 2. Start a discussion on the MIKEY modes. (to follow-up) > > > > regards, > > Lakshminath > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 14 20:23:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbpXX-0003l5-8T for msec-archive@megatron.ietf.org; Mon, 14 Nov 2005 20:23:15 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16856 for ; Mon, 14 Nov 2005 20:22:43 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3592D8C8DB; Mon, 14 Nov 2005 20:23:14 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 9DFDB8C6F9 for ; Mon, 14 Nov 2005 20:23:13 -0500 (EST) Received: (qmail 14660 invoked by uid 3269); 15 Nov 2005 01:23:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14657 invoked from network); 15 Nov 2005 01:23:13 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Nov 2005 01:23:13 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 346646836F for ; Mon, 14 Nov 2005 20:23:13 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAF1N8dE022623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Nov 2005 17:23:09 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAF1N6vB006806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Nov 2005 17:23:07 -0800 (PST) Message-Id: <6.2.5.6.2.20051114172047.03cfeee0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 14 Nov 2005 17:23:04 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ran Canetti Subject: [MSEC] All meeting materials available on the MSEC site. X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org hi all, All meeting materials are available at http://www.securemulticast.org/IETF-64/msec-ietf-64.htm regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Nov 15 12:16:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4Q1-00027j-3u for msec-archive@megatron.ietf.org; Tue, 15 Nov 2005 12:16:29 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10373 for ; Tue, 15 Nov 2005 12:15:55 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0F0C38D199; Tue, 15 Nov 2005 12:16:20 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 4C39B8CF2A for ; Tue, 15 Nov 2005 12:16:16 -0500 (EST) Received: (qmail 10996 invoked by uid 3269); 15 Nov 2005 17:16:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10992 invoked from network); 15 Nov 2005 17:16:16 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Nov 2005 17:16:16 -0000 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by klesh.pair.com (Postfix) with ESMTP id 454F768374 for ; Tue, 15 Nov 2005 12:16:16 -0500 (EST) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 15 Nov 2005 09:16:15 -0800 Received: from [128.107.163.183] (dhcp-128-107-163-183.cisco.com [128.107.163.183]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAFHG9Iq018341; Tue, 15 Nov 2005 09:16:10 -0800 (PST) Message-ID: <437A17E1.2080402@cisco.com> Date: Tue, 15 Nov 2005 09:16:17 -0800 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [MSEC] Draft minutes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi George, [snip] > As a separate question, could someone please clarify for my benefit more > about what was said in the context of the meeting minutes about Issue 1 > where Russ is quoted as saying: > > "Russ: 2401bis gets through the entire architecture without touching > IKE. Why do you think you can't do the same thing." > > Would it be accurate to say that if the MSEC IPsec extensions document > defined a conceptual interface between the GKMP and the IPsec subsystem > (as discussed in Issue 4) then the document would suffiently independent > from the GKMP, and therefore the document would be following in the spirit > of RFC2401-bis? There was some discussion (Issue 4 on the slides) on what a conceptual interface might be, but there was no consensus on the topic during the meeting. Someone did point out that one attempt has been made to define the interface between IKE and IPsec, which is PF_KEY. Note that this has never been standardized. Also, because it was designed with a particular architecture in mind it is not universally useful to all IKE/IPsec implementations. I'm not sure a *conceptual interface* would be any more useful to IKE/IPsec than the PF_KEY. This indicates to me that such a conceptual GCKS/Ipsec interface wouldn't be any more useful to obtain interoperability. On the other hand, an particular implementation IKE/IPsec interface could benefit from a singular interface from key management systems to IPsec. For example, I've found the Linux 2.6 IKE/IPsec interface (PF_KEY + extensions) to be an adequate interface for my GDOI/IPsec implementation. Looking ahead, if the IPsec multicast extensions draft defines additional IPsec attributes, then the Linux 2.6 interface needs to be extended to pass those attributes. But however that particular interface gets extended should be sufficient for any GKMP running on that implementation. Thanks, Brian > hth, > George > > On Wed, 9 Nov 2005, Lakshminath Dondeti wrote: > > >>All, >> >>Thanks to Steffen Fries we have the following draft minutes. I >>edited them and so any mistakes are mine. Please take the time to >>review them. I would like to post these around noon tomorrow. If >>you need more time, please let me know. thanks. >> >>http://www.securemulticast.org/IETF-64/minutes.txt >> >>A couple (there are more; I will list them in the meeting summary) of >>action items from the meeting are as follows: >> >>1. Start a discussion on the scope of the IPsec extensions work; once >>that is done, Brian and his co-editors will prepare -01- of that >>document and we will circulate to the IPSEC list. (Brian to follow-up) >> >>2. Start a discussion on the MIKEY modes. (to follow-up) >> >>regards, >>Lakshminath >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://six.pairlist.net/mailman/listinfo/msec >> > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Nov 15 14:42:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6hi-0003Tn-J9 for msec-archive@megatron.ietf.org; Tue, 15 Nov 2005 14:42:54 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21721 for ; Tue, 15 Nov 2005 14:42:22 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3E0BA8C6B3; Tue, 15 Nov 2005 14:42:53 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 813D18C5A1 for ; Tue, 15 Nov 2005 14:42:51 -0500 (EST) Received: (qmail 34095 invoked by uid 3269); 15 Nov 2005 19:42:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34091 invoked from network); 15 Nov 2005 19:42:51 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Nov 2005 19:42:51 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 23AC26836F for ; Tue, 15 Nov 2005 14:42:51 -0500 (EST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAFJgkdE006470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Nov 2005 11:42:46 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAFJgh7K008826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Nov 2005 11:42:44 -0800 (PST) Message-Id: <6.2.5.6.2.20051115113230.03c5de30@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 15 Nov 2005 11:42:41 -0800 To: Brian Weis , George Gross From: Lakshminath Dondeti Subject: MSEC IPsec extensions scoping (Re: [MSEC] Draft minutes) In-Reply-To: <437A17E1.2080402@cisco.com> References: <437A17E1.2080402@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org *****Speaking strictly as a WG member At 09:16 AM 11/15/2005, Brian Weis wrote: >Hi George, > >[snip] > >>As a separate question, could someone please clarify for my benefit more >>about what was said in the context of the meeting minutes about Issue 1 >>where Russ is quoted as saying: >>"Russ: 2401bis gets through the entire architecture without touching >>IKE. Why do you think you can't do the same thing." >>Would it be accurate to say that if the MSEC IPsec extensions document >>defined a conceptual interface between the GKMP and the IPsec subsystem >>(as discussed in Issue 4) then the document would suffiently independent >>from the GKMP, and therefore the document would be following in the spirit >>of RFC2401-bis? > >There was some discussion (Issue 4 on the slides) on what a >conceptual interface might be, but there was no consensus on the >topic during the meeting. Someone did point out that one attempt has >been made to define the interface between IKE and IPsec, which is >PF_KEY. Note that this has never been standardized. Also, because it >was designed with a particular architecture in mind it is not >universally useful to all IKE/IPsec implementations. > >I'm not sure a *conceptual interface* would be any more useful to >IKE/IPsec than the PF_KEY. This indicates to me that such a >conceptual GCKS/Ipsec interface wouldn't be any more useful to >obtain interoperability. PF_KEY or any of its cousins are definitely out of scope for the MSEC IPsec extensions I think. Russ's general guidance has been to take a look at what IPsecbis covers and address those areas. If there is a case that group keying is different in this respect, I would like to see it. >On the other hand, an particular implementation IKE/IPsec interface >could benefit from a singular interface from key management systems >to IPsec. For example, I've found the Linux 2.6 IKE/IPsec interface >(PF_KEY + extensions) to be an adequate interface for my GDOI/IPsec >implementation. Looking ahead, if the IPsec multicast extensions >draft defines additional IPsec attributes, then the Linux 2.6 >interface needs to be extended to pass those attributes. But however >that particular interface gets extended should be sufficient for any >GKMP running on that implementation. What might be in scope is a discussion or a mapping of the various parameters that a group keying system might provide and how they map into the various databases described in 2401bis. An interface sounds somewhat rigid and it appears that is the problem with PF_KEY. Many implementers found (reported in MOBIKE, IPSEC and other WG discussions) that they eventually drifted toward their own extensions to the interface and found that a standards based solution is either limiting or unnecessary. I agree with that. The IETF has no control really on how people map the parameters from the key management subsystem to the data encapsulation subsytem. (Note that for instance, a number of implementations integrate the SPD into the firewall rules.) Lakshminath >Thanks, >Brian > >>hth, >> George >>On Wed, 9 Nov 2005, Lakshminath Dondeti wrote: >> >>>All, >>> >>>Thanks to Steffen Fries we have the following draft minutes. I >>>edited them and so any mistakes are mine. Please take the time to >>>review them. I would like to post these around noon tomorrow. If >>>you need more time, please let me know. thanks. >>> >>>http://www.securemulticast.org/IETF-64/minutes.txt >>> >>>A couple (there are more; I will list them in the meeting summary) of >>>action items from the meeting are as follows: >>> >>>1. Start a discussion on the scope of the IPsec extensions work; once >>>that is done, Brian and his co-editors will prepare -01- of that >>>document and we will circulate to the IPSEC list. (Brian to follow-up) >>> >>>2. Start a discussion on the MIKEY modes. (to follow-up) >>> >>>regards, >>>Lakshminath >>> >>>_______________________________________________ >>>msec mailing list >>>msec@securemulticast.org >>>http://six.pairlist.net/mailman/listinfo/msec >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://six.pairlist.net/mailman/listinfo/msec > > >-- >Brian Weis >Advanced Security Development, Security Technology Group, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Nov 15 17:59:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec9lg-000448-Qf for msec-archive@megatron.ietf.org; Tue, 15 Nov 2005 17:59:12 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03695 for ; Tue, 15 Nov 2005 17:58:38 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1E6778CD86; Tue, 15 Nov 2005 17:59:10 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 7F50A8CD16 for ; Tue, 15 Nov 2005 17:59:07 -0500 (EST) Received: (qmail 66897 invoked by uid 3269); 15 Nov 2005 22:59:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66894 invoked from network); 15 Nov 2005 22:59:07 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Nov 2005 22:59:07 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id 484B968371 for ; Tue, 15 Nov 2005 17:59:07 -0500 (EST) Received: (qmail 4872 invoked from network); 15 Nov 2005 22:59:06 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 15 Nov 2005 22:59:06 -0000 Received: (qmail 42946 invoked from network); 15 Nov 2005 17:59:05 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 15 Nov 2005 17:59:05 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id jAFMmjd26903; Tue, 15 Nov 2005 17:48:45 -0500 Date: Tue, 15 Nov 2005 17:48:45 -0500 (EST) From: George Gross To: Lakshminath Dondeti Subject: Re: MSEC IPsec extensions scoping (Re: [MSEC] Draft minutes) In-Reply-To: <6.2.5.6.2.20051115113230.03c5de30@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: canetti , Brian Weis , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi Lakshminath and Brian, inline.... On Tue, 15 Nov 2005, Lakshminath Dondeti wrote: > *****Speaking strictly as a WG member > > At 09:16 AM 11/15/2005, Brian Weis wrote: > >Hi George, > > > >[snip] > > > >>As a separate question, could someone please clarify for my benefit more > >>about what was said in the context of the meeting minutes about Issue 1 > >>where Russ is quoted as saying: > >>"Russ: 2401bis gets through the entire architecture without touching > >>IKE. Why do you think you can't do the same thing." > >>Would it be accurate to say that if the MSEC IPsec extensions document > >>defined a conceptual interface between the GKMP and the IPsec subsystem > >>(as discussed in Issue 4) then the document would suffiently independent > >>from the GKMP, and therefore the document would be following in the spirit > >>of RFC2401-bis? > > > >There was some discussion (Issue 4 on the slides) on what a > >conceptual interface might be, but there was no consensus on the > >topic during the meeting. Someone did point out that one attempt has > >been made to define the interface between IKE and IPsec, which is > >PF_KEY. Note that this has never been standardized. Also, because it > >was designed with a particular architecture in mind it is not > >universally useful to all IKE/IPsec implementations. I agree that PF_KEY is architecture specific. OTOH, the IETF has had a long history of publishing informational RFC wrt/ how an implementation could direct and manage a standards track RFC protocol. Examples that come to mind are the various socket interfaces to IPv6, LDAP, and MIP CoA management. So it is not unusual practice to complement the bits-on-the-wire protocol spec with an API spec that helps implementations make a common set of features and controls available to the programmer. That said, I'm not advocating that the MSEC IPsec extensions doc add that granularity of detail. What I do expect to identify in the document are those attributes that are the MSEC IPsec superset of those SPD/SAD/PAD attributes that one would exchange between a GKMP and an RFC2401-bis capable IPsec subsystem. see below for additional details... > > > >I'm not sure a *conceptual interface* would be any more useful to > >IKE/IPsec than the PF_KEY. This indicates to me that such a > >conceptual GCKS/Ipsec interface wouldn't be any more useful to > >obtain interoperability. > > PF_KEY or any of its cousins are definitely out of scope for the MSEC > IPsec extensions I think. Russ's general guidance has been to take a > look at what IPsecbis covers and address those areas. If there is a > case that group keying is different in this respect, I would like to see it. > > > >On the other hand, an particular implementation IKE/IPsec interface > >could benefit from a singular interface from key management systems > >to IPsec. For example, I've found the Linux 2.6 IKE/IPsec interface > >(PF_KEY + extensions) to be an adequate interface for my GDOI/IPsec > >implementation. Looking ahead, if the IPsec multicast extensions > >draft defines additional IPsec attributes, then the Linux 2.6 > >interface needs to be extended to pass those attributes. But however > >that particular interface gets extended should be sufficient for any > >GKMP running on that implementation. > > What might be in scope is a discussion or a mapping of the various > parameters that a group keying system might provide and how they map > into the various databases described in 2401bis. An interface sounds > somewhat rigid and it appears that is the problem with PF_KEY. Many > implementers found (reported in MOBIKE, IPSEC and other WG > discussions) that they eventually drifted toward their own extensions > to the interface and found that a standards based solution is either > limiting or unnecessary. I agree with that. Yes, this aligns with what I had in mind. Unfortunately, everyone can take the term "conceptual interface" and run with it in many directions, including PF_KEY. The PF_KEY interface is not what I had in mind. I simply want a line drawn in the architecture diagram, and a statement of what MSEC IPsec and GKMP do that is special at that boundary. Examples of the parameters that I'd like to see identified as being passed from GKMP into the MSEC IPsec subsystem: o SA sequence number for a Group Member joining a group data SA that is in progress o Signature public key of a Group Speaker used to validate source authenticated ESP o The ability to manage the timing of multiple concurrent data SA traffic flows, with the goal of assuring application data flow continuity across group rekey events (i.e. drain an old data SA's transmissions while the group is installing a new data SA and then transitioning to that new data SA). o PAD group membership and GCKS authorization configuration data o SA synchronization state for counter-oriented encryption algorithms. o Ability to revise a SPD traffic selector's SSM source address to track a change incurred by NAT. o Allow Group Receivers to configure their SPD/SAD to permit unicast error repair requests directed at the Group Speaker (i.e. when using NORM). In other words, allow multicast in one direction, unicast in the other... There may be other attributes needed in the so called "conceptual interface" that will emerge as we go further into describing MSEC IPsec, the above items are the ones that I thought of at this moment... hth, George > > The IETF has no control really on how people map the parameters from > the key management subsystem to the data encapsulation > subsytem. (Note that for instance, a number of implementations > integrate the SPD into the firewall rules.) agreed. br, George > > Lakshminath > > > >Thanks, > >Brian > > > >>hth, > >> George > >>On Wed, 9 Nov 2005, Lakshminath Dondeti wrote: > >> > >>>All, > >>> > >>>Thanks to Steffen Fries we have the following draft minutes. I > >>>edited them and so any mistakes are mine. Please take the time to > >>>review them. I would like to post these around noon tomorrow. If > >>>you need more time, please let me know. thanks. > >>> > >>>http://www.securemulticast.org/IETF-64/minutes.txt > >>> > >>>A couple (there are more; I will list them in the meeting summary) of > >>>action items from the meeting are as follows: > >>> > >>>1. Start a discussion on the scope of the IPsec extensions work; once > >>>that is done, Brian and his co-editors will prepare -01- of that > >>>document and we will circulate to the IPSEC list. (Brian to follow-up) > >>> > >>>2. Start a discussion on the MIKEY modes. (to follow-up) > >>> > >>>regards, > >>>Lakshminath > >>> > >>>_______________________________________________ > >>>msec mailing list > >>>msec@securemulticast.org > >>>http://six.pairlist.net/mailman/listinfo/msec > >> > >>_______________________________________________ > >>msec mailing list > >>msec@securemulticast.org > >>http://six.pairlist.net/mailman/listinfo/msec > > > > > >-- > >Brian Weis > >Advanced Security Development, Security Technology Group, Cisco Systems > >Telephone: +1 408 526 4796 > >Email: bew@cisco.com > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Nov 16 20:39:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcYkn-00038H-Ev for msec-archive@megatron.ietf.org; Wed, 16 Nov 2005 20:39:57 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13935 for ; Wed, 16 Nov 2005 20:39:22 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 557308CB38; Wed, 16 Nov 2005 20:39:56 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 5A2DE8CB18 for ; Wed, 16 Nov 2005 20:39:55 -0500 (EST) Received: (qmail 97727 invoked by uid 3269); 17 Nov 2005 01:39:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97724 invoked from network); 17 Nov 2005 01:39:55 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 17 Nov 2005 01:39:55 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 0BD1E6836F for ; Wed, 16 Nov 2005 20:39:54 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAH1dqxe026795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Nov 2005 17:39:52 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jAH1doEu018875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Nov 2005 17:39:50 -0800 (PST) Message-Id: <6.2.5.6.2.20051116172427.03c8c468@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 16 Nov 2005 17:39:50 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti Subject: [MSEC] SHA-1 replacement analyses for MSEC protocols X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org At the SAAG meeting, Russ directed all SEC area WGs to analyze the protocols they are working (worked) on and plan for SHA-1 replacement. Here are the directives (1) and (2): "1.Do the Bellovin-Rescorla analysis before IETF 65 for each protocol in the WG" "2.Start standards work for transition to SHA-256, but remember another transition is coming, so plan for it" MSEC has the following documents/protocols to analyze: GSAKMP GDOI MSEC-signatures MIKEY related TESLA Did I miss any? Our first request to everyone is to read the Belloving-Rescorla paper (the relevant NIST and SAAG presentations materials should help as well). Feel free to discuss the analysis method and your review of that paper with other MSEC contributors. References: http://www.cs.columbia.edu/~smb/papers/new-hash.pdf http://www.csrc.nist.gov/pki/HashWorkshop/2005/Oct31_Presentations/Bellovin_new-hash.pdf https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 (search for SAAG meeting materials) Next, if you are interested in analyzing any of the MSEC documents or protocols, please contact Ran and me. Some of you have already done so; thanks. We need to start work on this ASAP as we need to finish this work before the March IETF meeting, **February 27, 2006 would be the -00- deadline We'll post the protocol analysis assignments :-) toward the end of next week. (Please hurry and volunteer). thanks and regards, Lakshminath for Ran & Lakshminath PS: Current document authors MUST do the analysis as part of their next document revision. Thanks. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 17 17:09:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecrx4-0007g3-HR for msec-archive@megatron.ietf.org; Thu, 17 Nov 2005 17:09:54 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29476 for ; Thu, 17 Nov 2005 17:09:20 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 508278C2BF; Thu, 17 Nov 2005 17:09:53 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 087FD8C1B4 for ; Thu, 17 Nov 2005 17:09:52 -0500 (EST) Received: (qmail 49685 invoked by uid 3269); 17 Nov 2005 22:09:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49682 invoked from network); 17 Nov 2005 22:09:52 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 17 Nov 2005 22:09:52 -0000 Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by klesh.pair.com (Postfix) with SMTP id CE0CC68374 for ; Thu, 17 Nov 2005 17:09:51 -0500 (EST) Received: from nc4010.htt-consult.com ([65.84.78.209]) by htt-consult.com ; Thu, 17 Nov 2005 17:10:46 -0500 Message-Id: <6.2.3.4.2.20051117130449.02960118@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 17 Nov 2005 13:08:44 -0800 To: Lakshminath Dondeti , msec@securemulticast.org From: Robert Moskowitz Subject: Re: [MSEC] SHA-1 replacement analyses for MSEC protocols In-Reply-To: <6.2.5.6.2.20051116172427.03c8c468@qualcomm.com> References: <6.2.5.6.2.20051116172427.03c8c468@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: Cc: canetti X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org At 05:39 PM 11/16/2005, Lakshminath Dondeti wrote: >At the SAAG meeting, Russ directed all SEC area WGs to analyze the >protocols they are working (worked) on and plan for SHA-1 >replacement. Here are the directives (1) and (2): I would also like to point out NSA's 'Suite B' algorithms that will have a large impact on Diffie-Hellman based key exchanges. Actually, it has a big impact on ANY key exchange; at least based on analyses that I have seen. Vendors may find themselves doing one set of suites for govs, and another for commerce unless they either license some ECC patents, or we get further clearification on NSA's purchase of rights to said patents. Robert Moskowitz ICSAlabs/A Division of TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 17 19:56:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcuYh-0002Ec-Ak for msec-archive@megatron.ietf.org; Thu, 17 Nov 2005 19:56:55 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09310 for ; Thu, 17 Nov 2005 19:56:20 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2DCAA8C026; Thu, 17 Nov 2005 19:56:54 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 726F18C6F4 for ; Thu, 17 Nov 2005 19:56:52 -0500 (EST) Received: (qmail 85361 invoked by uid 3269); 18 Nov 2005 00:56:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85358 invoked from network); 18 Nov 2005 00:56:52 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 18 Nov 2005 00:56:52 -0000 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by klesh.pair.com (Postfix) with ESMTP id C777E6836F for ; Thu, 17 Nov 2005 19:56:51 -0500 (EST) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2005 16:56:50 -0800 Received: from [128.107.163.66] (dhcp-128-107-163-66.cisco.com [128.107.163.66]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAI0ul6a015829; Thu, 17 Nov 2005 16:56:48 -0800 (PST) Message-ID: <437D26D4.7010005@cisco.com> Date: Thu, 17 Nov 2005 16:56:52 -0800 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: MSEC IPsec extensions scoping (Re: [MSEC] Draft minutes) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Hi George, George Gross wrote: > Hi Lakshminath and Brian, > > inline.... > > On Tue, 15 Nov 2005, Lakshminath Dondeti wrote: > > >>*****Speaking strictly as a WG member >> >>At 09:16 AM 11/15/2005, Brian Weis wrote: >> >>>Hi George, >>> >>>[snip] >>> >>> >>>>As a separate question, could someone please clarify for my benefit more >>>>about what was said in the context of the meeting minutes about Issue 1 >>>>where Russ is quoted as saying: >>>>"Russ: 2401bis gets through the entire architecture without touching >>>>IKE. Why do you think you can't do the same thing." >>>>Would it be accurate to say that if the MSEC IPsec extensions document >>>>defined a conceptual interface between the GKMP and the IPsec subsystem >>>>(as discussed in Issue 4) then the document would suffiently independent >>> >>>>from the GKMP, and therefore the document would be following in the spirit >>> >>>>of RFC2401-bis? >>> >>>There was some discussion (Issue 4 on the slides) on what a >>>conceptual interface might be, but there was no consensus on the >>>topic during the meeting. Someone did point out that one attempt has >>>been made to define the interface between IKE and IPsec, which is >>>PF_KEY. Note that this has never been standardized. Also, because it >>>was designed with a particular architecture in mind it is not >>>universally useful to all IKE/IPsec implementations. > > > I agree that PF_KEY is architecture specific. OTOH, the IETF has had a > long history of publishing informational RFC wrt/ how an implementation > could direct and manage a standards track RFC protocol. Examples that come > to mind are the various socket interfaces to IPv6, LDAP, and MIP CoA > management. So it is not unusual practice to complement the > bits-on-the-wire protocol spec with an API spec that helps implementations > make a common set of features and controls available to the programmer. > > That said, I'm not advocating that the MSEC IPsec extensions doc add that > granularity of detail. What I do expect to identify in the document are > those attributes that are the MSEC IPsec superset of those SPD/SAD/PAD > attributes that one would exchange between a GKMP and an RFC2401-bis > capable IPsec subsystem. I definitely agree that additional attributes (along the lines or your examples below) will need to be defined for IPsec group SAs. I don't think the MSEC IPsec extensions doc can do much more than identify the attributes though -- each GKMP & IPsec implementation will need to decide how to represent them in their own namespaces. Thanks, Brian > see below for additional details... > > >>>I'm not sure a *conceptual interface* would be any more useful to >>>IKE/IPsec than the PF_KEY. This indicates to me that such a >>>conceptual GCKS/Ipsec interface wouldn't be any more useful to >>>obtain interoperability. >> >>PF_KEY or any of its cousins are definitely out of scope for the MSEC >>IPsec extensions I think. Russ's general guidance has been to take a >>look at what IPsecbis covers and address those areas. If there is a >>case that group keying is different in this respect, I would like to see it. >> >> >> >>>On the other hand, an particular implementation IKE/IPsec interface >>>could benefit from a singular interface from key management systems >>>to IPsec. For example, I've found the Linux 2.6 IKE/IPsec interface >>>(PF_KEY + extensions) to be an adequate interface for my GDOI/IPsec >>>implementation. Looking ahead, if the IPsec multicast extensions >>>draft defines additional IPsec attributes, then the Linux 2.6 >>>interface needs to be extended to pass those attributes. But however >>>that particular interface gets extended should be sufficient for any >>>GKMP running on that implementation. >> >>What might be in scope is a discussion or a mapping of the various >>parameters that a group keying system might provide and how they map >>into the various databases described in 2401bis. An interface sounds >>somewhat rigid and it appears that is the problem with PF_KEY. Many >>implementers found (reported in MOBIKE, IPSEC and other WG >>discussions) that they eventually drifted toward their own extensions >>to the interface and found that a standards based solution is either >>limiting or unnecessary. I agree with that. > > > Yes, this aligns with what I had in mind. Unfortunately, everyone can take > the term "conceptual interface" and run with it in many directions, > including PF_KEY. The PF_KEY interface is not what I had in mind. I simply > want a line drawn in the architecture diagram, and a statement of what > MSEC IPsec and GKMP do that is special at that boundary. > > Examples of the parameters that I'd like to see identified as being passed > from GKMP into the MSEC IPsec subsystem: > > o SA sequence number for a Group Member joining a group data SA that is in > progress > > o Signature public key of a Group Speaker used to validate source > authenticated ESP > > o The ability to manage the timing of multiple concurrent data SA traffic > flows, with the goal of assuring application data flow continuity across > group rekey events (i.e. drain an old data SA's transmissions while the > group is installing a new data SA and then transitioning to that new data > SA). > > o PAD group membership and GCKS authorization configuration data > > o SA synchronization state for counter-oriented encryption algorithms. > > o Ability to revise a SPD traffic selector's SSM source address to track a > change incurred by NAT. > > o Allow Group Receivers to configure their SPD/SAD to permit unicast error > repair requests directed at the Group Speaker (i.e. when using NORM). In > other words, allow multicast in one direction, unicast in the other... > > There may be other attributes needed in the so called "conceptual > interface" that will emerge as we go further into describing MSEC IPsec, > the above items are the ones that I thought of at this moment... > > hth, > George > >>The IETF has no control really on how people map the parameters from >>the key management subsystem to the data encapsulation >>subsytem. (Note that for instance, a number of implementations >>integrate the SPD into the firewall rules.) > > > agreed. > > br, > George > > >>Lakshminath >> >> >> >>>Thanks, >>>Brian >>> >>> >>>>hth, >>>> George >>>>On Wed, 9 Nov 2005, Lakshminath Dondeti wrote: >>>> >>>> >>>>>All, >>>>> >>>>>Thanks to Steffen Fries we have the following draft minutes. I >>>>>edited them and so any mistakes are mine. Please take the time to >>>>>review them. I would like to post these around noon tomorrow. If >>>>>you need more time, please let me know. thanks. >>>>> >>>>>http://www.securemulticast.org/IETF-64/minutes.txt >>>>> >>>>>A couple (there are more; I will list them in the meeting summary) of >>>>>action items from the meeting are as follows: >>>>> >>>>>1. Start a discussion on the scope of the IPsec extensions work; once >>>>>that is done, Brian and his co-editors will prepare -01- of that >>>>>document and we will circulate to the IPSEC list. (Brian to follow-up) >>>>> >>>>>2. Start a discussion on the MIKEY modes. (to follow-up) >>>>> >>>>>regards, >>>>>Lakshminath >>>>> >>>>>_______________________________________________ >>>>>msec mailing list >>>>>msec@securemulticast.org >>>>>http://six.pairlist.net/mailman/listinfo/msec >>>> >>>>_______________________________________________ >>>>msec mailing list >>>>msec@securemulticast.org >>>>http://six.pairlist.net/mailman/listinfo/msec >>> >>> >>>-- >>>Brian Weis >>>Advanced Security Development, Security Technology Group, Cisco Systems >>>Telephone: +1 408 526 4796 >>>Email: bew@cisco.com >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://six.pairlist.net/mailman/listinfo/msec >> > > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 17 21:15:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecvn7-0008Nf-Rf for msec-archive@megatron.ietf.org; Thu, 17 Nov 2005 21:15:54 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12661 for ; Thu, 17 Nov 2005 21:15:18 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3D2458CC77; Thu, 17 Nov 2005 21:15:52 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 29F328CC32 for ; Thu, 17 Nov 2005 21:15:51 -0500 (EST) Received: (qmail 2397 invoked by uid 3269); 18 Nov 2005 02:15:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 2394 invoked from network); 18 Nov 2005 02:15:51 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 18 Nov 2005 02:15:51 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id 2108D68374 for ; Thu, 17 Nov 2005 21:15:51 -0500 (EST) Received: (qmail 33462 invoked from network); 18 Nov 2005 02:15:50 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 18 Nov 2005 02:15:50 -0000 Received: (qmail 22629 invoked from network); 17 Nov 2005 21:15:50 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 17 Nov 2005 21:15:50 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id jAI258931538; Thu, 17 Nov 2005 21:05:08 -0500 Date: Thu, 17 Nov 2005 21:05:07 -0500 (EST) From: George Gross To: Robert Moskowitz Subject: Re: [MSEC] SHA-1 replacement analyses for MSEC protocols In-Reply-To: <6.2.3.4.2.20051117130449.02960118@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi Bob, On Thu, 17 Nov 2005, Robert Moskowitz wrote: > At 05:39 PM 11/16/2005, Lakshminath Dondeti wrote: > >At the SAAG meeting, Russ directed all SEC area WGs to analyze the > >protocols they are working (worked) on and plan for SHA-1 > >replacement. Here are the directives (1) and (2): > > I would also like to point out NSA's 'Suite B' algorithms that will > have a large impact on Diffie-Hellman based key exchanges. I infer that these are ECC-based DH algorithms? do you have a web pointer to a reference for "Suite B" in the public domain? > Actually, it has a big impact on ANY key exchange; at least based on > analyses that I have seen. So far, the IETF focus has been on MD5 and SHA1 replacement. Is it your contention that the scope should be widened to replace classic Diffie-Hellman key agreement in IETF standards? Doing a migration to DH++, if needed, could be piggybacked onto the SHA1->SHA-256 and 3DES->AES migrations. But if we're serious about that, then it needs to get worked in parallel in IPsec working group, not just here in MSEC... i.e. the larger IETF community would need to buy in. local to MSEC, AFAIK all of the current standards track protocols use Diffie-Hellman in their registration SA phase... > > Vendors may find themselves doing one set of suites for govs, and > another for commerce unless they either license some ECC patents, or > we get further clearification on NSA's purchase of rights to said patents. yuck. sounds like we're overdue for a crypto suite that eclipses classic DH yet does not have IPR encumberances ;o( are there any such alternatives? br, George > > > > Robert Moskowitz > ICSAlabs/A Division of TruSecure Corporation > Security Interest EMail: rgm-sec@htt-consult.com > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Nov 17 21:22:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecvtf-0001tf-2n for msec-archive@megatron.ietf.org; Thu, 17 Nov 2005 21:22:39 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13150 for ; Thu, 17 Nov 2005 21:22:03 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id EDAD78C922; Thu, 17 Nov 2005 21:22:37 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id C9DA28C083 for ; Thu, 17 Nov 2005 21:22:36 -0500 (EST) Received: (qmail 3678 invoked by uid 3269); 18 Nov 2005 02:22:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3675 invoked from network); 18 Nov 2005 02:22:36 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 18 Nov 2005 02:22:36 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id 1863168371 for ; Thu, 17 Nov 2005 21:22:36 -0500 (EST) Received: (qmail 34798 invoked from network); 18 Nov 2005 02:22:35 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 18 Nov 2005 02:22:35 -0000 Received: (qmail 25452 invoked from network); 17 Nov 2005 21:22:34 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 17 Nov 2005 21:22:34 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id jAI2BrK31565; Thu, 17 Nov 2005 21:11:53 -0500 Date: Thu, 17 Nov 2005 21:11:53 -0500 (EST) From: George Gross To: Brian Weis Subject: Re: MSEC IPsec extensions scoping (Re: [MSEC] Draft minutes) In-Reply-To: <437D26D4.7010005@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi Brian, okay, we seem to be on the same wavelength about this issue. I'd like to suggest that we work out offlist (with Dragan too) the details about how to insert these additions to the MSEC IPsec extensions v01. perhaps we should turn our attention to one of the other issues raised at Vancouver? perhaps composite groups in support of crypto algorithm migration? ;o) br, George On Thu, 17 Nov 2005, Brian Weis wrote: > Hi George, > > George Gross wrote: > > Hi Lakshminath and Brian, > > > > inline.... > > > > On Tue, 15 Nov 2005, Lakshminath Dondeti wrote: > > > > > >>*****Speaking strictly as a WG member > >> > >>At 09:16 AM 11/15/2005, Brian Weis wrote: > >> > >>>Hi George, > >>> > >>>[snip] > >>> > >>> > >>>>As a separate question, could someone please clarify for my benefit more > >>>>about what was said in the context of the meeting minutes about Issue 1 > >>>>where Russ is quoted as saying: > >>>>"Russ: 2401bis gets through the entire architecture without touching > >>>>IKE. Why do you think you can't do the same thing." > >>>>Would it be accurate to say that if the MSEC IPsec extensions document > >>>>defined a conceptual interface between the GKMP and the IPsec subsystem > >>>>(as discussed in Issue 4) then the document would suffiently independent > >>> > >>>>from the GKMP, and therefore the document would be following in the spirit > >>> > >>>>of RFC2401-bis? > >>> > >>>There was some discussion (Issue 4 on the slides) on what a > >>>conceptual interface might be, but there was no consensus on the > >>>topic during the meeting. Someone did point out that one attempt has > >>>been made to define the interface between IKE and IPsec, which is > >>>PF_KEY. Note that this has never been standardized. Also, because it > >>>was designed with a particular architecture in mind it is not > >>>universally useful to all IKE/IPsec implementations. > > > > > > I agree that PF_KEY is architecture specific. OTOH, the IETF has had a > > long history of publishing informational RFC wrt/ how an implementation > > could direct and manage a standards track RFC protocol. Examples that come > > to mind are the various socket interfaces to IPv6, LDAP, and MIP CoA > > management. So it is not unusual practice to complement the > > bits-on-the-wire protocol spec with an API spec that helps implementations > > make a common set of features and controls available to the programmer. > > > > That said, I'm not advocating that the MSEC IPsec extensions doc add that > > granularity of detail. What I do expect to identify in the document are > > those attributes that are the MSEC IPsec superset of those SPD/SAD/PAD > > attributes that one would exchange between a GKMP and an RFC2401-bis > > capable IPsec subsystem. > > I definitely agree that additional attributes (along the lines or your > examples below) will need to be defined for IPsec group SAs. I don't > think the MSEC IPsec extensions doc can do much more than identify the > attributes though -- each GKMP & IPsec implementation will need to > decide how to represent them in their own namespaces. > > Thanks, > Brian > > > see below for additional details... > > > > > >>>I'm not sure a *conceptual interface* would be any more useful to > >>>IKE/IPsec than the PF_KEY. This indicates to me that such a > >>>conceptual GCKS/Ipsec interface wouldn't be any more useful to > >>>obtain interoperability. > >> > >>PF_KEY or any of its cousins are definitely out of scope for the MSEC > >>IPsec extensions I think. Russ's general guidance has been to take a > >>look at what IPsecbis covers and address those areas. If there is a > >>case that group keying is different in this respect, I would like to see it. > >> > >> > >> > >>>On the other hand, an particular implementation IKE/IPsec interface > >>>could benefit from a singular interface from key management systems > >>>to IPsec. For example, I've found the Linux 2.6 IKE/IPsec interface > >>>(PF_KEY + extensions) to be an adequate interface for my GDOI/IPsec > >>>implementation. Looking ahead, if the IPsec multicast extensions > >>>draft defines additional IPsec attributes, then the Linux 2.6 > >>>interface needs to be extended to pass those attributes. But however > >>>that particular interface gets extended should be sufficient for any > >>>GKMP running on that implementation. > >> > >>What might be in scope is a discussion or a mapping of the various > >>parameters that a group keying system might provide and how they map > >>into the various databases described in 2401bis. An interface sounds > >>somewhat rigid and it appears that is the problem with PF_KEY. Many > >>implementers found (reported in MOBIKE, IPSEC and other WG > >>discussions) that they eventually drifted toward their own extensions > >>to the interface and found that a standards based solution is either > >>limiting or unnecessary. I agree with that. > > > > > > Yes, this aligns with what I had in mind. Unfortunately, everyone can take > > the term "conceptual interface" and run with it in many directions, > > including PF_KEY. The PF_KEY interface is not what I had in mind. I simply > > want a line drawn in the architecture diagram, and a statement of what > > MSEC IPsec and GKMP do that is special at that boundary. > > > > Examples of the parameters that I'd like to see identified as being passed > > from GKMP into the MSEC IPsec subsystem: > > > > o SA sequence number for a Group Member joining a group data SA that is in > > progress > > > > o Signature public key of a Group Speaker used to validate source > > authenticated ESP > > > > o The ability to manage the timing of multiple concurrent data SA traffic > > flows, with the goal of assuring application data flow continuity across > > group rekey events (i.e. drain an old data SA's transmissions while the > > group is installing a new data SA and then transitioning to that new data > > SA). > > > > o PAD group membership and GCKS authorization configuration data > > > > o SA synchronization state for counter-oriented encryption algorithms. > > > > o Ability to revise a SPD traffic selector's SSM source address to track a > > change incurred by NAT. > > > > o Allow Group Receivers to configure their SPD/SAD to permit unicast error > > repair requests directed at the Group Speaker (i.e. when using NORM). In > > other words, allow multicast in one direction, unicast in the other... > > > > There may be other attributes needed in the so called "conceptual > > interface" that will emerge as we go further into describing MSEC IPsec, > > the above items are the ones that I thought of at this moment... > > > > hth, > > George > > > >>The IETF has no control really on how people map the parameters from > >>the key management subsystem to the data encapsulation > >>subsytem. (Note that for instance, a number of implementations > >>integrate the SPD into the firewall rules.) > > > > > > agreed. > > > > br, > > George > > > > > >>Lakshminath > >> > >> > >> > >>>Thanks, > >>>Brian > >>> > >>> > >>>>hth, > >>>> George > >>>>On Wed, 9 Nov 2005, Lakshminath Dondeti wrote: > >>>> > >>>> > >>>>>All, > >>>>> > >>>>>Thanks to Steffen Fries we have the following draft minutes. I > >>>>>edited them and so any mistakes are mine. Please take the time to > >>>>>review them. I would like to post these around noon tomorrow. If > >>>>>you need more time, please let me know. thanks. > >>>>> > >>>>>http://www.securemulticast.org/IETF-64/minutes.txt > >>>>> > >>>>>A couple (there are more; I will list them in the meeting summary) of > >>>>>action items from the meeting are as follows: > >>>>> > >>>>>1. Start a discussion on the scope of the IPsec extensions work; once > >>>>>that is done, Brian and his co-editors will prepare -01- of that > >>>>>document and we will circulate to the IPSEC list. (Brian to follow-up) > >>>>> > >>>>>2. Start a discussion on the MIKEY modes. (to follow-up) > >>>>> > >>>>>regards, > >>>>>Lakshminath > >>>>> > >>>>>_______________________________________________ > >>>>>msec mailing list > >>>>>msec@securemulticast.org > >>>>>http://six.pairlist.net/mailman/listinfo/msec > >>>> > >>>>_______________________________________________ > >>>>msec mailing list > >>>>msec@securemulticast.org > >>>>http://six.pairlist.net/mailman/listinfo/msec > >>> > >>> > >>>-- > >>>Brian Weis > >>>Advanced Security Development, Security Technology Group, Cisco Systems > >>>Telephone: +1 408 526 4796 > >>>Email: bew@cisco.com > >> > >>_______________________________________________ > >>msec mailing list > >>msec@securemulticast.org > >>http://six.pairlist.net/mailman/listinfo/msec > >> > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 18 02:31:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed0ig-0005wD-R2 for msec-archive@megatron.ietf.org; Fri, 18 Nov 2005 02:31:38 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27962 for ; Fri, 18 Nov 2005 02:31:03 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 36A9C8CAD7; Fri, 18 Nov 2005 02:31:35 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 3B9828CA3E for ; Fri, 18 Nov 2005 02:31:34 -0500 (EST) Received: (qmail 95501 invoked by uid 3269); 18 Nov 2005 07:31:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95498 invoked from network); 18 Nov 2005 07:31:34 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 18 Nov 2005 07:31:34 -0000 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by klesh.pair.com (Postfix) with ESMTP id ED98D68377 for ; Fri, 18 Nov 2005 02:31:33 -0500 (EST) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2005 23:31:33 -0800 X-IronPort-AV: i="3.97,345,1125903600"; d="scan'208"; a="231979719:sNHT24375032" Received: from [192.168.123.196] (sjc-vpn2-911.cisco.com [10.21.115.143]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jAI7VUOp009728 for ; Thu, 17 Nov 2005 23:31:31 -0800 (PST) Message-ID: <437D8358.2010304@cisco.com> Date: Thu, 17 Nov 2005 23:31:36 -0800 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] IPsec multicast extensions issues -- consensus needed! X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit This message follows up the IPsec multicast extensions draft discussion at the IETF 64 MSEC meeting: http://www.securemulticast.org/IETF-64/IETF64_IPsec_multicast_ext.pdf Four scope issues were identified at that meeting. They are reproduced here with the summary of the discussion at the meeting. Issue 1: Goal of this document. The root question is how far into key management should an IPsec multicast extensions architecture document have? The guidance given was that the document should discuss key management no more than rfc2401bis discusses IKEv2. Issue 2: GCKS deployments. Should the document mandate multiple GCKS device be defined in this architecture? The guidance given was that this should be in a separate document. Also, the guidance from Issue 1 implies that this would not be in scope. Issue 3: Composite cryptographic groups The root question here is whether or not IPsec systems conforming with the IPsec multicast extensions should be required to replicate a packet if two sets of policy matched that packet. Examples of when it may be advantageous for two sets of policy to match a single packet would be: a) During a policy upgrade of group members where different group members might have old or new policy. b) If two heterogeneous sets of clients are part of the same group, each of which requires a different set of policy. No guidance was given during the IETF 64 meeting, so a discussion is required on this in order to get consensus. Rather than try to discuss the pros and cons here, I will express one point of view in a separate email, and expect that George Gross will express an alternate viewpoint. Issue 4: GKMS/IPsec interface There was a question as to what the Group Key Management System interface to IPsec should be, and how much this document should cover. I believe we achieved consensus in a recent email thread that the interface should be to define a set of new IPsec attributes with which GKMS' and IPsec systems need to be concerned. It would be helpful to hear additional views on the mailing list to ensure we reach a consensus on these issues. Thanks, Brian -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Nov 18 02:34:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed0l7-0007EV-KM for msec-archive@megatron.ietf.org; Fri, 18 Nov 2005 02:34:09 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28074 for ; Fri, 18 Nov 2005 02:33:34 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 84E918CA5E; Fri, 18 Nov 2005 02:34:08 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B31138CA70 for ; Fri, 18 Nov 2005 02:34:07 -0500 (EST) Received: (qmail 95923 invoked by uid 3269); 18 Nov 2005 07:34:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95920 invoked from network); 18 Nov 2005 07:34:07 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 18 Nov 2005 07:34:07 -0000 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by klesh.pair.com (Postfix) with ESMTP id 6C9696836F for ; Fri, 18 Nov 2005 02:34:07 -0500 (EST) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2005 23:34:07 -0800 Received: from [192.168.123.196] (sjc-vpn2-911.cisco.com [10.21.115.143]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAI7Y46a019029 for ; Thu, 17 Nov 2005 23:34:05 -0800 (PST) Message-ID: <437D83F1.9050506@cisco.com> Date: Thu, 17 Nov 2005 23:34:09 -0800 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Comments on Issue 3: Composite cryptographic groups X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit This email contains one viewpoint regarding Issue 3, which is wrestling with the idea of a single IPsec context having to possibly match a single multicast packet against multiple policies. [Note: the term "IPsec contexts" comes from Section 4 of rfc2401bis.] While it is a noble goal to ensure that all Ipsec systems to have this capability, I fear that it is an unreasonable goal from the standpoint of some Ipsec systems. Here are some reasons why. This change requires *all* systems creating IPsec packets to implement at least two new processing steps. a. This proposed semantics requires the IPsec context to match a multicast packet against multiple IPsec policies. In the unicast case, a single SPD lookup always results in matching a single IPsec SA. b. The proposed semantics require an IPsec context to replicate packets (once for each matched policy). This is a completely new and disruptive processing step in the encapsulating an IPsec packet! In my estimation, this new semantic is disruptive to IPsec encapsulation processing in either a UNIX or UNIX-like system (acting as a sender, receiving a packet from a socket) or an IPsec gateway (relaying a multicast packet). An alternative to requiring a single IPsec context to replicate packets would be to apply multicast packet replication where it usually happens -- as a result of multicast routing. Doing so does imply that there exists a different IPsec context for each policy. This is possible in an IPsec gateway with multiple interfaces, or perhaps in a host with a complex internal architecture. However, a simple host with a single IPsec context could not support encrypting to multiple groups -- it would be necessary for the sending host to deliver the packet to a LAN containing multiple IPsec contexts, one for each group. However, this avoids costly new semantics in the IPsec context itself. Thanks, Brian -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Nov 21 18:59:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeLZ6-0005gq-CZ for msec-archive@megatron.ietf.org; Mon, 21 Nov 2005 18:59:16 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01466 for ; Mon, 21 Nov 2005 18:58:36 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7D01E8CADC; Mon, 21 Nov 2005 18:59:10 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id BA12F8C9CD for ; Mon, 21 Nov 2005 18:59:09 -0500 (EST) Received: (qmail 17800 invoked by uid 3269); 21 Nov 2005 23:59:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17797 invoked from network); 21 Nov 2005 23:59:09 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 21 Nov 2005 23:59:09 -0000 Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by klesh.pair.com (Postfix) with SMTP id 985796836F for ; Mon, 21 Nov 2005 18:59:09 -0500 (EST) Received: (qmail 91448 invoked from network); 21 Nov 2005 18:59:08 -0500 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 21 Nov 2005 18:59:08 -0500 Received: (qmail 34675 invoked from network); 21 Nov 2005 18:59:07 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 21 Nov 2005 18:59:07 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id jALNlmn10938; Mon, 21 Nov 2005 18:47:48 -0500 Date: Mon, 21 Nov 2005 18:47:48 -0500 (EST) From: George Gross To: Brian Weis Subject: Re: [MSEC] Comments on Issue 3: Composite cryptographic groups In-Reply-To: <437D83F1.9050506@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi Brian, I set aside my first attempt at responding to your e-mail, as that response delved into too much detail arguing about the technical feasibility of implementing composite groups. I decided that was not germane to our discussion. Each platform will have its own set of IP stack level tools and facilities that could be a springboard for adding an IPsec composite group capability. Given it is only software R&D, I don't think that arguing feasibility is the primary issue that we face here.... As standards authors, I am pretty sure that we agree that our responsibility is simply to outline those elements of an IPsec subsystem that assure inter-op across the whole MSEC IPsec extensions lifecycle. I remain convinced that the cryptographic algorithm migration problem is a genuine deterrent to deploying MSEC IPsec extensions unless we can state the conformance guidance that assures multiple vendors can cooperate to make a composite group work. This implies both IPsec gateway and host OS vendors all must clear the same hurdle. Our job is to identify the admin knobs and GKMP related controls that make that happen, not to argue the subjective complexity of introducing the composite group feature in a hypothetical IPsec subsystem's implementation. I should mention in passing that having a single packet match multiple SPD policies is not without precedent. It is described in RFC2401 as the "nested SA bundles" capability used to do ESP plus AH on a single packet. As you know, RFC2401-bis no longer mandates this capability, but it does acknowledge this capability is a valid IPsec implementation option. That said, I would like to float an idea that might finesse your misgivings about making a single packet match multiple SPD policies. Perhaps we could agree that MSEC IPsec subsystems operating in transport mode must be capable of being configured/controlled to doing the following: 1) assign a distinct destination IP multicast address to each sub-group within the composite group, along with a corresponding SPD/SAD entry that applies the respective sub-group's security policy. The SPD entry would match the sub-group's destination address, not the composite group's destination IP address. It would make sense to have separate multicast sub-groups in any case, since the two or more sub-group multicast data SA flows are received and can only be decrypted at disjoint sets of endpoints. 2) assign a unique destination IP multicast address to represent the composite group. This destination IP address would be different than the destination IP multicast address assigned to any of the sub-groups. For host-based IPsec systems, this could be a virtual multicast group address that is internal to the system (i.e. not seen on the wire). 3) Identify a new architectural component, called a "composite group distributor", that intercepts each packet *before* the SPD/SAD see it. The composite group distributor recognizes the composite group's IP multicast address, and then replicates the IP packet for each sub-group. As an example, the existing Linux iptables ULOG facility in combination with a user level composite group distributor process could provide this capability. It is an implementation choice whether packet replication occurs in a user level process or at the kernel level. Of course, our document would only describe the composite group distributor as a black box. 4) After being replicated, each cloned packet is sent to its sub-group's destination IP multicast address, not the composite group's IP multicast address. The SPD/SAD entry matches and applies the respective sub-group's security policy. The key point to observe here is that the SPD/SAD does not need to match a single packet against multiple security policies. In effect, we've solved that problem in an adjacent MSEC IPsec architectural component, the composite group distributor. This component would be required only for transport mode group SA configurations. Obviously, in a tunnel mode SA configuration, you have the lattitude of letting multicast routing solve the replication problem, as was illustrated in the slides presented at the Vancouver MSEC meeting. br, George On Thu, 17 Nov 2005, Brian Weis wrote: > This email contains one viewpoint regarding Issue 3, which is wrestling > with the idea of a single IPsec context having to possibly match a > single multicast packet against multiple policies. [Note: the term > "IPsec contexts" comes from Section 4 of rfc2401bis.] While it is a > noble goal to ensure that all Ipsec systems to have this capability, I > fear that it is an unreasonable goal from the standpoint of some Ipsec > systems. Here are some reasons why. > > This change requires *all* systems creating IPsec packets to implement > at least two new processing steps. > > a. This proposed semantics requires the IPsec context to match a > multicast packet against multiple IPsec policies. In the unicast case, a > single SPD lookup always results in matching a single IPsec SA. > > b. The proposed semantics require an IPsec context to replicate > packets (once for each matched policy). This is a completely new and > disruptive processing step in the encapsulating an IPsec packet! In my > estimation, this new semantic is disruptive to IPsec encapsulation > processing in either a UNIX or UNIX-like system (acting as a sender, > receiving a packet from a socket) or an IPsec gateway (relaying a > multicast packet). > > An alternative to requiring a single IPsec context to replicate packets > would be to apply multicast packet replication where it usually happens > -- as a result of multicast routing. Doing so does imply that there > exists a different IPsec context for each policy. This is possible in an > IPsec gateway with multiple interfaces, or perhaps in a host with a > complex internal architecture. However, a simple host with a single > IPsec context could not support encrypting to multiple groups -- it > would be necessary for the sending host to deliver the packet to a LAN > containing multiple IPsec contexts, one for each group. However, this > avoids costly new semantics in the IPsec context itself. > > Thanks, > Brian > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Nov 30 10:59:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUMU-0005hc-JJ for msec-archive@megatron.ietf.org; Wed, 30 Nov 2005 10:59:14 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03549 for ; Wed, 30 Nov 2005 10:58:28 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 025668D241; Wed, 30 Nov 2005 10:59:12 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id DB3178CB64 for ; Wed, 30 Nov 2005 10:59:09 -0500 (EST) Received: (qmail 61368 invoked by uid 3269); 30 Nov 2005 15:59:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61365 invoked from network); 30 Nov 2005 15:59:09 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 30 Nov 2005 15:59:09 -0000 Received: from 126.com (bj45-160.i.netease.com [202.108.45.160]) by klesh.pair.com (Postfix) with SMTP id 6187468377 for ; Wed, 30 Nov 2005 10:59:07 -0500 (EST) Received: from IMAGE-MYCOMPUTER (unknown [202.115.30.191]) by smtp3 (Coremail) with SMTP id f0AcGkPMjUN9_3QC.14364S2; Wed, 30 Nov 2005 23:58:57 +0800 (CST) Date: Thu, 1 Dec 2005 00:00:47 +0800 From: "Q.Shevchenko" To: "msec" Organization: UESTC X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20051130155907.6187468377@klesh.pair.com> Subject: [MSEC] GKMP,GDOI,GSAKMP AND MIKEY X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0197939363==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============0197939363== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBmb2xrczoNCg0KT29wcywgSSBhbSBjb25mdXNlZCBieSBHS01QLCBHRE9JLCBHU0FLTVAg YW5kIE1JS0VZLiBDYW4gYW55b25lIGRvIG1lIGEgZmF2b3IgdG8gdGVsbCBtZSB3aGF0IGFyZSB0 aGUgZGlmZmVyZW5jZXMgYW5kIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiB0aGVtPyBUaGFua3MgYSBs b3QNCg0KDQqhoaGhoaGhoaGhoaGhoaGhUS5TaGV2Y2hlbmtvDQoNCg== --===============0197939363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0197939363==-- From msec-bounces@securemulticast.org Wed Nov 30 11:17:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUeT-00015Z-Kv for msec-archive@megatron.ietf.org; Wed, 30 Nov 2005 11:17:49 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05610 for ; Wed, 30 Nov 2005 11:17:03 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 11C798C927; Wed, 30 Nov 2005 11:17:48 -0500 (EST) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 88A498C4B8 for ; Wed, 30 Nov 2005 11:17:46 -0500 (EST) Received: (qmail 65681 invoked by uid 3269); 30 Nov 2005 16:17:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65678 invoked from network); 30 Nov 2005 16:17:46 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 30 Nov 2005 16:17:46 -0000 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by klesh.pair.com (Postfix) with ESMTP id 588B468377 for ; Wed, 30 Nov 2005 11:17:46 -0500 (EST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2005 08:17:45 -0800 X-IronPort-AV: i="3.99,196,1131350400"; d="scan'208"; a="235689490:sNHT27764960" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAUGHXec022605; Wed, 30 Nov 2005 08:17:43 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 08:17:40 -0800 Received: from [192.168.0.10] ([10.21.144.243]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 08:17:39 -0800 In-Reply-To: <20051130155907.6187468377@klesh.pair.com> References: <20051130155907.6187468377@klesh.pair.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] GKMP,GDOI,GSAKMP AND MIKEY Date: Wed, 30 Nov 2005 08:17:38 -0800 To: "Q.Shevchenko" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 30 Nov 2005 16:17:39.0795 (UTC) FILETIME=[95A7A230:01C5F5C9] Cc: msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable GKMP is the ancestor of IETF group key management protocols, which I =20 think Hugh and others would say has been superseded by GSAKMP. There =20= are a number of differences, but to me one of the most important =20 difference is that GSAKMP supports efficient revocation of receivers =20 who leave or are removed from the secure group. GDOI has a subset of =20= the features of GSAKMP and is distinguished by the fact that it uses =20 ISAKMP headers and extends IKE for group security. The ISAKMP and =20 IKEv1 specifications both said that their protocols would support =20 extension by means of a "Domain of Interpretation," hence the name =20 "Group DOI." Personally, I thought IKEv1 was really an ISAMKP DOI as =20= is GDOI. (IKE v2 abandoned the DOI concept.) I also think that GDOI =20= and GSAKMP are better suited to large-scale broadcast, multicast, and =20= multi-unicast; by "large scale," I mean hundreds or more. Like the =20 other two, MIKEY pushes a key and can be used for groups, but MIKEY =20 is optimized (i.e. makes security tradeoffs) to minimize the message =20 exchange to one, two or three messages, which is considered to be a =20 requirement for teleconferencing. I'd say that MIKEY is suited to =20 smaller groups such as a teleconferencing session as opposed to a =20 video broadcast. Mark On Nov 30, 2005, at 8:00 AM, Q.Shevchenko wrote: > Dear folks: > > Oops, I am confused by GKMP, GDOI, GSAKMP and MIKEY. Can anyone do =20 > me a favor to tell me what are the differences and relationships =20 > between them? Thanks a lot > > > =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80= Q.Shevchenko > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec