Commit graph

1 commit

Author SHA1 Message Date
François Laignel
0f7be28eb1 rtspsrc: client-managed MIKEY KeyMgmt
Some servers (e.g. Axis cameras) expect the client to propose the encryption
key(s) to be used for SRTP / SRTCP. This is required to allow re-keying so
as to evade cryptanalysis. Note that the behaviour is not specified by the
RFCs. By setting the 'client-managed-mikey-mode' property to 'true', rtspsrc
acts as follows:

* For a secured profile (RTP/SAVP or RTP/SAVPF), any media in the SDP
  returned by the server for which a MIKEY key management applies is
  elligible for client managed mode. The MIKEY from the server is then
  ignored.
* rtspsrc sends a SETUP with a MIKEY payload proposed by the user. The
  payload is formed by calling the 'request-rtp-key' signal for each
  elligible stream. During initialisation, 'request-rtcp-key' is also
  called as usual. The keys returned by both signals should be the same
  for a single stream, but the mechanism allows a different approach.
* The user can start re-keying of a stream by calling SET_PARAMETER.
  The convenience signal 'set-mikey-parameter' can be used to build a
  'KeyMgmt' parameter with a MIKEY payload.
* After the server accepts the new parameter, the user can call
  'remove-key' and prepare for the new key(s) to be served by signals
  'request-rtp-key' & 'request-rtcp-key'.
* The signals 'soft-limit' & 'hard-limit' are called when a key
  reaches the limits of its utilisation.

This commit adds support for:

* client-managed MIKEY mode to srtpsrc.
* Master Key Index (MKI) parsing and encoding to GstMIKEYMessage.
* re-keying using the signals 'set-mikey-parameter' & 'remove-key' and
  then by serving the new key via 'request-rtp-key' & 'request-rtcp-key'.
* 'soft-limit' & 'hard-limit' signals, similar to those provided by srtpdec.

See also:

* https://www.rfc-editor.org/rfc/rfc3830
* https://www.rfc-editor.org/rfc/rfc4567

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7587>
2024-10-24 12:43:11 +00:00