Vous êtes sur la page 1sur 5

Mutual Authentication for SIP:

A semantic meaning for the SIP opaque values

Thomas Guillet, Ahmed Serhrouchni Mohamad Badra
Dept. Computer Sciences and Networks LIMOS Laboratory, UMR 6158
TELECOM ParisTech, Institut TELECOM CNRS France
Paris, France badra@isima.fr
{guillet, ahmed}@enst.fr

Abstract—The Session Initiation Protocol (SIP) is rapidly (Session Initiation Protocol) [1] are usually deployed with a
becoming the dominant signalling protocol for calls over the simple authentication and not necessarily in a trust domain.
Internet. It has quickly made large inroads into the Voice over IP These networks and applications are widely deployed and
(VoIP) market. SIP is an application-layer control operating on implemented and therefore any modification to their
top of a transport protocol and allows to create, modify, and functionalities undoubtedly involves interoperability issues.
terminate sessions with one or more participants. With security Consequently, proposed solutions should be backward
considerations, these operations require authentication from compatible with existing deployed protocols in telephony
participating end-points, confidentiality, data integrity, and domain such as SIP. SIP is currently very popular in the
protection against internal and external attacks. For
telecommunications industry because it allows to easily
authentication, SIP relies on HTTP Digest by default; the client is
develop new services.
authenticated to the SIP proxy server. In order to have mutual
authentication between client and server, SIP could be SIP is an application layer signalling protocol for
implemented over TLS (Transport Layer Security) when TCP is transmitting and managing voice, video or data. SIP is based on
supported by SIP architecture network. In this paper, we client/server architecture with intermediate proxies to convey
propose a mutual authentication mechanism within HTTP Digest signalling and voice packets between multiple SIP applications.
since this later is implemented by default in all SIP environments. SIP, like any other internet applications, has to be protected
It consists in providing meaning and semantic to some of the against internal and external attacks; security mechanisms are
parameters’ values generated by the participating end-points
required on both application and network layers. SIP uses
during SIP session establishment, especially to the “nonce”
values. Our solution is backward-compatible with today
protocols such as TCP [9], UDP [8] or RTP (Real-time
implementations. Without being in opposition to security Transport Protocol) [11]. Consequently, SIP inherits the
protocols like TLS, this approach helps in reducing DoS (Denial vulnerabilities of these protocols [26]. The text-based nature of
of Service) attacks, detects server identity spoofing and ensures SIP messages gives more opportunities for attacks like
basic mutual authentication with comparison to HTTP digest. spoofing. The use of malicious SIP messages is also possible
and can be the cause of unauthorized access and DoS attacks
Keywords-component; SIP; Security; HTTP Digest; ToIP; [17]. This is why security begins by using security mechanisms
VoIP; TLS (Transport Layer Security); IPSec; Authentication and like those deployed in data networks (firewall, authentication,
Key Agreement (AKA) encryption, etc.). Modern security protocols such as TLS [14],
IPSec [7] and SRTP (Secure RTP) [12] could be deployed with
I. INTRODUCTION SIP to improve security.
In the first generation of networks, services were based on Security mechanisms on the network-layer may protect
client-server architectures. The networks were considered signalling and voice packets exchanged between proxies
trusty, the objective was to provide services with a minimum against eavesdropping and spoofing, and build trustworthy
level of security based on a challenge/response; the server boundaries. This is what we call protection against external
sends a “nonce” to the client, to which the client applies a attacks. These attacks are inherited from network protocols
cryptographic function on the received “nonce” using a shared since SIP operates over a transport protocol. The internal
password. Thus, only the client is authenticated, which attacks operate on the application layer. They take various
therefore opens the door to many active and passive attacks; forms, ranging from identity usurpation to spam call
especially man-in-the-middle and identity spoofing attacks. generation. To defend against such attacks, the application
layer defines two security modes: end-to-end and hop-to-hop,
Some modern networks take into account the new need for and proposes various security mechanisms for each mode such
security and implement some mutual authentication as S/MIME [15] for the first mode and HTTP Digest [3] for the
mechanisms: for example AKA (Authentication and Key second.
Agreement) [5] and A3-A8 [22] are respectively deployed for
3G and 2G mobile networks to mutually authenticate the In this paper, we focus on SIP security solutions based on
entities using challenge-response mechanisms. Unfortunately, HTTP Digest, which is used to authenticate clients to proxies.
applications such as Voice over IP [10] and especially SIP First, we briefly present SIP messages such as INVITE and

978-2-9532443-0-4 © 2008 ESRGroups France 1

Authorized licensed use limited to: National Chi-Nan University Library. Downloaded on September 28, 2009 at 00:53 from IEEE Xplore. Restrictions apply.
REGISTER. In section 3, we present and analyze HTTP III. SIP AND HTTP DIGEST
Digest. After we expose a related work in section 4 and In this section, we present the main SIP authentication
describe our solution in section 5. Then, our concluding mechanism: “HTTP Authentication”. The authentication in
remarks and future works are presented in section 6. essence is a process of verifying the authenticity of one
identity, in which the SIP network only checks User Agent
II. SIP: SHORT OVERVIEW legitimate. Other mechanisms are conceivable for simple or
SIP is a real time signalling protocol for Voice over IP that mutual authentication like TLS or S/MIME; but these solutions
was developed by the Internet Engineering Task Force (IETF) are more difficult to implement and for S/MIME authentication
[1]. It is used for bi-directional communication session is only made between user agents. To improve SIP security,
initiation between two or more nodes. SIP defines messages to our works focused on HTTP Digest Authentication since this
establish, modify and terminate a session. Developed for the mechanism is implemented everywhere.
telephony over IP, it provides basic telephone call. However,
SIP is also used in Instant Messaging, and can support many A. SIP authentication mechanism
other applications. Authentication offered by SIP is defined in the RFC 2617
SIP is an application level protocol, so it can be used on top [2] and called “HTTP Authentication”. This mechanism has
of different protocols. It can be carried by UDP [8] or TCP [9]. been chosen because SIP has been developed on HTTP
UDP provides speed efficiency, and TCP is used to ensure data client/server architecture. HTTP Authentication provides two
reliability required for security protocols such as TLS. For methods for a user to authenticate: the basic one and the digest
voice media, SIP usually operates on top of RTP [11]. SIP access authentication. The first one is not recommended by
provides generic session establishment with standard SIP, because user and password are passed over cleartext. So
signalling. Any service like chat could be developed with SIP the chosen mechanism for SIP is the Digest access
and generic IP protocols. This principle explains why SIP is authentication. HTTP Digest provides a challenge/response and
rapidly becoming the dominant signalling protocol for calls uses by default MD5 algorithm [4].
over the Internet. From the security point of view, SIP could After a REGISTER sent by a UA, the SIP proxy server
use Internet solutions like SRTP [12] to ensure voice generates the challenge and sends the response “401
confidentiality. Unauthorized” via the field “WWW-Authenticate”:
SIP is a request/response protocol between a client and a SIP/2.0 401 Unauthorized
server, similarly to HTTP. It composes of different components Via: SIP/2.0/UDP;received=
such as User Agent (UA), redirect server, registrar server, From: <sip:ahmed@enst.fr>
To: <sip:ahmed@enst.fr>;tag=as7b4af592
location server and proxy server. This architecture enables five Call-ID: D8A5240D579C4D6E8CE1@enst.fr
capabilities: User location, User availability, User capabilities, CSeq: 7168 REGISTER
Session setup, and Session management. In the telephony User-Agent: Asterisk PBX
application, the User Agents could be a soft or a hard phone Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
that generates and receives request/response. SUBSCRIBE, NOTIFY
Max-Forwards: 70
SIP uses a set of request messages including INVITE, Contact: <sip:ahmed@>
ACK, CANCEL, OPTIONS, BYE and REGISTER. A User WWW-Authenticate: Digest realm="asterisk", nonce="64d45b88"
Content-Length: 0
Agent, wishing to initiate a session, sends an INVITE message.
This message is responded by an OK followed by an ACK The SIP User Agent uses the “nonce” to build the
message. When a UA wants to terminate the session, it sends a “response”. The “response” is computed using username,
BYE. The CANCEL cancels the INVITE before the OK. password, method (i.e. REGISTER), “Request-URI”, “nonce”
OPTIONS is used to interrogate servers about their and “realm”. The basic “nonce” computation is made with the
capabilities. SIP traffic is a plain text exchange, and is encoded following RFC 2617 [2] formalism:
using the UTF-8 charset [23]. These messages contain the user
parameters for appropriate transmission data use during one • H(A1) = MD5(username”:”realm”:”password)
session. These parameters are described by the protocol SDP • H(A2)=MD5(METHOD”:”Request-URI)
(Session Description Protocol) [16].
• response=MD5(H(A1)”:”nonce”:”H(A2))
As Internet, SIP isn’t created with robust security
mechanisms. Some solutions have been developed to improve With the example parameters:
its security, but the multitude of protocols or implementations
create interoperability problems. Encoded text facilitates easy • H(A1) = MD5(ahmed:asterisk:password)
analysis with standard tools of Internet. Attackers can easily • H(A2)=MD5(REGISTER:sip:enst.fr)
download free software to sniff packet and analyse networks
[24]. IP telephony infrastructure could be attacked by using a • response=MD5(H(A1): 64d45b88:H(A2))
large collection of hacker tools [25]. The authentication based Password is provided with username during SIP account
on HTTP Digest mechanism is one of SIP weakness, the reason creation. This paper doesn’t handle the method used to
why this paper proposes a new approach to improve SIP distribute this shared secret. So the REGISTER message with
security. the “response” is:

