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

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 12 Jul 2005 14:10:35 -0400

-------- Original Message --------
Subject: 	Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed 
Standard
Date: 	Mon, 11 Jul 2005 17:18:07 -0400
From: 	Russ Housley <[email-masked]>
To: 	[email-masked], [email-masked]

Please let me know how you want to handle this comment.

Russ

>From: Colin Perkins <[email-masked]>
>Date: Mon, 11 Jul 2005 18:34:45 +0100
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: Last Call: 'The Use of TESLA in SRTP' to Proposed Standard
>
>On 24 Jun 2005, at 23:54, The IESG wrote:
>>The IESG has received a request from the Multicast Security WG to
>>consider the
>>following document:
>>
>>- 'The Use of TESLA in SRTP '
>>    <draft-ietf-msec-srtp-tesla-03.txt> as a Proposed Standard
>>
>>The IESG plans to make a decision in the next few weeks, and solicits
>>final comments on this action.  Please send any comments to the
>>[email-masked] or [email-masked] mailing lists by 2005-07-11.
>
>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
>

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

---

From: Mark Baugher <[email-masked]>
Date: Tue, 12 Jul 2005 11:39:30 -0700

hi,
   I think there is a misunderstanding here:
...
>> draft fits with SRTP as a whole.

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 12 Jul 2005 14:58:18 -0400

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:

> p.s. I think that changing the protocol format is not a good way to 
> add tesla to a security protocol.

---

From: Mark Baugher <[email-masked]>
Date: Tue, 12 Jul 2005 13:06:50 -0700

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:

> 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.
>
> 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,
>> 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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 13 Jul 2005 21:36:25 -0700

Colin,
   Thanks for your comments.  More below...
On Jul 12, 2005, at 1:15 PM, Colin Perkins wrote:

> On 12 Jul 2005, at 19:58, Lakshminath Dondeti wrote:
...
> That's close: I'm asking why the TESLA MAC is presented as a new set 
> of headers to be added to SRTP, rather than as part of the existing 
> authentication header (which would gain more structure to include the 
> second MAC). There didn't seem to be a good rationale for extending 
> SRTP,

We're not, the whole thing is processed by tesla but the tesla 
authentication tag is a compound tag with different parts for different 
purposes.

> rather than registering a new authentication mechanism that happens to 
> do something funky with dual MACs, but within the usual SRTP 
> framework.

Yes this is a new authentication framework that does something funky 
with dual MACs.  What am I missing?

Mark