From msec-admin@securemulticast.org Mon Jun 3 10:47:08 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16099 for ; Mon, 3 Jun 2002 10:47:06 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8E7F55355C; Mon, 3 Jun 2002 10:14:16 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0D83453565 for ; Mon, 3 Jun 2002 10:11:47 -0400 (EDT) Received: (qmail 3011 invoked by uid 3269); 3 Jun 2002 14:16:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3008 invoked from network); 3 Jun 2002 14:16:17 -0000 Received: from smtp1.cluster.oleane.net (195.25.12.16) by klesh.pair.com with SMTP; 3 Jun 2002 14:16:17 -0000 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp1.cluster.oleane.net with SMTP id g53EGFb43451 for ; Mon, 3 Jun 2002 16:16:15 +0200 (CEST) Message-ID: <00f601c20b0a$1cd69a80$0701a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F3_01C20B1A.DF9DA120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [MSEC] IPSec Global Summit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 3 Jun 2002 16:22:36 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_00F3_01C20B1A.DF9DA120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The call for proposal dead line of the fourth annual IPSec Global Summit = (to take place in Paris October 22 though 25, 2002) has been postponed = to June 21st. All details at: http://www.upperside.fr/ipsec02/ipsec02intro.htm ------=_NextPart_000_00F3_01C20B1A.DF9DA120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The call for proposal dead line = of the=20 fourth annual IPSec Global = Summit=20 (to take place in Paris October 22 though 25, = 2002) has=20 been postponed to June 21st.
All details = at:

http://www.uppe= rside.fr/ipsec02/ipsec02intro.htm

