From msec-admin@securemulticast.org Thu Oct 4 20:16:33 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26588 for ; Thu, 4 Oct 2001 20:16:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 23B5D53578; Thu, 4 Oct 2001 20:16:05 -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 28BA75356F for ; Thu, 4 Oct 2001 20:15:12 -0400 (EDT) Received: (qmail 62611 invoked by uid 3269); 5 Oct 2001 00:15:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62608 invoked from network); 5 Oct 2001 00:15:11 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by klesh.pair.com with SMTP; 5 Oct 2001 00:15:11 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f950EXk10034; Thu, 4 Oct 2001 17:14:33 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn2-5.cisco.com [10.21.112.5]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AGO02724; Thu, 4 Oct 2001 17:14:30 -0700 (PDT) Message-Id: <4.3.2.7.2.20011004160051.025663c0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Jeff Lotspiech" , "Dalit Naor" From: Mark Baugher Cc: smug@cs.umass.edu, ietf-idrm@lists.elistx.com, msec@securemulticast.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] draft-irtf-smug-subsetdifference-00.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 04 Oct 2001 17:13:12 -0700 Jeff, Dalit I think http://search.ietf.org/internet-drafts/draft-irtf-smug-subsetdifference-00.txt is a very important draft on key revocation. Thanks for submitting it. Anyone considering LKH or a similar type of algorithm should study subset difference. We should ask if there's any reason to use LKH or LKH+ given subset difference, which does not require a receiver to keep a history of membership changes as LKH-style algorithms do. The only issue that comes to my mind is the larger amount of initial state. I'll come back to that at the end of this note. I hope interested people take the time to read your I-D. In addition to copying smug (now gsec) your draft is of interest to other groups. It's of interest to the Internet Digital Rights Management research group because this algorithm spans both network and removable-media delivery of keying material, which is used in various copy protection schemes. In addition to IDRM, I also am copying IETF msec, which is developing key management protocols that incorporate key revocation such as LKH+. The subset-difference I-D took me a lot of time to read compared to, say, LKH, and I found it necessary to also read http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.html. I don't think we need proofs in the I-D, a well-reviewed paper should suffice, but I needed the explanation and examples from the longer work (Revocation and Traitor Tracing Schemes for Stateless Receivers - 2nl.html) to understand what you're describing in the I-D. If this work is to become the basis for standards such as a key revocation algorithm used by an MSEC key management protocol, it should be more accessible and self-contained, in my opinion. For example, "Steiner Trees" is used in the I-D but is not defined; a crisp definition of how this concept is being applied would help. I hope the next version of your draft can help the implementer by providing the detail to put the algorithm into code and validate correctness. I found the word "stateless" to be misleading since the first step to initialize a member is to install state in the form of keys. "Static state" seems to be more descriptive than "stateless." I was a bit mystified in the beginning in trying to understand the process of adding members, which is not described for good reason: The initial tree is as large as it will ever be. Every new member has a label in the tree, or one can be created on demand as you describe. But the tree gets no larger, does it? I am persuaded by your arguments that this inefficiency is probably not great since labels and keys can be dynamically generated in a Group Controller/Key Server. But we do commit to more space at the receiver than the LKH-style key revocation. This is the only downside I see at present wrt LKH. Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Oct 23 16:00:34 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18110 for ; Tue, 23 Oct 2001 16:00:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 30734535CB; Tue, 23 Oct 2001 16:00:04 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 28E7853533 for ; Tue, 23 Oct 2001 15:59:21 -0400 (EDT) Received: (qmail 64205 invoked by uid 3269); 23 Oct 2001 19:59:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 64202 invoked from network); 23 Oct 2001 19:59:20 -0000 Received: from softdnserror (HELO sj-msg-core-1.cisco.com) (171.71.163.11) by klesh.pair.com with SMTP; 23 Oct 2001 19:59:20 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9NJwrU23833; Tue, 23 Oct 2001 12:58:53 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn2-760.cisco.com [10.21.114.248]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAE12191; Tue, 23 Oct 2001 12:58:14 -0700 (PDT) Message-Id: <4.3.2.7.2.20011023125038.0432f718@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Dalit Naor" From: Mark Baugher Cc: smug@cs.umass.edu, ietf-idrm@lists.elistx.com, msec@securemulticast.org, canetti@watson.ibm.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: draft-irtf-smug-subsetdifference-00.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 23 Oct 2001 12:57:22 -0700 Dalit We are a bit late in posting information from the London meeting on our smug (now gsec) website as it is "under new management." We should get it posted soon. thanks, Mark At 11:23 AM 10/14/2001 +0300, Dalit Naor wrote: >Below are my remarks on Mark's comments regarding our I-D. The attachment >has been deleted as I hope it appears on the site soon (will be glad to >send it to whoever is interested). >Further comments are welcome. > >Regards, Dalit. > >---------------------- Forwarded by Dalit Naor/Haifa/IBM on 10/14/2001 >10:12 AM --------------------------- > > > > > >Dalit Naor >10/11/2001 03:45 PM > > >To: mbaugher@cisco.com >cc: Jeff Lotspiech/Almaden/IBM@IBMUS, canetti@watson.ibm.com, Jeffry > Ullman/Fort Lauderdale/IBM@IBMUS > >From: Dalit Naor/Haifa/IBM@IBMIL >Subject: Re: draft-irtf-smug-subsetdifference-00.txt >Importance: Normal > > > >Mark, > >Thanks for your useful comments, both on the algorithm and on the >exposition in the I-D. > >I will do my best to incorporate your suggestions (or any others, if any >arrive) into the next revision, and make it more self-contained. Since the >algorithm has been completely implemented and its specs have been written, >I believe I can also include implementation details in the next round. For >now, I am attaching a pdf file that contains slides presented by Ran >Canetti at the IRTF meeting in London. I believe these pictures and >diagrams are quite useful for understanding the algorithm's details. Is it >possible to post it on the SMuG site? > >As for your concern regarding the size of the tree, you are correct. It >should be as large as the maximum number of users throughout the lifetime >of the system. However, how large can this be? let's take a numeric >example. For the total of 4B users you need a tree of depth 32, requiring a >user to store about 500 keys. A further optimization can be done that >requires a user to store only about 300 (for the same number of users) and >adding at most 64 more keys to the message size. I recently looked at a >paper "Comparison of Hierarchical Key Distribution Schemes", by Dondeti, >Mukherjee and Samal, which looked at real-life benchmarks for group >memberships. As for as I can tell, the total number of users was not >reported explicitly, but the numbers didn't get to the billions. Do you >have any concrete examples? > >Finally please note that my email address has been changed and is now >dalit@il.ibm.com > >Below is the attached presentation. > >Regards, Dalit. > > > > > > >Mark Baugher on 10/05/2001 02:13:12 AM > >To: Jeff Lotspiech/Almaden/IBM@IBMUS, Dalit Naor/Almaden/IBM@IBMUS >cc: smug@cs.umass.edu, ietf-idrm@lists.elistx.com, > msec@securemulticast.org >Subject: draft-irtf-smug-subsetdifference-00.txt > > > >Jeff, Dalit > I think >http://search.ietf.org/internet-drafts/draft-irtf-smug-subsetdifference-00.txt > >is a very important draft on key revocation. Thanks for submitting >it. Anyone considering LKH or a similar type of algorithm should study >subset difference. We should ask if there's any reason to use LKH or LKH+ >given subset difference, which does not require a receiver to keep a >history of membership changes as LKH-style algorithms do. The only issue >that comes to my mind is the larger amount of initial state. I'll come >back to that at the end of this note. > > I hope interested people take the time to read your I-D. In addition >to copying smug (now gsec) your draft is of interest to other groups. It's >of interest to the Internet Digital Rights Management research group >because this algorithm spans both network and removable-media delivery of >keying material, which is used in various copy protection schemes. In >addition to IDRM, I also am copying IETF msec, which is developing key >management protocols that incorporate key revocation such as LKH+. > > The subset-difference I-D took me a lot of time to read compared to, >say, LKH, and I found it necessary to also read >http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.html. I don't think we >need proofs in the I-D, a well-reviewed paper should suffice, but I needed >the explanation and examples from the longer work (Revocation and Traitor >Tracing Schemes for Stateless Receivers - 2nl.html) to understand what >you're describing in the I-D. If this work is to become the basis for >standards such as a key revocation algorithm used by an MSEC key management >protocol, it should be more accessible and self-contained, in my >opinion. For example, "Steiner Trees" is used in the I-D but is not >defined; a crisp definition of how this concept is being applied would >help. I hope the next version of your draft can help the implementer by >providing the detail to put the algorithm into code and validate >correctness. > > I found the word "stateless" to be misleading since the first step to >initialize a member is to install state in the form of keys. "Static >state" seems to be more descriptive than "stateless." I was a bit >mystified in the beginning in trying to understand the process of adding >members, which is not described for good reason: The initial tree is as >large as it will ever be. Every new member has a label in the tree, or one >can be created on demand as you describe. But the tree gets no larger, >does it? I am persuaded by your arguments that this inefficiency is >probably not great since labels and keys can be dynamically generated in a >Group Controller/Key Server. But we do commit to more space at the >receiver than the LKH-style key revocation. This is the only downside I >see at present wrt LKH. > >Mark > > > > > >*******Attachment(s) have been removed******* > > >--------------------------------------------------- >--------------------------------------------------- >CONTRIBUTIONS: Mail to smug@cs.umass.edu >UNSUBSCRIBE: Send "unsubscribe smug" to majordomo@cs.umass.edu >PROBLEMS: Report to owner-smug@cs.umass.edu >TO SUBSCRIBE: Send "subscribe smug" to majordomo@cs.umass.edu _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Oct 25 11:43:35 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21887 for ; Thu, 25 Oct 2001 11:43:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B2B6B53549; Thu, 25 Oct 2001 11:41:45 -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 6240C53697 for ; Thu, 25 Oct 2001 10:55:45 -0400 (EDT) Received: (qmail 19802 invoked by uid 3269); 25 Oct 2001 14:55:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19799 invoked from network); 25 Oct 2001 14:55:44 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 25 Oct 2001 14:55:44 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f9PEtEe29152 for ; Thu, 25 Oct 2001 07:55:14 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-817.cisco.com [10.21.99.49]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAE46788; Thu, 25 Oct 2001 07:54:39 -0700 (PDT) Message-Id: <4.3.2.7.2.20011025075128.045c0960@agora.rdrop.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: msec@securemulticast.org From: Mark Baugher Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: I-D ACTION:draft-ietf-msec-gkmarch-01.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 25 Oct 2001 07:53:46 -0700 Hi We tried to address all the issues that were raised during last Summer's discussion on the group key management architecture. I'm eager to hear any comments you have on this draft. Mark >To: IETF-Announce: ; >Cc: msec@securemulticast.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-msec-gkmarch-01.txt >Date: Wed, 24 Oct 2001 07:10:58 -0400 >Sender: nsyracus@cnri.reston.va.us > >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 : Group Key Management Architecture > Author(s) : M. Baugher, R. Canetti, L. Dondeti > Filename : draft-ietf-msec-gkmarch-01.txt > Pages : 22 > Date : 23-Oct-01 > >This document presents a group key-management architecture for MSEC. >The purpose of this document is to define the common architecture for >MSEC group key-management protocols that support a variety of >application, transport, and internetwork security protocols. To >address these diverse uses, MSEC may need to standardize two or more >group key management protocols that have common requirements, >abstractions, overall design, and messages. The framework and >guidelines in this document allow for a modular and flexible design of >group key management protocols for a variety different settings that >are specialized to application needs. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-01.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-msec-gkmarch-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-msec-gkmarch-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20011023111744.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-msec-gkmarch-01.txt > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Oct 31 23:22:29 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10156 for ; Wed, 31 Oct 2001 23:22:29 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5977453550; Wed, 31 Oct 2001 23:22:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6422553532 for ; Wed, 31 Oct 2001 23:21:56 -0500 (EST) Received: (qmail 87606 invoked by uid 3269); 1 Nov 2001 04:21:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87603 invoked from network); 1 Nov 2001 04:21:55 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 1 Nov 2001 04:21:55 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fA14LIa22292; Wed, 31 Oct 2001 20:21:18 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-755.cisco.com [10.21.98.243]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAF90150; Wed, 31 Oct 2001 20:20:45 -0800 (PST) Message-Id: <4.3.2.7.2.20011031201702.01f2d450@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: smug@cs.umass.edu From: Mark Baugher Cc: msec@securemulticast.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Materials from the IETF 51 GSEC meeting Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Wed, 31 Oct 2001 20:19:49 -0800 Hello, Thanks to Thomas Hardjono for posting the minutes and presentations from our last gsec meeting on the web: http://www.securemulticast.org/index.htm. You can go directly to the materials from our London meeting at http://www.securemulticast.org/gsec-meetings.htm Best Regards, Mark & Pete _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec