Secure Real-Time Protocol (SRTP) for Software
The Secure Real-Time Transport Protocol, as described in RFC 3711, The Secure Real-time Transport Protocol (SRTP), provides a framework for the encryption and authentication of Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) streams. Both RTP and RTCP are defined by RFC 3550, RTP: A Transport Protocol for Real-Time Applications.
Encryption ensures that the call content and associated signalling remains private during transmission.
- Received packets are from the purported source
- Packets have not been tampered with during transmission
- A packet has not been replayed by a malicious server
Protocol Overview
While the RFC 3711 framework provides encryption and authentication procedures and defines a set of default cryptographic transforms required for RFC compliance, it does not specify a key management protocol to securely derive and exchange cryptographic keys. RFC 4568, Session Description Protocol (SDP) Security Description for Media Streams, defines such a protocol specifically designed to exchange cryptographic material using a newly defined SDP crypto attribute. Cryptographic parameters are established with only a single message or in single round-trip exchange using the offer/answer model defined in RFC 3264, An Offer/Answer Model with the Session Description Protocol.
The current release provides support for an initial SDP Security Descriptions (SDES) implementation that generates keys used to encrypt SRTP/SRTCP packets.
Authentication of packets will be added to a subsequent release.
A sample SDP exchange is shown below:
The SDP offerer sends:
v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4
The SDP answerer replies:
v=0
o=jill 25690844 8070842634 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=homer@example.com (Homer Simpson)
c=IN IP4 168.2.17.11
t=2873397526 2873405696
m=audio 32640 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
The media-level SDP attribute, crypto, describes the cryptographic suite, key parameters, and session parameters for the preceding unicast media line. The crypto attribute takes the form:
a=crypto: tag crypto-suite key-parameter [session-parameters]
tag
The tag field contains a decimal number that identifies a specific attribute instance. When an offer contains multiple crypto attributes, the answer uses the tag value to identify the accepted offer.
In the sample offer the tag value is 1.
crypto-suite
The crypto-suite field contains the encryption and authentication algorithms, either AES_CM_128_HMAC_SHA1_80 or AES_CM_128_HMAC_SHA1_32.
key-parameter
The key-parameter field contains one or more sets of keying material for the selected crypto-suite and it has following format.
"inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]
inline is a method and specifies that the crypto material to be used by the offerer is transmitted via the SDP.
The key||salt field contains a base64-encoded concatenated master key and salt.
Assuming the offer is accepted, the key || salt provides the crypto material used by the offerer to encrypt SRTP/SRTCP packets, and used by the answerer to decrypt SRTP/SRTCP packets.
Conversely the key || salt contained in the answer to the offer provides the crypto material used by the answerer to encrypt SRTP/SRTCP packets, and used by the offerer to decrypt SRTP/SRTCP packets.
The lifetime field optionally contains the master key lifetime (maximum number of SRTP or SRTCP packets encoded using this master key).
In the sample offer the lifetime value is 1,048, 576 (220) packets.
The MKI:length field optionally contains the Master Key Index (MKI) value and the MKI length.
The MKI is used only when the offer contains multiple keys; it provides a means to differentiate one key from another. The MKI takes the form of an integer, followed by its byte length when included in SRTP/SRTCP packets. For hardware-based platforms, the length value can be up to 32 bytes. For software-based platforms, the length value is 4 bytes.
In the sample offer the MKI value is 1 with a length of 4 bytes.
The session-parameters field contains a set of optional parameters that may override SRTP session defaults for the SRTP and SRTCP streams.
UNENCRYPTED_SRTP — SRTP messages are not encrypted
UNENCRYPTED_SRTCP — SRTCP messages are not encrypted
UNAUTHENTICATED_SRTP — SRTP messages are not authenticated
When generating an initial offer, the offerer ensures that there is at least one crypto attribute for each media stream for which security is desired. Each crypto attribute for a given media stream must contain a unique tag. The ordering of multiple crypto attributes is significant — the most preferred crypto suite is listed first.
Upon receiving the initial offer, the answerer must either accept one of the offered crypto attributes, or reject the offer in its entirety.
When an offered crypto attribute is accepted, the crypto attribute contained in the answer MUST contain the tag and crypto-suite from the accepted crypto attribute in the offer, and the key(s) the answerer will use to encrypt media sent to the offerer.
The crypto-suite is bidirectional and specifies encryption and authentication algorithms for both ends of the connection. The keys are unidirectional in that one key or key set encrypts and decrypts traffic originated by the offerer, while the other key or key set encrypts and decrypts traffic originated by the answerer.
Key exchange via text-based SDP is unacceptable in that malicious network elements could easily eavesdrop and obtain the plaintext keys, thus compromising the privacy and integrity of the encrypted media stream. Consequently, the SDP exchange must be protected by a security protocol such as TLS.
Operational Modes
SRTP topologies can be reduced to three basic topologies which are described in the following sections.
Single-Ended SRTP Termination
Single-ended SRTP termination is illustrated in the following figure.
![The OCSBC performing Single-Ended SRTP termination. The OCSBC performing Single-Ended SRTP termination.](img/image21.png)
If SRTP is enabled for the inbound realm/interface, the Oracle® Enterprise Session Border Controller handles the incoming call as specified by the Media Security Policy assigned to the inbound realm. If there is crypto attribute contained in the offer, the Oracle® Enterprise Session Border Controller parses the crypto attributes and optional parameters, if any. If the offer contains a crypto attribute or attributes compatible with the requirements specified by the SDES profile assigned to the Media Security policy, it selects the most preferred compatible attribute. Otherwise, the Oracle® Enterprise Session Border Controller rejects the offer. Before the SDP is forwarded to the called party, the Oracle® Enterprise Session Border Controller allocates resources, established SRTP and SRTCP Security Associations and updates the SDP by removing the crypto attribute and inserting possibly NAT’ed media addresses and ports. At the same time, the original crypto attribute is also removed from the SDP.
Once the reply from the called party is received, the Oracle® Enterprise Session Border Controller inserts appropriate crypto attribute(s) to form a new SDP, and forward the response back to the calling party.
Refer to ACLI Example Configurations for a sample ACLI configuration.
Back-to-Back SRTP Termination
The following figure illustrates Back-to-back SRTP termination.
![The OCSBC performing back-to-back SRTP termination. The OCSBC performing back-to-back SRTP termination.](img/image41.png)
Initial processing is similar to the single-ended termination described above. Before forwarding the request to the called party, the Oracle® Enterprise Session Border Controller (ESBC) replaces the original crypto attribute with a new one whose crypto attribute conforms to the media security policy for the outbound realm/interface. Upon receiving the answer from the called party, the ESBC accepts or rejects it, again based upon conformity to the media security policy. If accepted, the ESBC replaces the original crypto attribute from the called party with its own to form a new SDP, which it forwards back to the calling party. At this point, SRTP media sessions are established on both sides for both calling and called parties.
SRTP Pass-Thru
The following figure illustrates SRTP pass-thru.
![The OCSBC supporting SRTP passthrough mode. The OCSBC supporting SRTP passthrough mode.](img/image61.png)
SRTP Pass-Thru
If the media security policy specifies pass-through mode, the Oracle® Enterprise Session Border Controller (ESBC) does not alter the crypto attribute exchange between the calling and the called party; the attribute is transparently passed.
ACLI Instructions
SDES configuration consists of the following steps.
- Create one or more SDES profiles which specify parameter values negotiated during the offer/answer exchange.
- Create one or more Media Security Policies that specify key exchange protocols and protocol-specific profiles.
- Assign a Media Security Policy to a realm.
- Create an interface-specific Security Policy (refer to Security Policy for a sample ACLI configuration)
Configure an SDES Profile
A Session Description Protocol Security Descriptions (SDES) profile specifies the parameter values offered or accepted during SDES negotiation.
In the following procedure, use the Key and Salt parameters to generate the synchronous key used to encrypt and decrypt SRTP/SRTCP traffic originated by theOracle® Enterprise Session Border Controller (ESBC). The ESBC passes these concatenated values to the remote SRTP peer. Upon reception, the remote peer inputs the key and salt values to the negotiated encryption algorithm (AES in the current implementation), and derives the key required to decrypt SRTP/SRTCP traffic received from the ESBC. The key parameter provides the basic keying material, while the salt (a bit string) provides the randomness/entropy required by the encryption algorithm.
Media Security Policy Configuration
Use the following procedure to create a Media Security Policy that specifies the role of the Oracle® Enterprise Session Border Controller (ESBC) in the security negotiation. When the ESBC takes part in the negotiation, the policy specifies a key exchange protocol and SDES profile for both incoming and outgoing calls.
ACLI Example Configurations
The following section contain XML representations of system configurations for basic operational modes.
Single-Ended SRTP Termination Configuration
<sdesProfile name='sdes'
srtpAuth='enabled'
srtpEncrypt='enabled'
srtcpEncrypt='enabled'
mki='disabled'
egressOfferFormat='same-as-ingress'
useIngressSessionParams=''
options=''
key=''
salt=''
lastModifiedBy='admin@172.30.11.55'
lastModifiedDate='2013-03-04 19:29:40' objectId='21'>
<cipherSuites name='AES_CM_128_HMAC_SHA1_80'/>
key>sdes</key>
</sdesProfile>
<mediaSecPolicy name='sdes'
passThrough='disabled'
options=''
lastModifiedBy='admin@172.30.11.55'
lastModifiedDate='2013-03-04 19:30:23' objectId='22'>
<inbound profile='sdes'
mode='srtp'
protocol='sdes'/>
<outbound profile='sdes'
mode='sdes'
protocol='sdes'/>
key>sdes</key>
</mediaSecPolicy>
...
...
...
realm-config
identifier peer
description
addr-prefix 192.168.0.0/16
network-interfaces M00:0
mm-in-realm enabled
mm-in-network enabled
mm-same-ip enabled
mm-in-system enabled
bw-cac-non-mm disabled
msm-release disabled
qos-enable disabled
generate-UDP-checksum disabled
max-bandwidth 0
fallback-bandwidth 0
max-priority-bandwidth 0
max-latency 0
max-jitter 0
max-packet-loss 0
observ-window-size 0
parent-realm
dns-realm
media-policy
media-sec-policy msp2
in-translationid
...
...
...
last-modified-by admin@console
last-modified-date 2009-11-10 15:38:19
Note:
Whenever there is a RTP for ingress leg and SRTP for egress leg, add an RTP media-sec-policy for single-ended SRTP termination configuration that adds a=crypto line to the Oracle® Enterprise Session Border Controller.
Back-to-Back SRTP Termination Configuration
ORACLE# show running-config
...
...
...
sdes-profile
name sdes1
crypto-list AES_CM_128_HMAC_SHA1_80
srtp-auth enabled
srtp-encrypt enabled
srtcp-encrypt enabled
mki disabled
key
salt
last-modified-by admin@console
last-modified-date 2009-11-16 15:37:13
media-sec-policy
name msp2
pass-through disabled
inbound
profile sdes1
mode srtp
protocol sdes
outbound
profile sdes1
mode srtp
protocol sdes
last-modified-by admin@console
last-modified-date 2009-11-16 15:37:51
...
...
...
realm-config
identifier peer
description
addr-prefix 192.168.0.0/16
network-interfaces M00:0
mm-in-realm enabled
mm-in-network enabled
mm-same-ip enabled
mm-in-system enabled
bw-cac-non-mm disabled
msm-release disabled
qos-enable disabled
generate-UDP-checksum disabled
max-bandwidth 0
fallback-bandwidth 0
max-priority-bandwidth 0
max-latency 0
max-jitter 0
max-packet-loss 0
observ-window-size 0
parent-realm
dns-realm
media-policy
media-sec-policy msp2
in-translationid
...
...
...
realm-config
identifier backOffice
description
addr-prefix 172.16.0.0/16
network-interfaces M10:0
mm-in-realm enabled
mm-in-network enabled
mm-same-ip enabled
mm-in-system enabled
bw-cac-non-mm disabled
msm-release disabled
qos-enable disabled
generate-UDP-checksum disabled
max-bandwidth 0
fallback-bandwidth 0
max-priority-bandwidth 0
max-latency 0
max-jitter 0
max-packet-loss 0
observ-window-size 0
parent-realm
dns-realm
media-policy
media-sec-policy msp2
in-translationid
...
...
...
last-modified-by admin@console
last-modified-date 2009-11-10 15:38:19
SRTP Pass-Thru Configuration
ORACLE# show running-config
...
...
...
sdes-profile
name sdes1
crypto-list AES_CM_128_HMAC_SHA1_80
srtp-auth enabled
srtp-encrypt enabled
srtcp-encrypt enabled
mki disabled
key
salt
last-modified-by admin@console
last-modified-date 2009-11-16 15:37:13
media-sec-policy
name msp2
pass-through enabled
inbound
profile sdes1
mode srtp
protocol sdes
outbound
profile sdes1
mode srtp
protocol sdes
last-modified-by admin@console
last-modified-date 2009-11-16 15:37:51
...
...
...
realm-config
identifier peer
description
addr-prefix 192.168.0.0/16
network-interfaces M00:0
mm-in-realm enabled
mm-in-network enabled
mm-same-ip enabled
mm-in-system enabled
bw-cac-non-mm disabled
msm-release disabled
qos-enable disabled
generate-UDP-checksum disabled
max-bandwidth 0
fallback-bandwidth 0
max-priority-bandwidth 0
max-latency 0
max-jitter 0
max-packet-loss 0
observ-window-size 0
parent-realm
dns-realm
media-policy
media-sec-policy msp2
...
...
...
realm-config
identifier core
description
addr-prefix 172.16.0.0/16
network-interfaces M10:0
mm-in-realm enabled
mm-in-network enabled
mm-same-ip enabled
mm-in-system enabled
bw-cac-non-mm disabled
msm-release disabled
qos-enable disabled
generate-UDP-checksum disabled
max-bandwidth 0
fallback-bandwidth 0
max-priority-bandwidth 0
max-latency 0
max-jitter 0
max-packet-loss 0
observ-window-size 0
parent-realm
dns-realm
media-policy
media-sec-policy msp2
in-translationid
...
...
...
last-modified-by admin@console
last-modified-date 2009-11-10 15:38:19
Security Policy
A Security Policy enables the Oracle® Enterprise Session Border Controller to identify inbound and outbound media streams that are treated as SRTP/SRTCP. The high-priority Security Policy, p1, (shown below) allows signaling traffic from source 172.16.1.3 to destination 172.16.1.10:5060. The lower-priority Security Policy, p2, (also shown below) matches media traffic with the same source and destination, but without any specific ports. Consequently, SIP signaling traffic (from local port 5060) go through, but the media stream will be handled by appropriate SRTP SA.
security-policy
name p1
network-interface private:0
priority 0
local-ip-addr-match 172.16.1.3
remote-ip-addr-match 172.16.1.10
local-port-match 5060
remote-port-match 0
trans-protocol-match UDP
direction both
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
action allow
ike-sainfo-name
outbound-sa-fine-grained-mask
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
local-port-mask 0
remote-port-mask 0
trans-protocol-mask 0
valid enabled
vlan-mask 0xFFF
last-modified-by admin@console
last-modified-date 2009-11-09 15:01:55
security-policy
name p2
network-interface private:0
priority 10
local-ip-addr-match 172.16.1.3
remote-ip-addr-match 172.16.1.10
local-port-match 0
remote-port-match 0
trans-protocol-match UDP
direction both
local-ip-mask 255.255.255.255
remote-ip-mask 255.255.255.255
action ipsec
ike-sainfo-name
outbound-sa-fine-grained-mask
local-ip-mask 0.0.0.0
remote-ip-mask 255.255.255.255
local-port-mask 0
remote-port-mask 65535
trans-protocol-mask 255
valid enabled
vlan-mask 0xFFF
last-modified-by admin@console
last-modified-date 2009-11-09 15:38:19
SRTP Re-keying
Initialization of SRTP re-keying is supported by the Oracle® Enterprise Session Border Controller.
The Oracle® Enterprise Session Border Controller can generate a new outbound crypto attribute in the SDP offer in a SIP re-INVITE when the srtp-rekey-on-reinvite parameter is set to enabled. The system generates the attribute regardless of the state of the flow, active or not.
This capability is important for some clients that reside on the SRTP side in a single SRTP termination mode configuration. Any media changes that happen in the RTP side are hidden by the Oracle® Enterprise Session Border Controller. This concealment may cause issues in some configurations, where media servers are involved. When the media changes from media server to called phone, the SRTP endpoint is not aware the media source changed because the SDP offer from the Oracle® Enterprise Session Border Controller is the same as original invite. The result is that some devices drop packets because of Synchronization Source Identifier (SSRC) values mismatch, unexpected jumps in sequence number, sequence number reversions back to 1 triggering replay attack defense, and so forth. In certain environment is has been found that re-keying on every re-invite eliminates all these issues especially in customer setups that use Microsoft Lync products.
The processing of standard RE-INVITES (those containing an SDP offer) and offerless RE-INVITES is shown below.
With SDP:
![Processing RE-INVITES with SDP Processing RE-INVITES with SDP](img/invitewithoffer.jpg)
No SDP:
![Processing RE-INVITES without SDP Processing RE-INVITES without SDP](img/invitewithoutoffer.jpg)
If the re-invite message is a refresh and srtp-rekey-on-reinvite is enabled, the outbound crypto will change but the SDP version will not be incremented on the outgoing invite. If this scenario causes incompatibility issues with customer equipment then add the unique-sdp-id option to media-manager, option configuration so the Oracle® Enterprise Session Border Controller increments the SDP version in the outgoing invite.
Modified ALCI Configuration Elements
The action parameter in security-policy configuration mode has been modified to accept additional values, srtp and srtcp.
ARIA Cipher Support
Previous and the current Oracle® Enterprise Session Border Controller releases have provided support for the Secure Real-Time Transport Protocol (SRTP), as defined in RFC 3711, to encrypt and authenticate Real-Time Transport Protocol (RTP) and Real-Time Transport Control Protocol (RTCP) media streams. Concurrent support for Session Description Protocol Security Descriptions (SDES) enabled the exchange of SRTP keying material. These releases have supported a single encryption algorithm, Advanced Encryption System (AES) counter mod with 128-bit keys
This release supports ARIA, a block cipher selected by the Korean Agency for Technology and Standards as a standard cryptographic Technique. The Oracle Oracle® Enterprise Session Border Controller now supports the ARIA cipher with a 192-bit key in counter mode for RTP and RTCP encryption; authentication is supported by HMAC_SHA1 with either 32-bit or 80-bit keys.
Call Flow
An example call flow between a ARIA endpoint, the OracleSD, and a Gateway/Application Server illustrates a successful call establishment where the call is originated from an ARIA enabled phone and destined to a core network server.
ARIA phone Acme SD Gateway/App Server
1. | INVITE/SDP | |
| ----------------> | |
| INVITE/SDP |
| | ----------------> |
2. | 100 TRYING | |
| <---------------- | |
| | 180 RINGING |
| | <---------------- |
| 180 RINGING | |
| <---------------- | |
| | 200 OK/SDP |
| | <---------------- |
3. | 200 OK/SDP | |
| <---------------- | |
| ACK | |
| ----------------> | |
| | ACK |
| | ----------------> |
| | |
4. | <-SRTP/ARIA media->| <- RTPmedia flow ->|
- The ARIA-enabled phone sends an INVITE request to the SD with the crypto attribute in the SDP specifying the ARIA 192 CM cipher for encryption and HMAC_SHA1_80 for authentication. The crypto attribute also has the master key encoded in base-64 format, as well the mki parameters (optionally). The SD forwards the INVITE to the called party via the gateway according to the media-security-policy on the outbound realm.
- The SD sends provisional response to INVITE request
- Assuming that the SD gets successful answer from called party, the SD sends a 200 OK response to the caller, with the crypto attribute in the accompanying SDP specifying the ARIA 192 CM cipher for encryption and HMAC_SHA1_80 for authentication. The crypto attribute also has the master key, as well the mki parameters (optionally).
- The ARIA-enabled phone acknowledges the reception of 200 OK final response. At this point, encrypted SRTP traffic using the ARIA 192 counter mode cipher flows between the phone and the SD, and unencrypted traffic flows between the SD and the core network.