From msec-admin@securemulticast.org Mon Dec 1 12:45:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19740 for ; Mon, 1 Dec 2003 12:45:30 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1BDAA535D3; Mon, 1 Dec 2003 12:45:13 -0500 (EST) Delivered-To: msec@pairlist.net Received: from mailhub-4.iastate.edu (mailhub-4.iastate.edu [129.186.140.14]) by pairlist.net (Postfix) with ESMTP id A457553546 for ; Mon, 1 Dec 2003 12:43:31 -0500 (EST) Received: from mailout-2.iastate.edu (mailout-2.iastate.edu [129.186.140.2]) by mailhub-4.iastate.edu (8.12.10/8.12.10) with SMTP id hB1HhSIG026791 for ; Mon, 1 Dec 2003 11:43:28 -0600 Received: from csl-asst2.ait.iastate.edu(129.186.144.139) by mailout-2.iastate.edu via csmap id 16331; Mon, 01 Dec 2003 11:50:37 -0600 (CST) Message-Id: <5.1.0.14.2.20031201113731.02173f30@liyan.mail.iastate.edu> X-Sender: liyan@liyan.mail.iastate.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: msec@lists.securemulticast.org From: Yan Li Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Implementation over P2P? Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 01 Dec 2003 11:43:28 -0600 Hi, there, I am developing a multi cast application based on P2P network. Is there an implementation or protocol to secure the traffic including text and audio? In particularly, how to implement the key agreement with DH algorithm? Regards, Yan _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Dec 4 18:30:16 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25252 for ; Thu, 4 Dec 2003 18:30:15 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 58AE8538D4; Thu, 4 Dec 2003 18:29: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 726D45356E for ; Thu, 4 Dec 2003 15:39:47 -0500 (EST) Received: (qmail 22219 invoked by uid 3269); 4 Dec 2003 20:39:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 22214 invoked from network); 4 Dec 2003 20:39:47 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 4 Dec 2003 20:39:46 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13448; Thu, 4 Dec 2003 15:39:26 -0500 (EST) Message-Id: <200312042039.PAA13448@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-dhhmac-05.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 04 Dec 2003 15:39:25 -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 : HMAC-authenticated Diffie-Hellman for MIKEY Author(s) : M. Euchner Filename : draft-ietf-msec-mikey-dhhmac-05.txt Pages : 32 Date : 2003-12-4 This document describes a point-to-point key management protocol variant for the multimedia Internet keying (MIKEY). In particular, the classic Diffie-Hellman key agreement protocol is used for key establishment in conjunction with a keyed hash (HMAC-SHA1) for achieving mutual authentication and message integrity of the key management messages exchanged. This MIKEY variant is called the HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-dhhmac-05.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-dhhmac-05.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-dhhmac-05.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: <2003-12-4154831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-dhhmac-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154831.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Dec 4 18:32:21 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25334 for ; Thu, 4 Dec 2003 18:32:21 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 16BBF538DA; Thu, 4 Dec 2003 18:29:27 -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 508B453620 for ; Thu, 4 Dec 2003 15:39:56 -0500 (EST) Received: (qmail 22237 invoked by uid 3269); 4 Dec 2003 20:39:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 22233 invoked from network); 4 Dec 2003 20:39:55 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 4 Dec 2003 20:39: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 PAA13465; Thu, 4 Dec 2003 15:39:39 -0500 (EST) Message-Id: <200312042039.PAA13465@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-ipsec-signatures-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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 04 Dec 2003 15:39:38 -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 : The Use of RSA Signatures within ESP and AH Author(s) : B. Weis Filename : draft-ietf-msec-ipsec-signatures-00.txt Pages : 8 Date : 2003-12-4 This memo describes the use of the RSA Signature algorithm [RSA] as an authentication algorithm within the revised IPSEC Encapsulating Security Payload [ESPbis] and the revised IPSEC Authentication Header [AHbis]. The use of a digital signature algorithm such as RSA provides data origin authentication when a secret key method (e.g., HMAC) cannot do so. For example, when ESP and AH are used to protect IP multicast data flows. Further information on the other components necessary for ESP and AH implementations is provided by [ROADMAP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-signatures-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-ipsec-signatures-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-ipsec-signatures-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: <2003-12-4154841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-ipsec-signatures-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-ipsec-signatures-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154841.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 Dec 9 10:17:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29379 for ; Tue, 9 Dec 2003 10:17:38 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 22E1A53935; Tue, 9 Dec 2003 10:16:12 -0500 (EST) Delivered-To: msec@pairlist.net Received: from mailhub-3.iastate.edu (mailhub-3.iastate.edu [129.186.140.13]) by pairlist.net (Postfix) with ESMTP id D1D14535DB for ; Mon, 8 Dec 2003 22:38:02 -0500 (EST) Received: from mailout-1.iastate.edu (mailout-1.iastate.edu [129.186.140.1]) by mailhub-3.iastate.edu (8.12.10/8.12.10) with SMTP id hB93boVf029895 for ; Mon, 8 Dec 2003 21:37:53 -0600 Received: from csl-asst2.ait.iastate.edu(129.186.144.139) by mailout-1.iastate.edu via csmap id 128f238e_29f9_11d8_8205_00304811c6dc_32063; Mon, 08 Dec 2003 21:37:54 -0600 (CST) Message-Id: <5.1.0.14.2.20031208213022.05668a08@liyan.mail.iastate.edu> X-Sender: liyan@liyan.mail.iastate.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: msec@lists.securemulticast.org From: Yan Li Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Algorithm and implementation of Diffie-Hellman Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 08 Dec 2003 21:37:50 -0600 Hi, there, I hope to compute n-party group keys with DH within one group. Is there an algorithm to implement it? Thanks for any help! Regards, Yan Li _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Dec 9 10:19:35 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29558 for ; Tue, 9 Dec 2003 10:19:33 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 77AE4539C1; Tue, 9 Dec 2003 10:16:18 -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 AB60153532 for ; Mon, 8 Dec 2003 21:34:15 -0500 (EST) Received: (qmail 42917 invoked by uid 3269); 9 Dec 2003 02:34:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 42914 invoked from network); 9 Dec 2003 02:34:15 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 9 Dec 2003 02:34:15 -0000 Received: from cisco.com ([128.107.177.199]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB92XgBN028742 for ; Mon, 8 Dec 2003 18:33:43 -0800 (PST) Message-ID: <3FD53485.F0753E5A@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Comments on draft-ietf-msec-tesla-intro-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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 08 Dec 2003 18:33:41 -0800 Content-Transfer-Encoding: 7bit Hello TESLA authors, I just have some minor comments on this draft. I will say that it is rather terse, but it seems that this was intentional as references are provided for more details. 1. Section 3. I recommend moving this section (Notation) to be a new subsection of the introduction (e.g., Section 1.1). This puts it before the first usage of notation (which occurs in in Section 2.1). 2. Section 4.3. The second paragraph ends by mentioning a "the TESLA technical draft". Please either provide a formal reference or remove the phrase. 3. Section 4.3. The first bullet contains a list. It reads "start time and index of interval i, ....", which puts the "and" in an awkward place in the sentence. It might read better as "start time of interval i, index value of interval i, and ...". 4. Section 4.6. Misspelling: "to loose their" should be "to lose their". 5. Section 4.7. Misspelling: "delays withing a" should be "delays within a". 6. Author Contact Information". I believe that several of these are no longer current. Thanks, Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Dec 9 11:10:21 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01709 for ; Tue, 9 Dec 2003 11:10:21 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 64FF1537C7; Tue, 9 Dec 2003 11:10:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by pairlist.net (Postfix) with ESMTP id 26B0F537C7 for ; Tue, 9 Dec 2003 11:08:33 -0500 (EST) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Dec 2003 16:09:26 +0000 Received: from mbaugher-w2k07.cisco.com (sjc-vpn4-473.cisco.com [10.21.81.217]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hB9G8TrY019085; Tue, 9 Dec 2003 08:08:30 -0800 (PST) Message-Id: <6.0.0.22.2.20031209080804.03dc7ac8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: Yan Li From: Mark Baugher Subject: Re: [MSEC] Algorithm and implementation of Diffie-Hellman Cc: msec@lists.securemulticast.org In-Reply-To: <5.1.0.14.2.20031208213022.05668a08@liyan.mail.iastate.edu> References: <5.1.0.14.2.20031208213022.05668a08@liyan.mail.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 09 Dec 2003 08:08:28 -0800 hi Have you looked at Cliques? Mark At 07:37 PM 12/8/2003, Yan Li wrote: >Hi, there, > >I hope to compute n-party group keys with DH within one group. Is there an >algorithm to implement it? > >Thanks for any help! > >Regards, > >Yan Li > > >_______________________________________________ >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 Dec 9 12:05:18 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03739 for ; Tue, 9 Dec 2003 12:05:18 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CFFF8537C7; Tue, 9 Dec 2003 12:00:54 -0500 (EST) Delivered-To: msec@pairlist.net Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by pairlist.net (Postfix) with ESMTP id 2B650536F3 for ; Tue, 9 Dec 2003 11:58:00 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Dec 2003 08:59:50 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB9GvpBN016105; Tue, 9 Dec 2003 08:57:51 -0800 (PST) Received: from sfluhrer-hpc (stealth-10-32-244-83.cisco.com [10.32.244.83]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOH39507; Tue, 9 Dec 2003 08:57:50 -0800 (PST) Message-Id: <200312091657.AOH39507@mira-sjc5-b.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 To: Yan Li , msec@lists.securemulticast.org From: Scott Fluhrer Subject: Re: [MSEC] Algorithm and implementation of Diffie-Hellman In-Reply-To: <5.1.0.14.2.20031208213022.05668a08@liyan.mail.iastate.edu> 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 09 Dec 2003 08:54:02 -0800 At 07:37 PM 12/8/03 , Yan Li wrote: >Hi, there, > >I hope to compute n-party group keys with DH within one group. Is there an >algorithm to implement it? What security properties are you hoping to achieve? -- scott _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Dec 9 12:35:05 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04488 for ; Tue, 9 Dec 2003 12:35:04 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6E7985386B; Tue, 9 Dec 2003 12:31:50 -0500 (EST) Delivered-To: msec@pairlist.net Received: from smtp2.su.se (smtp2.su.se [130.237.93.212]) by pairlist.net (Postfix) with ESMTP id 9F4F1536AE for ; Tue, 9 Dec 2003 12:25:18 -0500 (EST) Received: from localhost (smtp2.su.se [127.0.0.1]) by smtp2.su.se (Postfix) with ESMTP id C08B920071E; Tue, 9 Dec 2003 18:25:17 +0100 (CET) Received: from smtp2.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17093-16; Tue, 9 Dec 2003 18:25:17 +0100 (CET) Received: from unni.dsv.su.se (unni.dsv.su.se [130.237.161.27]) by smtp2.su.se (Postfix) with ESMTP id 58B8B200044; Tue, 9 Dec 2003 18:25:17 +0100 (CET) Received: from SeadMuftic.dsv.su.se (r2d2.cpi.seas.gwu.edu [128.164.82.43]) by unni.dsv.su.se (Postfix) with ESMTP id 910278B344; Tue, 9 Dec 2003 18:25:16 +0100 (CET) Message-Id: <5.2.0.8.2.20031209122005.00b8df10@mail.dsv.su.se> X-Sender: sead@mail.dsv.su.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.8 To: Yan Li , msec@lists.securemulticast.org From: Sead Muftic Subject: Re: [MSEC] Algorithm and implementation of Diffie-Hellman In-Reply-To: <5.1.0.14.2.20031208213022.05668a08@liyan.mail.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at su.se Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 09 Dec 2003 12:25:16 -0500 Yan: >I hope to compute n-party group keys with DH within one group. Is there an >algorithm to implement it? Depends what you want to do: either to use DH bilaterally between each group member and GSAKMP controller to securely DISTRIBUTE group key to each individual group member or to use extended DH protocol to ESTABLISH group key within a group. In the former case, you may use DH implementation in JCE, for the later case I guess the best protocol is by I. Ingemarsson, but I don't know of any implementation, so that would be your R&D exercise. Since we have the implementation of the full GSAKMP protocol, supporting secure instant messaging and secure forum, but not using DH (in fact we use SSL between group members and GSA Controller) if you will do any of the above in Java, we would be glad to integrate your results in our system and later swap them. Regards, Sead Muftic CSPRI/GWU _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Dec 9 16:30:09 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18223 for ; Tue, 9 Dec 2003 16:30:08 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1B6E853784; Tue, 9 Dec 2003 16:27:00 -0500 (EST) Delivered-To: msec@pairlist.net Received: from mail.cs.umn.edu (mail.cs.umn.edu [128.101.32.202]) by pairlist.net (Postfix) with ESMTP id 6A65B535BC for ; Tue, 9 Dec 2003 16:24:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by augustus.cs.umn.edu (Postfix) with ESMTP id E829D1134A; Tue, 9 Dec 2003 15:24:06 -0600 (CST) Received: from mail.cs.umn.edu ([127.0.0.1]) by localhost (augustus [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15219-01-3; Tue, 9 Dec 2003 15:23:59 -0600 (CST) Received: from isi.edu (sclab.cs.umn.edu [128.101.189.234]) by mail.cs.umn.edu (Postfix) with ESMTP id 2C68A11313; Tue, 9 Dec 2003 15:23:59 -0600 (CST) Message-ID: <3FD63D6E.1000804@isi.edu> From: Yongdae Kim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031203 Debian/1.5-2woody3 X-Accept-Language: en MIME-Version: 1.0 To: Scott Fluhrer Cc: Yan Li , msec@lists.securemulticast.org Subject: Re: [MSEC] Algorithm and implementation of Diffie-Hellman References: <200312091657.AOH39507@mira-sjc5-b.cisco.com> In-Reply-To: <200312091657.AOH39507@mira-sjc5-b.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at cs.umn.edu Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 09 Dec 2003 15:23:58 -0600 Content-Transfer-Encoding: 7bit Yan, Currently Cliques, TGDH, STR, and BD are implemented and available from http://sconce.ics.uci.edu/cliques/download.html ... Communication is supported by Spread group communication system and integrated version is available from http://cnds.jhu.edu/research/group/secure_spread/. Cheers, Yongdae > At 07:37 PM 12/8/03 , Yan Li wrote: > >>Hi, there, >> >>I hope to compute n-party group keys with DH within one group. Is there an >>algorithm to implement it? > > > What security properties are you hoping to achieve? > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 10 19:55:52 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29125 for ; Wed, 10 Dec 2003 19:55:51 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A297253671; Wed, 10 Dec 2003 19:55:17 -0500 (EST) Delivered-To: msec@pairlist.net Received: from mailhub-4.iastate.edu (mailhub-4.iastate.edu [129.186.140.14]) by pairlist.net (Postfix) with ESMTP id 8F92D535F6 for ; Wed, 10 Dec 2003 16:19:43 -0500 (EST) Received: from mailout-2.iastate.edu (mailout-2.iastate.edu [129.186.140.2]) by mailhub-4.iastate.edu (8.12.10/8.12.10) with SMTP id hBALJWl0011571; Wed, 10 Dec 2003 15:19:33 -0600 Received: from csl-asst2.ait.iastate.edu(129.186.144.139) by mailout-2.iastate.edu via csmap id 14337; Wed, 10 Dec 2003 15:25:08 -0600 (CST) Message-Id: <5.1.0.14.2.20031210151314.02207678@liyan.mail.iastate.edu> X-Sender: liyan@liyan.mail.iastate.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Yongdae Kim , msec@lists.securemulticast.org From: Yan Li Subject: Re: [MSEC] Algorithm and implementation of Diffie-Hellman In-Reply-To: <3FD63D6E.1000804@isi.edu> References: <200312091657.AOH39507@mira-sjc5-b.cisco.com> <200312091657.AOH39507@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 10 Dec 2003 15:17:36 -0600 Thanks for all your response. I developed an application to provide P2P synchronous services to groups. These services include group and private text chat, this application is a Java application that uses the JXTA P2P framework to provide these services. I am planning to encrypt the group message with a symmetric algorithm, such as RC4 or DES, and multicast the encrypted message to the members within one group. I hope to establish a group key for the group communication. No authentication will be considered in this case. To be more precise, the communication model assumes all peers authenticated in advance to work in a trusting environment but the communication to be not private. The trusted peers cannot be involved in unauthorized activities such as eavesdropping and MIME. The attacks are assumed to be active and passive, i.e. the attacker may eavesdrop on arbitrary communication and interfere it. The group size is assumed to scale up to hundreds of peers. Now my problem is how to establish a group key? How to select the big random number, exponentiation and the large prime for DH? How can I generate the key for RC4 or DES? The requirement for my application is: simple, secure, efficient and practical. I know Cliques and GSAKMP are good for secure multicast group management, but they are too complex to be implemented and need high computation cost. regards, Yan At 08:54 AM 12/9/2003 -0800, you wrote: >At 07:37 PM 12/8/03 , Yan Li wrote: > >Hi, there, > > > >I hope to compute n-party group keys with DH within one group. Is there an > >algorithm to implement it? > >What security properties are you hoping to achieve? > >-- >scott At 03:23 PM 12/9/2003 -0600, you wrote: >Yan, > >Currently Cliques, TGDH, STR, and BD are implemented and available from >http://sconce.ics.uci.edu/cliques/download.html ... Communication is >supported by Spread group communication system and integrated version is >available from http://cnds.jhu.edu/research/group/secure_spread/. > >Cheers, >Yongdae > > >>At 07:37 PM 12/8/03 , Yan Li wrote: >> >>>Hi, there, >>> >>>I hope to compute n-party group keys with DH within one group. Is there >>>an algorithm to implement it? >> >>What security properties are you hoping to achieve? > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Dec 11 09:56:10 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02746 for ; Thu, 11 Dec 2003 09:56:08 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0CB2853699; Thu, 11 Dec 2003 09:53:01 -0500 (EST) Delivered-To: msec@pairlist.net Received: from cree.web.itd.umich.edu (cree.web.itd.umich.edu [141.211.144.140]) by pairlist.net (Postfix) with ESMTP id 8875C5380E for ; Tue, 9 Dec 2003 14:29:36 -0500 (EST) Received: (from www@localhost) by cree.web.itd.umich.edu (8.12.9/8.12.9) id hB9JTTFX003538; Tue, 9 Dec 2003 14:29:29 -0500 X-Authentication-Warning: cree.web.itd.umich.edu: www set sender to sgoswami@umich.edu using -f Received: from 206-176-229-202.vbbn.com (206-176-229-202.vbbn.com [206.176.229.202]) by carrierpigeon.mail.umich.edu (IMP) with HTTP for ; Tue, 9 Dec 2003 14:29:29 -0500 Message-ID: <1070998169.3fd62299a1f61@carrierpigeon.mail.umich.edu> From: sgoswami@umich.edu To: Scott Fluhrer Cc: Yan Li , msec@lists.securemulticast.org Subject: Re: [MSEC] Algorithm and implementation of Diffie-Hellman References: <200312091657.AOH39507@mira-sjc5-b.cisco.com> In-Reply-To: <200312091657.AOH39507@mira-sjc5-b.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-IMP-Server: carrierpigeon.mail.umich.edu X-Originating-IP: 206.176.229.202 X-Originating-User: sgoswami Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 9 Dec 2003 14:29:29 -0500 Content-Transfer-Encoding: 8bit There is a Tree-based Group Diffie Hellman (TGDH) that has been shown to be scalable to groups of 50 nodes. I am not aware of any standardization effort on this. Please refer to the following paper. An Efficient Tree-based Group Key Agreement using Bilinear Map by Sangwon Lee, Yongdae Kim, Kwangjo Kim, and Dae-Hyun Ryu. Subrata Quoting Scott Fluhrer : > At 07:37 PM 12/8/03 , Yan Li wrote: > >Hi, there, > > > >I hope to compute n-party group keys with DH within one group. Is there an > >algorithm to implement it? > > What security properties are you hoping to achieve? > > -- > scott > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > Subrata Goswami, Ph.D. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Dec 11 10:25:45 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06119 for ; Thu, 11 Dec 2003 10:25:38 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2E3E9537D0; Thu, 11 Dec 2003 10:24:55 -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 A7AE15353D for ; Tue, 9 Dec 2003 12:57:55 -0500 (EST) Received: (qmail 32698 invoked by uid 3269); 9 Dec 2003 17:57:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32695 invoked from network); 9 Dec 2003 17:57:55 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 9 Dec 2003 17:57:55 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id hB9HvOC137716; Tue, 9 Dec 2003 12:57:24 -0500 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7) with ESMTP id hB9HvIC54392; Tue, 9 Dec 2003 12:57:18 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id hB9Hv7L25132; Tue, 9 Dec 2003 12:57:07 -0500 From: canetti To: msec@securemulticast.org Cc: Margaret.Wasserman@nokia.com, hayashi.tsunemasa@lab.ntt.co.jp, haixiang@nortelnetworks.com, housley@vigilsec.com, thardjono@yahoo.com, thardjono@verisign.com, smb@research.att.com, brian@innovationslab.net In-Reply-To: <6.0.0.22.2.20031205132645.02ed2e30@MOU1WNEXM03.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] IGAP to RFC? Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 9 Dec 2003 12:57:01 -0500 (EST) Folks, The private I-D http://www.ietf.org/internet-drafts/draft-hayashi-igap-03.txt describes IGAP, a group membership authentication protocol that allows users to authenticate themselves to a group center for billing and accounting purposes. The draft provides no means for encrypting or authenitcating the multicasted data. The authors of this I-D have asked the IESG to publish this document as an informational RFC. Since this is a security-related and multicast-repated protocol, the security ADs and the MSEC chairs were asked by the IESG whether we see a danger in endorsing the proposed protocol, either by providing an "insecure work around" to the MSEC protocols, or by interacting badly with MSEC protocols - or alternatively whether we think it is ok to publish the draft as an informational RFC. We would like to poll the WG for opinions. Please take the time to look ad the I-D and opinionate. Thanks, Ran and Thomas _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Dec 11 10:31:16 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06444 for ; Thu, 11 Dec 2003 10:31:10 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A0895537E4; Thu, 11 Dec 2003 10:30:15 -0500 (EST) Delivered-To: msec@pairlist.net Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by pairlist.net (Postfix) with ESMTP id 27B4A536BD for ; Tue, 9 Dec 2003 14:28:45 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id hB9JSgF23486; Tue, 9 Dec 2003 20:28:42 +0100 (MET) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id hB9JSfL19032; Tue, 9 Dec 2003 20:28:41 +0100 (MET) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id UAA03966; Tue, 9 Dec 2003 20:28:41 +0100 (MET) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 9 Dec 2003 20:28:41 +0100 Message-ID: <8C878B55C96F924389908D4A7384842A0139E282@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: "'Yan Li'" , msec@lists.securemulticast.org, Euchner Martin Subject: RE: [MSEC] Algorithm and implementation of Diffie-Hellman MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 9 Dec 2003 20:28:39 +0100 You may look at some classic group Diffie-Hellman work: M. Burmester and Y. Desmedt. A secure and efficient conference key distribution system. In A. De Santis, editor, Advances in Cryptology EUROCRYPT '94, Workshop on the Theory and Application of Cryptographic Techniques, volume 950 of Lecture Notes in Computer Science, pages 275-286. Springer-Verlag, 1995. The paper describes a generalized group-based DH crypto protocol where the group key = g**(x1*x2*x3*...*xn) in a circular-connected group of size n is computed in a round-robin fashion (n-steps). I haven't seen this algorithm implemented anywhere (should be very straight-forward in small groups). With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Yan Li [mailto:liyan@iastate.edu] Sent: Tuesday, December 09, 2003 4:38 AM To: msec@lists.securemulticast.org Subject: [MSEC] Algorithm and implementation of Diffie-Hellman Hi, there, I hope to compute n-party group keys with DH within one group. Is there an algorithm to implement it? Thanks for any help! Regards, Yan Li _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Dec 11 14:00:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14696 for ; Thu, 11 Dec 2003 14:00:36 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2A028536A5; Thu, 11 Dec 2003 14:00: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 595CC53753 for ; Thu, 11 Dec 2003 13:58:19 -0500 (EST) Received: (qmail 17146 invoked by uid 3269); 11 Dec 2003 18:58:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17142 invoked from network); 11 Dec 2003 18:58:19 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 11 Dec 2003 18:58:19 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id hBBIvmC160746 for ; Thu, 11 Dec 2003 13:57:48 -0500 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7) with ESMTP id hBBIvlc96558 for ; Thu, 11 Dec 2003 13:57:47 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id hBBIvk925168 for ; Thu, 11 Dec 2003 13:57:47 -0500 From: canetti To: msec@securemulticast.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] Re: IGAP to RFC? (fwd) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 11 Dec 2003 13:57:45 -0500 (EST) Folks, You may want to wait for the revised version. Thanks, Ran and Thomas > On Wed, 10 Dec 2003, Tsunemasa Hayashi wrote: >> Ran and Thomas, >> >> Thank you for the informing MSEC of our IGAP draft. But, we >> would like to revise the both sections of abstract and >> introduction of the draft. We are explicitly going to describe >> the topic IGAP solves. We will update it soon. >> >> Regards, >> >> Tsune. >> >> >>>>> "canetti" == canetti writes: >> canetti> Folks, >> canetti> The private I-D canetti> http://www.ietf.org/internet-drafts/draft-hayashi-igap-03.txt canetti> describes IGAP, a group membership authentication protocol canetti> that allows users to authenticate themselves to a group canetti> center for billing and accounting purposes. The draft canetti> provides no means for encrypting or authenitcating the canetti> multicasted data. >> canetti> The authors of this I-D have asked the IESG to publish this canetti> document as an informational RFC. Since this is a canetti> security-related and multicast-repated protocol, the canetti> security ADs and the MSEC chairs were asked by the IESG canetti> whether we see a danger in endorsing the proposed protocol, canetti> either by providing an "insecure work around" to the MSEC canetti> protocols, or by interacting badly with MSEC protocols - or canetti> alternatively whether we think it is ok to publish the canetti> draft as an informational RFC. We would like to poll the WG canetti> for opinions. Please take the time to look ad the I-D and canetti> opinionate. >> canetti> Thanks, >> canetti> Ran and Thomas >> _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Dec 14 21:36:04 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06449 for ; Sun, 14 Dec 2003 21:36:03 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CD81353595; Sun, 14 Dec 2003 21:34:51 -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 79A9253747 for ; Sun, 14 Dec 2003 21:32:55 -0500 (EST) Received: (qmail 86179 invoked by uid 3269); 15 Dec 2003 02:32:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86176 invoked from network); 15 Dec 2003 02:32:55 -0000 Received: from smtp-out2.oct.nac.net (209.123.233.212) by klesh.pair.com with SMTP; 15 Dec 2003 02:32:55 -0000 Received: (qmail 27387 invoked by uid 0); 14 Dec 2003 21:32:54 -0500 Received: from gmgross@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.046289 secs); 15 Dec 2003 02:32:54 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 14 Dec 2003 21:32:54 -0500 Received: (qmail 55786 invoked from network); 14 Dec 2003 21:32:53 -0500 Received: from unknown (HELO nsx.garage) (gmgross@209.123.180.190) by mail1.oct.nac.net with SMTP; 14 Dec 2003 21:32:53 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id hBF1II220698; Sun, 14 Dec 2003 20:18:18 -0500 From: George Gross To: canetti Cc: Subject: Re: [MSEC] Re: IGAP to RFC? (fwd) In-Reply-To: Message-ID: 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 14 Dec 2003 20:18:18 -0500 (EST) Hi, I took a 2nd look at IGAP just to be sure it really was as bad I thought the 1st time I looked. From a both multicast security and AAA perspective, IMHO it is unacceptable that the IETF move this forward to informational RFC status. For example, passwords in the clear using PAP as per section 3.2.1. The CHAP authentication is weak against offline dictionary attacks. No digital signature source authentication mechanism. Lots of opportunity for fraud, DoS, theft of service. The fact that a service provider and a vendor banded together to build something like this is their private business. I recommend that it should not be published, as it easily could become a marketware tool, and obstruct future movement in our industry towards a secure and comprehensive standard solution. For a summary of a design direction and open issues that is congruent with both the MSEC and AAA standards, I would encourage the folks who want to pursue MSEC/AAA please please take a look at my presentation from IETF58 Minneapolis: http://www.identaware.com/IETF58_MSEC_AAA_v00.ppt and I would welcome their discussion on its assessment. br, George On Thu, 11 Dec 2003, canetti wrote: > > Folks, > > You may want to wait for the revised version. > > Thanks, > > Ran and Thomas > > > > On Wed, 10 Dec 2003, Tsunemasa Hayashi wrote: > > >> Ran and Thomas, > >> > >> Thank you for the informing MSEC of our IGAP draft. But, we > >> would like to revise the both sections of abstract and > >> introduction of the draft. We are explicitly going to describe > >> the topic IGAP solves. We will update it soon. > >> > >> Regards, > >> > >> Tsune. > >> > >> >>>>> "canetti" == canetti writes: > >> > canetti> Folks, > >> > canetti> The private I-D > canetti> http://www.ietf.org/internet-drafts/draft-hayashi-igap-03.txt > canetti> describes IGAP, a group membership authentication protocol > canetti> that allows users to authenticate themselves to a group > canetti> center for billing and accounting purposes. The draft > canetti> provides no means for encrypting or authenitcating the > canetti> multicasted data. > >> > canetti> The authors of this I-D have asked the IESG to publish this > canetti> document as an informational RFC. Since this is a > canetti> security-related and multicast-repated protocol, the > canetti> security ADs and the MSEC chairs were asked by the IESG > canetti> whether we see a danger in endorsing the proposed protocol, > canetti> either by providing an "insecure work around" to the MSEC > canetti> protocols, or by interacting badly with MSEC protocols - or > canetti> alternatively whether we think it is ok to publish the > canetti> draft as an informational RFC. We would like to poll the WG > canetti> for opinions. Please take the time to look ad the I-D and > canetti> opinionate. > >> > canetti> Thanks, > >> > canetti> Ran and Thomas > >> > > > > > _______________________________________________ > 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 Dec 16 16:13:57 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05984 for ; Tue, 16 Dec 2003 16:13:56 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 27AEC536EB; Tue, 16 Dec 2003 16:13:18 -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 7628553667 for ; Tue, 16 Dec 2003 16:02:29 -0500 (EST) Received: (qmail 98234 invoked by uid 3269); 16 Dec 2003 21:02:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98229 invoked from network); 16 Dec 2003 21:02:29 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 16 Dec 2003 21:02:29 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04222; Tue, 16 Dec 2003 16:02:26 -0500 (EST) Message-Id: <200312162102.QAA04222@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-08.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 16:02:22 -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 Filename : draft-ietf-msec-mikey-08.txt Pages : 61 Date : 2003-12-16 Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication), and shows how it may work together with protocols such as SIP and RTSP. In particular, its use to support the Secure Real-time Transport Protocol, [SRTP], is described in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-08.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-08.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-08.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: <2003-12-16154236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-16154236.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 Dec 17 11:02:43 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17256 for ; Wed, 17 Dec 2003 11:02:42 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C96EE535C0; Wed, 17 Dec 2003 11:02: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 BAFB15372C for ; Wed, 17 Dec 2003 11:00:26 -0500 (EST) Received: (qmail 44798 invoked by uid 3269); 17 Dec 2003 16:00:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 44795 invoked from network); 17 Dec 2003 16:00:26 -0000 Received: from diabolo.hds.utc.fr (195.83.157.26) by klesh.pair.com with SMTP; 17 Dec 2003 16:00:26 -0000 Received: by diabolo.hds.utc.fr (Postfix, from userid 1100) id 8AA876E5B; Wed, 17 Dec 2003 17:03:47 +0100 (MET) Received: from 81.255.30.220 ([81.255.30.220]) by mail.hds.utc.fr (IMP) with HTTP for ; Wed, 17 Dec 2003 17:03:47 +0100 Message-ID: <1071677027.3fe07e6350a25@mail.hds.utc.fr> From: mounir.kellil@hds.utc.fr To: George Gross Cc: canetti , msec@securemulticast.org Subject: Re: [MSEC] Re: IGAP to RFC? (fwd) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 17 Dec 2003 17:03:47 +0100 Content-Transfer-Encoding: 8bit dear all, I took a look at the IGAP draft a few moths ago. I don’t know if it has changed since then. My understanding is that one of the goals of IGAP is to provide receiver access control (with respect to the multicast delivery tree). This aims at avoiding fake IGMP report messages and reducing DoS attacks risks against the delivery tree [T. Hardjono :-)]. I noticed that in the Msec charter the receiver access control problem (or group membership security) has not been quoted. Is this an intended omission?. Best regards Mounir Selon George Gross : > Hi, > I took a 2nd look at IGAP just to be sure it really was as bad I > thought the 1st time I looked. From a both multicast security and AAA > perspective, IMHO it is unacceptable that the IETF move this forward to > informational RFC status. > > For example, passwords in the clear using PAP as per section > 3.2.1. The CHAP authentication is weak against offline dictionary attacks. > No digital signature source authentication mechanism. Lots of opportunity > for fraud, DoS, theft of service. > > The fact that a service provider and a vendor banded together to > build something like this is their private business. I recommend that it > should not be published, as it easily could become a marketware tool, and > obstruct future movement in our industry towards a secure and > comprehensive standard solution. > > For a summary of a design direction and open issues that is > congruent with both the MSEC and AAA standards, I would encourage the > folks who want to pursue MSEC/AAA please please take a look at my > presentation from IETF58 Minneapolis: > > http://www.identaware.com/IETF58_MSEC_AAA_v00.ppt > > and I would welcome their discussion on its assessment. > > br, > George > > > On Thu, 11 Dec 2003, canetti wrote: > > > > > Folks, > > > > You may want to wait for the revised version. > > > > Thanks, > > > > Ran and Thomas > > > > > > > On Wed, 10 Dec 2003, Tsunemasa Hayashi wrote: > > > > >> Ran and Thomas, > > >> > > >> Thank you for the informing MSEC of our IGAP draft. But, we > > >> would like to revise the both sections of abstract and > > >> introduction of the draft. We are explicitly going to describe > > >> the topic IGAP solves. We will update it soon. > > >> > > >> Regards, > > >> > > >> Tsune. > > >> > > >> >>>>> "canetti" == canetti writes: > > >> > > canetti> Folks, > > >> > > canetti> The private I-D > > canetti> http://www.ietf.org/internet-drafts/draft-hayashi-igap-03.txt > > canetti> describes IGAP, a group membership authentication protocol > > canetti> that allows users to authenticate themselves to a group > > canetti> center for billing and accounting purposes. The draft > > canetti> provides no means for encrypting or authenitcating the > > canetti> multicasted data. > > >> > > canetti> The authors of this I-D have asked the IESG to publish this > > canetti> document as an informational RFC. Since this is a > > canetti> security-related and multicast-repated protocol, the > > canetti> security ADs and the MSEC chairs were asked by the IESG > > canetti> whether we see a danger in endorsing the proposed protocol, > > canetti> either by providing an "insecure work around" to the MSEC > > canetti> protocols, or by interacting badly with MSEC protocols - or > > canetti> alternatively whether we think it is ok to publish the > > canetti> draft as an informational RFC. We would like to poll the WG > > canetti> for opinions. Please take the time to look ad the I-D and > > canetti> opinionate. > > >> > > canetti> Thanks, > > >> > > canetti> Ran and Thomas > > >> > > > > > > > > > > _______________________________________________ > > 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 > ------------------------------------------------- Laboratoire Heudiasyc. UMR CNRS 6599 http://www.hds.utc.fr _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 17 11:46:57 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19565 for ; Wed, 17 Dec 2003 11:46:57 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B2B87535D3; Wed, 17 Dec 2003 11:46: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 B2825536EB for ; Wed, 17 Dec 2003 11:45:14 -0500 (EST) Received: (qmail 54702 invoked by uid 3269); 17 Dec 2003 16:45:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54699 invoked from network); 17 Dec 2003 16:45:14 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 17 Dec 2003 16:45:14 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id hBHGidC43804; Wed, 17 Dec 2003 11:44:39 -0500 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7) with ESMTP id hBHGida84048; Wed, 17 Dec 2003 11:44:39 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id hBHGicv39402; Wed, 17 Dec 2003 11:44:38 -0500 From: canetti To: mounir.kellil@hds.utc.fr Cc: George Gross , msec@securemulticast.org Subject: Re: [MSEC] Re: IGAP to RFC? (fwd) In-Reply-To: <1071677027.3fe07e6350a25@mail.hds.utc.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 17 Dec 2003 11:44:37 -0500 (EST) Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 17 Dec 2003 mounir.kellil@hds.utc.fr wrote: > dear all, > I took a look at the IGAP draft a few moths ago. I don=92t know if it has= changed > since then.=20 >=20 > My understanding is that one of the goals of IGAP is to provide receiver= access > control (with respect to the multicast delivery tree). This aims at avoid= ing > fake IGMP report messages and reducing DoS attacks risks against the deli= very > tree [T. Hardjono :-)].=20 > I noticed that in the Msec charter the receiver access control problem (o= r group > membership security) has not been quoted. Is this an intended omission?.= =20 Depends on what you mean by "group membership security". MSEC charter certainly addresses access control for the multicasted data. (That is, it is a requirement that non-members do not have access to the plaintext data.) However, the charter does not address protecting the multicast routing infrastructure from DoS attacks. This is indeed intentional, in order to have a focused set of goals that can be completed in reasonable time. Once we near completion of the present set of goals, we can start discussion on rechartering msec to deal also with this set of problems. Regarding IGAP, from reading the present draft, it looked like the intention there is controlling access to the multicasted data, including billing and accounting, rather than protecting the infrastructure from DoS attacks. But perhaps we should wait for the revised version for clarifications. Best, Ran >=20 > Best regards >=20 >=20 > Mounir >=20 >=20 > Selon George Gross : >=20 > > Hi, > > =09I took a 2nd look at IGAP just to be sure it really was as bad I > > thought the 1st time I looked. From a both multicast security and AAA > > perspective, IMHO it is unacceptable that the IETF move this forward to > > informational RFC status. > >=20 > > =09For example, passwords in the clear using PAP as per section > > 3.2.1. The CHAP authentication is weak against offline dictionary attac= ks. > > No digital signature source authentication mechanism. Lots of opportuni= ty > > for fraud, DoS, theft of service. > >=20 > > =09The fact that a service provider and a vendor banded together to > > build something like this is their private business. I recommend that i= t > > should not be published, as it easily could become a marketware tool, a= nd > > obstruct future movement in our industry towards a secure and > > comprehensive standard solution. > >=20 > > =09For a summary of a design direction and open issues that is > > congruent with both the MSEC and AAA standards, I would encourage the > > folks who want to pursue MSEC/AAA please please take a look at my > > presentation from IETF58 Minneapolis: > >=20 > > http://www.identaware.com/IETF58_MSEC_AAA_v00.ppt > >=20 > > and I would welcome their discussion on its assessment. > >=20 > > br, > > =09George > >=20 > >=20 > > On Thu, 11 Dec 2003, canetti wrote: > >=20 > > > > > > Folks, > > > > > > You may want to wait for the revised version. > > > > > > Thanks, > > > > > > Ran and Thomas > > > > > > > > > > On Wed, 10 Dec 2003, Tsunemasa Hayashi wrote: > > > > > > >> Ran and Thomas, > > > >> > > > >> Thank you for the informing MSEC of our IGAP draft. But, we > > > >> would like to revise the both sections of abstract and > > > >> introduction of the draft. We are explicitly going to describe > > > >> the topic IGAP solves. We will update it soon. > > > >> > > > >> Regards, > > > >> > > > >> Tsune. > > > >> > > > >> >>>>> "canetti" =3D=3D canetti writes= : > > > >> > > > canetti> Folks, > > > >> > > > canetti> The private I-D > > > canetti> http://www.ietf.org/internet-drafts/draft-hayashi-igap-0= 3.txt > > > canetti> describes IGAP, a group membership authentication protoc= ol > > > canetti> that allows users to authenticate themselves to a group > > > canetti> center for billing and accounting purposes. The draft > > > canetti> provides no means for encrypting or authenitcating the > > > canetti> multicasted data. > > > >> > > > canetti> The authors of this I-D have asked the IESG to publish t= his > > > canetti> document as an informational RFC. Since this is a > > > canetti> security-related and multicast-repated protocol, the > > > canetti> security ADs and the MSEC chairs were asked by the IESG > > > canetti> whether we see a danger in endorsing the proposed protoc= ol, > > > canetti> either by providing an "insecure work around" to the MSE= C > > > canetti> protocols, or by interacting badly with MSEC protocols -= or > > > canetti> alternatively whether we think it is ok to publish the > > > canetti> draft as an informational RFC. We would like to poll the= WG > > > canetti> for opinions. Please take the time to look ad the I-D an= d > > > canetti> opinionate. > > > >> > > > canetti> Thanks, > > > >> > > > canetti> Ran and Thomas > > > >> > > > > > > > > > > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://www.pairlist.net/mailman/listinfo/msec > > > > >=20 > >=20 > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------- > Laboratoire Heudiasyc. UMR CNRS 6599 > http://www.hds.utc.fr >=20 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 17 12:06:50 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20629 for ; Wed, 17 Dec 2003 12:06:49 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5FC15537C1; Wed, 17 Dec 2003 12:06: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 A83E053588 for ; Wed, 17 Dec 2003 12:05:54 -0500 (EST) Received: (qmail 58747 invoked by uid 3269); 17 Dec 2003 17:05:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58744 invoked from network); 17 Dec 2003 17:05:54 -0000 Received: from diabolo.hds.utc.fr (195.83.157.26) by klesh.pair.com with SMTP; 17 Dec 2003 17:05:54 -0000 Received: by diabolo.hds.utc.fr (Postfix, from userid 1100) id C6DBF6E89; Wed, 17 Dec 2003 18:09:15 +0100 (MET) Received: from wwwgate181.motorola.com (wwwgate181.motorola.com [62.180.53.220]) by mail.hds.utc.fr (IMP) with HTTP for ; Wed, 17 Dec 2003 18:09:15 +0100 Message-ID: <1071680955.3fe08dbb976b9@mail.hds.utc.fr> From: mounir.kellil@hds.utc.fr To: canetti Cc: George Gross , msec@securemulticast.org Subject: Re: [MSEC] Re: IGAP to RFC? (fwd) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 17 Dec 2003 18:09:15 +0100 Content-Transfer-Encoding: 8bit Ran, thank you for your useful explanations, Just a little remark: as far as I know, regarding the term "group membership", it has been used in the msec WG area to describe both the registration and rekeying procedures (member-GCKS). The "group membership" term is also used to describe IGMP/MLD protocols (member-router). On the other hand, the term "access control" has been used in the msec WG area to deal with multicast data confidentiality. In the literature, we also can find the term "access control" in the work that addresses the security issues in the edge of the multicast distribution tree. Mounir Selon canetti : > > > On Wed, 17 Dec 2003 mounir.kellil@hds.utc.fr wrote: > > > dear all, > > I took a look at the IGAP draft a few moths ago. I don’t know if it has > changed > > since then. > > > > My understanding is that one of the goals of IGAP is to provide receiver > access > > control (with respect to the multicast delivery tree). This aims at > avoiding > > fake IGMP report messages and reducing DoS attacks risks against the > delivery > > tree [T. Hardjono :-)]. > > I noticed that in the Msec charter the receiver access control problem (or > group > > membership security) has not been quoted. Is this an intended omission?. > > Depends on what you mean by "group membership security". MSEC charter > certainly addresses access control for the multicasted data. > (That is, it is a requirement that non-members do not have access > to the plaintext data.) However, the charter does not address protecting > the multicast routing infrastructure from DoS attacks. This is indeed > intentional, in order to have a focused set of goals that can be > completed in reasonable time. Once we near completion of the present set of > goals, we can start discussion on rechartering msec to deal also with this > set of problems. > > Regarding IGAP, from reading the present draft, it looked like the > intention there is controlling access to the multicasted data, including > billing and accounting, rather than protecting the infrastructure from > DoS attacks. But perhaps we should wait for the revised version for > clarifications. > > Best, > > Ran > > > > > > Best regards > > > > > > Mounir > > > > > > Selon George Gross : > > > > > Hi, > > > I took a 2nd look at IGAP just to be sure it really was as bad I > > > thought the 1st time I looked. From a both multicast security and AAA > > > perspective, IMHO it is unacceptable that the IETF move this forward to > > > informational RFC status. > > > > > > For example, passwords in the clear using PAP as per section > > > 3.2.1. The CHAP authentication is weak against offline dictionary > attacks. > > > No digital signature source authentication mechanism. Lots of > opportunity > > > for fraud, DoS, theft of service. > > > > > > The fact that a service provider and a vendor banded together to > > > build something like this is their private business. I recommend that it > > > should not be published, as it easily could become a marketware tool, > and > > > obstruct future movement in our industry towards a secure and > > > comprehensive standard solution. > > > > > > For a summary of a design direction and open issues that is > > > congruent with both the MSEC and AAA standards, I would encourage the > > > folks who want to pursue MSEC/AAA please please take a look at my > > > presentation from IETF58 Minneapolis: > > > > > > http://www.identaware.com/IETF58_MSEC_AAA_v00.ppt > > > > > > and I would welcome their discussion on its assessment. > > > > > > br, > > > George > > > > > > > > > On Thu, 11 Dec 2003, canetti wrote: > > > > > > > > > > > Folks, > > > > > > > > You may want to wait for the revised version. > > > > > > > > Thanks, > > > > > > > > Ran and Thomas > > > > > > > > > > > > > On Wed, 10 Dec 2003, Tsunemasa Hayashi wrote: > > > > > > > > >> Ran and Thomas, > > > > >> > > > > >> Thank you for the informing MSEC of our IGAP draft. But, we > > > > >> would like to revise the both sections of abstract and > > > > >> introduction of the draft. We are explicitly going to describe > > > > >> the topic IGAP solves. We will update it soon. > > > > >> > > > > >> Regards, > > > > >> > > > > >> Tsune. > > > > >> > > > > >> >>>>> "canetti" == canetti writes: > > > > >> > > > > canetti> Folks, > > > > >> > > > > canetti> The private I-D > > > > canetti> > http://www.ietf.org/internet-drafts/draft-hayashi-igap-03.txt > > > > canetti> describes IGAP, a group membership authentication > protocol > > > > canetti> that allows users to authenticate themselves to a group > > > > canetti> center for billing and accounting purposes. The draft > > > > canetti> provides no means for encrypting or authenitcating the > > > > canetti> multicasted data. > > > > >> > > > > canetti> The authors of this I-D have asked the IESG to publish > this > > > > canetti> document as an informational RFC. Since this is a > > > > canetti> security-related and multicast-repated protocol, the > > > > canetti> security ADs and the MSEC chairs were asked by the IESG > > > > canetti> whether we see a danger in endorsing the proposed > protocol, > > > > canetti> either by providing an "insecure work around" to the MSEC > > > > canetti> protocols, or by interacting badly with MSEC protocols - > or > > > > canetti> alternatively whether we think it is ok to publish the > > > > canetti> draft as an informational RFC. We would like to poll the > WG > > > > canetti> for opinions. Please take the time to look ad the I-D and > > > > canetti> opinionate. > > > > >> > > > > canetti> Thanks, > > > > >> > > > > canetti> Ran and Thomas > > > > >> > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > > > ------------------------------------------------- > > Laboratoire Heudiasyc. UMR CNRS 6599 > > http://www.hds.utc.fr > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > > ------------------------------------------------- Laboratoire Heudiasyc. UMR CNRS 6599 http://www.hds.utc.fr _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Dec 18 19:00:01 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29823 for ; Thu, 18 Dec 2003 19:00:01 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5821953794; Thu, 18 Dec 2003 18:59:27 -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 6DC4A53609 for ; Thu, 18 Dec 2003 14:58:54 -0500 (EST) Received: (qmail 89355 invoked by uid 3269); 18 Dec 2003 19:58:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89352 invoked from network); 18 Dec 2003 19:58:54 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 18 Dec 2003 19:58:54 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Dec 2003 12:02:09 +0000 Received: from cisco.com (stealth-10-32-244-210.cisco.com [10.32.244.210]) by sj-core-5.cisco.com (8.12.9/8.12.6) with SMTP id hBIJwKZ0024274; Thu, 18 Dec 2003 11:58:21 -0800 (PST) Message-ID: <3FE206DC.AF96820D@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: canetti Cc: msec@securemulticast.org Subject: Re: [MSEC] Re: IGAP to RFC? (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 18 Dec 2003 11:58:20 -0800 Content-Transfer-Encoding: 7bit Folks, After a lot of thought I'm still having a hard time coming up with a justification for accepting a document that specifies the use of clear-text passwords (i.e., use of PAP). That really has no place in new RFCs, even Informational ones. Issues with clear-text passwords aren't discussed at all in the Security Considerations document. On suggestion would to take out the support for PAP, leaving only CHAP. But I believe that CHAP is probably not so likely to be deployed because it appear to require new challenge/response message flows. Finally, I surprised that IGAP is an update to IGMPv2, which has been made obsolete by the latest version of IGMP (IGMPv3, RFC 3376). I understand why it might be desirable to do this in ones product, but I don't think it's appropriate to specify a new standard adding to an obsolete version of a protocol. Brian canetti wrote: > > Folks, > > You may want to wait for the revised version. > > Thanks, > > Ran and Thomas > > > On Wed, 10 Dec 2003, Tsunemasa Hayashi wrote: > > >> Ran and Thomas, > >> > >> Thank you for the informing MSEC of our IGAP draft. But, we > >> would like to revise the both sections of abstract and > >> introduction of the draft. We are explicitly going to describe > >> the topic IGAP solves. We will update it soon. > >> > >> Regards, > >> > >> Tsune. > >> > >> >>>>> "canetti" == canetti writes: > >> > canetti> Folks, > >> > canetti> The private I-D > canetti> http://www.ietf.org/internet-drafts/draft-hayashi-igap-03.txt > canetti> describes IGAP, a group membership authentication protocol > canetti> that allows users to authenticate themselves to a group > canetti> center for billing and accounting purposes. The draft > canetti> provides no means for encrypting or authenitcating the > canetti> multicasted data. > >> > canetti> The authors of this I-D have asked the IESG to publish this > canetti> document as an informational RFC. Since this is a > canetti> security-related and multicast-repated protocol, the > canetti> security ADs and the MSEC chairs were asked by the IESG > canetti> whether we see a danger in endorsing the proposed protocol, > canetti> either by providing an "insecure work around" to the MSEC > canetti> protocols, or by interacting badly with MSEC protocols - or > canetti> alternatively whether we think it is ok to publish the > canetti> draft as an informational RFC. We would like to poll the WG > canetti> for opinions. Please take the time to look ad the I-D and > canetti> opinionate. > >> > canetti> Thanks, > >> > canetti> Ran and Thomas > >> > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec