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

[fquiers]

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]

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]

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!