Proposal to add support for configuring the SRTP algorithm.

[jcbeaulieu]

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

[jcbeaulieu]

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.

[sirzooro]

Thanks, I have added few comments.

[kieran242]

@jcbeaulieu very comprehensive. I have provided some typo and grammar updates as suggestions.

[sirzooro]

MAC in KEMAC is also not needed, as TLS provides integrity protection.

[bsriramprasad]

"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.

[bsriramprasad]

Suggestion

Instead of repeating this whole structure definition in all 3 places across videoencoder/audioencoder/metadata configurations, can it be defined as its own type that can be declared in the places the structure is needed? This can make the schema changes look more compact?

Example Definiton

<xs:complexType name="SecureStreamingProtocolAlgorithmsType">
    <xs:attribute name="SecureStreamingProtocolAlgorithms" type="tt:StringAttrList" use="optional">
        <xs:annotation>
            <xs:documentation>If secure RTSP streaming is supported, this shall return the list of supported cryptographic algorithms as defined by tt:SrtpSecurityAlgorithms.</xs:documentation>
        </xs:annotation>
    </xs:attribute>
</xs:complexType>

Example Declaration/Calling

<xs:element name="ElementName" type="SecureStreamingProtocolAlgorithmsType" minOccurs="0"/>

[cappentz]

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]

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.

[robberos]

can we coordinate and re-use SecureStreamingProtocolAlgorithms/SrtpSecurityAlgorithms with SRTPCryptoPolicy from https://github.com/onvif/specs/pull/631/files#diff-08105416aca13f9bad6ccbfe90e4d919f85e9a87f0ccf23f1ca0e6e3ab5d7ddeR2246?

[bsriramprasad]

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.

[sujithhanwha]

Actual Enum for this is defined as NONE, it would be better correct here to match with the enum and in the description we can mention that NONE refers to RTSPS_ONLY.

[kieran242]

"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

[ocampana-videotec]

Postponing to 26.06