From msec-bounces@securemulticast.org Fri Sep 09 20:01:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDsnk-0002gu-TZ for msec-archive@megatron.ietf.org; Fri, 09 Sep 2005 20:01:01 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23310 for ; Fri, 9 Sep 2005 20:00:58 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C6C888C8BD; Fri, 9 Sep 2005 20:00:58 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id A01A98C7D8 for ; Fri, 9 Sep 2005 20:00:57 -0400 (EDT) Received: (qmail 9437 invoked by uid 3269); 10 Sep 2005 00:00:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9434 invoked from network); 10 Sep 2005 00:00:57 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 10 Sep 2005 00:00:57 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 4F51A68352 for ; Fri, 9 Sep 2005 20:00:57 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8A00sIr010504; Fri, 9 Sep 2005 17:00:54 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8A00pkN019701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Sep 2005 17:00:52 -0700 (PDT) Message-Id: <6.2.2.1.2.20050909165332.031f7500@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Fri, 09 Sep 2005 17:00:47 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_108403395==_" Cc: canetti , jeff.mandin@streetwaves.com.cnri.reston.va.us Subject: [MSEC] MSEC Review of 802.16eD7 specification X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --=====================_108403395==_ Content-Type: text/html; charset="us-ascii" Hi all,

Attached is the draft text that I plan to submit to the 802.16e group as the response to their request for MSEC review of the version 7 of the 802.16e draft specification.  The review is a summary of all the reviews that were received just before the Paris meeting.  I would like to take the opportunity to thank the reviewers for their time.  Please feel free to suggest any revisions to the review text.  (Note: I am explicitly noting that this review does NOT reflect MSEC WG consensus).

Jeff,

Please let us know if we can clarify anything.  Also, please feel free to use any text from the review towards contributions to the 16e group.  Once Ran and you give the go ahead, I will submit the review as the official MSEC response to the review request.

