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

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 6 Mar 2006 10:43:20 +0100

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. 

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

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

---

From: David McGrew <[email-masked]>
Date: Mon, 6 Mar 2006 06:45:58 -0800

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