Subject: [MSEC] new draft avaialable for bootstrapping TESLA

From: "Steffen Fries" <[email-masked]>
Date: Wed, 20 Oct 2004 08:42:57 +0200

Hi,

please find the Internet draft in the attachment or at the given
URL. We would like to discuss this approach on the mailing list.
Please sent comments!

Title

Bootstrapping TESLA

Abstract

With the Timed Efficient Stream Loss-tolerant Authentication

protocol (TESLA) a protocol for providing source authentication

in multicast scenarios was introduced.  A mapping for TESLA to

the Secure Real-time Transport Protocol (SRTP) has been

published which assumes that some TESLA parameters are made

available by out-of-band mechanisms.  This document describes

payloads for bootstrapping these parameters with the help of

the Multimedia Internet KEYing (MIKEY)

Authors:

S. Fries

H. Tschofenig

URL:

http://www.tschofenig.com/drafts/draft-fries-msec-
bootstrapping-tesla-00.txt

http://www.tschofenig.com/drafts/draft-fries-msec-
bootstrapping-tesla-00.html

Best Regards,

Steffen Fries

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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 20 Oct 2004 13:15:57 -0700

This looks cool.  Why don't we merge this into the TESLA I-D and I'll 
add a section on sdescriptions?

Mark
On Oct 19, 2004, at 11:42 PM, Steffen Fries wrote:

> Hi,
>
>
> please find the Internet draft in the attachment or at the given URL. 
> We would like to discuss this approach on the mailing list. Please 
> sent comments!
>
>
> Title
>
>
>    Bootstrapping TESLA
>
>
>  Abstract
>
>

---

From: "Steffen Fries" <[email-masked]>
Date: Fri, 22 Oct 2004 14:25:57 +0200

Hi Mark,

sorry for the dely. 

Hm, merging it with the TESLA ID would bind the applicability 
to SRTP only. Wouldn't it make more sense to have it stand 
alone to be able to use it also for scenarios, were TESLA is 
used without SRTP?

Ciao
    Steffen

Copies to:      	Thomas Hardjono <[email-masked]>, [email-masked],
       	canetti <[email-masked]>,
       	hannes Tschofenig <[email-masked]>,
       	Elisabetta Carrara (KI/EAB) <[email-masked]>
From:           	Mark Baugher <[email-masked]>
Subject:        	Re: [MSEC] new draft avaialable for bootstrapping TESLA
Date sent:      	Wed, 20 Oct 2004 13:15:57 -0700
To:             	[email-masked]

> >  the Secure Real-time Transport Protocol (SRTP) has been   published
> >  which assumes that some TESLA parameters are made   available by
> >  out-of-band mechanisms.  This document describes   payloads for
> >  bootstrapping these parameters with the help of   the Multimedia
> >  Internet KEYing (MIKEY)
> >
> >
> >  Authors:
> >
> >
> >    S. Fries
> >    H. Tschofenig
> >
> >
> >  URL:
> >
> >

---

From: Mark Baugher <[email-masked]>
Date: Fri, 22 Oct 2004 09:03:01 -0700

hi Steffen
   That's true, it _might_ be more modular if it stands alone as a 
separate document.  It is also possible that different security 
protocols will have different parameters for TESLA.  I don't think it's 
necessary and don't think that would be a good thing, but we have 
approached SRTP TESLA as if we were free to invent new parameters or 
reuse existing parameters such as the RTP timestamp (which turned out 
to be infeasible).

   This question comes up repeatedly and there is a tradeoff between 
giving the implementer a single document to use versus having several 
that are general purpose.  Dan Harkins thought this was a big problem 
with IKE v1.  I have heard complaints about GDOI, which assumes 
knowledge of a few other documents (GDOI uses an IKE v1 phase 1 
exchange, for example).

   At present, there is only one TESLA protocol that would use MIKEY, 
