Configuring SIP Support for SRTP

The table below lists the default and recommended SRTP settings.

Before an SRTP session can be established on a Cisco IOS voice gateway or Cisco UBE, the following cryptographic information must be exchanged in SDP between the two endpoints:

• Crypto suite--crypto algorithm {AES_CM_128_HMAC_SHA1_32} and the supported codec list {g711, G729, G729a}. There could be one or more crypto suites. Cisco IOS Release 12.4(15)T supports only one crypto suite.
• Crypto context--16-byte master key and a 14-byte master salt.

The SRTP library provides an application program interface (API), srtp_generate_master_key, to generate a random master key. For encryption and authentication purposes, the key length is 128 bits (master key and session keys). Additionally, RFC 3711 introduces "salting keys"--master salts and sessions salts--and strongly recommends the use of a master salt in the key derivation of session keys. The salting keys (salts) are used to fight against pre-computation and time-memory tradeoff attacks.

The master salt (also known as the n-bit SRTP key) prevents off-line key-collision attacks on the key derivation and, when used, must be random (but can be public). The master salt is derived from the master key and is used in the key derivation of session keys. Session salts, in turn, are used in encryption to counter various attacks against additive stream ciphers. All salting keys (master salt and session salts) are 112 bits.

If you configure the gateway for SRTP (globally or on an individual dial peer) and end-to-end TLS, an outgoing INVITE message has cryptographic parameters in the SDP.

If you use the srtp fallback command and the called endpoint does not support SRTP (offer is rejected with a 4xx class error response), the gateway or Cisco Unified Border Element sends an RTP offer SDP in a new INVITE request. If you do not configure the srtp fallback command, the call fails.

Note	In Cisco IOS Release 12.4(20)T and later releases (and, for Cisco UBEs, in Cisco IOS Release 12.4(22)T and later releases), calls established with SRTP only (and not SIPS) will succeed even if the srtp fallback command is not configured.

When a gateway or Cisco Unified Border Element receives an SRTP offer, negotiation is based on the inbound dial peer if specified and, if not, the global configuration. If multiple cryptographic attributes are offered, the gateway selects an SRTP offer it supports (AES_CM_128_HMAC_SHA1_32). The cryptographic attribute will include the following:

• The tag and same crypto suite from the accepted cryptographic attribute in the offer.
• A unique key the gateway generates from the SRTP library API.
• Any negotiated session parameters and its own set of declarative parameters, if any.

If this cryptographic suite is not in the list of offered attributes, or if none of the attributes are valid, the SRTP negotiation fails. If the INVITE message contains an alternative RTP offer, the gateway (or Cisco UBE) negotiates and the call falls back to (nonsecure) RTP mode. If there is no alternative offer and the SRTP negotiation fails, the INVITE message is rejected with a 488 error (Not Acceptable Media).

There is no rekeying on an SRTP stream. A REINVITE/UPDATE message is used in an established SIP call to update media-related information (codec, destination address, and port number) or other features, such as call-hold. A new key need only be generated if the offer SDP has a new connection address or port. Because the source connection address and port do not change, the gateway or Cisco UBE will not generate a new master key after a key has been established for an SRTP session.

If a gateway receives a call hold REINVITE message after an initial call setup is secured, the gateway places the existing SRTP stream on hold, and its answer in the 200 OK message depends on the offer SDP. If there is a cryptographic attribute in the offer, the gateway responds with a cryptographic attribute in its answer.

A proxy can fork an INVITE message that contains an SRTP offer, which can result in multiple SRTP streams until a 200 OK message is received. Because the gateway always honors the last answer, the gateway deletes previous SRTP streams and creates a new stream to the latest endpoint. Other endpoints might also stream to the gateway, but because the DSP knows only the last streams's cryptographic suite and key, authentication on these packets fails, and the packets are dropped.

A gateway redirects a call when an INVITE message, sent to a proxy or redirect server, results in a 3xx response with a list of redirected contact addresses. The gateway handles a 3xx response based on the schema in the contact of a 3xx message. If the message is SIP, and you configure the call for SRTP with fallback, the gateway offers an SRTP-only redirected INVITE message. If you configure for SRTP only, the offer is SRTP only.

If the schema is SIP, and you use the srtp fallback command to configure the call for RTP with fallback, the INVITE message has an RTP offer. If you do not configure the srtp fallback command, the call fails.

Note	In Cisco IOS Release 12.4(20)T and later releases (and, for Cisco UBEs, in Cisco IOS Release 12.4(22)T and later releases), calls established with SRTP only (and not SIPS) will succeed even if the srtp fallback command is not configured.

The SIP Support for SRTP feature interaction with call transfer depends on your outbound dial peer or global configuration. During a call transfer, the gateway sends an INVITE message to establish the connection to the transfer target. The gateway includes an SRTP offer in the INVITE message if the outbound dial peer or global configuration includes the SRTP offer.

The T.38 transport supported is User Datagram Protocol (UDP). A T.38 call is initiated as a voice call, which can be RTP or SRTP, and when it switches to T.38 fax mode, the fax call is not secure. When the fax is switched back to voice, the call returns to its initial voice state.

For conferencing calls, the incoming INVITE message does not match any inbound dial peer and the message body is sent to the application in a container. The conferencing application performs the necessary negotiation and replies through PROGRESS or CONNECT events.