From msec-admin@securemulticast.org Thu Sep 6 01:03:11 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01356 for ; Thu, 6 Sep 2001 01:03:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 53C8553541; Thu, 6 Sep 2001 01:04: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 B51525353B for ; Thu, 6 Sep 2001 01:03:54 -0400 (EDT) Received: (qmail 86691 invoked by uid 3269); 6 Sep 2001 05:03:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86688 invoked from network); 6 Sep 2001 05:03:54 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 6 Sep 2001 05:03:54 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f8653C809804; Thu, 6 Sep 2001 01:03:12 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f8653Cn41224; Thu, 6 Sep 2001 01:03:12 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id BAA28756; Thu, 6 Sep 2001 01:03:08 -0400 From: Ran Canetti Message-Id: <200109060503.BAA28756@ornavella.watson.ibm.com> To: Elisabetta.Carrara@era.ericsson.se, Fredrik.Lindholm@era.ericsson.se, canetti@watson.ibm.com, mats.naslund@era-t.ericsson.se, rolf.blom@era-t.ericsson.se Subject: RE: [MSEC] draft-blom-mm-kmgt-00.txt Cc: confctrl@isi.edu, msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security list List-Unsubscribe: , List-Archive: Date: Thu, 6 Sep 2001 01:03:08 -0400 Fredrik, Sorry for the long delay. Here are some responses to yours. I think that the most important issue is the first one, ie the deployment of the timestamps in the internet environment. Best, Ran > > From: "Fredrik Lindholm (ERA)" > Date: Mon, 27 Aug 2001 16:39:43 +0200 > > > * One of the design choices has been to use timestamps > even though it has limitations. We are aware that we must add > clarifications of its use in different scenarios, the > security implications etc. We like this approach because it gives us the > possibility to let the source "push" down keys very > fast and because it gives the possibility to integrate/piggy-back the > protocol in the call control, e.g. SIP and RTSP. I certainly appreciate the benefits of using timestamps. But in order to understand what is being suggested I'd be interested in hearing more on the parameters you had in mind with respect to deployment. How large would you expect the time interval to be in a typical connection? say, between a source and a desktop computer, or between a source and a roaming laptop, or a hand-held device such as a pda or a cell-phone? how synchronized would your solution require the devices to be? (Note that here we not only talk about time synchronization from the beginning of a session, but rather global time synchronization.) That these questions are arguably at the heart of the realizability of the method... > * For one way authentication our public key scheme > needs 1/2 round. This can't be achieved with a scheme that requires > mutual party input for the key derivation (such as the revised public key). Mutual input to the key is a rather minor concern, and is not really the issue. What prevents the public-key mode (as well as the other modes of IKE) from being "1/2 round" is a number of things, perhaps the most basic of which is the need to guarantee freshness of the key without using timestamps. > * We do not mandate forward secrecy due to the > computational burden, but we included the DH to be able to provide it as > optional. Note that there often exists constrains on > call setup time and the delay budget is essentially filled by the transport > of bits itself. That's absolutely fine. I'd add language to the drafts explaining that what DH buys is PFS and discussing the price and tradeoffs. > > SIP scenario > > What we tried to describe in the SIP scenario was that > even though it might be technical possible to have an end-to-end > protection of the SIP signaling, this will probably not > be done in many practical implementations (due to intermediate nodes > etc.). Instead of always relying on the security of SIP > (or RTSP) we believe that we need our own protection which should be > independent of the transport protocol used. I see. That's a valid and good point. (Somehow I didn't understand it from the text. Perhaps it should be clarified.) > > ID protection > > Your points are definitely valid. But our main concern > was not to provide anonymity at the extra cost of additional > roundtrips. However, some level of identity protection > can be given, e.g. in the pre-shared key version. In this case, of > course, the two calling parties know the identity by > the other (e.g. by using pseudonyms). In the public key case we do > provide identity protection by allowing the > ID/Certificate to be encrypted (this will however open DoS problems). The > initiator's identity will then be protected as well as > the responder's (this will of course require that the responder knows what > private key to decrypt with). This is good against attackers that only listen on the line. Your protocol does not protect the identity of the initiator (typically, the client) against active attackers that impersonate the receiver. This may be ok/acceptable to you, but it should probably be said explicitly. > Groups > > We had as an application, a multimedia session in which > you dynamically may add new streams. To us it is then natural to make > the source the membership controller. i see. How do you envision the process of joining a session/adding streams? how (and to whom) would a new receiver express its wish to join the session? how will it learn which stream to listen to? _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Sep 7 11:08:08 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16692 for ; Fri, 7 Sep 2001 11:08:05 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9123E53567; Fri, 7 Sep 2001 11:08:14 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DEA425361B for ; Fri, 7 Sep 2001 11:06:46 -0400 (EDT) Received: (qmail 30927 invoked by uid 3269); 7 Sep 2001 15:06:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 30924 invoked from network); 7 Sep 2001 15:06:45 -0000 Received: from ebene.inrialpes.fr (194.199.18.70) by klesh.pair.com with SMTP; 7 Sep 2001 15:06:45 -0000 Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.3) with ESMTP id f87F4qq26142 for ; Fri, 7 Sep 2001 17:04:52 +0200 (MEST) Received: from inrialpes.fr (IDENT:nadjar@iseran.inrialpes.fr [194.199.24.100]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f87F4r508520 for ; Fri, 7 Sep 2001 17:04:54 +0200 (MEST) Message-ID: <3B98E30E.9419E056@inrialpes.fr> From: Mohamed Nadjar X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: "msec@securemulticast.org" Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [MSEC] TESLA 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, 07 Sep 2001 17:09:02 +0200 Content-Transfer-Encoding: 8bit Hi, I would like to know if somebody already tried to implement TESLA?? I don't know how to do it and I need some help. Thanks. Mohamed NADJAR, Inria Rhône-Alpes, Planete Team, France _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Sep 9 20:11:10 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15501 for ; Sun, 9 Sep 2001 20:11:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4C353537E6; Sun, 9 Sep 2001 20:12:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by pairlist.net (Postfix) with ESMTP id 0B27E535BA for ; Fri, 17 Aug 2001 16:41:30 -0400 (EDT) Received: by sentry.gw.tislabs.com; id QAA01017; Fri, 17 Aug 2001 16:45:45 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma001002; Fri, 17 Aug 01 16:44:47 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id QAA09342 for msec@lists.securemulticast.org; Fri, 17 Aug 2001 16:40:21 -0400 (EDT) From: "David M. Balenson" Message-Id: <200108172040.QAA09342@clipper.gw.tislabs.com> To: msec@lists.securemulticast.org Subject: [MSEC] CFP: Submission deadline for NDSS'02 extended to Aug 29th 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, 17 Aug 2001 16:40:21 -0400 (EDT) Due to the unusually large number of requests for an extension, the submissions deadline for NDSS'02 has been extended to Wednesday August 29, 9:00am EST (U.S. east coast time). Paul Van Oorschot and Virgil Gligor Co-Chairs, NDSS'02 C A L L F O R P A P E R S Internet Society's 2002 Network and Distributed System Security Symposium (NDSS'02) Catamaran Resort - San Diego, California February 6-8, 2002 IMPORTANT DATES Paper and panel submissions due August 22, 2001 Author notification October 17, 2001 Final version of papers and panels due November 20, 2001 GOAL: The symposium fosters information exchange among research scientists and practitioners of network and distributed system security services. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation (rather than theory). A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings are published by the Internet Society. GENERAL CHAIR: Clifford Neuman, USC Information Sciences Institute PROGRAM CO-CHAIRS: Paul Van Oorschot, Entrust Technologies Virgil Gligor, University of Maryland TUTORIAL CHAIR: Eric Harder, National Security Agency LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Mahesh Tripunitara, Purdue University PUBLICITY CHAIR: David Balenson, NAI Labs, Network Associates LOGISTICS CHAIR: Terry Weigler, Internet Society PROGRAM COMMITTEE: Steve Bellovin, AT&T Labs Research Dan Boneh, Stanford University Bill Cheswick, Lumeta Corporation Li Gong, Sun Microsystems Peter Gutmann, Univ. of Auckland, N.Z. Charlie Kaufman, Iris Associates Steve Kent, BBN Technologies Markus Kuhn, Univ. of Cambridge, U.K. Douglas Maughan, DARPA Kevin McCurley, IBM Almaden Research Gary McGraw, Cigital Fabian Monrose, Bell Labs Sandra Murphy, Network Associates Radha Poovendran, Univ. of Washington Michael Roe, Microsoft Research, U.K. Christoph Schuba, Sun Microsystems Clay Shields, Purdue University Jonathan Trostle, Cisco Systems Dan Wallach, Rice University OUTSTANDING PAPER AWARD: There will be an Outstanding Paper award. The award will be presented at the symposium to the authors of an outstanding paper, as selected by the Program Committee. SUBMISSIONS: Both technical papers and panel proposals are solicited. Technical papers must include a main body of at most 12 pages, with any additional details in clearly marked appendices for a combined total of at most 20 pages. Technical papers will appear in the proceedings. Panel proposals should be one page and must describe the topic, identify the panel chair, explain the panel format, and list three to four potential panelists. A description of each panel will appear in the proceedings, and may, at the discretion of the panel chair, include written position statements from the panelists. Submissions are solicited in, but not limited to, the following areas: * Integrating security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web. * Intrusion avoidance, detection, and response: systems, experiences and architectures. * Attack-resistant protocols and services. * Network perimeter controls: firewalls, packet filters, application gateways. * Virtual private networks. * Public key infrastructure, key management, certification, and revocation. * Secure electronic commerce: e.g., payment, barter, EDI, notarization, timestamping, endorsement, and licensing. * Supporting security mechanisms and APIs; audit trails; accountability. * Implementation, deployment and management of network security policies. * Intellectual property protection: protocols, schemas, implementations, metering, watermarking, digital rights management. * Fundamental services on network and distributed systems: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing. * Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: teleconferencing and video-conferencing, groupwork, etc. Each submission must contain a separate Submission Overview specifying the submission type (paper or panel), the title or topic, author names with organizational affiliations, and must specify a contact author along with corresponding phone number, FAX number, postal address and email address. Submissions must be received by August 22, 2001, and must be made electronically in either printable PostScript or PDF. Each submission will be acknowledged by e-mail; if acknowledgment is not received within seven days, contact a program co-chair (see above). Authors and panelists will be notified of acceptance by October 17, 2001, and given instructions for preparing the camera-ready copy. The camera-ready copy must be received by November 20, 2001. FURTHER INFORMATION: Official dates, the final call for papers, the advance program, and registration information will be available shortly at http://www.isoc.org/ndss2002. For official submission information, visit http://www.isoc.org/ndss2002/cfp. Internet Society 11150 Sunset Hills Road, Suite 100 Reston, VA 20191 USA Tel: +1 703 326 9880 Fax: +1 703 326 9880 www.isoc.org 4, rue des Falaises CH-1205 Geneva Switzerland Tel: +41 22 807 1444 Fax: +41 22 807 1445 www.isoc.org _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Sep 9 20:12:23 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15530 for ; Sun, 9 Sep 2001 20:12:21 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3CB335389B; Sun, 9 Sep 2001 20:12: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 D47E75356C for ; Fri, 7 Sep 2001 23:04:26 -0400 (EDT) Received: (qmail 36435 invoked by uid 3269); 8 Sep 2001 03:04:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36432 invoked from network); 8 Sep 2001 03:04:26 -0000 Received: from relay.eecs.berkeley.edu (169.229.34.228) by klesh.pair.com with SMTP; 8 Sep 2001 03:04:26 -0000 Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id UAA04731 for ; Fri, 7 Sep 2001 20:04:24 -0700 (PDT) Received: from cs.berkeley.edu (c787017-a.pinol1.sfba.home.com [24.5.193.121]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id GJBPVA00.R48; Fri, 7 Sep 2001 20:04:22 -0700 Message-ID: <3B998C0A.767AD4BE@cs.berkeley.edu> From: Adrian Perrig X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mohamed Nadjar Cc: "msec@securemulticast.org" Subject: Re: [MSEC] TESLA References: <3B98E30E.9419E056@inrialpes.fr> 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: Fri, 07 Sep 2001 20:10:02 -0700 Content-Transfer-Encoding: 7bit Hi Mohamed, I implemented a prototype in Java about two years ago. In the meantime TESLA has evolved, and we specified the authentication field format. We are now working on a clean reference implementation in C, aiming to be ready by the next IETF. However, it would be great to have more than one independent implementations, to make sure that they interoperate. > I would like to know if somebody already tried to implement TESLA?? > I don't know how to do it and I need some help. What problems in particular did you encounter? We would be happy to help you with any questions you have. Greetings, Adrian _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Sep 9 20:13:21 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15549 for ; Sun, 9 Sep 2001 20:13:21 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D0909538A4; Sun, 9 Sep 2001 20:12:07 -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 F2A5F53575 for ; Tue, 14 Aug 2001 07:03:25 -0400 (EDT) Received: (qmail 38423 invoked by uid 3269); 14 Aug 2001 11:03:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 38420 invoked from network); 14 Aug 2001 11:03:25 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 14 Aug 2001 11:03:25 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26229; Tue, 14 Aug 2001 07:01:56 -0400 (EDT) Message-Id: <200108141101.HAA26229@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: smug@cs.umass.edu, msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION: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, 14 Aug 2001 07:01:55 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Subset-Difference based Key Management for Secure Multicast Author(s) : J. Lotspiech, M. Naor, D. Naor Filename : draft-irtf-smug-subsetdifference-00.txt Pages : Date : 13-Aug-01 This document describes a key management mechanism for multicast communication sessions that is based on the 'Subset-Difference' algorithm. The Subset-Difference algorithm is a new revocation scheme which allows a Center (such as a Group Controller/ Key Manager) to send a message so that *every* authorized receiver, but none of the revoked receivers, can decrypt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-smug-subsetdifference-00.txt 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-irtf-smug-subsetdifference-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-irtf-smug-subsetdifference-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: <20010813131241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-irtf-smug-subsetdifference-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-irtf-smug-subsetdifference-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010813131241.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Sep 10 23:25:29 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12289 for ; Mon, 10 Sep 2001 23:25:28 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 44C895365F; Mon, 10 Sep 2001 23:26:27 -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 97E7553564 for ; Mon, 10 Sep 2001 23:25:30 -0400 (EDT) Received: (qmail 87345 invoked by uid 3269); 11 Sep 2001 03:25:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87342 invoked from network); 11 Sep 2001 03:25:30 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 11 Sep 2001 03:25:30 -0000 Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f8B3OsM09206 for ; Mon, 10 Sep 2001 23:24:54 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n189at0.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f8B3Osn25432 for ; Mon, 10 Sep 2001 23:24:54 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id XAA27848 for msec@securemulticast.org; Mon, 10 Sep 2001 23:24:53 -0400 From: Ran Canetti Message-Id: <200109110324.XAA27848@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [MSEC] Minutes of London 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: Mon, 10 Sep 2001 23:24:53 -0400 Folks, With apologies for the delay and with thanks to PEte Dinsmore who took them, here are the minutes of the MSEC meeting in the London IETF last month. Ran and Thomas ========================================================= Minutes of the August 8, 2001 MSEC meeting IETF 51 3:30-5:30 pm Thomas Hardjono and Ran Canetti, chairs Copies of all of the presentations are on www.securemulticast.org GKM Architecture presentation by Mark Baugher: Presented where GKM arch fits into big picture of docs and architecture Comments: Hugh Harney: external policy interface necessary for static policy issues. Policy that insures that the key being passed around is secure should be included within the GKM. This can be dynamic (within a group) and is required to make/keep group secure. Re-key protocol presented by Lakshminath Dondeti (No I-D posted yet) Comments: Thomas Hardjono: - rekey protocol needs to deal with policy changes during rekey, e.g. changing from DES to 3DES when key changes. - Keep Cat 1 SA's up in place of backchannel Pete Dinsmore - need backchannel for "I need to be resynched" - don't use backchannel for group management, i.e., de-registration - don't include support for subgroup communication/keying; too complicated Hugh Harney: - don't confuse KEK's with TEK's. i.e., don't use tree keys for subgroup communication Ken Calvert: - what is motivation for subgroup communication? It seems too complicated for now. ???: - will backchannel have implosion problem? Ran Canetti - separate de-registration from key mgmt backchannel (for resynch) - subgroup is too complicated for now - Suggest piggybacking key messages on data - Will the rekey protocol be stateless? What happens if a message is missed? GSAKMP Lite presentation by Hugh Harney: (no I-D posted yet) Purpose of work is to simplify GSAKMP and provide easier implementation, easier analysis, and faster setup Cut out optional payloads, initial infrastructure search, first unicast SA. Kept full GSAKMP functionality for distribution of policy, key mgmt, Defined security suite for initial setup of group Comments: Thomas Hardjono: - is cat 1 over secure channel? Hugh: Intent is to be secure without unicast SA Haven't specified yet which parameters are kept after exchange (state created by exchange) - Where does member ID come from? Hugh – it's a 32 bit number. Lakshminath Dondeti: - will key node number updates be part of key update? Key Mgmt for Multimedia Sessions ( and SRTP) presentation by Fredrik Linkholm (drafts published as individual I-D) This work originates from securing SRTP in AVT WG Mark Baugher: - is there a home for this work here? - It does not seem this is doing authenticated key exchanges (can it be done in less than 3 messages?) Hugh Harney: - What is the class of applications? Who owns the data shared on the group? The issue is that "how do group members trust that group is secure enough to share my data? Thomas Hardjono: - Does this work belong in MSEC? It is common with our work because it is group security. Brian Weis: - Isn't SRTP going forward as a unicast protocol? Therefore, this work might not belong in MSEC. ?? - Mmusic will be discussing the unicast/multicast aspects of SRTP. The group security aspects are covered better in MSEC Mark Baugher: - feels GKM arch is modular and should be able to handle this. Ran Canetti: - agrees this would be good for MSEC. Mark Baugher: - MSEC should define key messages, regardless of how they are transmitted (specified probably in Mmusic) Straw poll taken by Ran was that this work should be included in MSEC (about 30 said yes, 0 said no) Group Domain of Interpretation by Brian Weis Brian first explained that GDOI uses IKE phase 1 unchanged, and does not use IKE phase 2 at all. It replaces IKE phase 2 with GDOI, under its own Domain number, and most likely running on its own port. He then presented updates on GDOI since the last IETF. Questions/Comments ??? - Does it make sense to just redo the IKE phase 1 exchange to refresh the DH material, instead of having the KE payloads optional in phase 2? Steve Kent - Feasible just to use public key certs with narrow scopes of use in place of attribute certs. - Warning: defering this (Alternative C) may end up requiring an arbitrary number of exchanges, as opposed to the current 2. Protocol will need to be more generic to account for this if the doc follows this alternative. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Sep 17 14:18:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17662 for ; Mon, 17 Sep 2001 14:18:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 577A553572; Mon, 17 Sep 2001 14:17:37 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 3569B5353B for ; Mon, 17 Sep 2001 13:43:23 -0400 (EDT) Received: (qmail 22352 invoked by uid 3269); 17 Sep 2001 17:43:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 22349 invoked from network); 17 Sep 2001 17:43:22 -0000 Received: from softdnserror (HELO sj-msg-core-3.cisco.com) (171.70.157.152) by klesh.pair.com with SMTP; 17 Sep 2001 17:43:22 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f8HHemO05504; Mon, 17 Sep 2001 10:40:49 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-163.cisco.com [10.21.96.163]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AFZ02722; Mon, 17 Sep 2001 10:42:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20010917083415.04223540@agora.rdrop.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: thardjono@verisign.com, hh@sparta.com, pdmcdan@eecs.umich.edu, ac@columbia.sparta.com, Pete_Dinsmore@NAI.com From: Mark Baugher Cc: msec@securemulticast.org In-Reply-To: <200109171100.HAA07808@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: I-D ACTION:draft-ietf-msec-gspt-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: Mon, 17 Sep 2001 10:41:36 -0700 You did a great job pulling this together well before the next IETF meeting. We need to consider this document as we work on the next revision of the key management architecture. I gave it a first read and made a lot of notes. I'll mention some things here and the rest later. My first question is: What do we do with this? Does it get coded in a structure and passed through announcement, key management, and other group protocols? Do you think that this spec is intended to be implemented? In its present form? Figure 2 looks neat. It appears that policy gets put in a policy repository, which only feeds key management. That would suggest that this goes into (a) a policy repository schema and (b) a key management payload. But the GO has a flow to ANNOUNCEMENT, and the draft does not define what this is - the draft explicitly states that it does not define what it is. Maybe it should define what it could be? Do we need policy profiles to help people through this complex process? On p.5, (a), the GID is identified as a unique ID. Is it unique to an owner, GCKS, or is it globally unique? Does this always require a PKI? X.509 naming? In 4.1 you say that the group ID consists of an "IP Addresses and serial numbers, and a Timestamp." I don't understand why it has to include such things. We have avoided introducing timestamps in the architecture so far. Do we really want to require synchronized clocks? Pg. 5 (b) mentions entities and actions but does not state what these are. On p6, (d), key change and key push should be included, shouldn't it? I don't get the notion of a "bypass SA" on p.10, 4.4. The bypass SA appears in the example section 6. I don't get the example because there are two distinct cases that are not distinguished in section 6. The first case is using a key management protocol to install SAs for a security protocol such as ESP, AH. Note that 6.1 identifies GSAKMP as a "group security protocol" and this is not the terminology we have adopted in gkmarch: There are key management protocols such as GSAKMP and GDOI that manage SAs for security protocols such ESP and AH. So GSAKMP could be run over IPsec (ESP and AH security protocols) and there are policy choices for how this is to be done. _And_ GSAKMP could be run to establish multicast SAs for IPsec (ESP and AH security protocols using IP multicast delivery). What are we talking about in section 6? Thanks, Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Sep 17 15:46:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20099 for ; Mon, 17 Sep 2001 15:46:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D3951536C6; Mon, 17 Sep 2001 15:40:27 -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 7A35453A60 for ; Wed, 12 Sep 2001 07:12:06 -0400 (EDT) Received: (qmail 89332 invoked by uid 3269); 12 Sep 2001 11:12:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89329 invoked from network); 12 Sep 2001 11:12:05 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 12 Sep 2001 11:12:05 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17249; Wed, 12 Sep 2001 07:11:56 -0400 (EDT) Message-Id: <200109121111.HAA17249@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-gsakmp-light-sec-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, 12 Sep 2001 07:11:56 -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 : GSAKMP Light Author(s) : H. Harney, A. Schuett, A. Colegrove Filename : draft-ietf-msec-gsakmp-light-sec-00.txt Pages : 38 Date : 11-Sep-01 A protocol specification must balance two often conflicting goals: to produce as general a protocol as possible, and to produce a simple protocol. The Group Secure Association Key Management Protocol (GSAKMP) is a general protocol for creating and managing cryptographic groups on a network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-light-sec-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-gsakmp-light-sec-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-gsakmp-light-sec-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: <20010911131748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gsakmp-light-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gsakmp-light-sec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010911131748.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Sep 17 15:49:29 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20157 for ; Mon, 17 Sep 2001 15:49:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DD7F3536CA; Mon, 17 Sep 2001 15:40:30 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2F6D7537FA for ; Mon, 17 Sep 2001 06:59:56 -0400 (EDT) Received: (qmail 86896 invoked by uid 3269); 17 Sep 2001 10:59:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86893 invoked from network); 17 Sep 2001 10:59:55 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 17 Sep 2001 10:59:55 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07808; Mon, 17 Sep 2001 07:00:31 -0400 (EDT) Message-Id: <200109171100.HAA07808@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-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: Mon, 17 Sep 2001 07:00:30 -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 Security Policy Token Author(s) : T. Hardjono et al. Filename : draft-ietf-msec-gspt-00.txt Pages : 26 Date : 14-Sep-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-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-gspt-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-gspt-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: <20010914110757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gspt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gspt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010914110757.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec