Subject: [AVT] RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 6 Mar 2006 15:57:32 +0100

Hi David,

aggreed, backward compatibility would be hard if not impossible.

The assumption was (as far as I understood the DVB scenario), that there is some out of band means to provide the ROC information. The assumption was further that this ROC would be accepted by SRTP for processing. According to the draft the MAC calculation itself is the same as in RFC3711, so this should not pose a problem. The only thing would be the acceptance of the new ROC.

Regards
	Steffen

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David McGrew
> Sent: Monday, March 06, 2006 3:46 PM
> To: Fries, Steffen
> Cc: [email-masked]; Rauschenbach, Uwe; Vesa Lehtovirta 
> (JO/LMF); Jerichow, Anja; [email-masked]
> Subject: Re: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt
> 
> Hi Steffen,
> 
> On Mar 6, 2006, at 1:43 AM, Fries, Steffen wrote:
> 
> > Hi Lakshminath,
> >
> > the reason for asking that question is the following scenario. (It 
> > stems from discusssions regarding OMA and DVB). If you have 
> a device, 
> > that currently supports SRTP and gets the session parameter 
> by other 
> > means (other than MIKEY od sedescriptions) you may break backward 
> > compatibility with those devices while changing the MAC position.
> >
> > If one can ensure that the device gets the right ROC (the 
> righ one is 
> > the one, which would be submitted in the RCC packet) by 
> other means, 
> > and the device does not now about the new integrity 
> transform (because 
> > it is a parameter which is fixed), then the device could verify the 
> > MAC even so it is not aware of a new integrity transform. 
> As far as I 
> > understood the scenario it would keep current DVB devices working.
> >
> > On the other hand, this approach would assume that all "legacy"  
> > terminals use the same algorithm to find the MAC in the message. In 
> > the scenario described above, it would make a difference if 
> one starts 
> > from the beginning or the end of a packet to search for the 
> MAC. But 
> > as you said, the same problem would arise for the legacy terminals 
> > when using EKT, as it adds after the MAC.
> >
> > Hm, it seams that backward compatibility is getting tough 
> ... maybe it 
> > is worth to ask SRTP implementers, what the most used algorithm for 
> > finding the MAC is.
> 
> I suspect that they do it like this:
> 
>      auth_tag = (uint8_t *)hdr + *pkt_octet_len - tag_len;
> 
> where auth_tag is the initial octet of the tag, hdr is a 
> pointer to the start of the RTP header, *pkt_octet_len is the 
> length of the RTP packet in bytes, and tag_len is the 
> expected tag length for that packet (which is predictable 
> because the particular MAC that is being used is determined 
> by the SSRC and the session particulars).
> 
> I'm a bit confused on how RCC could ever achieve backwards 
> compatibility, though.  A "legacy" SRTP implementation would 
> need to know how to correctly verify the MAC and would need 
> to know to  
> discard the ROC value rather than to pass it to the RTP layer.   
> Alternately, the RTP layer could discard the ROC value, but 
> legacy RTP implementations won't do this.  Also, there is the 
> major issue that in RCC only selected packets will be 
> authenticated; I don't see any way to make that work.
> 
> David
> 
> >
> > Regards
> > 	Steffen
> >
> >> -----Original Message-----
> >> From: Lakshminath Dondeti [mailto:[email-masked]]
> >> Sent: Saturday, March 04, 2006 12:54 AM
> >> To: Fries, Steffen; Vesa Lehtovirta (JO/LMF); 
> >> [email-masked]; [email-masked]
> >> Cc: Jerichow, Anja; Rauschenbach, Uwe
> >> Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp- 
> >> rcc-01.txt
> >>
> >> Hi Steffen,
> >>
> >> Just some thoughts on this as WG contributor:
> >>
> >> RCC would be signalled as a new MAC algorithm anyway and 
> that would 
> >> imply that receivers that don't understand the new MAC 
> construction 
> >> would need to decide against joining the secure group.  
> Furthermore, 
> >> if I recall the semantics correctly, the received ROC and not the 
> >> stored ROC would be used in the MAC verification process.
> >>
> >> For those reasons, I don't think the proposed construction is a 
> >> problem.  Your proposal is also ok.  I guess one way to 
> look at it is 
> >> if R is sufficiently high (i.e., RCC packets are infrequent), 
> >> receivers that don't support the new extension can also 
> listen in as 
> >> long as the key management semantics are revised to allow that.
> >>
> >> That said, once again if memory serves me the reason for 
> the current 
> >> design of RCC is to have the MAC at the end.  The EKT work 
> adds new 
> >> payloads at the end, however.
> >>
> >> In conclusion, I think if the RCC extension is to support what you 
> >> propose, we may need to specify the RCC extension to keep the MAC 
> >> algorithm the same and signal the extension differently.
> >>
> >> regards,
> >> Lakshminath
> >>
> >> At 07:28 AM 3/3/2006, Fries, Steffen wrote:
> >>>  Hi Vesa,
> >>>
> >>> I just read your draft regarding the SRTP/MIKEY extension.
> >> It is a good
> >>> enhancement to transmit the ROC in parts pof the SRTP payload.
> >>> Nevertheless, I have a comment/question to the transform
> >> described in
> >>> section 2. It is stated that TAG = ROC_sender || MAC. What is the 
> >>> reason that the TAG is constructed in that way, rather than
> >> TAG = MAC
> >>> || ROC_sender?
> >>>
> >>>> From my point of view there is an advantage
> >>> for the latter case. This approach would provide a better 
> backward 
> >>> compatibility for terminals which are not aware of the SRTP
> >> extension
> >>> you are describing. If they get the ROC information by 
> other means 
> >>> (e.g., seperate
> >>> messages) there still would be able to handle the MAC 
> verification 
> >>> correctly, as the MAC starts at the same position as described in 
> >>> RFC3711. When inserting the ROC before the MAC in the 
> packet, older 
> >>> terminaly would take a part of the ROC as MAC, which 
> would lead to 
> >>> errors in the MAC verification.
> >>>
> >>> Would it influence the security in any way by choosing the
> >> TAG = MAC ||
> >>> ROC_sender?
> >>>
> >>> Regards
> >>>         Steffen
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] 
> >>>> [mailto:[email-masked]] On Behalf Of Vesa 
> >>>> Lehtovirta (JO/LMF)
> >>>> Sent: Tuesday, February 14, 2006 3:31 PM
> >>>> To: [email-masked]; [email-masked]
> >>>> Cc: Magnus Westerlund (KI/EAB)
> >>>> Subject: [MSEC] FW: Submission of 
> draft-lehtovirta-srtp-rcc-01.txt
> >>>>
> >>>> Dear all,
> >>>>
> >>>> Forwarding on behalf of Karl.
> >>>>
> >>>> -----Original Message-----
> >>>> From: Karl Norrman (KI/EAB)
> >>>> Sent: 13. helmikuuta 2006 18:04
> >>>> To: [email-masked]
> >>>> Cc: Vesa Lehtovirta (JO/LMF); Mats Näslund (KI/EAB)
> >>>> Subject: Submission of draft-lehtovirta-srtp-rcc-01.txt
> >>>>
> >>>> Dear Editor,
> >>>>
> >>>> Please submit the new version of 
> draft-lehtovirta-srtp-rcc-01.txt.
> >>>>
> >>>> Best Regards,
> >>>> Karl Norrman
> >>>> Ericsson
> >>>>
> >>> _______________________________________________
> >>> 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
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: David McGrew <[email-masked]>
Date: Mon, 6 Mar 2006 11:24:13 -0800

Hi Steffen,

On Mar 6, 2006, at 6:57 AM, Fries, Steffen wrote:

> The assumption was (as far as I understood the DVB scenario), that  
> there is some out of band means to provide the ROC information. The  
> assumption was further that this ROC would be accepted by SRTP for  
> processing. According to the draft the MAC calculation itself is  
> the same as in RFC3711, so this should not pose a problem. The only  
> thing would be the acceptance of the new ROC.
>

I'm not familiar with the specifics of the DVB scenario, but I do  
like the idea of using heuristic methods to estimate the ROC (at  
least whenever there is some way for the receiver to discern good  
guesses from bad guesses).

I've just finished writing up my thoughts on ROC synchronization  
methods, which I've put online at http://www.mindspring.com/~dmcgrew/ 
roc.txt.  It includes a few recommendations centered around the use  
of heuristics.  I'd be interested to hear your thoughts.

Best regards,

David

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 07 Mar 2006 04:31:09 -0800

At 06:57 AM 3/6/2006, Fries, Steffen wrote:
>The assumption was (as far as I understood the 
>DVB scenario), that there is some out of band 
>means to provide the ROC information. The 
>assumption was further that this ROC would be 
>accepted by SRTP for processing. According to 
>the draft the MAC calculation itself is the same 
>as in RFC3711, so this should not pose a 
>problem. The only thing would be the acceptance of the new ROC.

