Internet DRAFT - draft-gurbani-spirits-security
draft-gurbani-spirits-security
INTERNET-DRAFT Vijay K. Gurbani
September 2002 Lucent Technologies, Inc.
Expires: March 2003
Document: draft-gurbani-spirits-security-01.txt
Services in the PSTN/IN Requesting InTernet Services (SPIRITS) protocol security
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document analyses the trust model inherent in SPIRITS with the
result of documenting possible security implications for the entities
participating in the SPIRITS network. It also proposes solutions for
countering the security threats that are possible in such a network.
1. Introduction
The Services in the PSTN/IN Requesting InTernet Services (SPIRITS)
IETF WG addresses how services supported by Internet Protocol (IP)
network entities can be started from Intelligent Network (IN)
requests as well as the protocol arrangements through which PSTN
(Public Switched Telephone Network) can request actions to be carried
out in the IP network in response to events (IN Triggers) occurring
within the PSTN/IN. To that extent, an architecture [1] has been
defined and work is currently underway [2] to specify a protocol
which will serve as an interface between the PSTN/IN and the IP
network. Familiarity with [1] and [2] is assumed.
This draft outlines the trust model inherent in SPIRITS and from that
model, outlines possible security implications for entities
participating in the SPIRITS network. Once the security implications
are laid out, possible solutions that address such problems will be
investigated. The final outcome of this draft is to form a coherent
security strategy for SPIRITS services, which will serve as input to
draft-gurbani-spirits-security-01.txt [Page 1]
SPIRITS protocol security September 2002
the SPIRITS protocol Internet-Draft [2].
The rest of this draft is organized as follows: section 2 reproduces
the SPIRITS architecture from [1] as a quick reference and provides
some background on the interfaces in the architecture that need to be
secured. Section 3 outlines the trust model inherent in a SPIRITS
network and uses it to generate possible security threats to SPIRITS
services. This section can thus serve as a requirement to guide the
SPIRITS security solution. Section 4 presents possible solutions to
the requirements posed in the earlier section.
2. The SPIRITS architecture
Architectures such as SPIRITS which involve multiple network domain,
multiple administrative domains and multiple protocols are
exceedingly hard to secure. Figure 1 below provides the joint
SPIRITS/PINT architecture as outlined in [1].
+--------------+
| Subscriber's |
| IP Host | +--------------+
| | | |
| +----------+ | | +----------+ |
| | PINT | | A | | PINT | |
| | Client +<-------/-------->+ Gateway +<-----+
| +----------+ | | +----------+ | |
| | | | |
| +----------+ | | +----------+ | |
| | SPIRITS | | B | | SPIRITS | | |
| | Server +<-------/-------->+ Gateway | | |
| +----------+ | | +--------+-+ | |
| | | ^ | |
+--------------+ +----------|---+ |
| |
IP Network | |
------------------------------------------|--------|---
PSTN / C / E
| |
v |
+----+------+ |
| SPIRITS | |
| Client | v
+-------------------+ +---+-----D-----+-++
| Service Switching |INAP/SS7 | Service Control |
| Function +---------+ Function |
+----+--------------+ +------------------+
|
|line
+-+
[0] Subscriber's phone
Figure 1: The SPIRITS Architecture.
Figure 1 contains many interfaces which are candidates for security; these
draft-gurbani-spirits-security-01.txt [Page 2]
SPIRITS protocol security September 2002
interfaces are described in detail in the SPIRITS architecture document
[1]. Of interest to us from Figure 1 are interfaces B and C only; security
for interfaces A and E is discussed in the PINT RFC [4] and thus will not be
addressed by this document. Likewise, interfaces in the PSTN -- namely,
interface D and the interface labeled "INAP/SS7" -- are assumed to be secured
by the virtue of their being in a controlled network (namely, the PSTN).
Thus, they will not be discussed in this document either.
This focus of this document is providing security for interfaces B and C
only.
3. The SPIRITS trust model
The SPIRITS architecture straddles two network domains: the PSTN and the
Internet. Additionally, at the very least, three authentication domains
are involved in a SPIRITS network:
(1) The PSTN service provider: this is the entity in the PSTN domain
which owns and/or operates the PSTN network on which SPIRITS events
are generated.
(2) The Requester: this is the entity in the IP domain which requests
the PSTN service provider to send it events of interest for service
execution.
(3) The SIP [3] service provider: this is the entity that provides
an IP transport to the requester (note that SIP has been chosen as
the SPIRITS protocol, see section 2.2 of [2]).
It could very well be that the SIP service provider and the PSTN service
provider are the same, but for the purpose of outlining a threat model,
we will consider them to be different entities.
Likewise, there are three network entities involved in a SPIRITS service:
(1) The SPIRITS server: also known as the subscriber, this SPIRITS
network entity uses a SIP REGISTER or a SIP SUBSCRIBE to indicate
an interest in getting notifications of events occurring in the
PSTN domain.
(2) The SPIRITS gateway: serves as an intermediary between the SPIRITS
client and the SPIRITS server; it may be owned by the PSTN service
provider, and if so, the security requirements for interface C may be
somewhat relaxed. However, we will assume that the SPIRITS gateway is
not necessarily owned by the PSTN service provider, and thus, as a
worst case scenario needs to implement robust security on interface C.
(3) The SPIRITS client: also known as the notifier, this SPIRITS
network entity uses a SIP INVITE or a SIP NOTIFY to transfer the
events of interest to the subscriber.
The fundamental IP security requirements revolve around the following
attributes:
draft-gurbani-spirits-security-01.txt [Page 3]
SPIRITS protocol security September 2002
o Preserving the confidentiality and integrity of the message
(encryption)
o Preventing reply attacks or message spoofing
o Preventing denial of service (DoS) attacks
o Providing for the authentication of parties involved in a transaction
o Providing privacy of the participants
In the SPIRITS trust model, we will take an extreme view and posit that
none of the authentication domains (and by extension, the network domains)
trust each other; in other words, security must be provided for interfaces
B and C with the assumption that no one trusts anyone else.
We now outline some specific security threats that are possible in a
SPIRITS service by analyzing the responsibility of each of the SPIRITS
authentication domains.
3.1 Requirements for the PSTN service provider
The PSTN provider is making available to other parties information that can
be very private in nature. The mechanism for it to do so is the arrival
of a SIP REGISTER or a SIP SUBSCRIBE request. It is far too easy for IP
network entities to spoof packets, thus filtering on IP addresses or
host names is probably not enough of a deterrent.
Requirement 1: Requests arriving at the SPIRITS client MUST be
authenticated.
The PSTN provider MUST authenticate any request arriving to it from the
SPIRITS gateway. Otherwise, if the requests were not authenticated, it is
entirely possible that unauthorized eavesdroppers will have the PSTN send
notifications to their endpoints instead, resulting in a DoS attack.
While Requirement 1 takes care of authenticating the requester to the
SPIRITS client, a mechanism is needed to establish a trust relationship
between the SPIRITS gateway and the SPIRITS client as well. Since the
SPIRITS gateway "fronts" the SPIRITS client, a long standing trust
relationship between them will expedite requests through interface C.
Requirement 2: A trust relationship MUST exist between the SPIRITS
gateway and the SPIRITS client.
SPIRITS makes possible services which depend on mobility as well. For
instance, a requester may make a request to get notified of the movements
(or location) of another user. The requester may be authenticated, but
in order to provide services, they MUST be authorized as well.
Requirement 3: The PSTN service provider MUST authorize service
requests before accepting them.
draft-gurbani-spirits-security-01.txt [Page 4]
SPIRITS protocol security September 2002
The PSTN service provider also sends SIP INVITE or SIP NOTIFY requests
(collectively called 'notification requests') to the requester. These
notification requests contain information which may be private and protected
from eavesdroppers. Thus, the PSTN service provider MUST attempt to secure
the notification requests on their way to the requester.
Requirement 4: The PSTN service provider MUST secure the notification
requests.
3.2 Responsibility of the requester (IP network entity)
The requester is responsible for informing the PSTN service provider of
the events it is interested in receiving the notification for. Since it
is using the resources of the PSTN, it MUST authenticate itself properly.
If such authentication is not available, the PSTN service provider may
choose not to honor the request from the requester.
Even if the identity of the requester has been well established, there is
a possibility that the request is either corrupted, maliciously altered,
or even replaced whilst in transition on interface B.
Requirement 5: The requests from the requester MUST be protected from
corruption, alteration, spoofing, and replay or delay attacks.
3.3 Responsibility of the SIP service provider
Note: need some discussion here -- what are the responsibilities, if any,
of the SIP service provider?
4. Security solutions
The previous section outlined numerous requirements on the authentication
domains of a SPIRITS network. This section matches up existing security
technologies to these requirements.
4.1 Requirement 1
Requirement 1 can be met by using the HTTP Digest authentication specified
in SIP [3]. Requests coming into the SPIRITS client will arrive via the
SPIRITS gateway. The SPIRITS gateway will not originate such requests,
instead, it will act as a proxy to forward requests from the SPIRITS server
to the SPIRITS client. Thus, an out of band mechanism is needed to arrange
for a shared secret between the requester and the PSTN service provider.
4.2 Requirement 2
If the SPIRITS gateway and the SPIRITS client belong to the same
authentication domain, IPSec [5] can be used, otherwise, the use of the
"sips:" scheme and TLS [6] is a good candidate.
Note: Is XML Digest something we can use here?
IPSec is a set of network-layer protocol tools that collectively can be
used as a secure replacement for traditional IP (Internet Protocol).
draft-gurbani-spirits-security-01.txt [Page 5]
SPIRITS protocol security September 2002
IPSec is most commonly used in architectures in which a set of hosts or
administrative domains have an existing trust relationship with one another.
IPSec is usually implemented at the operating system level in a host, or on
a security gateway that provides confidentiality and integrity for all
traffic it receives from a particular interface (as in a VPN architecture).
SIP supports the use of TLS on a hop by hop basis through the use of the
"sips:" scheme [3]. If the SPIRITS gateway and the SPIRITS client do not
belong to the same autonomous system, then the hop labeled interface 'C'
in Figure 1 MUST be secured through the use of a "sips:" URI.
4.3 Requirement 3
The PSTN service provider must authorize service requests to ensure
that they are valid before accepting them. How this is done is outside
the scope of SPIRITS. For instance, take the case of sending
notifications to Alice about Bob's location; Bob must obviously acquiesce
to having his whereabouts monitored.
4.4 Requirement 4
Note: Need some discussion here -- what is adequate between the
following two choices: (1) requiring the UAC to have a "sips:" URI,
or (2) using S/MIME for notification requests traveling to the
requester?
4.5 Requirement 5
The base SIP protocol supports S/MIME [7]. S/MIME allows SIP UAs to encrypt
MIME bodies within SIP, securing these bodies end-to-end. S/MIME can provide
end-to-end confidentiality and integrity for message bodies, as well as
mutual authentication. It is also possible to use S/MIME to provide a form
of integrity and confidentiality for SIP header fields through SIP message
tunneling.
5. Changes from previous drafts
Change from <draft-gurbani-spirits-security-00.txt>
o Incorporated comments from Alec Brusilovsky, Eric Grosse and Musa
Unmehopa.
6. Acknowledgments
Alec Brusilovsky, Eric Grosse, and Musa Unmehopa were kind enough to suffer
through the initial draft and suggest the missing pieces. Eric also
suggested the use of 'authentication domains' over 'organizational entities.'
AUTHOR'S ADDRESSES
Vijay K. Gurbani
2000 Lucent Lane
Rm 6G-440
Naperville, IL 60566
USA
draft-gurbani-spirits-security-01.txt [Page 6]
SPIRITS protocol security September 2002
Email: vkg@lucent.com
REFERENCES
Normative references
[1] L. Slutsman (Ed.), I. Faynberg, H. Lu, and M. Weissman, "The
SPIRITS Architecture", IETF RFC 3136, June 2001,
<http://www.ietf.org/rfc/rfc3136.txt>.
[2] V. Gurbani (Ed.), A. Brusilovsky, I. Faynberg, H-L. Lu, M.
Unmehopa, and K. Vemuri, "The SPIRITS Protocol", IETF I-D, Work in
Progress, expires December 2002, <http://www.ietf.org/internet-
drafts/draft-ietf-spirits-protocol-02.txt>.
[3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: The Session
Initiation Protocol", IETF RFC 3261, June 2002,
<http://www.ietf.org/rfc/rfc3261>
Informative references
[4] S. Petrack and L. Conroy, "The PINT Service Protocol: Extensions
to SIP and SDP for IP Access to Telephone Call Services", IETF RFC
2848, June 2002, <http://www.ietf.org/rfc/rfc2848.txt>
[5] S. Kent R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998,
<http://www.ietf.org/rfc/rfc2401.txt>
[6] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999, <http://www.ietf.org/rfc/rfc2246.txt>
[7] B. Ramsdell, "S/MIME Version 3 Message Specification", IETF RFC
2633, June 1999, <http://www.ietf.org/rfc/rfc2633.txt>
FULL COPYRIGHT STATEMENT
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
draft-gurbani-spirits-security-01.txt [Page 7]
SPIRITS protocol security September 2002
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
draft-gurbani-spirits-security-01.txt [Page 8]