Authorized licensed use limited to: National Chi-Nan University Library. Downloaded on September 28, 2009 at 00:53 from IEEE Xplore. Restrictions apply.
Via: SIP/2.0/UDP
From: <sip:ahmed@enst.fr> Digest authentication (Fig. 1) is a common authentication
To: <sip:ahmed@enst.fr> mechanism. This solution became famous with web services.
Contact: "Serhrouchni" <sip:ahmed@> The principle is relies on a simple challenge-response
Call-ID: D8A5240D579C4D6E8CE1@enst.fr authentication. The server challenges the client with a request.
Expires: 500 Then the client provides authentication information with a
Authorization: Digest digest to demonstrate its knowledge of the shared secret. This
username="ahmed",realm="asterisk",nonce="64d45b88",response="e2 mechanism results in client authentication but doesn’t provide
2a354a2eb630906d5527bb0c45ea8a",uri="sip:enst.fr" mutual authentication.
User-Agent: X-Lite build 1059
Content-Length: 0 client server
The proxy server uses the same process as the client to request
nonce secret
create its own digest and compares it for equality to the digest
secret challenge
sent by the client. If the two values are equal, the server
authenticates the client. This authentication is necessary for digest
each request (REGISTER and the others). The first
authentication is made during registration. The server checks
responce no client
that the user is legal. = unautenticated
B. SIP Authentication security considerations client
The main security considerations are given by RFC 2617 autenticated
[2]. The essential announcement is that the Digest Figure 1. The Digest authentication mechanism
Authentication does not ensure a strong authentication To register, a SIP user should be authenticated by the
mechanism with comparison to the other usual mechanisms. server. This security solution isn’t acceptable for critical
However, this elementary solution circumscribes usurpation of applications like Telephony over IP. HTTP Digest could be
identity. Hackers can download free software such as Cain more robust with a long password, but this is still a simple
[18] to sniff packet and guess passwords. The SIP profile could authentication. Some applications implement today a different
be easily intercepted and used by a hacker if the password is mechanism to mutually authenticate the entities using
too short. This vulnerability is bound to authentication based challenge-response mechanisms like AKA. It is the same
on HTTP Digest mechanism and consequently, authentication situation for authentication in cellular mobile communication.
is particularly difficult to achieve in SIP. It is worth noting that Global System for Mobile (GSM) provides simple
in a SIP transaction, there are a number of intermediate authentication. With the Universal Mobile
elements and therefore the authentication is an essential trusted Telecommunications System (UMTS), there is an improvement
factor. with the AKA mechanism [3]. This solution enables a mutual
The security analysis of SIP presented in [6] shows that an authentication between a mobile phone and the network. This
attacker who is able to impersonate a proxy server can do security policy requires a shared secret key and a shared
damage like deny of services. The illegal server can know all cryptographic algorithm that exist in SIP.
transactions and so all the private life details. Mutual SIP could be deployed in different networks with mutual
authentication should be a requirement, but it’s not specified in authentication like 2G mobile networks or in an Internet
the SIP requirement. There are certainly other mechanisms to network with simple authentication, that why mutual
strengthen authentication such as TLS [14] or IPSec [7]. But authentication implementation in SIP is important. Two options
the problem is still the interoperability. Relying on TCP is are possible to improve SIP security; extend the protocol with
necessary to run TLS, which is not always the case of SIP. SIP new components or modify the header semantic. RFC [13,21]
uses UDP as default transport protocol that could be secured by propose a trusted SIP servers network but creates new header
DTLS [20]; what is still rare. In addition, there are other RFC fields. But the extension is used only in a “trusted domain”.
proposing to improve safety and more specifically This paper improves this authentication without any new
authentication with a semantic type S/MIME [19]. S/MIME header field, avoiding any interoperability problem. The main
provides a set of security functionalities that allows SIP to idea is to enhance the existing security mechanism in SIP. A
establish tunneling with integrity, authentication and number of works in particularly the RFC 3310 [3] propose
confidentiality. However, deployment of a global S/MIME enhancing the Digest authentication with the AKA mechanism.
Public Key Infrastructure (PKI) is necessary. Both network and user are authenticated. The principle is a
Our proposition doesn’t improve HTTP Digest challenge/response where each part verifies a value calculated
authentication security level but it gives supplementary with a shared secret. But these recommendations aren’t
information about network trust level. With our mutual implemented because backward compatibility isn’t possible. So
authentication, the user could perceive different security this paper proposes to improve SIP security by a service-
configuration. If the mutual authentication fails, the user is oriented and backward-compatible solution.
invited to limit his phone use.

Authorized licensed use limited to: National Chi-Nan University Library. Downloaded on September 28, 2009 at 00:53 from IEEE Xplore. Restrictions apply.
V. OUR SOLUTION OVERVIEW The proxy server generates the “nonce” with the pre-shared
secret (the password) and an element of the SIP header
A. Principle generated by the user. When the user receives the “nonce”, it
This work has been focused on SIP protocol since this later sends the response for SIP authentication and at the same time
is the most common one used in ToIP infrastructures. checks if the “nonce” has a meaning. The SIP user agent
Moreover ToIP market deals with many interoperability and compares the “nonce” with the value that it had computed. If
security problems. So this paper is a response to both they match, the proxy server should be the legitimate one. The
difficulties with a very strong hypothesis: no change of the computing proposal is as follows:
signalisation protocol. • H(A1) = H(username”:”realm”:”password)
Most security solutions introduced in the section I present • Nonce =H(H(A1):callid-value)
drawbacks that slow down deployment, even if security
improvements are significant. Giving a semantic meaning to • By default, H(data) = MD5(data) (like in the SIP
SIP header fields seems to be an inefficient and simple solution RFC).
to improve SIP security. Some parameters in the SIP header are
opaque as such “Call-ID” or “nonce”, so it is possible to use Keeping the H(A1) calculating approach is interesting
them for security. because it avoids keeping the password in clear in the proxy
An opaque value is usually a random value. Our work
proposes to give a semantic meaning for SIP opaque values. So Our method is exposed with the MD5 algorithm, since this
HTTP digest in SIP could become a mutual authentication with later is the hash function by default in SIP. Recent research
a specific semantic meaning for the “nonce”. This solution is a results [27], which affect the collision resistance of MD5 - the
service-oriented design. difficulty of finding two new messages with the same hash
value - don't directly affect the way of using the hash function
used in this paper. In fact, the hash function is used in
B. Improvement of the authentication combination with a secret key (the password) and with random
The Digest authentication mechanism is based on a simple values as well. Since the challenge/response strength depends
challenge-response authentication allowing a server to on the strength of HMAC-MD5, not the collision-resistance of
challenge a client request and the client to provide MD5, the results don't directly affect our extension.
authentication information. The client replies with a digest to
demonstrate its knowledge of the shared secret. This The originality of this solution is alike the principle of
mechanism results in client authentication but doesn’t provide AKA without amending the protocol. This SIP mutual
mutual authentication. authentication is users service. Reading the “nonce” gives
information but is not a condition to phone. Figure 3 presents
As exposed in section II, SIP enables the user an information pictogram example.
authentication to the server. The security mechanism requires a
pre-shared key and cryptographic algorithm by hiding user
credentials with cryptographic hashes. The pre-shared key is
given with the username by the telephony provider. Our mutual
authentication mechanism (Fig. 2) doesn’t increase the number
of hand-shake.
client server
secret random Figure 3. User information icon example
other-parameters This SIP mutual authentication provides information to the
user; allowing him to know whether the proxy is a trusty server
or not. This service solution provides an easy deployment to
server no
consolidate security. Our work doesn’t provide a new method
challenge concatenation
unautenticated = (nonce) (strong or not) but reinforces an usual method.
server SIP mutual authentication between server and client is
possible with this approach but also with TLS. Nevertheless
secret secret our solution is independent of transport layer protocols whereas
other-parameters other-parameters TLS needs TCP. Other condition for TLS is the PKI
deployment. Using the “nonce” to improve security doesn’t
Alg Alg need prerequisite in a SIP context like TLS with TCP or a PKI.
So giving a semantic meaning to opaque values offers a new
responce no client
= unautenticated and simple technics to reduce some security vulnerabilities.
(e.g. digest)
C. Interoperability and backward-compatible
As with HTTP Digest, the “nonce” computation presents
Figure 2. Our authentication enhancement mechanism the same weakness regarding dictionary attack on hash value.

Authorized licensed use limited to: National Chi-Nan University Library. Downloaded on September 28, 2009 at 00:53 from IEEE Xplore. Restrictions apply.
The main idea of this paper is to improve security with existing Agreeement (AKA)”, RFC 3310, September 2002:
elements such as the MD5 algorithm and to enable easy http://www.ietf.org/rfc/rfc3310.txt.
deployment. One of the strength points of this solution is that [4] R. Rivest, “The MD5 Message-Digest Algorithm”, RFC 1321, April
1992: http://www.ietf.org/rfc/rfc1321.txt.
this later doesn’t affect signalling, so it can be implemented
[5] 3GPP TS 33.102, “3GPP Security ; Security Architecture”, Release 7,
without interrupting service; deployment doesn’t alter the December 2006, 64p.
ability to establish a SIP session. Equipments without the SIP
[6] P. Gupta, V. Shmatikov, “Security Analysis of Voice-over-IP
mutual authentication continue to use the services. Protocols”, Computer Security Foundations Symposium, 2007, CSF '07,
20th IEEE, July 2007, p 49-63.
Our solution provides a progressive deployment without
interruption of service. In all configurations, the SIP user agent [7] S. Kent, and R. Atkinson, “Security Architecture for the Internet
Protocol”, RFC 2401, November 1998:
can phone: http://www.ietf.org/rfc/rfc2401.txt.
• First event, both user and proxy are fitted with our [8] J. Postel, “User Datagram Protocol”, RFC 768, August 1980:
solution. Mutual authentication is obtained without
[9] J. Postel, “Transmission Control Protocol”, STD 7, RFC 793, September
problem. 1981: http://www.ietf.org/rfc/rfc793.txt.
• Second event, proxy is fitted with our solution but the [10] J.F. Ransome, J.W. Rittinghouse, VoIP Security, Elsevier Digital Press,
user isn’t. The user can’t read the “nonce” but can 2005, 402p.
generate a REGISTER with the response to the [11] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, “RTP: A
Transport Protocol for Real-Time Applications”, RFC 3550, July 2003.
challenge. The user can’t benefit from the security http://www.ietf.org/rfc/rfc3550.txt.
[12] M. Baugher, S. Casner, R. Frederick and V. Jacobson, “The Secure
• Third event, the user is fitted with our solution but the Real-time Transport Protocol (SRTP)”, RFC 3711, March 2004:
proxy isn’t. The user can be registered but he is
[13] J. Peterson, and C. Jennings, “Enhancements for Authenticated Identity
informed by the softphone that the proxy isn’t Management in the Session Initiation Protocol (SIP)”, RFC 4474,
authenticated. August 2006: http://www.ietf.org/rfc/rfc4474.txt.
Our solution could be implemented retrospectively. The proxy [14] T. Dierks, and C. Allen, “The TLS Protocol”, RFC 2246, January 1999:
servers and the phones could be modified in an operational
[15] B. Ramsdell, “Secure/Multipurpose Internet Mail Extensions (S/MIME)
infrastructure without interrupting telephone service. Version 3.1 Message Specification”, RFC 3851, July 2004:
VI. CONCLUSION [16] M. Handley, V. Jacobson and C. Perkins, “SDP : Session Description
The minimum solution to secure ToIP is to use security Protocol”, RFC 4566, July 2006: http://www.ietf.org/rfc/rfc4566.txt.
mechanisms like those deployed in data networks (firewalls, [17] M. Zandi, M.V. Martin and P.C.K. Hung, “Overview of security issues
encryption, etc.). Nevertheless interoperability and backward of VoIP“, Proceeding of IASTED European Conference Internet and
Multimedia Systems and Applications, March 2007.
compatibility problems limit the implementation of any
[18] Cain software. The Cain & Abel Project: http://www.oxid.it.
solution like IPsec or TLS.
[19] J. Peterson, “S/MIME Advanced Encryption Standard (AES)
Mutual authentication mechanism for SIP presented in this Requirement for the Session Initiation Protocol (SIP)”, RFC 3853, July
paper greatly improves SIP security without changing 2004: www.ietf.org/rfc/rfc3853.txt.
signalling. This service-oriented approach enables easy [20] E. Rescolar, and N. Modadugu, “Datagram Transport Layer Security”,
RFC 4347, April 2006: http://www.ietf.org/rfc/rfc4347.txt.
deployment and total interoperability contrary to existed
[21] C. Jennings, J. Peterson and M. Watson, “Private Extensions to the
solutions such as TLS that needs PKI. Giving a semantic Session Initiation Protocol (SIP) for Asserted Identity within Trusted
meaning to some header fields seems to be a very promising Networks”, RFC 3325, November 2002: www.ietf.org/rfc/rfc3325.txt.
solution to improve SIP security. The “nonce” is opaque for the [22] B. Wallis, “Hypertext Transfer Protocol (HTTP) Digest Authentication
user, the reason why our approach could be implemented in using Global System for Mobile Communications (GSM) A3 and A8”,
order to offer other security services. Many other SIP header Internet draft (work in progress), August 2007.
parameters could be handled for that purpose such as the “Call- [23] F. Yergeau, “UTF-8, a transformation format of ISO 10646”, RFC 2279,
ID”. Future prospects will identify the new services that could January 1998: http://www.ietf.org/rfc/rfc2279.txt.
be developed. The privacy or the bill checks are the main [24] N. Dubée, “La voix sur IP (VoIP) : une opportunité pour la sécurité ?“,
evolutions to be considered in future works. Proceeding of SSTIC symposium, June 2007.
[25] V. Iossifov, T. Totev and A. Tochatschek, “Experiences in VoIP
telephone network security policy at the University of Applied Sciences
REFERENCES (FHTW) Berlin“, Proceedings of the 2007 international conference on
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Computer systems and technologies, CompSysTech’07, 2007, Vol. 283,
Sparks, M. Handley and E. Schooler, “SIP: Session Initiation Protocol”, p3-1 to p3-18.
RFC 3261, June 2002: http://www.ietf.org/rfc/rfc3261.txt. [26] S. El Sawda and P. Urien, “SIP Security Attacks and Solutions : A state-
[2] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. of-the-art review”, Information and Communication Technologies 2006,
Luotonen and L. Stewart, “HTTP Authentication: Basic and Digest ICTTA'06, April 2006, Vol.2, p 3187–3191.
Access Authentication”, RFC 2617, June 1999: [27] X. Wang, D. Feng, X. Lai and H. Yu, Collisions for Hash Functions
http://www.ietf.org/rfc/rfc2617.txt. MD4, MD5, HAVAL-128 and RIPEMD, Cryptology ePrint Archive,
[3] A. Niemi, J. Arkko and V. Torvinen, “Hypertext Transfer Protocol Report 2004/199 : http://eprint.iacr.org/2004/199.pdf.
(HTTP) Digest Authentication Using Authentication and Key

Authorized licensed use limited to: National Chi-Nan University Library. Downloaded on September 28, 2009 at 00:53 from IEEE Xplore. Restrictions apply.