the ESP variant would use IKE v2, I expect.  I would like to see one 
comprehensive document for SRTP TESLA.  I'd also like to see some 
cooperative work on getting an SRTP TESLA prototype, which presumably 
would include signaling and key management.

Mark

---

From: canetti <[email-masked]>
Date: Sat, 23 Oct 2004 23:18:10 -0400 (EDT)

I can certainly see arguments both ways regarding whether to join the new
draft with the current tesla-srtp or not. This would be something to
discuss and decide in DC.

I wanted to relate to another issue in the new draft. In fact, the issue
is relevant also to tesla-srtp: The draft misses one important parameter:
before the receiver can do anything, it must have a bound on the time
difference its local clock and the senders's clock. (This value is denoted
D_t in the tesla-intro draft.) Setting this value could be tricky - it may
need a roundtrip receiver->sender->receiver.

Looking again at the tesla-srtp draft, I didn't find this parameter there
either. this parameter is necessary for determining the cutoff time for a
packet, and in particular in determining if the packet is safe or did it
arrive too late.

Ran

---

From: "Steffen Fries" <[email-masked]>
Date: Mon, 25 Oct 2004 12:12:05 +0200

Hi Ran,

okay, I see your point. 

MIKEY already provides timestamps as part of the MIKEY payload, 
which is used in the context of MIKEY to detect replay. This 
also requires a loosly time synchronization. I thought that this 
is also sufficient for TESLA. 
Do you think it would be enough to add a section explaining 
this?

Regards
	Steffen

Date sent:      	Sat, 23 Oct 2004 23:18:10 -0400 (EDT)
From:           	canetti <[email-masked]>
To:             	Mark Baugher <[email-masked]>
Copies to:      	[email-masked], Thomas Hardjono <[email-masked]>,
       	[email-masked],
       	hannes Tschofenig <[email-masked]>,
       	Elisabetta Carrara <[email-masked]>
Subject:        	Re: [MSEC] new draft avaialable for bootstrapping TESLA

> 
> I can certainly see arguments both ways regarding whether to join the
> new draft with the current tesla-srtp or not. This would be something
> to discuss and decide in DC.
> 
> I wanted to relate to another issue in the new draft. In fact, the
> issue is relevant also to tesla-srtp: The draft misses one important
> parameter: before the receiver can do anything, it must have a bound
> on the time difference its local clock and the senders's clock. (This
> value is denoted D_t in the tesla-intro draft.) Setting this value
> could be tricky - it may need a roundtrip receiver->sender->receiver.
> 
> Looking again at the tesla-srtp draft, I didn't find this parameter
> there either. this parameter is necessary for determining the cutoff
> time for a packet, and in particular in determining if the packet is
> safe or did it arrive too late.
> 
> Ran
> 
> 
> > protocols will have different parameters for TESLA.  I don't think
> > it's necessary and don't think that would be a good thing, but we
> > have approached SRTP TESLA as if we were free to invent new
> > parameters or reuse existing parameters such as the RTP timestamp
> > (which turned out to be infeasible).
> >
> > giving the implementer a single document to use versus having
> > several that are general purpose.  Dan Harkins thought this was a
> > big problem with IKE v1.  I have heard complaints about GDOI, which
> > assumes knowledge of a few other documents (GDOI uses an IKE v1
> > phase 1 exchange, for example).
> >
> > cooperative work on getting an SRTP TESLA prototype, which
> > presumably would include signaling and key management.
> >
> > Mark
> > > Hm, merging it with the TESLA ID would bind the applicability to
> > > SRTP only. Wouldn't it make more sense to have it stand alone to
> > > be able to use it also for scenarios, were TESLA is used without
> > > SRTP?
> > >
> > > Ciao
> > >     Steffen
> > >
> > >
> > > Subject:        	Re: [MSEC] new draft avaialable for bootstrapping
> > > TESLA Date sent:      	Wed, 20 Oct 2004 13:15:57 -0700 To:        
> > >     	[email-masked]
> > >
> > >> This looks cool.  Why don't we merge this into the TESLA I-D and
> > >> I'll add a section on sdescriptions?
> > >>
> > >> Mark
> > >>>    protocol (TESLA) a protocol for providing source
> > >>>  authentication   in multicast scenarios was introduced.  A
> > >>>  mapping for TESLA to   the Secure Real-time Transport Protocol
> > >>>  (SRTP) has been   published which assumes that some TESLA
> > >>>  parameters are made   available by out-of-band mechanisms. 
> > >>>  This document describes   payloads for bootstrapping these
> > >>>  parameters with the help of   the Multimedia Internet KEYing
> > >>>  (MIKEY)
> > >>>
> > >>>
> > >>>  Authors:
> > >>>
> > >>>
> > >>>    S. Fries
> > >>>    H. Tschofenig
> > >>>
> > >>>
> > >>>  URL:
> > >>>
> > >>>

-----------------------------------------------------------
    Steffen Fries,     Siemens AG, CT IC 3	
    Otto-Hahn-Ring 6,  D-81730 Munich, Germany 
    Phone:  (+49) 89 / 636-53403,    
    Fax  :  (+49) 89 / 636-48000
    Email:  [email-masked]
-----------------------------------------------------------

---

From: canetti <[email-masked]>
Date: Mon, 25 Oct 2004 15:39:39 -0400 (EDT)

Steffen,

I dont think that a simple MIKEY timestamp would suffice here.
The MIKEY timestamp only records the local time at the sender at the time
of sending. In contrast, what the receiver needs for TESLA is an upper
bound on the difference (sender's local time - receiver's local time).
That is, the receiver needs to know that if its local time is T then the
sender's local time is at MOST T+D_t.

In order to get an upper bound on D_t there needs to be some communication
from the receiver to the sender. Alternatively, if a GCKS is used, then
it's ok to have a communication from the receiver to the GCKS.

I can think of two things we can do:

1. assume that the value D_t is computed using means external to MIKEY and
MIKEY only communicates the already-known value. (This would make sense
if, say, there was already some interaction between the sender and
receiver, or between a GCKS and the sender.)
2. use the interactive (two-message) variant of MIKEY, and piggyback an
exchange of timing messages on the two MIKEY messages.

Any other ideas?

Ran

---

From: "Steffen Fries" <[email-masked]>
Date: Tue, 26 Oct 2004 15:32:55 +0200

Hi Ran

MIKEY also recommends using NTP for time synchronization. This 
could be done in group based communication scenarios via a GCKS 
as you pointed out in option 1.

Providing a piggyback mechanism on top of MIKEY may not be work 
for every case as MIKEY runs with two messages at most. Imagine 
that a client opens a media session with the a media data 
provider and acts as MIKEY initiator. In this case both could 
piggyback the timestamps as described in section 3.3.1 in the 
TESLA intro draft. After receiving the MIKEY responder message 
the client would be able to calculate D_t. 
If on the other hand the media data provider acts as a MIKEY 
initiator the client would not be able to follow the example 
from section 3.3.1, without receiving an additional message 
(carrying t_s, t_r).

I would suggest going with option 1 using out of band mechanisms 
like NTP or SNTP as MIKEY already needs to solve the problem of 
time synchronization too. 

Regards
	Steffen

Date sent:      	Mon, 25 Oct 2004 15:39:39 -0400 (EDT)
From:           	canetti <[email-masked]>
To:             	Steffen Fries <[email-masked]>
Copies to:      	Mark Baugher <[email-masked]>,
       	Thomas Hardjono <[email-masked]>, [email-masked],
       	hannes Tschofenig <[email-masked]>,
       	Elisabetta Carrara <[email-masked]>
Subject:        	Re: [MSEC] new draft avaialable for bootstrapping TESLA