thanks and regards,
Lakshminath --=====================_108403395==_ Content-Type: text/plain; charset="us-ascii" September 09, 2005 Roger B. Marks, Chair, IEEE 802.16 cc: Jeff Mandin, IEEE 802.16 Liaison to IETF Brian Kiernan, Chair, IEEE 802.16 Task Group e Ran Canetti, co-chair, IETF MSEC Working Group Bernard Aboba, IETF Liaison to IEEE 802 Russ Housley, Security Area Director, IETF Sam Hartman, Security Area Director, IETF MSEC WG, msec@securemulticast.org Subject: MSEC Working Group review of the 802.16eD7 specification (MBS and Multicast security mechanisms) Editor: Lakshminath Dondeti Reviewers: Ran Canetti Lakshminath Dondeti Dragan Ignjatic Men Long QinKe Brian Weis Review process: The MSEC chairs sent an open request to the MSEC mailing list to review the 802.16eD7 specification. The chairs also personally recruited MSEC contributors (authors and editors) to review the specification. IETF participation is on an individual basis and to the best of the Editor's knowledge the comments are individuals' opinions. The 802.16 liaison has been copied on the full reviews. Note: This review is based on voluntary contributions and does not reflect the consensus of the MSEC WG. Summary: The MBS and Multicast security portions of the 802.16eD7 specification are in a good shape. The reviewers identified group rekeying, group authentication, counter mode usage, and notes on security properties as areas of potential improvement. In most cases, the reviews request clarification, but in a few instances, suggest improvements to the specification. Review: The following topics have been identified by the MSEC reviewers as areas of concern. 1.0 One-to-many authentication: >From section 7.8.3: The current specification does not seem to cover one-to-many authentication for the transmitted contents. This is in contrast to the unicast case where the contents is authenticated. I can see the rationale for this decision (since one-to-many authentication is indeed more complext than unicast authentication); but it might be a good idea to say it explicitly in the document. (otherwise, implementors and users might get a "false feeling of security".) 2.0 Group rekeying: Another issue that seems to be left uncovered is dealing with key management for dynamically changing groups. Again, I can understand this decision on basis of efficiency (although some not-that-complex solutions do exist). But I would recommend saying so explicitly and providing some rationale. 2.1 In the current specification, Group key update messages are integrity protected with a group key. The specification correctly notes that using a group key for intergrity protection of data allows any member of the group to impersonate the BS. With group authentication of group key update messages, the attacker can modify the GTEK or GKEK itself to efficiently carry out the impersonation attack. In MSEC protocols, rekey messages are signed by the sender. That allows security encapsulated data packets to be either group authenticated (with the threat of impersonation) or source authenticated (using the TESLA protocol -- which has low overhead, but requires loose time synchronization). Perhaps the 802.16e specification might consider signing group key update messages (in frequent, so should not be too much of a performance burden). 3.0 Cipher mode usage: Section 7.8.4.1 Data encryption with AES in CTR mode Using a counter mode algorithm to protect a GTEK is only safe if the multicast or broadcast traffic originates with one sender (e.g., the BS). This is due to the (already stated) issue that a counter can only be used once per key. However, since the document does not describe any means of avoiding multiple senders to use the counter space (e.g., by allocating each sender a subset of the counter space), the single sender rule must apply. Note that even if the GTEK only authorizes one sender to use the key, the GTEK is a shared key. There is still a risk of an unauthorized BS sending packets encrypted with the counter mode GTEK key (either unintentionally, or in collusion with an eavesdropper). In summary, CTR mode isn't a very good mode to use with GTEKs. 4.0 Notes on security considerations: MBS security encapsulation does not include integrity protection. Encryption without integrity protection might undermine confidentiality property itself. Thus, while group keys only provide group authentication of data, it is still beneficial to use it. We understand that the design decision was made to reduce per-packet overhead and with the consideration that the data sent via MBS might not need "strong" protection. We suggest to add a note in the MBS section along these lines to indicate potential threats even after the MBS security encapsulation. We also note that there is not sufficient detail in the 802.16e specification about the protections provided or not provided by the protocols employed. For example, lack of integrity protection in MBS PDUs might be pointed out so the users and implementers are aware of the implications. 5.0 Additional comments Section 7.2.2.3.3: Please explain the role of a MGTEK if a MAK is already present. Section 7.2.2.4.2 Last sentence - How does the receiver know whether GKEK or KEK is used to encrypt? Please clarify. Section 7.2.2.3.2: Please fill in all the contents of a GSA: GTEK & GKEK (two sets, grace time)? --=====================_108403395==_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --=====================_108403395==_-- From msec-bounces@securemulticast.org Tue Sep 13 10:36:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFBti-00084T-UY for msec-archive@megatron.ietf.org; Tue, 13 Sep 2005 10:36:36 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25156 for ; Tue, 13 Sep 2005 10:36:28 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B5C978CC92; Tue, 13 Sep 2005 10:36:23 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 7755F8CB44 for ; Tue, 13 Sep 2005 10:36:22 -0400 (EDT) Received: (qmail 3444 invoked by uid 3269); 13 Sep 2005 14:36:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3441 invoked from network); 13 Sep 2005 14:36:20 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 13 Sep 2005 14:36:20 -0000 Received: from mx1.lan.ch (mx1.lan.ch [212.60.61.244]) by klesh.pair.com (Postfix) with ESMTP id B98D468352 for ; Tue, 13 Sep 2005 10:36:20 -0400 (EDT) Received: from localhost (av1.lan.ch [127.0.0.1]) by av1.lan.ch (Postfix) with SMTP id 6D6756BB05 for ; Tue, 13 Sep 2005 16:36:17 +0200 (CEST) Received: from mail.hazienda.local (49-195-221-213-pool.cable.lan.ch [213.221.195.49]) by mx1.lan.ch (Postfix) with ESMTP id 23FA66BB0A for ; Tue, 13 Sep 2005 16:36:17 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hazienda.local (Postfix) with ESMTP id 6687A2769E for ; Tue, 13 Sep 2005 16:36:18 +0200 (CEST) Received: from mail.hazienda.local ([127.0.0.1]) by localhost (mail.hazienda.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23758-01 for ; Tue, 13 Sep 2005 16:35:56 +0200 (CEST) Received: from [192.168.0.198] (thunderbird.hazienda.local [192.168.0.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hazienda.local (Postfix) with ESMTP id 57ABD2769A for ; Tue, 13 Sep 2005 16:35:54 +0200 (CEST) Message-ID: <4326E40B.10406@ggs.ch> Date: Tue, 13 Sep 2005 16:36:59 +0200 From: reet User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050801) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: amavisd-new at hazienda.local X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mx1.lan.ch X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,FORGED_RCVD_HELO, FROM_ENDS_IN_NUMS autolearn=disabled version=3.0.1 Subject: [MSEC] GSAKMP X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA25156 Hi MSEC list, I'm trying to do some testing with implementations of group key management protocols on linux. I found the GSAKMP proof-of-concept implementation (version 0.8.1) but it needs some changes to compile on a current linux system (gcc-3.3.5). Is this version the latest version available? If not, where could I find a more recent version of this implementation? Are you aware of possible other implementations of group key management protocols? Thank you very much for your help! Reto B=FCrki _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Sep 14 07:29:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVSV-0000JZ-Q1 for msec-archive@megatron.ietf.org; Wed, 14 Sep 2005 07:29:47 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04925 for ; Wed, 14 Sep 2005 07:29:46 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6ED6C8CA44; Wed, 14 Sep 2005 07:29:46 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 71A768C943 for ; Wed, 14 Sep 2005 07:29:45 -0400 (EDT) Received: (qmail 20588 invoked by uid 3269); 14 Sep 2005 11:29:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20585 invoked from network); 14 Sep 2005 11:29:45 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 14 Sep 2005 11:29:45 -0000 Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by klesh.pair.com (Postfix) with SMTP id 4689C68359 for ; Wed, 14 Sep 2005 07:29:45 -0400 (EDT) Received: (qmail 3739 invoked from network); 14 Sep 2005 07:29:40 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 14 Sep 2005 07:29:40 -0400 Received: (qmail 86959 invoked from network); 14 Sep 2005 07:29:40 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 14 Sep 2005 07:29:40 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j8E83Mi32516; Wed, 14 Sep 2005 04:03:22 -0400 Date: Wed, 14 Sep 2005 04:03:18 -0400 (EDT) From: George Gross To: reet Subject: Re: [MSEC] GSAKMP In-Reply-To: <4326E40B.10406@ggs.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Reto, On Tue, 13 Sep 2005, reet wrote: > Hi MSEC list, > > I'm trying to do some testing with implementations of group key > management protocols on linux. I found the GSAKMP proof-of-concept > implementation (version 0.8.1) but it needs some changes to compile on a > current linux system (gcc-3.3.5). Is this version the latest version > available? If not, where could I find a more recent version of this > implementation? AFAIK, the GSAKMP version you mentioned is the only one available with source code in the public domain. I have not attempted to compile that source code, so I'm not able to offer you advice about making it work with gcc-3.3.5. > Are you aware of possible other implementations of group > key management protocols? There is a GDOI implementation at http://www.vovida.org. I do not know of any MIKEY implementations in the public domain. perhaps someone else on the MSEC list may know of one? hth, =09George > > Thank you very much for your help! > > Reto B=FCrki > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 15 09:06:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtRY-0007CU-DK for msec-archive@megatron.ietf.org; Thu, 15 Sep 2005 09:06:26 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09101 for ; Thu, 15 Sep 2005 09:06:22 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 523EE8CC3E; Thu, 15 Sep 2005 09:06:23 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id EB81E8CC05 for ; Thu, 15 Sep 2005 09:06:22 -0400 (EDT) Received: (qmail 70962 invoked by uid 3269); 15 Sep 2005 13:06:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 70959 invoked from network); 15 Sep 2005 13:06:22 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 15 Sep 2005 13:06:22 -0000 Received: from 126.com (bj45-161.i.netease.com [202.108.45.161]) by klesh.pair.com (Postfix) with SMTP id 63D1868354 for ; Thu, 15 Sep 2005 09:06:20 -0400 (EDT) Received: from thinker (unknown [202.115.28.189]) by smtp4 (Coremail) with SMTP id 0wCxTsZxKUNmvB5n.1 for ; Thu, 15 Sep 2005 21:06:18 +0800 (CST) X-Originating-IP: [202.115.28.189] Date: Thu, 15 Sep 2005 21:06:06 +0800 From: "QinKe" To: "msec" Organization: UESTC X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20050915130620.63D1868354@klesh.pair.com> Subject: [MSEC] any overwhelming advantages of distributed key generation? X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992287842==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============0992287842== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBmb2xrczoNCg0KCUmhr2QgbGlrZSB0byBrbm93LCBhcmUgdGhlcmUgYW55IG92ZXJ3aGVs bWluZyBhZHZhbnRhZ2VzIG9mIGRpc3RyaWJ1dGVkIGtleSBnZW5lcmF0aW9uPyBJbiBvdGhlciB3 b3JkcywgaXMgaXQgbmVjZXNzYXJ5IHRoYXQgYWxsIHVzZXJzIGNhbiB0YWtlIHBhcnQgaW4ga2V5 IGdlbmVyYXRpb24/DQogCVRoYW5rIHlvdSBmb3IgeW91ciByZXBseSBpbiBhZHZhbmNlIQ0KIAkJ CQkNCg0KoaGhoaGhoaGhoaGhoaGhoVFpbktlDQqhoaGhoaGhoaGhoaGhoaGheXV4dWFucWtAMTI2 LmNvbQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA1LTA5LTE1DQo= --===============0992287842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0992287842==-- From msec-bounces@securemulticast.org Fri Sep 16 08:45:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGFaP-0002T9-NR for msec-archive@megatron.ietf.org; Fri, 16 Sep 2005 08:45:01 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14191 for ; Fri, 16 Sep 2005 08:44:59 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D03C08C554; Fri, 16 Sep 2005 08:45:00 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 4E6128C16C for ; Fri, 16 Sep 2005 08:44:59 -0400 (EDT) Received: (qmail 86100 invoked by uid 3269); 16 Sep 2005 12:44:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86097 invoked from network); 16 Sep 2005 12:44:59 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 16 Sep 2005 12:44:59 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id CE6EC68352 for ; Fri, 16 Sep 2005 08:44:58 -0400 (EDT) Received: (qmail 93125 invoked from network); 16 Sep 2005 12:44:55 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 16 Sep 2005 12:44:55 -0000 Received: (qmail 89336 invoked from network); 16 Sep 2005 08:44:55 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 16 Sep 2005 08:44:55 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j8G9IIH03737; Fri, 16 Sep 2005 05:18:18 -0400 Date: Fri, 16 Sep 2005 05:18:18 -0400 (EDT) From: George Gross To: QinKe Subject: Re: [MSEC] any overwhelming advantages of distributed key generation? In-Reply-To: <20050915130620.63D1868354@klesh.pair.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: msec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, A distributed key generation algorithm is best suited for small-scale groups that have nodes with enough computational resources for group Diffie-Hellman key agreement and enough memory to store state information about all of the group's members. There also has to be a trusted mechanism to announce the membership join/leave events and the DH public keys. In contrast, large-scale groups usually have a central trusted group key server. the answer to your question is really dependent on your secure multicast application's requirements. what is your application? hth, =09George On Thu, 15 Sep 2005, QinKe wrote: > Dear folks: > > =09I=A1=AFd like to know, are there any overwhelming advantages of distri= buted key generation? In other words, is it necessary that all users can ta= ke part in key generation? > =09Thank you for your reply in advance! > > > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1QinKe > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1yuxuanqk@126.com > =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12005-09-15 > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Sep 16 09:24:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGCm-0004Hs-21 for msec-archive@megatron.ietf.org; Fri, 16 Sep 2005 09:24:43 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16388 for ; Fri, 16 Sep 2005 09:24:37 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7CB8A8CC8E; Fri, 16 Sep 2005 09:17:03 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 8141F8D197 for ; Fri, 16 Sep 2005 09:12:09 -0400 (EDT) Received: (qmail 89913 invoked by uid 3269); 16 Sep 2005 13:12:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89910 invoked from network); 16 Sep 2005 13:12:09 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 16 Sep 2005 13:12:09 -0000 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by klesh.pair.com (Postfix) with ESMTP id 5B50B68359 for ; Fri, 16 Sep 2005 09:12:09 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 16 Sep 2005 06:12:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8GDBwKG025377; Fri, 16 Sep 2005 06:12:03 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 06:12:05 -0700 Received: from [10.32.254.211] ([10.32.254.211]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 06:12:04 -0700 In-Reply-To: <20050915130620.63D1868354@klesh.pair.com> References: <20050915130620.63D1868354@klesh.pair.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <5d7534565795052e542e2f6e2d8e793f@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [MSEC] any overwhelming advantages of distributed key generation? Date: Fri, 16 Sep 2005 06:12:02 -0700 To: "QinKe" X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 16 Sep 2005 13:12:04.0651 (UTC) FILETIME=[3B9C3FB0:01C5BAC0] Cc: "'msec@securemulticast.org'" X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit QinKe, there are various goals that are worthwhile and which can be met with distributed key generation. For example, the key generation algorithm can be designed so that its output is uniformly random as long as the random source used by at least one of the members is actually uniformly random (to defend against bad random sources). Another goal is that no single member can "control" the key, that is, can uniquely determine what the key is. People who work in this area can undoubtedly cite many more goals. Of course, the benefits of distributed key distribution must be weighed against its disadvantages. Many such schemes have a high complexity, and many have a high computational cost. David On Sep 15, 2005, at 6:06 AM, QinKe wrote: > Dear folks: > > I’d like to know, are there any overwhelming advantages of > distributed key generation? In other words, is it necessary that all > users can take part in key generation? > Thank you for your reply in advance! > > > 　　　　　　　　QinKe > 　　　　　　　　yuxuanqk@126.com > 　　　　　　　　　　2005-09-15 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Sep 16 10:21:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGH5U-0003Ul-HG for msec-archive@megatron.ietf.org; Fri, 16 Sep 2005 10:21:12 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20110 for ; Fri, 16 Sep 2005 10:21:09 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1FED68C751; Fri, 16 Sep 2005 10:20:57 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 929A38C6C2 for ; Fri, 16 Sep 2005 10:20:56 -0400 (EDT) Received: (qmail 99983 invoked by uid 3269); 16 Sep 2005 14:20:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99980 invoked from network); 16 Sep 2005 14:20:56 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 16 Sep 2005 14:20:56 -0000 Received: from 126.com (bj45-160.i.netease.com [202.108.45.160]) by klesh.pair.com (Postfix) with SMTP id DFA0768352 for ; Fri, 16 Sep 2005 10:20:54 -0400 (EDT) Received: from thinker (unknown [202.115.28.189]) by smtp3 (Coremail) with SMTP id t4BKCcXUKkNlYM4v.1 for ; Fri, 16 Sep 2005 22:20:55 +0800 (CST) X-Originating-IP: [202.115.28.189] Date: Fri, 16 Sep 2005 22:20:45 +0800 From: "QinKe" To: "msec" Subject: Re: Re: [MSEC] any overwhelming advantages of distributed key generation? Organization: UESTC X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20050916142054.DFA0768352@klesh.pair.com> X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0873475005==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============0873475005== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 R2VvcmdlIEdyb3NzOg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkuIEkgaGF2ZSBub3QgYSBj b25jcmV0ZSBhcHBsaWNhdGlvbi4gV2hhdCBJIGFtIHRoaW5raW5nIGlzIHRoYXQgdGhlIGdyb3Vw IERIIGtleSBhZ3JlZW1lbnQgaGFzIGEgaGlnaCBjb21wdXRhdGlvbmFsIGNvc3QuIEkgYW0gZG9p bmcgc29tZSByZXNlYXJjaCBvbiBncm91cCBrZXkgYWdyZWVtZW50IG5vdy4gQnV0IHByZXZpb3Vz bHksIEkgaGF2ZSBub3Qgc2VlbiB0b28gbXVjaCBvdmVyd2hlbG1pbmcgYWR2YW50YWdlcyBvZiBk aXN0cmlidXRlZCBrZXkgZ2VuZXJhdGlvbi4gICANCgkJCQkgDQqhoaGhoaGhoaGhoaGhoaGhICAg ICAgUWluS2UNCqGhoaGhoaGhoaGhoaGhoaF5dXh1YW5xa0AxMjYuY29tDQqhoaGhoaGhoaGhoaGh oaGhoaGhoTIwMDUtMDktMTYNCg0KDQo+SGksDQo+DQo+QSBkaXN0cmlidXRlZCBrZXkgZ2VuZXJh dGlvbiBhbGdvcml0aG0gaXMgYmVzdCBzdWl0ZWQgZm9yIHNtYWxsLXNjYWxlDQo+Z3JvdXBzIHRo YXQgaGF2ZSBub2RlcyB3aXRoIGVub3VnaCBjb21wdXRhdGlvbmFsIHJlc291cmNlcyBmb3IgZ3Jv dXANCj5EaWZmaWUtSGVsbG1hbiBrZXkgYWdyZWVtZW50IGFuZCBlbm91Z2ggbWVtb3J5IHRvIHN0 b3JlIHN0YXRlIGluZm9ybWF0aW9uDQo+YWJvdXQgYWxsIG9mIHRoZSBncm91cCdzIG1lbWJlcnMu IFRoZXJlIGFsc28gaGFzIHRvIGJlIGEgdHJ1c3RlZCBtZWNoYW5pc20NCj50byBhbm5vdW5jZSB0 aGUgbWVtYmVyc2hpcCBqb2luL2xlYXZlIGV2ZW50cyBhbmQgdGhlIERIIHB1YmxpYyBrZXlzLg0K Pg0KPkluIGNvbnRyYXN0LCBsYXJnZS1zY2FsZSBncm91cHMgdXN1YWxseSBoYXZlIGEgY2VudHJh bCB0cnVzdGVkIGdyb3VwIGtleQ0KPnNlcnZlci4NCj4NCj50aGUgYW5zd2VyIHRvIHlvdXIgcXVl c3Rpb24gaXMgcmVhbGx5IGRlcGVuZGVudCBvbiB5b3VyIHNlY3VyZSBtdWx0aWNhc3QNCj5hcHBs aWNhdGlvbidzIHJlcXVpcmVtZW50cy4NCj4NCj53aGF0IGlzIHlvdXIgYXBwbGljYXRpb24/DQo+ DQo+aHRoLA0KPglHZW9yZ2UNCj4NCj5PbiBUaHUsIDE1IFNlcCAyMDA1LCBRaW5LZSB3cm90ZToN Cj4NCj4+IERlYXIgZm9sa3M6DQo+Pg0KPj4gCUmhr2QgbGlrZSB0byBrbm93LCBhcmUgdGhlcmUg YW55IG92ZXJ3aGVsbWluZyBhZHZhbnRhZ2VzIG9mIGRpc3RyaWJ1dGVkIGtleSBnZW5lcmF0aW9u PyBJbiBvdGhlciB3b3JkcywgaXMgaXQgbmVjZXNzYXJ5IHRoYXQgYWxsIHVzZXJzIGNhbiB0YWtl IHBhcnQgaW4ga2V5IGdlbmVyYXRpb24/DQo+PiAgCVRoYW5rIHlvdSBmb3IgeW91ciByZXBseSBp biBhZHZhbmNlIQ0KPj4NCj4+DQo+PiChoaGhoaGhoaGhoaGhoaGhUWluS2UNCj4+IKGhoaGhoaGh oaGhoaGhoaF5dXh1YW5xa0AxMjYuY29tDQo+PiChoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDkt MTUNCj4+DQoNCg0K --===============0873475005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0873475005==-- From msec-bounces@securemulticast.org Mon Sep 19 16:03:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRrd-00050x-PY for msec-archive@megatron.ietf.org; Mon, 19 Sep 2005 16:03:45 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23570 for ; Mon, 19 Sep 2005 16:03:43 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C70328CB93; Mon, 19 Sep 2005 16:03:44 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B08C48C9F4 for ; Mon, 19 Sep 2005 16:03:42 -0400 (EDT) Received: (qmail 58470 invoked by uid 3269); 19 Sep 2005 20:03:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58467 invoked from network); 19 Sep 2005 20:03:42 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Sep 2005 20:03:42 -0000 Received: from motgate7.mot.com (motgate7.mot.com [129.188.136.7]) by klesh.pair.com (Postfix) with ESMTP id A616F68354 for ; Mon, 19 Sep 2005 16:03:37 -0400 (EDT) Received: from az33exr04.mot.com ([10.64.251.234]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id j8JKOjGI004589 for ; Mon, 19 Sep 2005 13:24:45 -0700 (MST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j8JK9NfZ021938 for ; Mon, 19 Sep 2005 15:09:24 -0500 (CDT) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Sep 2005 16:03:34 -0400 Message-ID: Thread-Topic: Looking for GDOIv2 info Thread-Index: AcW9VTc5M2NlqQUlQG2qipSFkPulOA== From: "Lewis Adam-CAL022" To: Subject: [MSEC] Looking for GDOIv2 info X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable Hi all, I'm looking for somebody to point me in the right direction for the latest status on GDOIv2. The most recent draft I can locate is http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoiv2-02.txt which is expired. The last IETF update I can find is from IETF-61 in Washington. Is this draft still alive? =20 Tx, Adam _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Sep 19 16:10:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRyc-0001p5-Gn for msec-archive@megatron.ietf.org; Mon, 19 Sep 2005 16:10:58 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24873 for ; Mon, 19 Sep 2005 16:10:56 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D03A78C776; Mon, 19 Sep 2005 16:10:57 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id D4D688C338 for ; Mon, 19 Sep 2005 16:10:55 -0400 (EDT) Received: (qmail 59780 invoked by uid 3269); 19 Sep 2005 20:10:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59777 invoked from network); 19 Sep 2005 20:10:54 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Sep 2005 20:10:54 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 0059868354 for ; Mon, 19 Sep 2005 16:10:53 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JKAnIr016688; Mon, 19 Sep 2005 13:10:49 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JKAloZ024785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Sep 2005 13:10:47 -0700 (PDT) Message-Id: <6.2.2.1.2.20050919130835.06266ac8@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Mon, 19 Sep 2005 13:10:45 -0700 To: "Lewis Adam-CAL022" , From: Lakshminath Dondeti Subject: Re: [MSEC] Looking for GDOIv2 info In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi, Yes, it is somewhat embarrassing that I dropped the ball on that. Yes, there will be a revision before Vancouver (my commitment as a co-author) and we are going to put a middle of the year 2006 LC deadline on it (as co-chair of the group). If you would like to contribute, you are welcome. Please contact me offline. thanks and regards, Lakshminath At 01:03 PM 9/19/2005, Lewis Adam-CAL022 wrote: >Hi all, > >I'm looking for somebody to point me in the right direction for the >latest status on GDOIv2. The most recent draft I can locate is >http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoiv2-02.txt which >is expired. The last IETF update I can find is from IETF-61 in >Washington. Is this draft still alive? > > >Tx, >Adam >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Sep 19 16:57:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSi4-0007ds-6a for msec-archive@megatron.ietf.org; Mon, 19 Sep 2005 16:57:59 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28926 for ; Mon, 19 Sep 2005 16:57:53 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 792B38C776; Mon, 19 Sep 2005 16:57:55 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 545898C471 for ; Mon, 19 Sep 2005 16:57:52 -0400 (EDT) Received: (qmail 69009 invoked by uid 3269); 19 Sep 2005 20:57:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69006 invoked from network); 19 Sep 2005 20:57:52 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Sep 2005 20:57:52 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 1438168352 for ; Mon, 19 Sep 2005 16:57:51 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JKvlIr022901; Mon, 19 Sep 2005 13:57:48 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JKvkoZ003807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Sep 2005 13:57:46 -0700 (PDT) Message-Id: <6.2.2.1.2.20050919135207.05d4f150@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Mon, 19 Sep 2005 13:57:44 -0700 To: "Lewis Adam-CAL022" , From: Lakshminath Dondeti Subject: Correction: Replace GDOIv2 with GKDP (Re: [MSEC] Looking for GDOIv2 info) In-Reply-To: <6.2.2.1.2.20050919130835.06266ac8@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050919130835.06266ac8@qcmail1.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, Apologies for not using the correct name of the protocol. So, we all know the old draft I submitted as GDOIv2 has since been renamed, and the work item on MSEC charter now should be referred to as GKDP. It is based on IKEv2 and so forth, but we'll reserve GDOIvX for future revisions of 3547. If this is confusing, please wait for the I-D to be posted. I will post it this week (with correct names in title, draft name etc.) and update it before the Vancouver meeting. thanks and regards, Lakshminath At 01:10 PM 9/19/2005, Lakshminath Dondeti wrote: >Hi, > >Yes, it is somewhat embarrassing that I dropped the ball on that. Yes, >there will be a revision before Vancouver (my commitment as a co-author) >and we are going to put a middle of the year 2006 LC deadline on it (as >co-chair of the group). > >If you would like to contribute, you are welcome. Please contact me offline. > >thanks and regards, >Lakshminath > >At 01:03 PM 9/19/2005, Lewis Adam-CAL022 wrote: >>Hi all, >> >>I'm looking for somebody to point me in the right direction for the >>latest status on GDOIv2. The most recent draft I can locate is >>http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoiv2-02.txt which >>is expired. The last IETF update I can find is from IETF-61 in >>Washington. Is this draft still alive? >> >> >>Tx, >>Adam >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://six.pairlist.net/mailman/listinfo/msec > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 22 14:14:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIVa8-0007d6-T9 for msec-archive@megatron.ietf.org; Thu, 22 Sep 2005 14:14:05 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14918 for ; Thu, 22 Sep 2005 14:14:02 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F2B4B8C9EE; Thu, 22 Sep 2005 14:14:00 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 84C478C9A8 for ; Thu, 22 Sep 2005 14:13:59 -0400 (EDT) Received: (qmail 65062 invoked by uid 3269); 22 Sep 2005 18:13:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65059 invoked from network); 22 Sep 2005 18:13:59 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 22 Sep 2005 18:13:59 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 3B2A068352 for ; Thu, 22 Sep 2005 14:13:59 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MIDutC004977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Sep 2005 11:13:57 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MIDsS4005444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 22 Sep 2005 11:13:55 -0700 (PDT) Message-Id: <6.2.2.1.2.20050922103429.02aaf2c0@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Thu, 22 Sep 2005 11:13:52 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Vancouver deadlines X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, Just in case you haven't seen these, here are the deadlines for the Vancouver meeting: October 10, Monday - Working Group Chair approval for (Version -00) document submissions appreciated by 09:00 ET (13:00 GMT) October 17, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (13:00 GMT) October 24, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 GMT) We need an update on at least the following documents before the meeting: RSA-R ECC Bootstrapping TESLA -- Steffen and Hannes sent an email noting this will be ready in October IPsec-extensions GKDP Did I miss any? thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 22 14:21:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIVgx-0000E7-WD for msec-archive@megatron.ietf.org; Thu, 22 Sep 2005 14:21:08 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15384 for ; Thu, 22 Sep 2005 14:21:06 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6EECF8CF91; Thu, 22 Sep 2005 14:21:07 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 941618C9FF for ; Thu, 22 Sep 2005 14:21:06 -0400 (EDT) Received: (qmail 65897 invoked by uid 3269); 22 Sep 2005 18:21:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 65894 invoked from network); 22 Sep 2005 18:21:06 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 22 Sep 2005 18:21:06 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 4D51A68354 for ; Thu, 22 Sep 2005 14:21:06 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MIL3tC006116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Sep 2005 11:21:04 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MIL1oZ021529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 22 Sep 2005 11:21:02 -0700 (PDT) Message-Id: <6.2.2.1.2.20050922111358.02aaf030@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Thu, 22 Sep 2005 11:21:00 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Call for agenda items in Vancouver X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, I plan to send a request for meeting time for MSEC at the Vancouver IETF. I have the following agenda items in mind; please let me know if there are any others: 1. IPsec-extensions 2. RSA-R (close to last call; the meeting would be a good time to raise any issues. Comments to the mailing list are welcome as usual) 3. ECC (this is also close to LC; Steffen had some thoughts on the DH groups. Any other discussion on this?) 4. GKDP Any new topics? Folks interested in presenting any multicast or group security research to MSEC, please feel free to contact Ran and me. At the moment it looks like we need about 60 minutes (may be 90 minutes if there are any other topics). thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 22 14:23:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIVj5-0000bI-MO for msec-archive@megatron.ietf.org; Thu, 22 Sep 2005 14:23:20 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15576 for ; Thu, 22 Sep 2005 14:23:18 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 1C4598C9FF; Thu, 22 Sep 2005 14:23:19 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id D88C88C814 for ; Thu, 22 Sep 2005 14:23:17 -0400 (EDT) Received: (qmail 66158 invoked by uid 3269); 22 Sep 2005 18:23:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66155 invoked from network); 22 Sep 2005 18:23:17 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 22 Sep 2005 18:23:17 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 6C1AB6835B for ; Thu, 22 Sep 2005 14:23:17 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MINEtC006394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Sep 2005 11:23:15 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MINCkN021797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 22 Sep 2005 11:23:13 -0700 (PDT) Message-Id: <6.2.2.1.2.20050922112153.0310a7a8@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Thu, 22 Sep 2005 11:23:11 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] One more item -- newtype-keyid X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, I missed one. The newtype-keyid draft might be revised after discussion and consensus in 3GPP, and may be ready for discussion and completion around Vancouver meeting time. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 22 18:10:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZH7-000725-Fo for msec-archive@megatron.ietf.org; Thu, 22 Sep 2005 18:10:41 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29154 for ; Thu, 22 Sep 2005 18:10:38 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9AAAD8C15D; Thu, 22 Sep 2005 18:10:38 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id A67C78BFD4 for ; Thu, 22 Sep 2005 18:10:36 -0400 (EDT) Received: (qmail 14463 invoked by uid 3269); 22 Sep 2005 22:10:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14460 invoked from network); 22 Sep 2005 22:10:36 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 22 Sep 2005 22:10:36 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 4A3FB68354 for ; Thu, 22 Sep 2005 18:10:36 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MM9doV009454; Thu, 22 Sep 2005 15:09:40 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MM9aoZ004324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Sep 2005 15:09:37 -0700 (PDT) Message-Id: <6.2.2.1.2.20050922133615.02af53b8@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Thu, 22 Sep 2005 15:09:35 -0700 To: "Steven M. Bellovin" , saag@mit.edu From: Lakshminath Dondeti In-Reply-To: <20050920002221.B7B973BFCBF@berkshire.machshav.com> References: <20050920002221.B7B973BFCBF@berkshire.machshav.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, msec@securemulticast.org Subject: [MSEC] Re: [saag] I-D ACTION:draft-bellovin-useipsec-04.txt (Forwarded) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Note: This document is also in IETF last call, so I am cc'ing the IESG. Someone might choose to delete them from the cc list if a long discussion follows. Summary: I read the 00 or 01 of this document, and hoped that it will be revised and brought up to date before being published as an RFC. As is stands now, it will be published in early 2006, already outdated and not as useful as it might be if revised to reflect the issues in choosing IPsecbis and IKEv2. Furthermore, many new standards proposals in the IETF and in other SDOs are already using IKEv2 and IPsecbis, so this BCP, if published as is sends mixed messages. Finally, the text on the use of IPsec for multicast security is at odds with several years worth of completed and ongoing work in the MSEC WG. Review: "Let's use IPsec (2401bis etc) and IKEv2" is what IETF WGs and other SDOs say nowadays. An entire working group (MOBIKE), at least one work item in the MIP6 WG (e.g., http://ietfreport.isoc.org/all-ids/draft-ietf-mip6-ikev2-ipsec-03.txt) and some work in 3GPP2 are examples of this. I recently started a couple of discussions in the IPSEC list asking questions that arose while working on 3GPP2 contributions, and the discussions centered around strict compliance with 2401bis and IKEv2 (as well they should; however, there are some conflicts in requirements between those two documents and there is the ikev2-clarifications document to address that, but I digress). Tone of the document -------------------------- The useipsec I-D takes the tone of not all required features in the specifications are supported in implementations so new RFC authors might want to take note of that: practical advice, but I think also a slippery slope to normalize implementations that might have been centered around a specific use case -- e.g., VPNs. Other use cases -- some in discussion now and others yet to be conceived -- may require features that are in the specs as RECOMMENDED or even MUST, but are not necessarily available in all implementations. (Please see Section 8, item (h)). The IETF's advice should be along the lines of what's in the specs and not what is widely implemented. If there is consensus that what's implemented is all that is needed and the original specifications are overdone, well we should revise the specs (e.g., we do that, as in case of IKE to IKEv2). New protocols vs. Old protocols -------------------------------------- To come back to the issue of IKE+IPsec vs. IKEv2+IPsecbis: I think the BCP should talk about IKEv2 and IPsecbis and make some passing references to IKE and IPsec in historical notes. I realize IKEv2 and IPsecbis are in infancy w.r.t. implementation and deployment, but we should encourage future specification writers, whether in the IETF or other SDOs, to use IKEv2 and IPsecbis and not the older versions (as I note above, people are already using IKEv2 and IPsecbis, and so the IETF publishing a BCP referring to protocols that are ready to be phased out sends a mixed message). Some specific changes along those lines would be in Sections 6 (e.g., there are new selectors and databases in IPsecbis to consider now) and 8 (No more main and aggressive modes, please :-)). In Section 8, I would delete (h). Section 7, Multicast related text ------------------------------------------ Next, I think Section 7 needs to be updated and references to Transport mode need to be updated with point to multi-point use (perhaps end-to-end is a more generic and all encompassing term to use with transport mode). Section 7 notes that there are no key management protocols for the general case: the MSEC group developed, not one but two (MIKEY, which is referred to, was also an MSEC product, but has nothing to do with IPsec) group key management protocols: GDOI specified in RFC 3547 is quite similar to IKEv1 and is a general purpose group key management protocol; similarly GSAKMP is also a general purpose key management protocol, and is currently in the RFC Editor queue. While I agree that replay protection is important, it is after all OPTIONAL in IPsec specifications and so was not a priority for MSEC. Multi-sender replay protection is indeed a hard problem and someone -- Sandy Harris@Paris -- noted that it has come up in RPSEC recently, and so MSEC agreed to try and look at the problem again. GDOI and GSAKMP work very well with IPsec and other security encapsulation protocols and so the BCP should not be saying that it is inappropriate to use IPsec for multicast traffic. In fact, there is a msec-ipsec-extensions document which is specifying multicast and group security extensions to IPsec. The multicast portions of the current IPsecbis document were written after a good amount of discussion with a team of MSEC contributors. Some nits: Old Authors of RFCs that rely on IPsec must specify the following: New Authors of standards documents that rely on IPsec must specify the following In Section 4 Old RFC2041 New RFC2401 In Section 8 Old RFC2284 New RFC3748 regards, Lakshminath At 05:22 PM 9/19/2005, Steven M. Bellovin wrote: >------- Forwarded Message > > >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Message-Id: >Date: Mon, 19 Sep 2005 10:50:02 -0400 > > >- --NextPart > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Guidelines for Mandating the Use of IPsec > Author(s) : S. Bellovin > Filename : draft-bellovin-useipsec-04.txt > Pages : 13 > Date : 2005-9-19 > >The Security Considerations sections of many Internet Drafts say, in > effect, "just use IPsec". While this is sometimes correct, more > often it will leave users without real, interoperable security > mechanisms. This memo offers some guidance on when IPsec should and > should not be specified. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-04.txt > > > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb > > >_______________________________________________ >saag mailing list >saag@mit.edu >https://jis.mit.edu/mailman/listinfo/saag _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 22 18:15:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZLH-0008DZ-AC for msec-archive@megatron.ietf.org; Thu, 22 Sep 2005 18:15:03 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29514 for ; Thu, 22 Sep 2005 18:14:56 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8F7048C99E; Thu, 22 Sep 2005 18:14:58 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 4E6018C056 for ; Thu, 22 Sep 2005 18:14:57 -0400 (EDT) Received: (qmail 15244 invoked by uid 3269); 22 Sep 2005 22:14:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15241 invoked from network); 22 Sep 2005 22:14:57 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 22 Sep 2005 22:14:57 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 0DA2268352 for ; Thu, 22 Sep 2005 18:14:56 -0400 (EDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MMERoV010023; Thu, 22 Sep 2005 15:14:27 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8MMEP7T012936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Sep 2005 15:14:25 -0700 (PDT) Message-Id: <6.2.2.1.2.20050922150946.0331c9e0@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Thu, 22 Sep 2005 15:14:21 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] draft-bellovin-useipsec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Folks, Please read the following text from http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-04.txt 7. Broadcast and Multicast Although the designers of IPsec tried to leave room for protection of multicast traffic, a complete design wasn't finished until much later. There is, as yet, no key management for the general case, though MIKEY [RFC3830] will work for peer-to-peer, simple one-to- many, and small group multicast. Worse yet, an important component of over-the-wire IPsec -- replay protection -- was designed even later [2401bis,2402bis,ESPv3], and is thus unavailable in deployed multicast implementations. IPsec is thus inappropriate for such protocols unless and until suitable key management and replay protection mechanisms are available in the target domain. This draft is in IETF last call and is to be published as BCP soon. I wrote my review and complained about the inaccuracies above (I have cc'ed MSEC). Please send your notes on that draft to the IESG and the SEC ADs. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Sep 22 18:36:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIZgP-0004LD-UM for msec-archive@megatron.ietf.org; Thu, 22 Sep 2005 18:36:52 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00912 for ; Thu, 22 Sep 2005 18:36:47 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0BF1F8CB47; Thu, 22 Sep 2005 18:36:49 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 251C88CA39 for ; Thu, 22 Sep 2005 18:36:48 -0400 (EDT) Received: (qmail 19642 invoked by uid 3269); 22 Sep 2005 22:36:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19632 invoked from network); 22 Sep 2005 22:36:45 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 22 Sep 2005 22:36:45 -0000 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by klesh.pair.com (Postfix) with ESMTP id CE7BA68352 for ; Thu, 22 Sep 2005 18:36:43 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 22 Sep 2005 15:36:43 -0700 X-IronPort-AV: i="3.97,138,1125903600"; d="scan'208"; a="661514021:sNHT31154636" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8MMaC4v018421; Thu, 22 Sep 2005 15:36:40 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 15:36:40 -0700 Received: from [192.168.0.10] ([10.21.82.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Sep 2005 15:36:11 -0700 In-Reply-To: <6.2.2.1.2.20050922150946.0331c9e0@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050922150946.0331c9e0@qcmail1.qualcomm.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Thu, 22 Sep 2005 15:36:37 -0700 To: smb@cs.columbia.edu, Lakshminath Dondeti X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 22 Sep 2005 22:36:11.0742 (UTC) FILETIME=[0886F7E0:01C5BFC6] Cc: msec@securemulticast.org Subject: [MSEC] Re: draft-bellovin-useipsec X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 7bit Steve, Lakshminath Thanks for pointing this out, Lakshminath. It is not clear to me why Steve does not mention the two group key management RFCs that we have produced in this working group. In particular, the RFC 3547 design is specifically for support of one-to-many IPsec. I don't understand why a peer-to-peer protocol is mentioned but not RFC 3547, which was published during Steve's watch as security AD. Mark On Sep 22, 2005, at 3:14 PM, Lakshminath Dondeti wrote: > Folks, > > Please read the following text from http://www.ietf.org/internet- > drafts/draft-bellovin-useipsec-04.txt > > 7. Broadcast and Multicast > > Although the designers of IPsec tried to leave room for > protection of > multicast traffic, a complete design wasn't finished until much > later. There is, as yet, no key management for the general case, > though MIKEY [RFC3830] will work for peer-to-peer, simple one-to- > many, and small group multicast. Worse yet, an important component > of over-the-wire IPsec -- replay protection -- was designed even > later [2401bis,2402bis,ESPv3], and is thus unavailable in deployed > multicast implementations. IPsec is thus inappropriate for such > protocols unless and until suitable key management and replay > protection mechanisms are available in the target domain. > > This draft is in IETF last call and is to be published as BCP > soon. I wrote my review and complained about the inaccuracies > above (I have cc'ed MSEC). Please send your notes on that draft to > the IESG and the SEC ADs. > > thanks and regards, > Lakshminath > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Sep 30 18:56:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELToB-0002ym-HE for msec-archive@megatron.ietf.org; Fri, 30 Sep 2005 18:56:51 -0400 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24668 for ; Fri, 30 Sep 2005 18:56:48 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 885D28CBEE; Fri, 30 Sep 2005 18:56:50 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 6B4FC8C85D for ; Fri, 30 Sep 2005 18:56:49 -0400 (EDT) Received: (qmail 19721 invoked by uid 3269); 30 Sep 2005 22:56:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19718 invoked from network); 30 Sep 2005 22:56:49 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 30 Sep 2005 22:56:49 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 2570D68359 for ; Fri, 30 Sep 2005 18:56:49 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8UMuioV021069; Fri, 30 Sep 2005 15:56:44 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8UMugkN010538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Sep 2005 15:56:43 -0700 (PDT) Message-Id: <6.2.2.1.2.20050930155104.02dea568@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Fri, 30 Sep 2005 15:56:38 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Fwd: I-D ACTION:draft-ietf-msec-policy-token-sec-04.txt X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, The MSEC policy token spec has been updated. Most of the changes are editorial, but there are a couple of SHOULDs that are MUSTs now, and there is a new field called senderAuthorization (see B.1.1). Please send a message to the mailing list if there are any issues with the changes (note that this I-D has already passed WGLC, and had been waiting for my review which resulted in the changes listed). At the end of Oct 3, 2005, Monday 5PM PT, I plan to forward this draft to Russ. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ thanks and regards, Lakshminath http://tools.ietf.org/wg/msec/draft-ietf-msec-policy-token-sec/draft-ietf-msec-policy-token-sec-04-from-03.diff.html >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 v1 > Author(s) : H. Harney, A. Colegrove > Filename : draft-ietf-msec-policy-token-sec-04.txt > Pages : 36 > Date : 2005-9-30 > >The Group Security Policy Token is a structure used to > specify the security policy and configurable parameters for > a cryptographic group, such as a secure multicast group. > This document specifies the structure of such a token in > order to securely bind system-level security to protocols > supporting the management of cryptographic groups. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-policy-token-sec-04.txt _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec