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 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-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 | +----+--------------+ +------------------+ | |line +-+ [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 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-ietf-spirits-security-00.txt [Page 3]
SPIRITS protocol security October 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-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 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-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 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-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 Unmehopa. 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. AUTHOR'S ADDRESSES 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 USA 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 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 "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-ietf-spirits-security-00.txt [Page 8]
