Subject: [Rmt] Comments on TESLA source authentication in the ALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt

From: "Michael Luby" <[email-masked]>
Date: Tue, 26 Jul 2005 14:41:38 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: faurite <[email-masked]>
Date: Thu, 28 Jul 2005 10:10:14 +0200

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

---

From: George Gross <[email-masked]>
Date: Fri, 29 Jul 2005 07:31:34 -0400 (EDT)

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:

> msec mailing list
> [email-masked]
> http://six.pairlist.net/mailman/listinfo/msec
>