Skip to main content

SRTP and RTSPS reference

Introduction​

This document serves as a reference for the Secure Real-Time Protocol (SRTP). Previously described in RFC3711, SRTP is a profile of the Real-Time Protocol (RTP). It provides encryption of the payload data, as well as authentication and replay protection for the RTP streams. SRTP can be used over any lower transport but it is best suited for User Datagram Protocol (UDP), which is best-effort, but with lower latency. UDP is the only choice for sending multicast media, as there previously had not been any easy ways to secure datagram-based RTP other than IPSec.

The main objective with the Axis RTSPS/SRTP implementation is to solve this problem by providing secure streaming over IP multicast with multiple viewers sharing the same stream. However, there is still nothing preventing the user to use unicast UDP or TCP (Transport Control Protocol) as it is functional in both cases.

In every case for SRTP, the inherent problem is how to securely exchange the “cryptographic context”, namely the Master Key, the current Roll-Over Counter (ROC) and the Synchronization Source (SSRC).

The intended audience for this document are VMS manufacturers wanting to be able to use secure RTP with Axis products.

Background reading​

You should be familiar with SRTP and have read RFC3711 and RFC7714.

Axis implements the key exchange using an RTSP SDP attribute RFC4567 along with MIKEY and RFC7714. You should also be familiar with these standards before implementing Axis RTSPS and SRTP.

Axis uses the open source libSRTP from Cisco Systems. You should be familiar with this library or similar alternatives.

This document doesn't cover instructions for the underlying SRTP library.

Identifying SRTP support and configuring​

Supported products​

Axis products starting from ARTPEC-5 and running firmware version 7.30 and higher support SRTP.

Properties​

On a product with SRTP support, you can access the following properties:

Properties.SRTP.Acceleration=”<hardware|none>”
Properties.SRTP.Authentication=”hmac-sha1”
Properties.SRTP.Encryption=”aes-ctr-128,aes-ctr-256,aes-gcm-128,aes-gcm-256”
Properties.SRTP.SRTP=”yes”
Properties.SRTP.Version=”1.0”

PropertyDescription
AccelerationThe encryption and authentication process for SRTP is CPU-heavy. This informational property shows if cryptographic hardware acceleration is used. This is most relevant for developers of ACAP applications.
AuthenticationA comma-separated list of SRTP authentication algorithms that the current implementation supports. As defined in RFC3711, the only supported authentication algorithm is HMAC-SHA1.
This parameter applies only when you use non-AEAD encryption algorithms (for example, AES-CTR). When you use authenticated encryption algorithms such as AES-GCM, the encryption algorithm itself provides integrity and authentication, so you don't use a separate SRTP authentication algorithm.
EncryptionA comma-separated list of SRTP encryption algorithms that the current implementation supports. This list may expand in later versions.
AES-GCM algorithms are authenticated encryption (AEAD) modes and provide both confidentiality and integrity protection as defined in RFC7714. When you select an AES-GCM encryption algorithm, you must omit or ignore the Authentication parameter.
SRTPThis property is always 'yes' when SRTP support is present.
VersionThe version of the Axis SRTP implementation that's supported.

Network.RTSPS​

Network.RTSPS.AllowClientTransportSettings=”yes”
Network.RTSPS.CertificateId=”rtsps”
Network.RTSPS.Enabled=”yes”
Network.RTSPS.Port=”322”
Network.RTSPS.Timeout=”60”

The RTSPS server handles all user-configurable options for SRTP. You can find them at root.Network.RTSPS in the parameter hierarchy. The RTSPS server is an RTSP server that only accepts TLS-encrypted connections. As a result, the RTSPS parameters closely resemble those of RTSP root.Network.RTSP, with a few irrelevant parameters removed.

The following table summarizes these parameters:

ParameterDescription
AllowClientTransportSettingsConfigure whether to allow the client to configure RTSP transport settings such as a multicast address and a port range.
CertificateIDThe ID of the certificate (within the global store) to use for the RTSPS TLS connections. The certificate must already exist on the device. You can use a self-signed certificate. The empty string ("") or "none" means no certificate.
EnabledSet to 'yes' to enable the RTSPS server.
PortA network port to listen for RTSPS connections (Default 322).
TimeoutNumber of seconds of inactivity before the connection closes due to a timeout.

RTSPS and SRTP introduction​

Overview​

You start a secure RTSPS/SRTP/SRTCP session the same way as a non-secure session. The basic steps are:

note

192.168.0.90 is used in the examples.

  1. The client establishes a TCP/TLS connection to an RTSP server listening on the device, typically on TCP port 322.

  2. The client sends DESCRIBE rtsp://192.168.0.90:322 and the server returns its key information in the SDP key-mgmt attribute and the key information embedded in a Base-64 encoded MIKEY message:

    RTSP/1.0 200 OK
    Content-Type: application/sdp
    .....
    m=video 0 RTP/SAVP 96
    a=rtpmap: 96 H264/90000
    a=key-mgmt:mikey
    AQAFAI36PLkBAADCohE9AAAAAAsA3GpZJ16GHpIKEFqKF1NwY0CMskn
    HAzWvah4BAAAAFQABAQEBEAIBAQMBCgcBAQgBAQoBAQAAACIAIAAeEjm+smTG/W AivFGVxaxAqnQD984ucyhbeZrxszRLAA==

The MIKEY message describes what key policy and key information the server uses for RTP and RTCP. Note that the 'm' media attribute profile is defined as RTP/SAVP and not RTP/AVP.

  1. Like the server, the client must also decide on a key policy and master key, but it sends information in the SETUP header KeyMgmt.

    Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057 KeyMgmt:prot=mikey;uri="rtsp://192.168.0.90:322";data="AQAFAJqYnFQBAADNHU3KAAAAAA sA3GpZJ19CmdgKEDF/cdBsmcPLrEw5qcjdhc0BAAAAFQABAQEBEAIBAQMBCgcBAQgBAQoBAQAAACIA IAAeeVks5yUI8DaOQgRQGApBpwZOilMntV/yRmdzRzyZAA=="

  2. Once you complete the negotiation of transport parameters, issue an RTSP PLAY command to instruct the server to start delivering the SRTP/SRTCP stream.

  3. When you want to close the stream, issue a TEARDOWN command.

Server details​

From the previous example, the SDP attribute-key equals:

AQAFAI36PLkBAADCohE9AAAAAAsA3GpZJ16GHpIKEFqKF1NwY0CMsknHAzWvah4BAAAAFQABAQEBEAIBAQMBCgcB AQgBAQoBAQAAACIAIAAeEjm+smTG/WAivFGVxaxAqnQD984ucyhbeZrxszRLAA==

Translated into a hexadecimal array makes it look like this:

0x01 0x00 0x05 0x00 0x8d 0xfa 0x3c 0xb9 0x01 0x00 0x00 0xc2 0xa2 0x11 0x3d 0x00
0x00 0x00 0x00 0x0b 0x00 0xdc 0x6a 0x59 0x27 0x5e 0x86 0x1e 0x92 0x0a 0x10 0x5a
0x8a 0x17 0x53 0x70 0x63 0x40 0x8c 0xb2 0x49 0xc7 0x03 0x35 0xaf 0x6a 0x1e 0x01
0x00 0x00 0x00 0x15 0x00 0x01 0x01 0x01 0x01 0x10 0x02 0x01 0x01 0x03 0x01 0x0a
0x07 0x01 0x01 0x08 0x01 0x01 0x0a 0x01 0x01 0x00 0x00 0x00 0x22 0x00 0x20 0x00
0x1e 0x12 0x39 0xbe 0xb2 0x64 0xc6 0xfd 0x60 0x22 0xbc 0x51 0x95 0xc5 0xac 0x40
0xaa 0x74 0x03 0xf7 0xce 0x2e 0x73 0x28 0x5b 0x79 0x9a 0xf1 0xb3 0x34 0x4b 0x00

Lastly, the decoded server MIKEY[3] message looks like this:

#HDR
0x01, #version
0x00, #data type
0x05, #next payload == T
0x00, #V + PRF function
0x8d,0xfa,0x3c,0xb9 , #CSB ID
0x01, #CS
0x00, #CS ID map type
0x00, #Policy_no_1
0xc2,0xa2,0x11,0x3d, #SSRC_1 0xc2a2113d for RTP/RTCP
0x00,0x00,0x00,0x00, #ROC_1
#T
0x0b, #next payload == RAND
0x00, #TS type
0xdc,0x6a,0x59,0x27,0x5e,0x86,0x1e,0x92 , #TS value
#RAND
0x0a, #next payload == SP
0x10, #RAND length
0x5a,0x8a,0x17,0x53,0x70,0x63,0x40,0x8c,
#SP
0x01, #next payload == KEMAC
0x00, #Policy no
0x00, #Protocol type
0x00,0x15, #Policy parameter length == 21
0x00,0x01,0x01, #Type | Length | Value Encryption algorithm, 1, AES-CM
0x01,0x01,0x10, #Type | Length | Value Session encryption key length, 1, 16
0x02,0x01,0x01, #Type | Length | Value Authentication algorithm, 1, HMAC-SHA-1
0x03,0x01,0x14, #Type | Length | Value Session authentication key length, 1, 20
0x07,0x01,0x01, #Type | Length | Value SRTP encryption off/on, 1, ON
0x08,0x01,0x01, #Type | Length | Value SRTCP encryption off/on, 1, ON
0x0a,0x01,0x01, #Type | Length | Value SRTP authentication off/on, 1, ON
#KEMAC
0x00, #next payload == Last payload
0x00, #Encryption algorithm
0x00, 0x22, #Encryption data length 0x22 == 34
#Key data sub-payload
0x00, #Next Payload == Last payload
0x20, #Type | KV 4 bits each 0010 ==> TEK | 0000 ==> no SPI/MKI
0x00,0x1e, #Key data length 0x1e == 30
0x12,0x39,0xbe,0xb2,0x64,0xc6,0xfd,0x60,0x22,0xbc, #Key data
0x51,0x95,0xc5,0xac,0x40,0xaa,0x74,0x03,0xf7,0xce,
0x2e,0x73,0x28,0x5b,0x79,0x9a,0xf1,0xb3,0x34,0x4b,
0x00 #Last payload

Client details​

Examining the MIKEY message sent from the client reveals the following details:

From the Setup, KeyMgmt equals:

AQAFAJqYnFQBAADNHU3KAAAAAAsA3GpZJ19CmdgKEDF/cdBsmcPLrEw5qcjdhc0BAAAAFQABAQEBEAIBAQMBCgcB AQgBAQoBAQAAACIAIAAeeVks5yUI8DaOQgRQGApBpwZOilMntV/yRmdzRzyZAA==

Translated into a hexadecimal array makes it look like this:

0x01 0x00 0x05 0x00 0x9a 0x98 0x9c 0x54 0x01 0x00 0x00 0xcd 0x1d 0x4d 0xca 0x00
0x00 0x00 0x00 0x0b 0x00 0xdc 0x6a 0x59 0x27 0x5f 0x42 0x99 0xd8 0x0a 0x10 0x31
0x7f 0x71 0xd0 0x6c 0x99 0xc3 0xcb 0xac 0x4c 0x39 0xa9 0xc8 0xdd 0x85 0xcd 0x01
0x00 0x00 0x00 0x15 0x00 0x01 0x01 0x01 0x01 0x10 0x02 0x01 0x01 0x03 0x01 0x0a
0x07 0x01 0x01 0x08 0x01 0x01 0x0a 0x01 0x01 0x00 0x00 0x00 0x22 0x00 0x20 0x00
0x1e 0x79 0x59 0x2c 0xe7 0x25 0x08 0xf0 0x36 0x8e 0x42 0x04 0x50 0x18 0x0a 0x41
0xa7 0x06 0x4e 0x8a 0x53 0x27 0xb5 0x5f 0xf2 0x46 0x67 0x73 0x47 0x3c 0x99 0x00

Lastly, the decoded client MIKEY message looks like this:

#HDR
0x01, #version
0x00, #data type
0x05, #next payload == T
0x00, #V + PRF function
0x9a,0x98,0x9c,0x54, #CSB ID
0x01, #CS
0x00, #CS ID map type
0x00, #Policy_no_1
0xcd,0x1d,0x4d,0xca, #SSRC_1 0xcd1d4dca for RTCP receiver reports
0x00,0x00,0x00,0x00, #ROC_1
#T
0x0b, #next payload == RAND
0x00, #TS type
0xdc,0x6a,0x59,0x27,0x5f,0x42,0x99,0xd8, #TS value
#RAND
0x0a, #next payload == SP
0x10, #RAND length
0x31,0x7f,0x71,0xd0,0x6c,0x99,0xc3,0xcb, #RAND value
0xac,0x4c,0x39,0xa9,0xc8,0xdd,0x85,0xcd,
#SP
0x01, #next payload == KEMAC
0x00, #Policy number
0x00, #Protocol type
0x00,0x15, #Policy parameter length == 21
0x00,0x01,0x01, #Type | Length | Value Encryption algorithm, 1, AES-CM
0x01,0x01,0x10, #Type | Length | Value Session encryption key length, 1, 16
0x02,0x01,0x01, #Type | Length | Value Authentication algorithm, 1, HMAC-SHA-1
0x03,0x01,0x14, #Type | Length | Value Session authentication key length, 1, 20
0x07,0x01,0x01, #Type | Length | Value SRTP encryption off/on, 1, ON
0x08,0x01,0x01, #Type | Length | Value SRTCP encryption off/on, 1, ON
0x0a,0x01,0x01, #Type | Length | Value SRTP authentication off/on, 1, ON
#KEMAC
0x00, #next payload == Last payload
0x00, #Encryption algorithm
0x00, 0x22, #Encryption data length 0x22 == 34
#Key data sub-payload
0x00, #Next Payload == Last payload
0x20, #Type | KV 4 bits each 0010 ==> TEK | 0000 ==> no SPI/MKI
0x00,0x1e, #Key data length 0x1e == 30
0x79,0x59,0x2c,0xe7,0x25,0x08,0xf0,0x36,0x8e,0x42, #Key data
0x04,0x50,0x18,0x0a,0x41,0xa7,0x06,0x4e,0x8a,0x53,
0x27,0xb5,0x5f,0xf2,0x46,0x67,0x73,0x47,0x3c,0x99,
0x00 #Last payload

The Axis RTSPS and SRTP implementation​

The Axis SRTP implementation differs from the standard setup described in the RTSPS and SRTP introduction. The main differences are:

  1. The client selects the key for both the client (SRTCP/RR) and the device (SRTP/SRTCP SR), and the key is the same in both directions. Note that sending an RR from the client is optional, like an unsecured RTP stream.
  2. The MKI (Master Key Index) determines which key to use. This means that the SRTP library you use for the client implementation must support MKI (such as Cisco libsrtp, starting from version 2.1.0).
  3. You can change the master key on an ongoing RTSPS and SRTP session, as described in the Client change key details.

Starting a SRTP session​

You start an Axis secure RTSPS/SRTP/SRTCP session the same way as a non-secure session. The basic steps are:

  1. The client establishes a TCP/TLS connection to the Axis device, typically on TCP port 322.

  2. The client sends DESCRIBE rtsp://192.168.0.90:322/axis-media.amp?resolution=1280x720. The Axis device returns the key information in the SDP key-mgmt attribute. You can disregard this key, as it's not usable in the current SRTP implementation.

    RTSP/1.0 200 OK
    Content-Type: application/sdp
    .....
    m=video 0 RTP/SAVP 96
    a=rtpmap:96 H264/90000
    a=key-mgmt:mikey
    AQAFAAAAAAABAABIpAblAAAAAAsA3KxN3+6Uqx0KEC5nZkODCBg1jUIUrekng94BAAAAFQABAQEBEAIBEAM BCgcBCggBCgoBCgAAACIAIAAe9fsLRL5YjBTDlbzHsTNr9I262IColck3E8ejuLx3AA==

  3. The client then sends the key information in the SETUP header KeyMgmt.

    Transport: RTP/SAVP/UDP;unicast;client_port=3056-3057
    KeyMgmt: prot=mikey; uri="rtsp://192.168.0.90:322/axis-media/media.amp/stream=0?resolution=1280x720";data="AQAFAKcvl/0BAABjLq/2AAAAAAsA3KxN2i3rUskKEMPS0oFezZ/Pvrjgps1iobcBAAAAFQABAQEBEAIBAQMBCgcBAQgBAQoBAQAAACcAIQAeU0R+ULopXZLLLazeZQEkiMP1ruTZKj2WTHZh3SmKBAAAAAwA"

    The MIKEY message describes what key policy and key information the Axis device uses for RTP and RTCP and for the client RTCP messages. Note that you should use the same key in both directions. You don't need to send any RTCP RR from the client because you can use RTSP OPTIONS/GET_PARAMETER commands for keep-alive instead. Include a unique RTCP SSRC number in the client MIKEY message even if you use RTSP OPTIONS/GET_PARAMETER for keepalive (see decoded client MIKEY message above).

  4. Once you complete the negotiation of the transport parameters, issue a PLAY command to instruct the Axis product to start delivering the SRTP/SRTCP stream.

  5. When you want to close the stream, issue a TEARDOWN command.

Client setup details​

Examining the MIKEY message sent from the client reveals the following details:

From the Setup, KeyMgmt equals:

AQAFAKcvl/0BAABjLq/2AAAAAAsA3KxN2i3rUskKEMPS0oFezZ/Pvrjgps1iobcBAAAAFQABAQE
BEAIBAQMBCgcBAQgBAQoBAQAAACcAIQAeU0R+ULopXZLLLazeZQEkiMP1ruTZKj2WTHZh3SmKBAAAAAwA

Translated into a hexadecimal array makes it look like this:

0x01 0x00 0x05 0x00 0xa7 0x2f 0x97 0xfd 0x01 0x00 0x00 0x63 0x2e 0xaf 0xf6 0x00
0x00 0x00 0x00 0x0b 0x00 0xdc 0xac 0x4d 0xda 0x2d 0xeb 0x52 0xc9 0x0a 0x10 0xc3
0xd2 0xd2 0x81 0x5e 0xcd 0x9f 0xcf 0xbe 0xb8 0xe0 0xa6 0xcd 0x62 0xa1 0xb7 0x01
0x00 0x00 0x00 0x15 0x00 0x01 0x01 0x01 0x01 0x10 0x02 0x01 0x01 0x03 0x01 0x0a
0x07 0x01 0x01 0x08 0x01 0x01 0x0a 0x01 0x01 0x00 0x00 0x00 0x27 0x00 0x21 0x00
0x1e 0x53 0x44 0x7e 0x50 0xba 0x29 0x5d 0x92 0xcb 0x2d 0xac 0xde 0x65 0x01 0x24
0x88 0xc3 0xf5 0xae 0xe4 0xd9 0x2a 0x3d 0x96 0x4c 0x76 0x61 0xdd 0x29 0x8a 0x04
0x00 0x00 0x00 0x0c 0x00

Lastly, the decoded client MIKEY[3] message looks like this:

#HDR
0x01, #Version
0x00, #Data type
0x05, #Next payload == T
0x00, #V + PRF function
0xa7,0x2f,0x97,0xfd, #CSB ID
0x01, #CS
0x00, #CS ID map type
0x00, #Policy_no_1
0x63,0x2e,0xaf,0xf6, #SSRC_1 for RTCP RR's (if RR isn't used for keep-alive, use any
random number)
0x00,0x00,0x00,0x00, #ROC_1
#T
0x0b, #Next payload == RAND
0x00, #TS type
0xdc,0xac,0x4d,0xda,0x2d,0xeb,0x52,0xc9 , #TS value
#RAND
0x0a, #Next payload == SP
0x10, #RAND length
0xc3,0xd2,0xd2,0x81,0x5e,0xcd,0x9f,0xcf, #RAND value
0xbe,0xb8,0xe0,0xa6,0xcd,0x62,0xa1,0xb7,
#SP
0x01, #Next payload == KEMAC
0x00, #Policy number
0x00, #Protocol type
0x00,0x15, #Policy parameter length == 21
0x00,0x01,0x01, #Type | Length | Value Encryption algorithm, 1, AES-CM
0x01,0x01,0x10, #Type | Length | Value Session encryption key length, 1, 16
0x02,0x01,0x01, #Type | Length | Value Authentication algorithm, 1, HMAC-SHA-1
0x03,0x01,0x14, #Type | Length | Value Session authentication key length, 1, 20
0x07,0x01,0x01, #Type | Length | Value SRTP encryption off/on, 1, ON
0x08,0x01,0x01, #Type | Length | Value SRTCP encryption off/on, 1, ON
0x0a,0x01,0x01, #Type | Length | Value SRTP authentication off/on, 1, ON
#KEMAC
0x00, #Next payload == Last payload
0x00, #Encryption algorithm
0x00, 0x27, #Encryption data length 0x27 == 39
#Key data sub-payload
0x00, #Next Payload == Last payload
0x21, #Type | KV 4 bits each 0010 ==> TEK | 0001 ==> SPI/MKI
0x00,0x1e, #Key data length 0x1e == 30
0x53,0x44,0x7e,0x50,0xba,0x29,0x5d,0x92,0xcb,0x2d, #Key data
0xac,0xde,0x65,0x01,0x24,0x88,0xc3,0xf5,0xae,0xe4,
0xd9,0x2a,0x3d,0x96,0x4c,0x76,0x61,0xdd,0x29,0x8a,
0x04, #SPI/MKI length
0x00 0x00 0x00 0x0c # SPI/MKI value
0x00 #Last payload

Client get key details​

Information about the current cryptographic context on an ongoing session can be retrieved by the GET_PARAMETER request:

C->S: GET_PARAMETER rtsp://192.168.0.90:322/axis-media/media.amp?resolution=1280x720
       CSeq: 431
       Content-Type: text/parameters

       srtp-sessions
S->C: RTSP/1.0 200 OK
       CSeq: 431
       Content-Type: text/parameters
       pt=96;ssrc=270482974;destination=239.245.254.189;port=50000;
       key=53447e50ba295d92cb2dacde65012488c3f5aee4d92a3d964c7661dd298a;
       mki=0x0c;roc=0

Client change key details​

You can change the SRTP key with a SET_PARAMETER request:

C->S: SET_PARAMETER rtsp://192.168.0.90:322/axis-media/media.amp?resolution=1280x720
       CSeq: 615

       KeyMgmt: prot=mikey;uri="rtsp://192.168.0.90:322/axis-media/media.amp/stream=0?resolution=1280x720";data="AQABANbDAh8BAAAQHz4eAAAAAAAAACcAIQAerlqPH0PI8A20rmY4BJcBgQFWYfTCgYRInVCQMTzVBAAAAA0A"
S->C: RTSP/1.0 200 OK
       CSeq: 615

From the SET_PARAMETER, KeyMgmt equals:

AQABANbDAh8BAAAQHz4eAAAAAAAAACcAIQAerlqPH0PI8A20rmY4BJcBgQFWYfTCgYRInVCQMTzVBAAAAA0A

Translated into a hexadecimal array makes it look like this:

0x01 0x00 0x01 0x00 0xd6 0xc3 0x02 0x1f 0x01 0x00 0x00 0x10 0x1f 0x3e 0x1e 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x27 0x00 0x21 0x00 0x1e 0xae 0x5a 0x8f 0x1f 0x43
0xc8 0xf0 0x0d 0xb4 0xae 0x66 0x38 0x04 0x97 0x01 0x81 0x01 0x56 0x61 0xf4 0xc2
0x81 0x84 0x48 0x9d 0x50 0x90 0x31 0x3c 0xd5 0x04 0x00 0x00 0x00 0x0d 0x00

Lastly, the decoded server MIKEY message looks like this:

#HDR
0x01, #Version
0x00, #Data type
0x01, #Next payload == KEMAC
0x00, #V + PRF function
0xd6,0xc3,0x02,0x1f, #CSB ID
0x01, #CS
0x00, #CS ID map type
0x00, #Policy_no_1
0x10 0x1f 0x3e 0x1e, #SSRC_1 The SSRC used by the SRTP/SRTCP stream from the Axis device
0x00,0x00,0x00,0x00, #ROC_1
#KEMAC
0x00, #Next payload == Last payload
0x00, #Encryption algorithm
0x00, 0x27, #Encryption data length 0x27 == 39
#Key data sub-payload
0x00, #Next Payload == Last payload
0x21, #Type | KV 4 bits each 0010 ==> TEK | 0001 ==> SPI/MKI
0x00,0x1e, #Key data length 0x1e == 30
0xae,0x5a,0x8f,0x1f,0x43,0xc8,0xf0,0x0d,0xb4,0xae, #Key data
0x66,0x38,0x04,0x97,0x01,0x81,0x01,0x56,0x61,0xf4,
0xc2,0x81,0x84,0x48,0x9d,0x50,0x90,0x31,0x3c,0xd5,
0x04, #SPI/MKI length
0x00 0x00 0x00 0x0d #SPI/MKI value
0x00 #Last payload

Using authenticated encryption algorithms (AES-GCM)​

Authenticated encryption algorithms such as AES-GCM provide both confidentiality and integrity protection within a single cryptographic operation. When you use AES-GCM with SRTP, you don't need a separate authentication algorithm (for example, HMAC-SHA1).

We recommend AES-GCM for SRTP as it offers stronger security guarantees and a simpler configuration compared to traditional encryption-plus-HMAC schemes.

Let's take an example of a KeyMgmt data enforcing AES-GCM according to RFC7714 (applicable to both SETUP and SET_PARAMETER):

AQAFAMIqTsMBAADlprfjAAAAAAsA7SM0atNcW0oKEDsqaqDHlkff8Hzz4UyAgS8BAAAAFQABBgEBEAIBAAMBAAcBAQgBAQoBAQAAACUAIQAcEse/LlAh7CwfZXJoQTCwnplSE+3v3KVnOMEYsgQAAASwAA==

Translated into a hexadecimal array makes it look like this:

0x01 0x00 0x05 0x00 0xc2 0x2a 0x4e 0xc3 0x01 0x00 0x00 0xe5 0xa6 0xb7 0xe3 0x00
0x00 0x00 0x00 0x0b 0x00 0xed 0x23 0x34 0x6a 0xd3 0x5c 0x5b 0x4a 0x0a 0x10 0x3b
0x2a 0x6a 0xa0 0xc7 0x96 0x47 0xdf 0xf0 0x7c 0xf3 0xe1 0x4c 0x80 0x81 0x2f 0x01
0x00 0x00 0x00 0x15 0x00 0x01 0x06 0x01 0x01 0x10 0x02 0x01 0x00 0x03 0x01 0x00
0x07 0x01 0x01 0x08 0x01 0x01 0x0a 0x01 0x01 0x00 0x00 0x00 0x25 0x00 0x21 0x00
0x1c 0x12 0xc7 0xbf 0x2e 0x50 0x21 0xec 0x2c 0x1f 0x65 0x72 0x68 0x41 0x30 0xb0
0x9e 0x99 0x52 0x13 0xed 0xef 0xdc 0xa5 0x67 0x38 0xc1 0x18 0xb2 0x04 0x00 0x00
0x04 0xb0 0x00

The decoded #SP, #KEMAC and #Key data sub-payload parts of the MIKEY & RFC7714 message look like this:

#SP
0x01, #Next payload == KEMAC
0x00, #Policy no
0x00, #Protocol type
0x00,0x15, #Policy length = 21
0x00,0x01,0x06, #Type | Length | Encryption algorithm AES-128-GCM (or AES-256-GCM based on key length below)
0x01,0x01,0x10, #Type | Length | Session encryption key length, 0x10==16 (or 0x20==32 to enforce AES-256-GCM)
0x02,0x01,0x00, #Type | Length | Authentication algorithm, None
0x03,0x01,0x00, #Type | Length | Session authentication key length, 0
0x07,0x01,0x01, #Type | Length | SRTP encryption ON
0x08,0x01,0x01, #Type | Length | SRTCP encryption ON
0x0a,0x01,0x01, #Type | Length | SRTP authentication ON
#KEMAC
0x00, #Next payload == Last payload
0x00, #Encryption algorithm
0x00,0x25, #Encryption data length 0x25 == 37
#Key data sub-payload
0x00 #Next payload == Last payload
0x21 #Type | KV 4 bits each 0010 ==> TEK | 0001 ==> SPI/MKI
0x00,0x1c, #Key data length 0x1c == 28 (incl salt)
0x12,0xc7,0xbf,0x2e,0x50,0x21,0xec,0x2c,0x1f,0x65, #Key data
0x72,0x68,0x41,0x30,0xb0,0x9e,0x99,0x52,0x13,0xed,
0xef,0xdc,0xa5,0x67,0x38,0xc1,0x18,0xb2,
0x04, #SPI/MKI length
0x00,0x00,0x04,0xb0 #SPI/MKI value

