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

From: "Karl Norrman (KI/EAB)" <[email-masked]>
Date: Thu, 8 Dec 2005 17:09:53 +0100

Hello!

> -----Original Message-----
> From: Mark Baugher [mailto:[email-masked]]
> Sent: den 7 december 2005 20:35
> 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
> 
> 
> Karl,
> 
> On Dec 7, 2005, at 2:23 AM, Karl Norrman (KI/EAB) wrote:
> 
> > 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.
> 
> 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
> 
> >
> >>
> >> 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).
> 
> 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?

Please see answer at the end of the mail.

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

Section 3.2.1 of RFC 3711 specifies as the first bullet that the ROC
is a transform-independent parameter.  I.e., no matter which transform
is added to SRTP, the ROC is still part of the protocol used in other
places than the encryption.  Some parts of SRTP are not replaceable,
even though SRTP is a framework.

> 
> > 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),
> 
> 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?

If you mean sending the IV with each packet, that can be done.  Note
however, that this would add about 128 bits to each packet, which is
about the same that would be added if the ROC is sent in each packet.

Furthermore, the index (the concatenation of ROC and SEQ) is
used in SRTP by:

* Key derivation
* Replay protection
* Limit of the number of packets that can be protected without re-keying

So even if a new integrity/confidentiality transform is added, that does
not use the index as part of the IV, there are still important parts
of SRTP that are dependent on the ROC.

> 
> > 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).
> 
> I'd be willing to help with this analysis.  It would prove how well  
> we achieved the RFC 3711 goal of implementing a framework.
> >
> >>
> >> 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).
> 
> 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
> > 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).
> 
> Why would you necessarily do the key refresh point-to-point for a  
> broadcast or multicast service?

TS 33.246 delivers the policy on a point-to-point link, but the 
traffic keys are refreshed using mcast/bcast signalling.  The
reason for this is that the TS 33.246 supports use cases where
the TEK is very frequently updated (e.g., every few seconds).
If the policy is sent every time a TEK is delivered, there will
be unnecessary waste of bandwidth.

The TS 33.246 had a solution where the ROC was sent with multicast/broadcast
key management messages, but also in this case an unfortunate packet loss
or delay could still cause ROC to be out of synch.  That is why this SRTP 
centered solution was developed to replace it.

But again, this discussion is centered around TS 33.246 and not
around draft-lehtovirta-srtp-rcc-00.txt.  I can provide you
with links to the discussion papers that have been presented in
3GPP/SA3, where these questions have been analyzed and lead to
the solution that you see in TS 33.246.

Regards,
Karl

> 
> cheers, Mark
> >
> > 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: Thu, 15 Dec 2005 12:56:31 -0800

Karl,

On Dec 8, 2005, at 8:09 AM, Karl Norrman (KI/EAB) wrote:
...
> Please see answer at the end of the mail.

I think the short answer is that multicast key management is either  
perceived or observed not to work properly outside of the data  
stream.  As you point out, the key management is a 3GPP concern and  
not an IETF concern.  So we are left with a situation where a non- 
IETF key management protocol needs changes to an IETF protocol in  
order to work properly.

This is of interest to msec, since the 3GPP experience may call into  
question part of our architecture for group key management.  The msec  
architecture, rightly or wrongly, does not put the keying in the data  
plane.  If we're wrong, that would be a good thing for us to understand.

> even though SRTP is a framework.

I agree that securing the ROC is needed even if we invent encryption  
transforms that have no dependencies on the ROC.
...
> of SRTP that are dependent on the ROC.

I agree.  Properly considered, securing the ROC is a service that  
SRTP provides to RTP sessions.

...
> be unnecessary waste of bandwidth.

There is no cryptographic reason to replace a TEK (SRTP master key)  
every few seconds, is there?

> or delay could still cause ROC to be out of synch.

Was this proven through an analysis, experiment, or deployment?

> That is why this SRTP

What does this say to msec about sending keys separately from the  
media in a broadcast (i.e. large-scale multicast) service?  Maybe  
nothing.  The rapid TEK rotation makes me think that this system is  
more of a conditional access system than a security system.  I'm  
still not entirely clear on why the ROC being carried in (some) RTP  
packets addresses the problems of TEK rotation.

> the solution that you see in TS 33.246.

Thanks for sending the links in a separate note.  I plan to look at  
them soon.

Mark

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 16 Dec 2005 09:52:58 +0200

Mark,

I have some of the same observations as you have.  Please see inline 
for specific comments.

>plane.  If we're wrong, that would be a good thing for us to understand.

Folks active in 3GPP2 also noted that SA synchronization (MSEC term, 
not theirs) is a major issue.  Mobiles may go in and out of coverage 
and may receive encrypted content for which they don't have the 
latest SA/keys.  SA updates sent out of band from data may have been 
sent when the mobile was off or out of coverage.  For that same 
reason LKH would NOT be useful in such environments (Subset 
difference OTOH would work, but the high overhead of course is a concern).

This, I think, call us to rethink MSEC key management architecture a 
bit.  I think we have some notes on SA synchronization in 4046, but 
probably need to start thinking about solutions.

In case of 3GPP2, they send some keying information as part of SRTP packets.

>>* Limit of the number of packets that can be protected without re- keying
>>

Here is the best reasoning I found so far (and no it is not quite 
sufficient to me, but please read on).  Suppose there are two parts 
to a mobile: a terminal and a smartcard.  Assume further that the 
smartcard has secure storage and the terminal doesn't.  The smartcard 
has access to all the long term keys and the terminal is given access 
to the TEK.  It is assumed that the terminal owner may try and share 
the TEK with his/her friends.  To do so, he/she may need to use the 
interactive channel to send the key to the others (say for argument 
sake via SMS).  There is a cost associated with the Broadcast service 
and of course with the SMS service.  If the TEK is changed frequently 
enough to make the cost of sharing the key more than the cost of 
Broadcast service, it might be worthwhile to change the TEK frequently.

(I realize the explanation is along the lines of CAS reasoning, but 
anyway there it is).

Of course if the unicast service usage is not metered, this technique 
is useless.

In closing, the lessons learned from the MSEC perspective is of the 
need for SA synchronization and of the need for stateless 
rekeying.  I think we need to start a concerted effort on mechanisms 
to carry key material as part of secure data encapsulation protocols, 
e.g., IPsec and SRTP.

I'd like to hear others' opinions on this.

thanks and regards,
Lakshminath

>>The TS 33.246 had a solution where the ROC was sent with multicast/ broadcast