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?