------=_NextPart_000_00F3_01C20B1A.DF9DA120-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 6 09:57:13 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13819 for ; Thu, 6 Jun 2002 09:57:12 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DE91753993; Thu, 6 Jun 2002 09:29:50 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CD3AD5370B for ; Thu, 6 Jun 2002 09:27:45 -0400 (EDT) Received: (qmail 87403 invoked by uid 3269); 6 Jun 2002 13:27:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87396 invoked from network); 6 Jun 2002 13:27:51 -0000 Received: from rumba.cefriel.it (131.175.53.6) by klesh.pair.com with SMTP; 6 Jun 2002 13:27:51 -0000 Received: by rumba.cefriel.it with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 15:29:34 +0200 Message-ID: <7B6D8AAF768F194EB3090A0325C85202056580@rumba.cefriel.it> From: Luca Venturi To: "'msec@securemulticast.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] STR acronym Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 6 Jun 2002 15:29:30 +0200 Hi everybody, I have to post a silly question: does anybody know if the name 'STR' of the protocol by Adrian Perrig, Yongdae Kim and Gene Tsudik is an acronym or simply a fantasy name? what does it stand for? I would really appreciate a kind answer from you! thank you in advance Luca _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 7 10:35:25 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28436 for ; Fri, 7 Jun 2002 10:35:24 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DCA1753999; Fri, 7 Jun 2002 10:33:49 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 24586537E0 for ; Fri, 7 Jun 2002 10:31:15 -0400 (EDT) Received: (qmail 94965 invoked by uid 3269); 7 Jun 2002 14:31:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94962 invoked from network); 7 Jun 2002 14:31:23 -0000 Received: from smtp016.mail.yahoo.com (216.136.174.113) by klesh.pair.com with SMTP; 7 Jun 2002 14:31:23 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Jun 2002 14:31:23 -0000 Message-Id: <5.0.0.25.2.20020607103122.01904e78@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com, gsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MSEC WG will NOT meet at Yokohama IETF Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 07 Jun 2002 10:32:54 -0400 Folks, It appears that only very few of the draft editors are planning to attend the Yokohama IETF. We are therefore not planning to hold an MSEC meeting in Yokohama. If people think it is worthwhile to hold a meeting nonetheless, then please say so now. Best, Ran and Thomas _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 7 10:59:21 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29462 for ; Fri, 7 Jun 2002 10:59:20 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C1A6653985; Fri, 7 Jun 2002 10:32:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 469CA53701 for ; Fri, 7 Jun 2002 10:28:47 -0400 (EDT) Received: (qmail 94707 invoked by uid 3269); 7 Jun 2002 14:28:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94704 invoked from network); 7 Jun 2002 14:28:55 -0000 Received: from smtp016.mail.yahoo.com (216.136.174.113) by klesh.pair.com with SMTP; 7 Jun 2002 14:28:55 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Jun 2002 14:28:54 -0000 Message-Id: <5.0.0.25.2.20020607102811.04555d80@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: BOF on Securing Neighbor Discovery at IETF 54 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 07 Jun 2002 10:30:26 -0400 >X-Apparently-To: thardjono@yahoo.com via web12508.mail.yahoo.com; 07 Jun >2002 05:42:43 -0700 (PDT) >X-Track: 1: 100 >From: "James Kempf" >To: , >Subject: BOF on Securing Neighbor Discovery at IETF 54 >Date: Fri, 7 Jun 2002 01:39:16 -0700 >Sender: owner-ipsec@lists.tislabs.com > >On Tues. afternoon 13:00-14:00 at IETF 54, a BOF will be held to discuss >securing IPv6 Neighbor Discovery. A BOF description including a reading >list and mailing list will appear shortly when the agenda is posted. If >you are interested in this problem, please attend. If you would like to >speak, please send email to me or Pekka Nikkander >(Pekka.Nikander@nomadiclab.com). We are especially interested in getting >people who have implemented an IPsec solution or think they have a >solution using IPsec, as a major issue that has come up with using IPsec >is how to do key distribution given that IKE would require using >Neighbor Discovery and manual keying is inconvenient for a large public >access network. > > jak _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 7 11:36:53 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01334 for ; Fri, 7 Jun 2002 11:36:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id ED8AC53A39; Fri, 7 Jun 2002 11:27:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E4E8153A27 for ; Fri, 7 Jun 2002 11:26:39 -0400 (EDT) Received: (qmail 1191 invoked by uid 3269); 7 Jun 2002 15:26:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1187 invoked from network); 7 Jun 2002 15:26:47 -0000 Received: from prue.eim.surrey.ac.uk (exim@131.227.76.5) by klesh.pair.com with SMTP; 7 Jun 2002 15:26:47 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17GLdF-0001AE-00; Fri, 07 Jun 2002 16:26:29 +0100 Message-ID: <3D00D097.4A005BC5@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Hardjono Cc: msec@securemulticast.org, canetti@watson.ibm.com, gsec@lists.tislabs.com Subject: Re: [MSEC] MSEC WG will NOT meet at Yokohama IETF References: <5.0.0.25.2.20020607103122.01904e78@pop.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *17GLdF-0001AE-00*YUj0d7hvMuA* (SECM, UniS) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 07 Jun 2002 16:26:15 +0100 Content-Transfer-Encoding: 7bit Hi Folks, I think the meeting should go as planned. I am sure there will be plenty of topics to discuss such GDOI and others. I am sure there is still great interest in MSEC and GSEC work. Best wishes. Haitham Thomas Hardjono wrote: > Folks, > > It appears that only very few of the draft editors are planning to attend the > Yokohama IETF. We are therefore not planning to hold an MSEC meeting in > Yokohama. If people think it is worthwhile to hold a meeting nonetheless, > then please say so now. > > Best, > Ran and Thomas > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 7 17:09:58 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13039 for ; Fri, 7 Jun 2002 17:09:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 64A80536FF; Fri, 7 Jun 2002 16:38:14 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 008D453A0E for ; Fri, 7 Jun 2002 16:36:14 -0400 (EDT) Received: (qmail 63456 invoked by uid 3269); 7 Jun 2002 20:36:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59561 invoked from network); 7 Jun 2002 20:29:42 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 7 Jun 2002 20:29:42 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g57KSVO11928; Fri, 7 Jun 2002 16:28:31 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g57KSRk34470; Fri, 7 Jun 2002 16:28:27 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id QAA27448; Fri, 7 Jun 2002 16:28:22 -0400 From: Ran Canetti Message-Id: <200206072028.QAA27448@ornavella.watson.ibm.com> To: H.Cruickshank@eim.surrey.ac.uk, thardjono@yahoo.com Subject: Re: [MSEC] MSEC WG will NOT meet at Yokohama IETF Cc: canetti@watson.ibm.com, gsec@lists.tislabs.com, msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 7 Jun 2002 16:28:22 -0400 Dear Haitham, I agree that there is interest, and it would have been great to be able to hold a meeting. But it seems that very few of the draft editors are planning to make it, and I doubt there is much point in holding a meeting without them. (Specifically, if I understand correctly then none of the editors of GDOI are planning to make it. Please correct me if I'm wrong.) If there are any specific issues that you'd like to bring up in the meeting, you're welcome to bring them up on the list. Best, Ran > From msec-admin@securemulticast.org Fri Jun 7 11:38:57 2002 > > Hi Folks, > > I think the meeting should go as planned. I am sure there will be plenty of > topics to discuss such GDOI and others. I am sure there is still great interest > in MSEC and GSEC work. > > Best wishes. > Haitham > > Thomas Hardjono wrote: > > > Folks, > > > > It appears that only very few of the draft editors are planning to attend the > > Yokohama IETF. We are therefore not planning to hold an MSEC meeting in > > Yokohama. If people think it is worthwhile to hold a meeting nonetheless, > > then please say so now. > > > > Best, > > Ran and Thomas > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 7 18:15:39 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14907 for ; Fri, 7 Jun 2002 18:15:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1780153642; Fri, 7 Jun 2002 18:15:30 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id F3EB453642 for ; Fri, 7 Jun 2002 18:13:41 -0400 (EDT) Received: (qmail 80106 invoked by uid 3269); 7 Jun 2002 22:13:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80097 invoked from network); 7 Jun 2002 22:13:51 -0000 Received: from gremlin.ics.uci.edu (mmdf@128.195.1.70) by klesh.pair.com with SMTP; 7 Jun 2002 22:13:51 -0000 Received: from isi.edu ( sconce.ics.uci.edu [128.200.38.76] ) by gremlin-relay.ics.uci.edu id aa20546 for ; 7 Jun 2002 15:13 PDT Message-ID: <3D012C73.6050205@isi.edu> From: Yongdae Kim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020513 Netscape/7.0b1 X-Accept-Language: en-us, en, ko, ko-kr MIME-Version: 1.0 To: MSEC Subject: Re: [MSEC] STR acronym Content-Type: multipart/related; boundary="------------070006030605010709020406" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 07 Jun 2002 14:58:11 -0700 --------------070006030605010709020406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 2 days ago I already posted from hotmail, but the message is not showing up till now... So repost... If duplicated, disregard this message... Static version of our paper was already written in 80's by Steer et. al... Later in ICDCS 98, Michael Steiner et. al called this static scheme as STR... We also call our dynamic version protocol as STR without having any specific reason... After some discussion with other coauthors, we decide that "STR" is acronym of "Skinny TRee" ;-) Thanks, Yongdae From venturi@cefriel.it Thu Jun 6 14:29:30 2002 From: venturi@cefriel.it (Luca Venturi) Date: Thu, 6 Jun 2002 15:29:30 +0200 Subject: [MSEC] STR acronym Message-ID: <7B6D8AAF768F194EB3090A0325C85202056580@rumba.cefriel.it> Hi everybody, I have to post a silly question: does anybody know if the name 'STR' of the protocol by Adrian Perrig, Yongdae Kim and Gene Tsudik is an acronym or simply a fantasy name? what does it stand for? I would really appreciate a kind answer from you! thank you in advance Luca --------------070006030605010709020406-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jun 11 03:11:57 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14998 for ; Tue, 11 Jun 2002 03:11:56 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 144725362F; Tue, 11 Jun 2002 02:46:37 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2DC365362F for ; Tue, 11 Jun 2002 02:45:04 -0400 (EDT) Received: (qmail 25465 invoked by uid 3269); 11 Jun 2002 06:45:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25462 invoked from network); 11 Jun 2002 06:45:21 -0000 Received: from albatross-ext.wise.edt.ericsson.se (HELO albatross.wise.edt.ericsson.se) (193.180.251.49) by klesh.pair.com with SMTP; 11 Jun 2002 06:45:21 -0000 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5B6jFmG010306 for ; Tue, 11 Jun 2002 08:45:15 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 08:45:05 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E070CBBF3@esealnt416> From: "Fredrik Lindholm (ERA)" To: msec@securemulticast.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] draft-ietf-msec-mikey-02.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 11 Jun 2002 08:43:34 +0200 Hi, a new version of MIKEY is now available. The updates are mainly editorial. We have tried to address the comments and questions posted previously on the list by Martin Euchner (posted 11th of March) and by Mark Baugher (posted 1st of April). http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-02.txt Enjoy, Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jun 11 09:43:41 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23775 for ; Tue, 11 Jun 2002 09:43:41 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 55E3D53706; Tue, 11 Jun 2002 09:42:24 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E01B453650 for ; Tue, 11 Jun 2002 09:41:30 -0400 (EDT) Received: (qmail 70621 invoked by uid 3269); 11 Jun 2002 13:41:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 70616 invoked from network); 11 Jun 2002 13:41:49 -0000 Received: from rumba.cefriel.it (131.175.53.6) by klesh.pair.com with SMTP; 11 Jun 2002 13:41:49 -0000 Received: by rumba.cefriel.it with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 15:43:34 +0200 Message-ID: <7B6D8AAF768F194EB3090A0325C852023984F0@rumba.cefriel.it> From: Luca Venturi To: "'msec@securemulticast.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C2115E.BAC64830" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [MSEC] gdoi simulation Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 11 Jun 2002 15:43:33 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C2115E.BAC64830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi everybody, I have been implementing gdoi for network simulator. now I would like to use my model to measure gdoi performance . however I am not sure about what kind of data and measurements might be of some interest. any idea? any suggestion is welcome! please reply! thanks a lot in advance Luca ------=_NextPart_000_0000_01C2115E.BAC64830 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBjCCApUw ggH+oAMCAQICAwdOqDANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAyMDQyNDA4MjkxMFoXDTAzMDQyNDA4MjkxMFowWzEQMA4GA1UEBBMHVmVudHVy aTENMAsGA1UEKhMETHVjYTEVMBMGA1UEAxMMTHVjYSBWZW50dXJpMSEwHwYJKoZIhvcNAQkBFhJ2 ZW50dXJpQGNlZnJpZWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOgHZQCZdsGNot5Q YmndQCvzq6nDbZ+xmmg/6TKEX6jenb+63EF8tByDzQiIkc8Y/WLT3bI9zCpRy1UYU2Zg4sZGXP7B z227my7ALv/VGupqAVuNyCDhjBVLJyRnciyNTTIs7Oyn6e9E+F8Z3ruUZBaGl5rZpVsYDQk19qV/ Ve81AgMBAAGjLzAtMB0GA1UdEQQWMBSBEnZlbnR1cmlAY2VmcmllbC5pdDAMBgNVHRMBAf8EAjAA MA0GCSqGSIb3DQEBBAUAA4GBAAY0MATZYldnFSlYb68pavbpY7awj6gnv8e2jAw/uogsoZFJkkDo aTsImz+f6HIt1meCGLlzM3HDLdKMuWOnKjs0aBldYsdUThi+LJC5KkgepHi92/WpX6IQToSKuX3P Q20Y/tM5qfA3sTw1xTRpanbJumiA82fDhYjrjuwvPQ0dMIIDLTCCApagAwIBAgIBADANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEw MTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhh d3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRe fS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5 lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMT MBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBv jWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgC neSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAzgw ggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wNDA4MjcyMzU5NTla MIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNV BAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCj bZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0 m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQ cml2YXRlTGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG 9w0BAQQFAAOBgQAxsUtHXfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3s DSo491BVqGz3Da1MG7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLz WtvKPPZE6iZph39Ins6ln+eE2MliYq0FxjGCAqowggKmAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0 ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAyMDAwLjguMzACAwdOqDAJBgUrDgMCGgUAoIIBZTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTExMzQzMjdaMCMGCSqGSIb3DQEJBDEWBBRfl7TZ zm8Nggry4nZCjc3BbYadKTBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYB BAGCNxAEMYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwdOqDANBgkq hkiG9w0BAQEFAASBgE5cAcZSDES9wCS1tIR+A4p5ZNnX/8q9Y65ySvyGFnH3M/KjwrNcQOKGQBXA ZjO60+J2+5a5WNBi57jUOpcmbpONpIm+WxbU+27msLCRQfKlaysYFbZFUfEu9vbmk4kXKTZcSNd1 itCkWsZqBv+EMVAvLY4hehTg/xXi9qTugGaAAAAAAAAA ------=_NextPart_000_0000_01C2115E.BAC64830-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jun 11 20:50:18 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18168 for ; Tue, 11 Jun 2002 20:50:17 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4997B5358A; Tue, 11 Jun 2002 20:50:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5A720535E2 for ; Mon, 10 Jun 2002 07:19:37 -0400 (EDT) Received: (qmail 58578 invoked by uid 3269); 10 Jun 2002 11:19:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58575 invoked from network); 10 Jun 2002 11:19:53 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 10 Jun 2002 11:19:53 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28625; Mon, 10 Jun 2002 07:19:13 -0400 (EDT) Message-Id: <200206101119.HAA28625@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-mikey-02.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 10 Jun 2002 07:19:13 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : MIKEY: Multimedia Internet KEYing Author(s) : J. Arkko et al. Filename : draft-ietf-msec-mikey-02.txt Pages : 52 Date : 07-Jun-02 Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. Such a solution has to be suitable to be used in the context of conversational multimedia in a heterogeneous environment. This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication), and shows how it may work together with protocols such as SIP and RTSP. In particular, its use to support the Secure Real-time Transport Protocol, [SRTP], is described in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mikey-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mikey-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020607140120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607140120.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jun 11 21:04:47 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18518 for ; Tue, 11 Jun 2002 21:04:46 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DF3A153699; Tue, 11 Jun 2002 20:30:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 922E953532 for ; Tue, 11 Jun 2002 20:29:04 -0400 (EDT) Received: (qmail 84118 invoked by uid 3269); 12 Jun 2002 00:29:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84115 invoked from network); 12 Jun 2002 00:29:24 -0000 Received: from softdnserror (HELO sj-msg-core-1.cisco.com) (171.71.163.11) by klesh.pair.com with SMTP; 12 Jun 2002 00:29:24 -0000 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5C0SqHs001423; Tue, 11 Jun 2002 17:28:52 -0700 (PDT) Received: from cisco.com (dhcp-128-107-212-116.cisco.com [128.107.212.116]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA29544; Tue, 11 Jun 2002 17:28:50 -0700 (PDT) Message-ID: <3D0695C3.7B741768@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Luca Venturi Cc: msec@securemulticast.org, gdoi@www.vovida.org References: <008501c2113f$30b64a60$6205af83@cefriel.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: [gdoi] gdoi simulation Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 11 Jun 2002 17:28:51 -0700 Content-Transfer-Encoding: 7bit Hi Luca, One very interesting measurement would be to determine how well a GDOI key server scales. For example, to measure the number of GDOI registration (GROUPKEY-PULL) requests that a key server could handle per second. Brian > Luca Venturi wrote: > > hi everybody, > > I have been implementing gdoi for network simulator. now I would like > to use my model to measure gdoi performance . however I am not sure > about what kind of data and measurements might be of some interest. > any idea? any suggestion is welcome! please reply! > > thanks a lot in advance > > Luca -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jun 11 23:11:41 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21604 for ; Tue, 11 Jun 2002 23:11:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 322F253787; Tue, 11 Jun 2002 23:11:23 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CD6BD53649 for ; Tue, 11 Jun 2002 23:10:27 -0400 (EDT) Received: (qmail 403 invoked by uid 3269); 12 Jun 2002 03:10:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 393 invoked from network); 12 Jun 2002 03:10:46 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 12 Jun 2002 03:10:46 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5C39ouF004902; Tue, 11 Jun 2002 20:09:50 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABV32335; Tue, 11 Jun 2002 20:07:56 -0700 (PDT) Message-Id: <4.3.2.7.2.20020611195759.044d3408@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Luca Venturi From: Mark Baugher Subject: Re: [MSEC] gdoi simulation Cc: gsec@lists.tislabs.com, msec@securemulticast.org In-Reply-To: <7B6D8AAF768F194EB3090A0325C852023984F0@rumba.cefriel.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 11 Jun 2002 20:08:19 -0700 hi Luca I'm forwarding your note from msec to gsec as there might be some interest here as well. I think we would like to know how gdoi scales from clique-size groups and consider what gdoi does and does not do well for such applications (http://sconce.ics.uci.edu/cliques/). Consider multicast and group conferencing. How expensive is it add a member, remove a member, or change a key in the context of unicast and multicast conferencing sessions? It would be interesting to consider client/server gdoi applications where the features of gdoi can be used to improve client authentication and stream security over, say, SSL. Imagine an interactive TV program that uses gdoi to manage get SRTP or MP4 keys. What happens if there is a "Victoria's Secret" or flash- crowd effect in this application scenario? The communications overhead, processing overhead, stability and convergence of very large broadcast groups is also of interest to us. At 03:43 PM 6/11/2002 +0200, Luca Venturi wrote: >hi everybody, > >I have been implementing gdoi for network simulator. now I would like to >use my model to measure gdoi performance . however I am not sure about >what kind of data and measurements might be of some interest. any idea? >any suggestion is welcome! please reply! > >thanks a lot in advance > >Luca _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jun 18 18:34:33 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07091 for ; Tue, 18 Jun 2002 18:34:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9D80C5364B; Tue, 18 Jun 2002 17:59:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B54E5535DC for ; Tue, 18 Jun 2002 17:57:04 -0400 (EDT) Received: (qmail 49608 invoked by uid 3269); 18 Jun 2002 21:57:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49605 invoked from network); 18 Jun 2002 21:57:41 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 18 Jun 2002 21:57:41 -0000 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5ILv5PI007234 for ; Tue, 18 Jun 2002 14:57:05 -0700 (PDT) Received: from cisco.com (dhcp-128-107-212-85.cisco.com [128.107.212.85]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA00992 for ; Tue, 18 Jun 2002 14:57:04 -0700 (PDT) Message-ID: <3D0FACB0.42A78E54@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Next GDOI draft Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 18 Jun 2002 14:57:04 -0700 Content-Transfer-Encoding: 7bit This is a heads up that we will be submitting a new GDOI draft soon with some minor changes. It is necessitated by a request from the Steve Bellovin that we improve the Security Considerations section before submitting it to the IESG. In the meantime we've discovered a few small issues which need to be corrected; I'll forbear from describing them here, but could send them to the list if requested. One issue does warrant some discussion on this list. It has primarily to do with expelling group members when a group key management algorithm (e.g., LKH) is used with a KEK. It is also somewhat of an issue when a KEK is used alone. Recall that a GROUPKEY-PUSH message is a single exchange sent to all group members (probably via multicast). It looks like this: Member GCKS or Delegate ------ ---------------- <---- HDR*, SEQ, SA, KD, [CERT,] SIG The entire message (following the *) is encrypted under the "current" KEK which is held by all group members. The SA payload may contain policy for a "new" KEK which will replace the existing KEK, and this replacement begins with the next GROUPKEY-PUSH message. If the SA payload has new KEK policy, then the KD payload will contain the new KEK keys. This is most likely the case where an LKH group membership key tree is used, so the KD payload will have several sets of key arrays which work together to provide a new KEK to group members who have not been expelled from the group. [See RFC 2627 for details.] Notice that the expelled group member will not be able to read the new KEK (that's the main property of a group management algorithm), but because he has possession of the "current" KEK and can decrypt and read the rest of the message. Now if someone has taken the trouble to expel one or more group members they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so that the expelled member can no longer participate in the group. For efficiency reasons it should be possible to send out the new TEK SAs in the same GROUPKEY-PUSH message in which the KEK is changed. The SA and KD payloads support this today. But here's the problem: Since the expelled group member has the "current" KEK and can read the entire message, he will be able to read the new TEK SAs and keys and thus won't be expelled from the group until the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message will be the first use of the new KEK. Here are some possibilities to resolve the issue in the draft: Solution 1: The simplest fix for this problem is to disallow sending of any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. Unfortunately, this disallows any possibility of efficient rekeys of group policy. This does have the advantage of being the most minimal change to the draft as it would simply add some MUST NOT statements. Solution 2: Leave the KD payload intact. That is, allow it to contain both the KEK and TEK keys. But require the TEK portion of the KD payload to be super-encrypted with the new KEK. This maintains efficiency, but requires extra processing to that portion of the KD payload which is super-encrypted. This is a minimal (but subtle) change to the GROUPKEY-PUSH protocol. However it does add substantial complexity to the construction and processing of the KD payload. Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one which would contain the KEK keys. The other would the TEK keys and be super-encrypted with the new KEK. This is the most change to the draft, but does provide the desired efficiency and is the cleanest overall design. I'd be interested at hearing opinions on the above solutions and/or alternate solutions. Thanks, Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 19 13:12:17 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27464 for ; Wed, 19 Jun 2002 13:12:17 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2D32E53592; Wed, 19 Jun 2002 12:46:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4129F535B9 for ; Wed, 19 Jun 2002 12:44:37 -0400 (EDT) Received: (qmail 97872 invoked by uid 3269); 19 Jun 2002 16:45:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97869 invoked from network); 19 Jun 2002 16:45:15 -0000 Received: from softdnserror (HELO sj-msg-core-1.cisco.com) (171.71.163.11) by klesh.pair.com with SMTP; 19 Jun 2002 16:45:15 -0000 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5JGigHs006237 for ; Wed, 19 Jun 2002 09:44:42 -0700 (PDT) Received: from cisco.com (dhcp-128-107-212-54.cisco.com [128.107.212.54]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA27590 for ; Wed, 19 Jun 2002 09:44:38 -0700 (PDT) Message-ID: <3D10B4F7.7027A9B0@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <3D0FACB0.42A78E54@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 19 Jun 2002 09:44:39 -0700 Content-Transfer-Encoding: 7bit Further clarification is needed since I wasn't very clear how Solutions 2 and 3 below would be implemented. As currently specified the entire rekey message is protected under KEK. The first operation of any group member is to decrypt the message with KEK. Then as part of KD payload processing the group member determines the new key protecting rekey messages (KEK') from the LKH update arrays. The new proposed processing (for solutions 2 and 3) would be for the group member to use KEK' to decrypt the TEK keys in the KD payload. In this way, a group member who had been removed from the group would not be able to gain the next set of TEK keys. This is a reasonable thing to do. But I'd like to get a sense from the working group as to how comfortable they feel about making a change like this after the protocol has finished working group last call. The difference between solutions 2 and 3 has to do with payload processing. Solution 2 does not change the message structure, but may be more difficult for an implementation. Thanks, Brian Brian Weis wrote: > One issue does warrant some discussion on this list. It has primarily to > do with expelling group members when a group key management algorithm > (e.g., LKH) is used with a KEK. It is also somewhat of an issue when a > KEK is used alone. > > Recall that a GROUPKEY-PUSH message is a single exchange sent to all > group members (probably via multicast). It looks like this: > > Member GCKS or Delegate > ------ ---------------- > > <---- HDR*, SEQ, SA, KD, [CERT,] SIG > > The entire message (following the *) is encrypted under the "current" > KEK which is held by all group members. The SA payload may contain > policy for a "new" KEK which will replace the existing KEK, and this > replacement begins with the next GROUPKEY-PUSH message. If the SA > payload has new KEK policy, then the KD payload will contain the new KEK > keys. This is most likely the case where an LKH group membership key > tree is used, so the KD payload will have several sets of key arrays > which work together to provide a new KEK to group members who have not > been expelled from the group. [See RFC 2627 for details.] > > Notice that the expelled group member will not be able to read the new > KEK (that's the main property of a group management algorithm), but > because he has possession of the "current" KEK and can decrypt and read > the rest of the message. > > Now if someone has taken the trouble to expel one or more group members > they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so > that the expelled member can no longer participate in the group. For > efficiency reasons it should be possible to send out the new TEK SAs in > the same GROUPKEY-PUSH message in which the KEK is changed. The SA and > KD payloads support this today. > > But here's the problem: Since the expelled group member has the > "current" KEK and can read the entire message, he will be able to read > the new TEK SAs and keys and thus won't be expelled from the group until > the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message > will be the first use of the new KEK. > > Here are some possibilities to resolve the issue in the draft: > > Solution 1: The simplest fix for this problem is to disallow sending of > any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. > Unfortunately, this disallows any possibility of efficient rekeys of > group policy. This does have the advantage of being the most minimal > change to the draft as it would simply add some MUST NOT statements. > > Solution 2: Leave the KD payload intact. That is, allow it to contain > both the KEK and TEK keys. But require the TEK portion of the KD payload > to be super-encrypted with the new KEK. This maintains efficiency, but > requires extra processing to that portion of the KD payload which is > super-encrypted. This is a minimal (but subtle) change to the > GROUPKEY-PUSH protocol. However it does add substantial complexity to > the construction and processing of the KD payload. > > Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one > which would contain the KEK keys. The other would the TEK keys and be > super-encrypted with the new KEK. This is the most change to the draft, > but does provide the desired efficiency and is the cleanest overall > design. > > I'd be interested at hearing opinions on the above solutions and/or > alternate solutions. > > Thanks, > Brian > > -- > Brian Weis > Strategic Cryptographic Development, ITD, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 20 13:21:13 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07333 for ; Thu, 20 Jun 2002 13:21:11 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 70D6F5362F; Thu, 20 Jun 2002 12:50:34 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3803853840 for ; Thu, 20 Jun 2002 12:49:07 -0400 (EDT) Received: (qmail 90855 invoked by uid 3269); 20 Jun 2002 16:49:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90852 invoked from network); 20 Jun 2002 16:49:48 -0000 Received: from softdnserror (HELO sj-msg-core-3.cisco.com) (171.70.157.152) by klesh.pair.com with SMTP; 20 Jun 2002 16:49:48 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5KGmauF019484; Thu, 20 Jun 2002 09:48:42 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABW79309; Thu, 20 Jun 2002 09:46:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20020620094018.04759940@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: perrig@cs.berkeley.edu (Adrian Perrig) From: Mark Baugher Cc: thardjono@verisign.com, hh@sparta.com, Brian Weis , canetti@watson.ibm.com, rbriscoe@jungle.bt.co.uk, msec@securemulticast.org In-Reply-To: <20020620162507.F29561CD0AF@paris.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: Tesla source authentication in GDOI draft Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 20 Jun 2002 09:46:57 -0700 hi Adrian, We have a GDOI-TESLA proposal and posted that proposal over a year ago in a GDOI appendix. We removed that appendix to avoid the issue of referencing an expired I-D in a standards-track I-D, which is what GDOI is now. I'd like to resume work from that appendix, since it has been reviewed by you and other. I posted it: http://www.rdrop.com/users/mbaugher/I-D/Old-Tesla-appendix.txt At 09:25 AM 6/20/2002 -0700, Adrian Perrig wrote: >Hi, >we're now working on the TESLA drafts and we would like to discuss the >interactions between GDOI and TESLA. Ideally, the current version of >GDOI would also specify the parameter setup for TESLA, as version 2 of >the draft did (draft-ietf-msec-gdoi-02.txt). We would be happy to >collaborate with you to work out these details. If you like, we can >have a phone meeting next week (Thursday or Friday would be good for >me). > >We're also working on an standard implementation. Ideally, our >implementation would be interoperable with the GDOI implementation, >and we also be happy to collaborate with you on that as well. > >We feel that such collaboration would strengthen both GDOI and TESLA, >and speed up adoption for both. Let us know what you think. Best >wishes, > Adrian > >PS: Here's a preliminary list of parameters/return values for TESLA. > >SENDERS_CERT_TYPE >SENDERS_CERT >REQUEST_ARRIVAL_TIME (NTP format, for direct time synchronization) >REQUEST_NONCE (Nonce that receiver sent in request) >CLOCK_SKEW (Determines how often receivers re-synchronize clocks) And here's the TESLA table (in ISAKMP TLV) from http://www.rdrop.com/users/mbaugher/I-D/Old-Tesla-appendix.txt A.3 TESLA SA TEK Attributes The attributes for the source authentication algorithm follow the MESP/AMESP SA TEK attributes. These are for TESLA. ID Class Value Type -------- ----- ---- RESERVED 0 SOURCE_ID 64 B DIRECT_SYNCHRONIZATION 65 B SENDERS_CERT_TYPE 66 B SENDERS_CERT 67 V HMAC_TYPE 68 B KEY_CHAIN_PRF 69 B INTERVAL_TIME 70 V INTERVAL_NUMBER 71 V INTERVAL_DURATION 72 V KEY_DISCLOSURE_DELAY 73 V KEY_CHAIN_COMMITMENT_VALUE 74 V KEY_CHAIN_EXPIRATION_VALUE 75 V Are we on the same page? cheers, Mark >Crypto algorithms, all specify [input and] output sizes in bits: >MAC_FUNCTION >KEY_CHAIN_GENERATION_FUNCTION >MAC_KEY_DERIVATION_FUNCTION > >Interval information: >INTERVAL_NUMBER (An interval of which the key can be disclosed) >INTERVAL_START_TIME (Of the interval with INTERVAL_NUMBER, NTP format) >INTERVAL_DURATION (NTP format) > >Keychain parameters: >KEY_DISCLOSURE_DELAY (Number of intervals) >KEY_CHAIN_VALUE (Key chain key of interval INTERVAL_NUMBER) >KEY_CHAIN_LENGTH (Total length of current key chain) >KEY_CHAIN_LAST_KEY (Index of last key in key chain, could be > different from KEY_CHAIN_LENGTH if multiple key > chains were concatenated.) _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 00:20:28 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21447 for ; Fri, 21 Jun 2002 00:20:23 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9D42C536EB; Thu, 20 Jun 2002 23:43:09 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id ECAE3538F7 for ; Thu, 20 Jun 2002 23:31:04 -0400 (EDT) Received: (qmail 83002 invoked by uid 3269); 21 Jun 2002 03:31:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82999 invoked from network); 21 Jun 2002 03:31:46 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 21 Jun 2002 03:31:46 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5KH9UPI015771; Thu, 20 Jun 2002 10:09:37 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABW79748; Thu, 20 Jun 2002 10:07:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20020620100108.04993a58@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Brian Weis From: Mark Baugher Subject: Re: [MSEC] Next GDOI draft Cc: msec@securemulticast.org In-Reply-To: <3D0FACB0.42A78E54@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 20 Jun 2002 10:07:35 -0700 Hi All, At 02:57 PM 6/18/2002 -0700, Brian Weis wrote: >This is a heads up that we will be submitting a new GDOI draft soon with >some minor changes. It is necessitated by a request from the Steve >Bellovin that we improve the Security Considerations section before >submitting it to the IESG. > >In the meantime we've discovered a few small issues which need to be >corrected; I'll forbear from describing them here, but could send them >to the list if requested. > >One issue does warrant some discussion on this list. It has primarily to >do with expelling group members when a group key management algorithm >(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a >KEK is used alone. > >Recall that a GROUPKEY-PUSH message is a single exchange sent to all >group members (probably via multicast). It looks like this: > > Member GCKS or Delegate > ------ ---------------- > > <---- HDR*, SEQ, SA, KD, [CERT,] SIG > >The entire message (following the *) is encrypted under the "current" >KEK which is held by all group members. The SA payload may contain >policy for a "new" KEK which will replace the existing KEK, and this >replacement begins with the next GROUPKEY-PUSH message. If the SA >payload has new KEK policy, then the KD payload will contain the new KEK >keys. This is most likely the case where an LKH group membership key >tree is used, so the KD payload will have several sets of key arrays >which work together to provide a new KEK to group members who have not >been expelled from the group. [See RFC 2627 for details.] > >Notice that the expelled group member will not be able to read the new >KEK (that's the main property of a group management algorithm), but >because he has possession of the "current" KEK and can decrypt and read >the rest of the message. > >Now if someone has taken the trouble to expel one or more group members >they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so >that the expelled member can no longer participate in the group. For >efficiency reasons it should be possible to send out the new TEK SAs in >the same GROUPKEY-PUSH message in which the KEK is changed. The SA and >KD payloads support this today. > >But here's the problem: Since the expelled group member has the >"current" KEK and can read the entire message, he will be able to read >the new TEK SAs and keys and thus won't be expelled from the group until >the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message >will be the first use of the new KEK. > >Here are some possibilities to resolve the issue in the draft: > >Solution 1: The simplest fix for this problem is to disallow sending of >any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. >Unfortunately, this disallows any possibility of efficient rekeys of >group policy. This does have the advantage of being the most minimal >change to the draft as it would simply add some MUST NOT statements. I favor this solution although it is arguably broken. The reason I favor a broken solution is that we don't yet have enough implementation experience. We discussed this problem at length at the start of WG Last Call. There is no IETF requirement that we have interoperable implementations for a Proposed Standard. Thanks to Brian and Lakshminath, we did have interoperable implementations for the PULL (GKM Registration) exchange. I recall that you discovered a problem with the PUSH (GKM Rekey) message as soon as you implemented it. I expect that we'll discover more as we get more implementation experience with LKH (e.g. two interoperable implementations). I'm afraid that too many last-minute design decisions will result in problems. I also think that GDOI is very useful without LKH-like function. I think this is okay for the Proposed Standard. regards, Mark >Solution 2: Leave the KD payload intact. That is, allow it to contain >both the KEK and TEK keys. But require the TEK portion of the KD payload >to be super-encrypted with the new KEK. This maintains efficiency, but >requires extra processing to that portion of the KD payload which is >super-encrypted. This is a minimal (but subtle) change to the >GROUPKEY-PUSH protocol. However it does add substantial complexity to >the construction and processing of the KD payload. > >Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one >which would contain the KEK keys. The other would the TEK keys and be >super-encrypted with the new KEK. This is the most change to the draft, >but does provide the desired efficiency and is the cleanest overall >design. > >I'd be interested at hearing opinions on the above solutions and/or >alternate solutions. > >Thanks, >Brian > >-- >Brian Weis >Strategic Cryptographic Development, ITD, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.com > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 06:29:42 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06350 for ; Fri, 21 Jun 2002 06:29:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 03DC0535A3; Fri, 21 Jun 2002 06:29:01 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 57E8D5359A for ; Fri, 21 Jun 2002 06:28:32 -0400 (EDT) Received: (qmail 64193 invoked by uid 3269); 21 Jun 2002 10:29:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 64190 invoked from network); 21 Jun 2002 10:29:15 -0000 Received: from rumba.cefriel.it (131.175.53.6) by klesh.pair.com with SMTP; 21 Jun 2002 10:29:15 -0000 Received: by rumba.cefriel.it with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 12:30:42 +0200 Message-ID: <7B6D8AAF768F194EB3090A0325C85202398524@rumba.cefriel.it> From: Luca Venturi To: "'msec@securemulticast.org'" Subject: RE: [MSEC] Next GDOI draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00AB_01C2191F.73FFF4F0" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 12:30:41 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_00AB_01C2191F.73FFF4F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I believe that would really be a great effort, but to my mind it is definitely a better solution to fix the draft according to one of the solutions 2 or 3. Solution 3 seems to me the most efficient as it is a cleaner solution to divide the KD payload up into a KEK part and a TEK part: that would be also easier to implement. I see that would be a most change to the draft as it would require a re-definition of the KD payload, but it if we renounce to the chance of changing both the TEK and the KEK in the same message, that means not to take advantage of the properties of LKH algorithm, without which GDOI loses most of its efficiency, as that would reduce GDOI's potential of being used in the greatest possible number of contexts. Indeed, the only thing to take into account is the computational overhead introduced by such a modification (although Solution 3 wouldn't require that much payload processing, after all ...), but in my opinion this problem is overwhelmed by the benefits GDOI might draw from it. Best Regards Luca ------=_NextPart_000_00AB_01C2191F.73FFF4F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBjCCApUw ggH+oAMCAQICAwdOqDANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAyMDQyNDA4MjkxMFoXDTAzMDQyNDA4MjkxMFowWzEQMA4GA1UEBBMHVmVudHVy aTENMAsGA1UEKhMETHVjYTEVMBMGA1UEAxMMTHVjYSBWZW50dXJpMSEwHwYJKoZIhvcNAQkBFhJ2 ZW50dXJpQGNlZnJpZWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOgHZQCZdsGNot5Q YmndQCvzq6nDbZ+xmmg/6TKEX6jenb+63EF8tByDzQiIkc8Y/WLT3bI9zCpRy1UYU2Zg4sZGXP7B z227my7ALv/VGupqAVuNyCDhjBVLJyRnciyNTTIs7Oyn6e9E+F8Z3ruUZBaGl5rZpVsYDQk19qV/ Ve81AgMBAAGjLzAtMB0GA1UdEQQWMBSBEnZlbnR1cmlAY2VmcmllbC5pdDAMBgNVHRMBAf8EAjAA MA0GCSqGSIb3DQEBBAUAA4GBAAY0MATZYldnFSlYb68pavbpY7awj6gnv8e2jAw/uogsoZFJkkDo aTsImz+f6HIt1meCGLlzM3HDLdKMuWOnKjs0aBldYsdUThi+LJC5KkgepHi92/WpX6IQToSKuX3P Q20Y/tM5qfA3sTw1xTRpanbJumiA82fDhYjrjuwvPQ0dMIIDLTCCApagAwIBAgIBADANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEw MTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhh d3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRe fS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5 lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMT MBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBv jWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgC neSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAzgw ggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wNDA4MjcyMzU5NTla MIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNV BAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCj bZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0 m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQ cml2YXRlTGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG 9w0BAQQFAAOBgQAxsUtHXfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3s DSo491BVqGz3Da1MG7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLz WtvKPPZE6iZph39Ins6ln+eE2MliYq0FxjGCAqowggKmAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0 ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAyMDAwLjguMzACAwdOqDAJBgUrDgMCGgUAoIIBZTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MjExMDMwNDBaMCMGCSqGSIb3DQEJBDEWBBRRSzTS I5hWcByGfHW6z9arvO3vLTBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYB BAGCNxAEMYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwdOqDANBgkq hkiG9w0BAQEFAASBgBCm78H19KF66kny7H/iTl3h8DaSAABdMu86uuyus43DR7y0dzqyG6LskScO kZk446IkGWVnA4+4rBtmAQ356pjnR01yCfSObrzkHDfwpvlG8XHAIPMKxGo+Ytbm0bf8Q3Kci43K zPpTWIo/Q8gazUQakHb9aChIOY5MGgC4vpksAAAAAAAA ------=_NextPart_000_00AB_01C2191F.73FFF4F0-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 10:57:01 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15664 for ; Fri, 21 Jun 2002 10:57:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9039D5369E; Fri, 21 Jun 2002 10:56:26 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id AAB37535FA for ; Fri, 21 Jun 2002 10:55:31 -0400 (EDT) Received: (qmail 95567 invoked by uid 3269); 21 Jun 2002 14:56:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95564 invoked from network); 21 Jun 2002 14:56:15 -0000 Received: from zcars04e.nortelnetworks.com (HELO zcars04e.ca.nortel.com) (47.129.242.56) by klesh.pair.com with SMTP; 21 Jun 2002 14:56:15 -0000 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5LEtV201496; Fri, 21 Jun 2002 10:55:32 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFR0XGX5; Fri, 21 Jun 2002 10:55:31 -0400 Received: from nortelnetworks.com (lakshminath1.us.nortel.com [47.16.67.111]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N12LGRN2; Fri, 21 Jun 2002 10:55:31 -0400 Message-ID: <3D133F33.3090008@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Brian Weis Cc: msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <3D0FACB0.42A78E54@cisco.com> <3D10B4F7.7027A9B0@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 10:58:59 -0400 Content-Transfer-Encoding: 7bit Brian, Would it be possible to keep the SA payload secret (to disallow kickedout members from knowing policy changes), if necessary? cheers, Lakshminath Brian Weis wrote: > Further clarification is needed since I wasn't very clear how Solutions > 2 and 3 below would be implemented. > > As currently specified the entire rekey message is protected under KEK. > The first operation of any group member is to decrypt the message with > KEK. Then as part of KD payload processing the group member determines > the new key protecting rekey messages (KEK') from the LKH update arrays. > > The new proposed processing (for solutions 2 and 3) would be for the > group member to use KEK' to decrypt the TEK keys in the KD payload. In > this way, a group member who had been removed from the group would not > be able to gain the next set of TEK keys. > > This is a reasonable thing to do. But I'd like to get a sense from the > working group as to how comfortable they feel about making a change like > this after the protocol has finished working group last call. > > The difference between solutions 2 and 3 has to do with payload > processing. Solution 2 does not change the message structure, but may be > more difficult for an implementation. > > Thanks, > Brian > > Brian Weis wrote: > > >>One issue does warrant some discussion on this list. It has primarily to >>do with expelling group members when a group key management algorithm >>(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a >>KEK is used alone. >> >>Recall that a GROUPKEY-PUSH message is a single exchange sent to all >>group members (probably via multicast). It looks like this: >> >> Member GCKS or Delegate >> ------ ---------------- >> >> <---- HDR*, SEQ, SA, KD, [CERT,] SIG >> >>The entire message (following the *) is encrypted under the "current" >>KEK which is held by all group members. The SA payload may contain >>policy for a "new" KEK which will replace the existing KEK, and this >>replacement begins with the next GROUPKEY-PUSH message. If the SA >>payload has new KEK policy, then the KD payload will contain the new KEK >>keys. This is most likely the case where an LKH group membership key >>tree is used, so the KD payload will have several sets of key arrays >>which work together to provide a new KEK to group members who have not >>been expelled from the group. [See RFC 2627 for details.] >> >>Notice that the expelled group member will not be able to read the new >>KEK (that's the main property of a group management algorithm), but >>because he has possession of the "current" KEK and can decrypt and read >>the rest of the message. >> >>Now if someone has taken the trouble to expel one or more group members >>they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so >>that the expelled member can no longer participate in the group. For >>efficiency reasons it should be possible to send out the new TEK SAs in >>the same GROUPKEY-PUSH message in which the KEK is changed. The SA and >>KD payloads support this today. >> >>But here's the problem: Since the expelled group member has the >>"current" KEK and can read the entire message, he will be able to read >>the new TEK SAs and keys and thus won't be expelled from the group until >>the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message >>will be the first use of the new KEK. >> >>Here are some possibilities to resolve the issue in the draft: >> >>Solution 1: The simplest fix for this problem is to disallow sending of >>any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. >>Unfortunately, this disallows any possibility of efficient rekeys of >>group policy. This does have the advantage of being the most minimal >>change to the draft as it would simply add some MUST NOT statements. >> >>Solution 2: Leave the KD payload intact. That is, allow it to contain >>both the KEK and TEK keys. But require the TEK portion of the KD payload >>to be super-encrypted with the new KEK. This maintains efficiency, but >>requires extra processing to that portion of the KD payload which is >>super-encrypted. This is a minimal (but subtle) change to the >>GROUPKEY-PUSH protocol. However it does add substantial complexity to >>the construction and processing of the KD payload. >> >>Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one >>which would contain the KEK keys. The other would the TEK keys and be >>super-encrypted with the new KEK. This is the most change to the draft, >>but does provide the desired efficiency and is the cleanest overall >>design. >> >>I'd be interested at hearing opinions on the above solutions and/or >>alternate solutions. >> >>Thanks, >>Brian >> >>-- >>Brian Weis >>Strategic Cryptographic Development, ITD, Cisco Systems >>Telephone: +1 408 526 4796 >>Email: bew@cisco.com >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec >> > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 11:55:43 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18525 for ; Fri, 21 Jun 2002 11:55:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B4305537DA; Fri, 21 Jun 2002 11:27:26 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6B6D653599 for ; Fri, 21 Jun 2002 11:26:12 -0400 (EDT) Received: (qmail 1029 invoked by uid 3269); 21 Jun 2002 15:26:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1026 invoked from network); 21 Jun 2002 15:26:55 -0000 Received: from zcars04e.nortelnetworks.com (HELO zcars04e.ca.nortel.com) (47.129.242.56) by klesh.pair.com with SMTP; 21 Jun 2002 15:26:55 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5LFQA210640; Fri, 21 Jun 2002 11:26:10 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NGKKSXRV; Fri, 21 Jun 2002 11:26:09 -0400 Received: from nortelnetworks.com (lakshminath1.us.nortel.com [47.16.67.111]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N12LGRQ4; Fri, 21 Jun 2002 11:26:09 -0400 Message-ID: <3D134667.7060908@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Mark Baugher Cc: Brian Weis , msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <4.3.2.7.2.20020620100108.04993a58@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 11:29:43 -0400 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > > There is no IETF requirement > that we have interoperable implementations for a Proposed Standard. > Thanks to Brian and Lakshminath, we did have interoperable > implementations for the PULL (GKM Registration) exchange. I recall > that you discovered a problem with the PUSH (GKM Rekey) message as > soon as you implemented it. I expect that we'll discover more as > we get more implementation experience with LKH (e.g. two > interoperable implementations). Standards rules aside, an interoperability exercise and a protocol analysis similar to what Cathy Meadows did for GDOI, will help identity problems that we might otherwise overlook. This applies to LKH and similar algorithms, considering everyone has a different take on how to implement them. > I'm afraid that too many last-minute design decisions will > result in problems. I also think that GDOI is very useful > without LKH-like function. I think this is okay for the > Proposed Standard. > > regards, Mark > I agree with GDOI being useful without LKH scalability, and favor leaving it out of the spec and concentrate on getting the PUSH message right. Finally, I must note that Brian has put a lot of work into incorporating LKH into the GDOI draft. We could take one of the following many :-) routes: 1) Pull it out and start a separate draft on LKH ... n) Pull it out and start a separate draft on LKH n+1) Take the time to do a thorough review. Many of us implemented it at some level. It is time to put that experience to come up with a standard. cheers, Lakshminath PS: n is a large positive integer _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 11:58:09 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18771 for ; Fri, 21 Jun 2002 11:58:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 113DB53776; Fri, 21 Jun 2002 11:52:28 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DC0F2535EF for ; Fri, 21 Jun 2002 11:51:12 -0400 (EDT) Received: (qmail 3971 invoked by uid 3269); 21 Jun 2002 15:51:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3968 invoked from network); 21 Jun 2002 15:51:56 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 21 Jun 2002 15:51:56 -0000 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5LFpFBW005769; Fri, 21 Jun 2002 08:51:15 -0700 (PDT) Received: from cisco.com (stealth-10-34-255-60.cisco.com [10.34.255.60]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id IAA15304; Fri, 21 Jun 2002 08:51:13 -0700 (PDT) Message-ID: <3D134B6C.5DC13532@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lakshminath Dondeti Cc: msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <3D0FACB0.42A78E54@cisco.com> <3D10B4F7.7027A9B0@cisco.com> <3D133F33.3090008@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 08:51:08 -0700 Content-Transfer-Encoding: 7bit Hi Lakshminath, It's not really possible to keep the SA_KEK payload secret, because that policy is needed in order for a group member to use the KEK (including any LKH arrays) in the KD payload. :-) But I think you were asking about the SA_TEK payloads containing policy for the IPSec SAs. We don't have any mechanism today for keeping expelled group members from viewing the SA_TEK payloads. They will have access to the KEK which is used to decrypt the entire PUSH message. The only method I can think of for hiding them from expelled group members would be to send them in a separate PUSH message following the KEK change so that they are wholly encrypted under the new KEK. But I'm not convinced there's much risk to expelled group members from seeing the policy. The new SA policy is unlikely to change when replacement SAs are distributed. The new SPI values will be documented in the SA_TEKs, but then they'll also be in the clear when data traffic using those SPIs starts flowing too. If a group has a security policy which says that the policy must be kept secret, that policy can be easily accommodated by sending the SA_TEKs in a separate PUSH message from the SA_KEK. Do you see any other risk? Thanks, Brian Lakshminath Dondeti wrote: > > Brian, > > Would it be possible to keep the SA payload secret (to disallow > kickedout members from knowing policy changes), if necessary? > > cheers, > Lakshminath > > Brian Weis wrote: > > > Further clarification is needed since I wasn't very clear how Solutions > > 2 and 3 below would be implemented. > > > > As currently specified the entire rekey message is protected under KEK. > > The first operation of any group member is to decrypt the message with > > KEK. Then as part of KD payload processing the group member determines > > the new key protecting rekey messages (KEK') from the LKH update arrays. > > > > The new proposed processing (for solutions 2 and 3) would be for the > > group member to use KEK' to decrypt the TEK keys in the KD payload. In > > this way, a group member who had been removed from the group would not > > be able to gain the next set of TEK keys. > > > > This is a reasonable thing to do. But I'd like to get a sense from the > > working group as to how comfortable they feel about making a change like > > this after the protocol has finished working group last call. > > > > The difference between solutions 2 and 3 has to do with payload > > processing. Solution 2 does not change the message structure, but may be > > more difficult for an implementation. > > > > Thanks, > > Brian > > > > Brian Weis wrote: > > > > > >>One issue does warrant some discussion on this list. It has primarily to > >>do with expelling group members when a group key management algorithm > >>(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a > >>KEK is used alone. > >> > >>Recall that a GROUPKEY-PUSH message is a single exchange sent to all > >>group members (probably via multicast). It looks like this: > >> > >> Member GCKS or Delegate > >> ------ ---------------- > >> > >> <---- HDR*, SEQ, SA, KD, [CERT,] SIG > >> > >>The entire message (following the *) is encrypted under the "current" > >>KEK which is held by all group members. The SA payload may contain > >>policy for a "new" KEK which will replace the existing KEK, and this > >>replacement begins with the next GROUPKEY-PUSH message. If the SA > >>payload has new KEK policy, then the KD payload will contain the new KEK > >>keys. This is most likely the case where an LKH group membership key > >>tree is used, so the KD payload will have several sets of key arrays > >>which work together to provide a new KEK to group members who have not > >>been expelled from the group. [See RFC 2627 for details.] > >> > >>Notice that the expelled group member will not be able to read the new > >>KEK (that's the main property of a group management algorithm), but > >>because he has possession of the "current" KEK and can decrypt and read > >>the rest of the message. > >> > >>Now if someone has taken the trouble to expel one or more group members > >>they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so > >>that the expelled member can no longer participate in the group. For > >>efficiency reasons it should be possible to send out the new TEK SAs in > >>the same GROUPKEY-PUSH message in which the KEK is changed. The SA and > >>KD payloads support this today. > >> > >>But here's the problem: Since the expelled group member has the > >>"current" KEK and can read the entire message, he will be able to read > >>the new TEK SAs and keys and thus won't be expelled from the group until > >>the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message > >>will be the first use of the new KEK. > >> > >>Here are some possibilities to resolve the issue in the draft: > >> > >>Solution 1: The simplest fix for this problem is to disallow sending of > >>any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. > >>Unfortunately, this disallows any possibility of efficient rekeys of > >>group policy. This does have the advantage of being the most minimal > >>change to the draft as it would simply add some MUST NOT statements. > >> > >>Solution 2: Leave the KD payload intact. That is, allow it to contain > >>both the KEK and TEK keys. But require the TEK portion of the KD payload > >>to be super-encrypted with the new KEK. This maintains efficiency, but > >>requires extra processing to that portion of the KD payload which is > >>super-encrypted. This is a minimal (but subtle) change to the > >>GROUPKEY-PUSH protocol. However it does add substantial complexity to > >>the construction and processing of the KD payload. > >> > >>Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one > >>which would contain the KEK keys. The other would the TEK keys and be > >>super-encrypted with the new KEK. This is the most change to the draft, > >>but does provide the desired efficiency and is the cleanest overall > >>design. > >> > >>I'd be interested at hearing opinions on the above solutions and/or > >>alternate solutions. > >> > >>Thanks, > >>Brian > >> > >>-- > >>Brian Weis > >>Strategic Cryptographic Development, ITD, Cisco Systems > >>Telephone: +1 408 526 4796 > >>Email: bew@cisco.com > >> > >>_______________________________________________ > >>msec mailing list > >>msec@securemulticast.org > >>http://www.pairlist.net/mailman/listinfo/msec > >> > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 11:58:41 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18802 for ; Fri, 21 Jun 2002 11:58:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 21E9A536A4; Fri, 21 Jun 2002 11:58:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 53DA853619 for ; Fri, 21 Jun 2002 11:57:11 -0400 (EDT) Received: (qmail 4511 invoked by uid 3269); 21 Jun 2002 15:57:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4505 invoked from network); 21 Jun 2002 15:57:53 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 21 Jun 2002 15:57:53 -0000 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5LFvML0023995; Fri, 21 Jun 2002 08:57:22 -0700 (PDT) Received: from cisco.com (stealth-10-34-255-60.cisco.com [10.34.255.60]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id IAA19684; Fri, 21 Jun 2002 08:57:21 -0700 (PDT) Message-ID: <3D134CE0.E4AC868F@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <4.3.2.7.2.20020620100108.04993a58@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 08:57:20 -0700 Content-Transfer-Encoding: 7bit Mark Baugher wrote: > > >Solution 1: The simplest fix for this problem is to disallow sending of > >any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. > >Unfortunately, this disallows any possibility of efficient rekeys of > >group policy. This does have the advantage of being the most minimal > >change to the draft as it would simply add some MUST NOT statements. > > I favor this solution although it is arguably broken. The > reason I favor a broken solution is that we don't yet have > enough implementation experience. We discussed this problem > at length at the start of WG Last Call. There is no IETF requirement > that we have interoperable implementations for a Proposed Standard. > Thanks to Brian and Lakshminath, we did have interoperable > implementations for the PULL (GKM Registration) exchange. I recall > that you discovered a problem with the PUSH (GKM Rekey) message as > soon as you implemented it. I expect that we'll discover more as > we get more implementation experience with LKH (e.g. two > interoperable implementations). > > I'm afraid that too many last-minute design decisions will > result in problems. I also think that GDOI is very useful > without LKH-like function. I think this is okay for the > Proposed Standard. I need to clarify that Solution 1 does NOT propose removing LKH. It proposes forcing changes of the LKH KEK to be isolated into its own PUSH message, which is a very small change to the existing draft. Removing LKH would be a relatively large change to the draft. Brian > regards, Mark -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 13:01:58 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22300 for ; Fri, 21 Jun 2002 13:01:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0B860535BE; Fri, 21 Jun 2002 13:01:24 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4BC5E5359A for ; Fri, 21 Jun 2002 13:00:01 -0400 (EDT) Received: (qmail 12929 invoked by uid 3269); 21 Jun 2002 17:00:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12926 invoked from network); 21 Jun 2002 17:00:45 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 21 Jun 2002 17:00:45 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5LGxkAB016670; Fri, 21 Jun 2002 09:59:46 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABX00753; Fri, 21 Jun 2002 09:57:57 -0700 (PDT) Message-Id: <4.3.2.7.2.20020621095741.04a39cd0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Brian Weis From: Mark Baugher Subject: Re: [MSEC] Next GDOI draft Cc: msec@securemulticast.org In-Reply-To: <3D134CE0.E4AC868F@cisco.com> References: <4.3.2.7.2.20020620100108.04993a58@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 09:58:12 -0700 Brian I understand that you want to minimize refinement of LKH in the draft and not eliminate LKH from the draft. Mark At 08:57 AM 6/21/2002 -0700, Brian Weis wrote: >Mark Baugher wrote: > > > > > >Solution 1: The simplest fix for this problem is to disallow sending of > > >any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. > > >Unfortunately, this disallows any possibility of efficient rekeys of > > >group policy. This does have the advantage of being the most minimal > > >change to the draft as it would simply add some MUST NOT statements. > > > > I favor this solution although it is arguably broken. The > > reason I favor a broken solution is that we don't yet have > > enough implementation experience. We discussed this problem > > at length at the start of WG Last Call. There is no IETF requirement > > that we have interoperable implementations for a Proposed Standard. > > Thanks to Brian and Lakshminath, we did have interoperable > > implementations for the PULL (GKM Registration) exchange. I recall > > that you discovered a problem with the PUSH (GKM Rekey) message as > > soon as you implemented it. I expect that we'll discover more as > > we get more implementation experience with LKH (e.g. two > > interoperable implementations). > > > > I'm afraid that too many last-minute design decisions will > > result in problems. I also think that GDOI is very useful > > without LKH-like function. I think this is okay for the > > Proposed Standard. > >I need to clarify that Solution 1 does NOT propose removing LKH. It >proposes forcing changes of the LKH KEK to be isolated into its own PUSH >message, which is a very small change to the existing draft. Removing >LKH would be a relatively large change to the draft. > >Brian > > > regards, Mark > >-- >Brian Weis >Strategic Cryptographic Development, ITD, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 13:37:28 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23872 for ; Fri, 21 Jun 2002 13:37:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E784653823; Fri, 21 Jun 2002 13:36:42 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5F59653808 for ; Fri, 21 Jun 2002 13:35:59 -0400 (EDT) Received: (qmail 24626 invoked by uid 3269); 21 Jun 2002 17:36:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24579 invoked from network); 21 Jun 2002 17:36:38 -0000 Received: from zcars04f.nortelnetworks.com (HELO zcars04f.ca.nortel.com) (47.129.242.57) by klesh.pair.com with SMTP; 21 Jun 2002 17:36:38 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5LHZwv18187; Fri, 21 Jun 2002 13:35:59 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NGKKSYTS; Fri, 21 Jun 2002 13:35:58 -0400 Received: from nortelnetworks.com (lakshminath1.us.nortel.com [47.16.67.111]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N12LGRYV; Fri, 21 Jun 2002 13:35:58 -0400 Message-ID: <3D1364D1.40706@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Brian Weis Cc: "Lakshminath Dondeti" , msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <3D0FACB0.42A78E54@cisco.com> <3D10B4F7.7027A9B0@cisco.com> <3D133F33.3090008@nortelnetworks.com> <3D134B6C.5DC13532@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 13:39:29 -0400 Content-Transfer-Encoding: 7bit Brian, Securing SAKEK or SATEK policy, or the GSPT may be a requirement for some applications. The solution (sending policy twice) could be confusing and must be stated either in the PUSH message description, or in the Security Considerations section. Thanks. best, Lakshminath Brian Weis wrote: > Hi Lakshminath, > > It's not really possible to keep the SA_KEK payload secret, because that > policy is needed in order for a group member to use the KEK (including > any LKH arrays) in the KD payload. :-) > > But I think you were asking about the SA_TEK payloads containing policy > for the IPSec SAs. We don't have any mechanism today for keeping > expelled group members from viewing the SA_TEK payloads. They will have > access to the KEK which is used to decrypt the entire PUSH message. The > only method I can think of for hiding them from expelled group members > would be to send them in a separate PUSH message following the KEK > change so that they are wholly encrypted under the new KEK. > > But I'm not convinced there's much risk to expelled group members from > seeing the policy. The new SA policy is unlikely to change when > replacement SAs are distributed. The new SPI values will be documented > in the SA_TEKs, but then they'll also be in the clear when data traffic > using those SPIs starts flowing too. If a group has a security policy > which says that the policy must be kept secret, that policy can be > easily accommodated by sending the SA_TEKs in a separate PUSH message > from the SA_KEK. > > Do you see any other risk? > > Thanks, > Brian > > Lakshminath Dondeti wrote: > >>Brian, >> >>Would it be possible to keep the SA payload secret (to disallow >>kickedout members from knowing policy changes), if necessary? >> >>cheers, >>Lakshminath >> >>Brian Weis wrote: >> >> >>>Further clarification is needed since I wasn't very clear how Solutions >>>2 and 3 below would be implemented. >>> >>>As currently specified the entire rekey message is protected under KEK. >>>The first operation of any group member is to decrypt the message with >>>KEK. Then as part of KD payload processing the group member determines >>>the new key protecting rekey messages (KEK') from the LKH update arrays. >>> >>>The new proposed processing (for solutions 2 and 3) would be for the >>>group member to use KEK' to decrypt the TEK keys in the KD payload. In >>>this way, a group member who had been removed from the group would not >>>be able to gain the next set of TEK keys. >>> >>>This is a reasonable thing to do. But I'd like to get a sense from the >>>working group as to how comfortable they feel about making a change like >>>this after the protocol has finished working group last call. >>> >>>The difference between solutions 2 and 3 has to do with payload >>>processing. Solution 2 does not change the message structure, but may be >>>more difficult for an implementation. >>> >>>Thanks, >>>Brian >>> >>>Brian Weis wrote: >>> >>> >>> >>>>One issue does warrant some discussion on this list. It has primarily to >>>>do with expelling group members when a group key management algorithm >>>>(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a >>>>KEK is used alone. >>>> >>>>Recall that a GROUPKEY-PUSH message is a single exchange sent to all >>>>group members (probably via multicast). It looks like this: >>>> >>>> Member GCKS or Delegate >>>> ------ ---------------- >>>> >>>> <---- HDR*, SEQ, SA, KD, [CERT,] SIG >>>> >>>>The entire message (following the *) is encrypted under the "current" >>>>KEK which is held by all group members. The SA payload may contain >>>>policy for a "new" KEK which will replace the existing KEK, and this >>>>replacement begins with the next GROUPKEY-PUSH message. If the SA >>>>payload has new KEK policy, then the KD payload will contain the new KEK >>>>keys. This is most likely the case where an LKH group membership key >>>>tree is used, so the KD payload will have several sets of key arrays >>>>which work together to provide a new KEK to group members who have not >>>>been expelled from the group. [See RFC 2627 for details.] >>>> >>>>Notice that the expelled group member will not be able to read the new >>>>KEK (that's the main property of a group management algorithm), but >>>>because he has possession of the "current" KEK and can decrypt and read >>>>the rest of the message. >>>> >>>>Now if someone has taken the trouble to expel one or more group members >>>>they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so >>>>that the expelled member can no longer participate in the group. For >>>>efficiency reasons it should be possible to send out the new TEK SAs in >>>>the same GROUPKEY-PUSH message in which the KEK is changed. The SA and >>>>KD payloads support this today. >>>> >>>>But here's the problem: Since the expelled group member has the >>>>"current" KEK and can read the entire message, he will be able to read >>>>the new TEK SAs and keys and thus won't be expelled from the group until >>>>the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message >>>>will be the first use of the new KEK. >>>> >>>>Here are some possibilities to resolve the issue in the draft: >>>> >>>>Solution 1: The simplest fix for this problem is to disallow sending of >>>>any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. >>>>Unfortunately, this disallows any possibility of efficient rekeys of >>>>group policy. This does have the advantage of being the most minimal >>>>change to the draft as it would simply add some MUST NOT statements. >>>> >>>>Solution 2: Leave the KD payload intact. That is, allow it to contain >>>>both the KEK and TEK keys. But require the TEK portion of the KD payload >>>>to be super-encrypted with the new KEK. This maintains efficiency, but >>>>requires extra processing to that portion of the KD payload which is >>>>super-encrypted. This is a minimal (but subtle) change to the >>>>GROUPKEY-PUSH protocol. However it does add substantial complexity to >>>>the construction and processing of the KD payload. >>>> >>>>Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one >>>>which would contain the KEK keys. The other would the TEK keys and be >>>>super-encrypted with the new KEK. This is the most change to the draft, >>>>but does provide the desired efficiency and is the cleanest overall >>>>design. >>>> >>>>I'd be interested at hearing opinions on the above solutions and/or >>>>alternate solutions. >>>> >>>>Thanks, >>>>Brian >>>> >>>>-- >>>>Brian Weis >>>>Strategic Cryptographic Development, ITD, Cisco Systems >>>>Telephone: +1 408 526 4796 >>>>Email: bew@cisco.com >>>> >>>>_______________________________________________ >>>>msec mailing list >>>>msec@securemulticast.org >>>>http://www.pairlist.net/mailman/listinfo/msec >>>> >>>> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec >> > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 13:56:43 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24644 for ; Fri, 21 Jun 2002 13:56:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C3A6F537C0; Fri, 21 Jun 2002 13:56:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3B33C53779 for ; Fri, 21 Jun 2002 13:55:06 -0400 (EDT) Received: (qmail 27690 invoked by uid 3269); 21 Jun 2002 17:55:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 27687 invoked from network); 21 Jun 2002 17:55:50 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 21 Jun 2002 17:55:50 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5LHtDdg008987; Fri, 21 Jun 2002 10:55:13 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABX02309; Fri, 21 Jun 2002 10:53:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20020621105156.04becc68@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] Next GDOI draft Cc: Brian Weis , "Lakshminath Dondeti" , msec@securemulticast.org In-Reply-To: <3D1364D1.40706@nortelnetworks.com> References: <3D0FACB0.42A78E54@cisco.com> <3D10B4F7.7027A9B0@cisco.com> <3D133F33.3090008@nortelnetworks.com> <3D134B6C.5DC13532@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 10:53:18 -0700 hi Lakshminath, At 01:39 PM 6/21/2002 -0400, Lakshminath Dondeti wrote: >Brian, > >Securing SAKEK or SATEK policy, or the GSPT may be a requirement for some >applications. If we try to solve the security problems of all actual and potential applications, we'll have a protocol that is too complex for most applications. ISAKMP is complex enough and so is its GDOI. thanks, Mark >The solution (sending policy twice) could be confusing and must be stated >either in the PUSH message description, or in the Security Considerations >section. Thanks. > >best, >Lakshminath > >Brian Weis wrote: > >>Hi Lakshminath, >>It's not really possible to keep the SA_KEK payload secret, because that >>policy is needed in order for a group member to use the KEK (including >>any LKH arrays) in the KD payload. :-) >>But I think you were asking about the SA_TEK payloads containing policy >>for the IPSec SAs. We don't have any mechanism today for keeping >>expelled group members from viewing the SA_TEK payloads. They will have >>access to the KEK which is used to decrypt the entire PUSH message. The >>only method I can think of for hiding them from expelled group members >>would be to send them in a separate PUSH message following the KEK >>change so that they are wholly encrypted under the new KEK. >>But I'm not convinced there's much risk to expelled group members from >>seeing the policy. The new SA policy is unlikely to change when >>replacement SAs are distributed. The new SPI values will be documented >>in the SA_TEKs, but then they'll also be in the clear when data traffic >>using those SPIs starts flowing too. If a group has a security policy >>which says that the policy must be kept secret, that policy can be >>easily accommodated by sending the SA_TEKs in a separate PUSH message >>from the SA_KEK. >>Do you see any other risk? >>Thanks, >>Brian >>Lakshminath Dondeti wrote: >> >>>Brian, >>> >>>Would it be possible to keep the SA payload secret (to disallow >>>kickedout members from knowing policy changes), if necessary? >>> >>>cheers, >>>Lakshminath >>> >>>Brian Weis wrote: >>> >>> >>>>Further clarification is needed since I wasn't very clear how Solutions >>>>2 and 3 below would be implemented. >>>> >>>>As currently specified the entire rekey message is protected under KEK. >>>>The first operation of any group member is to decrypt the message with >>>>KEK. Then as part of KD payload processing the group member determines >>>>the new key protecting rekey messages (KEK') from the LKH update arrays. >>>> >>>>The new proposed processing (for solutions 2 and 3) would be for the >>>>group member to use KEK' to decrypt the TEK keys in the KD payload. In >>>>this way, a group member who had been removed from the group would not >>>>be able to gain the next set of TEK keys. >>>> >>>>This is a reasonable thing to do. But I'd like to get a sense from the >>>>working group as to how comfortable they feel about making a change like >>>>this after the protocol has finished working group last call. >>>> >>>>The difference between solutions 2 and 3 has to do with payload >>>>processing. Solution 2 does not change the message structure, but may be >>>>more difficult for an implementation. >>>> >>>>Thanks, >>>>Brian >>>> >>>>Brian Weis wrote: >>>> >>>> >>>> >>>>>One issue does warrant some discussion on this list. It has primarily to >>>>>do with expelling group members when a group key management algorithm >>>>>(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a >>>>>KEK is used alone. >>>>> >>>>>Recall that a GROUPKEY-PUSH message is a single exchange sent to all >>>>>group members (probably via multicast). It looks like this: >>>>> >>>>> Member GCKS or Delegate >>>>> ------ ---------------- >>>>> >>>>> <---- HDR*, SEQ, SA, KD, [CERT,] SIG >>>>> >>>>>The entire message (following the *) is encrypted under the "current" >>>>>KEK which is held by all group members. The SA payload may contain >>>>>policy for a "new" KEK which will replace the existing KEK, and this >>>>>replacement begins with the next GROUPKEY-PUSH message. If the SA >>>>>payload has new KEK policy, then the KD payload will contain the new KEK >>>>>keys. This is most likely the case where an LKH group membership key >>>>>tree is used, so the KD payload will have several sets of key arrays >>>>>which work together to provide a new KEK to group members who have not >>>>>been expelled from the group. [See RFC 2627 for details.] >>>>> >>>>>Notice that the expelled group member will not be able to read the new >>>>>KEK (that's the main property of a group management algorithm), but >>>>>because he has possession of the "current" KEK and can decrypt and read >>>>>the rest of the message. >>>>> >>>>>Now if someone has taken the trouble to expel one or more group members >>>>>they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so >>>>>that the expelled member can no longer participate in the group. For >>>>>efficiency reasons it should be possible to send out the new TEK SAs in >>>>>the same GROUPKEY-PUSH message in which the KEK is changed. The SA and >>>>>KD payloads support this today. >>>>> >>>>>But here's the problem: Since the expelled group member has the >>>>>"current" KEK and can read the entire message, he will be able to read >>>>>the new TEK SAs and keys and thus won't be expelled from the group until >>>>>the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message >>>>>will be the first use of the new KEK. >>>>> >>>>>Here are some possibilities to resolve the issue in the draft: >>>>> >>>>>Solution 1: The simplest fix for this problem is to disallow sending of >>>>>any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. >>>>>Unfortunately, this disallows any possibility of efficient rekeys of >>>>>group policy. This does have the advantage of being the most minimal >>>>>change to the draft as it would simply add some MUST NOT statements. >>>>> >>>>>Solution 2: Leave the KD payload intact. That is, allow it to contain >>>>>both the KEK and TEK keys. But require the TEK portion of the KD payload >>>>>to be super-encrypted with the new KEK. This maintains efficiency, but >>>>>requires extra processing to that portion of the KD payload which is >>>>>super-encrypted. This is a minimal (but subtle) change to the >>>>>GROUPKEY-PUSH protocol. However it does add substantial complexity to >>>>>the construction and processing of the KD payload. >>>>> >>>>>Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one >>>>>which would contain the KEK keys. The other would the TEK keys and be >>>>>super-encrypted with the new KEK. This is the most change to the draft, >>>>>but does provide the desired efficiency and is the cleanest overall >>>>>design. >>>>> >>>>>I'd be interested at hearing opinions on the above solutions and/or >>>>>alternate solutions. >>>>> >>>>>Thanks, >>>>>Brian >>>>> >>>>>-- >>>>>Brian Weis >>>>>Strategic Cryptographic Development, ITD, Cisco Systems >>>>>Telephone: +1 408 526 4796 >>>>>Email: bew@cisco.com >>>>> >>>>>_______________________________________________ >>>>>msec mailing list >>>>>msec@securemulticast.org >>>>>http://www.pairlist.net/mailman/listinfo/msec >>>>> >>>_______________________________________________ >>>msec mailing list >>>msec@securemulticast.org >>>http://www.pairlist.net/mailman/listinfo/msec > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 14:13:41 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25396 for ; Fri, 21 Jun 2002 14:13:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C2618538AE; Fri, 21 Jun 2002 14:09:34 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id BB41153886 for ; Fri, 21 Jun 2002 14:07:23 -0400 (EDT) Received: (qmail 28836 invoked by uid 3269); 21 Jun 2002 18:08:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28833 invoked from network); 21 Jun 2002 18:08:07 -0000 Received: from zcars04e.nortelnetworks.com (HELO zcars04e.ca.nortel.com) (47.129.242.56) by klesh.pair.com with SMTP; 21 Jun 2002 18:08:07 -0000 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5LI7M206621; Fri, 21 Jun 2002 14:07:22 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFR0XKJL; Fri, 21 Jun 2002 14:07:22 -0400 Received: from nortelnetworks.com (lakshminath1.us.nortel.com [47.16.67.111]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N12LGR68; Fri, 21 Jun 2002 14:07:21 -0400 Message-ID: <3D136C2C.6020108@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Mark Baugher Cc: "Lakshminath Dondeti" , Brian Weis , msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <3D0FACB0.42A78E54@cisco.com> <3D10B4F7.7027A9B0@cisco.com> <3D133F33.3090008@nortelnetworks.com> <3D134B6C.5DC13532@cisco.com> <4.3.2.7.2.20020621105156.04becc68@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 14:10:52 -0400 Content-Transfer-Encoding: 7bit Mark, I understand that, and my point is it is ok to not support a potential security requirement, but that should be made clear in the Security Considerations section. It turns out that GDOI can do it (I think) with an extra PUSH message. cheers, Lakshminath Mark Baugher wrote: > hi Lakshminath, > > At 01:39 PM 6/21/2002 -0400, Lakshminath Dondeti wrote: > >> Brian, >> >> Securing SAKEK or SATEK policy, or the GSPT may be a requirement for >> some applications. > > > If we try to solve the security problems of all actual > and potential applications, we'll have a protocol that > is too complex for most applications. ISAKMP is > complex enough and so is its GDOI. > > thanks, Mark > > >> The solution (sending policy twice) could be confusing and must be >> stated either in the PUSH message description, or in the Security >> Considerations section. Thanks. >> >> best, >> Lakshminath >> >> Brian Weis wrote: >> >>> Hi Lakshminath, >>> It's not really possible to keep the SA_KEK payload secret, because that >>> policy is needed in order for a group member to use the KEK (including >>> any LKH arrays) in the KD payload. :-) >>> But I think you were asking about the SA_TEK payloads containing policy >>> for the IPSec SAs. We don't have any mechanism today for keeping >>> expelled group members from viewing the SA_TEK payloads. They will have >>> access to the KEK which is used to decrypt the entire PUSH message. The >>> only method I can think of for hiding them from expelled group members >>> would be to send them in a separate PUSH message following the KEK >>> change so that they are wholly encrypted under the new KEK. >>> But I'm not convinced there's much risk to expelled group members from >>> seeing the policy. The new SA policy is unlikely to change when >>> replacement SAs are distributed. The new SPI values will be documented >>> in the SA_TEKs, but then they'll also be in the clear when data traffic >>> using those SPIs starts flowing too. If a group has a security policy >>> which says that the policy must be kept secret, that policy can be >>> easily accommodated by sending the SA_TEKs in a separate PUSH message >>> from the SA_KEK. >>> Do you see any other risk? >>> Thanks, >>> Brian >>> Lakshminath Dondeti wrote: >>> >>>> Brian, >>>> >>>> Would it be possible to keep the SA payload secret (to disallow >>>> kickedout members from knowing policy changes), if necessary? >>>> >>>> cheers, >>>> Lakshminath >>>> >>>> Brian Weis wrote: >>>> >>>> >>>>> Further clarification is needed since I wasn't very clear how >>>>> Solutions >>>>> 2 and 3 below would be implemented. >>>>> >>>>> As currently specified the entire rekey message is protected under >>>>> KEK. >>>>> The first operation of any group member is to decrypt the message with >>>>> KEK. Then as part of KD payload processing the group member determines >>>>> the new key protecting rekey messages (KEK') from the LKH update >>>>> arrays. >>>>> >>>>> The new proposed processing (for solutions 2 and 3) would be for the >>>>> group member to use KEK' to decrypt the TEK keys in the KD payload. In >>>>> this way, a group member who had been removed from the group would not >>>>> be able to gain the next set of TEK keys. >>>>> >>>>> This is a reasonable thing to do. But I'd like to get a sense from the >>>>> working group as to how comfortable they feel about making a change >>>>> like >>>>> this after the protocol has finished working group last call. >>>>> >>>>> The difference between solutions 2 and 3 has to do with payload >>>>> processing. Solution 2 does not change the message structure, but >>>>> may be >>>>> more difficult for an implementation. >>>>> >>>>> Thanks, >>>>> Brian >>>>> >>>>> Brian Weis wrote: >>>>> >>>>> >>>>> >>>>>> One issue does warrant some discussion on this list. It has >>>>>> primarily to >>>>>> do with expelling group members when a group key management algorithm >>>>>> (e.g., LKH) is used with a KEK. It is also somewhat of an issue >>>>>> when a >>>>>> KEK is used alone. >>>>>> >>>>>> Recall that a GROUPKEY-PUSH message is a single exchange sent to all >>>>>> group members (probably via multicast). It looks like this: >>>>>> >>>>>> Member GCKS or Delegate >>>>>> ------ ---------------- >>>>>> >>>>>> <---- HDR*, SEQ, SA, KD, [CERT,] SIG >>>>>> >>>>>> The entire message (following the *) is encrypted under the "current" >>>>>> KEK which is held by all group members. The SA payload may contain >>>>>> policy for a "new" KEK which will replace the existing KEK, and this >>>>>> replacement begins with the next GROUPKEY-PUSH message. If the SA >>>>>> payload has new KEK policy, then the KD payload will contain the >>>>>> new KEK >>>>>> keys. This is most likely the case where an LKH group membership key >>>>>> tree is used, so the KD payload will have several sets of key arrays >>>>>> which work together to provide a new KEK to group members who have >>>>>> not >>>>>> been expelled from the group. [See RFC 2627 for details.] >>>>>> >>>>>> Notice that the expelled group member will not be able to read the >>>>>> new >>>>>> KEK (that's the main property of a group management algorithm), but >>>>>> because he has possession of the "current" KEK and can decrypt and >>>>>> read >>>>>> the rest of the message. >>>>>> >>>>>> Now if someone has taken the trouble to expel one or more group >>>>>> members >>>>>> they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so >>>>>> that the expelled member can no longer participate in the group. For >>>>>> efficiency reasons it should be possible to send out the new TEK >>>>>> SAs in >>>>>> the same GROUPKEY-PUSH message in which the KEK is changed. The SA >>>>>> and >>>>>> KD payloads support this today. >>>>>> >>>>>> But here's the problem: Since the expelled group member has the >>>>>> "current" KEK and can read the entire message, he will be able to >>>>>> read >>>>>> the new TEK SAs and keys and thus won't be expelled from the group >>>>>> until >>>>>> the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message >>>>>> will be the first use of the new KEK. >>>>>> >>>>>> Here are some possibilities to resolve the issue in the draft: >>>>>> >>>>>> Solution 1: The simplest fix for this problem is to disallow >>>>>> sending of >>>>>> any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. >>>>>> Unfortunately, this disallows any possibility of efficient rekeys of >>>>>> group policy. This does have the advantage of being the most minimal >>>>>> change to the draft as it would simply add some MUST NOT statements. >>>>>> >>>>>> Solution 2: Leave the KD payload intact. That is, allow it to contain >>>>>> both the KEK and TEK keys. But require the TEK portion of the KD >>>>>> payload >>>>>> to be super-encrypted with the new KEK. This maintains efficiency, >>>>>> but >>>>>> requires extra processing to that portion of the KD payload which is >>>>>> super-encrypted. This is a minimal (but subtle) change to the >>>>>> GROUPKEY-PUSH protocol. However it does add substantial complexity to >>>>>> the construction and processing of the KD payload. >>>>>> >>>>>> Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one >>>>>> which would contain the KEK keys. The other would the TEK keys and be >>>>>> super-encrypted with the new KEK. This is the most change to the >>>>>> draft, >>>>>> but does provide the desired efficiency and is the cleanest overall >>>>>> design. >>>>>> >>>>>> I'd be interested at hearing opinions on the above solutions and/or >>>>>> alternate solutions. >>>>>> >>>>>> Thanks, >>>>>> Brian >>>>>> >>>>>> -- >>>>>> Brian Weis >>>>>> Strategic Cryptographic Development, ITD, Cisco Systems >>>>>> Telephone: +1 408 526 4796 >>>>>> Email: bew@cisco.com >>>>>> >>>>>> _______________________________________________ >>>>>> msec mailing list >>>>>> msec@securemulticast.org >>>>>> http://www.pairlist.net/mailman/listinfo/msec >>>>>> >>>> _______________________________________________ >>>> msec mailing list >>>> msec@securemulticast.org >>>> http://www.pairlist.net/mailman/listinfo/msec >>> >> >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 14:17:37 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25623 for ; Fri, 21 Jun 2002 14:17:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7F5BD538B7; Fri, 21 Jun 2002 14:10:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 481975388D for ; Fri, 21 Jun 2002 14:08:05 -0400 (EDT) Received: (qmail 28866 invoked by uid 3269); 21 Jun 2002 18:08:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28863 invoked from network); 21 Jun 2002 18:08:49 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 21 Jun 2002 18:08:49 -0000 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5LI68BW008464; Fri, 21 Jun 2002 11:06:08 -0700 (PDT) Received: from cisco.com (dhcp-128-107-212-74.cisco.com [128.107.212.74]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA10401; Fri, 21 Jun 2002 11:06:02 -0700 (PDT) Message-ID: <3D136B0A.1FB1A9CF@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lakshminath Dondeti Cc: msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <3D0FACB0.42A78E54@cisco.com> <3D10B4F7.7027A9B0@cisco.com> <3D133F33.3090008@nortelnetworks.com> <3D134B6C.5DC13532@cisco.com> <3D1364D1.40706@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 11:06:02 -0700 Content-Transfer-Encoding: 7bit Hi Lakshminath, Lakshminath Dondeti wrote: > > Brian, > > Securing SAKEK or SATEK policy, or the GSPT may be a requirement for > some applications. The only way to secure the SAKEK would be to force all authorized group members to re-register via a PULL message. We can note this in the Security Considerations. > The solution (sending policy twice) could be confusing and must be > stated either in the PUSH message description, or in the Security > Considerations section. Thanks. Just to clarify my point earlier, the no single policy is actually sent twice -- the KEK keys/policy is just split from the TEK keys/policy. There are two independent PUSH messages. But I agree that it warrants discussion in the Security Considerations too. Thanks, Brian > best, > Lakshminath > > Brian Weis wrote: > > > Hi Lakshminath, > > > > It's not really possible to keep the SA_KEK payload secret, because that > > policy is needed in order for a group member to use the KEK (including > > any LKH arrays) in the KD payload. :-) > > > > But I think you were asking about the SA_TEK payloads containing policy > > for the IPSec SAs. We don't have any mechanism today for keeping > > expelled group members from viewing the SA_TEK payloads. They will have > > access to the KEK which is used to decrypt the entire PUSH message. The > > only method I can think of for hiding them from expelled group members > > would be to send them in a separate PUSH message following the KEK > > change so that they are wholly encrypted under the new KEK. > > > > But I'm not convinced there's much risk to expelled group members from > > seeing the policy. The new SA policy is unlikely to change when > > replacement SAs are distributed. The new SPI values will be documented > > in the SA_TEKs, but then they'll also be in the clear when data traffic > > using those SPIs starts flowing too. If a group has a security policy > > which says that the policy must be kept secret, that policy can be > > easily accommodated by sending the SA_TEKs in a separate PUSH message > > from the SA_KEK. > > > > Do you see any other risk? > > > > Thanks, > > Brian > > > > Lakshminath Dondeti wrote: > > > >>Brian, > >> > >>Would it be possible to keep the SA payload secret (to disallow > >>kickedout members from knowing policy changes), if necessary? > >> > >>cheers, > >>Lakshminath > >> > >>Brian Weis wrote: > >> > >> > >>>Further clarification is needed since I wasn't very clear how Solutions > >>>2 and 3 below would be implemented. > >>> > >>>As currently specified the entire rekey message is protected under KEK. > >>>The first operation of any group member is to decrypt the message with > >>>KEK. Then as part of KD payload processing the group member determines > >>>the new key protecting rekey messages (KEK') from the LKH update arrays. > >>> > >>>The new proposed processing (for solutions 2 and 3) would be for the > >>>group member to use KEK' to decrypt the TEK keys in the KD payload. In > >>>this way, a group member who had been removed from the group would not > >>>be able to gain the next set of TEK keys. > >>> > >>>This is a reasonable thing to do. But I'd like to get a sense from the > >>>working group as to how comfortable they feel about making a change like > >>>this after the protocol has finished working group last call. > >>> > >>>The difference between solutions 2 and 3 has to do with payload > >>>processing. Solution 2 does not change the message structure, but may be > >>>more difficult for an implementation. > >>> > >>>Thanks, > >>>Brian > >>> > >>>Brian Weis wrote: > >>> > >>> > >>> > >>>>One issue does warrant some discussion on this list. It has primarily to > >>>>do with expelling group members when a group key management algorithm > >>>>(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a > >>>>KEK is used alone. > >>>> > >>>>Recall that a GROUPKEY-PUSH message is a single exchange sent to all > >>>>group members (probably via multicast). It looks like this: > >>>> > >>>> Member GCKS or Delegate > >>>> ------ ---------------- > >>>> > >>>> <---- HDR*, SEQ, SA, KD, [CERT,] SIG > >>>> > >>>>The entire message (following the *) is encrypted under the "current" > >>>>KEK which is held by all group members. The SA payload may contain > >>>>policy for a "new" KEK which will replace the existing KEK, and this > >>>>replacement begins with the next GROUPKEY-PUSH message. If the SA > >>>>payload has new KEK policy, then the KD payload will contain the new KEK > >>>>keys. This is most likely the case where an LKH group membership key > >>>>tree is used, so the KD payload will have several sets of key arrays > >>>>which work together to provide a new KEK to group members who have not > >>>>been expelled from the group. [See RFC 2627 for details.] > >>>> > >>>>Notice that the expelled group member will not be able to read the new > >>>>KEK (that's the main property of a group management algorithm), but > >>>>because he has possession of the "current" KEK and can decrypt and read > >>>>the rest of the message. > >>>> > >>>>Now if someone has taken the trouble to expel one or more group members > >>>>they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so > >>>>that the expelled member can no longer participate in the group. For > >>>>efficiency reasons it should be possible to send out the new TEK SAs in > >>>>the same GROUPKEY-PUSH message in which the KEK is changed. The SA and > >>>>KD payloads support this today. > >>>> > >>>>But here's the problem: Since the expelled group member has the > >>>>"current" KEK and can read the entire message, he will be able to read > >>>>the new TEK SAs and keys and thus won't be expelled from the group until > >>>>the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message > >>>>will be the first use of the new KEK. > >>>> > >>>>Here are some possibilities to resolve the issue in the draft: > >>>> > >>>>Solution 1: The simplest fix for this problem is to disallow sending of > >>>>any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. > >>>>Unfortunately, this disallows any possibility of efficient rekeys of > >>>>group policy. This does have the advantage of being the most minimal > >>>>change to the draft as it would simply add some MUST NOT statements. > >>>> > >>>>Solution 2: Leave the KD payload intact. That is, allow it to contain > >>>>both the KEK and TEK keys. But require the TEK portion of the KD payload > >>>>to be super-encrypted with the new KEK. This maintains efficiency, but > >>>>requires extra processing to that portion of the KD payload which is > >>>>super-encrypted. This is a minimal (but subtle) change to the > >>>>GROUPKEY-PUSH protocol. However it does add substantial complexity to > >>>>the construction and processing of the KD payload. > >>>> > >>>>Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one > >>>>which would contain the KEK keys. The other would the TEK keys and be > >>>>super-encrypted with the new KEK. This is the most change to the draft, > >>>>but does provide the desired efficiency and is the cleanest overall > >>>>design. > >>>> > >>>>I'd be interested at hearing opinions on the above solutions and/or > >>>>alternate solutions. > >>>> > >>>>Thanks, > >>>>Brian > >>>> > >>>>-- > >>>>Brian Weis > >>>>Strategic Cryptographic Development, ITD, Cisco Systems > >>>>Telephone: +1 408 526 4796 > >>>>Email: bew@cisco.com > >>>> > >>>>_______________________________________________ > >>>>msec mailing list > >>>>msec@securemulticast.org > >>>>http://www.pairlist.net/mailman/listinfo/msec > >>>> > >>>> > >>_______________________________________________ > >>msec mailing list > >>msec@securemulticast.org > >>http://www.pairlist.net/mailman/listinfo/msec > >> > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 14:31:58 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26057 for ; Fri, 21 Jun 2002 14:31:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 279AB535F4; Fri, 21 Jun 2002 14:31:24 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0BC7C53675 for ; Fri, 21 Jun 2002 14:30:34 -0400 (EDT) Received: (qmail 33194 invoked by uid 3269); 21 Jun 2002 18:31:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 33191 invoked from network); 21 Jun 2002 18:31:17 -0000 Received: from zcars04f.nortelnetworks.com (HELO zcars04f.ca.nortel.com) (47.129.242.57) by klesh.pair.com with SMTP; 21 Jun 2002 18:31:17 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5LIUSv23106; Fri, 21 Jun 2002 14:30:28 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NGKKSZ1Q; Fri, 21 Jun 2002 14:30:27 -0400 Received: from nortelnetworks.com (lakshminath1.us.nortel.com [47.16.67.111]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N12LGR9T; Fri, 21 Jun 2002 14:30:27 -0400 Message-ID: <3D137195.6010009@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Brian Weis Cc: "Lakshminath Dondeti" , msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <3D0FACB0.42A78E54@cisco.com> <3D10B4F7.7027A9B0@cisco.com> <3D133F33.3090008@nortelnetworks.com> <3D134B6C.5DC13532@cisco.com> <3D1364D1.40706@nortelnetworks.com> <3D136B0A.1FB1A9CF@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 14:33:57 -0400 Content-Transfer-Encoding: 7bit First, It seems that we agree that this is a topic to be covered in the Security considerations section. But, :-) ... please see inline: Brian Weis wrote: > Hi Lakshminath, > > Lakshminath Dondeti wrote: > >>Brian, >> >>Securing SAKEK or SATEK policy, or the GSPT may be a requirement for >>some applications. >> > > The only way to secure the SAKEK would be to force all authorized group > members to re-register via a PULL message. We can note this in the > Security Considerations. > What if we do a round of rekeying under old policy and another round of rekeying with a new policy. Thus the group switches over to new keys first followed immediately by a switch over to new policy (with or without a whole new set of keys). Would that work? Thus a kicked out member will not know whether the group changed the KEK_ALGORITHM or not :-). Now, I am NOT saying that hiding the algorithm name offers any extra protection. The point is that the SA payload is part of the encrypted portion of the PUSH message. If it is not made clear that evicted members can see it, we might add a more important attribute to the payload forgetting that it is effectively sent in the clear. cheers, Lakshminath > >>The solution (sending policy twice) could be confusing and must be >>stated either in the PUSH message description, or in the Security >>Considerations section. Thanks. >> > > Just to clarify my point earlier, the no single policy is actually sent > twice -- the KEK keys/policy is just split from the TEK keys/policy. > There are two independent PUSH messages. But I agree that it warrants > discussion in the Security Considerations too. > > Thanks, > Brian > > >>best, >>Lakshminath >> >>Brian Weis wrote: >> >> >>>Hi Lakshminath, >>> >>>It's not really possible to keep the SA_KEK payload secret, because that >>>policy is needed in order for a group member to use the KEK (including >>>any LKH arrays) in the KD payload. :-) >>> >>>But I think you were asking about the SA_TEK payloads containing policy >>>for the IPSec SAs. We don't have any mechanism today for keeping >>>expelled group members from viewing the SA_TEK payloads. They will have >>>access to the KEK which is used to decrypt the entire PUSH message. The >>>only method I can think of for hiding them from expelled group members >>>would be to send them in a separate PUSH message following the KEK >>>change so that they are wholly encrypted under the new KEK. >>> >>>But I'm not convinced there's much risk to expelled group members from >>>seeing the policy. The new SA policy is unlikely to change when >>>replacement SAs are distributed. The new SPI values will be documented >>>in the SA_TEKs, but then they'll also be in the clear when data traffic >>>using those SPIs starts flowing too. If a group has a security policy >>>which says that the policy must be kept secret, that policy can be >>>easily accommodated by sending the SA_TEKs in a separate PUSH message >>>from the SA_KEK. >>> >>>Do you see any other risk? >>> >>>Thanks, >>>Brian >>> >>>Lakshminath Dondeti wrote: >>> >>> >>>>Brian, >>>> >>>>Would it be possible to keep the SA payload secret (to disallow >>>>kickedout members from knowing policy changes), if necessary? >>>> >>>>cheers, >>>>Lakshminath >>>> >>>>Brian Weis wrote: >>>> >>>> >>>> >>>>>Further clarification is needed since I wasn't very clear how Solutions >>>>>2 and 3 below would be implemented. >>>>> >>>>>As currently specified the entire rekey message is protected under KEK. >>>>>The first operation of any group member is to decrypt the message with >>>>>KEK. Then as part of KD payload processing the group member determines >>>>>the new key protecting rekey messages (KEK') from the LKH update arrays. >>>>> >>>>>The new proposed processing (for solutions 2 and 3) would be for the >>>>>group member to use KEK' to decrypt the TEK keys in the KD payload. In >>>>>this way, a group member who had been removed from the group would not >>>>>be able to gain the next set of TEK keys. >>>>> >>>>>This is a reasonable thing to do. But I'd like to get a sense from the >>>>>working group as to how comfortable they feel about making a change like >>>>>this after the protocol has finished working group last call. >>>>> >>>>>The difference between solutions 2 and 3 has to do with payload >>>>>processing. Solution 2 does not change the message structure, but may be >>>>>more difficult for an implementation. >>>>> >>>>>Thanks, >>>>>Brian >>>>> >>>>>Brian Weis wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>One issue does warrant some discussion on this list. It has primarily to >>>>>>do with expelling group members when a group key management algorithm >>>>>>(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a >>>>>>KEK is used alone. >>>>>> >>>>>>Recall that a GROUPKEY-PUSH message is a single exchange sent to all >>>>>>group members (probably via multicast). It looks like this: >>>>>> >>>>>> Member GCKS or Delegate >>>>>> ------ ---------------- >>>>>> >>>>>> <---- HDR*, SEQ, SA, KD, [CERT,] SIG >>>>>> >>>>>>The entire message (following the *) is encrypted under the "current" >>>>>>KEK which is held by all group members. The SA payload may contain >>>>>>policy for a "new" KEK which will replace the existing KEK, and this >>>>>>replacement begins with the next GROUPKEY-PUSH message. If the SA >>>>>>payload has new KEK policy, then the KD payload will contain the new KEK >>>>>>keys. This is most likely the case where an LKH group membership key >>>>>>tree is used, so the KD payload will have several sets of key arrays >>>>>>which work together to provide a new KEK to group members who have not >>>>>>been expelled from the group. [See RFC 2627 for details.] >>>>>> >>>>>>Notice that the expelled group member will not be able to read the new >>>>>>KEK (that's the main property of a group management algorithm), but >>>>>>because he has possession of the "current" KEK and can decrypt and read >>>>>>the rest of the message. >>>>>> >>>>>>Now if someone has taken the trouble to expel one or more group members >>>>>>they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so >>>>>>that the expelled member can no longer participate in the group. For >>>>>>efficiency reasons it should be possible to send out the new TEK SAs in >>>>>>the same GROUPKEY-PUSH message in which the KEK is changed. The SA and >>>>>>KD payloads support this today. >>>>>> >>>>>>But here's the problem: Since the expelled group member has the >>>>>>"current" KEK and can read the entire message, he will be able to read >>>>>>the new TEK SAs and keys and thus won't be expelled from the group until >>>>>>the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message >>>>>>will be the first use of the new KEK. >>>>>> >>>>>>Here are some possibilities to resolve the issue in the draft: >>>>>> >>>>>>Solution 1: The simplest fix for this problem is to disallow sending of >>>>>>any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. >>>>>>Unfortunately, this disallows any possibility of efficient rekeys of >>>>>>group policy. This does have the advantage of being the most minimal >>>>>>change to the draft as it would simply add some MUST NOT statements. >>>>>> >>>>>>Solution 2: Leave the KD payload intact. That is, allow it to contain >>>>>>both the KEK and TEK keys. But require the TEK portion of the KD payload >>>>>>to be super-encrypted with the new KEK. This maintains efficiency, but >>>>>>requires extra processing to that portion of the KD payload which is >>>>>>super-encrypted. This is a minimal (but subtle) change to the >>>>>>GROUPKEY-PUSH protocol. However it does add substantial complexity to >>>>>>the construction and processing of the KD payload. >>>>>> >>>>>>Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one >>>>>>which would contain the KEK keys. The other would the TEK keys and be >>>>>>super-encrypted with the new KEK. This is the most change to the draft, >>>>>>but does provide the desired efficiency and is the cleanest overall >>>>>>design. >>>>>> >>>>>>I'd be interested at hearing opinions on the above solutions and/or >>>>>>alternate solutions. >>>>>> >>>>>>Thanks, >>>>>>Brian >>>>>> >>>>>>-- >>>>>>Brian Weis >>>>>>Strategic Cryptographic Development, ITD, Cisco Systems >>>>>>Telephone: +1 408 526 4796 >>>>>>Email: bew@cisco.com >>>>>> >>>>>>_______________________________________________ >>>>>>msec mailing list >>>>>>msec@securemulticast.org >>>>>>http://www.pairlist.net/mailman/listinfo/msec >>>>>> >>>>>> >>>>>> >>>>_______________________________________________ >>>>msec mailing list >>>>msec@securemulticast.org >>>>http://www.pairlist.net/mailman/listinfo/msec >>>> >>>> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec >> > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 15:20:31 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28279 for ; Fri, 21 Jun 2002 15:20:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2321353711; Fri, 21 Jun 2002 15:19:39 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id EB81E53711 for ; Fri, 21 Jun 2002 15:18:23 -0400 (EDT) Received: (qmail 38676 invoked by uid 3269); 21 Jun 2002 19:19:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 38671 invoked from network); 21 Jun 2002 19:19:07 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 21 Jun 2002 19:19:07 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5LJIVL0022616; Fri, 21 Jun 2002 12:18:31 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABX04561; Fri, 21 Jun 2002 12:16:20 -0700 (PDT) Message-Id: <4.3.2.7.2.20020621121613.04a1ab98@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] Next GDOI draft Cc: "Lakshminath Dondeti" , Brian Weis , msec@securemulticast.org In-Reply-To: <3D136C2C.6020108@nortelnetworks.com> References: <3D0FACB0.42A78E54@cisco.com> <3D10B4F7.7027A9B0@cisco.com> <3D133F33.3090008@nortelnetworks.com> <3D134B6C.5DC13532@cisco.com> <4.3.2.7.2.20020621105156.04becc68@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 12:16:35 -0700 hi I'm happy with adding this to the security considerations section thanks, Mark At 02:10 PM 6/21/2002 -0400, Lakshminath Dondeti wrote: >Mark, > >I understand that, and my point is it is ok to not support a potential >security requirement, but that should be made clear in the Security >Considerations section. > >It turns out that GDOI can do it (I think) with an extra PUSH message. > >cheers, >Lakshminath > > >Mark Baugher wrote: > >>hi Lakshminath, >>At 01:39 PM 6/21/2002 -0400, Lakshminath Dondeti wrote: >> >>>Brian, >>> >>>Securing SAKEK or SATEK policy, or the GSPT may be a requirement for >>>some applications. >> >>If we try to solve the security problems of all actual >>and potential applications, we'll have a protocol that >>is too complex for most applications. ISAKMP is >>complex enough and so is its GDOI. >>thanks, Mark >> >>>The solution (sending policy twice) could be confusing and must be >>>stated either in the PUSH message description, or in the Security >>>Considerations section. Thanks. >>> >>>best, >>>Lakshminath >>> >>>Brian Weis wrote: >>> >>>>Hi Lakshminath, >>>>It's not really possible to keep the SA_KEK payload secret, because that >>>>policy is needed in order for a group member to use the KEK (including >>>>any LKH arrays) in the KD payload. :-) >>>>But I think you were asking about the SA_TEK payloads containing policy >>>>for the IPSec SAs. We don't have any mechanism today for keeping >>>>expelled group members from viewing the SA_TEK payloads. They will have >>>>access to the KEK which is used to decrypt the entire PUSH message. The >>>>only method I can think of for hiding them from expelled group members >>>>would be to send them in a separate PUSH message following the KEK >>>>change so that they are wholly encrypted under the new KEK. >>>>But I'm not convinced there's much risk to expelled group members from >>>>seeing the policy. The new SA policy is unlikely to change when >>>>replacement SAs are distributed. The new SPI values will be documented >>>>in the SA_TEKs, but then they'll also be in the clear when data traffic >>>>using those SPIs starts flowing too. If a group has a security policy >>>>which says that the policy must be kept secret, that policy can be >>>>easily accommodated by sending the SA_TEKs in a separate PUSH message >>>>from the SA_KEK. >>>>Do you see any other risk? >>>>Thanks, >>>>Brian >>>>Lakshminath Dondeti wrote: >>>> >>>>>Brian, >>>>> >>>>>Would it be possible to keep the SA payload secret (to disallow >>>>>kickedout members from knowing policy changes), if necessary? >>>>> >>>>>cheers, >>>>>Lakshminath >>>>> >>>>>Brian Weis wrote: >>>>> >>>>> >>>>>>Further clarification is needed since I wasn't very clear how Solutions >>>>>>2 and 3 below would be implemented. >>>>>> >>>>>>As currently specified the entire rekey message is protected under KEK. >>>>>>The first operation of any group member is to decrypt the message with >>>>>>KEK. Then as part of KD payload processing the group member determines >>>>>>the new key protecting rekey messages (KEK') from the LKH update arrays. >>>>>> >>>>>>The new proposed processing (for solutions 2 and 3) would be for the >>>>>>group member to use KEK' to decrypt the TEK keys in the KD payload. In >>>>>>this way, a group member who had been removed from the group would not >>>>>>be able to gain the next set of TEK keys. >>>>>> >>>>>>This is a reasonable thing to do. But I'd like to get a sense from the >>>>>>working group as to how comfortable they feel about making a change like >>>>>>this after the protocol has finished working group last call. >>>>>> >>>>>>The difference between solutions 2 and 3 has to do with payload >>>>>>processing. Solution 2 does not change the message structure, but may be >>>>>>more difficult for an implementation. >>>>>> >>>>>>Thanks, >>>>>>Brian >>>>>> >>>>>>Brian Weis wrote: >>>>>> >>>>>> >>>>>> >>>>>>>One issue does warrant some discussion on this list. It has primarily to >>>>>>>do with expelling group members when a group key management algorithm >>>>>>>(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a >>>>>>>KEK is used alone. >>>>>>> >>>>>>>Recall that a GROUPKEY-PUSH message is a single exchange sent to all >>>>>>>group members (probably via multicast). It looks like this: >>>>>>> >>>>>>> Member GCKS or Delegate >>>>>>> ------ ---------------- >>>>>>> >>>>>>> <---- HDR*, SEQ, SA, KD, [CERT,] SIG >>>>>>> >>>>>>>The entire message (following the *) is encrypted under the "current" >>>>>>>KEK which is held by all group members. The SA payload may contain >>>>>>>policy for a "new" KEK which will replace the existing KEK, and this >>>>>>>replacement begins with the next GROUPKEY-PUSH message. If the SA >>>>>>>payload has new KEK policy, then the KD payload will contain the new KEK >>>>>>>keys. This is most likely the case where an LKH group membership key >>>>>>>tree is used, so the KD payload will have several sets of key arrays >>>>>>>which work together to provide a new KEK to group members who have not >>>>>>>been expelled from the group. [See RFC 2627 for details.] >>>>>>> >>>>>>>Notice that the expelled group member will not be able to read the new >>>>>>>KEK (that's the main property of a group management algorithm), but >>>>>>>because he has possession of the "current" KEK and can decrypt and read >>>>>>>the rest of the message. >>>>>>> >>>>>>>Now if someone has taken the trouble to expel one or more group members >>>>>>>they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so >>>>>>>that the expelled member can no longer participate in the group. For >>>>>>>efficiency reasons it should be possible to send out the new TEK SAs in >>>>>>>the same GROUPKEY-PUSH message in which the KEK is changed. The SA and >>>>>>>KD payloads support this today. >>>>>>> >>>>>>>But here's the problem: Since the expelled group member has the >>>>>>>"current" KEK and can read the entire message, he will be able to read >>>>>>>the new TEK SAs and keys and thus won't be expelled from the group until >>>>>>>the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message >>>>>>>will be the first use of the new KEK. >>>>>>> >>>>>>>Here are some possibilities to resolve the issue in the draft: >>>>>>> >>>>>>>Solution 1: The simplest fix for this problem is to disallow sending of >>>>>>>any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. >>>>>>>Unfortunately, this disallows any possibility of efficient rekeys of >>>>>>>group policy. This does have the advantage of being the most minimal >>>>>>>change to the draft as it would simply add some MUST NOT statements. >>>>>>> >>>>>>>Solution 2: Leave the KD payload intact. That is, allow it to contain >>>>>>>both the KEK and TEK keys. But require the TEK portion of the KD payload >>>>>>>to be super-encrypted with the new KEK. This maintains efficiency, but >>>>>>>requires extra processing to that portion of the KD payload which is >>>>>>>super-encrypted. This is a minimal (but subtle) change to the >>>>>>>GROUPKEY-PUSH protocol. However it does add substantial complexity to >>>>>>>the construction and processing of the KD payload. >>>>>>> >>>>>>>Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one >>>>>>>which would contain the KEK keys. The other would the TEK keys and be >>>>>>>super-encrypted with the new KEK. This is the most change to the draft, >>>>>>>but does provide the desired efficiency and is the cleanest overall >>>>>>>design. >>>>>>> >>>>>>>I'd be interested at hearing opinions on the above solutions and/or >>>>>>>alternate solutions. >>>>>>> >>>>>>>Thanks, >>>>>>>Brian >>>>>>> >>>>>>>-- >>>>>>>Brian Weis >>>>>>>Strategic Cryptographic Development, ITD, Cisco Systems >>>>>>>Telephone: +1 408 526 4796 >>>>>>>Email: bew@cisco.com >>>>>>> >>>>>>>_______________________________________________ >>>>>>>msec mailing list >>>>>>>msec@securemulticast.org >>>>>>>http://www.pairlist.net/mailman/listinfo/msec >>>>>_______________________________________________ >>>>>msec mailing list >>>>>msec@securemulticast.org >>>>>http://www.pairlist.net/mailman/listinfo/msec >>> >>> >>> >>>_______________________________________________ >>>msec mailing list >>>msec@securemulticast.org >>>http://www.pairlist.net/mailman/listinfo/msec >> > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 16:31:59 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00586 for ; Fri, 21 Jun 2002 16:31:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B6C40537B2; Fri, 21 Jun 2002 16:30:24 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0AE67535F9 for ; Fri, 21 Jun 2002 16:29:43 -0400 (EDT) Received: (qmail 50077 invoked by uid 3269); 21 Jun 2002 20:30:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 50074 invoked from network); 21 Jun 2002 20:30:26 -0000 Received: from zcars04f.nortelnetworks.com (HELO zcars04f.ca.nortel.com) (47.129.242.57) by klesh.pair.com with SMTP; 21 Jun 2002 20:30:26 -0000 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5LKTev02278; Fri, 21 Jun 2002 16:29:41 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFR0XMXR; Fri, 21 Jun 2002 16:29:40 -0400 Received: from nortelnetworks.com (lakshminath1.us.nortel.com [47.16.67.111]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N12LGS2G; Fri, 21 Jun 2002 16:29:39 -0400 Message-ID: <3D138D85.5040307@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Brian Weis Cc: "Lakshminath Dondeti" , msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <3D0FACB0.42A78E54@cisco.com> <3D10B4F7.7027A9B0@cisco.com> <3D133F33.3090008@nortelnetworks.com> <3D134B6C.5DC13532@cisco.com> <3D1364D1.40706@nortelnetworks.com> <3D136B0A.1FB1A9CF@cisco.com> <3D137195.6010009@nortelnetworks.com> <3D138A64.674F1665@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 16:33:09 -0400 Content-Transfer-Encoding: 7bit Brian, Thanks. Two complete rekeys it is then :-); I was thinking we could get away with some trick (a flag in the first message indicating that the SA will change and is in the next message) to change policy without having to resend a whole GKMA array again. But, doing two complete rekeys will be a much cleaner solution. cheers, Lakshminath Brian Weis wrote: > Hi Lakshminath, > > Lakshminath Dondeti wrote: > >>First, >> >>It seems that we agree that this is a topic to be covered in the >>Security considerations section. >> >>But, :-) ... please see inline: >> >>Brian Weis wrote: >> >> >>>Hi Lakshminath, >>> >>>Lakshminath Dondeti wrote: >>> >>> >>>>Brian, >>>> >>>>Securing SAKEK or SATEK policy, or the GSPT may be a requirement for >>>>some applications. >>>> >>>> >>>The only way to secure the SAKEK would be to force all authorized group >>>members to re-register via a PULL message. We can note this in the >>>Security Considerations. >>> >>> >>What if we do a round of rekeying under old policy and another round of >>rekeying with a new policy. Thus the group switches over to new keys >>first followed immediately by a switch over to new policy (with or >>without a whole new set of keys). Would that work? >> > > Hmmm, that's an interesting idea. But there's obviously potential for > some group member having the wrong policy since there would be different > sets of policy valid at different times for the same key! This would be > similar to changing an IPSec policy for the same key/SPI in the middle > of its lifetime (e.g., from 3DES/SHA to DES/MD5). It seems a bit > dangerous. > > But since two rekeys are required, you might as well do two complete > rekeys (new key/SPI, new policy) to get the desired result. At the end > of the first rekey the expelled group member knows the policy but not > the key. At the end of the second rekey, the group member has no > knowledge of group policy. > > How about if we document that solution in the Security Considerations? > > Thanks, > Brian > > >>Thus a kicked out member will not know whether the group changed the >>KEK_ALGORITHM or not :-). Now, I am NOT saying that hiding the >>algorithm name offers any extra protection. >> >>The point is that the SA payload is part of the encrypted portion of the >>PUSH message. If it is not made clear that evicted members can see it, >>we might add a more important attribute to the payload forgetting that >>it is effectively sent in the clear. >> >>cheers, >>Lakshminath >> >> >>>>The solution (sending policy twice) could be confusing and must be >>>>stated either in the PUSH message description, or in the Security >>>>Considerations section. Thanks. >>>> >>>> >>>Just to clarify my point earlier, the no single policy is actually sent >>>twice -- the KEK keys/policy is just split from the TEK keys/policy. >>>There are two independent PUSH messages. But I agree that it warrants >>>discussion in the Security Considerations too. >>> >>>Thanks, >>>Brian >>> >>> >>> >>>>best, >>>>Lakshminath >>>> >>>>Brian Weis wrote: >>>> >>>> >>>> >>>>>Hi Lakshminath, >>>>> >>>>>It's not really possible to keep the SA_KEK payload secret, because that >>>>>policy is needed in order for a group member to use the KEK (including >>>>>any LKH arrays) in the KD payload. :-) >>>>> >>>>>But I think you were asking about the SA_TEK payloads containing policy >>>>>for the IPSec SAs. We don't have any mechanism today for keeping >>>>>expelled group members from viewing the SA_TEK payloads. They will have >>>>>access to the KEK which is used to decrypt the entire PUSH message. The >>>>>only method I can think of for hiding them from expelled group members >>>>>would be to send them in a separate PUSH message following the KEK >>>>>change so that they are wholly encrypted under the new KEK. >>>>> >>>>>But I'm not convinced there's much risk to expelled group members from >>>>>seeing the policy. The new SA policy is unlikely to change when >>>>>replacement SAs are distributed. The new SPI values will be documented >>>>>in the SA_TEKs, but then they'll also be in the clear when data traffic >>>>>using those SPIs starts flowing too. If a group has a security policy >>>>>which says that the policy must be kept secret, that policy can be >>>>>easily accommodated by sending the SA_TEKs in a separate PUSH message >>>>> >>>>>from the SA_KEK. >>>> >>>>>Do you see any other risk? >>>>> >>>>>Thanks, >>>>>Brian >>>>> >>>>>Lakshminath Dondeti wrote: >>>>> >>>>> >>>>> >>>>>>Brian, >>>>>> >>>>>>Would it be possible to keep the SA payload secret (to disallow >>>>>>kickedout members from knowing policy changes), if necessary? >>>>>> >>>>>>cheers, >>>>>>Lakshminath >>>>>> >>>>>>Brian Weis wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Further clarification is needed since I wasn't very clear how Solutions >>>>>>>2 and 3 below would be implemented. >>>>>>> >>>>>>>As currently specified the entire rekey message is protected under KEK. >>>>>>>The first operation of any group member is to decrypt the message with >>>>>>>KEK. Then as part of KD payload processing the group member determines >>>>>>>the new key protecting rekey messages (KEK') from the LKH update arrays. >>>>>>> >>>>>>>The new proposed processing (for solutions 2 and 3) would be for the >>>>>>>group member to use KEK' to decrypt the TEK keys in the KD payload. In >>>>>>>this way, a group member who had been removed from the group would not >>>>>>>be able to gain the next set of TEK keys. >>>>>>> >>>>>>>This is a reasonable thing to do. But I'd like to get a sense from the >>>>>>>working group as to how comfortable they feel about making a change like >>>>>>>this after the protocol has finished working group last call. >>>>>>> >>>>>>>The difference between solutions 2 and 3 has to do with payload >>>>>>>processing. Solution 2 does not change the message structure, but may be >>>>>>>more difficult for an implementation. >>>>>>> >>>>>>>Thanks, >>>>>>>Brian >>>>>>> >>>>>>>Brian Weis wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>One issue does warrant some discussion on this list. It has primarily to >>>>>>>>do with expelling group members when a group key management algorithm >>>>>>>>(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a >>>>>>>>KEK is used alone. >>>>>>>> >>>>>>>>Recall that a GROUPKEY-PUSH message is a single exchange sent to all >>>>>>>>group members (probably via multicast). It looks like this: >>>>>>>> >>>>>>>> Member GCKS or Delegate >>>>>>>> ------ ---------------- >>>>>>>> >>>>>>>> <---- HDR*, SEQ, SA, KD, [CERT,] SIG >>>>>>>> >>>>>>>>The entire message (following the *) is encrypted under the "current" >>>>>>>>KEK which is held by all group members. The SA payload may contain >>>>>>>>policy for a "new" KEK which will replace the existing KEK, and this >>>>>>>>replacement begins with the next GROUPKEY-PUSH message. If the SA >>>>>>>>payload has new KEK policy, then the KD payload will contain the new KEK >>>>>>>>keys. This is most likely the case where an LKH group membership key >>>>>>>>tree is used, so the KD payload will have several sets of key arrays >>>>>>>>which work together to provide a new KEK to group members who have not >>>>>>>>been expelled from the group. [See RFC 2627 for details.] >>>>>>>> >>>>>>>>Notice that the expelled group member will not be able to read the new >>>>>>>>KEK (that's the main property of a group management algorithm), but >>>>>>>>because he has possession of the "current" KEK and can decrypt and read >>>>>>>>the rest of the message. >>>>>>>> >>>>>>>>Now if someone has taken the trouble to expel one or more group members >>>>>>>>they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so >>>>>>>>that the expelled member can no longer participate in the group. For >>>>>>>>efficiency reasons it should be possible to send out the new TEK SAs in >>>>>>>>the same GROUPKEY-PUSH message in which the KEK is changed. The SA and >>>>>>>>KD payloads support this today. >>>>>>>> >>>>>>>>But here's the problem: Since the expelled group member has the >>>>>>>>"current" KEK and can read the entire message, he will be able to read >>>>>>>>the new TEK SAs and keys and thus won't be expelled from the group until >>>>>>>>the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message >>>>>>>>will be the first use of the new KEK. >>>>>>>> >>>>>>>>Here are some possibilities to resolve the issue in the draft: >>>>>>>> >>>>>>>>Solution 1: The simplest fix for this problem is to disallow sending of >>>>>>>>any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. >>>>>>>>Unfortunately, this disallows any possibility of efficient rekeys of >>>>>>>>group policy. This does have the advantage of being the most minimal >>>>>>>>change to the draft as it would simply add some MUST NOT statements. >>>>>>>> >>>>>>>>Solution 2: Leave the KD payload intact. That is, allow it to contain >>>>>>>>both the KEK and TEK keys. But require the TEK portion of the KD payload >>>>>>>>to be super-encrypted with the new KEK. This maintains efficiency, but >>>>>>>>requires extra processing to that portion of the KD payload which is >>>>>>>>super-encrypted. This is a minimal (but subtle) change to the >>>>>>>>GROUPKEY-PUSH protocol. However it does add substantial complexity to >>>>>>>>the construction and processing of the KD payload. >>>>>>>> >>>>>>>>Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one >>>>>>>>which would contain the KEK keys. The other would the TEK keys and be >>>>>>>>super-encrypted with the new KEK. This is the most change to the draft, >>>>>>>>but does provide the desired efficiency and is the cleanest overall >>>>>>>>design. >>>>>>>> >>>>>>>>I'd be interested at hearing opinions on the above solutions and/or >>>>>>>>alternate solutions. >>>>>>>> >>>>>>>>Thanks, >>>>>>>>Brian >>>>>>>> >>>>>>>>-- >>>>>>>>Brian Weis >>>>>>>>Strategic Cryptographic Development, ITD, Cisco Systems >>>>>>>>Telephone: +1 408 526 4796 >>>>>>>>Email: bew@cisco.com >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>msec mailing list >>>>>>>>msec@securemulticast.org >>>>>>>>http://www.pairlist.net/mailman/listinfo/msec >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>_______________________________________________ >>>>>>msec mailing list >>>>>>msec@securemulticast.org >>>>>>http://www.pairlist.net/mailman/listinfo/msec >>>>>> >>>>>> >>>>>> >>>>_______________________________________________ >>>>msec mailing list >>>>msec@securemulticast.org >>>>http://www.pairlist.net/mailman/listinfo/msec >>>> >>>> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec >> > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 21 16:56:54 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01161 for ; Fri, 21 Jun 2002 16:56:54 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2EC36538B7; Fri, 21 Jun 2002 16:20:38 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7033253814 for ; Fri, 21 Jun 2002 16:19:47 -0400 (EDT) Received: (qmail 48194 invoked by uid 3269); 21 Jun 2002 20:20:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48191 invoked from network); 21 Jun 2002 20:20:31 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 21 Jun 2002 20:20:31 -0000 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5LKJnL0022824; Fri, 21 Jun 2002 13:19:49 -0700 (PDT) Received: from cisco.com (dhcp-128-107-212-74.cisco.com [128.107.212.74]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA20239; Fri, 21 Jun 2002 13:19:48 -0700 (PDT) Message-ID: <3D138A64.674F1665@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lakshminath Dondeti Cc: msec@securemulticast.org Subject: Re: [MSEC] Next GDOI draft References: <3D0FACB0.42A78E54@cisco.com> <3D10B4F7.7027A9B0@cisco.com> <3D133F33.3090008@nortelnetworks.com> <3D134B6C.5DC13532@cisco.com> <3D1364D1.40706@nortelnetworks.com> <3D136B0A.1FB1A9CF@cisco.com> <3D137195.6010009@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Jun 2002 13:19:48 -0700 Content-Transfer-Encoding: 7bit Hi Lakshminath, Lakshminath Dondeti wrote: > > First, > > It seems that we agree that this is a topic to be covered in the > Security considerations section. > > But, :-) ... please see inline: > > Brian Weis wrote: > > > Hi Lakshminath, > > > > Lakshminath Dondeti wrote: > > > >>Brian, > >> > >>Securing SAKEK or SATEK policy, or the GSPT may be a requirement for > >>some applications. > >> > > > > The only way to secure the SAKEK would be to force all authorized group > > members to re-register via a PULL message. We can note this in the > > Security Considerations. > > > > What if we do a round of rekeying under old policy and another round of > rekeying with a new policy. Thus the group switches over to new keys > first followed immediately by a switch over to new policy (with or > without a whole new set of keys). Would that work? Hmmm, that's an interesting idea. But there's obviously potential for some group member having the wrong policy since there would be different sets of policy valid at different times for the same key! This would be similar to changing an IPSec policy for the same key/SPI in the middle of its lifetime (e.g., from 3DES/SHA to DES/MD5). It seems a bit dangerous. But since two rekeys are required, you might as well do two complete rekeys (new key/SPI, new policy) to get the desired result. At the end of the first rekey the expelled group member knows the policy but not the key. At the end of the second rekey, the group member has no knowledge of group policy. How about if we document that solution in the Security Considerations? Thanks, Brian > Thus a kicked out member will not know whether the group changed the > KEK_ALGORITHM or not :-). Now, I am NOT saying that hiding the > algorithm name offers any extra protection. > > The point is that the SA payload is part of the encrypted portion of the > PUSH message. If it is not made clear that evicted members can see it, > we might add a more important attribute to the payload forgetting that > it is effectively sent in the clear. > > cheers, > Lakshminath > > > > >>The solution (sending policy twice) could be confusing and must be > >>stated either in the PUSH message description, or in the Security > >>Considerations section. Thanks. > >> > > > > Just to clarify my point earlier, the no single policy is actually sent > > twice -- the KEK keys/policy is just split from the TEK keys/policy. > > There are two independent PUSH messages. But I agree that it warrants > > discussion in the Security Considerations too. > > > > Thanks, > > Brian > > > > > >>best, > >>Lakshminath > >> > >>Brian Weis wrote: > >> > >> > >>>Hi Lakshminath, > >>> > >>>It's not really possible to keep the SA_KEK payload secret, because that > >>>policy is needed in order for a group member to use the KEK (including > >>>any LKH arrays) in the KD payload. :-) > >>> > >>>But I think you were asking about the SA_TEK payloads containing policy > >>>for the IPSec SAs. We don't have any mechanism today for keeping > >>>expelled group members from viewing the SA_TEK payloads. They will have > >>>access to the KEK which is used to decrypt the entire PUSH message. The > >>>only method I can think of for hiding them from expelled group members > >>>would be to send them in a separate PUSH message following the KEK > >>>change so that they are wholly encrypted under the new KEK. > >>> > >>>But I'm not convinced there's much risk to expelled group members from > >>>seeing the policy. The new SA policy is unlikely to change when > >>>replacement SAs are distributed. The new SPI values will be documented > >>>in the SA_TEKs, but then they'll also be in the clear when data traffic > >>>using those SPIs starts flowing too. If a group has a security policy > >>>which says that the policy must be kept secret, that policy can be > >>>easily accommodated by sending the SA_TEKs in a separate PUSH message > >>>from the SA_KEK. > >>> > >>>Do you see any other risk? > >>> > >>>Thanks, > >>>Brian > >>> > >>>Lakshminath Dondeti wrote: > >>> > >>> > >>>>Brian, > >>>> > >>>>Would it be possible to keep the SA payload secret (to disallow > >>>>kickedout members from knowing policy changes), if necessary? > >>>> > >>>>cheers, > >>>>Lakshminath > >>>> > >>>>Brian Weis wrote: > >>>> > >>>> > >>>> > >>>>>Further clarification is needed since I wasn't very clear how Solutions > >>>>>2 and 3 below would be implemented. > >>>>> > >>>>>As currently specified the entire rekey message is protected under KEK. > >>>>>The first operation of any group member is to decrypt the message with > >>>>>KEK. Then as part of KD payload processing the group member determines > >>>>>the new key protecting rekey messages (KEK') from the LKH update arrays. > >>>>> > >>>>>The new proposed processing (for solutions 2 and 3) would be for the > >>>>>group member to use KEK' to decrypt the TEK keys in the KD payload. In > >>>>>this way, a group member who had been removed from the group would not > >>>>>be able to gain the next set of TEK keys. > >>>>> > >>>>>This is a reasonable thing to do. But I'd like to get a sense from the > >>>>>working group as to how comfortable they feel about making a change like > >>>>>this after the protocol has finished working group last call. > >>>>> > >>>>>The difference between solutions 2 and 3 has to do with payload > >>>>>processing. Solution 2 does not change the message structure, but may be > >>>>>more difficult for an implementation. > >>>>> > >>>>>Thanks, > >>>>>Brian > >>>>> > >>>>>Brian Weis wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>One issue does warrant some discussion on this list. It has primarily to > >>>>>>do with expelling group members when a group key management algorithm > >>>>>>(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a > >>>>>>KEK is used alone. > >>>>>> > >>>>>>Recall that a GROUPKEY-PUSH message is a single exchange sent to all > >>>>>>group members (probably via multicast). It looks like this: > >>>>>> > >>>>>> Member GCKS or Delegate > >>>>>> ------ ---------------- > >>>>>> > >>>>>> <---- HDR*, SEQ, SA, KD, [CERT,] SIG > >>>>>> > >>>>>>The entire message (following the *) is encrypted under the "current" > >>>>>>KEK which is held by all group members. The SA payload may contain > >>>>>>policy for a "new" KEK which will replace the existing KEK, and this > >>>>>>replacement begins with the next GROUPKEY-PUSH message. If the SA > >>>>>>payload has new KEK policy, then the KD payload will contain the new KEK > >>>>>>keys. This is most likely the case where an LKH group membership key > >>>>>>tree is used, so the KD payload will have several sets of key arrays > >>>>>>which work together to provide a new KEK to group members who have not > >>>>>>been expelled from the group. [See RFC 2627 for details.] > >>>>>> > >>>>>>Notice that the expelled group member will not be able to read the new > >>>>>>KEK (that's the main property of a group management algorithm), but > >>>>>>because he has possession of the "current" KEK and can decrypt and read > >>>>>>the rest of the message. > >>>>>> > >>>>>>Now if someone has taken the trouble to expel one or more group members > >>>>>>they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so > >>>>>>that the expelled member can no longer participate in the group. For > >>>>>>efficiency reasons it should be possible to send out the new TEK SAs in > >>>>>>the same GROUPKEY-PUSH message in which the KEK is changed. The SA and > >>>>>>KD payloads support this today. > >>>>>> > >>>>>>But here's the problem: Since the expelled group member has the > >>>>>>"current" KEK and can read the entire message, he will be able to read > >>>>>>the new TEK SAs and keys and thus won't be expelled from the group until > >>>>>>the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message > >>>>>>will be the first use of the new KEK. > >>>>>> > >>>>>>Here are some possibilities to resolve the issue in the draft: > >>>>>> > >>>>>>Solution 1: The simplest fix for this problem is to disallow sending of > >>>>>>any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. > >>>>>>Unfortunately, this disallows any possibility of efficient rekeys of > >>>>>>group policy. This does have the advantage of being the most minimal > >>>>>>change to the draft as it would simply add some MUST NOT statements. > >>>>>> > >>>>>>Solution 2: Leave the KD payload intact. That is, allow it to contain > >>>>>>both the KEK and TEK keys. But require the TEK portion of the KD payload > >>>>>>to be super-encrypted with the new KEK. This maintains efficiency, but > >>>>>>requires extra processing to that portion of the KD payload which is > >>>>>>super-encrypted. This is a minimal (but subtle) change to the > >>>>>>GROUPKEY-PUSH protocol. However it does add substantial complexity to > >>>>>>the construction and processing of the KD payload. > >>>>>> > >>>>>>Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one > >>>>>>which would contain the KEK keys. The other would the TEK keys and be > >>>>>>super-encrypted with the new KEK. This is the most change to the draft, > >>>>>>but does provide the desired efficiency and is the cleanest overall > >>>>>>design. > >>>>>> > >>>>>>I'd be interested at hearing opinions on the above solutions and/or > >>>>>>alternate solutions. > >>>>>> > >>>>>>Thanks, > >>>>>>Brian > >>>>>> > >>>>>>-- > >>>>>>Brian Weis > >>>>>>Strategic Cryptographic Development, ITD, Cisco Systems > >>>>>>Telephone: +1 408 526 4796 > >>>>>>Email: bew@cisco.com > >>>>>> > >>>>>>_______________________________________________ > >>>>>>msec mailing list > >>>>>>msec@securemulticast.org > >>>>>>http://www.pairlist.net/mailman/listinfo/msec > >>>>>> > >>>>>> > >>>>>> > >>>>_______________________________________________ > >>>>msec mailing list > >>>>msec@securemulticast.org > >>>>http://www.pairlist.net/mailman/listinfo/msec > >>>> > >>>> > >>_______________________________________________ > >>msec mailing list > >>msec@securemulticast.org > >>http://www.pairlist.net/mailman/listinfo/msec > >> > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 24 09:11:30 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05293 for ; Mon, 24 Jun 2002 09:11:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A992C53686; Mon, 24 Jun 2002 08:36:28 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A647E53550 for ; Mon, 24 Jun 2002 08:23:18 -0400 (EDT) Received: (qmail 44311 invoked by uid 3269); 24 Jun 2002 12:24:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 44308 invoked from network); 24 Jun 2002 12:24:07 -0000 Received: from mantrade-bh.mandtbank.com (HELO comrcmailxxxn02.mandtbank.com) (12.19.225.250) by klesh.pair.com with SMTP; 24 Jun 2002 12:24:07 -0000 Received: from mandtbank.com (unverified) by comrcmailxxxn02.mandtbank.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Mon, 24 Jun 2002 08:22:05 -0400 Received: from INTERNET-DMZ-Message_Server by mandtbank.com with Novell_GroupWise; Mon, 24 Jun 2002 08:24:02 -0400 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 From: "MICHAEL GERMONY" To: Cc: , Subject: Re: [MSEC] Next GDOI draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 24 Jun 2002 08:23:42 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA05293 please add Scott Gribben in the contact info. 639-6641 >>> Lakshminath Dondeti 06/21/02 02:33PM >>> First, It seems that we agree that this is a topic to be covered in the Security considerations section. But, :-) ... please see inline: Brian Weis wrote: > Hi Lakshminath, > > Lakshminath Dondeti wrote: > >>Brian, >> >>Securing SAKEK or SATEK policy, or the GSPT may be a requirement for >>some applications. >> > > The only way to secure the SAKEK would be to force all authorized group > members to re-register via a PULL message. We can note this in the > Security Considerations. > What if we do a round of rekeying under old policy and another round of rekeying with a new policy. Thus the group switches over to new keys first followed immediately by a switch over to new policy (with or without a whole new set of keys). Would that work? Thus a kicked out member will not know whether the group changed the KEK_ALGORITHM or not :-). Now, I am NOT saying that hiding the algorithm name offers any extra protection. The point is that the SA payload is part of the encrypted portion of the PUSH message. If it is not made clear that evicted members can see it, we might add a more important attribute to the payload forgetting that it is effectively sent in the clear. cheers, Lakshminath > >>The solution (sending policy twice) could be confusing and must be >>stated either in the PUSH message description, or in the Security >>Considerations section. Thanks. >> > > Just to clarify my point earlier, the no single policy is actually sent > twice -- the KEK keys/policy is just split from the TEK keys/policy. > There are two independent PUSH messages. But I agree that it warrants > discussion in the Security Considerations too. > > Thanks, > Brian > > >>best, >>Lakshminath >> >>Brian Weis wrote: >> >> >>>Hi Lakshminath, >>> >>>It's not really possible to keep the SA_KEK payload secret, because that >>>policy is needed in order for a group member to use the KEK (including >>>any LKH arrays) in the KD payload. :-) >>> >>>But I think you were asking about the SA_TEK payloads containing policy >>>for the IPSec SAs. We don't have any mechanism today for keeping >>>expelled group members from viewing the SA_TEK payloads. They will have >>>access to the KEK which is used to decrypt the entire PUSH message. The >>>only method I can think of for hiding them from expelled group members >>>would be to send them in a separate PUSH message following the KEK >>>change so that they are wholly encrypted under the new KEK. >>> >>>But I'm not convinced there's much risk to expelled group members from >>>seeing the policy. The new SA policy is unlikely to change when >>>replacement SAs are distributed. The new SPI values will be documented >>>in the SA_TEKs, but then they'll also be in the clear when data traffic >>>using those SPIs starts flowing too. If a group has a security policy >>>which says that the policy must be kept secret, that policy can be >>>easily accommodated by sending the SA_TEKs in a separate PUSH message >>>from the SA_KEK. >>> >>>Do you see any other risk? >>> >>>Thanks, >>>Brian >>> >>>Lakshminath Dondeti wrote: >>> >>> >>>>Brian, >>>> >>>>Would it be possible to keep the SA payload secret (to disallow >>>>kickedout members from knowing policy changes), if necessary? >>>> >>>>cheers, >>>>Lakshminath >>>> >>>>Brian Weis wrote: >>>> >>>> >>>> >>>>>Further clarification is needed since I wasn't very clear how Solutions >>>>>2 and 3 below would be implemented. >>>>> >>>>>As currently specified the entire rekey message is protected under KEK. >>>>>The first operation of any group member is to decrypt the message with >>>>>KEK. Then as part of KD payload processing the group member determines >>>>>the new key protecting rekey messages (KEK') from the LKH update arrays. >>>>> >>>>>The new proposed processing (for solutions 2 and 3) would be for the >>>>>group member to use KEK' to decrypt the TEK keys in the KD payload. In >>>>>this way, a group member who had been removed from the group would not >>>>>be able to gain the next set of TEK keys. >>>>> >>>>>This is a reasonable thing to do. But I'd like to get a sense from the >>>>>working group as to how comfortable they feel about making a change like >>>>>this after the protocol has finished working group last call. >>>>> >>>>>The difference between solutions 2 and 3 has to do with payload >>>>>processing. Solution 2 does not change the message structure, but may be >>>>>more difficult for an implementation. >>>>> >>>>>Thanks, >>>>>Brian >>>>> >>>>>Brian Weis wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>One issue does warrant some discussion on this list. It has primarily to >>>>>>do with expelling group members when a group key management algorithm >>>>>>(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a >>>>>>KEK is used alone. >>>>>> >>>>>>Recall that a GROUPKEY-PUSH message is a single exchange sent to all >>>>>>group members (probably via multicast). It looks like this: >>>>>> >>>>>> Member GCKS or Delegate >>>>>> ------ ---------------- >>>>>> >>>>>> <---- HDR*, SEQ, SA, KD, [CERT,] SIG >>>>>> >>>>>>The entire message (following the *) is encrypted under the "current" >>>>>>KEK which is held by all group members. The SA payload may contain >>>>>>policy for a "new" KEK which will replace the existing KEK, and this >>>>>>replacement begins with the next GROUPKEY-PUSH message. If the SA >>>>>>payload has new KEK policy, then the KD payload will contain the new KEK >>>>>>keys. This is most likely the case where an LKH group membership key >>>>>>tree is used, so the KD payload will have several sets of key arrays >>>>>>which work together to provide a new KEK to group members who have not >>>>>>been expelled from the group. [See RFC 2627 for details.] >>>>>> >>>>>>Notice that the expelled group member will not be able to read the new >>>>>>KEK (that's the main property of a group management algorithm), but >>>>>>because he has possession of the "current" KEK and can decrypt and read >>>>>>the rest of the message. >>>>>> >>>>>>Now if someone has taken the trouble to expel one or more group members >>>>>>they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so >>>>>>that the expelled member can no longer participate in the group. For >>>>>>efficiency reasons it should be possible to send out the new TEK SAs in >>>>>>the same GROUPKEY-PUSH message in which the KEK is changed. The SA and >>>>>>KD payloads support this today. >>>>>> >>>>>>But here's the problem: Since the expelled group member has the >>>>>>"current" KEK and can read the entire message, he will be able to read >>>>>>the new TEK SAs and keys and thus won't be expelled from the group until >>>>>>the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message >>>>>>will be the first use of the new KEK. >>>>>> >>>>>>Here are some possibilities to resolve the issue in the draft: >>>>>> >>>>>>Solution 1: The simplest fix for this problem is to disallow sending of >>>>>>any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA. >>>>>>Unfortunately, this disallows any possibility of efficient rekeys of >>>>>>group policy. This does have the advantage of being the most minimal >>>>>>change to the draft as it would simply add some MUST NOT statements. >>>>>> >>>>>>Solution 2: Leave the KD payload intact. That is, allow it to contain >>>>>>both the KEK and TEK keys. But require the TEK portion of the KD payload >>>>>>to be super-encrypted with the new KEK. This maintains efficiency, but >>>>>>requires extra processing to that portion of the KD payload which is >>>>>>super-encrypted. This is a minimal (but subtle) change to the >>>>>>GROUPKEY-PUSH protocol. However it does add substantial complexity to >>>>>>the construction and processing of the KD payload. >>>>>> >>>>>>Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one >>>>>>which would contain the KEK keys. The other would the TEK keys and be >>>>>>super-encrypted with the new KEK. This is the most change to the draft, >>>>>>but does provide the desired efficiency and is the cleanest overall >>>>>>design. >>>>>> >>>>>>I'd be interested at hearing opinions on the above solutions and/or >>>>>>alternate solutions. >>>>>> >>>>>>Thanks, >>>>>>Brian >>>>>> >>>>>>-- >>>>>>Brian Weis >>>>>>Strategic Cryptographic Development, ITD, Cisco Systems >>>>>>Telephone: +1 408 526 4796 >>>>>>Email: bew@cisco.com >>>>>> >>>>>>_______________________________________________ >>>>>>msec mailing list >>>>>>msec@securemulticast.org >>>>>>http://www.pairlist.net/mailman/listinfo/msec >>>>>> >>>>>> >>>>>> >>>>_______________________________________________ >>>>msec mailing list >>>>msec@securemulticast.org >>>>http://www.pairlist.net/mailman/listinfo/msec >>>> >>>> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec >> > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 27 22:42:09 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27782 for ; Thu, 27 Jun 2002 22:42:08 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A1D9353A4D; Thu, 27 Jun 2002 22:41:17 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 225A253A4D for ; Thu, 27 Jun 2002 22:40:22 -0400 (EDT) Received: (qmail 60311 invoked by uid 3269); 28 Jun 2002 02:41:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60308 invoked from network); 28 Jun 2002 02:41:21 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 28 Jun 2002 02:41:21 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g5S2ehU12276; Thu, 27 Jun 2002 22:40:43 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g5S2ehL25576; Thu, 27 Jun 2002 22:40:43 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id WAA33474; Thu, 27 Jun 2002 22:40:31 -0400 From: Ran Canetti Message-Id: <200206280240.WAA33474@ornavella.watson.ibm.com> To: Fredrik.Lindholm@era.ericsson.se, msec@securemulticast.org Subject: [MSEC] A couple remarks on MIKEY Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: