SPEERMINT Working Group S. Niccolini
Internet-Draft NEC
Intended status: Informational E. Chen
Expires: March 2, 2008 NTT
August 30, 2007
VoIP Security Threats relevant to SPEERMINT
draft-niccolini-speermint-voipthreats-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Niccolini & Chen Expires March 2, 2008 [Page 1]
Internet-Draft VoIP Threats August 2007
Abstract
This memo presents the different security threats related to
SPEERMINT classifying them into threats to the Location Function, to
the Signaling Function and to the Media Function. The different
instances of the threats are briefly introduced inside the
classification. Finally the existing security solutions in SIP and
RTP/RTCP are presented to describe the countermeasures currently
available for such threats. The objective of this document is to
identify and enumerate the SPEERMINT-specific threat vectors in order
to specify security-related requirements. Once the requirements are
identified, methods and solutions how to achieve such requirements
can be selected.
Niccolini & Chen Expires March 2, 2008 [Page 2]
Internet-Draft VoIP Threats August 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Security Threats relevant to SPEERMINT . . . . . . . . . . . . 5
2.1. Threats Relevant to the Location Function (LF) . . . . . . 5
2.1.1. Threats to LF Confidentiality . . . . . . . . . . . . 5
2.1.2. Threats to LF Integrity . . . . . . . . . . . . . . . 5
2.1.3. Threats to LF Availability . . . . . . . . . . . . . . 6
2.2. Threats to the Signaling Function (SF) . . . . . . . . . . 6
2.2.1. Threats to SF Confidentiality . . . . . . . . . . . . 6
2.2.2. Threats to SF Integrity . . . . . . . . . . . . . . . 7
2.2.3. Threats to SF Availability . . . . . . . . . . . . . . 8
2.3. Threats to the Media Function (MF) . . . . . . . . . . . . 9
2.3.1. Threats to MF Confidentiality . . . . . . . . . . . . 9
2.3.2. Threats to MF Integrity . . . . . . . . . . . . . . . 9
2.3.3. Threats to MF Availability . . . . . . . . . . . . . . 9
3. Security Best Practices . . . . . . . . . . . . . . . . . . . 11
3.1. General Security Best Practices . . . . . . . . . . . . . 11
3.2. Security Best Practices for the LF . . . . . . . . . . . . 11
3.2.1. Ensure LF Confidentiality . . . . . . . . . . . . . . 11
3.2.2. Ensure LF Integrity . . . . . . . . . . . . . . . . . 11
3.2.3. Ensure LF Availability . . . . . . . . . . . . . . . . 11
3.3. Security Best Practices for the SF . . . . . . . . . . . . 12
3.3.1. Ensure SF Confidentiality . . . . . . . . . . . . . . 12
3.3.2. Ensure SF Integrity . . . . . . . . . . . . . . . . . 12
3.3.3. Ensure SF Availability . . . . . . . . . . . . . . . . 12
3.4. Security Best Practices for the MF . . . . . . . . . . . . 12
3.4.1. Ensure MF Confidentiality and Integrity . . . . . . . 12
3.4.2. Ensure MF Availability . . . . . . . . . . . . . . . . 12
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Niccolini & Chen Expires March 2, 2008 [Page 3]
Internet-Draft VoIP Threats August 2007
1. Introduction
With VoIP, the need for security is compounded because there is the
need to protect both the control plane and the data plane. In a
legacy telephone system, security is a more valid assumption.
Intercepting conversations requires either physical access to
telephone lines or to compromise the Public Switched Telephone
Network (PSTN) nodes or the office Private Branch eXchanges (PBXs).
Only particularly security-sensitive organizations bother to encrypt
voice traffic over traditional telephone lines. In contrast, the
risk of sending unencrypted data across the Internet is more
significant (e.g. DTMF tones corresponding to the credit card
number). An additional security threat to Internet Telephony comes
from the fact that the signaling is sent using the same network as
the multimedia data; traditional telephone systems have the signaling
network separated from the data network. This is an increased
security threat since a hacker could attack the signaling network and
its servers with increased damage potential (call hijacking, call
drop, DoS attacks, etc.). Therefore there is the need of
investigating the different security threats, to extract security-
related requirements and to highlight the solutions how to protect
from such threats.
Niccolini & Chen Expires March 2, 2008 [Page 4]
Internet-Draft VoIP Threats August 2007
2. Security Threats relevant to SPEERMINT
This section enumerates potential security threats relevant to
SPEERMINT. A taxonomy of VoIP security threats is defined in [1].
Such a taxonomy is really comprehensive and takes into account also
non-VoIP-specific threats (e.g. loss of power, etc.). Threats
relevant to the boundaries of layer-5 SIP networks are extracted from
such a taxonomy and mapped to the classification relevant for the
SPEERMINT architecture as defined in [2], moreover additional threats
for the SPEERMINT architecture are listed and detailed under the same
classification:
o Location Function (LF);
o Signaling Function (SF);
o Media Function (MF).
An additional category is also included for completeness to address
social threats relevant to SPEERMINT even if they are currently out
of the scope of the SPEERMINT charter.
2.1. Threats Relevant to the Location Function (LF)
2.1.1. Threats to LF Confidentiality
o numbers/identities harvesting - the attacker harvests numbers
and/or user identities by issuing a multitude of location requests
with the purpose of discovering the existent ones and their
identifiers/addresses for calling them, for using them as spoofed
identities or just for retrieving their location in the physical
topology;
o signaling entities harvesting - the attacker harvests signaling
entities (SIP Proxy Servers, etc.) addresses by issuing a specific
number of requests with the purpose of discovering their location
in the physical topology or for targeting them with subsequent
attacks.
2.1.2. Threats to LF Integrity
o routing directories modification - the attacker modifies routing
directories (e.g. DNS, ENUM tree, etc.) in an unauthorized way in
order to modify the call routing. The scope could be to reroute
the call inserting unauthorized nodes in the path, to exclude
authorized nodes from the path, to route the call towards a wrong
destination causing a Denial of Service (DoS), to route the call
towards a wrong destination causing annoyance for the callee;
Niccolini & Chen Expires March 2, 2008 [Page 5]
Internet-Draft VoIP Threats August 2007
o call routing modification by Man in the Middle (MitM) - the
attacker has already or inserts an unauthorized node in the
signaling path in order to modify the call routing. The scope
could be to reroute the call inserting other unauthorized nodes in
the path, to exclude authorized nodes from the path, to route the
call towards a wrong destination causing a Denial of Service
(DoS), to route the call towards a wrong destination causing
annoyance for the callee;
o DNS and ENUM hijacking - the attacker uses a technique called
cache poisoning that exploits a flaw in the DNS software and
tricks the server into receiving incorrect information. The
compromised server would cache and serve the incorrect information
locally. This technique can be used to replace arbitrary NAPTR
records for a set of ENUM queries with NAPTR records of an
attacker's choosing. This allows the attacker to redirect all
calls to a malicious destination.
o proxy impersonation - the attacker tricks a SIP UA or proxy into
communicating with a rogue proxy. VoIP calls established among
different peering providers may introduce a number of new
opportunities for such attack as intermediate proxies are
discovered dynamically during call routing. A successful proxy
impersonation allows full access and control to all routed SIP
messages.
2.1.3. Threats to LF Availability
o Denial of Service Attacks to LF - A DoS attack to the location
function is possible by sending a large number of queries to the
associated ENUM gateways or DNS servers. This prevents a User
Agent to look up the NAPTR record of the intended recipient of the
call.
2.2. Threats to the Signaling Function (SF)
Signaling function involves a great number of sensitive information.
Through signaling function, user agents (UA) assert identities and
VSP operators authorize billable resources. Correct and trusted
operations of signaling function is essential for service providers.
This section discusses potential security threats to the signaling
function to detail the possible attack vectors.
2.2.1. Threats to SF Confidentiality
o call pattern tracking - the attacker tracks the call patterns of
the users violating his/her privacy;
Niccolini & Chen Expires March 2, 2008 [Page 6]
Internet-Draft VoIP Threats August 2007
2.2.2. Threats to SF Integrity
o session black holing - the attacker intentionally drops essential
packets (e.g. INVITE) of the VoIP protocol resulting the call
initiation to fail, it is needed that the attacker controls (or
is) a node in the middle of the signaling path;
o session tear down - the attacker uses CANCEL/BYE messages in order
to tear down an existing call at SIP layer, it is needed that the
attacker replicates the proper SIP header for the hijacking to be
successful (To, From, Call-ID, CSeq);
o seesion hijacking - the attacker uses SIP messages (e.g. 301 Moved
Temporarily) in order to hijack an existing call towards
unexisting proxy/endpoint to make the session initiation fail, it
is needed that the attacker replicates the proper SIP header for
the hijacking to be successful (To, From, Call-ID, CSeq);
o SIP message spoofing - There are a number of ways to perform a DoS
attack by spoofing SIP messages. An attacker may directly send
initial INVITE messages to a User Agent that has no capability to
authenticate them. Such messages may cause the UA to ring non-
stop and effectively make it unusable. Moreover, if the INVITE
appears to come from a SIP server, the UA may keep responding to
the server with multiple messages. This may cause a DrDoS
(Distributed Reflection DoS) attack to the SIP server if enough
UAs are comprimised. Another technique involves injecting faked
BYE/CANCEL or error reponses to an ongoing dialogue in order to
tear down a session or interrupt a session establishment.
o accounting fraud by media oversize - the attacker injects in the
network more traffic than declared in the session request in order
to avoid paying for the used resources;
o session replay - the attacker replays a past session of another
user in order to have access to the same resources (e.g. a bank
account, etc.). This attack can results in using resources
without paying for them, having access to sensitive inforation,
loss of money, etc.;
o call hijacking - the attacker uses SIP messages (e.g. 301 Moved
Temporarily) in order to hijack an existing call towards other
proxy/endpoint, it is needed that the attacker replicates the
proper SIP header for the hijacking to be successful (To, From,
Call-ID, CSeq);
o caller ID spoofing - the attacker spoofs the caller identifier in
order to make calls avoiding paying for them.
Niccolini & Chen Expires March 2, 2008 [Page 7]
Internet-Draft VoIP Threats August 2007
o bypassing SF - the attacker sends the session intiation directly
to the endpoint (Ua, media gateway, etc.) bypassing signaling
entities in order to avoid paying for the used resources.
o weak caller ID assertion by peers - a carrier member fails to
achieve the level of identity assertion expected by the federation
may introduce an entry point for attackers to conduct CID (caller
ID) spoofing fraud. This would affect all members in the
federation, despite their efforts to strengthen the assertion
within their own domains.
o illegitimate transit peers - multimedia traffic may be
unknowningly delivered through an illegitimate transit peer. This
introduces opportunities for a variety of attacks by rough peers.
o codec negotiation interruption/modification - signaling function
is used to perform handshake regarding the codec(s) to be used
during multimedia session. An attacker may intentionally drop or
modify only packets involved in the handshake. This attack could
interrupt the multimedia communication or degrade the quality
achievable in the case o lower quality codec is used.
o SIP protocol spefication interruption/modification - signaling
function may use specific details of the signaling protocol.
Extensions and the signaling associated may vary. An attacker may
intentionally drop or modify only packets meant to give evidence
or declare such extensions tricking the peering party into wrong
assumptions. This attack could make the peering party wrongly
allocating protocol mediation function resulting in failure to
establish communications or parts of them. Moreover the peering
party would unnecessarly use resources in allocating such protocol
mediation function resulting in a DoS attack.
o bid-down attack to SF - a number of encryption key exchange
protocols performs handshake through the Signaling Function. An
attacker may intentionally drop or modify only packets involved in
the handshake. While this attack does not interrupt the voice
communication, calling parties are prenvented from establishing an
SRTP session to secure privacy.
2.2.3. Threats to SF Availability
o SIP malformed requests and messages - the attacker tries to cause
a crash or a reboot of the proxy/endpoint by sending SIP malformed
requests and messages;
o SIP requests and messages flooding - the attacker tries to exhaust
the resources of the proxy/endpoint by sending many SIP requests
Niccolini & Chen Expires March 2, 2008 [Page 8]
Internet-Draft VoIP Threats August 2007
and messages;
2.3. Threats to the Media Function (MF)
Media function is responsible for the actual delivery of multimedia
comunication between the users and carries sensitive information.
Through media function, user agents (UA) can establish secure
communications and monitor quality of conversations. Correct and
trusted operations of media function is essential for privacy and
service assurance issues. This section discusses potential security
threats to the media function to detail the possible attack vectors.
2.3.1. Threats to MF Confidentiality
o eavesdropping - the attacker reconstruct the conversation and/or
additional data delivered with it (e.g.numbers transmitted with
DTMF tones);
2.3.2. Threats to MF Integrity
o media alteration - the attacker alters some RTP packets in order
to modify the conversation between two users;
o bid-down attack to MF - a number of encryption key exchange
protocols performs handshake through the Media Function. ZRTP [3]
is an example of such protocol that exchanges key information
using RTP at the beginning before establishing an SRTP session.
An attacker may intentionally drop only RTP packets involved in
the handshake. While this attack does not interrupt the voice
communication, calling parties are prenvented from establishing an
SRTP session to secure privacy.
2.3.3. Threats to MF Availability
o RTP/RTCP malformed messages - the attacker tries to cause a crash
or a reboot of the proxy/endpoint by sending RTP/RTCP malformed
messages;
o RTP/RTCP messages flooding - the attacker tries to exhaust the
resources of the proxy/endpoint by sending many RTP/RTCP messages;
o RTP/RTCP session tear down - the attacker uses RTCP messages (e.g.
BYE) in order to tear down an existing call at RTP layer, the SIP
layer will not notice that the RTP flow has been torn down and the
call will not result as released;
o RTP/RTCP QoS degradation - the attacker sends wrong RTCP reports
advertising more packet loss or more jitter than actually
Niccolini & Chen Expires March 2, 2008 [Page 9]
Internet-Draft VoIP Threats August 2007
experimented resulting in the usage of a poor quality codec
degrading the overall quality of the call experience.
Niccolini & Chen Expires March 2, 2008 [Page 10]
Internet-Draft VoIP Threats August 2007
3. Security Best Practices
This section will be completed in the next version
3.1. General Security Best Practices
In the next version, this section will describe general security best
practices such as the following.
o source address assurance by ingress filtering
o audit trail, trapping and logging
o trusted time stamping
o critical resource allocation
o exception handling
o system monitoring
o mechanism to timely apply patches and supplementary code
o separate network for management
3.2. Security Best Practices for the LF
In the next version, this section will describe LF security best
practices such as the following.
3.2.1. Ensure LF Confidentiality
o Encryption
o stripping proper headers at the border by SM/SBE
3.2.2. Ensure LF Integrity
o authenticate DNS records with digital certificates [RFC 4033-4035]
o strong authentication against intermediate nodes
3.2.3. Ensure LF Availability
o server redundancy
o filter illegitimate traffic
Niccolini & Chen Expires March 2, 2008 [Page 11]
Internet-Draft VoIP Threats August 2007
3.3. Security Best Practices for the SF
In the next version, this section will describe SF security best
practices such as the following.
3.3.1. Ensure SF Confidentiality
o encryption
3.3.2. Ensure SF Integrity
o encryption
o Strong identity assertion
o strong authentication against intermediate nodes
o shared secret contact info between UA and server to prevent
illegitimate INVITE packets
3.3.3. Ensure SF Availability
o Fuzzing test against all devices before release
o Mechanism to timely apply patches
o Server redundancy
o Rate limitation
3.4. Security Best Practices for the MF
In the next version, this section will describe MF security best
practices such as the following.
3.4.1. Ensure MF Confidentiality and Integrity
o SRTP [requires consensus outside SPEERMINT on key exchange
protocol]
3.4.2. Ensure MF Availability
o Fuzzing test against all UA devices before release
o DBEs provides policing based on active sessions (also cross-layer
issue)
Niccolini & Chen Expires March 2, 2008 [Page 12]
Internet-Draft VoIP Threats August 2007
o verify whether packet rate is consistent with negotiated
parameters
Niccolini & Chen Expires March 2, 2008 [Page 13]
Internet-Draft VoIP Threats August 2007
4. Conclusions
This memo presented a the different SPEERMINT security threats
classified in groups related to the Location Function, Signaling
Function and Media Function respectively. The multiple instances of
the threats are presented with a brief explanation. Finally the
existing security solutions in VoIP were presented to describe the
countermeasures currently available for such threats. The objective
of this document is to identify and enumerate the VoIP threat vectors
in order to specify security-related requirements specific to
SPEERMINT (that will be included in section Section 3). Once the
requirements are identified, methods and solutions how to achieve
such requirements can be selected.
Niccolini & Chen Expires March 2, 2008 [Page 14]
Internet-Draft VoIP Threats August 2007
5. Security Considerations
This memo is entirely focused on the security threats for SPEERMINT.
Niccolini & Chen Expires March 2, 2008 [Page 15]
Internet-Draft VoIP Threats August 2007
6. Acknowledgements
This memo takes inspiration from VOIPSA VoIP Security and Privacy
Threat Taxonomy. The author would like to thank VOIPSA for having
produced such a comprehensive taxonomy which is the starting point of
this draft. The author would also like to thank Cullen Jennings for
the useful slides presented at the VoIP Management and Security
workshop in Vancouver.
Niccolini & Chen Expires March 2, 2008 [Page 16]
Internet-Draft VoIP Threats August 2007
7. Informative References
[1] "VOIPSA VoIP Security and Privacy Threat Taxonomy",
October 2005.
[2] Penno, R., Hammer, M., Khan, S., Malas, D., and A. Uzelac,
"SPEERMINT Peering Architecture",
draft-ietf-speermint-architecture-02.txt (work in progress),
October 2006.
[3] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Extensions
to RTP for Diffie-Hellman Key Agreement for SRTP",
draft-zimmermann-avt-zrtp-02.txt (work in progress),
October 2006.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[5] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2",
draft-ietf-tls-rfc4346-bis-02.txt (work in progress),
October 2006.
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[8] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
Niccolini & Chen Expires March 2, 2008 [Page 17]
Internet-Draft VoIP Threats August 2007
Authors' Addresses
Saverio Niccolini
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 4342 118
Email: saverio.niccolini@netlab.nec.de
URI: http://www.netlab.nec.de
Eric Chen
Information Sharing Platform Laboratories, NTT
3-9-11 Midori-cho
Musashino, Tokyo 180-8585
Japan
Email: eric.chen@lab.ntt.co.jp
URI: http://www.ntt.co.jp/index_e.html
Niccolini & Chen Expires March 2, 2008 [Page 18]
Internet-Draft VoIP Threats August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Niccolini & Chen Expires March 2, 2008 [Page 19]