Hi Steffen,

A couple of notes.  First, as I noted before I 
share the backward compatibility issues that 
David raised.  It might be worthwhile to see if 
there is a way to signal things to help legacy terminals.

Next, the RCC draft does specify a different way 
of computing the MAC.  3711 refers to using the 
locally maintained ROC to compute the MAC.  In 
RCC and in EKT there is a "trial" phase where the 
received ROC is used to derive the integrity key 
and that key is used for MAC verification.  If 
that succeeds, the received ROC replaces the 
local ROC and everything proceeds from there.  If 
the verification fails of course, the received 
ROC and the packet are discarded.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 07 Mar 2006 04:34:27 -0800

Hi David,

I had a chance to quickly read your paper on ROC 
synchronization.  You've talked about some of the techniques before, 
but I see some more new ideas there and they seem very 
interesting.  Your note about effective MAC strength when multiple 
ROC values are tried out is interesting.  Does that apply even if the 
receiver doesn't report on whether the verification succeeded or 
failed?  Does it apply if an adversary has no way of knowing how many 
values a receiver might try?

Thanks again for sharing your analysis and new ideas on this.

best,
Lakshminath

At 11:24 AM 3/6/2006, David McGrew wrote:

>methods, which I've put online at 
>http://www.mindspring.com/~dmcgrew/ roc.txt.  It includes a few 
>recommendations centered around the use

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 08 Mar 2006 13:07:31 -0800

David,

Just on the ROC synchronization topic:

Taking the DTLS stuff into account, we might call it a long IV 
maintenance based on a short IV or something like that. :-)  In any 
event, point being, IIRC, one of the DTLS specs suggests trying out 
as many sequence numbers that a replay window allows.  I may have 
misinterpreted that (waiting for clarifications, Eric is working on 
responding soon).  If indeed that's the case, a 64-bit window could 
reduce the MAC strength by 6 bits.  (they have other issues due to 
the authenticate and then encrypt nature of TLS encapsulation, but 
that's another story).

regards,
Lakshminath

At 12:52 PM 3/8/2006, David McGrew wrote:
>Lakshminath,
>
>I didn't do a whole lot of analysis about this case because I favor
>the "try one ROC value for each packet" approach (it's easy to
>implement on an embedded system that uses a bounded number of cycles
>to process each packet).  I think that the effective MAC strength
>holds in the cases that you mention, but if someone is really
>interested in pursuing that approach, let's do a more detailed analysis.
>
>David
>
>>
>>>methods, which I've put online at http://www.mindspring.com/ 
>>>~dmcgrew/ roc.txt.  It includes a few recommendations centered
>>>around the use

---

From: David McGrew <[email-masked]>
Date: Wed, 8 Mar 2006 12:52:16 -0800

Lakshminath,

On Mar 7, 2006, at 4:34 AM, Lakshminath Dondeti wrote:

> Hi David,
>
> I had a chance to quickly read your paper on ROC synchronization.   
> You've talked about some of the techniques before, but I see some  
> more new ideas there and they seem very interesting.

thanks.

> Your note about effective MAC strength when multiple ROC values are  
> tried out is interesting.  Does that apply even if the receiver  
> doesn't report on whether the verification succeeded or failed?   
> Does it apply if an adversary has no way of knowing how many values  
> a receiver might try?

David