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
| # | Title | Importance | Notes |
|---|---|---|---|
| 1 | SHALL support SDES (RFC4568) key exchange to establish SRTP (RFC3711) Media streams | Must Have |
|
| 2 | SHALL support SDES-SRTP with or without SIP TLS session establishment. | Must Have | |
| 3 | SHALL support SDP 'crypto' attribute to exchange SDES-SRTP encryption keys. | Must Have | |
| 4 | SHALL support the following crypto suites:
| Nice to Have | AES_CM_128_HMAC_SHA1_80 is required |
| 5 | SHALL support the key-method 'inline' for crypto SDP attribute: “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 and length of the MKI field in SRTP packets | Must Have | By default the lifetime should be forever or the largest possible value. |
| 6 | SHALL support key timeouts and refresh as specified by RFC4568 and key exchange parameters | Must Have | |
| 7 | Configuration Parameters. The configuration parameters for SRTP SHALL be contained within its own configuration file. The callctrl.cfg SHALL define a parameter to state if SRTP is enabled. | Must Have | |
| 8 | When SRTP is enabled, the callctrl.cfg SHALL define a parameter for the location of the of the SRTP configuration file. | Must Have | The parameters in the SRTP configuration file only apply when SRTP is enabled. |
| 9 | The parsing of the configuration parameters SHALL be present in the ecc.log file. | Must Have | |
| 10 | Lifetime: this value determines the maximum number of SRTP/SRTCP packets that can be transmitted using the master key selected for the session. | Optional | Will be to be non-configurable for the initial release. |
| 11 | Accept: this is a boolean value that enable processing of SDPs with crypto-attributes. note that if an ingress message (i.e. INVITE) contains SDP without crypto-attributes, the system shall still process the request. When "Disabled", messages with crypto-attributes are rejected. | Optional | This is to enable receiving SDP with crypto with SRTP enabled. |
| 12 | Number of Keys: this is an integer value that specifies the number of keys to use in the key rotation refresh. | Optional | Checking on need to support multiple crypto keys. Was not required for MRB implementation. Will just be 1. |
| 13 | Window Size Hint: this is an integer value that sets the SRTP window size to protect against replay attacks. | Optional | Not sure about the Window Hint, but Jon M think this is pretty standard. |
| 14 | Enforce: this is a boolean value that enable/disable mandatory enforcement of ingress calls to contain crypto-attributes. The system shall reject all calls that do NOT contain crypto-attributes in the SDP media lines. | Optional | |
| 15 | Unencrypted SRTP: this is a boolean value that enable/disables receiving unencrypted SRTP packet payloads. | Optional | |
| 16 | Unencrypted SRTCP: this is a boolean value that enable/disables receiving unencrypted SRTCP packet payloads. | Optional | |
| 17 | SRTP keys include a public and private key and have standard formats. | ||
| 18 | Use Case 1: SIP Invite with SDES - SR140 SHALL support receiving SDES in a receiving call. SIP Invite has Offer SDP with EP 'crypto' attribute. SR140 answers with crypto to establish the SRTP session. | ||
| 19 | Use Case 2: SIP Invite with SDES - SR140 SHALL support sending SDES in a transmitting call. SIP Invite has SDP with EP 'crypto' attribute. | ||
| 20 | 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. | Must Have | Part #951-105-20
|
| 21 | 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. | Must Have | |
| 22 | Documentation. The Brooktrout documentation SHALL be updated in the appopiate manuals. Should include information on security license, SRTP configuration in callctrl.cfg and SRTP configuration file including configuration of keys. Nice to have a usage example in documentation or tech note. | ||
| 23 | Export requirements SHALL be completed to support releasing a product with security features | Must Have | Will be completed with SIP over TLS. |
| 24 |
Revision History
Version | Author | Date | Description of Changes |
|---|---|---|---|
| 0.1 | JGS | 02/17/2017 | Initial Draft |
| 0.8 | JGS | 02/23/2017 | Draft will open questions. |
| 0.9 | JGS | 06/05/2017 | Updates to answer some of the open questions. |
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:
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 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:
| Question | Outcome |
|---|---|
| Default setting for Unencrypted SRTP? This is a boolean value that enable/disables receiving unencrypted SRTP packet payloads. | Thoughts are if a system has security features enabled to not allow non-secure calls. This settings are a nice to have. |
| Default setting for Unencrypted SRTCP? This is a boolean value that enable/disables receiving unencrypted SRTCP packet payloads. | |
| How are keys updated during a fax session. HMP selected a default Lifetime value to attempt to not update the key during a session. It does not prevent the remote sending from updating their keys. Do we want this to be configurable or do we just use a key per session with the large default setting? | The lifetime value should be set to the max and the parameter is a nice to have. |
There is a NULL invite and 3rd PCC use cases with the XMS. Are these use cases required for SR140? | This is not required. |
| Do we need to support multiple crypto keys? HMP has the ability to support multiple key rotation (up to 20) for a single session. Multiple crypto key rotation per session using Master Key Identifier (MKI) | No. Only a single key will be used. |
| Are we expecting the remote to updated their transmit key during a fax session (Lifetime expired)? | No. Expecting fax sessions to complete before lifetime expires. |
What about the enabling or disabling of SRTP authentication? | |
| Support switching between RTP to SRTP or SRTP to RTP in mid-session? | Again by default if SRTP is enabled then it should force SRTP encryption. No changing mid-session.
|
| Support setting the advance notification time (100 ms units) that the current encryption key is about to expire? | We should not need to switch keys during a session with the max lifetime setting. |
Support the setting of the thresholds for the SRTP alarms (authentication failure, packet replay detection and Master Key Identifier (MKI) mismatches)? | Will not be available in initial release. |
| Support enabling or disabling the advance notification time for key expiry and the SRTP alarms? | We should not need to switch keys during a session with the max lifetime setting. |
| Support changing the key derivation rate? | |
| Support different lifetimes for SRTP and SRTCP? Depending on whichever expires first, the key would then need to be changed. | We should not need to switch keys during a session with the max lifetime setting. |
| Support for F8_128_HMAC_SHA1_80? | This is a future requirement. |
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.
0 Comments