Subject: [MSEC] RE: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard]

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Tue, 12 Jul 2005 15:22:59 -0700

Mark,

Thanks.  Perhaps some additional text along the lines you explain below and responding to Colin's request would be great!

Have you had a chance to look at the RECOMMENDED vs. OPTIONAL references I listed below.

thanks again,
Lakshminath

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]]
Sent: Tue 7/12/2005 1:06 PM
To: Dondeti, Lakshminath
Cc: [email-masked]; Colin Perkins; elisabetta Carrara; Russ Housley
Subject: Re: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard]
 
Lakshminath,
   We discussed this extensively on the list and agreed that we would 
have two MACs as a means to (1) integrity-check the group, which uses 
an SRTP HMAC, and (2) integrity-check the sender, which uses TESLA.  
There are other alternatives, but we defined the one that is the most 
secure.  We could define a second, but I would wait until we see that 
this is needed because we don't like options in a security protocol; we 
don't like doubling the complexity and use cases.

   At the present, we do compound authentication, which is all 
completely defined by the specification.

Mark
On Jul 12, 2005, at 11:58 AM, Lakshminath Dondeti wrote:

> Thanks Mark.
> <Speaking as a contributor to the MSEC WG.>
>
> My *guess* is Colin is asking for an explanation as to why the auth 
> tag cannot be reused to put the result of the TESLA computation.  I 
> think in MSEC we know the history behind it; so perhaps the TESLA-SRTP 
> document should say in detail why (what are the pros and cons and why 
> we chose to use two MACs instead of using one.  The additional fields 
> might also be a concern.  Perhaps a section titled "Packet expansion 
> due to TESLA" might help.
>
> Colin, please elaborate.  Thanks.
>
> I also noticed that "4.2. SRTP Packet Format," Paragraph 1  says 
> (recommended)  authentication tag (SRTP MAC)
>                                                                        
>                    ^^^^^^^^^^^^^
> and
>
> Section 4.6, Paragraph 3 says The normal authentication tag (OPTIONAL 
> for SRTP, ... )
>                                                                        
>              ^^^^^^^^^^^
> That seems inconsistent.  Could you please double check? (Sorry I 
> missed that in the previous readings of the draft.)  Thanks.
>
> best regards,
> Lakshminath
>
> Mark Baugher wrote:
>
>> hi,
>>   I think there is a misunderstanding here:
>>
>>>>
>> ...
>>
>>>> I have reviewed this draft, and believe the material appropriate for
>>>> publication as a proposed standard RFC.
>>>>
>>>> My only minor concern is that the data origin authentication 
>>>> features
>>>> of TESLA are presented as extensions to SRTP, needing new headers 
>>>> and
>>>> new processing rules, and not as a new authentication option for use
>>>> within the existing SRTP framework. The protocol appears reasonable,
>>>> but would be more obviously compatible with SRTP if it were 
>>>> presented
>>>> differently. I would recommend either editorial clarifications to
>>>> explain this or, if TESLA cannot be considered a new authentication
>>>> option in the SRTP framework, a more detailed review of how this
>>>> draft fits with SRTP as a whole.
>>>>
>>>> Colin
>>>>
>>
>> It is definitely a new authentication option in the SRTP framework.  
>> This is made clear in the document, viz.
>> 4.1. The TESLA extension
>>
>>    TESLA is an OPTIONAL authentication transform for SRTP.  When used,
>>    TESLA adds the fields shown in Figure 1 per-packet.  The fields
>>    added by TESLA are called "TESLA authentication extensions"
>>    altogether, whereas "authentication tag" or "integrity protection
>>    tag" indicate the normal SRTP integrity protection tag, when the
>>    SRTP master key is shared by more than two endpoints [RFC3711].
>>
>> Baugher, Carrara                                              [Page 4]
>> 
>> INTERNET-DRAFT                 TESLA-SRTP                February 2005
>>
>>
>>
>>
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                              i                                |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    ~                         Disclosed Key                         ~
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    ~                           TESLA MAC                           ~
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    Figure 1: The "TESLA authentication extension".
>>
>> speaking strictly for myself, I think this is the right way to add 
>> the tesla function to a security protocol:  As a new transform.  All 
>> security protocols need to be extensible to new transforms and 
>> support the update of existing transforms in order to offer a known 
>> workload factor as computers get faster, to handle advances in 
>> breaking algorithms, and etc.  By adding a new 
>> authentication/message-integrity-check transform, TESLA gets added 
>> without the need to redefine SRTP at all.  It's business as usual.
>>
>> Mark
>>
>> p.s. I think that changing the protocol format is not a good way to 
>> add tesla to a security protocol.
>

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