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

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 9 Mar 2006 09:23:08 +0100

Hi Lakshminath, hi Dave,

okay, to summarize my thoughts:

In a scenario were RCC is used and within a message were SEQ is equal to 0 modulo some non-zero integer constant R the ROC is transmitted as ROC_sender || ROC, there may be problems with legacy terminals even if they get the actual ROC value on a different channel. (Let's assume you have another channel over which the ROC can be sent. Let's further assume you can force the legacy terminal to accept and use the received ROC).
The legacy terminal may not be able verify the MAC as it does not use the correct ROC value for calculation. Even if it has the correct ROC value available, there are problems as:
- if TAG = MAC || ROC_sender will lead to the case that the teriminal will (with a high propability) search for the MAC from the end, thus interpreting the ROC_sender and a part of the MAC as the actual MAC. The result will be different than the transmitted MAC.
- if TAG = ROC_sender || MAC would be fine in finding the MAC from the end
BUT, in both cases, the terminal would calculate the MAC value according to the RFC3711 integrity transform using the authenticated portion || local ROC value. The authenticated portion would comprise more than the data actually expected for the integrity transform. Thus, in both of the above cases the terminal would calculate the wrong MAC for this dedicated message. 
After that packet failed all further packets should be verified correctly, until the nect RCC packet is received. Does this match your point of view as well?

David, I read you document regarding the ROC synchronization. I like the idea of the heuristic approach as I think the method is easy to implement and may also have acceptable influence on speech clipping. The method itself may be succeptable to some kind of DoS atacks, were an adversary sends forged packets to the RTP port, were SRTP data is expected to be received. As the receiver is not able to verify the received packets without having the right ROC, it may stay desynchronized, when the ROC iteration is done just once per packet. But even if ROC iteration is done on a single packet, it may be the one received from the adversary. (I'm not sure about the applicability of this attack.)

Regards
	Steffen

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Lakshminath Dondeti
> Sent: Tuesday, March 07, 2006 1:31 PM
> To: Fries, Steffen; David McGrew
> Cc: Jerichow, Anja; Rauschenbach, Uwe; [email-masked]; Vesa 
> Lehtovirta (JO/LMF); [email-masked]
> Subject: RE: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.txt
> 
> At 06:57 AM 3/6/2006, Fries, Steffen wrote:
> >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.
> 
> 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
> 
> 
> >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
> > >
> >_______________________________________________
> >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