Subject: RE: [MSEC] new draft avaialable for bootstrapping TESLA

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Wed, 27 Oct 2004 08:26:46 +0200

Ran pointed out to me in San Diego that the parameter was missing, 
so the new version has it.

/E

>-----Original Message-----
>From: Mark Baugher [mailto:[email-masked]]
>Sent: den 26 oktober 2004 23:45
>To: canetti
>Cc: Elisabetta Carrara (KI/EAB); [email-masked]
>Subject: Re: [MSEC] new draft avaialable for bootstrapping TESLA
>
>
>
>On Oct 23, 2004, at 8:18 PM, canetti wrote:
>
>>
>> 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.
>
>I think we're missing that parameter
>
>Mark
>>
>> Ran
>>
>>
>> On Fri, 22 Oct 2004, Mark Baugher wrote:
>>
>>> 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
>>> On Oct 22, 2004, at 5:25 AM, Steffen Fries wrote:
>>>
>>>> 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]
>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>    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
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> msec mailing list
>> [email-masked]
>> http://six.pairlist.net/mailman/listinfo/msec
>>
>
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec