From msec-admin@securemulticast.org Mon Nov 12 21:59:17 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28424 for ; Mon, 12 Nov 2001 21:59:17 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EF2F853780; Mon, 12 Nov 2001 21:58:11 -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 A082D536CC for ; Mon, 12 Nov 2001 21:56:29 -0500 (EST) Received: (qmail 90956 invoked by uid 3269); 13 Nov 2001 02:56:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90953 invoked from network); 13 Nov 2001 02:56:29 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 13 Nov 2001 02:56:29 -0000 Received: from THARDJONO-LAP.mediaone.net (dca6-tgn-zoa-vty63.as.wcom.net [216.193.41.63]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id fAD2uFk27892; Mon, 12 Nov 2001 21:56:15 -0500 (EST) Message-Id: <5.0.0.25.2.20011112215335.0255c6c8@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Call for agenda items for December-01 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 list List-Unsubscribe: , List-Archive: Date: Mon, 12 Nov 2001 21:56:34 -0500 Folks, If you have any items you want on the MSEC WG Agenda for the December-01, please email myself/Ran. Note that the IETF schedule has been posted. MSEC is on Monday 1530-1730 (Afternoon Sessions II) cheers, thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Nov 19 04:40:32 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23534 for ; Mon, 19 Nov 2001 04:40:30 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8250153560; Mon, 19 Nov 2001 04:40: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 D61BD53557 for ; Mon, 19 Nov 2001 04:38:47 -0500 (EST) Received: (qmail 35773 invoked by uid 3269); 19 Nov 2001 09:38:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35770 invoked from network); 19 Nov 2001 09:38:47 -0000 Received: from albatross-ext.wise.edt.ericsson.se (194.237.142.116) by klesh.pair.com with SMTP; 19 Nov 2001 09:38:47 -0000 Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fAJ9cjf24734 for ; Mon, 19 Nov 2001 10:38:45 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Nov 19 10:38:41 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 10:30:37 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE3EDB@esealnt416> From: "Fredrik Lindholm (ERA)" To: msec@securemulticast.org, confctrl@isi.edu Cc: "Elisabetta Carrara (ERA)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] Key Management for Multimedia Sessions Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 19 Nov 2001 10:38:26 +0100 FYI The following drafts are the continuation of the work on the "Key Management for Multimedia Sessions" draft presented in London (at the MSEC and MMUSIC sessions). The original draft has now been split between the MMUSIC WG (where key management extensions to SDP and RTSP are handled) and the MSEC WG (where the protocol itself is handled). The MSEC draft ("MIKEY: Multimedia Internet KEYing") can be found at: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-00.txt and the MMUSIC draft ("Key Management Extensions for SDP and RTSP") can be found at: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-00.txt We would appreciate any comments. Fredrik & Elisabetta _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Nov 20 12:25:19 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21717 for ; Tue, 20 Nov 2001 12:25:19 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7A32853B7F; Tue, 20 Nov 2001 12:24:25 -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 9330D539B4 for ; Tue, 20 Nov 2001 12:17:50 -0500 (EST) Received: (qmail 62971 invoked by uid 3269); 20 Nov 2001 17:17:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62968 invoked from network); 20 Nov 2001 17:17:49 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 20 Nov 2001 17:17:49 -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 fAKHHDO09568; Tue, 20 Nov 2001 12:17:13 -0500 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 fAKHHDU23010; Tue, 20 Nov 2001 12:17:13 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id MAA35718; Tue, 20 Nov 2001 12:17:13 -0500 From: Ran Canetti Message-Id: <200111201717.MAA35718@ornavella.watson.ibm.com> To: msec@securemulticast.org Cc: thardjono@mediaone.net Subject: [MSEC] Advancing GDOI to proposed standard? 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, 20 Nov 2001 12:17:13 -0500 Folks, There have been proposals to advance the GDOI draft to proposed standard. Indeed, the draft has been stable for a while and there are two independent implementations (Cisco and Nortel) in advanced stages. Thomas and I would like to "test the waters" for this proposal. What do people think? If there are no substantial objections then we would start a last-call process shortly. Ran and Thomas _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Nov 20 13:59:16 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28755 for ; Tue, 20 Nov 2001 13:59:15 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2A6DF53BBC; Tue, 20 Nov 2001 13:54:33 -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 2D73353BC6 for ; Tue, 20 Nov 2001 13:51:38 -0500 (EST) Received: (qmail 72599 invoked by uid 3269); 20 Nov 2001 18:51:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72596 invoked from network); 20 Nov 2001 18:51:07 -0000 Received: from chmls06.mediaone.net (24.147.1.144) by klesh.pair.com with SMTP; 20 Nov 2001 18:51:07 -0000 Received: from THARDJONO-LAP.mediaone.net (1Cust37.tnt11.bos2.da.uu.net [63.42.57.37]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id fAKIpi828276; Tue, 20 Nov 2001 13:51:44 -0500 (EST) Message-Id: <5.0.0.25.2.20011120124547.01d2a360@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: thardjono@yahoo.com, canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MSEC review: current status & schedule 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, 20 Nov 2001 13:51:23 -0500 Folks, We are half-way through MSEC's time-schedule, and I am somewhat concerned that we will not be on time with our list of deliverables. I think meeting deadlines are a good thing, though understandably certain drafts may lag behind. Independent of individual drafts, I think MSEC should try to meet its final deadline of December 2002. When we asked for the creation of the MSEC WG it was made clear that Working Groups have a defined life-span. In the case of MSEC, I understood this to mean Dec 2002, at which time the WG has to disband or recharter. The MSEC charter was written to be specific in its schedule of deliverables: (1) An informational RFC describing the security requirements and problem-space for group and multicast security for one-to-many communications. This RFC will be based on draft-irtf-smug-taxonomy-01.txt. (2) An informational RFC that specifies the overall framework for the solution. This includes specifying the general functionality of the building blocks and their inter-relations. This RFC will be based on draft-irtf-smug-framework-01.txt. (3) RFCs detailing the structure and functionality of each building block. These RFCs will be based on: - draft-irtf-smug-data-transforms-00.txt - draft-irtf-smug-gkmbb-gsadef-01.txt - draft-irtf-smug-mcast-policy-01.txt (4) Standards-track RFCs describing specific protocols that instantiate each one of the functional building blocks. At least one protocol for instantiating each building block will be standardized. Some of these RFCs will be based on: - draft-irtf-smug-gdoi-00.txt - draft-harney-sparta-gsakmp-sec-02.txt - draft-irtf-smug-tesla-00.txt I think items (1) and (2) is mostly written and are architectural in nature, thus not too burdensome. Item (3) refers to the so called "building block" drafts. Out of the smug-drafts listed in item (3), the gkmbb-gsadef draft has been carried-over into the new GKM architecture draft (ie. draft-ietf-msec-gkmarch-00.txt). The issue of whether a separate Re-Key protocol is needed and how to document it, still needs to be clarified. The Group Policy material still needs further work, with the latest draft being the Group Security Policy Token (GSPT). As far as I know, the Data Transforms draft (smug-data-transforms) has expired. Item (3) refers to "instantiations" of the building blocks, in the form of actual protocols: - The GDOI draft is current, and I am told that implementations are almost done. - The GSAKMP draft is up to date, and a Lite version has been published. - The TESLA draft has not been submitted as an MSEC draft (as far as I know). The following is the schedule as of Nov01: Nov 01 Initial Drafts on protocols for instantiating the functional building blocks (item 4 above). Dec 01 IETF-52: Presentation of protocol drafts.<------ WE ARE HERE Feb 02 Complete building-block drafts WG Last-Call and submit as Proposed Standard. Mar 02 Second Review of protocol drafts. Jul 02 Third review of protocol drafts. Dec 02 Final review of protocol drafts. Dec 02 Complete protocol drafts WG Last-Call and submit as Proposed Standard. Dec 02 WG disband or re-charter for other work items. cheers, thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Nov 20 14:04:26 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29186 for ; Tue, 20 Nov 2001 14:04:26 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 390C553BDC; Tue, 20 Nov 2001 14:00:19 -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 04FF453569 for ; Sun, 14 Oct 2001 04:24:41 -0400 (EDT) Received: (qmail 31176 invoked by uid 3269); 14 Oct 2001 08:24:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 31173 invoked from network); 14 Oct 2001 08:24:40 -0000 Received: from d12lmsgate-2.de.ibm.com (195.212.91.200) by klesh.pair.com with SMTP; 14 Oct 2001 08:24:40 -0000 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id KAA62352; Sun, 14 Oct 2001 10:23:54 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f9E8Ne338198; Sun, 14 Oct 2001 10:23:42 +0200 Importance: Normal To: smug@cs.umass.edu, ietf-idrm@lists.elistx.com, msec@securemulticast.org Cc: mbaugher@cisco.com, canetti@watson.ibm.com X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: "Dalit Naor" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/10/2001 11:23:53 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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: Sun, 14 Oct 2001 11:23:08 +0300 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******* _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Nov 20 14:05:43 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29257 for ; Tue, 20 Nov 2001 14:05:42 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E5D2653BE0; Tue, 20 Nov 2001 14:00:20 -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 4B3E753533 for ; Wed, 24 Oct 2001 07:11:14 -0400 (EDT) Received: (qmail 49349 invoked by uid 3269); 24 Oct 2001 11:11:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49346 invoked from network); 24 Oct 2001 11:11:07 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 24 Oct 2001 11:11:07 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20930; Wed, 24 Oct 2001 07:10:58 -0400 (EDT) Message-Id: <200110241110.HAA20930@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-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: Wed, 24 Oct 2001 07:10:58 -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 : 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. --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: <20011023111744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gkmarch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gkmarch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011023111744.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 Nov 20 14:06:59 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29317 for ; Tue, 20 Nov 2001 14:06:59 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A29EA53BE4; Tue, 20 Nov 2001 14:00:22 -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 2987853564 for ; Wed, 14 Nov 2001 07:02:58 -0500 (EST) Received: (qmail 96376 invoked by uid 3269); 14 Nov 2001 12:02:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96373 invoked from network); 14 Nov 2001 12:02:57 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 14 Nov 2001 12:02:57 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18691; Wed, 14 Nov 2001 07:02:48 -0500 (EST) Message-Id: <200111141202.HAA18691@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-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: Wed, 14 Nov 2001 07:02:48 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : MIKEY: Multimedia Internet KEYing Author(s) : J. Arkko et al. Filename : draft-ietf-msec-mikey-00.txt Pages : 37 Date : 13-Nov-01 Work for securing real-time applications have started to appear. This has brought forward the need for a key management solution to support the security protocol. The key management has to fulfil requirements, which makes it suitable 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mikey-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mikey-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011113143855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011113143855.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 Nov 20 14:10:03 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29579 for ; Tue, 20 Nov 2001 14:10:03 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8613453BE8; Tue, 20 Nov 2001 14:00:24 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4FFF15396E for ; Tue, 20 Nov 2001 07:15:44 -0500 (EST) Received: (qmail 36051 invoked by uid 3269); 20 Nov 2001 12:15:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36048 invoked from network); 20 Nov 2001 12:15:43 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 20 Nov 2001 12:15:43 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05062; Tue, 20 Nov 2001 07:15:34 -0500 (EST) Message-Id: <200111201215.HAA05062@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-gspt-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: Tue, 20 Nov 2001 07:15:33 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : Group Security Policy Token Author(s) : T. Hardjono et al. Filename : draft-ietf-msec-gspt-01.txt Pages : 26 Date : 19-Nov-01 This document provides a definition for Group Security Policy, describes the set of elements that make-up an instance of group policy for a given group, and provides an explanation of the intended functions of each element of a group security policy as expressed in the form of the Policy Token or Policy Certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gspt-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-gspt-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-gspt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011119141206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gspt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gspt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011119141206.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Nov 21 11:21:38 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22708 for ; Wed, 21 Nov 2001 11:21:38 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 268AA53561; Wed, 21 Nov 2001 11:20:38 -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 305515354A for ; Wed, 21 Nov 2001 11:14:44 -0500 (EST) Received: (qmail 88975 invoked by uid 3269); 21 Nov 2001 16:14:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88972 invoked from network); 21 Nov 2001 16:14:44 -0000 Received: from chmls20.mediaone.net (24.147.1.156) by klesh.pair.com with SMTP; 21 Nov 2001 16:14:44 -0000 Received: from THARDJONO-LAP.mediaone.net (1Cust253.tnt11.bos2.da.uu.net [63.42.57.253]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id fALGFkx15904 for ; Wed, 21 Nov 2001 11:15:47 -0500 (EST) Message-Id: <5.0.0.25.2.20011121103543.018df188@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] New time for MSEC at IETF52 Salt Lake City 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, 21 Nov 2001 10:38:33 -0500 Folks, It seems MSEC has been moved to Friday Dec/14: FRIDAY, December 14, 2001 0900-1130 Morning Sessions Please keep checking the IETF site as the agenda can still move around. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Nov 25 00:18:33 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00406 for ; Sun, 25 Nov 2001 00:18:33 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 02BE4538D5; Sun, 25 Nov 2001 00:18:03 -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 2F701538BB for ; Sun, 25 Nov 2001 00:17:59 -0500 (EST) Received: (qmail 9023 invoked by uid 3269); 25 Nov 2001 05:17:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9020 invoked from network); 25 Nov 2001 05:17:58 -0000 Received: from unknown (HELO bjapp3.163.net) (202.108.255.195) by klesh.pair.com with SMTP; 25 Nov 2001 05:17:58 -0000 Received: by bjapp3.163.net (Postfix, from userid 1005) id 8362D1D09ECF4; Sun, 25 Nov 2001 13:17:57 +0800 (CST) MIME-Version: 1.0 Message-Id: <3C007F05.06511@bjapp3> From: "熊继平" To: msec@securemulticast.org X-Priority: 3 X-Originating-IP: [211.90.180.11] X-Mailer: COREMAIL Subject: [MSEC] =?gb2312?B?a2V5IG1hbmFnZW1lbnQgdXNpbmcgUEtJ?= Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sun, 25 Nov 2001 13:17:57 +0800 (CST) I am interesting in the security of multicast and want to do some work on it. I wonder if there are anywork on the key management using PKI? your sincerely xiong_ji_ping xiongjiping@163.net 加薪，升职密笈 http://www.englishtown.com/master/home/courseoverview.asp?etag=TOCN&ctr=cn =============================================== 我要用手机收邮件!!! —— 163“随身邮”手机邮箱 —— ◎ 手机号码就是电子邮箱地址，方便记忆 ◎ 不用上网，透过手机短信，随时掌握邮件的接收情况 ◎ 决不错过任何商业良机 ◎ 方便的按月收费方式，最低每月只需5元 详情请浏览 http://vip.163.net/mobile/mobile.htm =============================================== _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Nov 26 11:31:45 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08983 for ; Mon, 26 Nov 2001 11:31:44 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A3E0453560; Mon, 26 Nov 2001 11:29:16 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 87B12538B8 for ; Mon, 26 Nov 2001 11:06:33 -0500 (EST) Received: (qmail 76860 invoked by uid 3269); 26 Nov 2001 16:06:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76855 invoked from network); 26 Nov 2001 16:06:32 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 26 Nov 2001 16:06:32 -0000 Received: from sp1n293en1.watson.ibm.com ([9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id fAMJvWO35878 for ; Thu, 22 Nov 2001 15:02:32 -0500 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 fAMJsvU27826 for ; Thu, 22 Nov 2001 14:54:57 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id OAA33770 for msec@securemulticast.org; Thu, 22 Nov 2001 14:54:56 -0500 From: Ran Canetti Message-Id: <200111221954.OAA33770@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [MSEC] Comments on MIKEY 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 list List-Unsubscribe: , List-Archive: Date: Thu, 22 Nov 2001 14:54:56 -0500 I read the MIKEY draft () and thought that it is well-written, a pleasure to read. It also seems technically and cryptographically sound in general. (Most glitchs from the previous version were indeed fixed.) Some remarks, nonetheless: - My main concern regarding the applicability of MIKEY is still the fact that it inherently uses timestamps for liveness. Indeed, timestamps are used in telephony and also on small scale on the internet (kerberos/kink), but this is the first time that they are suggested for a large scale protocol, based on PKI, and without prior coordination between the two endpoints. This brings in the issue of how synchronized the clocks should be required to be. If I understand correctly, the approach taken by MIKEY is to have each partner keep a cache of the messages received in the past X time units, and discard an incoming message if it is a replay of a message in the cache. This means that the cache should be large enough to contain all received messages within the last X time units, where X is at least as large as the allowed clock skew. This puts a clear tradeoff between memory/state size and the amount of synchronization required. I guess only time and experience will tell whether there is a viable solution to this tradeoff that can work on a large scale. - Section 3.3 (Diffie-Hellman): you dont say what this type of exchange buys that the previous one does not. The answer seems to be that it buys forward secrecy. Please discuss. - You mention the notion of a multimedia crypto session that contains several "simple" crypto sessions. It may be helpful to use the notion of a "session bundle" where all sessions in the bundle use the same MIKEY exchange and the same rekey protocol. Finally, it should be interesting to see how MIKEY would fit into the GKMARCH framework - perhaps as another "registration protocol", or perhaps otherwise. Best, Ran BTW, are you aware of an implementation effort of MIKEY? _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Nov 26 15:10:20 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26721 for ; Mon, 26 Nov 2001 15:10:19 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0526F535E4; Mon, 26 Nov 2001 15:09:09 -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 1A2E3535E6 for ; Fri, 23 Nov 2001 09:07:33 -0500 (EST) Received: (qmail 18398 invoked by uid 3269); 23 Nov 2001 14:07:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18393 invoked from network); 23 Nov 2001 14:07:32 -0000 Received: from lorraine.loria.fr (152.81.1.17) by klesh.pair.com with SMTP; 23 Nov 2001 14:07:32 -0000 Received: from loria.fr (dolcourt.loria.fr [152.81.11.87]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with ESMTP id PAA12245 for ; Fri, 23 Nov 2001 15:07:24 +0100 (MET) Message-ID: <3BFE581C.2398B843@loria.fr> From: Ghassan Chaddoud Organization: LORIA X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org References: <200111161547.KAA06493@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access Control Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Fri, 23 Nov 2001 15:07:24 +0100 Content-Transfer-Encoding: 7bit Hi, I have two comments on this draft: 1) in 4.2. The host IP address is used, in the access token,to prevent another host outside the same network to use the same access token. Why you don't replace the IP address by the network ID ( a prefixe), such that the host can use dynamic configuration (ie DHCP). 2) in 2.2. ... End-to-end data encryption ensures data integrity, source authentication, and data confidentiality: I am not sure that in the case of multicast (n-to-n), end-to-end data encryption can ensure source authentication! Regards -- Ghassan CHADDOUD LORIA/INRIA _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Nov 26 15:11:23 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26828 for ; Mon, 26 Nov 2001 15:11:22 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9BC0B535E8; Mon, 26 Nov 2001 15:09:11 -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 38323537CD for ; Sat, 24 Nov 2001 07:13:57 -0500 (EST) Received: (qmail 22430 invoked by uid 3269); 24 Nov 2001 12:13:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 22425 invoked from network); 24 Nov 2001 12:13:56 -0000 Received: from unknown (HELO mx1.ustc.edu.cn) (61.132.182.1) by klesh.pair.com with SMTP; 24 Nov 2001 12:13:56 -0000 Received: from HUPENG (infonet.ustc.edu.cn [202.38.75.11]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id UAA12230 for ; Sat, 24 Nov 2001 20:48:42 -0800 Message-Id: <200111250448.UAA12230@mx1.ustc.edu.cn> From: jpxiong To: "msec@securemulticast.org" X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [MSEC] (no subject) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 24 Nov 2001 20:13:26 +0800 Content-Transfer-Encoding: 7bit I am interesting in the security of multicast and want to do some work on it. I wonder if there are anywork on the key management using PKI? your sincerely xiong_ji_ping xiongjiping@163.net _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Nov 26 15:12:46 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26955 for ; Mon, 26 Nov 2001 15:12:45 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 72DA4535EC; Mon, 26 Nov 2001 15:09:14 -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 0122B537DE for ; Sat, 24 Nov 2001 07:33:59 -0500 (EST) Received: (qmail 23649 invoked by uid 3269); 24 Nov 2001 12:33:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23646 invoked from network); 24 Nov 2001 12:33:58 -0000 Received: from unknown (HELO mx1.ustc.edu.cn) (61.132.182.1) by klesh.pair.com with SMTP; 24 Nov 2001 12:33:58 -0000 Received: from HUPENG (infonet.ustc.edu.cn [202.38.75.11]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id VAA12879 for ; Sat, 24 Nov 2001 21:15:36 -0800 Message-Id: <200111250515.VAA12879@mx1.ustc.edu.cn> From: jpxiong To: "msec@securemulticast.org" X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [MSEC] key management using PKI Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Sat, 24 Nov 2001 20:40:20 +0800 Content-Transfer-Encoding: 7bit I am interesting in the security of multicast and want to do some work on it. I wonder if there are anywork on the key management using PKI? your sincerely xiong_ji_ping xiongjiping@163.net _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Nov 26 15:13:50 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27030 for ; Mon, 26 Nov 2001 15:13:49 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 17408535F0; Mon, 26 Nov 2001 15:09:16 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id F10FE53535 for ; Mon, 26 Nov 2001 12:07:39 -0500 (EST) Received: (qmail 83252 invoked by uid 3269); 26 Nov 2001 17:07:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83233 invoked from network); 26 Nov 2001 17:07:34 -0000 Received: from ebene.inrialpes.fr (194.199.18.70) by klesh.pair.com with SMTP; 26 Nov 2001 17:07:34 -0000 Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id fAQH3Ki26741; Mon, 26 Nov 2001 18:03:20 +0100 (MET) Message-ID: <3C0275D9.484A2A4@inrialpes.fr> From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org, ipng@sunroof.eng.sun.com, smug@cs.umass.edu, gab@sun.com Content-Type: multipart/alternative; boundary="------------BD75A96D98BC6F2A58B220B2" Subject: [MSEC] Securing Group Management in IPv6 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 26 Nov 2001 18:03:21 +0100 --------------BD75A96D98BC6F2A58B220B2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, We have just released a new draft entitled "Securing Group Management in IPv6". Unfortunatly we've missed the IETF submission deadline but we'll submit it asap. This draft can be downloaded at: http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-sgmv6-00.txt We are looking forward your comments/feedbacks.... Thanks in advance... Regards, Claude. ====== Abstract Currently, group membership management in IP multicast and anycast lacks sufficient security. It can be abused by malicious hosts in order to launch denial-of-service (DoS) attacks. The root of the problem is that routers cannot determine if a given host is authorized to join a group, sometimes referred to as the Proof-of-Membership Problem We propose a solution for IPv6 based on new types of multicast and anycast group addresses which we respectively call SUCV-M and SUCV-A addresses. Their statistical and cryptographic characteristics lend themselves to severely limiting certain classes of attacks. Our scheme is fully distributed and does not require any third trusted party or pre-established security association between the routers and the hosts. This is not only a huge gain in terms of scalability, reliability and overhead, but also in terms of privacy. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------BD75A96D98BC6F2A58B220B2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Dear all,

We have just released a new draft  entitled "Securing Group Management in IPv6".
Unfortunatly we've missed the IETF submission deadline but we'll submit it
asap.

This draft can be downloaded at:
http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-sgmv6-00.txt

We are looking forward your comments/feedbacks....

Thanks in advance...
Regards,
Claude.

======

  Abstract

   Currently, group membership management in IP multicast and
   anycast lacks sufficient security.  It can be abused by
   malicious hosts in order to launch denial-of-service (DoS)
   attacks.  The root of the problem is that routers cannot
   determine if a given host is authorized to join a group,
   sometimes referred to as the  Proof-of-Membership Problem
    We propose a solution for IPv6 based on new types of
   multicast and anycast group addresses which we respectively call
   SUCV-M and SUCV-A addresses. Their statistical and cryptographic
   characteristics lend themselves to severely limiting certain
   classes of attacks.  Our scheme is fully distributed and does
   not require any third trusted party or pre-established security
   association between the routers and the hosts.  This is not only
   a huge gain in terms of scalability, reliability and overhead,
   but also in terms of privacy. 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------BD75A96D98BC6F2A58B220B2-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Nov 26 17:05:13 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05768 for ; Mon, 26 Nov 2001 17:05:11 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4672B5356A; Mon, 26 Nov 2001 17:04:44 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2F22253551 for ; Mon, 26 Nov 2001 17:02:06 -0500 (EST) Received: (qmail 15808 invoked by uid 3269); 26 Nov 2001 22:02:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15805 invoked from network); 26 Nov 2001 22:02:05 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 26 Nov 2001 22:02:05 -0000 Received: from THARDJONO-LAP.mediaone.net (1Cust218.tnt30.bos2.da.uu.net [63.36.195.218]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id fAQM1u108286; Mon, 26 Nov 2001 17:01:57 -0500 (EST) Message-Id: <5.0.0.25.2.20011126162841.0191d880@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Tentative agenda for MSEC at IETF52 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 26 Nov 2001 16:44:32 -0500 Folks, Here is a tentative Agenda for the MSEC WG meeting at IETF52 in Salt Lake City (Dec 2001): - Review of WG Status (T. Hardjono/R. Canetti) - GKM Architecture (L.Dondeti) - Group Security Policy Token (T. Hardjono/P. McDaniel) - Rekey protocol (L. Dondeti/M. Baugher) - MIKEY (F. Lindholm/E. Carrara) - GDOI Implementation (Cisco/Nortel) - Discussion: Last call for GDOI Please email Ran/Thomas for corrections/additions. Note that MSEC will now meet on: FRIDAY, December 14, 2001 0900-1130 Morning Sessions Our apologies for this scheduling. This last-minute "bump" was beyond our control. cheers, thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Nov 26 17:05:32 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05813 for ; Mon, 26 Nov 2001 17:05:32 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 60DA5535A7; Mon, 26 Nov 2001 17:04:47 -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 EDB0153581 for ; Mon, 26 Nov 2001 17:02:12 -0500 (EST) Received: (qmail 15821 invoked by uid 3269); 26 Nov 2001 22:02:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15818 invoked from network); 26 Nov 2001 22:02:12 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 26 Nov 2001 22:02:12 -0000 Received: from THARDJONO-LAP.mediaone.net (1Cust218.tnt30.bos2.da.uu.net [63.36.195.218]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id fAQM21108399; Mon, 26 Nov 2001 17:02:01 -0500 (EST) Message-Id: <5.0.0.25.2.20011126164440.0223a7a0@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Ghassan Chaddoud , msec@securemulticast.org From: Thomas Hardjono Subject: Re: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access Control In-Reply-To: <3BFE581C.2398B843@loria.fr> References: <200111161547.KAA06493@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Mon, 26 Nov 2001 16:57:57 -0500 At 11/23/2001||03:07 PM, Ghassan Chaddoud wrote: >Hi, >I have two comments on this draft: > >1) in 4.2. > >The host IP address is used, in the access token,to prevent another host >outside the same network to use the same access token. Why you don't >replace the IP address by the network ID ( a prefixe), such that the >host can use dynamic configuration (ie DHCP). Actually, the aim is to prevent another host *inside* the same network to initiate a join to a group that previously did not have any membership in that (non-member) host's subnet. Thus, the two problems are: - preventing illegal "First Joins", which pulls the multicast distribution tree to a subnet that has no members. - preventing illegal "Last prunes", which prunes the multicast distribution tree from a subnet that still has members. >2) in 2.2. >... End-to-end data encryption ensures data integrity, source >authentication, and data confidentiality: >I am not sure that in the case of multicast (n-to-n), end-to-end data >encryption can ensure source authentication! Correct. End-to-End encryption with a symmetric key will not provide source-authentication. However, the aim of the draft is provide member access control at the routing level, above which (or on which) encrypted data flows. This draft is only one part of 3-part solution that is needed to provide security for IP multicast: 1. Sender and Receiver access control (from the edge of the network to the distribution tree). 2. Multicast routing protection (to ensure multicast control packets are authentic and thus preserves the correct routing behavior) 3. Data/content protection (in the form of encryption, accompanied by the group key management protocol, etc.). cheers, thomas ------ >Regards > >-- >Ghassan CHADDOUD > >LORIA/INRIA > >_______________________________________________ >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 Tue Nov 27 05:06:37 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17573 for ; Tue, 27 Nov 2001 05:06:36 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2ACF353699; Tue, 27 Nov 2001 05:06:06 -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 1EAE153693 for ; Tue, 27 Nov 2001 05:02:46 -0500 (EST) Received: (qmail 91958 invoked by uid 3269); 27 Nov 2001 10:02:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91955 invoked from network); 27 Nov 2001 10:02:40 -0000 Received: from penguin-ext.wise.edt.ericsson.se (194.237.142.110) by klesh.pair.com with SMTP; 27 Nov 2001 10:02:40 -0000 Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fARA2Xf17713 for ; Tue, 27 Nov 2001 11:02:33 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Nov 27 11:01:35 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Nov 2001 10:53:20 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE3EF8@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Ran Canetti'" , msec@securemulticast.org Subject: RE: [MSEC] Comments on MIKEY draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Tue, 27 Nov 2001 11:01:16 +0100 Ran, thank you very much for the comments! (see my comments below) > > I read the MIKEY draft () > and thought that it is well-written, a pleasure to read. > It also seems technically and cryptographically sound in general. > (Most glitchs from the previous version were indeed fixed.) > Some remarks, nonetheless: > > - My main concern regarding the applicability of MIKEY is > still the fact > that it inherently uses timestamps for liveness. Indeed, > timestamps are > used in telephony and also on small scale on the internet > (kerberos/kink), > but this is the first time that they are suggested for a large scale > protocol, based on PKI, and without prior coordination between the two > endpoints. This brings in the issue of how synchronized the > clocks should be > required to be. > > If I understand correctly, the approach taken by MIKEY is to > have each > partner keep a cache of the messages received in the past X > time units, > and discard an incoming message if it is a replay of a > message in the cache. > This means that the cache should be large enough to contain > all received > messages within the last X time units, where X is at least as > large as > the allowed clock skew. This puts a clear tradeoff between > memory/state > size and the amount of synchronization required. I guess only > time and > experience will tell whether there is a viable solution to > this tradeoff > that can work on a large scale. > Yes, that's what we hope the new draft explains better. The use of timestamps may of course raise some concern. However, we believe that it is possible to use timestamps in certain scenarios (as the ones that MIKEY addresses). > - Section 3.3 (Diffie-Hellman): you dont say what this type > of exchange buys > that the previous one does not. The answer seems to be that > it buys forward > secrecy. Please discuss. > Sure > - You mention the notion of a multimedia crypto session that contains > several "simple" crypto sessions. It may be helpful to use > the notion of a > "session bundle" where all sessions in the bundle use the same MIKEY > exchange and the same rekey protocol. > Ok > > Finally, it should be interesting to see how MIKEY would fit > into the GKMARCH > framework - perhaps as another "registration protocol", or perhaps > otherwise. > Indeed, and I think it will be feasible to fit MIKEY into the GKMARCH framework. > > Best, > > Ran > > BTW, are you aware of an implementation effort of MIKEY? We are of course implementing MIKEY together with SRTP in a SIP client. For the moment, I am not aware of any other implementation effort. Thanks, Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Nov 27 11:07:04 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05971 for ; Tue, 27 Nov 2001 11:07:03 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 182AA535A1; Tue, 27 Nov 2001 11:05:49 -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 538C35352D for ; Tue, 27 Nov 2001 10:56:30 -0500 (EST) Received: (qmail 25767 invoked by uid 3269); 27 Nov 2001 15:56:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25764 invoked from network); 27 Nov 2001 15:56:27 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 27 Nov 2001 15:56:27 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fARFtHd15121 for ; Tue, 27 Nov 2001 10:55:17 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 27 Nov 2001 10:55:47 -0500 Received: from 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 XRD2WCA8; Tue, 27 Nov 2001 10:54:37 -0500 Received: from nortelnetworks.com (ELTON-THINKPAD [47.16.67.108]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XRGWZM9M; Tue, 27 Nov 2001 10:54:31 -0500 Message-ID: <3C03B6BF.1D250899@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Haixiang He" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh,zh-CN,zh-TW MIME-Version: 1.0 To: Ghassan Chaddoud Cc: msec@securemulticast.org Subject: Re: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access Control References: <200111161547.KAA06493@ietf.org> <3BFE581C.2398B843@loria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: 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, 27 Nov 2001 10:52:31 -0500 Content-Transfer-Encoding: 7bit Ghassan Chaddoud wrote: > Hi, > I have two comments on this draft: > > 1) in 4.2. > > The host IP address is used, in the access token,to prevent another host > outside the same network to use the same access token. Why you don't > replace the IP address by the network ID ( a prefixe), such that the > host can use dynamic configuration (ie DHCP). What do you gain by using prefix? Do you mean after the host get the Access Token, the host may change its IP address? > > > 2) in 2.2. > ... End-to-end data encryption ensures data integrity, source > authentication, and data confidentiality: > I am not sure that in the case of multicast (n-to-n), end-to-end data > encryption can ensure source authentication! I mean group authentication here. My mistake! Haixiang > > > Regards > > -- > Ghassan CHADDOUD > > LORIA/INRIA > > _______________________________________________ > 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 Wed Nov 28 09:18:40 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09210 for ; Wed, 28 Nov 2001 09:18:39 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0E484536FD; Wed, 28 Nov 2001 09:18:12 -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 56681535B8 for ; Wed, 28 Nov 2001 04:06:31 -0500 (EST) Received: (qmail 36979 invoked by uid 3269); 28 Nov 2001 09:06:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36976 invoked from network); 28 Nov 2001 09:06:30 -0000 Received: from lorraine.loria.fr (152.81.1.17) by klesh.pair.com with SMTP; 28 Nov 2001 09:06:30 -0000 Received: from loria.fr (dolcourt.loria.fr [152.81.11.87]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with ESMTP id KAA26013; Wed, 28 Nov 2001 10:06:21 +0100 (MET) Message-ID: <3C04A90C.3CDF805C@loria.fr> From: Ghassan Chaddoud Organization: LORIA X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Haixiang He Cc: msec@securemulticast.org Subject: Re: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access Control References: <200111161547.KAA06493@ietf.org> <3BFE581C.2398B843@loria.fr> <3C03B6BF.1D250899@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 list List-Unsubscribe: , List-Archive: Date: Wed, 28 Nov 2001 10:06:20 +0100 Content-Transfer-Encoding: 7bit Haixiang He wrote: > > Ghassan Chaddoud wrote: > > > Hi, > > I have two comments on this draft: > > > > 1) in 4.2. > > > > The host IP address is used, in the access token,to prevent another host > > outside the same network to use the same access token. Why you don't > > replace the IP address by the network ID ( a prefixe), such that the > > host can use dynamic configuration (ie DHCP). > > What do you gain by using prefix? Do you mean after the host get the Access > Token, the host may change its IP address? I mean if the host obtains an access token for an IP address A1, then if this host reboots and uses DHCP, its new address, A2, would be different from A1. Consequently it will not be capable to join another groups. And, since the access token, is used to prevent another host *outside* the same network to use the same access token. You do't care about hosts *inside* the network. For this reason, the use of prefix ( a prefix could represent the set of addresses used by DHCP, if it is used) can resolve the problem of dynamic configuration of hosts. Ghassan _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Nov 28 12:08:07 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21832 for ; Wed, 28 Nov 2001 12:08:06 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F23C253835; Wed, 28 Nov 2001 11:57:00 -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 27C0D53561 for ; Wed, 28 Nov 2001 10:41:58 -0500 (EST) Received: (qmail 72250 invoked by uid 3269); 28 Nov 2001 15:41:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72247 invoked from network); 28 Nov 2001 15:41:57 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 28 Nov 2001 15:41:57 -0000 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fASFehd25725 for ; Wed, 28 Nov 2001 10:40:43 -0500 (EST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Wed, 28 Nov 2001 10:40:55 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XXVB4JFD; Wed, 28 Nov 2001 10:39:48 -0500 Received: from nortelnetworks.com (elton-thinkpad.us.nortel.com [47.16.67.108]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XRGWZ3V5; Wed, 28 Nov 2001 10:39:50 -0500 Message-ID: <3C0504CD.11D08126@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Haixiang He" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh,zh-CN,zh-TW MIME-Version: 1.0 To: Ghassan Chaddoud Cc: "Haixiang He" , msec@securemulticast.org Subject: Re: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access Control References: <200111161547.KAA06493@ietf.org> <3BFE581C.2398B843@loria.fr> <3C03B6BF.1D250899@nortelnetworks.com> <3C04A90C.3CDF805C@loria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: 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, 28 Nov 2001 10:37:49 -0500 Content-Transfer-Encoding: 7bit > > > I mean if the host obtains an access token for an IP address A1, then if > this host reboots and uses DHCP, its new address, A2, would be > different from A1. Consequently it will not be capable to join another > groups. And, since the access token, is used to prevent another host > *outside* the same network to use the same access token. You do't care > about hosts *inside* the network. For this reason, the use of prefix ( a > prefix could represent the set of addresses used by DHCP, if it is used) > can resolve the problem of dynamic configuration of hosts. I did not think about this scenario in greater details. The problem with using prefix is that it does not work well with switch network such as switch ethernet. In switch network, two hosts connecting two different ports may have the same prefix. And also we did not try to apply this solution for mobile node at this time. Haixiang > > > Ghassan _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Nov 28 13:51:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29992 for ; Wed, 28 Nov 2001 13:51:54 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 328F6537F5; Wed, 28 Nov 2001 13:50:40 -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 24D29537FD for ; Wed, 28 Nov 2001 13:47:22 -0500 (EST) Received: (qmail 91806 invoked by uid 3269); 28 Nov 2001 18:47:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91801 invoked from network); 28 Nov 2001 18:47:21 -0000 Received: from mantrade-bh.mandtbank.com (HELO comrcmailxxxn02.mandtbank.com) (12.19.225.250) by klesh.pair.com with SMTP; 28 Nov 2001 18:47:21 -0000 Received: from mandtbank.com (unverified) by comrcmailxxxn02.mandtbank.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 28 Nov 2001 13:43:38 -0500 Received: from INTERNET-DMZ-Message_Server by mandtbank.com with Novell_GroupWise; Wed, 28 Nov 2001 13:46:14 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 From: "Michael Germony" To: Cc: , Subject: Re: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access Control 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 list List-Unsubscribe: , List-Archive: Date: Wed, 28 Nov 2001 13:46:04 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA29992 Ghassan and Haixiang, According to my understanding of the DHCP RFC, the only way that a client would loose its IP address after it reboots is if during the time it rebooted the DHCP server issued the same IP address to another client (likely only in extremely small or busy scopes) OR if the duration of the reboot exceeded 50% of the lease time defined in the scope. Otherwise it will get the same address issued. The only other possible way that it would get a different DHCP address is if the DHCP server's scope cache was flushed. Either way, wouldn't the reboot presumably cause the token to be released? Regards, Michael Germony Web Architecture Services mgermony@mandtbank.com >>> "Haixiang He" 11/28/01 10:37AM >>> > > > I mean if the host obtains an access token for an IP address A1, then if > this host reboots and uses DHCP, its new address, A2, would be > different from A1. Consequently it will not be capable to join another > groups. And, since the access token, is used to prevent another host > *outside* the same network to use the same access token. You do't care > about hosts *inside* the network. For this reason, the use of prefix ( a > prefix could represent the set of addresses used by DHCP, if it is used) > can resolve the problem of dynamic configuration of hosts. I did not think about this scenario in greater details. The problem with using prefix is that it does not work well with switch network such as switch ethernet. In switch network, two hosts connecting two different ports may have the same prefix. And also we did not try to apply this solution for mobile node at this time. Haixiang > > > Ghassan _______________________________________________ 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 Wed Nov 28 14:34:47 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03325 for ; Wed, 28 Nov 2001 14:34:46 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A3A2753798; Wed, 28 Nov 2001 14:34:19 -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 D6D1753569 for ; Wed, 28 Nov 2001 14:32:47 -0500 (EST) Received: (qmail 97057 invoked by uid 3269); 28 Nov 2001 19:32:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97051 invoked from network); 28 Nov 2001 19:32:47 -0000 Received: from softdnserror (HELO loki.coradiant.com) (199.84.5.37) by klesh.pair.com with SMTP; 28 Nov 2001 19:32:47 -0000 Subject: Re: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access Control To: "Michael Germony" Cc: Ghassan.Chaddoud@loria.fr, haixiang@nortelnetworks.com, msec@securemulticast.org, msec-admin@securemulticast.org X-Mailer: Lotus Notes Build V5_10182000 SHIMMER Beta 1 October 18, 2000 Message-ID: From: DRoyer@coradiant.com X-MIMETrack: Serialize by Router on Loki/Coradiant(Release 5.0.7 |March 21, 2001) at 11/28/2001 02:32:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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, 28 Nov 2001 14:30:09 -0500 Hi, The token should definitely be released if: - the ip address changes; - a reboot happens; - the token expires. Any relationship between the token and the ip address ? Regards, "Michael Germony" com> cc: , Sent by: Subject: Re: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access msec-admin@securemul Control ticast.org 11/28/2001 01:46 PM Ghassan and Haixiang, According to my understanding of the DHCP RFC, the only way that a client would loose its IP address after it reboots is if during the time it rebooted the DHCP server issued the same IP address to another client (likely only in extremely small or busy scopes) OR if the duration of the reboot exceeded 50% of the lease time defined in the scope. Otherwise it will get the same address issued. The only other possible way that it would get a different DHCP address is if the DHCP server's scope cache was flushed. Either way, wouldn't the reboot presumably cause the token to be released? Regards, Michael Germony Web Architecture Services mgermony@mandtbank.com >>> "Haixiang He" 11/28/01 10:37AM >>> > > > I mean if the host obtains an access token for an IP address A1, then if > this host reboots and uses DHCP, its new address, A2, would be > different from A1. Consequently it will not be capable to join another > groups. And, since the access token, is used to prevent another host > *outside* the same network to use the same access token. You do't care > about hosts *inside* the network. For this reason, the use of prefix ( a > prefix could represent the set of addresses used by DHCP, if it is used) > can resolve the problem of dynamic configuration of hosts. I did not think about this scenario in greater details. The problem with using prefix is that it does not work well with switch network such as switch ethernet. In switch network, two hosts connecting two different ports may have the same prefix. And also we did not try to apply this solution for mobile node at this time. Haixiang > > > Ghassan _______________________________________________ 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 Wed Nov 28 14:40:43 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03913 for ; Wed, 28 Nov 2001 14:40:42 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C006D537C9; Wed, 28 Nov 2001 14:40:15 -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 126AF53556 for ; Wed, 28 Nov 2001 14:39:24 -0500 (EST) Received: (qmail 97968 invoked by uid 3269); 28 Nov 2001 19:39:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97962 invoked from network); 28 Nov 2001 19:39:22 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 28 Nov 2001 19:39:22 -0000 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fASJc6d27482; Wed, 28 Nov 2001 14:38:06 -0500 (EST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Wed, 28 Nov 2001 14:38:30 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XXVB4JT9; Wed, 28 Nov 2001 14:37:22 -0500 Received: from nortelnetworks.com (elton-thinkpad.us.nortel.com [47.16.67.108]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XRGWZPH1; Wed, 28 Nov 2001 14:37:24 -0500 Message-ID: <3C053C7C.37CF9A5A@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Haixiang He" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh,zh-CN,zh-TW MIME-Version: 1.0 To: DRoyer@coradiant.com Cc: Michael Germony , Ghassan.Chaddoud@loria.fr, "Haixiang He" , msec@securemulticast.org, msec-admin@securemulticast.org Subject: Re: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access Control References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: 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, 28 Nov 2001 14:35:24 -0500 Content-Transfer-Encoding: 7bit > > > Any relationship between the token and the ip address ? > I was trying to make sure that other illegal hosts cannot reuse the same token. One way to achieve this goal is to put the host IP address in the Access Token. This solution is simple in my view and also does not require router to maintain other information. Haixiang _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Nov 28 15:41:04 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09571 for ; Wed, 28 Nov 2001 15:41:03 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D584153774; Wed, 28 Nov 2001 15:40:36 -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 EBCC65385D for ; Wed, 28 Nov 2001 15:37:43 -0500 (EST) Received: (qmail 4012 invoked by uid 3269); 28 Nov 2001 20:37:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4006 invoked from network); 28 Nov 2001 20:37:43 -0000 Received: from softdnserror (HELO loki.coradiant.com) (199.84.5.37) by klesh.pair.com with SMTP; 28 Nov 2001 20:37:43 -0000 Subject: Re: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access Control To: "Haixiang He" Cc: Ghassan.Chaddoud@loria.fr, "Haixiang He" , Michael Germony , msec@securemulticast.org, msec-admin@securemulticast.org X-Mailer: Lotus Notes Build V5_10182000 SHIMMER Beta 1 October 18, 2000 Message-ID: From: DRoyer@coradiant.com X-MIMETrack: Serialize by Router on Loki/Coradiant(Release 5.0.7 |March 21, 2001) at 11/28/2001 03:37:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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, 28 Nov 2001 15:36:07 -0500 simple... that's true. Is someone can resend me this draft ? Erased it by mistake... Regards, David "Haixiang He" cc: Michael Germony , Sent by: Ghassan.Chaddoud@loria.fr, "Haixiang He" , msec-admin@securemul msec@securemulticast.org, msec-admin@securemulticast.org ticast.org Subject: Re: [MSEC] Re: I-D ACTION : Simple Multicast Receiver Access Control 11/28/2001 02:35 PM > > > Any relationship between the token and the ip address ? > I was trying to make sure that other illegal hosts cannot reuse the same token. One way to achieve this goal is to put the host IP address in the Access Token. This solution is simple in my view and also does not require router to maintain other information. Haixiang _______________________________________________ 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