Proposal to add support for RFC 7714 SRTP with AES-GCM

[jcbeaulieu]

Proposal for cryptographic algorithm negotiation to add support for RFC 7714 SRTP AES-GCM.

Reason:
EU governments will start forbidding SHA-1 starting 2025 December 31.
RFC 3711 defines an 80 bit SHA-1 authentication tag, which will be forbidden.
Using AES-CM (Counter Mode) without an authentication tag is insecure and forbidden by FIPS.

Compatibility analysis:
Devices that do not support the feature will not include the SecureRTSPStreamingAlgorithms in the StreamingCapabilities.
Clients that do not support the feature will not include the SecurityProtocolAlgorithm the GetStreamUri.
When either a client or device does not support the feature, AES-128-CM-SHA1_80 is implied. (As defined in RFC 3711).

[HansBusch]

Adding support for multiple signature algorithm is a good idea.

However the proposal has two issues:
Minor: for backward compatibility reasons SecureRTSPStreamingAlgorithms may not be present for old devices.
Major: Inserting a parameter is a breaking change. We have never appended a parameter. Doing so would need a compatibility assessment.

[jcbeaulieu]

Adding support for multiple signature algorithm is a good idea.

However the proposal has two issues: Minor: for backward compatibility reasons SecureRTSPStreamingAlgorithms may not be present for old devices. Major: Inserting a parameter is a breaking change. We have never appended a parameter. Doing so would need a compatibility assessment.

The proposal has changed significantly since. There are now no changes to the StreamingCapabilities.

[sirzooro]

This approach is not RFC-compliant, RFC 4567 explicitly forbids using multiple a=key-mgmt attributes in section 4.2:

Note that only one key management protocol SHALL be used per session/media level.

Few possible alternatives which better follows RFCs:

• add additional security profile(s) to initiator's MIKEY message, which are not referenced from SRTP-ID map in HDR payload. Client would have to select one of them and update policy number SRTP-ID map in HDR payload sent in SETUP request. Some extra SDP attribute and/or General Extension MIKEY payload would be needed to tell client do to so. Server also would have to send TGK instead of TEK to allow client to generate key of proper length;
• use GENERIC-ID map from RFC 6043 instead of SRTP-ID map, it allows security profile negotiations;
• use approach from RFC 7826 where client sends initiator's message in SETUP request. It would also need way to discover available security profiles via some ONVIF query.

BTW, MIKEY protocol can be used in different ways. Existing RTSP implementations with SRTP support use in are not compatible with each others and have some details wrong (send concatenated key and salt as TEK instead of separate as TEK+SALT). I listed all discovered differences here: #436 . Make sure to review them and add necessary clarifications here to avoid ambiguities and incompatible implementations in the future.

[jcbeaulieu]

Thank you, we will revise the proposal.

[sirzooro]

Few more thoughts about this:

• You can define new tag for Require header, so RTSP server will know that it has to do something in non-standard way;
• You can define new SDP attribute for key management, e.g. a=onvif-key-mgmt, and define that initiator's MIKEY message has to use GENERIC-ID map instead of SRTP-ID in HDR like I suggested earlier. RTSP server could also send both a=key-mgmt and a=onvif-key-mgmt in SDP, so it would be backward-compatible with RTSP clients which does not support ONVIF too;
• Define procedure for rekeying. RFCs for RTSP 1.0 and 2.0 do not define it. In RTSP 1.0 where server is an initiator something new has to defined. In RTSP 2.0 initiator is client, so rekeying is implicitly defined - client can send SETUP request to update transport parameters, so it could also use it to perform rekeying as specified in MIKEY RFCs.

Please also check how Genetec handles SRTP. It has its own extension to ONVIF for this, and performs key exchange in RTSP 2.0 way (client is initiator) while using RTSP 1.0 headers. It also specifies rekeying procedure.

[kieran242]

@jcbeaulieu is this still in rework?

[jcbeaulieu]

@kieran242, Yes, I wanted to discuss it during the meeting.
I believe the best option would be moving the negotiation in ONVIF wsdls again.

[jcbeaulieu]

We've changed the proposal to configure the algorithm negotiation in ONVIF itself.
The capabilities have been added back into GetServiceCapabilities through SecureRTSPStreamingAlgorithms.
This should be possible since StreamingCapabilities defines the any parameter.

For GetStreamUri, no any parameter has been defined, so a GetStreamUri2 has been added.
The none algorithm has been added in case a camera does not wish to support video encryption.
Using RTSPS without SRTP increases security over RTSP since camera credentials are sent over HTTP in digest (md5) which is insecure.

@sirzooro, I've added clarification that the MKI must be used and an example for session opening.
I also plan on adding an example for key updates sent from the client to the device.
For the MIKEY modes, In RFC 3830 I have not found that supporting MIKEY-PK is mandatory. Could you link to the section and quote the sentence? I was planning on adding clarification that MIKEY-PSK is the only mandatory algorithm and that RTSPS (TLS) is mandatory for SRTP.
For the other points listed in #436 that I have not addressed here, could you link to the section of the RFC with a quote?

[sirzooro]

@jcbeaulieu RFC 3830 at the end of sections 3.1 (PSK) and 3.2 (PK) have sentence "It is MANDATORY to implement this method." Also keep in mind that PSK was intended to send keys in encrypted format. MIKEY-NULL is a special case of MIKEY-PSK. Some note that we do not use encryption and authentication intentionally would be good.

SSRC=0: section 6.1.1 of RFC 3830 contains this:

  Note that it is the sender of the streams that
  chooses the SSRC.  Therefore, it is possible that the Initiator of
  MIKEY cannot fill in all fields.  In this case, SSRCs that are not
  chosen by the Initiator are set to zero and the Responder fills in
  these fields in the response message.

Key type sent in Key - Table 6.13.a in RFC 3830 specifies both TEK and TEK+SALT versions, so TEK+SALT seems better choice to send key and salt, instead of concatenating them and send as TEK. GStreamer internally concatenates them, so maybe someone just sent them both as-is as TEK.

General Extension Payload with SDP IDs type probably is not an issue. As RTSP allows to use only one key management protocol, bidding-down attack cannot be performed as described in RFC 4567.

[jcbeaulieu]

Hello @sirzooro, For section 3.2 of RFC3830, I would like to explicitly propose in the streaming document that MIKEY-PK should not be used for ONVIF. MIKEY-PSK and initiation of SRTP should only be done using RTSPS, which would protect the key. I worry that implementing MIKEY-PSK would be a waste of time since:

1. As far as I know, all or most ONVIF certified SRTP compatible cameras should already support MIKEY-PSK. (Since this is what is used in Genetec Security Center)
2. The algorithms currently used by MIKEY-PK (RSA?) may be obsoleted in a few years (?) with implementation details on using replacement algorithms are currently undefined. (ML-KEM).

For MIKEY-NULL , it seems like it should only be used for SIP. "Note that this MUST NOT be used unless
the underlying protocols can guarantee security. The main reason for
including this is for specific SIP scenarios, where SDP is protected
end-to-end." - Section 4.2.3 RFC 3830. Instead of supporting MIKEY-NULL, I propose to add a "None" option to the Supported encryption algorithms which would make the device return an RTP/AVP media instead of RTP/SAVP. This would allow for the use of HTTPS for session initiation and authentication, when media encryption is not supported.

Would these proposals be acceptable?

For the MIKEY key data sub-payload, I know that Genetec uses TEK only and that many devices work with TEK.
For AES-GCM in RFC7714, section 12 defines a master salt length of 96 bits, which according to section 6.13.b of RFC 3380, is the mikey salt len and salt data.
So this is what would be mandated when using AES-GCM if I understood the spec correctly.

[sirzooro]

Hello @sirzooro, For section 3.2 of RFC3830, I would like to explicitly propose in the streaming document that MIKEY-PK should not be used for ONVIF. MIKEY-PSK and initiation of SRTP should only be done using RTSPS, which would protect the key. I worry that implementing MIKEY-PSK would be a waste of time since:

1. As far as I know, all or most ONVIF certified SRTP compatible cameras should already support MIKEY-PSK. (Since this is what is used in Genetec Security Center)
2. The algorithms currently used by MIKEY-PK (RSA?) may be obsoleted in a few years (?) with implementation details on using replacement algorithms are currently undefined. (ML-KEM).