> The MIKEY timestamp only records the local time at the sender at the
> time of sending. In contrast, what the receiver needs for TESLA is an
> upper bound on the difference (sender's local time - receiver's local
> time). That is, the receiver needs to know that if its local time is T
> then the sender's local time is at MOST T+D_t.
> 
> In order to get an upper bound on D_t there needs to be some
> communication from the receiver to the sender. Alternatively, if a
> GCKS is used, then it's ok to have a communication from the receiver
> to the GCKS.
> 
> 1. assume that the value D_t is computed using means external to MIKEY
> and MIKEY only communicates the already-known value. (This would make
> sense if, say, there was already some interaction between the sender
> and receiver, or between a GCKS and the sender.) 2. use the
> interactive (two-message) variant of MIKEY, and piggyback an exchange
> of timing messages on the two MIKEY messages.
> 
> Any other ideas?
> 
> Ran
> 
> > which is used in the context of MIKEY to detect replay. This also
> > requires a loosly time synchronization. I thought that this is also
> > sufficient for TESLA. Do you think it would be enough to add a
> > section explaining this?
> >
> > Regards
> > 	Steffen
> >
> >
> >
> > TESLA
> > > I can certainly see arguments both ways regarding whether to join
> > > the new draft with the current tesla-srtp or not. This would be
> > > something to discuss and decide in DC.
> > >
> > > issue is relevant also to tesla-srtp: The draft misses one
> > > important parameter: before the receiver can do anything, it must
> > > have a bound on the time difference its local clock and the
> > > senders's clock. (This value is denoted D_t in the tesla-intro
> > > draft.) Setting this value could be tricky - it may need a
> > > roundtrip receiver->sender->receiver.
> > >
> > > Looking again at the tesla-srtp draft, I didn't find this
> > > parameter there either. this parameter is necessary for
> > > determining the cutoff time for a packet, and in particular in
> > > determining if the packet is safe or did it arrive too late.
> > >
> > > Ran
> > >
> > >
> > > > protocols will have different parameters for TESLA.  I don't
> > > > think it's necessary and don't think that would be a good thing,
> > > > but we have approached SRTP TESLA as if we were free to invent
> > > > new parameters or reuse existing parameters such as the RTP
> > > > timestamp (which turned out to be infeasible).
> > > >
> > > > several that are general purpose.  Dan Harkins thought this was
> > > > a big problem with IKE v1.  I have heard complaints about GDOI,
> > > > which assumes knowledge of a few other documents (GDOI uses an
> > > > IKE v1 phase 1 exchange, for example).
> > > >
> > > > the ESP variant would use IKE v2, I expect.  I would like to see
> > > > one comprehensive document for SRTP TESLA.  I'd also like to see
> > > > some cooperative work on getting an SRTP TESLA prototype, which
> > > > > Subject:        	Re: [MSEC] new draft avaialable for
> > > > > bootstrapping TESLA Date sent:      	Wed, 20 Oct 2004 13:15:57
> > > > > -0700 To:
> > > > >> This looks cool.  Why don't we merge this into the TESLA I-D
> > > > >> and I'll add a section on sdescriptions?
> > > > >>
> > > > >> Mark
> > > > >>> please find the Internet draft in the attachment or at the
> > > > >>> given URL. We would like to discuss this approach on the
> > > > >>> mailing list. Please sent comments!
> > > > >>>
> > > > >>>
> > > > >>> Title
> > > > >>>
> > > > >>>
> > > > >>>    Bootstrapping TESLA
> > > > >>>
> > > > >>>
> > > > >>>  Abstract
> > > > >>>
> > > > >>>
> > > > >>>    With the Timed Efficient Stream Loss-tolerant
> > > > >>>  Authentication   protocol (TESLA) a protocol for providing
> > > > >>>  source authentication   in multicast scenarios was
> > > > >>>  introduced.  A mapping for TESLA to   the Secure Real-time
> > > > >>>  Transport Protocol (SRTP) has been   published which
> > > > >>>  assumes that some TESLA parameters are made   available by
> > > > >>>  out-of-band mechanisms.  This document describes   payloads
> > > > >>>  for bootstrapping these parameters with the help of   the
> > > > >>>  Multimedia Internet KEYing (MIKEY)
> > > > >>>
> > > > >>>
> > > > >>>  Authors:
> > > > >>>
> > > > >>>
> > > > >>>    S. Fries
> > > > >>>    H. Tschofenig
> > > > >>>
> > > > >>>
> > > > >>>  URL:
> > > > >>>
> > > > >>>

