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]>]

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: [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
> >>>
> >>
> >>
> >>
> > _______________________________________________
> > msec mailing list
> > [e-mail]
> > http://six.pairlist.net/mailman/listinfo/msec
> >
>
>

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