I am OK with a note in ONVIF spec that MIKEY-PK is not supported.

SRTP adoption in ONVIF cameras is not very common now - I did some research about year ago and at that time I was able to find some public documentation about Axis, Bosch and Hikvision cameras only. Probably other brands relied on media tunneling over SRTSP or RTSP/HTTPS to provide encryption. Incompatible implementations of open source clients also supports claim that SRTP in RTSP was/is not popular option.

For MIKEY-NULL , it seems like it should only be used for SIP. "Note that this MUST NOT be used unless the underlying protocols can guarantee security. The main reason for including this is for specific SIP scenarios, where SDP is protected end-to-end." - Section 4.2.3 RFC 3830. Instead of supporting MIKEY-NULL, I propose to add a "None" option to the Supported encryption algorithms which would make the device return an RTP/AVP media instead of RTP/SAVP. This would allow for the use of HTTPS for session initiation and authentication, when media encryption is not supported.

The key part here is "Note that this MUST NOT be used unless the underlying protocols can guarantee security". RTSP over TLS (RTSPS) provide it. Genetec docs also says something similar, that TLS is used so additional encryption and authentication of data in Key payload is not needed. So please add note in ONVIF spec that full MIKEY-PSK is not supported and MIKEY-NULL is used because TLS is used. Also please add requirement that use of SRTP and MIKEY key exchange require use of SRTCP or tunneling over secure protocol (RTSP over HTTPS).

"None" option may be useful like you wrote. Please add clarification that it means plain RTP and not NULL SRTP cipher - with latter one server still has to send MKI and authentication tag for SRTP, and use encryption/MKI/AuthTag with SRTCP. Current wording is a bit misleading here.

Would these proposals be acceptable?

For the MIKEY key data sub-payload, I know that Genetec uses TEK only and that many devices work with TEK. For AES-GCM in RFC7714, section 12 defines a master salt length of 96 bits, which according to section 6.13.b of RFC 3380, is the mikey salt len and salt data. So this is what would be mandated when using AES-GCM if I understood the spec correctly.

What is unclear here is whether key and salt should be sent using TEK+SALT format (Type field set to 3, key and salt in separate fields in Key payload), or using TEK (Type field set to 2, key and salt concatenated and sent in Key data field). Please add note which one should be used.

[jcbeaulieu]

Edit: There seems to be an issue with formatting. I've added formatted pictures:

To recap:

1. For wsdl changes for AES-GCM:
   a. SecureRTSPStreamingAlgorithms will be added to the StreamingCapabilities of the GetServiceCapabilitiesResponse. This should work since StreamingCapabilities has an any field.
   b. GetStreamUri2 will be created with an any field. It will also include a SecurityProtocolAlgorithm with is one of the listed SecureRTSPStreamingAlgorithms.

