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

From: "Elisabetta Carrara (AL/EAB)" <[email-masked]>
Date: Mon, 18 Jul 2005 18:26:08 +0200

Hi Colin!

your proposal appears good. It also shows well what a new transform 
that needs its own fields should do; for example, a cipher 
with an explicit IV may define to place such IV in front of the 
payload. 

However, the reason why the TESLA fields are placed like that, is 
the authentication coverage. It actually appeared to us a nice fit to
place all the fields to be authenticated together at the beginning. 
I think to recall that the TESLA RFC requires the group-key MAC 
(i.e. the SRTP MAC, here) to cover the message and the TESLA-own 
fields.
Hence, this would mean that, if we apply your proposal (your drawing 
nr 2), then we would have the following:
- there is a "jump" in coverage (since the MKI is not integrity 
protected in SRTP)[although this would not really have any impact 
in terms of implementation]
- what you call "MAC including TESLA MAC" would cover in part itself 
(the TESLA fields). This is not very elegant, although I believe
it has no implementation impact.

Would this two things be acceptable? I think so, maybe they are not 
extremely "elegant", still should have not big implications, as far as I
can see. 

Given these explanations, any preference from you and the msec folk is 
welcome. 

We had another issue to solve with GenArt (Elwyn Davies reviewed the
draft), and your drawing nr 2 much better aligns with the new fix
we have to do (which is, we make the flag for TESLA an IANA registration
within SRTP's identifier for the authentication algorithm transform).

Thanks for your review
cheers
/E

>-----Original Message-----
>From: Colin Perkins [mailto:[email-masked]]
>Sent: den 15 juli 2005 18:00
>To: Mark Baugher
>Cc: [email-masked]; [email-masked]; Elisabetta Carrara
>(AL/EAB); Russ Housley
>Subject: Re: [Fwd: Fwd: Re: Last Call: 'The Use of TESLA in SRTP' to
>Proposed Standard]
>
>
>Mark,
>
>On 14 Jul 2005, at 05:36, Mark Baugher wrote:
>> On Jul 12, 2005, at 1:15 PM, Colin Perkins 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.
>
>Sure, but that's not how the draft is presented. Section 4 states  
>"The present specification is an extension to the SRTP  
>specification", and defines an extra TESLA MAC header field in SRTP  
>before the MKI and MAC fields. Instead of using:
>
>         +-------------+
>         | RTP header  |
>         +-------------+
>         | RTP payload |
>         +-------------+
>         | TESLA MAC   |
>         +-------------+
>         | MKI         |
>         +-------------+
>         | MAC         |
>         +-------------+
>
>I was expecting:
>
>         +---------------+
>         | RTP header    |
>         +---------------+
>         | RTP payload   |
>         +---------------+
>         | MKI           |
>         +---------------+
>         | MAC including |
>         | TESLA MAC     |
>         +---------------+
>
>with the TESLA processing being described as part of the usual MAC  
>processing steps of SRTP, rather than as extra steps. This would seem  
>to be a better fit to the SRTP model, than the addition of extra  
>headers and processing steps.
>
>If there's a good reason for the ordering in the draft, that's fine  
>and just needs explaining. However, the reasoning isn't clear from  
>the draft, making it appear gratuitously different.
>
>Cheers,
>Colin
>
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Mon, 18 Jul 2005 12:02:19 -0700

Elisabetta, Colin
   Thanks to Elisabetta for explaining why we did not make the two 
authentication tags contiguous.  We wanted one tag to cover the other 
(viz. from P.6 of 
http://www.ietf.org/internet-drafts/draft-ietf-msec-srtp-tesla-03.txt),
    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
   |                           timestamp                           | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
   |           synchronization source (SSRC) identifier            | | |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
   |            contributing source (CSRC) identifiers             | | |
   |                               ....                            | | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
   |                   RTP extension (OPTIONAL)                    | | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| |                          payload  ...                         | | |
| |                               +-------------------------------+ | |
| |                               | RTP padding   | RTP pad count | | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |
| |                            i                                  | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~                      Disclosed Key                            ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~                          TESLA MAC                            ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+
| ~                            MKI                                ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~                            MAC                                ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
|                                                                   | |
+- Encrypted Portion                 TESLA Authenticated Portion ---+ |
                                                                       |
                                              Authenticated Portion ---+

SRTP HMAC-SHA1 includes up to the MKI field but does not include MKI.  
We want SRTP-TESLA tag to be covered by the SRTP HMAC-SHA-1 integrity 
check.  SRTP authors decided in our infinite wisdom not to cover the 
MKI field (because it did not need to be covered for SRTP packet 
integrity).  In order to make the two tags (SRTP-TESLA and 
SRTP-HMAC_SHA1) contiguous, we would need to redefine the SRTP 
specification to include the MKI in HMAC-SHA1 coverage.  We don't want 
to do that.

Unfortunately, this looks like a new packet format to people who know 
RTP.  Hence it follows to some that it requires a new profile as did 
SRTP.  But SRTP does not need to have profiles because it is a 
framework that accommodates upgrade (e.g. 256-bit AES, SRTP-TESLA) and 
replacement (e.g. f8 with AES) of authentication and encryption 
transforms, any of which may change the packet format (e.g. a 32-bit 
tag instead of an 80 bit tag).  We made SRTP-TESLA practically 
transparent to SRTP-HMAC-SHA1 processing, and included the TESLA tag in 
the HMAC integrity check (i.e. it is contiguous with the payload 
portion of the packet and easily covered by the integrity-check value). 
  The point of doing the HMAC integrity check is to add an additional 
layer of authentication that prevents non group-members from submitting 
packets to SRTP-TESLA processing as a denial-of-service prevention 
mechanism.

I recommend that we don't make the two authentication tags to be 
contiguous in the packet. Instead, we think of everything beyond the 
end of the application payload as being SRTP and key management stuff 
that are interpreted under a given transform or cipher suite.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Tue, 19 Jul 2005 07:03:57 -0700

Colin
   Yes, I think we need to discuss the nature of the SRTP framework and  
the fact that the SRTP packet can change without requiring a new  
profile.

Mark
On Jul 19, 2005, at 5:46 AM, Colin Perkins wrote:

> Mark,
>
> On 18 Jul 2005, at 20:02, Mark Baugher wrote:
>> Elisabetta, Colin
>>  We want SRTP-TESLA tag to be covered by the SRTP HMAC-SHA-1  
>> integrity check.  SRTP authors decided in our infinite wisdom not to  
>> cover the MKI field (because it did not need to be covered for SRTP  
>> packet integrity).  In order to make the two tags (SRTP-TESLA and  
>> specification to include the MKI in HMAC-SHA1 coverage.  We don't  
>> want to do that.
>>
>> framework that accommodates upgrade (e.g. 256-bit AES, SRTP-TESLA)  
>> and replacement (e.g. f8 with AES) of authentication and encryption  
>> transparent to SRTP-HMAC-SHA1 processing, and included the TESLA tag  
>> in the HMAC integrity check (i.e. it is contiguous with the payload  
>> portion of the packet and easily covered by the integrity-check  
>> value).  The point of doing the HMAC integrity check is to add an  
>> additional layer of authentication that prevents non group-members  
>> from submitting packets to SRTP-TESLA processing as a  
>> denial-of-service prevention mechanism.
>>
> Okay - I'm happy with this. Would it be possible to explain more of  
> this rationale in the draft?
>
> Colin
>