Subject: RE: [MSEC] Synchronization of SRTP roll-over counter

From: "Karl Norrman (KI/EAB)" <[email-masked]>
Date: Wed, 7 Dec 2005 11:23:52 +0100

Hello!

Thanks for the comments.  Please see answers inline.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mark Baugher
> Sent: den 5 december 2005 16:39
> To: Karl Norrman (KI/EAB)
> Cc: Vesa Lehtovirta (JO/LMF); AVT Lista; Mats Näslund (KI/EAB); msec
> Subject: Re: [MSEC] Synchronization of SRTP roll-over counter
> 
> 
> I'm glad that the Ericsson team and 3GPP have gotten to apply 
> SRTP to  
> broadcast.  We are missing a concise statement of the security  
> requirements in the document, however, though I see that there are a  
> few appendices in the accompanying 3GPP document.  Still, there are  
> things proposed or assumed in this document that warrant discussion.

Assuming you are discussing the 3GPP specification TS 33.246, 
this is probably not the right forum for discussing the 
requirements for the MBMS security solution. They should be 
raised in 3GPP groups.

> 
> The "trust model" appendix in the 3GPP Microsoft Word file is vague,  
> and it is therefore difficult to assess the no-integrity mode 
> that is  
> supported by this document.  There are also some assumptions that  
> need review, such as why it is better to greatly increase the  
> complexity of the media security protocol rather than increasing the  
> complexity (or frequency) of key management or simply changing the  
> cipher.

There was a proposal sent to 3GPP/SA3 that suggested sending the 
highest bit of the sequence number in key management messages.  That 
one did, however, not give a completely robust solution (packet loss 
could still get the receiver out of synch).

> 
> Regarding the cipher, why not change it to use a mode that does not  
> have a cryptographic dependency on the ROC?

Since 3GPP/SA3 decided to use SRTP as of RFC3711, the session keys 
are, as you know, derived from the index = ROC || SEQ and other 
parameters.  Removing the dependency of the ROC would also imply shortening 
the maximum number of packets that can be protected by the same key to 
2^{16} (since the index is part of the IV), and (in my opinion) the index
is such a fundamental part of SRTP, that the remaining part after removing it
would require a complete security analysis of SRTP again.  (Not to mention, 
we would have a specific 3GPP-SRTP and one IETF-SRTP).

> 
> Regarding assumptions about key management, all five of the reasons  
> advanced in the Introduction of draft-lehtovirta-srtp-rcc-00.txt for  
> this feature would be unneeded if a key management refresh operation  
> were performed.

Refreshing keys is allowed by TS 33.246.  Unfortunately, refreshing 
the security policy (including ROC) is far from free (especially in a
radio environment).  Opening a point-to-point link and delivering the 
policy to each and every user of a big group is a heavy operation 
(note that the point-to-point radio bearer may not be "always on", 
and setting it up requires some signalling).

Regards,
Karl

> 
> These are two-way networks, are they not?
> 
> cheers, Mark
> 
> On Dec 5, 2005, at 4:35 AM, Karl Norrman (KI/EAB) wrote:
> 
> > Hello!
> >
> > 3GPP has a service for multicast and broadcast distribution of data
> > called MBMS (Multimedia Broadcast/Multicast Service)
> > [http://www.3gpp.org/ftp/Specs/archive/33_series/ 
> > 33.246/33246-640.zip].
> >
> > This service uses SRTP for protection of media streams.
> > To achieve robust synchronization of late joiners to a session,
> > 3GPP has agreed on a mechanism that transports the SRTP roll-over
> > counter (ROC) in SRTP packets using the integrity transform hooks.
> >
> > To avoid collisions with IANA registered values in the future,
> > we would like to describe the transform in an IETF RFC and register
> > the required values with IANA.  The mechanism and the associated
> > IANA registrations are defined in draft-lehtovirta-srtp-rcc-00.txt
> > [http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp- 
> > rcc-00.txt].
> > Comments on the draft are very welcome.
> >
> > Since MBMS is close to finalization, we would like to send the draft
> > to IESG for approval before the end of 2005.
> >
> > Regards,
> > Karl
> > _______________________________________________
> > 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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 7 Dec 2005 11:35:07 -0800

Karl,

> requirements for the MBMS security solution. They should be

I'm referring to the document that you pointed to in your note to  
these lists: http://www.3gpp.org/ftp/Specs/archive/33_series/ 
33.246/33246-640.zip

> could still get the receiver out of synch).

I don't understand why we would send the highest bit of the sequence  
number in key management messages.  Why not run a key management  
exchange at the time that broadcast reception commences or  
periodically based on the rate of session packets relative to the  
sequence number space?  Better still, why not multicast or broadcast  
the key management messages?
> Since 3GPP/SA3 decided to use SRTP as of RFC3711,

RFC 3711 claims to be a framework.  It's a framework because we might  
want to specialize the cipher, mode or other transforms based on  
different application needs.  I have been working under the  
assumption that broadcast applications have much different  
requirements than VOIP.  So if we can't use the framework design of  
SRTP for these two diverse applications, I don't know when we would.

> the session keys
> 2^{16} (since the index is part of the IV),

That's if you don't change the cipher mode, but that's precisely what  
I suggested be changed.  What if we changed it to "randomized counter  
mode" for this application?

> and (in my opinion) the index

I'd be willing to help with this analysis.  It would prove how well  
we achieved the RFC 3711 goal of implementing a framework.
> radio environment).

The only part of the security policy that we want to refresh here is  
the ROC and that is six bytes long.

> Opening a point-to-point link and delivering the

Why would you necessarily do the key refresh point-to-point for a  
broadcast or multicast service?

cheers, Mark