2. For the Streaming specification document changes:
   a. Base SRTP using the old method (AES_CM_128_HMAC_SHA1_80) will be clarified using the specs of the Genetec SRTP whitepaper. This is already supported by Axis, Bosch, Hanwha, i-Pro and Vivotek devices.
   i. Encryption algorithm: AES-CM, master key length: 128 bits, master key salt: 112 bits, authentication algorithm: HMAC-SHA1, authentication key length: 160 bits, authentication tag length: 80 bits, mki length: 32 bits
   ii. The MKI is mandatory on all SRTP packets
   iii. SSRC must be defined in the transport header of a SETUP response as described in RFC 2326 Section 12.39.
   iv. Identifying key frames without decryption:
   1. First packet of every key frame should have a header extension as defined in RFC 5285. The extension profile shall be 0xBEDE and the payload shall be 0xE0050000.
   2. If the first packet of a key frame already includes a header extension, an empty RTP packet containing the key frame header extension shall be inserted right before the actual first packet in the frame. This empty packet is considered part of the frame so it must have the same RTP timestamp as the rest of the frame and must not be marked.
   v. MIKEY (RFC 3830) is used for key management.
   1. MIKEY-PSK must be supported
   2. MIKEY-PK support is optional, contrary to what is mandated in RFC 3830, due to obsolescence concerns.
   3. MIKEY payloads:
   a. Common header payload: Mandatory payload. It must always be the first payload in the MIKEY message. It includes general information about the message such as version and the type of data it contains. It also contains information about the crypto session which includes the SSRC and ROC.
   b. KEMAC payload: Mandatory for MIKEY-PSK, must be last payload. the payload should not be encrypted or authenticated since TLS already encrypts the RTSP(S) channel.
   The key type should be TEK without salt. Key validity is provided by an SPI/MKI association. The MKI is 4 bytes long.
   c. Security Policy payload. Mandatory. Specifies the encryption algorithm to be used by the streams. For AES_CM_128_HMAC_SHA1_80, the policies must be:
   i. Encryption algorithm: AES-CM
   ii. Session encryption key length: 128 bits
   iii. Authentication algorithm: HMAC-SHA-1
   iv. Session auth key length: 160 bits
   v. Session salt key length: 112 bits
   vi. SRTP encryption on
   vii. SRTCP encryption on
   viii. Authentication tag length: 80 bits
   iv. SRTP PRF: AES-CM
   vi. Key management extensions for SDP and RTSP (RFC 4567)
   1. Stream Initialization
   a. Device provided key
   The SDP is required to have a media of type RTP/SAVP and a MIKEY message.
   It's possible for to have two video tracks, one RTP/AVP and another RTP/SAVP.
   b. Client provided key
   On SETUP, the client will send a KeyMgmt header containing the MIKEY, with transport type RTP/SAVP.
   SETUP rtsp://<RTSP_URI> RTSP/1.0
   CSeq: 2
   User-Agent: OmnicastRTSPClient/1.0
   Transport: RTP/SAVP/UDP;unicast
   KeyMgmt: prot=mikey;uri="";data="AQAFAP1td9ABAADCD1UcAAAAAAoAAdOOGc75XD0BAAAAGAABAQEBEAIBAQMBFAcBAQgBAQoBAQsBCgAAACcAIQAe30C59UrClE0e27UP5h/Wty9UL8+dfzg+2ttmmo3kBAAAAC8A"

    	2. Re-keying with mikey
    		This is unspecified in RFC 4567. A custom rekeying method shall be used.
    		The SET_PARAMETER method shall be used with a mikey parameter allow the client to change they key to be used by the device.
    		SET_PARAMETER rtsp://<RTSP_URI> RTSP/1.0
    		CSeq: 6
    		Session: 15405670
    		User-Agent: OmnicastRTSPClient/1.0
    		Content-Type: text/parameters
    		Content-Length: 145
   
    		mikey: AQAFAGgCr8EBAADSvxgkAAAAAAoAAdOOK7UihqIBAAAAGAABAQEBEAIBAQMBFAcBAQgBAQoBAQsBCgAAACcAIQAepekjs88g+Q7AU6LAvRsoVyn18ZW1JuXI9qht4g6+BAAAAAIA
    		
    	3. Multicast considerations
    		In multicast, to allow other clients to retrieve changing keys, the device must support a GET_PARAMETER request with a mikey parameter.
    		The mikey must include the SRRC and ROC.
    		Request:
    		GET_PARAMETER rtsp://<RTSP_URI> RTSP/1.0
    		CSeq: 4
    		Session: 15405670
    		User-Agent: OmnicastRTSPClient/1.0
    		Content-Type: text/parameters
    		Content-Length: 9
   
    		mikey
   
    		Response:
    		RTSP/1.0 200 OK
    		CSeq: 4
   
    		mikey: AQAFAGrVolgBAADdBcAoAAAAAAsA2/K83QArhBIKEGrVolg1GZvp7DPyFCdYmXABAAAAGwABAQEBEAIBAQMBFAQBDgcBAQgBAQoBAQsBCgAAACcAIQAe7OzS5umZMXHqaegZC3UkDwbC5NNpj4b8+fB6MROeBAAAAA0A
   

   b. For the new algorithms
   i. NONE
   When the SecurityProtocolAlgorithm is set to "NONE", the device shall only return an RTP/AVP track without a mikey attribute. The RTP packets must be unencrypted.
   ii. AEAD_AES_128_GCM
   Same as base AES_CM_128_HMAC_SHA1_80, except for these points:
   1. MIKEY payloads:
   a. Security Policy payload:
   i. Encryption algorithm: AES-GCM
   ii. Session encryption key length: 128 bits
   iii. Authentication algorithm: NULL
   iv. Session auth key length: N/A
   v. Session salt key length: 96 bits
   vi. SRTP encryption on
   vii. SRTCP encryption on
   viii. Authentication tag length: N/A bits
   ix. SRTP PRF: AES-CM
   x. AEAD authentication tag length: 16 octets
   iii. AEAD_AES_256_GCM
   Same as base AES_CM_128_HMAC_SHA1_80, except for these points:
   1. MIKEY payloads:
   a. Security Policy payload:
   i. Encryption algorithm: AES-GCM
   ii. Session encryption key length: 256 bits
   iii. Authentication algorithm: NULL
   iv. Session auth key length: N/A
   v. Session salt key length: 96 bits
   vi. SRTP encryption on
   vii. SRTCP encryption on
   viii. Authentication tag length: N/A bits
   ix. SRTP PRF: AES-CM
   x. AEAD authentication tag length: 16 octets