---

From: canetti <[email-masked]>
Date: Tue, 26 Oct 2004 13:09:54 -0400 (EDT)

Steffen,

Perhaps you can discuss both options. Option 2 requires a light surgery
to MIKEY (specifying exactly how the piggybacking is done.)

In general, MIKEY makes a somewhat milder use of timestamping than TESLA.
MIKEY only uses the timestamping to avoid replay, and thus it does not need
a flow from the receiver to the sender. TESLA needs this back flow to get the
upper bound on the time difference.

Ran

---

From: Mark Baugher <[email-masked]>
Date: Tue, 26 Oct 2004 14:45:28 -0700

On Oct 23, 2004, at 8:18 PM, canetti wrote:

> new
> issue
> there

I think we're missing that parameter

Mark
>> it's
>>>>> published

---

From: "Steffen Fries" <[email-masked]>
Date: Wed, 27 Oct 2004 09:17:25 +0200

Hi Ran,

yes, discussing both options is fine I think. I will include it 
in the next version of the draft.

Regards
	Steffen

Date sent:      	Tue, 26 Oct 2004 13:09:54 -0400 (EDT)

> 
> Steffen,
> 
> Perhaps you can discuss both options. Option 2 requires a light
> surgery to MIKEY (specifying exactly how the piggybacking is done.)
> 
> In general, MIKEY makes a somewhat milder use of timestamping than
> TESLA. MIKEY only uses the timestamping to avoid replay, and thus it
> does not need a flow from the receiver to the sender. TESLA needs this
> back flow to get the upper bound on the time difference.
> 
> Ran
> 
> 
> 
> 
> > could be done in group based communication scenarios via a GCKS as
> > you pointed out in option 1.
> >
> > Providing a piggyback mechanism on top of MIKEY may not be work for
> > every case as MIKEY runs with two messages at most. Imagine that a
> > client opens a media session with the a media data provider and acts
> > as MIKEY initiator. In this case both could piggyback the timestamps
> > as described in section 3.3.1 in the TESLA intro draft. After
> > receiving the MIKEY responder message the client would be able to
> > calculate D_t. If on the other hand the media data provider acts as
> > a MIKEY initiator the client would not be able to follow the example
> > like NTP or SNTP as MIKEY already needs to solve the problem of time
> > synchronization too.
> >
> > Regards
> > 	Steffen
> >
> >
> >
> >        	Thomas Hardjono <[email-masked]>,
> >        [email-masked], 	hannes Tschofenig
> >        <[email-masked]>, 	Elisabetta Carrara
> >        <[email-masked]>
> > > I dont think that a simple MIKEY timestamp would suffice here. The
> > > MIKEY timestamp only records the local time at the sender at the
> > > time of sending. In contrast, what the receiver needs for TESLA is
> > > an upper bound on the difference (sender's local time - receiver's
> > > local time). That is, the receiver needs to know that if its local
> > > time is T then the sender's local time is at MOST T+D_t.
> > >
> > > GCKS is used, then it's ok to have a communication from the
> > > receiver to the GCKS.
> > >
> > > 1. assume that the value D_t is computed using means external to
> > > MIKEY and MIKEY only communicates the already-known value. (This
> > > would make sense if, say, there was already some interaction
> > > between the sender and receiver, or between a GCKS and the
> > > sender.) 2. use the interactive (two-message) variant of MIKEY,
> > > and piggyback an exchange of timing messages on the two MIKEY
> > > messages.
> > >
> > > Any other ideas?
> > >
> > > Ran
> > >
> > > > is also sufficient for TESLA. Do you think it would be enough to
> > > > add a section explaining this?
> > > >
> > > > Regards
> > > > 	Steffen
> > > >
> > > >
> > > >
> > > > bootstrapping TESLA
> > > > > I can certainly see arguments both ways regarding whether to
> > > > > join the new draft with the current tesla-srtp or not. This
> > > > > would be something to discuss and decide in DC.
> > > > >
> > > > > I wanted to relate to another issue in the new draft. In fact,
> > > > > the issue is relevant also to tesla-srtp: The draft misses one
> > > > > important parameter: before the receiver can do anything, it
> > > > > must have a bound on the time difference its local clock and
> > > > > the senders's clock. (This value is denoted D_t in the
> > > > > tesla-intro draft.) Setting this value could be tricky - it
> > > > > may need a roundtrip receiver->sender->receiver.
> > > > >
> > > > > > separate document.  It is also possible that different
> > > > > > security protocols will have different parameters for TESLA.
> > > > > >  I don't think it's necessary and don't think that would be
> > > > > > a good thing, but we have approached SRTP TESLA as if we
> > > > > > were free to invent new parameters or reuse existing
> > > > > > parameters such as the RTP timestamp (which turned out to be
> > > > > > infeasible).
> > > > > >
> > > > > > giving the implementer a single document to use versus
> > > > > > having several that are general purpose.  Dan Harkins
> > > > > > thought this was a big problem with IKE v1.  I have heard
> > > > > > complaints about GDOI, which assumes knowledge of a few
> > > > > > other documents (GDOI uses an IKE v1 phase 1 exchange, for
> > > > > > example).
> > > > > >
> > > > > > the ESP variant would use IKE v2, I expect.  I would like to
> > > > > > see one comprehensive document for SRTP TESLA.  I'd also
> > > > > > like to see some cooperative work on getting an SRTP TESLA
> > > > > > prototype, which presumably would include signaling and key
> > > > > > management.
> > > > > >
> > > > > > Mark
> > > > > > > Hm, merging it with the TESLA ID would bind the
> > > > > > > applicability to SRTP only. Wouldn't it make more sense to
> > > > > > > have it stand alone to be able to use it also for
> > > > > > > scenarios, were TESLA is used without SRTP?
> > > > > > >
> > > > > > > Ciao
> > > > > > >     Steffen
> > > > > > >
> > > > > > >
> > > > > > > bootstrapping TESLA Date sent:      	Wed, 20 Oct 2004
> > > > > > > 13:15:57 -0700 To:
> > > > > > >> This looks cool.  Why don't we merge this into the TESLA
> > > > > > >> I-D and I'll add a section on sdescriptions?
> > > > > > >>
> > > > > > >> Mark
> > > > > > >>> please find the Internet draft in the attachment or at
> > > > > > >>> the given URL. We would like to discuss this approach on
> > > > > > >>> the mailing list. Please sent comments!
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> Title
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>    Bootstrapping TESLA
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>  Abstract
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>  Authentication   protocol (TESLA) a protocol for
> > > > > > >>>  providing source authentication   in multicast
> > > > > > >>>  scenarios was introduced.  A mapping for TESLA to   the
> > > > > > >>>  Secure Real-time Transport Protocol (SRTP) has been  
> > > > > > >>>  published which assumes that some TESLA parameters are
> > > > > > >>>  made   available by out-of-band mechanisms.  This
> > > > > > >>>  document describes   payloads for bootstrapping these
> > > > > > >>>  parameters with the help of   the Multimedia Internet
> > > > > > >>>  KEYing (MIKEY)
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>  Authors:
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>    S. Fries
> > > > > > >>>    H. Tschofenig
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>  URL:
> > > > > > >>>
> > > > > > >>>