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

From: "Karl Norrman (KI/EAB)" <[email-masked]>
Date: Sun, 18 Dec 2005 17:28:24 +0100

Hello!

> -----Original Message-----
> From: Mark Baugher [mailto:[email-masked]]
> Sent: den 15 december 2005 21:57
> 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 8, 2005, at 8:09 AM, Karl Norrman (KI/EAB) wrote:
> ...
> >>
> >> 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.
> 
> 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.

I completely agree with the above.  However, the solution in 3GPP
uses the approach described in draft-lehtovirta-srtp-rcc-00,
and to avoid future collisions in the MIKEY and SRTP name spaces
it would be good if the IANA registrations in the draft could be done.

This does of course not stop any further work on the MSEC group
key management architecture.

[SNIP]

> > 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.
> 
> There is no cryptographic reason to replace a TEK (SRTP master key)  
> every few seconds, is there?

No, the reasoning in 3GPP that lead to this approach was along the
lines described by Lakshminath in another mail in this thread.

> 
> >
> > 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.
> 
> Was this proven through an analysis, experiment, or deployment?

This was the result of analysis.  Check the examples in the introduction
of the draft (example 2 should be a continuation of example 1, there was
a formatting error.  Sorry about that). 

> 
> 
> > That is why this SRTP
> > centered solution was developed to replace it.
> 
> 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.

It doesn't really.  The TEK rotation is another issue.  If a user joins
an ongoing session close to SEQ wrap around there can be synch problems,
regardless of the TEK rotation (see the examples in the draft).

Regards,
Karl
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: canetti <[email-masked]>
Date: Mon, 19 Dec 2005 14:38:32 -0500 (EST)

I was wondering in which way do you envision the MSEC architecture
be changed.

the MSEC architecture tries to provide separation between the
overall mechanism of initial keying followed by periodic rekeying
on one side, and the actual scheme used for membership management
(eg, LKH, subset-sum, etc) on the other side.

I'd classify the question of whether the member needs to obtain all
past rekeying messages as being a question about the properties of
specific schemes. also, the question of how the member obtains the
rekeying messages is scheme-specific, eg the member can get the
rekeying messages by explicitly pushed messages, or alternatively
the member can pull the rekeying information
from a (suitably replicated) website.

That said, it does sound like a very good idea to standardize one
particular group key management scheme as a "default".
suggestions are welcome...

Ran