From msec-bounces@securemulticast.org Mon Aug 01 00:28:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzRv5-0007in-Nq for msec-archive@megatron.ietf.org; Mon, 01 Aug 2005 00:28:56 -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 AAA07856 for ; Mon, 1 Aug 2005 00:28:52 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 73F928C31A; Mon, 1 Aug 2005 00:28:54 -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 189DB8C263 for ; Mon, 1 Aug 2005 00:28:53 -0400 (EDT) Received: (qmail 75148 invoked by uid 3269); 1 Aug 2005 04:28:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75145 invoked from network); 1 Aug 2005 04:28:52 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 1 Aug 2005 04:28:52 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id 2E4E468374 for ; Mon, 1 Aug 2005 00:28:42 -0400 (EDT) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j714UDOf030296 for ; Mon, 1 Aug 2005 00:30:13 -0400 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j714Seb33132 for ; Mon, 1 Aug 2005 00:28:40 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j714Sej33130 for ; Mon, 1 Aug 2005 00:28:40 -0400 Received: from prf.watson.ibm.com ([9.2.16.112]) by mgsmtp00.watson.ibm.com (IMF.2005.07.16.1055.haw) with SMTP ID IMFd1122870489.2049; Mon, 01 Aug 2005 00:28:09 -0400 Received: from localhost (canetti@localhost) by prf.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id j714SYM41542; Mon, 1 Aug 2005 00:28:34 -0400 Date: Mon, 1 Aug 2005 00:28:34 -0400 (EDT) From: canetti To: George Gross Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source authentication in the ALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: msec@securemulticast.org, vincent.roca@inrialpes.fr, "Rmt@ietf. 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 Faurite, Mike, George, and all - A few high-level points regarding the work on standardizing TESLA for RMT's ALC and NORM: First, I agree that this is a very worthwhile endeavor. Regarding how/where it should be done. The approach within MSEC so far wrt the standardization of TESLA was to have: (a) a single informational document that describes the principles and the rationale, but without specifying exact parameters, packet formats, etc. (This is now RFC 4082). (b) a number of standards-track documents that specify how to use TESLA in specific settings. Here we currently have the TESLA-SRTP rfc-to-be (together with the bootstrapping TESLA draft). the plan is to have also a document that describes how to use TESLA within ESP. (This document is long overdue. the dead tesla-spec-00 draft that Faurite mentioned can be regarded as a first draft of this future document.) The rationale behind organizing things this way was that TESLA is a relatively complex and delicate protocol, with several options and modes that make it hard to specify a single closed protocol that is not too complex and yet applies to all scenarios. Furthermore, the experience within MSEC was that it is non-trivial to understand the security of this protocol and to implement it securely. Therefore, a separate informational document seemed in place. Indeed, as Mike pointed out, this approach is different from RMT's bulding-block approach. In particular, it doesnt allow for easy "cut and paste" of a "TESLA block" from one protocol into another. Each protocol should define its own version of TESLA. Still, it seems appropriate given the complexity and rich number of options in TESLA (eg, direct/indirect synchronization, need for chain renewal, method of dealing with dos/packet buffering, etc.) Regarding the present draft. When Faurite asked the RMT and MSEC chairs a few weeks ago whether to standardize the present draft within RMT or within MSEC, my response was that I thought RMT was a more appropriate venue since the main challenge is to make TESLA fit well within the RMT protocol suite, and MSEC had no expertise in that. This approach was accepted by the RMT chairs, under the condition that there will be "security supervision of the draft" by MSEC folks. I still think that this is the best way to do things. In fact, one may regard the present draft as a "TESLA building block" for the purpose of RMT. This would give implementors three alternative ways of using TESLA: either within SRTP, or within ESP, or as part of the RMT suite. I've only read the draft at a high level, without delving into many of the details. Yet all the choices and descriptions that I read in the draft were good. One comment is that I'd refer more closely to RFC 4082, to make it clear in each part how exacly the principles and guidelines of RFC 4082 are implemented. This may give more confidence to readers of this document which are not familiar with 4082 and the security of TESLA. Best, Ran btw, George, there is considerable difference between the key setup stage for TESLA alone (ie, for message authentication alone) and session setup using GSAKMP and other group key agreement protocols. In particular, in the former there is no need to authenticate the receiver, and ther eis no need to setup a group key. On Fri, 29 Jul 2005, George Gross wrote: > Hi, > > =09I've taken a quick look at the NORM/ALC TESLA draft. It makes a > good starting point for how to apply TESLA in combination with the RMT > work. I did not dive into it to get details, but a few high level comment= s > seemed in order: > > 1) I have not identified a compelling architectural reason why NORM/ALC > TESLA needs to be applied in an application specific manner. Instead, thi= s > work is a good candidate for inclusion within a set of one or more > standards track documents that describe how to apply TESLA to existing an= d > emergent MSEC and IPsec standards. In particular, I would suggest taking = a > look at the draft-ietf-msec-ipsec-extensions-00.txt, particularly the > service models discussion in the appendix. > > 2) the bootstrapping phase of the NORM/ALC TESLA bears a strong > resemblance to the Internet layer group key management protocols already > developed in MSEC: GDOI and GSAKMP. For example, the TESLA bootstrap > information could become a sub-payload within the GSAKMP Key DownLoad > payload. By using an existent MSEC GKMP, the group membership and group > speaker authentication and authorization procedures are largely defined > and the TESLA feature becomes an extension of a framework. As an aside, > GSAKMP has a distributed mode of operation that alleviates the scalabilit= y > problem, and it also a uni-directional mode too (e.g. for satellite). > > 3) as part of the same activity, we would need to design a TESLA ESP > trailer authenticator, with NORM or ALC as the payload. > > 4) integration with the MSEC framework has the additional benefit that th= e > unicast NORM repair and congestion notification messages directed at the > group speaker could be both group and source endpoint authenticated, the > source authentication using the RSA signatures scheme now in RFC editor > queue. > > 5) The use of one-way hash chains advocated in the NORM/ALC TESLA draft > may have IPR issues. I'm not a patent attornory, YMMV. > > The NORM/ALC TESLA draft is on the MSEC agenda for Paris, but I won't be > there. So I would hope these discussions could continue on the MSEC list. > > hth, > =09George > > On Thu, 28 Jul 2005, faurite wrote: > > > Mike, thanks a lot for your constructive remarks. > > > > Generally speaking, we do agree with all of them. The choices > > we made have been done with the goal to bootstrap the work (keep > > in mind it's only a -00 version) and to fill in some missing > > aspects in current TESLA documents. > > > > > > Let's go into the details, in particular concerning the > > "split between MSEC and RMT WG". > > > > > > You're right, our I-D could easily be split into several separate > > documents, some of them being specified in the MSEC WG, and the > > ALC/NORM instanciation in the RMT WG. > > This is not the choice we made for the -00 version because we > > wanted to put forward all the points we believe are needed (and > > that are missing in current MSEC TESLA documents). > > > > For instance: > > - boostrap stuff could be moved to a separate "TESLA bootstraping > > for ALC/NORM" document (or merged with the current "TESLA > > bootstraping for SRTP" document if the authors believe it's > > feasible/desireable). > > > > - key chain switching: RFC4082 (TESLA introduction) does not discuss > > this possibility of high practical importance. The same is true > > for the "TESLA for SRTP" I-D. This is an issue in particular (but > > not only) with on-demand ALC sessions of non-predefined duration. > > We tried to fix this, but yes, a better solution would be to > > have this mechanism described in some MSEC TESLA document since > > it could then be used not only for ALC/NORM but also for SRTP... > > > > - time synchronization stuff: RFC4082 and "TESLA for SRTP" > > essentially focuss on direct synchronization, which is > > not necessarily appropriate in case of ALC (scalability/feedback > > problems). So we tried to further clarify how indirect synchronizati= on > > could be done (securely)... > > But yes, here also, a better solution would be to have it described > > in an MSEC TESLA document. > > > > Having it all in the same -00 document was a deliberate choice, but > > this is questionable, sure. A direct consequence is that this single > > I-D could not be submitted to both WGs and we've been adviced to send > > it to RMT and CC it to MSEC. That's why. > > > > BTW, an updated "TESLA spec" along the lines of the (dead) I-D: > > http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-spec-00.txt > > that would incorporate the missing points above is clearly missing. > > Some parts of our I-D is inspired from it, as we explained. > > > > Cheers, > > > > Sebastien/Aurelien/Vincent > > > > > > > > >Comments on TESLA source authentication in the ALC and NORM protocols: > > >draft-faurite-rmt-tesla-for-alc-norm-00.txt > > > > > >First off, I think that this is a very good thing to try and standardi= ze, as > > >TESLA is ideally suited to provide authentication and packet integrity > > >protection to ALC and NORM. Unfortunately, I have a lot of questions= and > > >issues with the draft, and some are basic questions about where this w= ork > > >should be done. > > > > > >What I was expecting is a document that describes how to apply TESLA a= nd > > >related security features that have been developed in MSEC that have b= een > > >developed in the spirit of a building block to ALC and NORM, where all= the > > >security issues have been addressed in the TESLA work and it is simply= cut > > >and paste to put that into the ALC and NORM context. What I see inste= ad is > > >a document that describes a lot of protocol work that has security asp= ects > > >to it that seems more suitable for MSEC. I=92m not sure why this is, = perhaps > > >because the TESLA specification does not lend itself to being used as = a > > >building block directly, and perhaps because some of the other securit= y > > >protocols have not been addressed by MSEC. It would be good though if= the > > >basic security work were done in MSEC, and only applications of that w= ork > > >that have no potential to introduce weaknesses in security were descri= bed in > > >the RMT work that describes how these protocols are applied to ALC and= NORM. > > >I have been informed that this is the approach taken with SRTP, i.e., = the > > >work to apply TESLA to SRTP is being done within MSEC, and not AVT. > > > > > >As an example, Section 2 describes protocols for time synchronization > > >between the sender and receivers. Since the security of TESLA entirel= y > > >relies on time synchronization, the security of this protocol is of cr= ucial > > >importance. Furthermore, it seems that time synchronization would be = a > > >basic primitive of any protocol that uses TESLA. Thus, it seems like = the > > >time synchronization protocols should be work done within the MSEC gro= up > > >that can then be leveraged for application work done in RMT, and it se= ems > > >inappropriate for this work to be done in RMT since the security proto= col > > >experts aren=92t there. > > > > > >Section 3 on setting TESLA parameters seems to be the type of thing th= at one > > >would expect in this draft. However, even in this section, there is v= ery > > >little reference and tie-in with the TESLA RFC, and thus it would be g= ood to > > >tighten this section up and refer to the appropriate sections and > > >definitions used in TESLA in this section and use the protocols that h= ave > > >been standardized in TESLA. A related comment is that it should be s= aid > > >somewhere in this draft incorporates the TESLA RFC and inherits all of= the > > >terminology of the TESLA RFC. > > > > > >The bulk of Section 3 defines the format of bootstrap information sign= ature > > >fields and authentication tags, and many related parameters. It seems= like > > >this format and information should all be defined in the TESLA RFC, or= if > > >not in a related RFC within MSEC. If this is all new to this draft an= d not > > >described in the TESLA RFC then this seems like a lot of new > > >formatting/information to be adding beyond TESLA, and I would feel a l= ot > > >more comfortable if this work were done in MSEC. > > > > > >There are a number of other technical comments that could be made, but= I > > >think the high level issue of how to split the work between MSEC and R= MT > > >should be solved before addressing lower level technical issues. > > > > > >Regards, > > >Michael Luby > > > > > > > > >_______________________________________________ > > >Rmt mailing list > > >Rmt@ietf.org > > >https://www1.ietf.org/mailman/listinfo/rmt > > > > > > > > > > > > > _______________________________________________ > > 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 Mon Aug 01 03:46:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzUzr-0002Tr-JY for msec-archive@megatron.ietf.org; Mon, 01 Aug 2005 03:46: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 DAA02142 for ; Mon, 1 Aug 2005 03:46:01 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 7EE958C2CC; Mon, 1 Aug 2005 03:46:02 -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 DAA198C285 for ; Mon, 1 Aug 2005 03:46:00 -0400 (EDT) Received: (qmail 987 invoked by uid 3269); 1 Aug 2005 07:46:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 984 invoked from network); 1 Aug 2005 07:46:00 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 1 Aug 2005 07:46:00 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 98A7468371 for ; Mon, 1 Aug 2005 03:46:00 -0400 (EDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j717ZZo7025198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Aug 2005 00:35:36 -0700 (PDT) Received: from [10.50.68.20] (qconnect-10-50-68-20.qualcomm.com [10.50.68.20]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j717ZTVG001676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Aug 2005 00:35:31 -0700 (PDT) Message-ID: <42EDD0C0.7030906@qualcomm.com> Date: Mon, 01 Aug 2005 09:35:28 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: H.Cruickshank@surrey.ac.uk, Ran Canetti , vincent.roca@inrialpes.fr Subject: [MSEC] Need presentations by Lunch on Tuesday X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Hi all, MSEC Agenda for IETF-63 is as follows. Please send Ran/I a copy of your presentations ASAP, before lunch on Tuesday at the latest. thanks and regards, Lakshminath * Blue sheets, Agenda Bashing etc., 2 mins * MSEC status report (Ran/Lakshminath) 10 mins Revised milestones Notes on cross-area work and reviews * draft-ietf-msec-bootstrapping-tesla (Steffen) 5 mins * draft-ietf-msec-newtype-keyid (Ran/Lakshminath) 5 mins * draft-ietf-msec-srtp-tesla (Ran/Lakshminath) 5 mins * draft-ietf-msec-ipsec-extensions (Dragan) 10 mins * draft-ietf-msec-mikey-ecc (Andy) 10 mins * draft-ietf-msec-mikey-rsa-r (Dragan) 10 mins * draft-dondeti-msec-inband-key-updates (Lakshminath) 10 mins * draft-faurite-rmt-tesla-for-alc-norm "RMT proposal for 10 mins MSEC review" * draft-cruickshank-ipdvb-sec-00.txt "IPDVB proposal for 10 mins MSEC review" * closing remarks 3 mins 90 mins _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 01 11:05:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzbrV-0007UZ-5J for msec-archive@megatron.ietf.org; Mon, 01 Aug 2005 11:05:56 -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 LAA14753 for ; Mon, 1 Aug 2005 11:05:50 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0B1D78C782; Mon, 1 Aug 2005 11:05:52 -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 4A1018C74C for ; Mon, 1 Aug 2005 11:05:51 -0400 (EDT) Received: (qmail 72598 invoked by uid 3269); 1 Aug 2005 15:05:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72595 invoked from network); 1 Aug 2005 15:05:51 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 1 Aug 2005 15:05:51 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id C8D2D6836F for ; Mon, 1 Aug 2005 11:05:40 -0400 (EDT) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j71F7Cmn012198 for ; Mon, 1 Aug 2005 11:07:12 -0400 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j71F5db43806 for ; Mon, 1 Aug 2005 11:05:39 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j71F5cj42128 for ; Mon, 1 Aug 2005 11:05:38 -0400 Received: from prf.watson.ibm.com ([9.2.16.112]) by mgsmtp00.watson.ibm.com (IMF.2005.07.16.1055.haw) with SMTP ID IMFd1122908704.12899; Mon, 01 Aug 2005 11:05:04 -0400 Received: from localhost (canetti@localhost) by prf.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id j71F5WU38202; Mon, 1 Aug 2005 11:05:32 -0400 Date: Mon, 1 Aug 2005 11:05:31 -0400 (EDT) From: canetti To: Michael Luby Subject: RE: [MSEC] Re: [Rmt] Comments on TESLA source authentication in theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: George Gross , "Rmt@ietf. org" , vincent.roca@inrialpes.fr, 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 On Mon, 1 Aug 2005, Michael Luby wrote: > I'm not understanding something. Why is it appropriate to do TESLA-SRTP = in > MSEC but TESLA-ALC/NORM in RMT? because the feeling was that we do have sufficient expertise on SRTP in MSEC (Mark Baugher is a cocauthor of both SRTP and TESLA-SRTP). Lets indeed discuss this issue at RMT and MSEC this week and see what the feelings are. In any case, this clearly should be a joint venture. > > I'm pretty skeptical of doing this work in RMT, since the expertise is ju= st > not there for security and since this draft adds a lot of stuff that seem= s > pretty generic and should be inherent MSEC work, and since the security > expert and one of the inventors of TESLA has himself described below that > TESLA is a relatively complex and delicate protocol. I guess this skepticism is natural, in the same way that I'm skeptical about developing in MSEC a protocol that would interoperate with other RMT protocol. But see below. > > I would really prefer as much of the basic work to be done in MSEC as > possible (like the initial bootstrapping to let the receivers have an > estimate and delta of the current time at the sender when there are a lot= of > receivers, which seems pretty generic to me, given that I understand MSEC= to > mean Multicast SECurity and multicast generally implies lots of receivers= ), > and it still seems to me too much is being done in this draft and not eno= ugh > of the basic work has been done in MSEC (assuming that the work described= in > the initial draft that seems to be new has not been done in MSEC). Practially all these details (bootstrapping, etc) are essentially a repetition of the description in RFC 4082. It's ok to repeat (since this is going to be standards-track), but as I remarked in the previous mail it should be made explicit that all the details are taken from 4082 (and say explicitly if there is deviation) > > As a side-remark: I'm a bit disappointed with the approach that MSEC seem= s > to be taking on TESLA, only doing work for an "Informational" RFC, > especially for something that involves a relatively complex and delicate > protocol that is non-trivial to understand and implement securely. An > "Informational" RFC is a good starting point, but if it is delicate and e= asy > to get wrong, it seems like there would be some more rock-solid protocol > descriptions in a "Standards" track that are developed as well, at least = for > all the common cases and some of the basic parts of the protocol. Well, careful reading may prevent disappointments... :) The plan is to have not one but (at least) two concrete, standards track documents: TESLA-SRTP is one, and the future TESLA-ESP is another. Ran > > > > -----Original Message----- > > From: rmt-bounces@ietf.org [mailto:rmt-bounces@ietf.org]On Behalf Of > > canetti > > Sent: Sunday, July 31, 2005 9:29 PM > > To: George Gross > > Cc: msec@securemulticast.org; vincent.roca@inrialpes.fr; Rmt@ietf. org > > Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source authentication i= n > > theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt > > > > > > > > Faurite, Mike, George, and all - > > > > A few high-level points regarding the work on standardizing TESLA for > > RMT's ALC and NORM: > > > > First, I agree that this is a very worthwhile endeavor. > > > > Regarding how/where it should be done. The approach within MSEC so far > > wrt the standardization of TESLA was to have: > > (a) a single informational document that describes the principles > > and the rationale, but without specifying exact parameters, packet > > formats, etc. (This is now RFC 4082). > > (b) a number of standards-track documents that specify how to use TESLA= in > > specific settings. Here we currently have the TESLA-SRTP rfc-to-be > > (together with the bootstrapping TESLA draft). the plan is to have also= a > > document that describes how to use TESLA within ESP. (This document is > > long overdue. the dead tesla-spec-00 draft that Faurite mentioned can > > be regarded as a first draft of this future document.) > > > > The rationale behind organizing things this way was that TESLA is a > > relatively complex and delicate protocol, with several options > > and modes that make it hard to specify a single closed protocol that is > > not too complex and yet applies to all scenarios. Furthermore, the > > experience within MSEC was that it is non-trivial to understand the > > security of this protocol and to implement it securely. Therefore, a > > separate informational document seemed in place. > > > > Indeed, as Mike pointed out, this approach is different from RMT's > > bulding-block approach. In particular, it doesnt allow for easy "cut an= d > > paste" of a "TESLA block" from one protocol into another. Each protocol > > should define its own version of TESLA. Still, it seems appropriate giv= en > > the complexity and rich number of options in TESLA (eg, direct/indirect > > synchronization, need for chain renewal, method of dealing with dos/pac= ket > > buffering, etc.) > > > > Regarding the present draft. > > When Faurite asked the RMT and MSEC chairs a few weeks ago whether to > > standardize the present draft within RMT or within MSEC, my response wa= s > > that I thought RMT was a more appropriate venue since the main challeng= e > > is to make TESLA fit well within the RMT protocol suite, and MSEC had n= o > > expertise in that. This approach was accepted by the RMT chairs, under = the > > condition that there will be "security supervision of the draft" by MSE= C > > folks. I still think that this is the best way to do things. In fact, o= ne > > may regard the present draft as a "TESLA building block" for the purpos= e > > of RMT. This would give implementors three alternative ways of using > > TESLA: either within SRTP, or within ESP, or as part of the RMT suite. > > > > I've only read the draft at a high level, without delving into many of = the > > details. Yet all the choices and descriptions that I read in the draft > > were good. One comment is that I'd refer more closely to RFC 4082, to m= ake > > it clear in each part how exacly the principles and guidelines of RFC 4= 082 > > are implemented. This may give more confidence to readers of this docum= ent > > which are not familiar with 4082 and the security of TESLA. > > > > Best, > > > > Ran > > > > > > btw, George, there is considerable difference between the key setup sta= ge > > for TESLA alone (ie, for message authentication alone) and session setu= p > > using GSAKMP and other group key agreement protocols. In particular, in > > the former there is no need to authenticate the receiver, and ther eis = no > > need to setup a group key. > > > > On Fri, 29 Jul 2005, George Gross wrote: > > > > > Hi, > > > > > > =09I've taken a quick look at the NORM/ALC TESLA draft. It makes a > > > good starting point for how to apply TESLA in combination with the RM= T > > > work. I did not dive into it to get details, but a few high > > level comments > > > seemed in order: > > > > > > 1) I have not identified a compelling architectural reason why NORM/A= LC > > > TESLA needs to be applied in an application specific manner. > > Instead, this > > > work is a good candidate for inclusion within a set of one or more > > > standards track documents that describe how to apply TESLA to > > existing and > > > emergent MSEC and IPsec standards. In particular, I would > > suggest taking a > > > look at the draft-ietf-msec-ipsec-extensions-00.txt, particularly the > > > service models discussion in the appendix. > > > > > > 2) the bootstrapping phase of the NORM/ALC TESLA bears a strong > > > resemblance to the Internet layer group key management protocols alre= ady > > > developed in MSEC: GDOI and GSAKMP. For example, the TESLA bootstrap > > > information could become a sub-payload within the GSAKMP Key DownLoad > > > payload. By using an existent MSEC GKMP, the group membership and gro= up > > > speaker authentication and authorization procedures are largely defin= ed > > > and the TESLA feature becomes an extension of a framework. As an asid= e, > > > GSAKMP has a distributed mode of operation that alleviates the > > scalability > > > problem, and it also a uni-directional mode too (e.g. for satellite). > > > > > > 3) as part of the same activity, we would need to design a TESLA ESP > > > trailer authenticator, with NORM or ALC as the payload. > > > > > > 4) integration with the MSEC framework has the additional > > benefit that the > > > unicast NORM repair and congestion notification messages directed at = the > > > group speaker could be both group and source endpoint authenticated, = the > > > source authentication using the RSA signatures scheme now in RFC edit= or > > > queue. > > > > > > 5) The use of one-way hash chains advocated in the NORM/ALC TESLA dra= ft > > > may have IPR issues. I'm not a patent attornory, YMMV. > > > > > > The NORM/ALC TESLA draft is on the MSEC agenda for Paris, but I won't= be > > > there. So I would hope these discussions could continue on the > > MSEC list. > > > > > > hth, > > > =09George > > > > > > On Thu, 28 Jul 2005, faurite wrote: > > > > > > > Mike, thanks a lot for your constructive remarks. > > > > > > > > Generally speaking, we do agree with all of them. The choices > > > > we made have been done with the goal to bootstrap the work (keep > > > > in mind it's only a -00 version) and to fill in some missing > > > > aspects in current TESLA documents. > > > > > > > > > > > > Let's go into the details, in particular concerning the > > > > "split between MSEC and RMT WG". > > > > > > > > > > > > You're right, our I-D could easily be split into several separate > > > > documents, some of them being specified in the MSEC WG, and the > > > > ALC/NORM instanciation in the RMT WG. > > > > This is not the choice we made for the -00 version because we > > > > wanted to put forward all the points we believe are needed (and > > > > that are missing in current MSEC TESLA documents). > > > > > > > > For instance: > > > > - boostrap stuff could be moved to a separate "TESLA bootstraping > > > > for ALC/NORM" document (or merged with the current "TESLA > > > > bootstraping for SRTP" document if the authors believe it's > > > > feasible/desireable). > > > > > > > > - key chain switching: RFC4082 (TESLA introduction) does not discu= ss > > > > this possibility of high practical importance. The same is true > > > > for the "TESLA for SRTP" I-D. This is an issue in particular (bu= t > > > > not only) with on-demand ALC sessions of non-predefined duration= =2E > > > > We tried to fix this, but yes, a better solution would be to > > > > have this mechanism described in some MSEC TESLA document since > > > > it could then be used not only for ALC/NORM but also for SRTP... > > > > > > > > - time synchronization stuff: RFC4082 and "TESLA for SRTP" > > > > essentially focuss on direct synchronization, which is > > > > not necessarily appropriate in case of ALC (scalability/feedback > > > > problems). So we tried to further clarify how indirect > > synchronization > > > > could be done (securely)... > > > > But yes, here also, a better solution would be to have it descri= bed > > > > in an MSEC TESLA document. > > > > > > > > Having it all in the same -00 document was a deliberate choice, but > > > > this is questionable, sure. A direct consequence is that this singl= e > > > > I-D could not be submitted to both WGs and we've been adviced to se= nd > > > > it to RMT and CC it to MSEC. That's why. > > > > > > > > BTW, an updated "TESLA spec" along the lines of the (dead) I-D: > > > > http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-spec-00.= txt > > > > that would incorporate the missing points above is clearly missing. > > > > Some parts of our I-D is inspired from it, as we explained. > > > > > > > > Cheers, > > > > > > > > Sebastien/Aurelien/Vincent > > > > > > > > > > > > > > > > >Comments on TESLA source authentication in the ALC and NORM > > protocols: > > > > >draft-faurite-rmt-tesla-for-alc-norm-00.txt > > > > > > > > > >First off, I think that this is a very good thing to try and > > standardize, as > > > > >TESLA is ideally suited to provide authentication and packet > > integrity > > > > >protection to ALC and NORM. Unfortunately, I have a lot of > > questions and > > > > >issues with the draft, and some are basic questions about > > where this work > > > > >should be done. > > > > > > > > > >What I was expecting is a document that describes how to > > apply TESLA and > > > > >related security features that have been developed in MSEC > > that have been > > > > >developed in the spirit of a building block to ALC and NORM, > > where all the > > > > >security issues have been addressed in the TESLA work and it > > is simply cut > > > > >and paste to put that into the ALC and NORM context. What I > > see instead is > > > > >a document that describes a lot of protocol work that has > > security aspects > > > > >to it that seems more suitable for MSEC. I=92m not sure why > > this is, perhaps > > > > >because the TESLA specification does not lend itself to > > being used as a > > > > >building block directly, and perhaps because some of the > > other security > > > > >protocols have not been addressed by MSEC. It would be good > > though if the > > > > >basic security work were done in MSEC, and only applications > > of that work > > > > >that have no potential to introduce weaknesses in security > > were described in > > > > >the RMT work that describes how these protocols are applied > > to ALC and NORM. > > > > >I have been informed that this is the approach taken with > > SRTP, i.e., the > > > > >work to apply TESLA to SRTP is being done within MSEC, and not AVT= =2E > > > > > > > > > >As an example, Section 2 describes protocols for time synchronizat= ion > > > > >between the sender and receivers. Since the security of > > TESLA entirely > > > > >relies on time synchronization, the security of this > > protocol is of crucial > > > > >importance. Furthermore, it seems that time synchronization > > would be a > > > > >basic primitive of any protocol that uses TESLA. Thus, it > > seems like the > > > > >time synchronization protocols should be work done within > > the MSEC group > > > > >that can then be leveraged for application work done in RMT, > > and it seems > > > > >inappropriate for this work to be done in RMT since the > > security protocol > > > > >experts aren=92t there. > > > > > > > > > >Section 3 on setting TESLA parameters seems to be the type > > of thing that one > > > > >would expect in this draft. However, even in this section, > > there is very > > > > >little reference and tie-in with the TESLA RFC, and thus it > > would be good to > > > > >tighten this section up and refer to the appropriate sections and > > > > >definitions used in TESLA in this section and use the > > protocols that have > > > > >been standardized in TESLA. A related comment is that it > > should be said > > > > >somewhere in this draft incorporates the TESLA RFC and > > inherits all of the > > > > >terminology of the TESLA RFC. > > > > > > > > > >The bulk of Section 3 defines the format of bootstrap > > information signature > > > > >fields and authentication tags, and many related parameters. > > It seems like > > > > >this format and information should all be defined in the > > TESLA RFC, or if > > > > >not in a related RFC within MSEC. If this is all new to > > this draft and not > > > > >described in the TESLA RFC then this seems like a lot of new > > > > >formatting/information to be adding beyond TESLA, and I > > would feel a lot > > > > >more comfortable if this work were done in MSEC. > > > > > > > > > >There are a number of other technical comments that could be > > made, but I > > > > >think the high level issue of how to split the work between > > MSEC and RMT > > > > >should be solved before addressing lower level technical issues. > > > > > > > > > >Regards, > > > > >Michael Luby > > > > > > > > > > > > > > >_______________________________________________ > > > > >Rmt mailing list > > > > >Rmt@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/rmt > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > > > _______________________________________________ > > Rmt mailing list > > Rmt@ietf.org > > https://www1.ietf.org/mailman/listinfo/rmt > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 01 11:39:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzcO7-0005y8-0G for msec-archive@megatron.ietf.org; Mon, 01 Aug 2005 11:39:35 -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 LAA17757 for ; Mon, 1 Aug 2005 11:39:32 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3A9F98C65F; Mon, 1 Aug 2005 11:39:34 -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 40AE68C57A for ; Mon, 1 Aug 2005 11:39:33 -0400 (EDT) Received: (qmail 77211 invoked by uid 3269); 1 Aug 2005 15:39:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 77208 invoked from network); 1 Aug 2005 15:39:33 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 1 Aug 2005 15:39:33 -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 BD50368371 for ; Mon, 1 Aug 2005 11:39:32 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 01 Aug 2005 08:39:32 -0700 X-IronPort-AV: i="3.95,157,1120460400"; d="scan'208"; a="652177166:sNHT40596462" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j71FdVJL028088; Mon, 1 Aug 2005 08:39:31 -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); Mon, 1 Aug 2005 08:39:31 -0700 Received: from [192.168.0.10] ([10.21.121.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 08:39:30 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <13f113bf42cb00fdd2c20aedbe18e424@cisco.com> Content-Transfer-Encoding: quoted-printable From: Mark Baugher Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source authentication in theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt Date: Mon, 1 Aug 2005 08:39:30 -0700 To: canetti X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 01 Aug 2005 15:39:30.0485 (UTC) FILETIME=[3522E650:01C596AF] Cc: msec@securemulticast.org, Michael Luby , George Gross , vincent.roca@inrialpes.fr, "Rmt@ietf. 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 On Aug 1, 2005, at 8:05 AM, canetti wrote: > > > On Mon, 1 Aug 2005, Michael Luby wrote: > >> I'm not understanding something. Why is it appropriate to do =20 >> TESLA-SRTP in >> MSEC but TESLA-ALC/NORM in RMT? > > because the feeling was that we do have sufficient expertise on SRTP = in > MSEC (Mark Baugher is a cocauthor of both SRTP and TESLA-SRTP). So too for Elisabetta Carrara, who kindly agree to help with this work =20= when Ran, uh, recruited me to do TESLA-SRTP. Mark > > Lets indeed discuss this issue at RMT and MSEC this week and see what =20= > the > feelings are. In any case, this clearly should be a joint venture. > >> >> I'm pretty skeptical of doing this work in RMT, since the expertise =20= >> is just >> not there for security and since this draft adds a lot of stuff that =20= >> seems >> pretty generic and should be inherent MSEC work, and since the =20 >> security >> expert and one of the inventors of TESLA has himself described below =20= >> that >> TESLA is a relatively complex and delicate protocol. > > I guess this skepticism is natural, in the same way that I'm skeptical > about developing in MSEC a protocol that would interoperate with other > RMT protocol. But see below. > >> >> I would really prefer as much of the basic work to be done in MSEC as >> possible (like the initial bootstrapping to let the receivers have an >> estimate and delta of the current time at the sender when there are a = =20 >> lot of >> receivers, which seems pretty generic to me, given that I understand =20= >> MSEC to >> mean Multicast SECurity and multicast generally implies lots of =20 >> receivers), >> and it still seems to me too much is being done in this draft and not = =20 >> enough >> of the basic work has been done in MSEC (assuming that the work =20 >> described in >> the initial draft that seems to be new has not been done in MSEC). > > Practially all these details (bootstrapping, etc) are essentially a > repetition of the description in RFC 4082. It's ok to repeat (since =20= > this > is going to be standards-track), but as I remarked in the previous =20 > mail it > should be made explicit that all the details are taken from 4082 (and =20= > say > explicitly if there is deviation) > >> >> As a side-remark: I'm a bit disappointed with the approach that MSEC =20= >> seems >> to be taking on TESLA, only doing work for an "Informational" RFC, >> especially for something that involves a relatively complex and =20 >> delicate >> protocol that is non-trivial to understand and implement securely. = An >> "Informational" RFC is a good starting point, but if it is delicate =20= >> and easy >> to get wrong, it seems like there would be some more rock-solid =20 >> protocol >> descriptions in a "Standards" track that are developed as well, at =20= >> least for >> all the common cases and some of the basic parts of the protocol. > > Well, careful reading may prevent disappointments... :) > > The plan is to have not one but (at least) two concrete, standards =20 > track > documents: TESLA-SRTP is one, and the future TESLA-ESP is another. > > Ran > > >> >> >>> -----Original Message----- >>> From: rmt-bounces@ietf.org [mailto:rmt-bounces@ietf.org]On Behalf Of >>> canetti >>> Sent: Sunday, July 31, 2005 9:29 PM >>> To: George Gross >>> Cc: msec@securemulticast.org; vincent.roca@inrialpes.fr; Rmt@ietf. =20= >>> org >>> Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source =20 >>> authentication in >>> theALC and NORM protocols: =20 >>> draft-faurite-rmt-tesla-for-alc-norm-00.txt >>> >>> >>> >>> Faurite, Mike, George, and all - >>> >>> A few high-level points regarding the work on standardizing TESLA = for >>> RMT's ALC and NORM: >>> >>> First, I agree that this is a very worthwhile endeavor. >>> >>> Regarding how/where it should be done. The approach within MSEC so =20= >>> far >>> wrt the standardization of TESLA was to have: >>> (a) a single informational document that describes the principles >>> and the rationale, but without specifying exact parameters, packet >>> formats, etc. (This is now RFC 4082). >>> (b) a number of standards-track documents that specify how to use =20= >>> TESLA in >>> specific settings. Here we currently have the TESLA-SRTP rfc-to-be >>> (together with the bootstrapping TESLA draft). the plan is to have =20= >>> also a >>> document that describes how to use TESLA within ESP. (This document =20= >>> is >>> long overdue. the dead tesla-spec-00 draft that Faurite mentioned = can >>> be regarded as a first draft of this future document.) >>> >>> The rationale behind organizing things this way was that TESLA is a >>> relatively complex and delicate protocol, with several options >>> and modes that make it hard to specify a single closed protocol that = =20 >>> is >>> not too complex and yet applies to all scenarios. Furthermore, the >>> experience within MSEC was that it is non-trivial to understand the >>> security of this protocol and to implement it securely. Therefore, a >>> separate informational document seemed in place. >>> >>> Indeed, as Mike pointed out, this approach is different from RMT's >>> bulding-block approach. In particular, it doesnt allow for easy "cut = =20 >>> and >>> paste" of a "TESLA block" from one protocol into another. Each =20 >>> protocol >>> should define its own version of TESLA. Still, it seems appropriate =20= >>> given >>> the complexity and rich number of options in TESLA (eg, =20 >>> direct/indirect >>> synchronization, need for chain renewal, method of dealing with =20 >>> dos/packet >>> buffering, etc.) >>> >>> Regarding the present draft. >>> When Faurite asked the RMT and MSEC chairs a few weeks ago whether = to >>> standardize the present draft within RMT or within MSEC, my response = =20 >>> was >>> that I thought RMT was a more appropriate venue since the main =20 >>> challenge >>> is to make TESLA fit well within the RMT protocol suite, and MSEC =20= >>> had no >>> expertise in that. This approach was accepted by the RMT chairs, =20 >>> under the >>> condition that there will be "security supervision of the draft" by =20= >>> MSEC >>> folks. I still think that this is the best way to do things. In =20 >>> fact, one >>> may regard the present draft as a "TESLA building block" for the =20 >>> purpose >>> of RMT. This would give implementors three alternative ways of using >>> TESLA: either within SRTP, or within ESP, or as part of the RMT =20 >>> suite. >>> >>> I've only read the draft at a high level, without delving into many =20= >>> of the >>> details. Yet all the choices and descriptions that I read in the =20 >>> draft >>> were good. One comment is that I'd refer more closely to RFC 4082, =20= >>> to make >>> it clear in each part how exacly the principles and guidelines of =20= >>> RFC 4082 >>> are implemented. This may give more confidence to readers of this =20= >>> document >>> which are not familiar with 4082 and the security of TESLA. >>> >>> Best, >>> >>> Ran >>> >>> >>> btw, George, there is considerable difference between the key setup =20= >>> stage >>> for TESLA alone (ie, for message authentication alone) and session =20= >>> setup >>> using GSAKMP and other group key agreement protocols. In particular, = =20 >>> in >>> the former there is no need to authenticate the receiver, and ther =20= >>> eis no >>> need to setup a group key. >>> >>> On Fri, 29 Jul 2005, George Gross wrote: >>> >>>> Hi, >>>> >>>> I've taken a quick look at the NORM/ALC TESLA draft. It makes a >>>> good starting point for how to apply TESLA in combination with the =20= >>>> RMT >>>> work. I did not dive into it to get details, but a few high >>> level comments >>>> seemed in order: >>>> >>>> 1) I have not identified a compelling architectural reason why =20 >>>> NORM/ALC >>>> TESLA needs to be applied in an application specific manner. >>> Instead, this >>>> work is a good candidate for inclusion within a set of one or more >>>> standards track documents that describe how to apply TESLA to >>> existing and >>>> emergent MSEC and IPsec standards. In particular, I would >>> suggest taking a >>>> look at the draft-ietf-msec-ipsec-extensions-00.txt, particularly =20= >>>> the >>>> service models discussion in the appendix. >>>> >>>> 2) the bootstrapping phase of the NORM/ALC TESLA bears a strong >>>> resemblance to the Internet layer group key management protocols =20= >>>> already >>>> developed in MSEC: GDOI and GSAKMP. For example, the TESLA =20 >>>> bootstrap >>>> information could become a sub-payload within the GSAKMP Key =20 >>>> DownLoad >>>> payload. By using an existent MSEC GKMP, the group membership and =20= >>>> group >>>> speaker authentication and authorization procedures are largely =20 >>>> defined >>>> and the TESLA feature becomes an extension of a framework. As an =20= >>>> aside, >>>> GSAKMP has a distributed mode of operation that alleviates the >>> scalability >>>> problem, and it also a uni-directional mode too (e.g. for =20 >>>> satellite). >>>> >>>> 3) as part of the same activity, we would need to design a TESLA = ESP >>>> trailer authenticator, with NORM or ALC as the payload. >>>> >>>> 4) integration with the MSEC framework has the additional >>> benefit that the >>>> unicast NORM repair and congestion notification messages directed =20= >>>> at the >>>> group speaker could be both group and source endpoint =20 >>>> authenticated, the >>>> source authentication using the RSA signatures scheme now in RFC =20= >>>> editor >>>> queue. >>>> >>>> 5) The use of one-way hash chains advocated in the NORM/ALC TESLA =20= >>>> draft >>>> may have IPR issues. I'm not a patent attornory, YMMV. >>>> >>>> The NORM/ALC TESLA draft is on the MSEC agenda for Paris, but I =20 >>>> won't be >>>> there. So I would hope these discussions could continue on the >>> MSEC list. >>>> >>>> hth, >>>> George >>>> >>>> On Thu, 28 Jul 2005, faurite wrote: >>>> >>>>> Mike, thanks a lot for your constructive remarks. >>>>> >>>>> Generally speaking, we do agree with all of them. The choices >>>>> we made have been done with the goal to bootstrap the work (keep >>>>> in mind it's only a -00 version) and to fill in some missing >>>>> aspects in current TESLA documents. >>>>> >>>>> >>>>> Let's go into the details, in particular concerning the >>>>> "split between MSEC and RMT WG". >>>>> >>>>> >>>>> You're right, our I-D could easily be split into several separate >>>>> documents, some of them being specified in the MSEC WG, and the >>>>> ALC/NORM instanciation in the RMT WG. >>>>> This is not the choice we made for the -00 version because we >>>>> wanted to put forward all the points we believe are needed (and >>>>> that are missing in current MSEC TESLA documents). >>>>> >>>>> For instance: >>>>> - boostrap stuff could be moved to a separate "TESLA bootstraping >>>>> for ALC/NORM" document (or merged with the current "TESLA >>>>> bootstraping for SRTP" document if the authors believe it's >>>>> feasible/desireable). >>>>> >>>>> - key chain switching: RFC4082 (TESLA introduction) does not =20 >>>>> discuss >>>>> this possibility of high practical importance. The same is true >>>>> for the "TESLA for SRTP" I-D. This is an issue in particular =20= >>>>> (but >>>>> not only) with on-demand ALC sessions of non-predefined =20 >>>>> duration. >>>>> We tried to fix this, but yes, a better solution would be to >>>>> have this mechanism described in some MSEC TESLA document since >>>>> it could then be used not only for ALC/NORM but also for = SRTP... >>>>> >>>>> - time synchronization stuff: RFC4082 and "TESLA for SRTP" >>>>> essentially focuss on direct synchronization, which is >>>>> not necessarily appropriate in case of ALC = (scalability/feedback >>>>> problems). So we tried to further clarify how indirect >>> synchronization >>>>> could be done (securely)... >>>>> But yes, here also, a better solution would be to have it =20 >>>>> described >>>>> in an MSEC TESLA document. >>>>> >>>>> Having it all in the same -00 document was a deliberate choice, = but >>>>> this is questionable, sure. A direct consequence is that this =20 >>>>> single >>>>> I-D could not be submitted to both WGs and we've been adviced to =20= >>>>> send >>>>> it to RMT and CC it to MSEC. That's why. >>>>> >>>>> BTW, an updated "TESLA spec" along the lines of the (dead) I-D: >>>>> http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-spec=20 >>>>> -00.txt >>>>> that would incorporate the missing points above is clearly = missing. >>>>> Some parts of our I-D is inspired from it, as we explained. >>>>> >>>>> Cheers, >>>>> >>>>> Sebastien/Aurelien/Vincent >>>>> >>>>> >>>>> >>>>>> Comments on TESLA source authentication in the ALC and NORM >>> protocols: >>>>>> draft-faurite-rmt-tesla-for-alc-norm-00.txt >>>>>> >>>>>> First off, I think that this is a very good thing to try and >>> standardize, as >>>>>> TESLA is ideally suited to provide authentication and packet >>> integrity >>>>>> protection to ALC and NORM. Unfortunately, I have a lot of >>> questions and >>>>>> issues with the draft, and some are basic questions about >>> where this work >>>>>> should be done. >>>>>> >>>>>> What I was expecting is a document that describes how to >>> apply TESLA and >>>>>> related security features that have been developed in MSEC >>> that have been >>>>>> developed in the spirit of a building block to ALC and NORM, >>> where all the >>>>>> security issues have been addressed in the TESLA work and it >>> is simply cut >>>>>> and paste to put that into the ALC and NORM context. What I >>> see instead is >>>>>> a document that describes a lot of protocol work that has >>> security aspects >>>>>> to it that seems more suitable for MSEC. I=92m not sure why >>> this is, perhaps >>>>>> because the TESLA specification does not lend itself to >>> being used as a >>>>>> building block directly, and perhaps because some of the >>> other security >>>>>> protocols have not been addressed by MSEC. It would be good >>> though if the >>>>>> basic security work were done in MSEC, and only applications >>> of that work >>>>>> that have no potential to introduce weaknesses in security >>> were described in >>>>>> the RMT work that describes how these protocols are applied >>> to ALC and NORM. >>>>>> I have been informed that this is the approach taken with >>> SRTP, i.e., the >>>>>> work to apply TESLA to SRTP is being done within MSEC, and not =20= >>>>>> AVT. >>>>>> >>>>>> As an example, Section 2 describes protocols for time =20 >>>>>> synchronization >>>>>> between the sender and receivers. Since the security of >>> TESLA entirely >>>>>> relies on time synchronization, the security of this >>> protocol is of crucial >>>>>> importance. Furthermore, it seems that time synchronization >>> would be a >>>>>> basic primitive of any protocol that uses TESLA. Thus, it >>> seems like the >>>>>> time synchronization protocols should be work done within >>> the MSEC group >>>>>> that can then be leveraged for application work done in RMT, >>> and it seems >>>>>> inappropriate for this work to be done in RMT since the >>> security protocol >>>>>> experts aren=92t there. >>>>>> >>>>>> Section 3 on setting TESLA parameters seems to be the type >>> of thing that one >>>>>> would expect in this draft. However, even in this section, >>> there is very >>>>>> little reference and tie-in with the TESLA RFC, and thus it >>> would be good to >>>>>> tighten this section up and refer to the appropriate sections and >>>>>> definitions used in TESLA in this section and use the >>> protocols that have >>>>>> been standardized in TESLA. A related comment is that it >>> should be said >>>>>> somewhere in this draft incorporates the TESLA RFC and >>> inherits all of the >>>>>> terminology of the TESLA RFC. >>>>>> >>>>>> The bulk of Section 3 defines the format of bootstrap >>> information signature >>>>>> fields and authentication tags, and many related parameters. >>> It seems like >>>>>> this format and information should all be defined in the >>> TESLA RFC, or if >>>>>> not in a related RFC within MSEC. If this is all new to >>> this draft and not >>>>>> described in the TESLA RFC then this seems like a lot of new >>>>>> formatting/information to be adding beyond TESLA, and I >>> would feel a lot >>>>>> more comfortable if this work were done in MSEC. >>>>>> >>>>>> There are a number of other technical comments that could be >>> made, but I >>>>>> think the high level issue of how to split the work between >>> MSEC and RMT >>>>>> should be solved before addressing lower level technical issues. >>>>>> >>>>>> Regards, >>>>>> Michael Luby >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rmt mailing list >>>>>> Rmt@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/rmt >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Rmt mailing list >>> Rmt@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rmt >>> >> >> >> > _______________________________________________ > 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 Aug 01 11:43:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzcRe-0008Lc-6W for msec-archive@megatron.ietf.org; Mon, 01 Aug 2005 11:43:14 -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 LAA18651 for ; Mon, 1 Aug 2005 11:43:11 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4099B8C642; Mon, 1 Aug 2005 11:43:13 -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 E996F8C269 for ; Mon, 1 Aug 2005 11:43:11 -0400 (EDT) Received: (qmail 77708 invoked by uid 3269); 1 Aug 2005 15:43:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 77705 invoked from network); 1 Aug 2005 15:43:11 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 1 Aug 2005 15:43:11 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id 7423368375 for ; Mon, 1 Aug 2005 11:43:11 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j71Fih7e016490 for ; Mon, 1 Aug 2005 11:44:43 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j71Fh9818330 for ; Mon, 1 Aug 2005 11:43:09 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j71Fh8371686 for ; Mon, 1 Aug 2005 11:43:08 -0400 Received: from prf.watson.ibm.com ([9.2.16.112]) by mgsmtp00.watson.ibm.com (IMF.2005.07.16.1055.haw) with SMTP ID IMFd1122910954.13474; Mon, 01 Aug 2005 11:42:34 -0400 Received: from localhost (canetti@localhost) by prf.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id j71Fh6R36338; Mon, 1 Aug 2005 11:43:06 -0400 Date: Mon, 1 Aug 2005 11:43:06 -0400 (EDT) From: canetti To: Mark Baugher Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source authentication in theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt In-Reply-To: <13f113bf42cb00fdd2c20aedbe18e424@cisco.com> Message-ID: References: <13f113bf42cb00fdd2c20aedbe18e424@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=WINDOWS-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: msec@securemulticast.org, Michael Luby , George Gross , vincent.roca@inrialpes.fr, "Rmt@ietf. 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 Indeed. My apologies, Elisabetta. Ran On Mon, 1 Aug 2005, Mark Baugher wrote: > > On Aug 1, 2005, at 8:05 AM, canetti wrote: > > > > > > > On Mon, 1 Aug 2005, Michael Luby wrote: > > > >> I'm not understanding something. Why is it appropriate to do > >> TESLA-SRTP in > >> MSEC but TESLA-ALC/NORM in RMT? > > > > because the feeling was that we do have sufficient expertise on SRTP in > > MSEC (Mark Baugher is a cocauthor of both SRTP and TESLA-SRTP). > > So too for Elisabetta Carrara, who kindly agree to help with this work > when Ran, uh, recruited me to do TESLA-SRTP. > > Mark > > > > Lets indeed discuss this issue at RMT and MSEC this week and see what > > the > > feelings are. In any case, this clearly should be a joint venture. > > > >> > >> I'm pretty skeptical of doing this work in RMT, since the expertise > >> is just > >> not there for security and since this draft adds a lot of stuff that > >> seems > >> pretty generic and should be inherent MSEC work, and since the > >> security > >> expert and one of the inventors of TESLA has himself described below > >> that > >> TESLA is a relatively complex and delicate protocol. > > > > I guess this skepticism is natural, in the same way that I'm skeptical > > about developing in MSEC a protocol that would interoperate with other > > RMT protocol. But see below. > > > >> > >> I would really prefer as much of the basic work to be done in MSEC as > >> possible (like the initial bootstrapping to let the receivers have an > >> estimate and delta of the current time at the sender when there are a > >> lot of > >> receivers, which seems pretty generic to me, given that I understand > >> MSEC to > >> mean Multicast SECurity and multicast generally implies lots of > >> receivers), > >> and it still seems to me too much is being done in this draft and not > >> enough > >> of the basic work has been done in MSEC (assuming that the work > >> described in > >> the initial draft that seems to be new has not been done in MSEC). > > > > Practially all these details (bootstrapping, etc) are essentially a > > repetition of the description in RFC 4082. It's ok to repeat (since > > this > > is going to be standards-track), but as I remarked in the previous > > mail it > > should be made explicit that all the details are taken from 4082 (and > > say > > explicitly if there is deviation) > > > >> > >> As a side-remark: I'm a bit disappointed with the approach that MSEC > >> seems > >> to be taking on TESLA, only doing work for an "Informational" RFC, > >> especially for something that involves a relatively complex and > >> delicate > >> protocol that is non-trivial to understand and implement securely. An > >> "Informational" RFC is a good starting point, but if it is delicate > >> and easy > >> to get wrong, it seems like there would be some more rock-solid > >> protocol > >> descriptions in a "Standards" track that are developed as well, at > >> least for > >> all the common cases and some of the basic parts of the protocol. > > > > Well, careful reading may prevent disappointments... :) > > > > The plan is to have not one but (at least) two concrete, standards > > track > > documents: TESLA-SRTP is one, and the future TESLA-ESP is another. > > > > Ran > > > > > >> > >> > >>> -----Original Message----- > >>> From: rmt-bounces@ietf.org [mailto:rmt-bounces@ietf.org]On Behalf Of > >>> canetti > >>> Sent: Sunday, July 31, 2005 9:29 PM > >>> To: George Gross > >>> Cc: msec@securemulticast.org; vincent.roca@inrialpes.fr; Rmt@ietf. > >>> org > >>> Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source > >>> authentication in > >>> theALC and NORM protocols: > >>> draft-faurite-rmt-tesla-for-alc-norm-00.txt > >>> > >>> > >>> > >>> Faurite, Mike, George, and all - > >>> > >>> A few high-level points regarding the work on standardizing TESLA for > >>> RMT's ALC and NORM: > >>> > >>> First, I agree that this is a very worthwhile endeavor. > >>> > >>> Regarding how/where it should be done. The approach within MSEC so > >>> far > >>> wrt the standardization of TESLA was to have: > >>> (a) a single informational document that describes the principles > >>> and the rationale, but without specifying exact parameters, packet > >>> formats, etc. (This is now RFC 4082). > >>> (b) a number of standards-track documents that specify how to use > >>> TESLA in > >>> specific settings. Here we currently have the TESLA-SRTP rfc-to-be > >>> (together with the bootstrapping TESLA draft). the plan is to have > >>> also a > >>> document that describes how to use TESLA within ESP. (This document > >>> is > >>> long overdue. the dead tesla-spec-00 draft that Faurite mentioned can > >>> be regarded as a first draft of this future document.) > >>> > >>> The rationale behind organizing things this way was that TESLA is a > >>> relatively complex and delicate protocol, with several options > >>> and modes that make it hard to specify a single closed protocol that > >>> is > >>> not too complex and yet applies to all scenarios. Furthermore, the > >>> experience within MSEC was that it is non-trivial to understand the > >>> security of this protocol and to implement it securely. Therefore, a > >>> separate informational document seemed in place. > >>> > >>> Indeed, as Mike pointed out, this approach is different from RMT's > >>> bulding-block approach. In particular, it doesnt allow for easy "cut > >>> and > >>> paste" of a "TESLA block" from one protocol into another. Each > >>> protocol > >>> should define its own version of TESLA. Still, it seems appropriate > >>> given > >>> the complexity and rich number of options in TESLA (eg, > >>> direct/indirect > >>> synchronization, need for chain renewal, method of dealing with > >>> dos/packet > >>> buffering, etc.) > >>> > >>> Regarding the present draft. > >>> When Faurite asked the RMT and MSEC chairs a few weeks ago whether to > >>> standardize the present draft within RMT or within MSEC, my response > >>> was > >>> that I thought RMT was a more appropriate venue since the main > >>> challenge > >>> is to make TESLA fit well within the RMT protocol suite, and MSEC > >>> had no > >>> expertise in that. This approach was accepted by the RMT chairs, > >>> under the > >>> condition that there will be "security supervision of the draft" by > >>> MSEC > >>> folks. I still think that this is the best way to do things. In > >>> fact, one > >>> may regard the present draft as a "TESLA building block" for the > >>> purpose > >>> of RMT. This would give implementors three alternative ways of using > >>> TESLA: either within SRTP, or within ESP, or as part of the RMT > >>> suite. > >>> > >>> I've only read the draft at a high level, without delving into many > >>> of the > >>> details. Yet all the choices and descriptions that I read in the > >>> draft > >>> were good. One comment is that I'd refer more closely to RFC 4082, > >>> to make > >>> it clear in each part how exacly the principles and guidelines of > >>> RFC 4082 > >>> are implemented. This may give more confidence to readers of this > >>> document > >>> which are not familiar with 4082 and the security of TESLA. > >>> > >>> Best, > >>> > >>> Ran > >>> > >>> > >>> btw, George, there is considerable difference between the key setup > >>> stage > >>> for TESLA alone (ie, for message authentication alone) and session > >>> setup > >>> using GSAKMP and other group key agreement protocols. In particular, > >>> in > >>> the former there is no need to authenticate the receiver, and ther > >>> eis no > >>> need to setup a group key. > >>> > >>> On Fri, 29 Jul 2005, George Gross wrote: > >>> > >>>> Hi, > >>>> > >>>> =09I've taken a quick look at the NORM/ALC TESLA draft. It makes a > >>>> good starting point for how to apply TESLA in combination with the > >>>> RMT > >>>> work. I did not dive into it to get details, but a few high > >>> level comments > >>>> seemed in order: > >>>> > >>>> 1) I have not identified a compelling architectural reason why > >>>> NORM/ALC > >>>> TESLA needs to be applied in an application specific manner. > >>> Instead, this > >>>> work is a good candidate for inclusion within a set of one or more > >>>> standards track documents that describe how to apply TESLA to > >>> existing and > >>>> emergent MSEC and IPsec standards. In particular, I would > >>> suggest taking a > >>>> look at the draft-ietf-msec-ipsec-extensions-00.txt, particularly > >>>> the > >>>> service models discussion in the appendix. > >>>> > >>>> 2) the bootstrapping phase of the NORM/ALC TESLA bears a strong > >>>> resemblance to the Internet layer group key management protocols > >>>> already > >>>> developed in MSEC: GDOI and GSAKMP. For example, the TESLA > >>>> bootstrap > >>>> information could become a sub-payload within the GSAKMP Key > >>>> DownLoad > >>>> payload. By using an existent MSEC GKMP, the group membership and > >>>> group > >>>> speaker authentication and authorization procedures are largely > >>>> defined > >>>> and the TESLA feature becomes an extension of a framework. As an > >>>> aside, > >>>> GSAKMP has a distributed mode of operation that alleviates the > >>> scalability > >>>> problem, and it also a uni-directional mode too (e.g. for > >>>> satellite). > >>>> > >>>> 3) as part of the same activity, we would need to design a TESLA ESP > >>>> trailer authenticator, with NORM or ALC as the payload. > >>>> > >>>> 4) integration with the MSEC framework has the additional > >>> benefit that the > >>>> unicast NORM repair and congestion notification messages directed > >>>> at the > >>>> group speaker could be both group and source endpoint > >>>> authenticated, the > >>>> source authentication using the RSA signatures scheme now in RFC > >>>> editor > >>>> queue. > >>>> > >>>> 5) The use of one-way hash chains advocated in the NORM/ALC TESLA > >>>> draft > >>>> may have IPR issues. I'm not a patent attornory, YMMV. > >>>> > >>>> The NORM/ALC TESLA draft is on the MSEC agenda for Paris, but I > >>>> won't be > >>>> there. So I would hope these discussions could continue on the > >>> MSEC list. > >>>> > >>>> hth, > >>>> =09George > >>>> > >>>> On Thu, 28 Jul 2005, faurite wrote: > >>>> > >>>>> Mike, thanks a lot for your constructive remarks. > >>>>> > >>>>> Generally speaking, we do agree with all of them. The choices > >>>>> we made have been done with the goal to bootstrap the work (keep > >>>>> in mind it's only a -00 version) and to fill in some missing > >>>>> aspects in current TESLA documents. > >>>>> > >>>>> > >>>>> Let's go into the details, in particular concerning the > >>>>> "split between MSEC and RMT WG". > >>>>> > >>>>> > >>>>> You're right, our I-D could easily be split into several separate > >>>>> documents, some of them being specified in the MSEC WG, and the > >>>>> ALC/NORM instanciation in the RMT WG. > >>>>> This is not the choice we made for the -00 version because we > >>>>> wanted to put forward all the points we believe are needed (and > >>>>> that are missing in current MSEC TESLA documents). > >>>>> > >>>>> For instance: > >>>>> - boostrap stuff could be moved to a separate "TESLA bootstraping > >>>>> for ALC/NORM" document (or merged with the current "TESLA > >>>>> bootstraping for SRTP" document if the authors believe it's > >>>>> feasible/desireable). > >>>>> > >>>>> - key chain switching: RFC4082 (TESLA introduction) does not > >>>>> discuss > >>>>> this possibility of high practical importance. The same is true > >>>>> for the "TESLA for SRTP" I-D. This is an issue in particular > >>>>> (but > >>>>> not only) with on-demand ALC sessions of non-predefined > >>>>> duration. > >>>>> We tried to fix this, but yes, a better solution would be to > >>>>> have this mechanism described in some MSEC TESLA document since > >>>>> it could then be used not only for ALC/NORM but also for SRTP... > >>>>> > >>>>> - time synchronization stuff: RFC4082 and "TESLA for SRTP" > >>>>> essentially focuss on direct synchronization, which is > >>>>> not necessarily appropriate in case of ALC (scalability/feedback > >>>>> problems). So we tried to further clarify how indirect > >>> synchronization > >>>>> could be done (securely)... > >>>>> But yes, here also, a better solution would be to have it > >>>>> described > >>>>> in an MSEC TESLA document. > >>>>> > >>>>> Having it all in the same -00 document was a deliberate choice, but > >>>>> this is questionable, sure. A direct consequence is that this > >>>>> single > >>>>> I-D could not be submitted to both WGs and we've been adviced to > >>>>> send > >>>>> it to RMT and CC it to MSEC. That's why. > >>>>> > >>>>> BTW, an updated "TESLA spec" along the lines of the (dead) I-D: > >>>>> http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-spec > >>>>> -00.txt > >>>>> that would incorporate the missing points above is clearly missing. > >>>>> Some parts of our I-D is inspired from it, as we explained. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Sebastien/Aurelien/Vincent > >>>>> > >>>>> > >>>>> > >>>>>> Comments on TESLA source authentication in the ALC and NORM > >>> protocols: > >>>>>> draft-faurite-rmt-tesla-for-alc-norm-00.txt > >>>>>> > >>>>>> First off, I think that this is a very good thing to try and > >>> standardize, as > >>>>>> TESLA is ideally suited to provide authentication and packet > >>> integrity > >>>>>> protection to ALC and NORM. Unfortunately, I have a lot of > >>> questions and > >>>>>> issues with the draft, and some are basic questions about > >>> where this work > >>>>>> should be done. > >>>>>> > >>>>>> What I was expecting is a document that describes how to > >>> apply TESLA and > >>>>>> related security features that have been developed in MSEC > >>> that have been > >>>>>> developed in the spirit of a building block to ALC and NORM, > >>> where all the > >>>>>> security issues have been addressed in the TESLA work and it > >>> is simply cut > >>>>>> and paste to put that into the ALC and NORM context. What I > >>> see instead is > >>>>>> a document that describes a lot of protocol work that has > >>> security aspects > >>>>>> to it that seems more suitable for MSEC. I=92m not sure why > >>> this is, perhaps > >>>>>> because the TESLA specification does not lend itself to > >>> being used as a > >>>>>> building block directly, and perhaps because some of the > >>> other security > >>>>>> protocols have not been addressed by MSEC. It would be good > >>> though if the > >>>>>> basic security work were done in MSEC, and only applications > >>> of that work > >>>>>> that have no potential to introduce weaknesses in security > >>> were described in > >>>>>> the RMT work that describes how these protocols are applied > >>> to ALC and NORM. > >>>>>> I have been informed that this is the approach taken with > >>> SRTP, i.e., the > >>>>>> work to apply TESLA to SRTP is being done within MSEC, and not > >>>>>> AVT. > >>>>>> > >>>>>> As an example, Section 2 describes protocols for time > >>>>>> synchronization > >>>>>> between the sender and receivers. Since the security of > >>> TESLA entirely > >>>>>> relies on time synchronization, the security of this > >>> protocol is of crucial > >>>>>> importance. Furthermore, it seems that time synchronization > >>> would be a > >>>>>> basic primitive of any protocol that uses TESLA. Thus, it > >>> seems like the > >>>>>> time synchronization protocols should be work done within > >>> the MSEC group > >>>>>> that can then be leveraged for application work done in RMT, > >>> and it seems > >>>>>> inappropriate for this work to be done in RMT since the > >>> security protocol > >>>>>> experts aren=92t there. > >>>>>> > >>>>>> Section 3 on setting TESLA parameters seems to be the type > >>> of thing that one > >>>>>> would expect in this draft. However, even in this section, > >>> there is very > >>>>>> little reference and tie-in with the TESLA RFC, and thus it > >>> would be good to > >>>>>> tighten this section up and refer to the appropriate sections and > >>>>>> definitions used in TESLA in this section and use the > >>> protocols that have > >>>>>> been standardized in TESLA. A related comment is that it > >>> should be said > >>>>>> somewhere in this draft incorporates the TESLA RFC and > >>> inherits all of the > >>>>>> terminology of the TESLA RFC. > >>>>>> > >>>>>> The bulk of Section 3 defines the format of bootstrap > >>> information signature > >>>>>> fields and authentication tags, and many related parameters. > >>> It seems like > >>>>>> this format and information should all be defined in the > >>> TESLA RFC, or if > >>>>>> not in a related RFC within MSEC. If this is all new to > >>> this draft and not > >>>>>> described in the TESLA RFC then this seems like a lot of new > >>>>>> formatting/information to be adding beyond TESLA, and I > >>> would feel a lot > >>>>>> more comfortable if this work were done in MSEC. > >>>>>> > >>>>>> There are a number of other technical comments that could be > >>> made, but I > >>>>>> think the high level issue of how to split the work between > >>> MSEC and RMT > >>>>>> should be solved before addressing lower level technical issues. > >>>>>> > >>>>>> Regards, > >>>>>> Michael Luby > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Rmt mailing list > >>>>>> Rmt@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/rmt > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Rmt mailing list > >>> Rmt@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/rmt > >>> > >> > >> > >> > > _______________________________________________ > > 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 Aug 01 12:09:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzcqm-0007Zh-Db for msec-archive@megatron.ietf.org; Mon, 01 Aug 2005 12:09: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 MAA20886 for ; Mon, 1 Aug 2005 12:09:08 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id AE7C58C7A1; Mon, 1 Aug 2005 12:09:06 -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 CC7688C646 for ; Mon, 1 Aug 2005 12:09:05 -0400 (EDT) Received: (qmail 81658 invoked by uid 3269); 1 Aug 2005 16:09:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81654 invoked from network); 1 Aug 2005 16:09:05 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 1 Aug 2005 16:09:05 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 74DC86836F for ; Mon, 1 Aug 2005 12:09:05 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j71G91sa016937; Mon, 1 Aug 2005 09:09:02 -0700 (PDT) Received: from [10.50.68.134] (qconnect-10-50-68-134.qualcomm.com [10.50.68.134]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j71G8vNp023688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Aug 2005 09:08:59 -0700 (PDT) Message-ID: <42EE4918.6070401@qualcomm.com> Date: Mon, 01 Aug 2005 18:08:56 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org, Ran Canetti Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] MSEC milestones for review X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Hi all, I apologize for the delay on this, but it took a while for me to get all the responses. And I wanted to make this a 1-shot effort with all the current new work covered in this update of the milestones. Anyway below is a compilation of the milestone updates for your review. You have until the meeting tomorrow :-). best regards, Lakshminath Dec 03 WG Last Call on MSEC Security Requirements draft ** Done (Sep 2003; Published as RFC 3740, in Mar 2004) Dec 03 WG Last Call on MSEC Policy Token ** Done (WGLC July 2005; will forward to AD after the Paris meeting) Dec 03 WG Last Call on GSAKMP ** Done (July 2004) Dec 03 Last Call on GSAKMP-Token (Dead; became MSEC Policy Token) Dec 03 WG Last Call on IP Multicast issues with IPsec (Dead, revived, TBD) Mar 04 WG Last call on TESLA-Intro draft ** Done (Finished in Feb 2004; Published as RFC 4082) Mar 04 WG Last Call on MESP Framework (Data Security Architecture) draft (Dead; absorbed into IPsec ESP) Mar 04 WG Last call on TESLA-Spec draft Delete (For Updated name & timeline: see below) Jul 04 WG re-charter for other work items (or disband) (Rechartered; new milestones will run into early 2006) New charter items: Aug 04 WG Last call on Use of RSA/SHA-1 Signatures within ESP and AH Done (in RFC Ed queue) Mar 05 WG Last Call on Key ID Information Type for the General Extension Payload in MIKEY Done (in IESG review) Mar 05 WG Last Call on The Use of TESLA in SRTP Done (in IESG review) Mar 05 WG Last Call on Bootstrapping TESLA Done (in AD review) Nov 05 WG Last Call on MIKEY-RSA-R Dec 05 WG Last Call on MIKEY-ECC Mar 06 WG Last Call on TESLA-ESP-Spec Apr 06 WG Last Call on Multicast Extensions to IPsec Jun 06 WG Last Call on GKDP _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Aug 01 22:42:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzmjU-0003hW-6B for msec-archive@megatron.ietf.org; Mon, 01 Aug 2005 22:42: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 WAA07212 for ; Mon, 1 Aug 2005 22:42:17 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A02AC8C683; Mon, 1 Aug 2005 22:42:18 -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 1B0F58C653 for ; Mon, 1 Aug 2005 22:42:17 -0400 (EDT) Received: (qmail 75015 invoked by uid 3269); 2 Aug 2005 02:42:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75012 invoked from network); 2 Aug 2005 02:42:16 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 Aug 2005 02:42:16 -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 A20036836F for ; Mon, 1 Aug 2005 22:42:16 -0400 (EDT) Received: (qmail 65242 invoked from network); 2 Aug 2005 02:42:15 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 2 Aug 2005 02:42:15 -0000 Received: (qmail 40873 invoked from network); 1 Aug 2005 22:42:14 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.6) by mail1.oct.nac.net with SMTP; 1 Aug 2005 22:42:14 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j71NNAe05944; Mon, 1 Aug 2005 19:23:10 -0400 Date: Mon, 1 Aug 2005 19:23:10 -0400 (EDT) From: George Gross To: canetti Subject: RE: [MSEC] Re: [Rmt] Comments on TESLA source authentication in theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: George Gross , msec@securemulticast.org, "Rmt@ietf. org" , vincent.roca@inrialpes.fr, Michael Luby 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 Ran, I tend to agree with Michael Luby's assessment, that the nature of the NORM/ALC/TESLA proposal really seems more closely aligned with our MSEC working group charter, and particularly the TESLA/ESP work item. The question becomes: are we interested in standardizing a secure multicast transport layer protocol analogous to TLS in the unicast world? or is the secure multicast protocol stack better served by a TESLA ESP standard for the Internet layer? You also outlined in a prior e-mail some previously unidentified requirements about NORM/ALC TESLA, which merits a follow up observation: > > btw, George, there is considerable difference between the key setup > > stage for TESLA alone (ie, for message authentication alone) and > > > session setup using GSAKMP and other group key agreement protocols. > > In particular, in the former there is no need to authenticate the > > receiver, and there is no need to setup a group key. I am not convinced that the requirements are as simple as your statement above would led us to believe. In effect, you are assuming that all NORM/ALC TESLA groups *must* have a fixed security policy that admits all candidate group members and does not use group traffic encryption (i.e. a no-op GM authorization policy and null encryption). WHile there may exist a subset of NORM applications that fit that low security profile, it is not pausible to say all multicast applications would have such requirements. Even for the narrow case described in the NORM/ALC TESLA draft, in order to validate the Group Speaker's signature on the TESLA bootstrap data, the Group Member needs to have: 1. a validated certificate chain from the Group Speaker to one of the group's trust anchor certificates. 2. for each group, a keyring of one or more trust anchor certificates. 3. a group security policy database indexed by Group Speaker identity, that can discriminate between authorized Group Speakers and bogus impostors. 4. a group security policy database that describes the authorized set of reference timing sources (e.g. timestamp authorities, such that one could audit the Group Speaker's asserted timestamp). 5. some kind of anti-replay mechanism to protect the TESLA bootstrap exchange. The first four items require per group receiver endpoint security policy configuration that best scales for a large group when using a group key management protocol. i.e. like as can be expressed using the GSAKMP policy token or an equivalent mechanism in other MSEC protocols. Given the above, it seems to me that NORM/ALC TESLA already needs many features that come with a full fledged group key management protocol exchange. br, =09George On Mon, 1 Aug 2005, canetti wrote: > > > On Mon, 1 Aug 2005, Michael Luby wrote: > > > I'm not understanding something. Why is it appropriate to do TESLA-SRT= P in > > MSEC but TESLA-ALC/NORM in RMT? > > because the feeling was that we do have sufficient expertise on SRTP in > MSEC (Mark Baugher is a cocauthor of both SRTP and TESLA-SRTP). > > Lets indeed discuss this issue at RMT and MSEC this week and see what the > feelings are. In any case, this clearly should be a joint venture. > > > > > I'm pretty skeptical of doing this work in RMT, since the expertise is = just > > not there for security and since this draft adds a lot of stuff that se= ems > > pretty generic and should be inherent MSEC work, and since the security > > expert and one of the inventors of TESLA has himself described below th= at > > TESLA is a relatively complex and delicate protocol. > > I guess this skepticism is natural, in the same way that I'm skeptical > about developing in MSEC a protocol that would interoperate with other > RMT protocol. But see below. > > > > > I would really prefer as much of the basic work to be done in MSEC as > > possible (like the initial bootstrapping to let the receivers have an > > estimate and delta of the current time at the sender when there are a l= ot of > > receivers, which seems pretty generic to me, given that I understand MS= EC to > > mean Multicast SECurity and multicast generally implies lots of receive= rs), > > and it still seems to me too much is being done in this draft and not e= nough > > of the basic work has been done in MSEC (assuming that the work describ= ed in > > the initial draft that seems to be new has not been done in MSEC). > > Practially all these details (bootstrapping, etc) are essentially a > repetition of the description in RFC 4082. It's ok to repeat (since this > is going to be standards-track), but as I remarked in the previous mail i= t > should be made explicit that all the details are taken from 4082 (and say > explicitly if there is deviation) > > > > > As a side-remark: I'm a bit disappointed with the approach that MSEC se= ems > > to be taking on TESLA, only doing work for an "Informational" RFC, > > especially for something that involves a relatively complex and delicat= e > > protocol that is non-trivial to understand and implement securely. An > > "Informational" RFC is a good starting point, but if it is delicate and= easy > > to get wrong, it seems like there would be some more rock-solid protoco= l > > descriptions in a "Standards" track that are developed as well, at leas= t for > > all the common cases and some of the basic parts of the protocol. > > Well, careful reading may prevent disappointments... :) > > The plan is to have not one but (at least) two concrete, standards track > documents: TESLA-SRTP is one, and the future TESLA-ESP is another. > > Ran > > > > > > > > > -----Original Message----- > > > From: rmt-bounces@ietf.org [mailto:rmt-bounces@ietf.org]On Behalf Of > > > canetti > > > Sent: Sunday, July 31, 2005 9:29 PM > > > To: George Gross > > > Cc: msec@securemulticast.org; vincent.roca@inrialpes.fr; Rmt@ietf. or= g > > > Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source authentication= in > > > theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.tx= t > > > > > > > > > > > > Faurite, Mike, George, and all - > > > > > > A few high-level points regarding the work on standardizing TESLA for > > > RMT's ALC and NORM: > > > > > > First, I agree that this is a very worthwhile endeavor. > > > > > > Regarding how/where it should be done. The approach within MSEC so fa= r > > > wrt the standardization of TESLA was to have: > > > (a) a single informational document that describes the principles > > > and the rationale, but without specifying exact parameters, packet > > > formats, etc. (This is now RFC 4082). > > > (b) a number of standards-track documents that specify how to use TES= LA in > > > specific settings. Here we currently have the TESLA-SRTP rfc-to-be > > > (together with the bootstrapping TESLA draft). the plan is to have al= so a > > > document that describes how to use TESLA within ESP. (This document i= s > > > long overdue. the dead tesla-spec-00 draft that Faurite mentioned can > > > be regarded as a first draft of this future document.) > > > > > > The rationale behind organizing things this way was that TESLA is a > > > relatively complex and delicate protocol, with several options > > > and modes that make it hard to specify a single closed protocol that = is > > > not too complex and yet applies to all scenarios. Furthermore, the > > > experience within MSEC was that it is non-trivial to understand the > > > security of this protocol and to implement it securely. Therefore, a > > > separate informational document seemed in place. > > > > > > Indeed, as Mike pointed out, this approach is different from RMT's > > > bulding-block approach. In particular, it doesnt allow for easy "cut = and > > > paste" of a "TESLA block" from one protocol into another. Each protoc= ol > > > should define its own version of TESLA. Still, it seems appropriate g= iven > > > the complexity and rich number of options in TESLA (eg, direct/indire= ct > > > synchronization, need for chain renewal, method of dealing with dos/p= acket > > > buffering, etc.) > > > > > > Regarding the present draft. > > > When Faurite asked the RMT and MSEC chairs a few weeks ago whether to > > > standardize the present draft within RMT or within MSEC, my response = was > > > that I thought RMT was a more appropriate venue since the main challe= nge > > > is to make TESLA fit well within the RMT protocol suite, and MSEC had= no > > > expertise in that. This approach was accepted by the RMT chairs, unde= r the > > > condition that there will be "security supervision of the draft" by M= SEC > > > folks. I still think that this is the best way to do things. In fact,= one > > > may regard the present draft as a "TESLA building block" for the purp= ose > > > of RMT. This would give implementors three alternative ways of using > > > TESLA: either within SRTP, or within ESP, or as part of the RMT suite= =2E > > > > > > I've only read the draft at a high level, without delving into many o= f the > > > details. Yet all the choices and descriptions that I read in the draf= t > > > were good. One comment is that I'd refer more closely to RFC 4082, to= make > > > it clear in each part how exacly the principles and guidelines of RFC= 4082 > > > are implemented. This may give more confidence to readers of this doc= ument > > > which are not familiar with 4082 and the security of TESLA. > > > > > > Best, > > > > > > Ran > > > > > > > > > btw, George, there is considerable difference between the key setup s= tage > > > for TESLA alone (ie, for message authentication alone) and session se= tup > > > using GSAKMP and other group key agreement protocols. In particular, = in > > > the former there is no need to authenticate the receiver, and ther ei= s no > > > need to setup a group key. > > > > > > On Fri, 29 Jul 2005, George Gross wrote: > > > > > > > Hi, > > > > > > > > =09I've taken a quick look at the NORM/ALC TESLA draft. It makes a > > > > good starting point for how to apply TESLA in combination with the = RMT > > > > work. I did not dive into it to get details, but a few high > > > level comments > > > > seemed in order: > > > > > > > > 1) I have not identified a compelling architectural reason why NORM= /ALC > > > > TESLA needs to be applied in an application specific manner. > > > Instead, this > > > > work is a good candidate for inclusion within a set of one or more > > > > standards track documents that describe how to apply TESLA to > > > existing and > > > > emergent MSEC and IPsec standards. In particular, I would > > > suggest taking a > > > > look at the draft-ietf-msec-ipsec-extensions-00.txt, particularly t= he > > > > service models discussion in the appendix. > > > > > > > > 2) the bootstrapping phase of the NORM/ALC TESLA bears a strong > > > > resemblance to the Internet layer group key management protocols al= ready > > > > developed in MSEC: GDOI and GSAKMP. For example, the TESLA bootstr= ap > > > > information could become a sub-payload within the GSAKMP Key DownLo= ad > > > > payload. By using an existent MSEC GKMP, the group membership and g= roup > > > > speaker authentication and authorization procedures are largely def= ined > > > > and the TESLA feature becomes an extension of a framework. As an as= ide, > > > > GSAKMP has a distributed mode of operation that alleviates the > > > scalability > > > > problem, and it also a uni-directional mode too (e.g. for satellite= ). > > > > > > > > 3) as part of the same activity, we would need to design a TESLA ES= P > > > > trailer authenticator, with NORM or ALC as the payload. > > > > > > > > 4) integration with the MSEC framework has the additional > > > benefit that the > > > > unicast NORM repair and congestion notification messages directed a= t the > > > > group speaker could be both group and source endpoint authenticated= , the > > > > source authentication using the RSA signatures scheme now in RFC ed= itor > > > > queue. > > > > > > > > 5) The use of one-way hash chains advocated in the NORM/ALC TESLA d= raft > > > > may have IPR issues. I'm not a patent attornory, YMMV. > > > > > > > > The NORM/ALC TESLA draft is on the MSEC agenda for Paris, but I won= 't be > > > > there. So I would hope these discussions could continue on the > > > MSEC list. > > > > > > > > hth, > > > > =09George > > > > > > > > On Thu, 28 Jul 2005, faurite wrote: > > > > > > > > > Mike, thanks a lot for your constructive remarks. > > > > > > > > > > Generally speaking, we do agree with all of them. The choices > > > > > we made have been done with the goal to bootstrap the work (keep > > > > > in mind it's only a -00 version) and to fill in some missing > > > > > aspects in current TESLA documents. > > > > > > > > > > > > > > > Let's go into the details, in particular concerning the > > > > > "split between MSEC and RMT WG". > > > > > > > > > > > > > > > You're right, our I-D could easily be split into several separate > > > > > documents, some of them being specified in the MSEC WG, and the > > > > > ALC/NORM instanciation in the RMT WG. > > > > > This is not the choice we made for the -00 version because we > > > > > wanted to put forward all the points we believe are needed (and > > > > > that are missing in current MSEC TESLA documents). > > > > > > > > > > For instance: > > > > > - boostrap stuff could be moved to a separate "TESLA bootstrapin= g > > > > > for ALC/NORM" document (or merged with the current "TESLA > > > > > bootstraping for SRTP" document if the authors believe it's > > > > > feasible/desireable). > > > > > > > > > > - key chain switching: RFC4082 (TESLA introduction) does not dis= cuss > > > > > this possibility of high practical importance. The same is tru= e > > > > > for the "TESLA for SRTP" I-D. This is an issue in particular (= but > > > > > not only) with on-demand ALC sessions of non-predefined durati= on. > > > > > We tried to fix this, but yes, a better solution would be to > > > > > have this mechanism described in some MSEC TESLA document sinc= e > > > > > it could then be used not only for ALC/NORM but also for SRTP.= =2E. > > > > > > > > > > - time synchronization stuff: RFC4082 and "TESLA for SRTP" > > > > > essentially focuss on direct synchronization, which is > > > > > not necessarily appropriate in case of ALC (scalability/feedba= ck > > > > > problems). So we tried to further clarify how indirect > > > synchronization > > > > > could be done (securely)... > > > > > But yes, here also, a better solution would be to have it desc= ribed > > > > > in an MSEC TESLA document. > > > > > > > > > > Having it all in the same -00 document was a deliberate choice, b= ut > > > > > this is questionable, sure. A direct consequence is that this sin= gle > > > > > I-D could not be submitted to both WGs and we've been adviced to = send > > > > > it to RMT and CC it to MSEC. That's why. > > > > > > > > > > BTW, an updated "TESLA spec" along the lines of the (dead) I-D: > > > > > http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-spec-0= 0.txt > > > > > that would incorporate the missing points above is clearly missin= g. > > > > > Some parts of our I-D is inspired from it, as we explained. > > > > > > > > > > Cheers, > > > > > > > > > > Sebastien/Aurelien/Vincent > > > > > > > > > > > > > > > > > > > > >Comments on TESLA source authentication in the ALC and NORM > > > protocols: > > > > > >draft-faurite-rmt-tesla-for-alc-norm-00.txt > > > > > > > > > > > >First off, I think that this is a very good thing to try and > > > standardize, as > > > > > >TESLA is ideally suited to provide authentication and packet > > > integrity > > > > > >protection to ALC and NORM. Unfortunately, I have a lot of > > > questions and > > > > > >issues with the draft, and some are basic questions about > > > where this work > > > > > >should be done. > > > > > > > > > > > >What I was expecting is a document that describes how to > > > apply TESLA and > > > > > >related security features that have been developed in MSEC > > > that have been > > > > > >developed in the spirit of a building block to ALC and NORM, > > > where all the > > > > > >security issues have been addressed in the TESLA work and it > > > is simply cut > > > > > >and paste to put that into the ALC and NORM context. What I > > > see instead is > > > > > >a document that describes a lot of protocol work that has > > > security aspects > > > > > >to it that seems more suitable for MSEC. I=92m not sure why > > > this is, perhaps > > > > > >because the TESLA specification does not lend itself to > > > being used as a > > > > > >building block directly, and perhaps because some of the > > > other security > > > > > >protocols have not been addressed by MSEC. It would be good > > > though if the > > > > > >basic security work were done in MSEC, and only applications > > > of that work > > > > > >that have no potential to introduce weaknesses in security > > > were described in > > > > > >the RMT work that describes how these protocols are applied > > > to ALC and NORM. > > > > > >I have been informed that this is the approach taken with > > > SRTP, i.e., the > > > > > >work to apply TESLA to SRTP is being done within MSEC, and not A= VT. > > > > > > > > > > > >As an example, Section 2 describes protocols for time synchroniz= ation > > > > > >between the sender and receivers. Since the security of > > > TESLA entirely > > > > > >relies on time synchronization, the security of this > > > protocol is of crucial > > > > > >importance. Furthermore, it seems that time synchronization > > > would be a > > > > > >basic primitive of any protocol that uses TESLA. Thus, it > > > seems like the > > > > > >time synchronization protocols should be work done within > > > the MSEC group > > > > > >that can then be leveraged for application work done in RMT, > > > and it seems > > > > > >inappropriate for this work to be done in RMT since the > > > security protocol > > > > > >experts aren=92t there. > > > > > > > > > > > >Section 3 on setting TESLA parameters seems to be the type > > > of thing that one > > > > > >would expect in this draft. However, even in this section, > > > there is very > > > > > >little reference and tie-in with the TESLA RFC, and thus it > > > would be good to > > > > > >tighten this section up and refer to the appropriate sections an= d > > > > > >definitions used in TESLA in this section and use the > > > protocols that have > > > > > >been standardized in TESLA. A related comment is that it > > > should be said > > > > > >somewhere in this draft incorporates the TESLA RFC and > > > inherits all of the > > > > > >terminology of the TESLA RFC. > > > > > > > > > > > >The bulk of Section 3 defines the format of bootstrap > > > information signature > > > > > >fields and authentication tags, and many related parameters. > > > It seems like > > > > > >this format and information should all be defined in the > > > TESLA RFC, or if > > > > > >not in a related RFC within MSEC. If this is all new to > > > this draft and not > > > > > >described in the TESLA RFC then this seems like a lot of new > > > > > >formatting/information to be adding beyond TESLA, and I > > > would feel a lot > > > > > >more comfortable if this work were done in MSEC. > > > > > > > > > > > >There are a number of other technical comments that could be > > > made, but I > > > > > >think the high level issue of how to split the work between > > > MSEC and RMT > > > > > >should be solved before addressing lower level technical issues. > > > > > > > > > > > >Regards, > > > > > >Michael Luby > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >Rmt mailing list > > > > > >Rmt@ietf.org > > > > > >https://www1.ietf.org/mailman/listinfo/rmt > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Rmt mailing list > > > Rmt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rmt > > > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 02 06:00:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztZE-0002Bo-Je for msec-archive@megatron.ietf.org; Tue, 02 Aug 2005 06:00: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 GAA04141 for ; Tue, 2 Aug 2005 06:00:09 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 911668C55C; Tue, 2 Aug 2005 06:00:11 -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 4DA6C8C4DF for ; Tue, 2 Aug 2005 06:00:10 -0400 (EDT) Received: (qmail 64195 invoked by uid 3269); 2 Aug 2005 10:00:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 64192 invoked from network); 2 Aug 2005 10:00:10 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 Aug 2005 10:00:10 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id F0E2A68371 for ; Tue, 2 Aug 2005 06:00:09 -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 j72A06sa003265 for ; Tue, 2 Aug 2005 03:00:07 -0700 (PDT) Received: from [10.50.68.168] (qconnect-10-50-68-168.qualcomm.com [10.50.68.168]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j72A02ic001752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Aug 2005 03:00:04 -0700 (PDT) Message-ID: <42EF4421.2070103@qualcomm.com> Date: Tue, 02 Aug 2005 12:00:01 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Need notetakers X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Hi, We need 2 volunteers to take minutes at this evening's meeting. thanks in advance, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Aug 02 10:09:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxSV-0004uM-EC for msec-archive@megatron.ietf.org; Tue, 02 Aug 2005 10:09:31 -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 KAA21309 for ; Tue, 2 Aug 2005 10:09:28 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3DDC58C3DD; Tue, 2 Aug 2005 10:09:30 -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 1AC018C2C8 for ; Tue, 2 Aug 2005 10:09:29 -0400 (EDT) Received: (qmail 97684 invoked by uid 3269); 2 Aug 2005 14:09:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97681 invoked from network); 2 Aug 2005 14:09:29 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 Aug 2005 14:09:29 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id BDF1868374 for ; Tue, 2 Aug 2005 10:09:28 -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 j72E9Psa021303 for ; Tue, 2 Aug 2005 07:09:26 -0700 (PDT) Received: from [10.50.68.138] (qconnect-10-50-68-138.qualcomm.com [10.50.68.138]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j72E9FVG025511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Aug 2005 07:09:22 -0700 (PDT) Message-ID: <42EF7E88.6080302@qualcomm.com> Date: Tue, 02 Aug 2005 16:09:12 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Presentations on the securemulticast.org site X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Dear MSEC presenters, Many thanks for sending the presentations in a timely manner! The presentations received so far are available at http://securemulticast.org/IETF-63/msec-ietf-63.htm Some of the links are broken, but will be uploaded as they are finalized. For instance, the minutes won't be ready until some time after the meeting. While we are on that topic, I still need 2 volunteers. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 03 05:11:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FI7-0005gK-JJ for msec-archive@megatron.ietf.org; Wed, 03 Aug 2005 05:11: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 FAA26875 for ; Wed, 3 Aug 2005 05:11:56 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D94F98C761; Wed, 3 Aug 2005 05:11: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 ABC7F8C74F for ; Wed, 3 Aug 2005 05:11:56 -0400 (EDT) Received: (qmail 95038 invoked by uid 3269); 3 Aug 2005 09:11:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95035 invoked from network); 3 Aug 2005 09:11:56 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Aug 2005 09:11:56 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 5FC2A68374 for ; Wed, 3 Aug 2005 05:11:56 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j739Bqsa016838; Wed, 3 Aug 2005 02:11:53 -0700 (PDT) Received: from [10.50.68.131] (qconnect-10-50-68-131.qualcomm.com [10.50.68.131]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j739BlNp013919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Aug 2005 02:11:49 -0700 (PDT) Message-ID: <42F08A4E.6090500@qualcomm.com> Date: Wed, 03 Aug 2005 11:11:42 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ran Canetti Subject: [MSEC] Draft MSEC meeting minutes for WG review (Thanks to Steffen) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Hi all, First, many thanks to Steffen for taking detailed minutes. I added some notes that I scribbled down and uploaded the minutes to the web site. Please review and let me know if anything has been incorrectly captured. http://securemulticast.org/IETF-63/IETF63-minutes-draft.htm I plan to submit the minutes on Friday morning. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 03 05:42:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Fln-0000dp-TF for msec-archive@megatron.ietf.org; Wed, 03 Aug 2005 05:42:39 -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 FAA29776 for ; Wed, 3 Aug 2005 05:42:37 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 3BF8A8C31B; Wed, 3 Aug 2005 05:42:39 -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 F1FB88C311 for ; Wed, 3 Aug 2005 05:42:37 -0400 (EDT) Received: (qmail 98586 invoked by uid 3269); 3 Aug 2005 09:42:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98583 invoked from network); 3 Aug 2005 09:42:37 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Aug 2005 09:42:37 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id C009A68375 for ; Wed, 3 Aug 2005 05:42:37 -0400 (EDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j739gYo7026040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Aug 2005 02:42:34 -0700 (PDT) Received: from [10.50.68.249] (qconnect-10-50-68-249.qualcomm.com [10.50.68.249]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j739gTVG022262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Aug 2005 02:42:31 -0700 (PDT) Message-ID: <42F09187.90700@qualcomm.com> Date: Wed, 03 Aug 2005 11:42:31 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org, sfries@web.de Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Posting for Steffen [Fwd: ECC stuff] X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 -------- Original Message -------- Subject: ECC stuff Date: Wed, 03 Aug 2005 11:20:15 +0200 From: Steffen Fries Organization: http://freemail.web.de/ To: ldondeti@qualcomm.com Hi Lakshminath, I checked the ECC draft regarding the DH stuff I sent on the list. You are right, it is mentioned, but from my point of view I would suggest adding the information I sent, as the usage of ECDH with ECDSA is underspecified. The draft elaborates very much on EC-MQV. As this may be patent related stuff it would be fair to discuss a patent free application in a similar extend. Maybe a comparison regarding advantages and disadvantages would be good, to give the reader an impression what he can gain be chosing an option. Ciao Steffen ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Wed Aug 03 07:02:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0H1S-0002vs-67 for msec-archive@megatron.ietf.org; Wed, 03 Aug 2005 07:02:54 -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 HAA05065 for ; Wed, 3 Aug 2005 07:02:51 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id EC7368C362; Wed, 3 Aug 2005 07:02:52 -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 97BBE8C349 for ; Wed, 3 Aug 2005 07:02:51 -0400 (EDT) Received: (qmail 72281 invoked by uid 3269); 3 Aug 2005 11:02:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72278 invoked from network); 3 Aug 2005 11:02:51 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Aug 2005 11:02:51 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 7424768371 for ; Wed, 3 Aug 2005 07:02:51 -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 j73B2msa025229; Wed, 3 Aug 2005 04:02:48 -0700 (PDT) Received: from [10.50.68.106] (qconnect-10-50-68-106.qualcomm.com [10.50.68.106]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j73B2hVG013743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Aug 2005 04:02:45 -0700 (PDT) Message-ID: <42F0A452.8080003@qualcomm.com> Date: Wed, 03 Aug 2005 13:02:42 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ran Canetti Subject: [MSEC] MSEC meeting summary for your review (draft) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Hi all, Here is a quick summary of the WG meeting that I put together for presentation in the SAAG meeting. Please review. We have until tomorrow morning to submit this to the ADs. regards, Lakshminath Two MSEC documents have been published as informational RFCs between Minneapolis and Paris (RFC 4046 and RFC 4082). Three more are in RFC Ed queue (1 added to the queue) Three more are in IESG review (working on revisions from there) In Minneapolis we got an action item from Russ to work on MSEC extensions to IPsec. Brian Weis, George Gross and Dragan Ignjatic wrote a draft. The chair to distribute it to the IPSEC WG list for wider review. That draft and several other MSEC drafts were presented at the meeting. We note that there are several MIKEY related drafts in MSEC now (4 + the RFC), so an action item might be to write an umbrella document to explain how they are related to each other. Or better yet, write a roadmap document for all MSEC documents. This is to be discussed on the list. (Action Item 1) MIKEY-RSA-R draft to be circulated to MMUSIC for their review. (Action Item 2) MSEC WG was asked to review an RMT-TESLA proposal. There was a question as to where that work belongs. The guidance is that it doesn't matter where the document is homed, as long it goes through an RMT and MSEC WGLCs. IPDVB group asked MSEC to review their use of the GSAKMP key management protocol. It appears that that work may have other things to do before tackling this particular issue (details of it are going to be covered by Steve Bellovin). First up is security requirements and MSEC will do a review when asked. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Aug 04 05:10:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0bjv-0001oq-6s for msec-archive@megatron.ietf.org; Thu, 04 Aug 2005 05:10:11 -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 FAA14805 for ; Thu, 4 Aug 2005 05:10:08 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9986B8C5A1; Thu, 4 Aug 2005 05:10:09 -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 240DF8C36B for ; Thu, 4 Aug 2005 05:10:08 -0400 (EDT) Received: (qmail 92670 invoked by uid 3269); 4 Aug 2005 09:10:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 92667 invoked from network); 4 Aug 2005 09:10:08 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 4 Aug 2005 09:10:08 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id D593F6836F for ; Thu, 4 Aug 2005 05:10:07 -0400 (EDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j7499so7015102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Aug 2005 02:09:54 -0700 (PDT) Received: from [10.50.68.206] (qconnect-10-50-68-206.qualcomm.com [10.50.68.206]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j7499nVG013278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Aug 2005 02:09:51 -0700 (PDT) Message-ID: <42F1DB5C.90500@qualcomm.com> Date: Thu, 04 Aug 2005 11:09:48 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hartmans-ietf@mit.edu, Russ Housley Subject: [MSEC] MSEC@IETF-63 meeting summary and draft minutes. X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Draft minutes: http://securemulticast.org/IETF-63/IETF63-minutes-draft.htm Summary: Two MSEC documents have been published as informational RFCs between Minneapolis and Paris (RFC 4046 and RFC 4082). Three more are in RFC Ed queue (1 added to the queue) Three more are in IESG review (working on revisions from there) In Minneapolis we got an action item from Russ to work on MSEC extensions to IPsec. Brian Weis, George Gross and Dragan Ignjatic wrote a draft. The chair will distribute it to the IPSEC WG list for wider review. (Action item 1) That draft and several other MSEC drafts were presented at the meeting. We note that there are several MIKEY related drafts in MSEC now (4 + the RFC), so an action item might be to write an umbrella document to explain how they are related to each other. Or better yet, write a roadmap document for all MSEC documents. This is to be discussed on the list. (Action Item 2) MIKEY-RSA-R draft to be circulated to MMUSIC for their review. (Action Item 3) MSEC milestones have been updated and will be submitted after the meeting. (Action Item 4) MSEC WG was asked to review an RMT-TESLA proposal. There was a question as to where that work belongs. The guidance is that it doesn't matter where the document is homed, as long it goes through an RMT and MSEC WGLCs. IPDVB group asked MSEC to review their use of the GSAKMP key management protocol. It appears that that work may have other things to do before tackling this particular issue (details of it are going to be covered by Steve Bellovin). First up is security requirements and MSEC will do a review when asked. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Aug 05 00:52:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uBh-0001EB-BY for msec-archive@megatron.ietf.org; Fri, 05 Aug 2005 00:52:06 -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 AAA00302 for ; Fri, 5 Aug 2005 00:52:00 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F3EDE8C827; Fri, 5 Aug 2005 00:51:59 -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 895378C758 for ; Fri, 5 Aug 2005 00:51:51 -0400 (EDT) Received: (qmail 86061 invoked by uid 3269); 5 Aug 2005 04:51:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86058 invoked from network); 5 Aug 2005 04:51:51 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Aug 2005 04:51:51 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id DA4846836F for ; Fri, 5 Aug 2005 00:51:40 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j754rDhr023944 for ; Fri, 5 Aug 2005 00:53:13 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j754pd886892 for ; Fri, 5 Aug 2005 00:51:39 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j754pc3108262 for ; Fri, 5 Aug 2005 00:51:38 -0400 Received: from prf.watson.ibm.com ([9.2.16.112]) by mgsmtp00.watson.ibm.com (IMF.2005.07.16.1055.haw) with SMTP ID IMFd1123217440.3632; Fri, 05 Aug 2005 00:50:40 -0400 Received: from localhost (canetti@localhost) by prf.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id j754pS938560; Fri, 5 Aug 2005 00:51:32 -0400 Date: Fri, 5 Aug 2005 00:51:28 -0400 (EDT) From: canetti To: George Gross Subject: RE: [MSEC] Re: [Rmt] Comments on TESLA source authentication in theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: msec@securemulticast.org, "Rmt@ietf. org" , vincent.roca@inrialpes.fr, Michael Luby 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 George, Sorry for the delayed response. Regarding where the NORM/ALS/TESLA draft should be advanced - as you've seen in the minutes, the feeling in both WGs and ofthe ADs was that the draft should be discussed in both WGs, and that the last call should be done in both. Hope that will make both you and Mike happy. Regarding the need for group key establishment protocol (such as GDOI, GSAKMP, MIKEY, etc): All I was saying is that, in the context of RMT, an application might want to use TESLA *even if* it is not interested in encrypting the contents. In such cases there is no need to run a full-fledged key establishment protocol. Thus it makes sense to develop a method for bootstrapping TESLA that does not require such key establishment protocols. (Ofcourse, if the application does wish to use encryption, then it might as well run an MSEC key establishement protocol.) Note that the bootstrapping of TESLA does not require transmitting any secret information between the sender and a receiver. In fact, all the bootstrapping information can in principle be posted on some public website for anyone to download. (the only part that requires interaction is the time synchronization, and even this need not be secret.) Best, Ran Mon, 1 Aug 2005, George Gross wrote: > Hi Ran, > > I tend to agree with Michael Luby's assessment, that the nature of the > NORM/ALC/TESLA proposal really seems more closely aligned with our MSEC > working group charter, and particularly the TESLA/ESP work item. The > question becomes: are we interested in standardizing a secure multicast > transport layer protocol analogous to TLS in the unicast world? or is the > secure multicast protocol stack better served by a TESLA ESP standard for > the Internet layer? > > You also outlined in a prior e-mail some previously unidentified > requirements about NORM/ALC TESLA, which merits a follow up observation: > > > > btw, George, there is considerable difference between the key setup > > > stage for TESLA alone (ie, for message authentication alone) and > > > > session setup using GSAKMP and other group key agreement protocols. > > > In particular, in the former there is no need to authenticate the > > > receiver, and there is no need to setup a group key. > > I am not convinced that the requirements are as simple as your statement > above would led us to believe. In effect, you are assuming that all > NORM/ALC TESLA groups *must* have a fixed security policy that admits all > candidate group members and does not use group traffic encryption (i.e. > a no-op GM authorization policy and null encryption). WHile there may > exist a subset of NORM applications that fit that low security profile, i= t > is not pausible to say all multicast applications would have such > requirements. > > Even for the narrow case described in the NORM/ALC TESLA draft, in order > to validate the Group Speaker's signature on the TESLA bootstrap data, th= e > Group Member needs to have: > > 1. a validated certificate chain from the Group Speaker to one of the > group's trust anchor certificates. > > 2. for each group, a keyring of one or more trust anchor certificates. > > 3. a group security policy database indexed by Group Speaker identity, > that can discriminate between authorized Group Speakers and bogus > impostors. > > 4. a group security policy database that describes the authorized set of > reference timing sources (e.g. timestamp authorities, such that one could > audit the Group Speaker's asserted timestamp). > > 5. some kind of anti-replay mechanism to protect the TESLA bootstrap > exchange. > > The first four items require per group receiver endpoint security policy > configuration that best scales for a large group when using a group key > management protocol. i.e. like as can be expressed using the GSAKMP polic= y > token or an equivalent mechanism in other MSEC protocols. > > Given the above, it seems to me that NORM/ALC TESLA already needs many > features that come with a full fledged group key management protocol > exchange. > > br, > =09George > > > On Mon, 1 Aug 2005, canetti wrote: > > > > > > > On Mon, 1 Aug 2005, Michael Luby wrote: > > > > > I'm not understanding something. Why is it appropriate to do TESLA-S= RTP in > > > MSEC but TESLA-ALC/NORM in RMT? > > > > because the feeling was that we do have sufficient expertise on SRTP in > > MSEC (Mark Baugher is a cocauthor of both SRTP and TESLA-SRTP). > > > > Lets indeed discuss this issue at RMT and MSEC this week and see what t= he > > feelings are. In any case, this clearly should be a joint venture. > > > > > > > > I'm pretty skeptical of doing this work in RMT, since the expertise i= s just > > > not there for security and since this draft adds a lot of stuff that = seems > > > pretty generic and should be inherent MSEC work, and since the securi= ty > > > expert and one of the inventors of TESLA has himself described below = that > > > TESLA is a relatively complex and delicate protocol. > > > > I guess this skepticism is natural, in the same way that I'm skeptical > > about developing in MSEC a protocol that would interoperate with other > > RMT protocol. But see below. > > > > > > > > I would really prefer as much of the basic work to be done in MSEC as > > > possible (like the initial bootstrapping to let the receivers have an > > > estimate and delta of the current time at the sender when there are a= lot of > > > receivers, which seems pretty generic to me, given that I understand = MSEC to > > > mean Multicast SECurity and multicast generally implies lots of recei= vers), > > > and it still seems to me too much is being done in this draft and not= enough > > > of the basic work has been done in MSEC (assuming that the work descr= ibed in > > > the initial draft that seems to be new has not been done in MSEC). > > > > Practially all these details (bootstrapping, etc) are essentially a > > repetition of the description in RFC 4082. It's ok to repeat (since thi= s > > is going to be standards-track), but as I remarked in the previous mail= it > > should be made explicit that all the details are taken from 4082 (and s= ay > > explicitly if there is deviation) > > > > > > > > As a side-remark: I'm a bit disappointed with the approach that MSEC = seems > > > to be taking on TESLA, only doing work for an "Informational" RFC, > > > especially for something that involves a relatively complex and delic= ate > > > protocol that is non-trivial to understand and implement securely. A= n > > > "Informational" RFC is a good starting point, but if it is delicate a= nd easy > > > to get wrong, it seems like there would be some more rock-solid proto= col > > > descriptions in a "Standards" track that are developed as well, at le= ast for > > > all the common cases and some of the basic parts of the protocol. > > > > Well, careful reading may prevent disappointments... :) > > > > The plan is to have not one but (at least) two concrete, standards trac= k > > documents: TESLA-SRTP is one, and the future TESLA-ESP is another. > > > > Ran > > > > > > > > > > > > > > -----Original Message----- > > > > From: rmt-bounces@ietf.org [mailto:rmt-bounces@ietf.org]On Behalf O= f > > > > canetti > > > > Sent: Sunday, July 31, 2005 9:29 PM > > > > To: George Gross > > > > Cc: msec@securemulticast.org; vincent.roca@inrialpes.fr; Rmt@ietf. = org > > > > Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source authenticati= on in > > > > theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.= txt > > > > > > > > > > > > > > > > Faurite, Mike, George, and all - > > > > > > > > A few high-level points regarding the work on standardizing TESLA f= or > > > > RMT's ALC and NORM: > > > > > > > > First, I agree that this is a very worthwhile endeavor. > > > > > > > > Regarding how/where it should be done. The approach within MSEC so = far > > > > wrt the standardization of TESLA was to have: > > > > (a) a single informational document that describes the principles > > > > and the rationale, but without specifying exact parameters, packet > > > > formats, etc. (This is now RFC 4082). > > > > (b) a number of standards-track documents that specify how to use T= ESLA in > > > > specific settings. Here we currently have the TESLA-SRTP rfc-to-be > > > > (together with the bootstrapping TESLA draft). the plan is to have = also a > > > > document that describes how to use TESLA within ESP. (This document= is > > > > long overdue. the dead tesla-spec-00 draft that Faurite mentioned c= an > > > > be regarded as a first draft of this future document.) > > > > > > > > The rationale behind organizing things this way was that TESLA is a > > > > relatively complex and delicate protocol, with several options > > > > and modes that make it hard to specify a single closed protocol tha= t is > > > > not too complex and yet applies to all scenarios. Furthermore, the > > > > experience within MSEC was that it is non-trivial to understand the > > > > security of this protocol and to implement it securely. Therefore, = a > > > > separate informational document seemed in place. > > > > > > > > Indeed, as Mike pointed out, this approach is different from RMT's > > > > bulding-block approach. In particular, it doesnt allow for easy "cu= t and > > > > paste" of a "TESLA block" from one protocol into another. Each prot= ocol > > > > should define its own version of TESLA. Still, it seems appropriate= given > > > > the complexity and rich number of options in TESLA (eg, direct/indi= rect > > > > synchronization, need for chain renewal, method of dealing with dos= /packet > > > > buffering, etc.) > > > > > > > > Regarding the present draft. > > > > When Faurite asked the RMT and MSEC chairs a few weeks ago whether = to > > > > standardize the present draft within RMT or within MSEC, my respons= e was > > > > that I thought RMT was a more appropriate venue since the main chal= lenge > > > > is to make TESLA fit well within the RMT protocol suite, and MSEC h= ad no > > > > expertise in that. This approach was accepted by the RMT chairs, un= der the > > > > condition that there will be "security supervision of the draft" by= MSEC > > > > folks. I still think that this is the best way to do things. In fac= t, one > > > > may regard the present draft as a "TESLA building block" for the pu= rpose > > > > of RMT. This would give implementors three alternative ways of usin= g > > > > TESLA: either within SRTP, or within ESP, or as part of the RMT sui= te. > > > > > > > > I've only read the draft at a high level, without delving into many= of the > > > > details. Yet all the choices and descriptions that I read in the dr= aft > > > > were good. One comment is that I'd refer more closely to RFC 4082, = to make > > > > it clear in each part how exacly the principles and guidelines of R= FC 4082 > > > > are implemented. This may give more confidence to readers of this d= ocument > > > > which are not familiar with 4082 and the security of TESLA. > > > > > > > > Best, > > > > > > > > Ran > > > > > > > > > > > > btw, George, there is considerable difference between the key setup= stage > > > > for TESLA alone (ie, for message authentication alone) and session = setup > > > > using GSAKMP and other group key agreement protocols. In particular= , in > > > > the former there is no need to authenticate the receiver, and ther = eis no > > > > need to setup a group key. > > > > > > > > On Fri, 29 Jul 2005, George Gross wrote: > > > > > > > > > Hi, > > > > > > > > > > =09I've taken a quick look at the NORM/ALC TESLA draft. It makes = a > > > > > good starting point for how to apply TESLA in combination with th= e RMT > > > > > work. I did not dive into it to get details, but a few high > > > > level comments > > > > > seemed in order: > > > > > > > > > > 1) I have not identified a compelling architectural reason why NO= RM/ALC > > > > > TESLA needs to be applied in an application specific manner. > > > > Instead, this > > > > > work is a good candidate for inclusion within a set of one or mor= e > > > > > standards track documents that describe how to apply TESLA to > > > > existing and > > > > > emergent MSEC and IPsec standards. In particular, I would > > > > suggest taking a > > > > > look at the draft-ietf-msec-ipsec-extensions-00.txt, particularly= the > > > > > service models discussion in the appendix. > > > > > > > > > > 2) the bootstrapping phase of the NORM/ALC TESLA bears a strong > > > > > resemblance to the Internet layer group key management protocols = already > > > > > developed in MSEC: GDOI and GSAKMP. For example, the TESLA boots= trap > > > > > information could become a sub-payload within the GSAKMP Key Down= Load > > > > > payload. By using an existent MSEC GKMP, the group membership and= group > > > > > speaker authentication and authorization procedures are largely d= efined > > > > > and the TESLA feature becomes an extension of a framework. As an = aside, > > > > > GSAKMP has a distributed mode of operation that alleviates the > > > > scalability > > > > > problem, and it also a uni-directional mode too (e.g. for satelli= te). > > > > > > > > > > 3) as part of the same activity, we would need to design a TESLA = ESP > > > > > trailer authenticator, with NORM or ALC as the payload. > > > > > > > > > > 4) integration with the MSEC framework has the additional > > > > benefit that the > > > > > unicast NORM repair and congestion notification messages directed= at the > > > > > group speaker could be both group and source endpoint authenticat= ed, the > > > > > source authentication using the RSA signatures scheme now in RFC = editor > > > > > queue. > > > > > > > > > > 5) The use of one-way hash chains advocated in the NORM/ALC TESLA= draft > > > > > may have IPR issues. I'm not a patent attornory, YMMV. > > > > > > > > > > The NORM/ALC TESLA draft is on the MSEC agenda for Paris, but I w= on't be > > > > > there. So I would hope these discussions could continue on the > > > > MSEC list. > > > > > > > > > > hth, > > > > > =09George > > > > > > > > > > On Thu, 28 Jul 2005, faurite wrote: > > > > > > > > > > > Mike, thanks a lot for your constructive remarks. > > > > > > > > > > > > Generally speaking, we do agree with all of them. The choices > > > > > > we made have been done with the goal to bootstrap the work (kee= p > > > > > > in mind it's only a -00 version) and to fill in some missing > > > > > > aspects in current TESLA documents. > > > > > > > > > > > > > > > > > > Let's go into the details, in particular concerning the > > > > > > "split between MSEC and RMT WG". > > > > > > > > > > > > > > > > > > You're right, our I-D could easily be split into several separa= te > > > > > > documents, some of them being specified in the MSEC WG, and the > > > > > > ALC/NORM instanciation in the RMT WG. > > > > > > This is not the choice we made for the -00 version because we > > > > > > wanted to put forward all the points we believe are needed (and > > > > > > that are missing in current MSEC TESLA documents). > > > > > > > > > > > > For instance: > > > > > > - boostrap stuff could be moved to a separate "TESLA bootstrap= ing > > > > > > for ALC/NORM" document (or merged with the current "TESLA > > > > > > bootstraping for SRTP" document if the authors believe it's > > > > > > feasible/desireable). > > > > > > > > > > > > - key chain switching: RFC4082 (TESLA introduction) does not d= iscuss > > > > > > this possibility of high practical importance. The same is t= rue > > > > > > for the "TESLA for SRTP" I-D. This is an issue in particular= (but > > > > > > not only) with on-demand ALC sessions of non-predefined dura= tion. > > > > > > We tried to fix this, but yes, a better solution would be to > > > > > > have this mechanism described in some MSEC TESLA document si= nce > > > > > > it could then be used not only for ALC/NORM but also for SRT= P... > > > > > > > > > > > > - time synchronization stuff: RFC4082 and "TESLA for SRTP" > > > > > > essentially focuss on direct synchronization, which is > > > > > > not necessarily appropriate in case of ALC (scalability/feed= back > > > > > > problems). So we tried to further clarify how indirect > > > > synchronization > > > > > > could be done (securely)... > > > > > > But yes, here also, a better solution would be to have it de= scribed > > > > > > in an MSEC TESLA document. > > > > > > > > > > > > Having it all in the same -00 document was a deliberate choice,= but > > > > > > this is questionable, sure. A direct consequence is that this s= ingle > > > > > > I-D could not be submitted to both WGs and we've been adviced t= o send > > > > > > it to RMT and CC it to MSEC. That's why. > > > > > > > > > > > > BTW, an updated "TESLA spec" along the lines of the (dead) I-D: > > > > > > http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-spec= -00.txt > > > > > > that would incorporate the missing points above is clearly miss= ing. > > > > > > Some parts of our I-D is inspired from it, as we explained. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Sebastien/Aurelien/Vincent > > > > > > > > > > > > > > > > > > > > > > > > >Comments on TESLA source authentication in the ALC and NORM > > > > protocols: > > > > > > >draft-faurite-rmt-tesla-for-alc-norm-00.txt > > > > > > > > > > > > > >First off, I think that this is a very good thing to try and > > > > standardize, as > > > > > > >TESLA is ideally suited to provide authentication and packet > > > > integrity > > > > > > >protection to ALC and NORM. Unfortunately, I have a lot of > > > > questions and > > > > > > >issues with the draft, and some are basic questions about > > > > where this work > > > > > > >should be done. > > > > > > > > > > > > > >What I was expecting is a document that describes how to > > > > apply TESLA and > > > > > > >related security features that have been developed in MSEC > > > > that have been > > > > > > >developed in the spirit of a building block to ALC and NORM, > > > > where all the > > > > > > >security issues have been addressed in the TESLA work and it > > > > is simply cut > > > > > > >and paste to put that into the ALC and NORM context. What I > > > > see instead is > > > > > > >a document that describes a lot of protocol work that has > > > > security aspects > > > > > > >to it that seems more suitable for MSEC. I=92m not sure why > > > > this is, perhaps > > > > > > >because the TESLA specification does not lend itself to > > > > being used as a > > > > > > >building block directly, and perhaps because some of the > > > > other security > > > > > > >protocols have not been addressed by MSEC. It would be good > > > > though if the > > > > > > >basic security work were done in MSEC, and only applications > > > > of that work > > > > > > >that have no potential to introduce weaknesses in security > > > > were described in > > > > > > >the RMT work that describes how these protocols are applied > > > > to ALC and NORM. > > > > > > >I have been informed that this is the approach taken with > > > > SRTP, i.e., the > > > > > > >work to apply TESLA to SRTP is being done within MSEC, and not= AVT. > > > > > > > > > > > > > >As an example, Section 2 describes protocols for time synchron= ization > > > > > > >between the sender and receivers. Since the security of > > > > TESLA entirely > > > > > > >relies on time synchronization, the security of this > > > > protocol is of crucial > > > > > > >importance. Furthermore, it seems that time synchronization > > > > would be a > > > > > > >basic primitive of any protocol that uses TESLA. Thus, it > > > > seems like the > > > > > > >time synchronization protocols should be work done within > > > > the MSEC group > > > > > > >that can then be leveraged for application work done in RMT, > > > > and it seems > > > > > > >inappropriate for this work to be done in RMT since the > > > > security protocol > > > > > > >experts aren=92t there. > > > > > > > > > > > > > >Section 3 on setting TESLA parameters seems to be the type > > > > of thing that one > > > > > > >would expect in this draft. However, even in this section, > > > > there is very > > > > > > >little reference and tie-in with the TESLA RFC, and thus it > > > > would be good to > > > > > > >tighten this section up and refer to the appropriate sections = and > > > > > > >definitions used in TESLA in this section and use the > > > > protocols that have > > > > > > >been standardized in TESLA. A related comment is that it > > > > should be said > > > > > > >somewhere in this draft incorporates the TESLA RFC and > > > > inherits all of the > > > > > > >terminology of the TESLA RFC. > > > > > > > > > > > > > >The bulk of Section 3 defines the format of bootstrap > > > > information signature > > > > > > >fields and authentication tags, and many related parameters. > > > > It seems like > > > > > > >this format and information should all be defined in the > > > > TESLA RFC, or if > > > > > > >not in a related RFC within MSEC. If this is all new to > > > > this draft and not > > > > > > >described in the TESLA RFC then this seems like a lot of new > > > > > > >formatting/information to be adding beyond TESLA, and I > > > > would feel a lot > > > > > > >more comfortable if this work were done in MSEC. > > > > > > > > > > > > > >There are a number of other technical comments that could be > > > > made, but I > > > > > > >think the high level issue of how to split the work between > > > > MSEC and RMT > > > > > > >should be solved before addressing lower level technical issue= s. > > > > > > > > > > > > > >Regards, > > > > > > >Michael Luby > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > >Rmt mailing list > > > > > > >Rmt@ietf.org > > > > > > >https://www1.ietf.org/mailman/listinfo/rmt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rmt mailing list > > > > Rmt@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rmt > > > > > > > > > > > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Aug 05 04:05:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xDL-0003iM-5E for msec-archive@megatron.ietf.org; Fri, 05 Aug 2005 04:05: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 EAA23835 for ; Fri, 5 Aug 2005 04:05:56 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E22FA8C7FF; Fri, 5 Aug 2005 04:05:51 -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 D345C8C3FA for ; Fri, 5 Aug 2005 04:04:54 -0400 (EDT) Received: (qmail 7021 invoked by uid 3269); 5 Aug 2005 08:04:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7018 invoked from network); 5 Aug 2005 08:04:54 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Aug 2005 08:04:54 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id B9B246836F for ; Fri, 5 Aug 2005 04:04:53 -0400 (EDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j7584oo7003009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Aug 2005 01:04:50 -0700 (PDT) Received: from [10.50.68.51] (qconnect-10-50-68-51.qualcomm.com [10.50.68.51]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j7584jVG008260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Aug 2005 01:04:47 -0700 (PDT) Message-ID: <42F31DA0.5070403@qualcomm.com> Date: Fri, 05 Aug 2005 10:04:48 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ran Canetti Subject: [MSEC] Action items from IETF-53 X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Hi all, We have several action items from the IETF-53 meeting. In the next few days (perhaps next week), I will try and post them for discussion. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Aug 05 04:16:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xNt-0006lf-B0 for msec-archive@megatron.ietf.org; Fri, 05 Aug 2005 04:16:53 -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 EAA24848 for ; Fri, 5 Aug 2005 04:16:51 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 30CD18C7FF; Fri, 5 Aug 2005 04:16:16 -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 12AC78C81E for ; Fri, 5 Aug 2005 04:13:09 -0400 (EDT) Received: (qmail 8571 invoked by uid 3269); 5 Aug 2005 08:12:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8568 invoked from network); 5 Aug 2005 08:12:57 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Aug 2005 08:12:57 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id A1F9C68371 for ; Fri, 5 Aug 2005 04:12:57 -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 j758Cssa020219; Fri, 5 Aug 2005 01:12:54 -0700 (PDT) Received: from [10.50.68.51] (qconnect-10-50-68-51.qualcomm.com [10.50.68.51]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j758CnVG010053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Aug 2005 01:12:51 -0700 (PDT) Message-ID: <42F31F86.1010206@qualcomm.com> Date: Fri, 05 Aug 2005 10:12:54 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ran Canetti Subject: [MSEC] MSEC documents roadmap vs. Umbrella document on MIKEY protocols X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 What: One of the topics for discussion is whether we want to write an MSEC documents roadmap or an umbrella document on MIKEY protocols (other ideas are welcome too). Why: At various times in the life of MSEC, people have asked for an MSEC documents roadmap. The number of MIKEY documents has also been increasing and it is always not clear to everyone what fits with what and so forth. How: I think a new RFC is the right way. There is a discussion in the newtrk working group on these things also. I don't think we should wait for what comes out of that group (that could take a long time), but we can steal ideas :-). Opinions and thoughts are very welcome. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Aug 05 04:15:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xMP-0006OD-BX for msec-archive@megatron.ietf.org; Fri, 05 Aug 2005 04:15:21 -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 EAA24736 for ; Fri, 5 Aug 2005 04:15:19 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 230C08C5B3; Fri, 5 Aug 2005 04:15: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 994528C496 for ; Fri, 5 Aug 2005 04:09:30 -0400 (EDT) Received: (qmail 7679 invoked by uid 3269); 5 Aug 2005 08:09:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7676 invoked from network); 5 Aug 2005 08:09:27 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Aug 2005 08:09:27 -0000 Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by klesh.pair.com (Postfix) with ESMTP id 66D796836F for ; Fri, 5 Aug 2005 04:09:27 -0400 (EDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j75899A18672; Fri, 5 Aug 2005 04:09:09 -0400 (EDT) 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 Subject: RE: [MSEC] Action items from IETF-53 Date: Fri, 5 Aug 2005 03:09:06 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF03A34E56@zrc2hxm0.corp.nortel.com> Thread-Topic: [MSEC] Action items from IETF-53 Thread-Index: AcWZlIjBZF9m0Zn8QYOqh5eHDpSh5gAAAodA From: "Francois Audet" To: , Cc: Ran Canetti 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 I suspect you mean IETF 63, not 53. Time flies... > -----Original Message----- > From: msec-bounces@securemulticast.org=20 > [mailto:msec-bounces@securemulticast.org] On Behalf Of=20 > Lakshminath Dondeti > Sent: Friday, August 05, 2005 01:05 > To: msec@securemulticast.org > Cc: Ran Canetti > Subject: [MSEC] Action items from IETF-53 >=20 >=20 > Hi all, >=20 > We have several action items from the IETF-53 meeting. In=20 > the next few=20 > days (perhaps next week), I will try and post them for discussion.=20 >=20 > regards, > Lakshminath > _______________________________________________ > msec mailing list > msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec >=20 >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Aug 05 04:20:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xR6-0008Cg-7X for msec-archive@megatron.ietf.org; Fri, 05 Aug 2005 04:20: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 EAA25014 for ; Fri, 5 Aug 2005 04:20:09 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F08FC8C822; Fri, 5 Aug 2005 04:20:06 -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 C7BF28C843 for ; Fri, 5 Aug 2005 04:16:51 -0400 (EDT) Received: (qmail 9271 invoked by uid 3269); 5 Aug 2005 08:16:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9268 invoked from network); 5 Aug 2005 08:16:24 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Aug 2005 08:16:24 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 9F5A56836F for ; Fri, 5 Aug 2005 04:16:24 -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 j758GLsa020472; Fri, 5 Aug 2005 01:16:21 -0700 (PDT) Received: from [10.50.68.51] (qconnect-10-50-68-51.qualcomm.com [10.50.68.51]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j758GGuZ016588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Aug 2005 01:16:18 -0700 (PDT) Message-ID: <42F32055.1050003@qualcomm.com> Date: Fri, 05 Aug 2005 10:16:21 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org References: <42F31DA0.5070403@qualcomm.com> In-Reply-To: <42F31DA0.5070403@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ran Canetti Subject: [MSEC] Action items from IETF-63 X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Hi all, We have several action items from the IETF-63 meeting. In the next few days (perhaps next week), I will try and post them for discussion. regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Aug 05 04:20:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0xRH-0008D5-5c for msec-archive@megatron.ietf.org; Fri, 05 Aug 2005 04:20:23 -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 EAA25032 for ; Fri, 5 Aug 2005 04:20:20 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 61C768C6DF; Fri, 5 Aug 2005 04:20:16 -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 C31B28C7E7 for ; Fri, 5 Aug 2005 04:15:55 -0400 (EDT) Received: (qmail 9150 invoked by uid 3269); 5 Aug 2005 08:15:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9144 invoked from network); 5 Aug 2005 08:15:39 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Aug 2005 08:15:39 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id EAF866836F for ; Fri, 5 Aug 2005 04:15:38 -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 j758FUo7003651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Aug 2005 01:15:31 -0700 (PDT) Received: from [10.50.68.51] (qconnect-10-50-68-51.qualcomm.com [10.50.68.51]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j758FPic005041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Aug 2005 01:15:27 -0700 (PDT) Message-ID: <42F32021.6050106@qualcomm.com> Date: Fri, 05 Aug 2005 10:15:29 +0200 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Action items from IETF-63 (Re: [MSEC] Action items from IETF-53) References: <1ECE0EB50388174790F9694F77522CCF03A34E56@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF03A34E56@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ran Canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Thanks Francois. I didn't realize it, but I guess it has been a long week already :-). best, Lakshminath Francois Audet wrote: >I suspect you mean IETF 63, not 53. > >Time flies... > > > >>-----Original Message----- >>From: msec-bounces@securemulticast.org >>[mailto:msec-bounces@securemulticast.org] On Behalf Of >>Lakshminath Dondeti >>Sent: Friday, August 05, 2005 01:05 >>To: msec@securemulticast.org >>Cc: Ran Canetti >>Subject: [MSEC] Action items from IETF-53 >> >> >>Hi all, >> >>We have several action items from the IETF-53 meeting. In >>the next few >>days (perhaps next week), I will try and post them for discussion. >> >>regards, >>Lakshminath >>_______________________________________________ >>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 Aug 05 06:06:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0z6D-0002fd-VQ for msec-archive@megatron.ietf.org; Fri, 05 Aug 2005 06:06:46 -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 GAA00278 for ; Fri, 5 Aug 2005 06:06:40 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D35288C859; Fri, 5 Aug 2005 06:06:39 -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 BAD538C53C for ; Fri, 5 Aug 2005 06:06:32 -0400 (EDT) Received: (qmail 26045 invoked by uid 3269); 5 Aug 2005 10:06:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26042 invoked from network); 5 Aug 2005 10:06:31 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Aug 2005 10:06:31 -0000 Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by klesh.pair.com (Postfix) with ESMTP id 4DA0A6836F for ; Fri, 5 Aug 2005 06:06:31 -0400 (EDT) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j75AGCPo013885 for ; Fri, 5 Aug 2005 03:16:12 -0700 (MST) Received: from zfr27exm01.corp.mot.com (zfr27exm01.corp.mot.com [10.161.200.203]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j75ABobi025274 for ; Fri, 5 Aug 2005 05:11:51 -0500 (CDT) Received: from [10.161.201.67] (zfr01-2067.crm.mot.com [10.161.201.67]) by zfr27exm01.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id NV3HVDK1; Fri, 5 Aug 2005 12:06:24 +0200 Message-ID: <42F33A1F.2000308@motorola.com> Date: Fri, 05 Aug 2005 12:06:23 +0200 From: Mounir Kellil User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ldondeti@qualcomm.com Subject: Re: [MSEC] MSEC documents roadmap vs. Umbrella document on MIKEY protocols References: <42F31F86.1010206@qualcomm.com> In-Reply-To: <42F31F86.1010206@qualcomm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Cc: Ran Canetti , 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 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA00278 Hi Lakshminath, Regarding the expected "MSEC documents roadmap", couldn=92t be some=20 overlapping with the RFC 3740, bearing in mind that all MSEC documents=20 (cuurent drafts and RFCs) are within the scope of that RFC? Regards Mounir Lakshminath Dondeti wrote: > What: One of the topics for discussion is whether we want to write an=20 > MSEC documents roadmap or an umbrella document on MIKEY protocols=20 > (other ideas are welcome too). > > Why: At various times in the life of MSEC, people have asked for an=20 > MSEC documents roadmap. The number of MIKEY documents has also been=20 > increasing and it is always not clear to everyone what fits with what=20 > and so forth. > > How: I think a new RFC is the right way. There is a discussion in the=20 > newtrk working group on these things also. I don't think we should=20 > wait for what comes out of that group (that could take a long time),=20 > but we can steal ideas :-). > > Opinions and thoughts are very welcome. > > thanks and regards, > Lakshminath > _______________________________________________ > 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 Sun Aug 07 15:21:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1qhq-0004Uu-Dh for msec-archive@megatron.ietf.org; Sun, 07 Aug 2005 15:21:10 -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 PAA22810 for ; Sun, 7 Aug 2005 15:21:08 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 225328C96B; Sun, 7 Aug 2005 15:21:09 -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 6DD0E8C64C for ; Sun, 7 Aug 2005 15:21:07 -0400 (EDT) Received: (qmail 94500 invoked by uid 3269); 7 Aug 2005 19:21:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94497 invoked from network); 7 Aug 2005 19:21:07 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 7 Aug 2005 19:21:07 -0000 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by klesh.pair.com (Postfix) with ESMTP id 2F5826836F for ; Sun, 7 Aug 2005 15:21:07 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Aug 2005 12:21:06 -0700 X-IronPort-AV: i="3.95,173,1120460400"; d="scan'208"; a="329936496:sNHT30268588" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j77JKwQM021571; Sun, 7 Aug 2005 12:20:58 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 7 Aug 2005 12:21:03 -0700 Received: from [192.168.0.11] ([10.21.83.40]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 7 Aug 2005 12:20:58 -0700 In-Reply-To: <42F31F86.1010206@qualcomm.com> References: <42F31F86.1010206@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <44767f99ece1e11b81c6fe8f2e0cb387@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] MSEC documents roadmap vs. Umbrella document on MIKEY protocols Date: Sun, 7 Aug 2005 12:21:06 -0700 To: ldondeti@qualcomm.com X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 07 Aug 2005 19:20:58.0802 (UTC) FILETIME=[2411A920:01C59B85] Cc: Ran Canetti , 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 MIKEY is an active development area. draft-ietf-mmusic-sdescriptions is also becoming a target for new features, but this is in mmusic. What I am thinking for sdescriptions might apply to MIKEY: Post and eventually publish new features as Proposed Standard RFCs and pick up the successful ones when the base protocol goes to Draft Standard. I believe this is in line with IETF process. Mark p.s. MIKEY and the kmgmt I-D perform a similar function to sdescriptions, which treats key management as a set of additional SDP signaling parameters. On Aug 5, 2005, at 1:12 AM, Lakshminath Dondeti wrote: > What: One of the topics for discussion is whether we want to write an > MSEC documents roadmap or an umbrella document on MIKEY protocols > (other ideas are welcome too). > > Why: At various times in the life of MSEC, people have asked for an > MSEC documents roadmap. The number of MIKEY documents has also been > increasing and it is always not clear to everyone what fits with what > and so forth. > > How: I think a new RFC is the right way. There is a discussion in > the newtrk working group on these things also. I don't think we > should wait for what comes out of that group (that could take a long > time), but we can steal ideas :-). > > Opinions and thoughts are very welcome. > > thanks and regards, > Lakshminath > _______________________________________________ > 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 Aug 08 18:11:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FqN-0007Ea-Uz for msec-archive@megatron.ietf.org; Mon, 08 Aug 2005 18:11:40 -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 SAA28220 for ; Mon, 8 Aug 2005 18:11:36 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C6C508C739; Mon, 8 Aug 2005 18:11: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 82C1E8C692 for ; Mon, 8 Aug 2005 18:11:37 -0400 (EDT) Received: (qmail 94617 invoked by uid 3269); 8 Aug 2005 22:11:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 94614 invoked from network); 8 Aug 2005 22:11:37 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Aug 2005 22:11:37 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 005646836F for ; Mon, 8 Aug 2005 18:11:36 -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 j78MBVo7024657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Aug 2005 15:11:32 -0700 (PDT) Received: from [10.50.64.244] (qconnect-10-50-64-244.qualcomm.com [10.50.64.244]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j78MBDNp015498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Aug 2005 15:11:29 -0700 (PDT) Message-ID: <42F7D882.5090101@qualcomm.com> Date: Mon, 08 Aug 2005 15:11:14 -0700 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MSEC] MSEC documents roadmap vs. Umbrella document on MIKEY protocols References: <42F31F86.1010206@qualcomm.com> <44767f99ece1e11b81c6fe8f2e0cb387@cisco.com> In-Reply-To: <44767f99ece1e11b81c6fe8f2e0cb387@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ran Canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Mark, That (PS --> DS) does sound like a good long term plan. What I am hoping to do is create a Work in Progress document (status TBD) that explains the inter-relationships between the MIKEY I-Ds? There are automated tools that do this (based on which doc refers to which), but a WG document or even an individual submission that puts those relationships in human readable terms would help us all to form consensus on the docs proposing new things to MIKEY. There is already a confusion out there, so this would help. Put another way, I am convinced on why (and hoping to convince others), and trying to figure out what to do and how to do it :-). thanks and regards, Lakshminath Mark Baugher wrote: > MIKEY is an active development area. draft-ietf-mmusic-sdescriptions > is also becoming a target for new features, but this is in mmusic. > What I am thinking for sdescriptions might apply to MIKEY: Post and > eventually publish new features as Proposed Standard RFCs and pick up > the successful ones when the base protocol goes to Draft Standard. I > believe this is in line with IETF process. > > Mark > > p.s. MIKEY and the kmgmt I-D perform a similar function to > sdescriptions, which treats key management as a set of additional SDP > signaling parameters. > > On Aug 5, 2005, at 1:12 AM, Lakshminath Dondeti wrote: > >> What: One of the topics for discussion is whether we want to write an >> MSEC documents roadmap or an umbrella document on MIKEY protocols >> (other ideas are welcome too). >> >> Why: At various times in the life of MSEC, people have asked for an >> MSEC documents roadmap. The number of MIKEY documents has also been >> increasing and it is always not clear to everyone what fits with what >> and so forth. >> >> How: I think a new RFC is the right way. There is a discussion in >> the newtrk working group on these things also. I don't think we >> should wait for what comes out of that group (that could take a long >> time), but we can steal ideas :-). >> >> Opinions and thoughts are very welcome. >> >> thanks and regards, >> Lakshminath >> _______________________________________________ >> 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 Aug 08 18:44:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2GMB-0001O0-7q for msec-archive@megatron.ietf.org; Mon, 08 Aug 2005 18:44:31 -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 SAA00124 for ; Mon, 8 Aug 2005 18:44:28 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 6C3838C88A; Mon, 8 Aug 2005 18:44:30 -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 799238C880 for ; Mon, 8 Aug 2005 18:44:29 -0400 (EDT) Received: (qmail 98220 invoked by uid 3269); 8 Aug 2005 22:44:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98217 invoked from network); 8 Aug 2005 22:44:29 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 8 Aug 2005 22:44:29 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id DCEC76836F for ; Mon, 8 Aug 2005 18:44:28 -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 j78MiNsa007310; Mon, 8 Aug 2005 15:44:24 -0700 (PDT) Received: from [10.50.65.21] (qconnect-10-50-65-21.qualcomm.com [10.50.65.21]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j78MiKic020846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Aug 2005 15:44:21 -0700 (PDT) Message-ID: <42F7E045.4080201@qualcomm.com> Date: Mon, 08 Aug 2005 15:44:21 -0700 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mounir Kellil Subject: Re: [MSEC] MSEC documents roadmap vs. Umbrella document on MIKEY protocols References: <42F31F86.1010206@qualcomm.com> <42F33A1F.2000308@motorola.com> In-Reply-To: <42F33A1F.2000308@motorola.com> Content-Type: text/plain; charset=windows-1252; format=flowed Cc: Ran Canetti , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 SAA00124 Thanks Mounir. 3740 does provide a good introduction to MSEC work,=20 however it doesn't cover all that we do (not all of the MSEC documents=20 get equivalent coverage in that document -- and for good reason). If=20 there is consensus that only MIKEY drafts need any explanation (as to=20 the interrelationships between them), then we can work on an umbrella=20 doc on MIKEY protocols. best, Lakshminath Mounir Kellil wrote: > Hi Lakshminath, > > Regarding the expected "MSEC documents roadmap", couldn=92t be some=20 > overlapping with the RFC 3740, bearing in mind that all MSEC documents=20 > (cuurent drafts and RFCs) are within the scope of that RFC? > > Regards > > Mounir > > Lakshminath Dondeti wrote: > >> What: One of the topics for discussion is whether we want to write an=20 >> MSEC documents roadmap or an umbrella document on MIKEY protocols=20 >> (other ideas are welcome too). >> >> Why: At various times in the life of MSEC, people have asked for an=20 >> MSEC documents roadmap. The number of MIKEY documents has also been=20 >> increasing and it is always not clear to everyone what fits with what=20 >> and so forth. >> >> How: I think a new RFC is the right way. There is a discussion in the=20 >> newtrk working group on these things also. I don't think we should=20 >> wait for what comes out of that group (that could take a long time),=20 >> but we can steal ideas :-). >> >> Opinions and thoughts are very welcome. >> >> thanks and regards, >> Lakshminath >> _______________________________________________ >> 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 Tue Aug 09 13:57:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2YLm-0005dO-7k for msec-archive@megatron.ietf.org; Tue, 09 Aug 2005 13:57:18 -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 NAA26212 for ; Tue, 9 Aug 2005 13:57:16 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C4EA18C460; Tue, 9 Aug 2005 13:57:16 -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 59D428C020 for ; Tue, 9 Aug 2005 13:57:15 -0400 (EDT) Received: (qmail 92273 invoked by uid 3269); 9 Aug 2005 17:57:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 92270 invoked from network); 9 Aug 2005 17:57:15 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 9 Aug 2005 17:57:15 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id 01A1868374 for ; Tue, 9 Aug 2005 13:57:14 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id j79HwKvQ005892; Tue, 9 Aug 2005 13:58:20 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id j79Huj8109200; Tue, 9 Aug 2005 13:56:45 -0400 Received: from prf.watson.ibm.com (prf.watson.ibm.com [9.2.16.112]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id j79Hui3105070; Tue, 9 Aug 2005 13:56:44 -0400 Received: from localhost (canetti@localhost) by prf.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id j79Hpe944760; Tue, 9 Aug 2005 13:51:40 -0400 Date: Tue, 9 Aug 2005 13:51:39 -0400 (EDT) From: canetti To: Michael Luby Subject: RE: [MSEC] Re: [Rmt] Comments on TESLA source authentication in theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: George Gross , "Rmt@ietf. org" , vincent.roca@inrialpes.fr, 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 Mike, If we can design a TESLA standard that's workable for RMT and is also useful elsewhere then all the better ofcourse. I'm also ok with splitting the document if it ends up being clearer. What do the authors think? Ran On Fri, 5 Aug 2005, Michael Luby wrote: > Ran, > I agree with you, an application may want to use TESLA authentication eve= n > if it isn't using encryption (or it is using a completely different form = of > encryption that is outside the scope of GDOI, GSAKMP, MIKEY, etc.). This > isn't particular to ALC or NORM though, and it seems like such a > light-weight bootstrapping TESLA protocol that does not require such key > establishment protocols would be a good independent working group item fo= r > MSEC to tackle. Since it is not particular to ALC or NORM and has wider > applicability, it would be good to do this work once in one place instead= of > repeating it again and again. In general, the proposed application of TE= SLA > to ALC and NORM could be broken up into a couple of nice MSEC building > blocks, since there are no idiosyncracies of ALC or NORM that would requi= re > customization of TESLA to those protocols. Then, there could be a very > short RMT docs that describe the few specifics of how to apply those MSEC > protocols to ALC and NORM and there would be little/no worries about the > overall correctness of the protocols, since all the security work would b= e > done in MSEC. > Mike > > > > -----Original Message----- > > From: canetti [mailto:canetti@watson.ibm.com] > > Sent: Thursday, August 04, 2005 9:51 PM > > To: George Gross > > Cc: Michael Luby; msec@securemulticast.org; vincent.roca@inrialpes.fr; > > Rmt@ietf. org > > Subject: RE: [MSEC] Re: [Rmt] Comments on TESLA source authentication i= n > > theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt > > > > > > George, > > > > Sorry for the delayed response. > > > > Regarding where the NORM/ALS/TESLA draft should be advanced - as you've > > seen in the minutes, the feeling in both WGs and ofthe ADs was that the > > draft should be discussed in both WGs, and that the last call should be > > done in both. Hope that will make both you and Mike happy. > > > > Regarding the need for group key establishment protocol (such as GDOI, > > GSAKMP, MIKEY, etc): All I was saying is that, in the context of RMT, a= n > > application might want to use TESLA *even if* it is not interested in > > encrypting the contents. In such cases there is no need to run a > > full-fledged key establishment protocol. Thus it makes sense to > > develop a method for bootstrapping TESLA that does not require > > such key establishment protocols. (Ofcourse, if the application does wi= sh > > to use encryption, then it might as well run an MSEC key establishement > > protocol.) > > > > Note that the bootstrapping of TESLA does not require transmitting any > > secret information between the sender and a receiver. In fact, all the > > bootstrapping information can in principle be posted on some public > > website for anyone to download. (the only part that requires interactio= n > > is the time synchronization, and even this need not be secret.) > > > > Best, > > > > Ran > > > > > > Mon, 1 Aug 2005, George Gross wrote: > > > > > Hi Ran, > > > > > > I tend to agree with Michael Luby's assessment, that the nature of th= e > > > NORM/ALC/TESLA proposal really seems more closely aligned with our MS= EC > > > working group charter, and particularly the TESLA/ESP work item. The > > > question becomes: are we interested in standardizing a secure multica= st > > > transport layer protocol analogous to TLS in the unicast world? > > or is the > > > secure multicast protocol stack better served by a TESLA ESP > > standard for > > > the Internet layer? > > > > > > You also outlined in a prior e-mail some previously unidentified > > > requirements about NORM/ALC TESLA, which merits a follow up observati= on: > > > > > > > > btw, George, there is considerable difference between the key set= up > > > > > stage for TESLA alone (ie, for message authentication alone) and = > > > > > > session setup using GSAKMP and other group key agreement protocol= s. > > > > > In particular, in the former there is no need to authenticate the > > > > > receiver, and there is no need to setup a group key. > > > > > > I am not convinced that the requirements are as simple as your statem= ent > > > above would led us to believe. In effect, you are assuming that all > > > NORM/ALC TESLA groups *must* have a fixed security policy that > > admits all > > > candidate group members and does not use group traffic encryption (i.= e. > > > a no-op GM authorization policy and null encryption). WHile there may > > > exist a subset of NORM applications that fit that low security > > profile, it > > > is not pausible to say all multicast applications would have such > > > requirements. > > > > > > Even for the narrow case described in the NORM/ALC TESLA draft, in or= der > > > to validate the Group Speaker's signature on the TESLA > > bootstrap data, the > > > Group Member needs to have: > > > > > > 1. a validated certificate chain from the Group Speaker to one of the > > > group's trust anchor certificates. > > > > > > 2. for each group, a keyring of one or more trust anchor certificates= =2E > > > > > > 3. a group security policy database indexed by Group Speaker identity= , > > > that can discriminate between authorized Group Speakers and bogus > > > impostors. > > > > > > 4. a group security policy database that describes the authorized set= of > > > reference timing sources (e.g. timestamp authorities, such that > > one could > > > audit the Group Speaker's asserted timestamp). > > > > > > 5. some kind of anti-replay mechanism to protect the TESLA bootstrap > > > exchange. > > > > > > The first four items require per group receiver endpoint security pol= icy > > > configuration that best scales for a large group when using a group k= ey > > > management protocol. i.e. like as can be expressed using the > > GSAKMP policy > > > token or an equivalent mechanism in other MSEC protocols. > > > > > > Given the above, it seems to me that NORM/ALC TESLA already needs man= y > > > features that come with a full fledged group key management protocol > > > exchange. > > > > > > br, > > > =09George > > > > > > > > > On Mon, 1 Aug 2005, canetti wrote: > > > > > > > > > > > > > > > On Mon, 1 Aug 2005, Michael Luby wrote: > > > > > > > > > I'm not understanding something. Why is it appropriate to > > do TESLA-SRTP in > > > > > MSEC but TESLA-ALC/NORM in RMT? > > > > > > > > because the feeling was that we do have sufficient expertise > > on SRTP in > > > > MSEC (Mark Baugher is a cocauthor of both SRTP and TESLA-SRTP). > > > > > > > > Lets indeed discuss this issue at RMT and MSEC this week and > > see what the > > > > feelings are. In any case, this clearly should be a joint venture. > > > > > > > > > > > > > > I'm pretty skeptical of doing this work in RMT, since the > > expertise is just > > > > > not there for security and since this draft adds a lot of > > stuff that seems > > > > > pretty generic and should be inherent MSEC work, and since > > the security > > > > > expert and one of the inventors of TESLA has himself > > described below that > > > > > TESLA is a relatively complex and delicate protocol. > > > > > > > > I guess this skepticism is natural, in the same way that I'm skepti= cal > > > > about developing in MSEC a protocol that would interoperate with ot= her > > > > RMT protocol. But see below. > > > > > > > > > > > > > > I would really prefer as much of the basic work to be done > > in MSEC as > > > > > possible (like the initial bootstrapping to let the > > receivers have an > > > > > estimate and delta of the current time at the sender when > > there are a lot of > > > > > receivers, which seems pretty generic to me, given that I > > understand MSEC to > > > > > mean Multicast SECurity and multicast generally implies > > lots of receivers), > > > > > and it still seems to me too much is being done in this > > draft and not enough > > > > > of the basic work has been done in MSEC (assuming that the > > work described in > > > > > the initial draft that seems to be new has not been done in MSEC)= =2E > > > > > > > > Practially all these details (bootstrapping, etc) are essentially a > > > > repetition of the description in RFC 4082. It's ok to repeat > > (since this > > > > is going to be standards-track), but as I remarked in the > > previous mail it > > > > should be made explicit that all the details are taken from > > 4082 (and say > > > > explicitly if there is deviation) > > > > > > > > > > > > > > As a side-remark: I'm a bit disappointed with the approach > > that MSEC seems > > > > > to be taking on TESLA, only doing work for an "Informational" RFC= , > > > > > especially for something that involves a relatively complex > > and delicate > > > > > protocol that is non-trivial to understand and implement > > securely. An > > > > > "Informational" RFC is a good starting point, but if it is > > delicate and easy > > > > > to get wrong, it seems like there would be some more > > rock-solid protocol > > > > > descriptions in a "Standards" track that are developed as > > well, at least for > > > > > all the common cases and some of the basic parts of the protocol. > > > > > > > > Well, careful reading may prevent disappointments... :) > > > > > > > > The plan is to have not one but (at least) two concrete, > > standards track > > > > documents: TESLA-SRTP is one, and the future TESLA-ESP is another. > > > > > > > > Ran > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: rmt-bounces@ietf.org > > [mailto:rmt-bounces@ietf.org]On Behalf Of > > > > > > canetti > > > > > > Sent: Sunday, July 31, 2005 9:29 PM > > > > > > To: George Gross > > > > > > Cc: msec@securemulticast.org; vincent.roca@inrialpes.fr; > > Rmt@ietf. org > > > > > > Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source > > authentication in > > > > > > theALC and NORM protocols: > > draft-faurite-rmt-tesla-for-alc-norm-00.txt > > > > > > > > > > > > > > > > > > > > > > > > Faurite, Mike, George, and all - > > > > > > > > > > > > A few high-level points regarding the work on > > standardizing TESLA for > > > > > > RMT's ALC and NORM: > > > > > > > > > > > > First, I agree that this is a very worthwhile endeavor. > > > > > > > > > > > > Regarding how/where it should be done. The approach > > within MSEC so far > > > > > > wrt the standardization of TESLA was to have: > > > > > > (a) a single informational document that describes the principl= es > > > > > > and the rationale, but without specifying exact parameters, pac= ket > > > > > > formats, etc. (This is now RFC 4082). > > > > > > (b) a number of standards-track documents that specify > > how to use TESLA in > > > > > > specific settings. Here we currently have the TESLA-SRTP rfc-to= -be > > > > > > (together with the bootstrapping TESLA draft). the plan > > is to have also a > > > > > > document that describes how to use TESLA within ESP. > > (This document is > > > > > > long overdue. the dead tesla-spec-00 draft that Faurite > > mentioned can > > > > > > be regarded as a first draft of this future document.) > > > > > > > > > > > > The rationale behind organizing things this way was that > > TESLA is a > > > > > > relatively complex and delicate protocol, with several options > > > > > > and modes that make it hard to specify a single closed > > protocol that is > > > > > > not too complex and yet applies to all scenarios. Furthermore, = the > > > > > > experience within MSEC was that it is non-trivial to > > understand the > > > > > > security of this protocol and to implement it securely. > > Therefore, a > > > > > > separate informational document seemed in place. > > > > > > > > > > > > Indeed, as Mike pointed out, this approach is different from RM= T's > > > > > > bulding-block approach. In particular, it doesnt allow > > for easy "cut and > > > > > > paste" of a "TESLA block" from one protocol into another. > > Each protocol > > > > > > should define its own version of TESLA. Still, it seems > > appropriate given > > > > > > the complexity and rich number of options in TESLA (eg, > > direct/indirect > > > > > > synchronization, need for chain renewal, method of > > dealing with dos/packet > > > > > > buffering, etc.) > > > > > > > > > > > > Regarding the present draft. > > > > > > When Faurite asked the RMT and MSEC chairs a few weeks > > ago whether to > > > > > > standardize the present draft within RMT or within MSEC, > > my response was > > > > > > that I thought RMT was a more appropriate venue since the > > main challenge > > > > > > is to make TESLA fit well within the RMT protocol suite, > > and MSEC had no > > > > > > expertise in that. This approach was accepted by the RMT > > chairs, under the > > > > > > condition that there will be "security supervision of the > > draft" by MSEC > > > > > > folks. I still think that this is the best way to do > > things. In fact, one > > > > > > may regard the present draft as a "TESLA building block" > > for the purpose > > > > > > of RMT. This would give implementors three alternative > > ways of using > > > > > > TESLA: either within SRTP, or within ESP, or as part of > > the RMT suite. > > > > > > > > > > > > I've only read the draft at a high level, without delving > > into many of the > > > > > > details. Yet all the choices and descriptions that I read > > in the draft > > > > > > were good. One comment is that I'd refer more closely to > > RFC 4082, to make > > > > > > it clear in each part how exacly the principles and > > guidelines of RFC 4082 > > > > > > are implemented. This may give more confidence to readers > > of this document > > > > > > which are not familiar with 4082 and the security of TESLA. > > > > > > > > > > > > Best, > > > > > > > > > > > > Ran > > > > > > > > > > > > > > > > > > btw, George, there is considerable difference between the > > key setup stage > > > > > > for TESLA alone (ie, for message authentication alone) > > and session setup > > > > > > using GSAKMP and other group key agreement protocols. In > > particular, in > > > > > > the former there is no need to authenticate the receiver, > > and ther eis no > > > > > > need to setup a group key. > > > > > > > > > > > > On Fri, 29 Jul 2005, George Gross wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > =09I've taken a quick look at the NORM/ALC TESLA > > draft. It makes a > > > > > > > good starting point for how to apply TESLA in > > combination with the RMT > > > > > > > work. I did not dive into it to get details, but a few high > > > > > > level comments > > > > > > > seemed in order: > > > > > > > > > > > > > > 1) I have not identified a compelling architectural > > reason why NORM/ALC > > > > > > > TESLA needs to be applied in an application specific manner. > > > > > > Instead, this > > > > > > > work is a good candidate for inclusion within a set of > > one or more > > > > > > > standards track documents that describe how to apply TESLA to > > > > > > existing and > > > > > > > emergent MSEC and IPsec standards. In particular, I would > > > > > > suggest taking a > > > > > > > look at the draft-ietf-msec-ipsec-extensions-00.txt, > > particularly the > > > > > > > service models discussion in the appendix. > > > > > > > > > > > > > > 2) the bootstrapping phase of the NORM/ALC TESLA bears a stro= ng > > > > > > > resemblance to the Internet layer group key management > > protocols already > > > > > > > developed in MSEC: GDOI and GSAKMP. For example, the > > TESLA bootstrap > > > > > > > information could become a sub-payload within the > > GSAKMP Key DownLoad > > > > > > > payload. By using an existent MSEC GKMP, the group > > membership and group > > > > > > > speaker authentication and authorization procedures are > > largely defined > > > > > > > and the TESLA feature becomes an extension of a > > framework. As an aside, > > > > > > > GSAKMP has a distributed mode of operation that alleviates th= e > > > > > > scalability > > > > > > > problem, and it also a uni-directional mode too (e.g. > > for satellite). > > > > > > > > > > > > > > 3) as part of the same activity, we would need to > > design a TESLA ESP > > > > > > > trailer authenticator, with NORM or ALC as the payload. > > > > > > > > > > > > > > 4) integration with the MSEC framework has the additional > > > > > > benefit that the > > > > > > > unicast NORM repair and congestion notification > > messages directed at the > > > > > > > group speaker could be both group and source endpoint > > authenticated, the > > > > > > > source authentication using the RSA signatures scheme > > now in RFC editor > > > > > > > queue. > > > > > > > > > > > > > > 5) The use of one-way hash chains advocated in the > > NORM/ALC TESLA draft > > > > > > > may have IPR issues. I'm not a patent attornory, YMMV. > > > > > > > > > > > > > > The NORM/ALC TESLA draft is on the MSEC agenda for > > Paris, but I won't be > > > > > > > there. So I would hope these discussions could continue on th= e > > > > > > MSEC list. > > > > > > > > > > > > > > hth, > > > > > > > =09George > > > > > > > > > > > > > > On Thu, 28 Jul 2005, faurite wrote: > > > > > > > > > > > > > > > Mike, thanks a lot for your constructive remarks. > > > > > > > > > > > > > > > > Generally speaking, we do agree with all of them. The choic= es > > > > > > > > we made have been done with the goal to bootstrap the > > work (keep > > > > > > > > in mind it's only a -00 version) and to fill in some missin= g > > > > > > > > aspects in current TESLA documents. > > > > > > > > > > > > > > > > > > > > > > > > Let's go into the details, in particular concerning the > > > > > > > > "split between MSEC and RMT WG". > > > > > > > > > > > > > > > > > > > > > > > > You're right, our I-D could easily be split into > > several separate > > > > > > > > documents, some of them being specified in the MSEC > > WG, and the > > > > > > > > ALC/NORM instanciation in the RMT WG. > > > > > > > > This is not the choice we made for the -00 version because = we > > > > > > > > wanted to put forward all the points we believe are > > needed (and > > > > > > > > that are missing in current MSEC TESLA documents). > > > > > > > > > > > > > > > > For instance: > > > > > > > > - boostrap stuff could be moved to a separate "TESLA > > bootstraping > > > > > > > > for ALC/NORM" document (or merged with the current "TESL= A > > > > > > > > bootstraping for SRTP" document if the authors believe i= t's > > > > > > > > feasible/desireable). > > > > > > > > > > > > > > > > - key chain switching: RFC4082 (TESLA introduction) > > does not discuss > > > > > > > > this possibility of high practical importance. The > > same is true > > > > > > > > for the "TESLA for SRTP" I-D. This is an issue in > > particular (but > > > > > > > > not only) with on-demand ALC sessions of > > non-predefined duration. > > > > > > > > We tried to fix this, but yes, a better solution > > would be to > > > > > > > > have this mechanism described in some MSEC TESLA > > document since > > > > > > > > it could then be used not only for ALC/NORM but > > also for SRTP... > > > > > > > > > > > > > > > > - time synchronization stuff: RFC4082 and "TESLA for SRTP" > > > > > > > > essentially focuss on direct synchronization, which is > > > > > > > > not necessarily appropriate in case of ALC > > (scalability/feedback > > > > > > > > problems). So we tried to further clarify how indirect > > > > > > synchronization > > > > > > > > could be done (securely)... > > > > > > > > But yes, here also, a better solution would be to > > have it described > > > > > > > > in an MSEC TESLA document. > > > > > > > > > > > > > > > > Having it all in the same -00 document was a > > deliberate choice, but > > > > > > > > this is questionable, sure. A direct consequence is > > that this single > > > > > > > > I-D could not be submitted to both WGs and we've been > > adviced to send > > > > > > > > it to RMT and CC it to MSEC. That's why. > > > > > > > > > > > > > > > > BTW, an updated "TESLA spec" along the lines of the > > (dead) I-D: > > > > > > > > > > http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-spec-00.txt > > > > > > > > that would incorporate the missing points above is > > clearly missing. > > > > > > > > Some parts of our I-D is inspired from it, as we explained. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Sebastien/Aurelien/Vincent > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Comments on TESLA source authentication in the ALC and NOR= M > > > > > > protocols: > > > > > > > > >draft-faurite-rmt-tesla-for-alc-norm-00.txt > > > > > > > > > > > > > > > > > >First off, I think that this is a very good thing to try a= nd > > > > > > standardize, as > > > > > > > > >TESLA is ideally suited to provide authentication and pack= et > > > > > > integrity > > > > > > > > >protection to ALC and NORM. Unfortunately, I have a lot = of > > > > > > questions and > > > > > > > > >issues with the draft, and some are basic questions about > > > > > > where this work > > > > > > > > >should be done. > > > > > > > > > > > > > > > > > >What I was expecting is a document that describes how to > > > > > > apply TESLA and > > > > > > > > >related security features that have been developed in MSEC > > > > > > that have been > > > > > > > > >developed in the spirit of a building block to ALC and NOR= M, > > > > > > where all the > > > > > > > > >security issues have been addressed in the TESLA work and = it > > > > > > is simply cut > > > > > > > > >and paste to put that into the ALC and NORM context. What= I > > > > > > see instead is > > > > > > > > >a document that describes a lot of protocol work that has > > > > > > security aspects > > > > > > > > >to it that seems more suitable for MSEC. I=92m not sure w= hy > > > > > > this is, perhaps > > > > > > > > >because the TESLA specification does not lend itself to > > > > > > being used as a > > > > > > > > >building block directly, and perhaps because some of the > > > > > > other security > > > > > > > > >protocols have not been addressed by MSEC. It would be go= od > > > > > > though if the > > > > > > > > >basic security work were done in MSEC, and only applicatio= ns > > > > > > of that work > > > > > > > > >that have no potential to introduce weaknesses in security > > > > > > were described in > > > > > > > > >the RMT work that describes how these protocols are applie= d > > > > > > to ALC and NORM. > > > > > > > > >I have been informed that this is the approach taken with > > > > > > SRTP, i.e., the > > > > > > > > >work to apply TESLA to SRTP is being done within > > MSEC, and not AVT. > > > > > > > > > > > > > > > > > >As an example, Section 2 describes protocols for > > time synchronization > > > > > > > > >between the sender and receivers. Since the security of > > > > > > TESLA entirely > > > > > > > > >relies on time synchronization, the security of this > > > > > > protocol is of crucial > > > > > > > > >importance. Furthermore, it seems that time synchronizati= on > > > > > > would be a > > > > > > > > >basic primitive of any protocol that uses TESLA. Thus, it > > > > > > seems like the > > > > > > > > >time synchronization protocols should be work done within > > > > > > the MSEC group > > > > > > > > >that can then be leveraged for application work done in RM= T, > > > > > > and it seems > > > > > > > > >inappropriate for this work to be done in RMT since the > > > > > > security protocol > > > > > > > > >experts aren=92t there. > > > > > > > > > > > > > > > > > >Section 3 on setting TESLA parameters seems to be the type > > > > > > of thing that one > > > > > > > > >would expect in this draft. However, even in this section= , > > > > > > there is very > > > > > > > > >little reference and tie-in with the TESLA RFC, and thus i= t > > > > > > would be good to > > > > > > > > >tighten this section up and refer to the appropriate > > sections and > > > > > > > > >definitions used in TESLA in this section and use the > > > > > > protocols that have > > > > > > > > >been standardized in TESLA. A related comment is that it > > > > > > should be said > > > > > > > > >somewhere in this draft incorporates the TESLA RFC and > > > > > > inherits all of the > > > > > > > > >terminology of the TESLA RFC. > > > > > > > > > > > > > > > > > >The bulk of Section 3 defines the format of bootstrap > > > > > > information signature > > > > > > > > >fields and authentication tags, and many related parameter= s. > > > > > > It seems like > > > > > > > > >this format and information should all be defined in the > > > > > > TESLA RFC, or if > > > > > > > > >not in a related RFC within MSEC. If this is all new to > > > > > > this draft and not > > > > > > > > >described in the TESLA RFC then this seems like a lot of n= ew > > > > > > > > >formatting/information to be adding beyond TESLA, and I > > > > > > would feel a lot > > > > > > > > >more comfortable if this work were done in MSEC. > > > > > > > > > > > > > > > > > >There are a number of other technical comments that could = be > > > > > > made, but I > > > > > > > > >think the high level issue of how to split the work betwee= n > > > > > > MSEC and RMT > > > > > > > > >should be solved before addressing lower level > > technical issues. > > > > > > > > > > > > > > > > > >Regards, > > > > > > > > >Michael Luby > > > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > > > > > >Rmt mailing list > > > > > > > > >Rmt@ietf.org > > > > > > > > >https://www1.ietf.org/mailman/listinfo/rmt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Rmt mailing list > > > > > > Rmt@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/rmt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From gulf_international@excite.com Thu Aug 25 21:31:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8T46-0005VF-NA for msec-archive@megatron.ietf.org; Thu, 25 Aug 2005 21:31:30 -0400 Received: from excite.com (servidor.incodema.edu.co [200.13.211.122] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06492 for ; Thu, 25 Aug 2005 21:31:26 -0400 (EDT) Message-ID: From: "PW LOTTERY" To: "PRIZE WINNER" Subject: AWARD WINNING NOTIFICATION Date: Fri, 26 Aug 2005 04:20:29 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 Content-Transfer-Encoding: 7bit FROM:THE DESK OF THE DIRECTOR OF PROMOTION INTERNATIONAL/PRIZE AWARD DEPT. REF:PL2/209318/09 BATCH:18/103/HME. Dear Winner, We are pleased to inform you of the result of the Lottery Winners International programs held on the 10th August, 2005. Your e-mail address attached to ticket number 436425795822-5022 with serial number 6614102, batch number 8561513507,lottery ref number 7675213911 and drew lucky numbers 7-9-4-17-34-44 which consequently won in category C, you have therefore been approved for a lump sum pay out of US$1.500,000.00 (0NE MILLION FIVE HUNDRED THOUSAND United States dollars). CONGRATULATIONS!!! Due to mix up of some numbers and names, we ask that youkeep your winning information confidential until your claims has been processed and your money Remitted to you. This is part of our security protocol to avoid double claiming and unwarranted abuse of this program by some participants. Al l participants were selected through a computer ballot system drawn from over 40,000 company and 20,000,000 individual email addresses and names from all over the world. This promotional program takes place every year.. This lottery was promoted and sponsored by Association of software roducers. we hope with part of your winning,you will take part in our next year US$20 million international lottery. To file for your claim, please contact our fiducial agent: ============================================================== Contact: FABIAN GEROLT Email:fabgerolt@netscape.net Tel: +316 2667 2428 ============================================================== Remember, all winning must be claimed not later than 15th of semptember, 2005. After this date all unclaimed funds will be included in the next stake. Please note in order to avoid unnecessary delays and complications. Please remember to quote your reference number and batch numbers in all correspondence. Furthermore, should there be any change of address do inform our agent as soon as possible. Congratulations once more from our members of staff and thank you for being part of our promotional program. Note: Anybody under the age of 18 is automatically disqualified. Yours Sincerely, John Smith, Lottery Online Coordinator. From msec-bounces@securemulticast.org Fri Aug 26 00:16:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Vdr-0000bZ-Qq for msec-archive@megatron.ietf.org; Fri, 26 Aug 2005 00:16:40 -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 AAA11918 for ; Fri, 26 Aug 2005 00:16:32 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id D008C8C5CC; Fri, 26 Aug 2005 00:16:34 -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 9F1B18C492 for ; Fri, 26 Aug 2005 00:16:34 -0400 (EDT) Received: (qmail 54591 invoked by uid 3269); 26 Aug 2005 04:16:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54588 invoked from network); 26 Aug 2005 04:16:34 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 26 Aug 2005 04:16:34 -0000 Received: from 126.com (bj45-160.i.netease.com [202.108.45.160]) by klesh.pair.com (Postfix) with SMTP id 255D868353 for ; Fri, 26 Aug 2005 00:16:32 -0400 (EDT) Received: from thinker (unknown [202.115.28.189]) by smtp3 (Coremail) with SMTP id nQJUtJyXDkPEW2FI.1 for ; Fri, 26 Aug 2005 12:16:29 +0800 (CST) X-Originating-IP: [202.115.28.189] Date: Fri, 26 Aug 2005 12:16:39 +0800 From: "QinKe" To: "msec" Organization: UESTC X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20050826041632.255D868353@klesh.pair.com> Subject: [MSEC] A basic question about LKH 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 Dear folks: I have some basic questions about this figure LKH which exists in many theises about secure multicast: k | +---------------+---------------+ | | k_(1-4) k_(5-8) | | +--------+------+ +------+-----+ | | | | k_(1-2) k_(3-4) k_(5-6) k_(7-8) | | | | +-----+-----+ +---+---+ +----+----+ +---+----+ | | | | | | | | k1 k2 k3 k4 k5 k6 k7 k8 The authors described the process of a new member's addition or a current member's eviction. What I'd like to know is that if the tree is a complete binary tree, then where will the GC set member 9? Like this? ...... | +-----+-----+ | | k1 k2 | +--+ | k9 But we can't make such an assumption that member 1 provides forwarding service. Therefore, the tree is really a binary tree? If not, the re-keying messages must be different from that of binary tree. I fell into confusion... _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Aug 26 02:55:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Y83-0005ui-KE for msec-archive@megatron.ietf.org; Fri, 26 Aug 2005 02:55:56 -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 CAA01260 for ; Fri, 26 Aug 2005 02:55:54 -0400 (EDT) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 211108C5E8; Fri, 26 Aug 2005 02:55:54 -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 9E1F98C3F8 for ; Fri, 26 Aug 2005 02:55:53 -0400 (EDT) Received: (qmail 73639 invoked by uid 3269); 26 Aug 2005 06:55:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73636 invoked from network); 26 Aug 2005 06:55:53 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 26 Aug 2005 06:55:53 -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 351A968353 for ; Fri, 26 Aug 2005 02:55:53 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 25 Aug 2005 23:55:52 -0700 X-IronPort-AV: i="3.96,143,1122879600"; d="scan'208"; a="656893605:sNHT32195224" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7Q6tWQa008173; Thu, 25 Aug 2005 23:55:48 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 23:55:48 -0700 Received: from [192.168.0.10] ([10.21.144.143]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 23:55:48 -0700 In-Reply-To: <20050826041632.255D868353@klesh.pair.com> References: <20050826041632.255D868353@klesh.pair.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] A basic question about LKH Date: Thu, 25 Aug 2005 23:55:48 -0700 To: "QinKe" X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 26 Aug 2005 06:55:48.0083 (UTC) FILETIME=[30409C30:01C5AA0B] 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: 7bit hi, LKH does not specify the tree type or balancing algorithms. RFC 2627 does not specify that the tree needs to be balanced or binary. Standard algorithms for adding and removing nodes to a tree such as a binary tree, balancing a tree, etc. can be used. RFC 2627 does specify what needs to be done when a path changes from the root to a leaf such as when a node is added to the tree or removed from the tree for the purposes of adding a leaf, removing a leaf or balancing the tree. The GC must send the updated keys to the leaves that are in the affected subtree. From p. 14 of 2627: "...Starting with those nodes all of whose children are leaves and proceeding towards the root, the server transmits the key for each node, encrypted using the keys for each of that node's children." I modified your diagram below to show one way of adding a leaf, k9 by giving k7, k8 and k9 a new common ancestor. In order to make this change, two keys are sent to k7, k8, k9. One key is k_(7-9) encrypted with k_(7-8) and the second key is k_(7-9) encrypted with k_(9). The point is, however, that whatever algorithm is use for the tree is internal to the GC and not specified by RFC 2627. Mark On Aug 25, 2005, at 9:16 PM, QinKe wrote: > Dear folks: > > I have some basic questions about this figure LKH which exists in many > theises about secure multicast: > > k > | > +---------------+---------------+ > | | > k_(1-4) k_(5-8) +-----+ > | | | | > +--------+------+ +------+----+ k_(7-9) > | | | +-----+----+ > k_(1-2) k_(3-4) k_(5-6) k_(7-8) k_(9) > | | | | | > +-----+-----+ +---+---+ +----+----+ +---+----+ + > | | | | | | | | | > k1 k2 k3 k4 k5 k6 k7 k8 k9 > > The authors described the process of a new member's addition or a > current member's eviction. > What I'd like to know is that if the tree is a complete binary tree, > then where will the GC set member 9? Like this? > > ...... > | > +-----+-----+ > | | > k1 k2 > | > +--+ > | > k9 > > But we can't make such an assumption that member 1 provides forwarding > service. > Therefore, the tree is really a binary tree? If not, the re-keying > messages must be different from that of binary tree. I fell into > confusion... > > > _______________________________________________ > 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