Mutual Authentication for SIP:
A semantic meaning for the SIP opaque values
Thomas Guillet, Ahmed Serhrouchni
Dept. Computer Sciences and Networks
TELECOM ParisTech, Institut TELECOM
Paris, France
{guillet, ahmed}@enst.fr
Abstract—The Session Initiation Protocol (SIP) is rapidly
becoming the dominant signalling protocol for calls over the
Internet. It has quickly made large inroads into the Voice over IP
(VoIP) market. SIP is an application-layer control operating on
top of a transport protocol and allows to create, modify, and
terminate sessions with one or more participants. With security
considerations, these operations require authentication from
participating end-points, confidentiality, data integrity, and
protection against internal and external attacks. For
authentication, SIP relies on HTTP Digest by default; the client is
authenticated to the SIP proxy server. In order to have mutual
authentication between client and server, SIP could be
implemented over TLS (Transport Layer Security) when TCP is
supported by SIP architecture network. In this paper, we
propose a mutual authentication mechanism within HTTP Digest
since this later is implemented by default in all SIP environments.
It consists in providing meaning and semantic to some of the
parameters’ values generated by the participating end-points
during SIP session establishment, especially to the “nonce”
values. Our solution is backward-compatible with today
implementations. Without being in opposition to security
protocols like TLS, this approach helps in reducing DoS (Denial
of Service) attacks, detects server identity spoofing and ensures
basic mutual authentication with comparison to HTTP digest.
Keywords-component; SIP; Security; HTTP Digest; ToIP;
VoIP; TLS (Transport Layer Security); IPSec; Authentication and
Key Agreement (AKA)
I. INTRODUCTION
In the first generation of networks, services were based on
client-server architectures. The networks were considered
trusty, the objective was to provide services with a minimum
level of security based on a challenge/response; the server
sends a “nonce” to the client, to which the client applies a
cryptographic function on the received “nonce” using a shared
password. Thus, only the client is authenticated, which
therefore opens the door to many active and passive attacks;
especially man-in-the-middle and identity spoofing attacks.
Some modern networks take into account the new need for
security and implement some mutual authentication
mechanisms: for example AKA (Authentication and Key
Agreement) [5] and A3-A8 [22] are respectively deployed for
3G and 2G mobile networks to mutually authenticate the
entities using challenge-response mechanisms. Unfortunately,
applications such as Voice over IP [10] and especially SIP
978-2-9532443-0-4 © 2008 ESRGroups France
Authorized licensed use limited to: National Chi-Nan University Library. Downloaded on September 28, 2009 at 00:53 from IEEE Xplore. Restrictions apply.
Mohamad Badra
LIMOS Laboratory, UMR 6158
CNRS France
badra@isima.fr
(Session Initiation Protocol) [1] are usually deployed with a
simple authentication and not necessarily in a trust domain.
These networks and applications are widely deployed and
implemented and therefore any modification to their
functionalities undoubtedly involves interoperability issues.
Consequently, proposed solutions should be backward
compatible with existing deployed protocols in telephony
domain such as SIP. SIP is currently very popular in the
telecommunications industry because it allows to easily
develop new services.
SIP is an application layer signalling protocol for
transmitting and managing voice, video or data. SIP is based on
client/server architecture with intermediate proxies to convey
signalling and voice packets between multiple SIP applications.
SIP, like any other internet applications, has to be protected
against internal and external attacks; security mechanisms are
required on both application and network layers. SIP uses
protocols such as TCP [9], UDP [8] or RTP (Real-time
Transport Protocol) [11]. Consequently, SIP inherits the
vulnerabilities of these protocols [26]. The text-based nature of
SIP messages gives more opportunities for attacks like
spoofing. The use of malicious SIP messages is also possible
and can be the cause of unauthorized access and DoS attacks
[17]. This is why security begins by using security mechanisms
like those deployed in data networks (firewall, authentication,
encryption, etc.). Modern security protocols such as TLS [14],
IPSec [7] and SRTP (Secure RTP) [12] could be deployed with
SIP to improve security.
Security mechanisms on the network-layer may protect
signalling and voice packets exchanged between proxies
against eavesdropping and spoofing, and build trustworthy
boundaries. This is what we call protection against external
attacks. These attacks are inherited from network protocols
since SIP operates over a transport protocol. The internal
attacks operate on the application layer. They take various
forms, ranging from identity usurpation to spam call
generation. To defend against such attacks, the application
layer defines two security modes: end-to-end and hop-to-hop,
and proposes various security mechanisms for each mode such
as S/MIME [15] for the first mode and HTTP Digest [3] for the
second.
In this paper, we focus on SIP security solutions based on
HTTP Digest, which is used to authenticate clients to proxies.
First, we briefly present SIP messages such as INVITE and
1
REGISTER. In section 3, we present and analyze HTTP
Digest. After we expose a related work in section 4 and
describe our solution in section 5. Then, our concluding
remarks and future works are presented in section 6.
II. SIP: SHORT OVERVIEW
SIP is a real time signalling protocol for Voice over IP that
was developed by the Internet Engineering Task Force (IETF)
[1]. It is used for bi-directional communication session
initiation between two or more nodes. SIP defines messages to
establish, modify and terminate a session. Developed for the
telephony over IP, it provides basic telephone call. However,
SIP is also used in Instant Messaging, and can support many
other applications.
SIP is an application level protocol, so it can be used on top
of different protocols. It can be carried by UDP [8] or TCP [9].
UDP provides speed efficiency, and TCP is used to ensure data
reliability required for security protocols such as TLS. For
voice media, SIP usually operates on top of RTP [11]. SIP
provides generic session establishment with standard
signalling. Any service like chat could be developed with SIP
and generic IP protocols. This principle explains why SIP is
rapidly becoming the dominant signalling protocol for calls
over the Internet. From the security point of view, SIP could
use Internet solutions like SRTP [12] to ensure voice
confidentiality.
SIP is a request/response protocol between a client and a
server, similarly to HTTP. It composes of different components
such as User Agent (UA), redirect server, registrar server,
location server and proxy server. This architecture enables five
capabilities: User location, User availability, User capabilities,
Session setup, and Session management. In the telephony
application, the User Agents could be a soft or a hard phone
that generates and receives request/response.
SIP uses a set of request messages including INVITE,
ACK, CANCEL, OPTIONS, BYE and REGISTER. A User
Agent, wishing to initiate a session, sends an INVITE message.
This message is responded by an OK followed by an ACK
message. When a UA wants to terminate the session, it sends a
BYE. The CANCEL cancels the INVITE before the OK.
OPTIONS is used to interrogate servers about their
capabilities. SIP traffic is a plain text exchange, and is encoded
using the UTF-8 charset [23]. These messages contain the user
parameters for appropriate transmission data use during one
session. These parameters are described by the protocol SDP
(Session Description Protocol) [16].
As Internet, SIP isn’t created with robust security
mechanisms. Some solutions have been developed to improve
its security, but the multitude of protocols or implementations
create interoperability problems. Encoded text facilitates easy
analysis with standard tools of Internet. Attackers can easily
download free software to sniff packet and analyse networks
[24]. IP telephony infrastructure could be attacked by using a
large collection of hacker tools [25]. The authentication based
on HTTP Digest mechanism is one of SIP weakness, the reason
why this paper proposes a new approach to improve SIP
security.
III. SIP AND HTTP DIGEST
In this section, we present the main SIP authentication
mechanism: “HTTP Authentication”. The authentication in
essence is a process of verifying the authenticity of one
identity, in which the SIP network only checks User Agent
legitimate. Other mechanisms are conceivable for simple or
mutual authentication like TLS or S/MIME; but these solutions
are more difficult to implement and for S/MIME authentication
is only made between user agents. To improve SIP security,
our works focused on HTTP Digest Authentication since this
mechanism is implemented everywhere.
A. SIP authentication mechanism
Authentication offered by SIP is defined in the RFC 2617
[2] and called “HTTP Authentication”. This mechanism has
been chosen because SIP has been developed on HTTP
client/server architecture. HTTP Authentication provides two
methods for a user to authenticate: the basic one and the digest
access authentication. The first one is not recommended by
SIP, because user and password are passed over cleartext. So
the chosen mechanism for SIP is the Digest access
authentication. HTTP Digest provides a challenge/response and
uses by default MD5 algorithm [4].
After a REGISTER sent by a UA, the SIP proxy server
generates the challenge and sends the response “401
Unauthorized” via the field “WWW-Authenticate”:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 137.194.192.237:5060;received=137.194.192.237
From: <sip:ahmed@enst.fr>
To: <sip:ahmed@enst.fr>;tag=as7b4af592
Call-ID: D8A5240D579C4D6E8CE1@enst.fr
CSeq: 7168 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Max-Forwards: 70
Contact: <sip:ahmed@137.194.192.228>
WWW-Authenticate: Digest realm="asterisk", nonce="64d45b88"
Content-Length: 0
The SIP User Agent uses the “nonce” to build the
“response”. The “response” is computed using username,
password, method (i.e. REGISTER), “Request-URI”, “nonce”
and “realm”. The basic “nonce” computation is made with the
following RFC 2617 [2] formalism:
• H(A1) = MD5(username”:”realm”:”password)
• H(A2)=MD5(METHOD”:”Request-URI)
• response=MD5(H(A1)”:”nonce”:”H(A2))
With the example parameters:
• H(A1) = MD5(ahmed:asterisk:password)
• H(A2)=MD5(REGISTER:sip:enst.fr)
• response=MD5(H(A1): 64d45b88:H(A2))
Password is provided with username during SIP account
creation. This paper doesn’t handle the method used to
distribute this shared secret. So the REGISTER message with
the “response” is:

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

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