Failures​

RTSP SETUP KeyMgmt failure​

If the KeyMgmt attribute in SETUP contains invalid settings, the device returns “463 Key Management Failure”, as shown in the example:

S->C: SETUP rtsp://192.168.0.90:322/axis-media/media.amp?resolution=1280x720
       CSeq: 3

       KeyMgmt: prot=mikey; uri="rtsp://192.168.0.90:322/axis-media/media.amp/stream=0?resolution=1280x720"; data="<INVALID_MIKEY_MESSAGE>"

C->S: RTSP/1.0 463 Key management Failure
       CSeq: 3

RTSP SET_PARAMETER KeyMgmt failure​

If the SET_PARAMETER change key command fails for any reason, the device returns "451 Parameter Not Understood", as shown in the example:

S->C: SET_PARAMETER rtsp://192.168.0.90:322/axis-media/media.amp?resolution=1280x720
       CSeq: 20

       KeyMgmt: prot=mikey;uri="rtsp://192.168.0.90:322/axis-media/media.amp/stream=0?resolution=1280x720";data="<INVALID_MIKEY_MESSAGE>"

C->S: RTSP/1.0 451 Parameter Not Understood
       CSeq: 20

Possible KeyMgmt failure reasons​

The SETUP or SET_PARAMETER change key commands may fail for several reasons. In these cases, SETUP returns error code "463 Key management Failure" and SET_PARAMETER returns "451 Parameter Not Understood". Possible failures:

  • Malformed MIKEY message.
  • Trying to select an unsupported NULL cipher or hash. The MKI is missing and must be present in the MIKEY message.
  • The MKI value is out of range. Valid MKI values are 0 to 4294967294.
  • Invalid MKI length. The supported length is 4.
  • Referring to multiple sessions in a single MIKEY message. Only one crypto session per MIKEY message is supported.
  • The SSRC couldn't be found when changing the key.
  1. RFC3711 – The Secure Real-Time Protocol https://tools.ietf.org/html/rfc3711
  2. RFC4567 - Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) https://tools.ietf.org/html/rfc4567
  3. MIKEY: Multimedia Internet KEYing https://tools.ietf.org/html/rfc3830
  4. Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) https://tools.ietf.org/html/rfc6904
  5. Cisco Systems - libSRTP (github) https://github.com/cisco/libsrtp
  6. AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) https://datatracker.ietf.org/doc/html/rfc7714

Document history​

DateVersionDescription
2017-09-281.0Initial version
2026-01-271.1Add AES-GCM as per RFC7714 [6], fix minor bug

Abbreviations​

ACAPAXIS Camera Application Platform
AESAdvanced Encryption Standard
FTPFile Transfer Protocol
HTTPHyper-Text Transport Protocol
ICMInteger Counter Mode
MKIMaster Key Index
RFCRequest For Comment
ROCRoll-Over Counter
RRReceiver Report (RTCP)
RTCPReal-Time Control Protocol
RTPReal-Time Protocol
RTSPReal-Time Streaming Protocol
RTSPSReal-Time Streaming Protocol Secure
SCPSecure Copy
SDPSession Description Protocol
SRTPSecure Real-Time Protocol
SSRCSynchronization Source
TCPTransport Control Protocol
TLSTransport Layer Security
UDPUser Datagram Protocol
VMSVideo Management System (or Software)
AEADAuthenticated Encryption with Associated Data
Last updated on