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

From: "Karl Norrman (KI/EAB)" <[email-masked]>
Date: Mon, 5 Dec 2005 13:35:53 +0100

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

---

From: Mark Baugher <[email-masked]>
Date: Mon, 5 Dec 2005 07:08:36 -0800

hi
   I have a lot of comments that have to do with SRTP's cipher,  
modes, and security.  Before posting these comments, I wonder if we  
should post to both lists or just to msec?

Mark

---

From: Mark Baugher <[email-masked]>
Date: Mon, 5 Dec 2005 07:39:04 -0800

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.

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.

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

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.

These are two-way networks, are they not?

cheers, Mark