Handling Master Key Lifetime

[aza547]

Hi,

Wondering if enforcing the master key lifetime is something that libsrtp supports, I've had a search and haven't found the answer - apologies if I'm missing something obvious.

Section 6.1 in RFC 4568 (https://datatracker.ietf.org/doc/html/rfc4568#section-6.1) states:

   The second field is the OPTIONAL lifetime of the master key as
   measured in maximum number of SRTP or SRTCP packets using that master
   key (i.e., the number of SRTP packets and the number of SRTCP packets
   each have to be less than the lifetime).  The lifetime value MAY be
   written as a non-zero, positive decimal integer or as a power of 2
   (see the grammar in Section 9.2 for details); leading zeroes MUST NOT
   be used.

...referring to the form:

inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:4

Is there a way to configure an SRTP policy with this information?

Thanks,
Alex

[pabuhler]

Hi @alexanderkershaw to me it looks like there was some thought for this but it was never really exposed.
There are error codes and events like srtp_event_t (event_key_soft_limit, event_key_hard_limit) and srtp_err_status_key_expired but the limit is currently hard coded with "srtp_key_limit_set(session_keys->limit, 0xffffffffffffLL);" .
Adding it to the policy would definitely make sense but that would break existing code, we should definitely add this to the policy when we can. Another option in the mean time would be to add a function to set it for a given key. PR's welcome :)

[bifurcation]

Yeah, the current key lifetime tracking is broken in a couple of ways. In addition to always setting the limit to 0xffffffffffffffff, there's a problem with streams derived from template streams: Key limits are cloned instead of shared, so even though the same key is being used on each cloned stream, it will only be expired if it hits its limit on a particular stream.