[sirzooro]

Thanks! Most things are clear now. One missing point is that encryption key and encryption salt should be concatenated before inserting into Key subpayload. I also noticed one typo, sohuld->should.

[jcbeaulieu]

In Genetec's implementation there is no salt, only the key data.
If I understand correctly what you mean, its that GStreamer uses TEK type and concatenates some internal key data with an internal salt, but everything is in the key data field of the payload? If that's the case, wouldn't that just be longer key data to be fed to the AES-CM-PRF?
Can you point to this concatenation?
It seems to me that the salt data and salt length is placed in memory after the key data and key length in gstmikey.c gst_mikey_payload_key_data_set_salt() line 654 (https://github.com/GStreamer/gstreamer/blob/2e8b542145c1b11f8b8d927f6c679fd8028ceb60/subprojects/gst-plugins-base/gst-libs/gst/sdp/gstmikey.c)

[sirzooro]

GStreamer internally stores concatenated key+salt in capabilities srtp-key and srtcp-key. The same format is expected by public API of libsrtp library, I suspect that Gstreamer reused that format. Actual concatenation is done here, if key and salt are sent separately in Key subpayload: https://github.com/GStreamer/gstreamer/blob/2e8b542145c1b11f8b8d927f6c679fd8028ceb60/subprojects/gst-plugins-base/gst-libs/gst/sdp/gstmikey.c#L2548-L2556
This code also works when key and salt are sent in concatenated form (in fact older GStreamer versions supported concatenated format only).
SRTP libraries internally have to split key and salt, even if they were concatenated. Here is how pion/srtp uses them to derive other keys: https://github.com/pion/srtp/blob/master/key_derivation.go#L11

Genetec uses Master Key with 128 bits and Master Salt with 112 bits, so definitely they have salt too. They just expect both to be concatenated and put in Key subpayload with Type set to TEK.

[jcbeaulieu]

You're right. I've tested with some cameras and sending a TEK+SALT MIKEY makes the camera return seemingly unencrypted packets (No MKI).
I'll add it to the documentation.

[jcbeaulieu]

I have changed the SRTP configuration from StreamingCapabilities and GetStreamUri2 to the encoder configurations, for audio, video and metadata for both media 1 and media 2.

Streaming specification XML changes are still ongoing and were not included in the latest commit.

[sirzooro]

Hi @jcbeaulieu, what are your plans for this PR? We are still have few points to address:

• value for Type field in Key subpayload: should we use TEK or TEK+SALT there?
• extra entries in HDR with SSRC=0 as a placeholder for RTCP SSRCs from other side;

In last few days I also noticed few new issues to clarify:

• how to perform rekeying when RTSP session has multiple streams (e.g. video and audio). Should client send two SET_PARAMETER requests, as TEK/TEK+SALT type of Key subpayload does not allow to explicitly associate key with SSRC? Or should we switch to TGK/TGK+SALT (Traffic Generation Key) which does not have this limitation?
• similar issue is for GET_PARAMETER, it returns one MIKEY message now.
• RFC 4567 adds new RTSP status code 463 Key management failure. Please add note that server should return it when something is wrong with MIKEY message (e.g. message cannot be parsed or specified cipher is not supported).
• we also have special case of ONVIF backchannel. Please add note that RTSP client should use SSRC selected by server in transport header of a SETUP response.
• what about SSRC for SRTCP messages sent from client? They should be different than ones used by server. Do we need extra header or field somewhere to send them too?

Edit: I have decoded MIKEY message examples and checked them. In ones for KeyMgmt header and SET_PARAMETER SP param 4 (Salt Length) is missing. RAND payload is also missing there, what may cause issues. Both missing things are present in example for GET_PARAMETER.

[jcbeaulieu]

Hello @sirzooro,

I plan on requiring TEK for AES-CM-128-HMAC-SHA1 since it's what is already used for cameras deployed, but I'd like to force TEK + SALT for the other algorithms to clearly delineate the key from the salt as some other algorithms may be more flexible than AES-GCM in the future. AEGIS comes to mind. (https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/)
I would like feedback on this approach.

If I understand correctly, ONVIF does not officially support stating multiple streams with the same RTSP session (Aggregate control). Is this correct @HansBusch?
If this is the case, then I don't believe there would be an advantage to TGK.

I will add the 463 error code and the server selected SSRC in SETUP note to the documentation.

SRTCP is not defined by our internal SRTP whitepaper and to my knowledge, has never been used or tested in an ONVIF device.
Can other manufacturers chime in for SRTCP implementation? @HansBusch, @bjornvolcker, @sujithhanwha?

[sirzooro]

Hello @sirzooro,

I plan on requiring TEK for AES-CM-128-HMAC-SHA1 since it's what is already used for cameras deployed, but I'd like to force TEK + SALT for the other algorithms to clearly delineate the key from the salt as some other algorithms may be more flexible than AES-GCM in the future. AEGIS comes to mind. (https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/) I would like feedback on this approach.

Ok, makes sense.

SRTCP is not defined by our internal SRTP whitepaper and to my knowledge, has never been used or tested in an ONVIF device. Can other manufacturers chime in for SRTCP implementation? @HansBusch, @bjornvolcker, @sujithhanwha?

RTCP is needed to properly synchronize video and audio streams. Receiver Reports also may be used for diagnostics at server side. Plus for extended feedback when AVPF/SAVPF profile is negotiated. And last very important role, RTCP packets also serve as a session keep-alive packets. GStreamer RTSP client does not use correct key+salt to encrypt SRTCP, so these packets are dropped by server because authentication tag is invalid, and as a result RTSP session times out. GStreamer RTSP client would have to be configured to repeatedly send RTSP requests to keep session alive. This may be common issue for RTSP clients and servers. When RTCP works but SRTCP not, it may be considered a regression.

[sirzooro]

If I understand correctly, ONVIF does not officially support stating multiple streams with the same RTSP session (Aggregate control). Is this correct @HansBusch? If this is the case, then I don't believe there would be an advantage to TGK.

ONVIF may require RTSP sessions with single stream and certified devices surely supports this. However there are also non-certified ONVIF devices which may work differently. I am aware of some video encoder with broken RTSP server, it sent 200 OK responses when client tried to start audio-only session and did not send any RTP frame with audio. That encoder properly sent audio when it was in one session with video. Despite this but it worked with at least some ONVIF software.

Edit: regarding SRTCP we can have something like "RTCP support is optional. When device supports RTCP, it should also support SRTCP" plus details necessary for SRTCP implementation.

Edit2: sometimes customers add camera to one VMS in ONVIF mode and as RTSP stream to other one(s). Please add new SDP attribute (e.g. a=onvif-keymgmt) so these other VMSes could discover that camera supports keys sent by client.

[sirzooro]

If I understand correctly, ONVIF does not officially support stating multiple streams with the same RTSP session (Aggregate control). Is this correct @HansBusch? If this is the case, then I don't believe there would be an advantage to TGK.

I have noticed that there is streaming capability "MultiTrackStreaming - Indicates support for multiple video RTP streams in one RTSP session.". So multiple streams in one RTSP sessions are supported, although for different use case (multiple video streams instead of video+audio).

[kieran242]

@jcbeaulieu Given the PR #555 is this PR still valid? Can it be closed or is it still required?

[jcbeaulieu]

Hello @kieran242, it can be closed. Work will continue in PR #555