SPEERMINT Working Group S. Niccolini
Internet-Draft NEC
Intended status: Informational E. Chen
Expires: August 24, 2008 NTT
J. Seedorf
NEC
February 21, 2008
SPEERMINT Security BCPs
draft-niccolini-speermint-voipthreats-03
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 August 24, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Niccolini, et al. Expires August 24, 2008 [Page 1]
Internet-Draft SPEERMINT Security BCPs February 2008
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, et al. Expires August 24, 2008 [Page 2]
Internet-Draft SPEERMINT Security BCPs February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Security Threats relevant to SPEERMINT . . . . . . . . . . . . 5
2.1. Threats Relevant to the Look-Up Function (LUF) . . . . . . 5
2.1.1. Threats to LUF Confidentiality . . . . . . . . . . . . 5
2.1.2. Threats to LUF Integrity . . . . . . . . . . . . . . . 5
2.1.3. Threats to LUF Availability . . . . . . . . . . . . . 5
2.2. Threats Relevant to the Location Function (LF) . . . . . . 6
2.2.1. Threats to LF Confidentiality . . . . . . . . . . . . 6
2.2.2. Threats to LF Integrity . . . . . . . . . . . . . . . 6
2.2.3. Threats to LF Availability . . . . . . . . . . . . . . 6
2.3. Threats to the Signaling Function (SF) . . . . . . . . . . 6
2.3.1. Threats to SF Confidentiality . . . . . . . . . . . . 7
2.3.2. Threats to SF Integrity . . . . . . . . . . . . . . . 7
2.3.3. Threats to SF Availability . . . . . . . . . . . . . . 8
2.4. Threats to the Media Function (MF) . . . . . . . . . . . . 9
2.4.1. Threats to MF Confidentiality . . . . . . . . . . . . 9
2.4.2. Threats to MF Integrity . . . . . . . . . . . . . . . 9
2.4.3. Threats to MF Availability . . . . . . . . . . . . . . 9
3. Security Best Practices . . . . . . . . . . . . . . . . . . . 11
3.1. Database BCPs . . . . . . . . . . . . . . . . . . . . . . 11
3.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. DNS Replication . . . . . . . . . . . . . . . . . . . . . 11
3.4. Privacy Service . . . . . . . . . . . . . . . . . . . . . 11
3.5. Digest Authentication on all requests . . . . . . . . . . 11
3.6. Use TCP instead of UDP to deliver SIP messages . . . . . . 12
3.7. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 12
3.8. Strong Identity Assertion . . . . . . . . . . . . . . . . 12
3.9. Server Pooling . . . . . . . . . . . . . . . . . . . . . . 13
3.10. Rate limit . . . . . . . . . . . . . . . . . . . . . . . . 13
3.11. Fuzz testing . . . . . . . . . . . . . . . . . . . . . . . 13
3.12. SRTCP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.13. Mapping BCPs to threats . . . . . . . . . . . . . . . . . 13
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
7. Informative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Niccolini, et al. Expires August 24, 2008 [Page 3]
Internet-Draft SPEERMINT Security BCPs February 2008
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, et al. Expires August 24, 2008 [Page 4]
Internet-Draft SPEERMINT Security BCPs February 2008
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 and according the CIA (Confidentiality, Integrity and
Availability) triad:
o Look-Up Function (LUF);
o Location Function (LF);
o Signaling Function (SF);
o Media Function (MF).
2.1. Threats Relevant to the Look-Up Function (LUF)
This is one of the latest additions of the terminology draft [7].
LUF is vulenrable to the same threats that affect database systems in
general.
2.1.1. Threats to LUF Confidentiality
o SIP URIs and peering domains harvesting - an attacker can exploit
this weakness if the underlying database has a weak authentication
system, and then use the gained knowledge to launch other kind of
attacks.
2.1.2. Threats to LUF Integrity
The underlying database could be vulnerable to:
o Injection attack - an attacker could manipulate statements
performed on the database by the end user.
2.1.3. Threats to LUF Availability
The underlying database could be vulnerable to:
o Denial of Service attacks - e.g. an attacker makes incomplete
requests causing the server to create an idle state for each of
them causing memory to be exhausted.
Niccolini, et al. Expires August 24, 2008 [Page 5]
Internet-Draft SPEERMINT Security BCPs February 2008
2.2. Threats Relevant to the Location Function (LF)
2.2.1. Threats to LF Confidentiality
o URI harvesting - the attacker harvests URIs and IP addresses of
the existing User Endpoints (UEs) by issuing a multitude of
location requests. Direct intrusion against vulnerable UEs or
telemarketing are possible attack scenarios that would use the
gained knowledge.
o SIP device enumeration - the attacker discovers the IP address of
each intermediate signaling device by looking at the Via and
Record-Route headers of a SIP message. Targeting the discovered
devices with subsequent attacks is a possible attack scenario.
2.2.2. Threats to LF Integrity
Bogus information can be accepted by LF if specific flaws are
exploited (e.g. if the LF involves a Location Server, LS, that does
not correctly validate routing data such as NAPTR records, then the
LS may develop incorrect Session Establishment Data, SED). Dynamic
call routing discovery and establishment, as in scope of SPEERMINT,
introduces new opportunities for such an attack. In the following
two example variants of such an attack are listed.
o Man-in-the-Middle attack - the attacker has already or inserts an
unauthorized node in the signaling path modifying the SED. The
results is that the attacker is then able to read, insert and
modify the multimedia communications.
o Incorrect destinations - the attacker redirect the calls to a
incorrect destination with the purpose of establishing fraud
communications like voice phishing or DoS attacks.
2.2.3. Threats to LF Availability
The LF can be object of DoS attacks. DoS attacks to the LF can be
carried out by sending a large number of queries to the LS or Session
Manager, SM, with the result of preventing an originating SSP from
looking up call routing data of any URI outside its administrative
domain. As an alternative the attacker could target the DNS to
disable resolution of SIP addresses.
2.3. 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
Niccolini, et al. Expires August 24, 2008 [Page 6]
Internet-Draft SPEERMINT Security BCPs February 2008
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.3.1. Threats to SF Confidentiality
SF traffic is vulnerable to eavesdropping, in particular when the
data is moved across multiple SSPs having different levels of
security policies. Threats for the SF confidentiality are listed
here:
o call pattern analysis - the attacker tracks the call patterns of
the users violating his/her privacy (e.g. revealing the social
network of various users, the daily phone usage, etc.), also rival
SSPs may infer information about the customer base of other SSPs
in this way;
o Password cracking - challenge-response authentication mechanism of
SIP is not secure if the attacker is able to eavesdrop a
sufficient number of SIP authentication messages exchanged between
a SIP server and a SIP client.
2.3.2. Threats to SF Integrity
The integrity of the SF can be violated using SIP request spoofing,
SIP reply spoofing and SIP message tampering.
2.3.2.1. SIP Request Spoofing
Most SIP request spoofing require first a SIP message eavesdropping
but some of the them could be also performed by guessing or
exploiting broken implementations. Threats in this category are:
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);
REGISTER spoofing - the attacker forges a REGISTER request and
register a bogus contact information with the objective of
hijacking incoming calls.
Billing fraud - the same attack as in the case of the REGISTEr
spoofing may lead an attacker to be able to direct billing for
calls to the victim UE and avoid paying for the phone calls;
user ID spoofing - SSPs are responsible for asserting the
legitimacy of user ID; if an SSP fails to achieve the level of
Niccolini, et al. Expires August 24, 2008 [Page 7]
Internet-Draft SPEERMINT Security BCPs February 2008
identity assertion that the federation it belongs expects, it may
create an entry point for attackers to conduct user ID spoofing
attacks.
2.3.2.2. SIP Reply Spoofing
Threats in this category are:
Forget 200 Response - the attacker sends a forged CANCEL request
to terminate a call in progress tricking the terminating UE to
believe that the originating UE actually sent it, and successfully
hijacks a call sending a forged 200 OK message to the originating
UE communicating the address of the rogue UE under the attacker's
control;
Forget 302 Response - the attacker sends a forged "302 Moved
Temporarily" reply instead of a 200 OK, this enables the attack to
hijack the call and to redirect it to any destination UE of his
choosing;
Forget 404 Response - the attacker sends a forged "404 Not Found"
reply instead of a 200 OK, this enables the attack to disrupt the
call establishment;
2.3.2.3. SIP Message Tampering
This threat involves the alternation of important field values in a
SIP message or in the SDP body. Examples of this threat could be the
dropping or modification of handshake packets in order to avoid the
establishment of a secure RTP session (SRTP). The same approach
could be used to degrade the quality of media session by letting UE
negotiate a poor quality codec.
2.3.3. Threats to SF Availability
o Flooding attack - a SBE is susceptible to message flooding attack
that may come from interconnected SSPs;
o Session Black Holing - the attacker (assumed to be able to make
Man-in-the-Middle attacks) intentionally drops essential packets,
e.g. INVITEs, to prevent certain calls from being established;
o SIP Fuzzing attack - fuzzing tests and software can be used by
attackersto discover and exploit vulnerabilities of a SIP entity,
this attack may result in crashing SIP entity.
Niccolini, et al. Expires August 24, 2008 [Page 8]
Internet-Draft SPEERMINT Security BCPs February 2008
2.4. Threats to the Media Function (MF)
The Media function (MF) is responsible for the actual delivery of
multimedia comunication between the users and carries sensitive
information. Through media function, UE can establish secure
communications and monitor quality of conversations. Correct and
trusted operations of MF is essential for privacy and service
assurance issues. This section discusses potential security threats
to the MF to detail the possible attack vectors.
2.4.1. Threats to MF Confidentiality
The MF is vulnerable to eavesdropping in which the attacker may
reconstruct the voice conversation or sensitive information (e.g.
PIN numbers from DTMF tones). SRTP and ZRTP are vulnerable to bid-
down attacks, i.e. by selectively dropping key exchange protocol
packets may result in the establishment of a non-secure
communications.
2.4.2. Threats to MF Integrity
Both RTP and RTCP are vulnerable to integrity violation in many ways:
o Media Hijack - if an attacker can somehow detect an ongoing media
session and eavesdrop a few RTP packets, he can start sending
bogus RTP packets to one of the UEs involved using the same codec.
As illustrated in Fig. 8, if the bogus RTP packets have
consistently greater timestamps and sequence numbers (but within
the acceptable range) than the legitimate RTP packets, the
recipient UE may accept the bogus RTP packets and discard the
legitimate ones.
o Media Session Tear Down - the attacker sends bogus RTCP BYE
messages to a target UE signaling to tear down the media
communication, please note tha tRTCP messages are normally not
authenticated.
o QoS degradation - the attacker sends wrong RTCP reports
advertising more packet loss or more jitter than actually
experimented resulting in the usage of a poor quality codec
degrading the overall quality of the call experience.
2.4.3. Threats to MF Availability
o Malformed messages - the attacker tries to cause a crash or a
reboot of the DBE/UE by sending RTP/RTCP malformed messages;
Niccolini, et al. Expires August 24, 2008 [Page 9]
Internet-Draft SPEERMINT Security BCPs February 2008
o Messages flooding - the attacker tries to exhaust the resources of
the DBE/UE by sending many RTP/RTCP messages.
Niccolini, et al. Expires August 24, 2008 [Page 10]
Internet-Draft SPEERMINT Security BCPs February 2008
3. Security Best Practices
This section describes implementer-specific BCPs to supplement the
security requirements described in [8]. The BCPs are first described
and then mapped to threats indicating whic BCPs are recommended to be
used in order to solve which threats.
3.1. Database BCPs
Adequate security measures must be applied to the LUF to prevent it
from being target of attacks since it involves the use of common
database systems. Common security BCPs for database include system
replication to prevent any database from being a single point of
failure, and the use of parameterized statements to prevent SQL
injections. [9] is one of many existing literatures that describe
BCPs in this area.
3.2. DNSSEC
In the case DNS is used by the LF, it is recommended to deploy the
recent version of Domain Name System Security Extensions (informally
called "DNSSEC-bis") defined by [10] [11] [12], to permit
authentication and data integrity checking of DNS data. DNSSEC adds
new records to the DNS data which permit the validation of data in
the DNS using strong cryptography.
3.3. DNS Replication
DNS replication is a very important BCP to mitigate availability
threats. Attacking multiple DNS servers simultaneously with the
purpose of bringing them all them is much more challenging than
attacking a sole DNS server (single point of failure).
3.4. Privacy Service
Stripping Via and Record-Route headers, replacing the Contact header,
and even changing Call-IDs are the mechanisms described in [13] to
protect SIP privacy. This practice allows an SSP to hide its SIP
network topology, prevents intermediate signaling equipment from
becoming the target of DoS attacks, as well as protects the privacy
of UEs according to their preferences.
3.5. Digest Authentication on all requests
In todays current practice, Digest authentication [14] is used to
challenge only REGISTER and INVITE requests. However, as a BCP, the
more messages it is applied to the more prevention from threats is
assured. It is recommended to apply digest authentication to all SIP
Niccolini, et al. Expires August 24, 2008 [Page 11]
Internet-Draft SPEERMINT Security BCPs February 2008
requests, including BYE and CANCEL, to prevent attacks such as
session tear-down.
3.6. Use TCP instead of UDP to deliver SIP messages
Most SIP clients stay connected with the server on a persistent basis
(differently from HTTP clients). Scalability requirements are
therefore much more stringent for a SIP server than for a web server.
This leads to the choice of UDP as protocol used between SSPs to
carry SIP messages (especially for providers with a large user
community). New improvements in the Linux kernel [15] show a big
increase of the scalability of TCP in handling large number of
persistent (but idle) connections. Therefore SSP operators still
using UDP for their SIP network should consider switching to TCP.
This would increase the difficulty of performing attacks such as
session teardown or forged responses.
3.7. Ingress Filtering
Ingress filtering, i.e. block all traffic coming from a host that has
a source address different than the addresses that have been assigned
to that host (see [16]) can effectively prevent UEs from sending
packets with a spoofed source IP address.
3.8. Strong Identity Assertion
"Caller ID spoofing" can be achieved thanks to a Weak identity
assertion on the From URI of an INVITE request. In a single SSP
domain, strong identity assertion can be easily achieved by
authenticating each INVITE request. However, in the context of
SPEERMINT, only the originating SSP is able to verify the identity
directly. In order to overcome this problem there are currently only
two major approaches: transitive trust and cryptographic signature.
The transitive trust approach builds a chain of trust among different
SSP domains. One example of this approach is a combined mechanism
specified in [17] and [18]. Using this approach in a transit peering
network scenario, the terminating SSP must establish a trust
relationship with all SSP domains on the path, which can be seen as
an underlying weakness. The use of cryptographic signatures is an
alternative approach. "SIP Authenticated Identity Body (AIB)" is
specified in [19]. [6] introduces two new header fields IDENTITY and
IDENTITY-INFO that allow a SIP server in the originating SSP to
digitally sign an INVITE request after authenticating the sending UE.
The terminating SSP can verify if the INVITE request is signed by a
trusted SSP domain. Although this approach does not require the
terminating SSP to establish a trust relationship with all transit
SSPs on the path, a PKI infrastructure is assumed to be in place.
Niccolini, et al. Expires August 24, 2008 [Page 12]
Internet-Draft SPEERMINT Security BCPs February 2008
3.9. Server Pooling
Architecture and protocols for the management of server pools
supporting mission-critical applications is addressed in the RSERPOOL
WG. Using this mechanisms (see [20] for requirements) an UE obtains
support for server failover in case of availability problems.
3.10. Rate limit
Packet flooding attacks can be mitigated by limiting the rate of
incoming traffic through policing or queuing. In this way legitimate
clients could be denied of the service since their traffic may be
discarded. Rate limiting can also be applied on a per-source-IP
basis under the assumption that the source IP of each attack packet
is not spoofed dynamically and will all the limitations related to
NAT and mobility issues.
3.11. Fuzz testing
Fuzz testing is a common black box testing technique used in software
engineering. Fuzz tests can be carried out preventively to assure
UE/SBE/DBE can handle unexpected data correctly without crashing.
[22] and [21] are examples of torture test cases specific for SIP
devices and freely available fuzzers, respectively. These type of
tests needs to be carried out before product release.
3.12. SRTCP
Secure RTCP (SRTCP) provides the same security-related features to
RTCP as SRTP does for RTP. SRTCP is described in [5] as optional.
In order to prevent some of the RTCP threats previously described it
is recommended to turn this feature on.
3.13. Mapping BCPs to threats
The following table shows how to mitigate threats with the above
mentioned BCPs.
+---------------------------------------------------------+
| Group | Threats | BCPs |
+--------+------------------------------------------------+
| | Unauthorized access | database BCPs |
| +---------------------+--------------------------+
| LUF | SQL injection | database BCPs |
| +---------------------+--------------------------+
| | DoS to LUF | database BCPs |
+--------+---------------------+--------------------------+
| | URI harvesting | DNSSEC |
Niccolini, et al. Expires August 24, 2008 [Page 13]
Internet-Draft SPEERMINT Security BCPs February 2008
| +---------------------+--------------------------+
| | SIP equipment | |
| | enumeration | DNSSEC, privacy service |
| +---------------------+--------------------------+
| LF | MitM attack | DNSSEC |
| +---------------------+--------------------------+
| | Incorrect | |
| | destinations | DNSSEC |
| +---------------------+--------------------------+
| | DoS to LF | DNS replication |
+--------+---------------------+--------------------------+
| | Call pattern | |
| | analysis | TLS |
| +---------------------+--------------------------+
| | Password cracking | TLs |
| +---------------------+--------------------------+
| | Session Tear Down | TLS, TCP, digest auth. |
| +---------------------+--------------------------+
| | REGISTER spoofing | digest auth. |
| +---------------------+--------------------------+
| | Billing fraud | digest auth. |
| +---------------------+--------------------------+
| | User ID spoofing | strong identity assertion|
| SF +---------------------+--------------------------+
| | Forged 200 Response | TLS, TCP, ingress filt. |
| +---------------------+--------------------------+
| | Forged 302 Response | TLS, TCP, ingress filt. |
| +---------------------+--------------------------+
| | Forged 404 Response | TLS, TCP, ingress filt. |
| +---------------------+--------------------------+
| | Flooding attack | server polling, |
| | | rate limit |
| +---------------------+--------------------------+
| | Session black | DNSSEC |
| | holing | |
| +---------------------+--------------------------+
| | SIP fuzzing attack | Fuzz testing |
+--------+---------------------+--------------------------+
| | Eavesdropping | SRTP |
| +---------------------+--------------------------+
| | Media Hijack | SRTP |
| +---------------------+--------------------------+
| MF | Media session | SRTCP |
| | tear-down | |
| +---------------------+--------------------------+
| | QoS degradation | SRTCP |
| +---------------------+--------------------------+
| | Malformed messages | Fuzzing test |
Niccolini, et al. Expires August 24, 2008 [Page 14]
Internet-Draft SPEERMINT Security BCPs February 2008
| +---------------------+--------------------------+
| | Messages flooding | rate limit |
+--------+---------------------+--------------------------+
Niccolini, et al. Expires August 24, 2008 [Page 15]
Internet-Draft SPEERMINT Security BCPs February 2008
4. Conclusions
This memo presented the different SPEERMINT security threats
classified in groups related to the LUF, LF, SF and MF respectively.
The multiple instances of the threats are presented with a brief
explanation. Afterwards the security BCPs for SPEERMINT are outlined
together with possible mitigation of the existing threats by means of
them.
Niccolini, et al. Expires August 24, 2008 [Page 16]
Internet-Draft SPEERMINT Security BCPs February 2008
5. Security Considerations
This memo is entirely focused on the security threats for SPEERMINT.
Niccolini, et al. Expires August 24, 2008 [Page 17]
Internet-Draft SPEERMINT Security BCPs February 2008
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, et al. Expires August 24, 2008 [Page 18]
Internet-Draft SPEERMINT Security BCPs February 2008
7. Informative References
[1] "VOIPSA VoIP Security and Privacy Threat Taxonomy",
October 2005.
[2] Penno, R., Malas, D., Khan, S., and A. Uzelac, "SPEERMINT
Peering Architecture", draft-ietf-speermint-architecture-04.txt
(work in progress), August 2007.
[3] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Extensions
to RTP for Diffie-Hellman Key Agreement for SRTP",
draft-zimmermann-avt-zrtp-04.txt (work in progress), July 2007.
[4] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2",
draft-ietf-tls-rfc4346-bis-09.txt (work in progress),
February 2008.
[5] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[6] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[7] Malas, D. and D. Meyer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-16 (work in progress),
February 2008.
[8] Mule, J., "SPEERMINT Requirements for SIP-based VoIP
Interconnection", draft-ietf-speermint-requirements-03 (work in
progress), November 2007.
[9] Gertz, M. and S. Jajodia, "Handbook of Database Security".
[10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[13] Peterson, J., "A Privacy Mechanism for the Session Initiation
Niccolini, et al. Expires August 24, 2008 [Page 19]
Internet-Draft SPEERMINT Security BCPs February 2008
Protocol (SIP)", RFC 3323, November 2002.
[14] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[15] Shemyak, K., "Scalability of TCP Servers, Handling Persistent
Connections".
[16] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[17] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
[18] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[19] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004.
[20] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
J., and M. Stillman, "Requirements for Reliable Server
Pooling", RFC 3237, January 2002.
[21] Wieser, C., "SIP Robustness Testing for Large-Scale Use".
[22] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and
H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test
Messages", RFC 4475, May 2006.
Niccolini, et al. Expires August 24, 2008 [Page 20]
Internet-Draft SPEERMINT Security BCPs February 2008
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
Jan Seedorf
NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 4342 221
Email: seedorf@nw.neclab.eu
URI: http://www.nw.neclab.eu
Niccolini, et al. Expires August 24, 2008 [Page 21]
Internet-Draft SPEERMINT Security BCPs February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, et al. Expires August 24, 2008 [Page 22]