onvif
Proposal to add support for configuring the SRTP algorithm.
The SRTP configuration is done using the encoder configurations for audio, video and metadata for media 2.
Streaming specification XML changes will be made once the basic design is considered adequate.
This is a continuation of #420
I've added the first draft for the updated SRTP streaming specification.
@sirzooro, I believe the only remaining issue is SRTCP. Since we do not use SRTCP and rely on RTSP messages for the keep alive, we cannot test an SRTCP specification.
I would propose that a new proposal should be created to define SRTCP specifically.
@jcbeaulieu
- If this feature is meant to be supported or applicable for Media2, why the Media1 related structures in onvif.xsd got updated? While only Media2 structures are listed in streaming specification?
- OR If its meant to be a common feature did Media1.wsdl update got missed?
Sorry if its discussed before, but the changes for now seems a bix mixed up.
@jcbeaulieu
- https://github.com/onvif/specs/pull/599
- added to address an xml validation issue, please have a look and merge into this branch.
As discussed with Hans on July 29th, All of the implementation details for every algorithm will stay in the streaming specification.
This is because no currently known SRTP implementation by major manufacturers respect the RFCs. There are many details which can make implementations incompatible, and no open source tools can currently be used to validate our implementations against.
We have also added non RFC standard key exchanges to support key sharing for multicast.
With the goal of making implementation of this standard clear, it was decided that many important details affecting interoperability that are already defined in the RFCs should be explained in this document as well for the aforementioned reasons. This includes every algorithm that is or was ever supported. The algorithms that are allowed, and subject to change for cybersecurity reasons, will be listed in the security baseline document.
Some footnotes have been added to clearly define what comes from an RFC and what is specific to ONVIF. Since the document generated by https://developer.onvif.org/pub/specs does not have pages, they are not visible in the preview.
*The algorithm negotiation has been removed from media1 as discussed in the last meeting.
Please add note that SET_PARAMETER rekeying request should contain new key only, not both current and new ones.
A capability for "Cryptographic algorithm negotiation" would be a more clean solution, then there would be no need to conditioning requirements on if supported algorithm is listed or not.
5.1.1.4 SRTP data transfer via UDP
5.1.1.4.1 General requirements
This mode allows secure transmission of RTP packets via UDP unicast and multicast.
A device signaling support for SecureRTSPStreaming parameter within StreamingCapabilities shall support SRTP as defined in RFC 3711, furthermore it shall support MIKEY for key exchange and management as defined in section 5.1.1.4.3.
A device listing any supported SRTP cryptographic algorithms via the SecureStreamingProtocolAlgorithms structure included in the Media2 service shall behave as defined in section 5.1.1.4.2, a device not listing supported SRTP cryptographic algorithms shall use the AES_CM_128_HMAC_SHA1_80 algorithm as defined in RFC 3711.
5.1.1.4.2 Cryptographic algorithm negotiation
This mechanism allows the client to choose the encryption algorithm used by the device for SRTP.
The device shall list supported SRTP cryptographic algorithms via the SecureStreamingProtocolAlgorithms structure included in the Media2 service video encoder, audio encoder and metadata configuration elements as listed below: • AudioEncoder2ConfigurationOptions • VideoEncoder2ConfigurationOptions • MetadataConfigurationOptions
A device shall list at least one of the following algorithms: • NONE NONE is a special case, where the media is listed as RTP/AVP instead of RTP/SAVP and where MIKEY is unused altogether. This is to allow the use of RTSPS without using an SRTP encrypted media stream. It can also be used for RTSPS interleaved where media is sent over the same TLS protected channel as the RTSP control messages. • AES_CM_128_HMAC_SHA1_803 • AEAD_AES_128_GCM4 • AEAD_AES_256_GCM5
A device shall allow a specific algorithm to be configured using the SecureStreamingProtocolAlgorithm attribute. The specific algorithm shall be configurable through the following methods: • SetAudioEncoderConfiguration • SetVideoEncoderConfiguration • SetMetadataConfiguration
5.1.1.4.3 MIKEY
MIKEY is used for key management with SRTP. The device shall support MIKEY as defined in RFC 3830 for key management and RFC 4567 for key exchange. One exception is that, in RFC 3830, support for MIKEY-PSK and MIKEY-PK are listed mandatory. For ONVIF SRTP, only MIKEY-PSK support is defined and mandatory. MIKEY-PK should not be used for ONVIF SRTP.
The MIKEY message shall contain the following payloads: • Common Header Payload • KEMAC Payload
The KEMAC payload should not be encrypted since TLS already encrypts the RTSPS channel.
If the key type is TEK without salt and a salt must be provided, the key and the salt shall be concatenated and sent in the Key data section of the payload.
If the key type is TEK+SALT and a salt must be provided, the SALT shall be in the Salt data section.
The device and client shall support TEK for AES_CM_128_HMAC_SHA1_80 and TEK+SALT for other encryption algorithms. To keep track of key validity, The SPI/MKI shall be set in the KV data. Each SRTP packet shall include the MKI. • Security Policy Payload
@cappentz did minor edits to the comment description.
"tr2" namespace is used for structures related or relevant to Media2 WSDL.
Since "SrtpSecurityAlgorithms" structure is defined in onvif.xsd itself, all references of SrtpSecurityAlgorithms should be "tt:SrtpSecurityAlgorithms" and not "tr2:SrtpSecurityAlgorithms"
In addition, Media1 structures listed below referring to dependency on Media2 structure like "tr2:SrtpSecurityAlgorithms" is incorrect and hence its even more important to refer as tt:SrtpSecurityAlgorithms
VideoEncoderConfiguration VideoEncoderConfigurationOptions AudioEncoderConfiguration AudioEncoderConfigurationOption
Hence the commit suggestion to replace all text references in onvif.xsd from tr2:SrtpSecurityAlgorithms to tt:SrtpSecurityAlgorithms, all the "tt:" structures can be reused between Media1/2.
Well spotted @bsriramprasad
