idnits 2.17.1 draft-ietf-spirits-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 84 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 199: '...arriving at the SPIRITS client MUST be...' RFC 2119 keyword, line 202: '...he PSTN provider MUST authenticate any...' RFC 2119 keyword, line 213: '...ust relationship MUST exist between th...' RFC 2119 keyword, line 219: '...e services, they MUST be authorized as...' RFC 2119 keyword, line 221: '...service provider MUST authorize servic...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 107, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3136 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '5') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '6') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. '7') (Obsoleted by RFC 3851) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Vijay K. Gurbani 3 October 2002 Lucent Technologies, Inc. 4 Expires: April 2003 6 Document: draft-ietf-spirits-security-00.txt 8 Services in the PSTN/IN Requesting InTernet Services (SPIRITS) protocol security 10 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 31 This document analyses the trust model inherent in SPIRITS with the 32 result of documenting possible security implications for the entities 33 participating in the SPIRITS network. It also proposes solutions for 34 countering the security threats that are possible in such a network. 36 1. Introduction 38 The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) 39 IETF WG addresses how services supported by Internet Protocol (IP) 40 network entities can be started from Intelligent Network (IN) 41 requests as well as the protocol arrangements through which PSTN 42 (Public Switched Telephone Network) can request actions to be carried 43 out in the IP network in response to events (IN Triggers) occurring 44 within the PSTN/IN. To that extent, an architecture [1] has been 45 defined and work is currently underway [2] to specify a protocol 46 which will serve as an interface between the PSTN/IN and the IP 47 network. Familiarity with [1] and [2] is assumed. 49 This draft outlines the trust model inherent in SPIRITS and from that 50 model, outlines possible security implications for entities 51 participating in the SPIRITS network. Once the security implications 52 are laid out, possible solutions that address such problems will be 53 investigated. The final outcome of this draft is to form a coherent 54 security strategy for SPIRITS services, which will serve as input to 56 SPIRITS protocol security October 2002 58 the SPIRITS protocol Internet-Draft [2]. 60 The rest of this draft is organized as follows: section 2 reproduces 61 the SPIRITS architecture from [1] as a quick reference and provides 62 some background on the interfaces in the architecture that need to be 63 secured. Section 3 outlines the trust model inherent in a SPIRITS 64 network and uses it to generate possible security threats to SPIRITS 65 services. This section can thus serve as a requirement to guide the 66 SPIRITS security solution. Section 4 presents possible solutions to 67 the requirements posed in the earlier section. 69 2. The SPIRITS architecture 71 Architectures such as SPIRITS which involve multiple network domain, 72 multiple administrative domains and multiple protocols are 73 exceedingly hard to secure. Figure 1 below provides the joint 74 SPIRITS/PINT architecture as outlined in [1]. 76 +--------------+ 77 | Subscriber's | 78 | IP Host | +--------------+ 79 | | | | 80 | +----------+ | | +----------+ | 81 | | PINT | | A | | PINT | | 82 | | Client +<-------/-------->+ Gateway +<-----+ 83 | +----------+ | | +----------+ | | 84 | | | | | 85 | +----------+ | | +----------+ | | 86 | | SPIRITS | | B | | SPIRITS | | | 87 | | Server +<-------/-------->+ Gateway | | | 88 | +----------+ | | +--------+-+ | | 89 | | | ^ | | 90 +--------------+ +----------|---+ | 91 | | 92 IP Network | | 93 ------------------------------------------|--------|--- 94 PSTN / C / E 95 | | 96 v | 97 +----+------+ | 98 | SPIRITS | | 99 | Client | v 100 +-------------------+ +---+-----D-----+-++ 101 | Service Switching |INAP/SS7 | Service Control | 102 | Function +---------+ Function | 103 +----+--------------+ +------------------+ 104 | 105 |line 106 +-+ 107 [0] Subscriber's phone 109 Figure 1: The SPIRITS Architecture. 111 Figure 1 contains many interfaces which are candidates for security; these 113 SPIRITS protocol security October 2002 115 interfaces are described in detail in the SPIRITS architecture document 116 [1]. Of interest to us from Figure 1 are interfaces B and C only; security 117 for interfaces A and E is discussed in the PINT RFC [4] and thus will not be 118 addressed by this document. Likewise, interfaces in the PSTN -- namely, 119 interface D and the interface labeled "INAP/SS7" -- are assumed to be secured 120 by the virtue of their being in a controlled network (namely, the PSTN). 121 Thus, they will not be discussed in this document either. 123 This focus of this document is providing security for interfaces B and C 124 only. 126 3. The SPIRITS trust model 128 The SPIRITS architecture straddles two network domains: the PSTN and the 129 Internet. Additionally, at the very least, three authentication domains 130 are involved in a SPIRITS network: 132 (1) The PSTN service provider: this is the entity in the PSTN domain 133 which owns and/or operates the PSTN network on which SPIRITS events 134 are generated. 136 (2) The Requester: this is the entity in the IP domain which requests 137 the PSTN service provider to send it events of interest for service 138 execution. 140 (3) The SIP [3] service provider: this is the entity that provides 141 an IP transport to the requester (note that SIP has been chosen as 142 the SPIRITS protocol, see section 2.2 of [2]). 144 It could very well be that the SIP service provider and the PSTN service 145 provider are the same, but for the purpose of outlining a threat model, 146 we will consider them to be different entities. 148 Likewise, there are three network entities involved in a SPIRITS service: 150 (1) The SPIRITS server: also known as the subscriber, this SPIRITS 151 network entity uses a SIP REGISTER or a SIP SUBSCRIBE to indicate 152 an interest in getting notifications of events occurring in the 153 PSTN domain. 155 (2) The SPIRITS gateway: serves as an intermediary between the SPIRITS 156 client and the SPIRITS server; it may be owned by the PSTN service 157 provider, and if so, the security requirements for interface C may be 158 somewhat relaxed. However, we will assume that the SPIRITS gateway is 159 not necessarily owned by the PSTN service provider, and thus, as a 160 worst case scenario needs to implement robust security on interface C. 162 (3) The SPIRITS client: also known as the notifier, this SPIRITS 163 network entity uses a SIP INVITE or a SIP NOTIFY to transfer the 164 events of interest to the subscriber. 166 The fundamental IP security requirements revolve around the following 167 attributes: 169 SPIRITS protocol security October 2002 171 o Preserving the confidentiality and integrity of the message 172 (encryption) 174 o Preventing reply attacks or message spoofing 176 o Preventing denial of service (DoS) attacks 178 o Providing for the authentication of parties involved in a transaction 180 o Providing privacy of the participants 182 In the SPIRITS trust model, we will take an extreme view and posit that 183 none of the authentication domains (and by extension, the network domains) 184 trust each other; in other words, security must be provided for interfaces 185 B and C with the assumption that no one trusts anyone else. 187 We now outline some specific security threats that are possible in a 188 SPIRITS service by analyzing the responsibility of each of the SPIRITS 189 authentication domains. 191 3.1 Requirements for the PSTN service provider 193 The PSTN provider is making available to other parties information that can 194 be very private in nature. The mechanism for it to do so is the arrival 195 of a SIP REGISTER or a SIP SUBSCRIBE request. It is far too easy for IP 196 network entities to spoof packets, thus filtering on IP addresses or 197 host names is probably not enough of a deterrent. 199 Requirement 1: Requests arriving at the SPIRITS client MUST be 200 authenticated. 202 The PSTN provider MUST authenticate any request arriving to it from the 203 SPIRITS gateway. Otherwise, if the requests were not authenticated, it is 204 entirely possible that unauthorized eavesdroppers will have the PSTN send 205 notifications to their endpoints instead, resulting in a DoS attack. 207 While Requirement 1 takes care of authenticating the requester to the 208 SPIRITS client, a mechanism is needed to establish a trust relationship 209 between the SPIRITS gateway and the SPIRITS client as well. Since the 210 SPIRITS gateway "fronts" the SPIRITS client, a long standing trust 211 relationship between them will expedite requests through interface C. 213 Requirement 2: A trust relationship MUST exist between the SPIRITS 214 gateway and the SPIRITS client. 216 SPIRITS makes possible services which depend on mobility as well. For 217 instance, a requester may make a request to get notified of the movements 218 (or location) of another user. The requester may be authenticated, but 219 in order to provide services, they MUST be authorized as well. 221 Requirement 3: The PSTN service provider MUST authorize service 222 requests before accepting them. 224 SPIRITS protocol security October 2002 226 The PSTN service provider also sends SIP INVITE or SIP NOTIFY requests 227 (collectively called 'notification requests') to the requester. These 228 notification requests contain information which may be private and protected 229 from eavesdroppers. Thus, the PSTN service provider MUST attempt to secure 230 the notification requests on their way to the requester. 232 Requirement 4: The PSTN service provider MUST secure the notification 233 requests. 235 3.2 Responsibility of the requester (IP network entity) 237 The requester is responsible for informing the PSTN service provider of 238 the events it is interested in receiving the notification for. Since it 239 is using the resources of the PSTN, it MUST authenticate itself properly. 240 If such authentication is not available, the PSTN service provider may 241 choose not to honor the request from the requester. 243 Even if the identity of the requester has been well established, there is 244 a possibility that the request is either corrupted, maliciously altered, 245 or even replaced whilst in transition on interface B. 247 Requirement 5: The requests from the requester MUST be protected from 248 corruption, alteration, spoofing, and replay or delay attacks. 250 3.3 Responsibility of the SIP service provider 252 Note: need some discussion here -- what are the responsibilities, if any, 253 of the SIP service provider? 255 4. Security solutions 257 The previous section outlined numerous requirements on the authentication 258 domains of a SPIRITS network. This section matches up existing security 259 technologies to these requirements. 261 4.1 Requirement 1 263 Requirement 1 can be met by using the HTTP Digest authentication specified 264 in SIP [3]. Requests coming into the SPIRITS client will arrive via the 265 SPIRITS gateway. The SPIRITS gateway will not originate such requests, 266 instead, it will act as a proxy to forward requests from the SPIRITS server 267 to the SPIRITS client. Thus, an out of band mechanism is needed to arrange 268 for a shared secret between the requester and the PSTN service provider. 270 4.2 Requirement 2 272 If the SPIRITS gateway and the SPIRITS client belong to the same 273 authentication domain, IPSec [5] can be used, otherwise, the use of the 274 "sips:" scheme and TLS [6] is a good candidate. 276 Note: Is XML Digest something we can use here? 278 IPSec is a set of network-layer protocol tools that collectively can be 279 used as a secure replacement for traditional IP (Internet Protocol). 281 SPIRITS protocol security October 2002 283 IPSec is most commonly used in architectures in which a set of hosts or 284 administrative domains have an existing trust relationship with one another. 285 IPSec is usually implemented at the operating system level in a host, or on 286 a security gateway that provides confidentiality and integrity for all 287 traffic it receives from a particular interface (as in a VPN architecture). 289 SIP supports the use of TLS on a hop by hop basis through the use of the 290 "sips:" scheme [3]. If the SPIRITS gateway and the SPIRITS client do not 291 belong to the same autonomous system, then the hop labeled interface 'C' 292 in Figure 1 MUST be secured through the use of a "sips:" URI. 294 4.3 Requirement 3 296 The PSTN service provider must authorize service requests to ensure 297 that they are valid before accepting them. How this is done is outside 298 the scope of SPIRITS. For instance, take the case of sending 299 notifications to Alice about Bob's location; Bob must obviously acquiesce 300 to having his whereabouts monitored. 302 4.4 Requirement 4 304 Note: Need some discussion here -- what is adequate between the 305 following two choices: (1) requiring the UAC to have a "sips:" URI, 306 or (2) using S/MIME for notification requests traveling to the 307 requester? 309 4.5 Requirement 5 311 The base SIP protocol supports S/MIME [7]. S/MIME allows SIP UAs to encrypt 312 MIME bodies within SIP, securing these bodies end-to-end. S/MIME can provide 313 end-to-end confidentiality and integrity for message bodies, as well as 314 mutual authentication. It is also possible to use S/MIME to provide a form 315 of integrity and confidentiality for SIP header fields through SIP message 316 tunneling. 318 5. Changes from previous drafts 320 Change from 321 o Changed name of I-D to draft-ietf-spirits-security-00 to reflect WG 322 agenda item. 324 Change from 325 o Incorporated comments from Alec Brusilovsky, Eric Grosse and Musa 326 Unmehopa. 328 6. Acknowledgments 330 Many thanks to Steve Bellovin, Alec Brusilovsky, Eric Grosse, and Musa 331 Unmehopa. Alec, Eric, and Musa were kind enough to suffer through the 332 initial draft and suggest the missing pieces. Eric also suggested the 333 use of 'authentication domains' over 'organizational entities.' Steve 334 Bellovin pushed hard to get this discussion started in a formal manner. 336 AUTHOR'S ADDRESSES 337 SPIRITS protocol security October 2002 339 Vijay K. Gurbani 340 2000 Lucent Lane 341 Rm 6G-440 342 Naperville, IL 60566 343 USA 344 Email: vkg@lucent.com 346 REFERENCES 348 Normative references 350 [1] L. Slutsman (Ed.), I. Faynberg, H. Lu, and M. Weissman, "The 351 SPIRITS Architecture", IETF RFC 3136, June 2001, 352 . 354 [2] V. Gurbani (Ed.), A. Brusilovsky, I. Faynberg, H-L. Lu, M. 355 Unmehopa, and K. Vemuri, "The SPIRITS Protocol", IETF I-D, Work in 356 Progress, expires December 2002, . 359 [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 360 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: The Session 361 Initiation Protocol", IETF RFC 3261, June 2002, 362 364 Informative references 366 [4] S. Petrack and L. Conroy, "The PINT Service Protocol: Extensions 367 to SIP and SDP for IP Access to Telephone Call Services", IETF RFC 368 2848, June 2002, 370 [5] S. Kent R. Atkinson, "Security Architecture for the Internet 371 Protocol", RFC 2401, November 1998, 372 374 [6] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", RFC 375 2246, January 1999, 377 [7] B. Ramsdell, "S/MIME Version 3 Message Specification", IETF RFC 378 2633, June 1999, 380 FULL COPYRIGHT STATEMENT 382 "Copyright (C) The Internet Society (date). All Rights Reserved. This 383 document and translations of it may be copied and furnished to 384 others, and derivative works that comment on or otherwise explain it 385 or assist in its implementation may be prepared, copied, published 386 and distributed, in whole or in part, without restriction of any 387 kind, provided that the above copyright notice and this paragraph are 388 included on all such copies and derivative works. However, this 389 document itself may not be modified in any way, such as by removing 390 the copyright notice or references to the Internet Society or other 391 Internet organizations, except as needed for the purpose of 392 developing Internet standards in which case the procedures for 394 SPIRITS protocol security October 2002 396 copyrights defined in the Internet Standards process must be 397 followed, or as required to translate it into followed, or as 398 required to translate it into languages other than English. 400 The limited permissions granted above are perpetual and will not be 401 revoked by the Internet Society or its successors or assigns. 403 This document and the information contained herein is provided on an 404 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 405 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 406 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 407 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 408 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.