Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling Master Key Lifetime #588

Open
Tracked by #669
aza547 opened this issue Dec 1, 2021 · 2 comments
Open
Tracked by #669

Handling Master Key Lifetime #588

aza547 opened this issue Dec 1, 2021 · 2 comments
Milestone

Comments

@aza547
Copy link

aza547 commented Dec 1, 2021

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 pabuhler added this to the Version 3.0 milestone Dec 10, 2021
@pabuhler
Copy link
Member

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
Copy link
Contributor

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.

@pabuhler pabuhler mentioned this issue Dec 21, 2023
16 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants