SIP Security BY, Vivek Nemarugommula. vulnerabilities Registration Hijacking.

SIP Security

BY,

Vivek Nemarugommula

vulnerabilities

Registration Hijacking

Proxy Impersonation

Message Tampering

Session Tear Down

Denial of Service (DoS)

SIP Security Architecture

Digest Authentication Sip Provides A challenge-based mechanism for

authentication that is based on authentication in HTTP.

This scheme is known as Digest authentication due to the use of MD5 hashing function on the username/password combination

When a client tries to establish a connection with UAS, registrar, or redirect server, the server sends the 401 Unauthorized response to challenge the identity of a UAC.

When the client initializes a connection with a proxy server, the proxy responds with the 407 Proxy Authentication Required to challenge the UAC.

Challenge Based Authentication

Digest Authentication Headers SIP uses headers for Authentication The WWW-Authentication header is used in 401

response message sent by the server. In response to the 401 challenge, the UA should include

a Authorization header containing the credentials in the next request.

Similarly, the Proxy-Authenticate header is used in 407 response message sent by the proxy.

Description Of Parameters

After the client receives the 401 or 407 challenge from the server, it re-submits a request with the credentials by including an Authorization (in response to 401) or Proxy-Authorization (in response to 407) header field with request.

Parameters in Authorization Header

Digest Calculation The Method of calculating the Request-Digest is as

follows: Default algorithm MD5 is used.

Digest Calculation

Problems with Digest

Hash is weak Authenticating a request to more

than one element is problematic Leaks hash to elements in the path Not well implemented In practice, DIGEST is only good for authenticating to the first hop

Secure MIME (S/MIME) SIP messages carry MIME bodies and the MIME standard

includes mechanisms for securing MIME contents to ensure both integrity and confidentiality by means of the multipart/signed and application/pkcs7-mime MIME types

Provides end-to-end integrity protection and encryption of the body and parts of the message header

X.509 certificates are used to identify the end users on the basis of their email addresses which are part of the SIP URI

The signing of MIME bodies is the lesser problem since each user is in possession of her private key and the user certificate may be forwarded to the recipient embedded into the pkcs7-mime or pkcs7-signature attachments

S/MIME

On the other hand the encryption of MIME bodies, e.g. the Session Description Protocol (SDP) payload [HJ98] requires the foreknowledge of the recipient’s public key. This key, usually certified by X.509 certificate must either be pre-fetched from a public directory or may be requested from the peer via a special SIP message.

Any mechanisms depending on the existence of end-user certificates are seriously limited in that there is virtually no consolidated authority today that provides certificates for end-user applications on a global scale.

Protecting the Signaling: TLS

Hop-by-hop transport security Typically, endpoints enter into a

serverauth relationship with a server and authenticate using DIGEST

Problems With TLS

Key distribution makes mutual authentication impractical (so far)

Only protects one hop - no assurances of what happens beyond that hop

SIPS “Secure” sip, like https is to http Proxies receiving a sips request are required to forward

only on secure transports (weakened in private domains)

Not as strong as https - no way to tell if a proxy doesn’t conform to the requirement

Protecting the Media: SRTP Encrypts individual media packets using a symmetric

session key. Session key must be securely exchanged - current

recommendation is to use S/MIME in the signaling.

The Secure Real-Time Transport Protocol (SRTP)

Both RTP and RTCP packets can be cryptographically secured by the Secure Real-time Transport Protocol (SRTP) and the companion Secure Real-time Transport Control Protocol (SRTCP)

The Secure RTP Packet Format:

only the RTP payload body (including any RTP padding if present) is encrypted.

The Master Key Identifier (MKI) field is optional and identifies the master key from which the session keys were derived.

The 16 bit sequence number already present in the RTP packet is used together with a 32 bit rollover counter (ROC) which is part of the cryptographic context for the SRTP session to prevent replay attacks.

The authentication tag is a cryptographic checksum computed over both the header and body of the RTP packet.

Secure RTP Packet Format

The Secure RTCP Packet Format

RTCP (continued) The RTP control packets are secured in a similar way as

the RTP packets themselves, one difference being that the use of the authentication tag is mandatory.

Otherwise it would be possible for a malevolent attacker e.g. to terminate an RTP media stream by sending a BYE packet.

An additional field is the SRTCP index which used as a sequence counter preventing replay-attacks.

The MSB of the index field is used as an Encryption flag (E) which is set if the RTCP body is encrypted.

Default Encryption Algorithms

Encryption using AES in counter mode.

In principle any encryption scheme can be used with SRTP.

As default algorithms the NULL cipher (no confidentiality) and the Advanced Encryption Standard in Counter Mode (AES-CTR) are defined.

AES in counter mode acts as a keystream generator producing a pseudo-random keystream of arbitrary length that is applied in a bit-wise fashion to the RTP/RTCP payload by means of a logical XOR function, thus working as a classical stream cipher.

In order to work as a pseudo-random generator AES is loaded at the start of each RTP/RTCP packet with a distinct initialization vector (IV) that is derived by hashing a 112 bit salt_key, the synchronisation source identifier (SSRC) of the media stream, and the packet index.

Encryption (continued) Encrypting this IV results in an output of 128 pseudo-

random bits.

By counting the IV up by increments of one as many keystream blocks can be generated as are required to encrypt the whole RTP/RTPC payload.

AES used in counter mode instead of the more common cipher block chaining mode (CBC) has the big advantage that the keystream can be precomputed before the payload becomes available thus minimizing the delay introduced by encryption

Default Authentication Algorithm

Authentication using HMAC-SHA-1

The default SRTP message authentication algorithm is HMAC-SHA-1 , based on the popular 160 bit SHA-1 hash function.

Cryptographical security is achieved by hashing a 160 bit secret auth_key into the checksum which is then truncated to 80 bits in order to reduce the packet overhead and which has the further advantage that it hides the complete internal state of the hash function.

In applications where transmission bandwidth is a problem the authentication tag might be weakened to 32 bits.

Session Key Derivation The encryption and authentication algorithms described

earlier both require secret symmetric session keys that must be known to all user agents participating in a SIP session.

The SRTP standard offers a partial solution by deriving all needed session keys from a common master key but leaves open the distribution of the master key itself.

Again the AES block cipher is used in counter mode to generate the necessary keying material.

The pseudo-random generator is loaded with an IV that is itself a function of a 112 bit master_salt value, a one byte label and a session key number .

Continued By applying the labels 0x00 up to 0x05, encryption,

authentication and salting keys for both SRTP and SRTCP are derived from the same master key.

If a key derivation rate has been defined then every time a number of packets equivalent to the key derivation rate have been sent, a new set of either SRTP or SRTCP session keys are computed.

Session Key Derivation (cont)

Conclusions DIGEST is only good for authenticating to the first hop.

Authenticating a request to more than one element is problematic

S/MIME Suffers from same key distribution issue hindering mutual-auth TLS.

Needs research on improving protection through SIP Identity.

Improving Protection through certificates and credentials.

References

SIP Security Andreas Steffen, Daniel Kaufmann,

Andreas Stricker http://www.site.uottawa.ca/~bob/

gradstudents/DigestAuthenticationReport.pdf