[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                         Vijay K. Gurbani
October 2002                                  Lucent Technologies, Inc.
Expires: April 2003

Document: draft-ietf-spirits-security-00.txt

Services in the PSTN/IN Requesting InTernet Services (SPIRITS) protocol security

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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-ietf-spirits-security-00.txt                             [Page 1]

SPIRITS protocol security                                   October 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     |
               +----+--------------+         +------------------+
                   [0] Subscriber's phone

                    Figure 1: The SPIRITS Architecture.

   Figure 1 contains many interfaces which are candidates for security; these

draft-ietf-spirits-security-00.txt                             [Page 2]

SPIRITS protocol security                                   October 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

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

      (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

draft-ietf-spirits-security-00.txt                             [Page 3]

SPIRITS protocol security                                   October 2002

      o Preserving the confidentiality and integrity of the message

      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

   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-ietf-spirits-security-00.txt                             [Page 4]

SPIRITS protocol security                                   October 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

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-ietf-spirits-security-00.txt                             [Page 5]

SPIRITS protocol security                                   October 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

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

5. Changes from previous drafts

   Change from <draft-gurbani-spirits-security-01.txt>
      o Changed name of I-D to draft-ietf-spirits-security-00 to reflect WG
      agenda item.

   Change from <draft-gurbani-spirits-security-00.txt>
      o Incorporated comments from Alec Brusilovsky, Eric Grosse and Musa

6. Acknowledgments

   Many thanks to Steve Bellovin, Alec Brusilovsky, Eric Grosse, and Musa
   Unmehopa.  Alec, Eric, and Musa 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.'  Steve
   Bellovin pushed hard to get this discussion started in a formal manner.


draft-ietf-spirits-security-00.txt                             [Page 6]

SPIRITS protocol security                                   October 2002

   Vijay K. Gurbani
   2000 Lucent Lane
   Rm 6G-440
   Naperville, IL 60566
   Email: vkg@lucent.com


Normative references

   [1]  L. Slutsman (Ed.), I. Faynberg, H. Lu, and M. Weissman, "The
   SPIRITS Architecture", IETF RFC 3136, June 2001,

   [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-

   [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,

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,

   [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>


   "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

draft-ietf-spirits-security-00.txt                             [Page 7]

SPIRITS protocol security                                   October 2002

   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
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

draft-ietf-spirits-security-00.txt                             [Page 8]