Secure RTP support for SR140

Target release	6.8.0
Epic	Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
Feature Request	Unable to locate Jira server for this macro. It may be due to Application Link configuration.
Document status	DRAFT
Document owner	John Shaheen

Goals

- The purpose of this feature is to provide media encryption for traditional SIP and VoIP environments
- Enable SRTP through standard SDP parameters, with and without need for SIP TLS

Background and strategic fit

SDES is a method to pass encryption keys through standard SDP. Customers are looking to be able to encrypt media on SIP and standard VoIP networks. This feature will support securiting the fax media stream when using G.711 mode. It does not cover secure T.38 media and secure call-control (SIP over TLS).

Assumptions

Requirements

#	Title	Notes
1
2
3
4
5
6
7
8	SRTP supported on by a single license keywork (Security). This keyword enables SRTP functionality on a per system basis. Add on part will need to be defined to add security to an existing SR140 deployment. This part will be added to the back office for normal order processing and will allow the end user to activate a security LAC via the current methods. The SR140 base feature license will not include Security support. Added support MUST require a seperate add-on LAC for security.	Part #951-105-20
9	COO Will need to be updated with changes to include the updated IPP (version 8.2.x) into the product. Will be required for both Windows and Linux.

Revision History

Version	Author	Date	Description of Changes
1.0	JGS	02/17/2017	Initial Draft

User interaction and design

Introduction

This document provides a high-level technical description of the customer request for adding support for SRTP for G.711 on the SR140. This document will cover SDES SRTP as defined by RFC 4568 : ‘Session Description Protocol (SDP) Security Descriptions for Media Streams’ to PowerMedia XMS. SDES (Session Description Protocol Security Descriptions for Media Streams) is a key exchange mechanism used to negotiate encryption of VoIP sessions using Secure RTP (SRTP), defined by RFC 3711: ‘The Secure Real-time Transport Protocol (SRTP)’.

SDES SRTP Usage

The SDES “a=crypto” attribute is used in the Offer/Answer model, defined in RFC3264, to establish secure unicast RTP streams. To establish the SRTP session, the SIP Offer contains one or more crypto attributes, each with a unique tag. The crypto attribute only appears at the SDP media level, under the associated m= media line (not at the session level). The crypto field describes the cryptographic suite, key parameters and session parameters for the media line. The “inline” parameter conveys the key data (master key) used by the endpoint to encrypt the media stream it sends. (The EP conveys the transmit direction in its offer SDP). The same keying data will be used by the receiver to decrypt those streams. There may be one or more key (ie, inline) parameters in a crypto attribute, separated by a semicolon.

The SIP Answer accepts one of the offered crypto attributes by returning the same tag and crypto-suite with its own key(s) and key parameters used to encrypt the answer stream. Each endpoint determines its own transmission keys for that media line which it sends in the SDP to the other endpoint. This exchange is shown in Figure 1, which is an example of a caller and called endpoint which have chosen crypto-suite AES_CM_128_HMAC_SHA1_80 and exchange the key they will use to encrypt the stream. If there is no accepted crypto attribute or SRTP cannot be supported for the media, the offered media stream is rejected.

Note: The called party will always return a key irrespective of media stream direction (sendonly, receiveonly) since even if SRTP is not returned, SRTCP may still be active. Both SRTP and SRTCP packet payloads are encrypted by default.

Once a session has been established it may be modified at any time in order to perform re-keying or change or remove the crypto-suite. (ie a new crypto suite can be used or a new master key can be established)

The SDES crypto attribute has the following format:

a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]

Tag:

Tag is a parameter that identifies the specific crypto attribute line.

Crypto- Suite:

typedef enum

{

IPM_CRYPTO_AES_CM_128_HMAC_SHA1_80 = 1,

IPM_CRYPTO_AES_CM_128_HMAC_SHA1_32 = 2

} eIPM_CRYPTO_SUITE;

Advanced Encryption Standard (AES 128) in Counter Mode with HMAC-SHA-1 Message Authentication Code (MAC)

AES_CM_128_HMAC_SHA1_80 (default). This is default AES standard. It offers a128bit master key with 80 bit authentication tag
AES_CM_128_HMAC_SHA1_32 - This crypto-suite is similar to the AES_CM_128_HMAC_SHA1_80 crypto-suite except it offers a 32 bit authentication tag

Key Parameters:

There is only one key-param defined by RFC4568. The key-method is “inline”, the key-info for inline contains the master key. SRTP security descriptions use the “inline” key method. A single master key is used or installed to derive the session keys for SRTP encryption and authentication.

“inline:” <key||salt> [“|”lifetime] [“|” MKI “:” length]

key || salt – concatenated master key and salt, base64 encoded
Lifetime – masterkey lifetime (max number of SRTP or SRTCP packets using this master key)
MKI:length – MKI (Master Key Identification) and length of the MKI field in SRTP packets

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Question	Outcome

Not Doing