Secure RTP support for SR140

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.  This feature does not cover securing T.38 media or securing call-control (SIP over TLS).

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’.  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)’.

This feature covers the addition of SDES for key exchange for establishment of SRTP on the SR140.  Data security protocols such as SRTP rely upon a separate key management system to securely establish encryption and/or authentication keys.  The key exchange mechanism commonly used in VoIP sessions is called SDES (Security Descriptions for Media Streams).  Using SDES the SRTP keys are negotiated in the SDP of the offer/answer model of a SIP exchange, using an SDP attribute called “crypto” which provides the cryptographic parameters of the requested media stream and other parameters that can be used to configure the SRTP media stream. 

The use of SDES to exchange the keys is not a secure method, since the crypto key is transferred in the SDP as plain text string.  The SDP “crypto” security description is normally used where IPsec, TLS, or some other encapsulating data-security protocol protects the SDP message.  SIP layer security between SIP Client and SIP Server, such as SIP TLS will be required by some customers to use SDES.  However, this document focuses only on the SDES key exchange to establish the Secure RTP session. 

If the fax session is re-invited to T.38, the T.38 media will not be secure. This feature will only secure the fax media when G.711 RTP mode has been selected.  Secure T.38 media will be addressed with a seperate feature request.  FR17636 : Add support for secure T.38 media

Assumptions

• • Forward Error Correction (FEC) is not required.
  • On SDES offer, the SR140 will support only one crypto attribute per media type.  If more than 1 crypto attribute is offered, we need to define the SR140 behavior.
  • SIP security preconditions (sprecon) will not be supported

Requirements

Revision History

User interaction and design

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:

 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 a 128bit 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:

Not Doing

Exploring Tasks

Due to time constraints, it was desided to not create a HLD but perform prototype work and document the exploration.  The notes as part of the investagate are attacked to the appropiate JIRA tasks.