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

srtp_create fails if setting up RTP encryption with AES-128-GCM and not specifying RTCP encryption #642

Open
Tracked by #669
fquiers opened this issue Feb 27, 2023 · 2 comments

Comments

@fquiers
Copy link

fquiers commented Feb 27, 2023

Please note that this is not necessarily an issue with the library. It could be that my understanding of the API is incorrect instead.

I modified the example code in order to set up RTP encryption as AES-128-GCM (I'm using Openssl 1.1.1t) with a 28-byte key, and leaving the RTCP policy unspecified/default.

/*
uint8_t key[30] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
                   0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
                   0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
                   0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D};
*/
uint8_t key[28] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
                   0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
                   0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
                   0x18, 0x19, 0x1A, 0x1B};
//[...]
/*
srtp_crypto_policy_set_rtp_default(&policy.rtp);
srtp_crypto_policy_set_rtcp_default(&policy.rtcp);
*/
srtp_crypto_policy_set_from_profile_for_rtp(&policy.rtp, srtp_profile_aead_aes_128_gcm);

When doing this, srtp_create() returns srtp_err_status_bad_param.

After some investigation, I found that the logic introduced in PR #589 was the reason for this result, because we end up with the following values at the point of the newly added check:
rtp_keylen = 28
rtcp_keylen = 0
input_keylen = 30

I think this is because in this case, the RTCP cipher is effectively left as null, and therefore full_key_length() returns:
SRTP_AES_ICM_128_KEY_LEN_WSALT = 14 + 16 = 30
...which is larger than:
SRTP_AES_GCM_128_KEY_LEN_WSALT = 12 + 16 = 28.

I wonder if the logic could/should be modified in order to take this use case into account? I'm thinking in particular about a scenario where RTP is encrypted but RTCP is not.

Alternatively, is the correct way to use the API to always call both _set_rtp_default() and _set_rtcp_default() as a pair, even for a case where RTCP is not encrypted (in which case, which srtp_profile_t should be passed to _set_rtcp_default()?
Thank you.

@pabuhler
Copy link
Member

Hi @fquiers, I think it is a bug / inconvenient behavior in that we should support rtp only for the cases where there is no rtcp without have to create and rtcp profile. Saying that though I do not know how often that is a actual use case.

It is import though in the case of SRTP to understand that "unencrypted" RTCP is supported but even though it is unencryoted it still should be authenticated, see https://www.rfc-editor.org/rfc/rfc3711#section-3.4 "Message authentication for RTCP is REQUIRED", so therefore if you have rtcp in you media session you must set up a rtcp profile for the policy but you can change the sec_serv of the policy to be sec_serv_auth . Did that make sense?

We could probably make this setup more intuitive, but that is a 3.0 ask.

@fquiers
Copy link
Author

fquiers commented Mar 14, 2023

Thank you @pabuhler for your answer. I will look into your point regarding mandatory RTCP authentication.

I guess we can keep this ticket open for a future 3.0 release for providing a resolution for the (somewhat hypothetical) use case of not having any RTCP stream. Thanks!

@fquiers fquiers mentioned this issue Jan 31, 2024
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

2 participants