[VOIPSEC] SRTP rekeying in the real world

[Mark Baugher]

Hello,
On Oct 13, 2006, at 7:39 AM, Waters Geoffrey-ra6722 wrote:

> Hello,
>
>     I'm looking for information related to SRTP rekeying  
> synchronization
> which multiple readings of RFC3711 didn't resolve for me.
>
> If a video on demand (VOD) application is considered with the  
> following
> configuration
>
> -          one sender (SRTP Tx stream, SRTCP Tx stream), one receiver
> (SRTP Rx stream, SRTCP Rx stream)
>
> -     SRTP and SRTCP streams have different SSRCs, but are using the
> same master key

I don't understand what you mean by the above.  Of course they are  
using the same master key but why would the SRTP SSRC differ from the  
SRTCP SSRC for a given source?


>
> -          re-key is based on the first stream using the master key to
> detect a key lifetime limit has been reached

RFC 3711 has no MUSTs, SHOULDs or MAYs regarding rekey or any key  
management function, as explained in Section 8 of the RFC.  So are  
you saying that the policy is to rekey when a key lifetime is  
reached, or crosses some value threshold?

>
>
>
> When the 'To' is reached in the <From, To> range, the SRTP Tx stream
> begins using a new master key. Suppose that around the same time that
> the SRTP packet is received by the receiver, the receiver sends an  
> SRTCP
> packet. How does the sender know if the old or new master key is being
> used by the receiver generated SRTCP packet? SRTCP index?

I'd recommend that you use an MKI rather than from-to.

> Does the
> sender need to support both master keys for a certain amount of  
> time? If
> both master keys need to be supported for a certain amount of time,  
> for
> how long?

The sender can switch to a new key and securely delete the old, but  
the receivers need to keep two keys around, the current key and the  
next key.  Once the next key is made the current key, the previous  
current key must be retained for out-of-order packets.

>
>
>
> If the MKI method was used for re-keying instead of the <From, To>
> method, the SRTP packet would include the MKI field. Does the  
> choice to
> use MKI in the SRTP stream guarantee that the MKI will be used in the
> SRTCP stream?

Yes, see Figure 2 in RFC 3711.
>
>
>
> If anyone knows of a 'SRTP Rekeying Issues' document, similar to the
> excellent IKE/IPSec rekeying document (Draft-Jenkins), I'd very much
> appreciate a pointer to it.

MIKEY (RFC 3830) defines how to do rekeying as does SDP Security  
Descriptions (RFC 4568).  So you need to pick a key management  
system.  There is also a third in the making, DTLS.

>
>
>
> Encrypted Key Transport for Secure RTP (draft-mcgrew-srtp-ekt-01) is
> tackling the signalling issues associated with SRTP/SRTCP key
> switch-over, but existing systems must be dealing with SRTP/SRTCP key
> linkage and switch over issues some other way.

Exactly.  EKT says how to use one existing system, SDP security  
descriptions, to establish its group key.  MIKEY needs to do the same  
as does GDOI (RFC 3547).

> Are SRTCP streams
> getting their own SSRCs to avoid linkage issues?

Sure.  That's how SRTCP works.  It's also how RTP and RTCP works in  
RFC 3550.

Cheers, Mark
>
>
>
> Regards,
>
>
>
> Geoff Waters
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org