RE: [MSEC] Re: [Rmt] Comments on TESLA source authentication in theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt

[canetti <[e-mail]>]

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 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: [e-mail] [mailto:[e-mail]]On Behalf Of
> > canetti
> > Sent: Sunday, July 31, 2005 9:29 PM
> > To: George Gross
> > Cc: [e-mail]; [e-mail]; 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,
> > >
> > > 	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 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,
> > > 	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 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’m 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’t 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
> > > > >[e-mail]
> > > > >https://www1.ietf.org/mailman/listinfo/rmt
> > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > msec mailing list
> > > > [e-mail]
> > > > http://six.pairlist.net/mailman/listinfo/msec
> > > >
> > >
> > > _______________________________________________
> > > msec mailing list
> > > [e-mail]
> > > http://six.pairlist.net/mailman/listinfo/msec
> > >
> > >
> > >
> >
> > _______________________________________________
> > Rmt mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/rmt
> >
>
>
>

_______________________________________________
Rmt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rmt