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 pkcs7mime 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 enduser 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 bitwise 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 HMACSHA-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/grads
tudents/DigestAuthenticationReport.pdf
