idnits 2.17.1 draft-tschofenig-sipping-framework-spit-reduction-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1016. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (July 14, 2008) is 5763 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.schwartz-sipping-spit-saml' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'I-D.niccolini-sipping-feedback-spit' is defined on line 862, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-12) exists of draft-ietf-dkim-overview-10 == Outdated reference: A later version (-08) exists of draft-ietf-sip-ua-privacy-01 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-03 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational H. Schulzrinne 5 Expires: January 15, 2009 Columbia University 6 D. Wing 7 J. Rosenberg 8 Cisco Systems 9 D. Schwartz 10 XConnect 11 July 14, 2008 13 A Framework to tackle Spam and Unwanted Communication for Internet 14 Telephony 15 draft-tschofenig-sipping-framework-spit-reduction-04 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 15, 2009. 42 Abstract 44 Spam, defined as sending unsolicited messages to someone in bulk, is 45 likely to become a problem on SIP open-wide deployed networks. A 46 number of solutions have been proposed for dealing with Spam for 47 Internet Telephony (SPIT) and unwanted communication, such as content 48 filtering, black lists, white lists, consent-based communication, 49 reputation systems, address obfuscation, limited use addresses, 50 turing tests, computational puzzles, payments at risk, circles of 51 trust, and many others. 53 This document describes the big picture that illustrates how the 54 different building blocks fit together and can be deployed 55 incrementally. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Communication Patterns and User Groups . . . . . . . . . . . . 9 63 4.1. Closed Groups . . . . . . . . . . . . . . . . . . . . . . 9 64 4.2. Semi-Open Groups . . . . . . . . . . . . . . . . . . . . . 9 65 4.3. Open Groups . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11 69 5.1. Rule Enforcement via a Trusted Intermediary . . . . . . . 12 70 5.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 12 71 5.3. Botnets . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15 73 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 79 Appendix A. Authorization Engine in SIP UA . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 81 Intellectual Property and Copyright Statements . . . . . . . . . . 24 83 1. Introduction 85 The problem of Spam for Internet Telephony (SPIT) is an imminent 86 challenge and only the combination of several techniques can provide 87 a way to deal with unwanted communication attempts. 89 [RFC5039] provides four core recommendations that need to be 90 considered for a SPIT solution, namely 92 o Strong Identity 93 o White Lists 94 o Solve the Introduction Problem 95 o Don't Wait Until its Too Late 97 This document illustrates how existing building blocks can be put 98 together to be able to recognize unwanted communication attempts and 99 to execute appropriate actions. Ideally, a framework should allow 100 new building blocks to be added as adversaries become more 101 sophisticated. Since there are strong economical incentives for 102 adversary to exploit communication networks that are widely deployed 103 it only possible to detect and react on unwanted communication 104 attempts in such a way that the total number of unwanted 105 communication attempts reaches a level that is acceptable for the end 106 user considering false positives and the additional burden for the 107 users using these mechanisms. 109 The purpose of this document defines a model of internal device 110 processing, protocol interfaces, and terminology to illustrate a way 111 in which SPIT prevention techniques can be added in a seamless 112 fashion. This document focuses on the descripion of how to combine 113 different building blocks in an architectural fashion. No specific 114 pre-selection is being provided on what mechanism should be 115 standardized or implemented by various parties. This is left to the 116 parties deploying these mechanisms and, when it comes to 117 standardization, subject of a separate document to pick an initial 118 set of mechanisms to start with. 120 2. Terminology 122 This document does not contain normative language. 124 3. Framework 126 Figure 1 shows the interaction between the end host and a SIP proxy 127 belonging to its VoIP provider. One important part of the overall 128 solution is the ability to make authorization decisions based on 129 incoming communication attempts. The entity that writes these 130 authorization rules is referred as Rule Maker. A human, acting as 131 the Rule Maker, might enter policies via some form of graphical user 132 interface; some other policies may be generated automatically by 133 observing the behavior of the user. Furthermore, in certain 134 deployment environments an initial rule set will be provided by some 135 third party entity, such as the enterprise system administrator or 136 the VoIP service provider. 138 Policies are processed by corresponding module within the SIP proxy, 139 called Authorization Engine, that interacts with the message routing 140 component. By following this architectural approach the Policy 141 Decision Point (PDP) and the Policy Enforcement Point (PEP) are 142 closely combined. As such, authorization policies are stored at at a 143 SIP proxy rather than the SIP UA client itself. The implications of 144 relocating these two functions, PDP and PEP, to the SIP UA client are 145 described in Appendix A. 147 +---------------------------------------------------------+ 148 | Authorization | 149 | re-route Policy +------------+ | 150 | ^ (implicit) ######| Rule Maker | | 151 | o +#######+ # +------------+ | 152 | o # # # | 153 | +---o----------#-------#--+ # Authorization | 154 | | o # # |<####### Policy | 155 +--------+ | | o Proxy # # | | 156 | | | | o # # |<*******************+ | 157 | Sender |<***>|+-------+ v # | * | 158 | | | ||Msg. | +-----------+| Authorization * | 159 +--------+ | ||Routing| | Authz. || Policy (explicit) * | 160 ^ o | ||Engine |<->| Engine |<#################+ * | 161 * o | |+-------+ +-----------+| # * | 162 * o | +-^--*--^-----------------+ # v | 163 * o | o * o +-------------+ | 164 * o | o * o | | | 165 * +oooo|oooo+ * +ooooooooooooooooooooooooooooo>| Recipient/ | | 166 +**************************************************>| Rule Maker | | 167 | +-------------+ | 168 | | 169 | | 170 +-------------------Domain Boundary-----------------------+ 172 Legend: 174 oooo: SIP message interaction 175 ****: Protocol Interaction for authorizing the message sender 176 ####: Management of authorization policies 178 Figure 1: Overview 180 Assume that an arbitrary entity transmits a message to a specific URI 181 that finally hits the SIP proxy on the recipients side. Information 182 provided within that message are used as input to the rule 183 evaluation. Any part of the message may serve as input to the 184 evaluation process but for practical reasons a few selected fields do 185 most of the work. There are three aspects to consider when it comes 186 to the rule evaluation: 188 Where does identity information come from? 190 Authentication information can come in different forms, depending 191 on the chosen SIP security mechanism (e.g., P-Asserted-ID 192 [RFC3325] or SIP Identity [RFC4474]). Additionally, the 193 interworking with the privacy mechanisms, such as [RFC3323] or 194 [I-D.ietf-sip-ua-privacy] need to be considered. 196 An example of how these different mechanisms are being considered 197 during the rule evaluation is described in Common Policy [RFC4745] 198 and Presence Authorization Policy [RFC5025]. 200 What is the quality of the authentication procedure? 202 When evaluating authorization policies with respect to an incoming 203 request the identity information of the entity sending the message 204 may provide enough information when the recipient authorized that 205 specific sender's identity. However, when the authorization 206 policies refer to entire domains instead of individual users then 207 it would be valuable to know how easily users within that specific 208 domain are able to aquire their identities and how strong the 209 authentication procedure actuallly is. Consider the following 210 example: an enterprise network provisions entities to employees 211 only and the authentication credentials are based on a smart card 212 based mechanism. In an other case new identities can be created 213 on the fly using a protocol interaction with an email-address 214 based return routability check without additional verification. 215 As such, in these two examples the chances to hold a real-world 216 person accountable for their actions is very likely to be 217 different in case that abuse reports are received by the two VoIP 218 providers. Unfortunately, information about such a process is 219 often not available when the authorization decision is being made. 221 Who creates the policies? 223 Identity based authorization rules may contain entries for 224 specific users or for entire domains. Such policies may be 225 configured by the end host as a Rule Maker or by the VoIP provider 226 themself. Particularly the later part is likely to be attractive 227 for VoIP providers since they may be able to form federations of 228 VoIP providers that fulfill certain preconditions with respect to 229 their VoIP / IM usage. These type of federations are also the 230 basis for getting SIP SAML [I-D.ietf-sip-saml] to work since a 231 valid digital signature together with the presence of certain 232 assertions statements is insufficient as a basis for trusting 233 their content. 235 As illustrated above, there are various possible actions that may be 236 taken by the receipient or it's VoIP provider to authorize the 237 message sender. Some of these mechanisms may require interaction 238 with the sender. The request for authorization might require the 239 message sender to be challenged (e.g., via hash cash 240 [I-D.jennings-sip-hashcash], via SIP payment 241 [I-D.jennings-sipping-pay], or via CAPTCHAs 242 [I-D.tschofenig-sipping-captcha]). Some other mechanisms, such as 243 SIP Identity do not require the verifying entity to challenge the 244 authentication service since the identity assertion is pushed towards 245 the recipient. 247 Additionally, it is possible to utilize mechanisms the Consent 248 Framework [I-D.ietf-sipping-consent-framework] or the Information 249 Event Package [RFC3857] to allow the recipient to authorize a 250 request. 252 Figure 2 shows this integration step. The conditions part of the 253 rule offer a mechanisms to incrementally extend the overall framework 254 with new components. Depending on the outcome of the rule 255 evaluation, the message may be re-routed to another entity, such as 256 an answering machine, to the recipient, rejected or other actions are 257 triggered. The latter aspect is particularly interesting since it 258 allows further solution components to be executed. 260 SIP msg with 261 authenticated 262 identity +---------------+ 263 -------------->| |----------------> 264 Additional | | Spam marked msg 265 Msg fields | Authorization | 266 -------------->| Engine |----------------> 267 Other SPIT | | Re-routed msg 268 Prevention | | 269 Components | |----------------> 270 -------------->+---------------+ Forwarded to 271 | | original recipient 272 | | 273 <-----------+ +----------->|| 274 Politely blocked Blocked 276 Figure 2: Message Filtering and Routing 278 Note that some traffic analysis and consequently some form of content 279 filtering (e.g., of MESSAGEs) message be applied locally within the 280 VoIP provider's domain also under the control of the end user. 281 However, this is largely an implementation-specific technique without 282 protocol impact. For example, consider a VoIP provider that wants to 283 utilize a statistical analysis tool for Spam prevention. It is not 284 necessary to standardized the algorithms nor protocols; the impact 285 for the authorization policies is mainly the ability to allow the 286 Rule Maker to enable or to disable the usage of these statistical 287 techniques and potentially to map the output of the analysis process 288 to value range from 0 (i.e., the message is not classified as Spam) 289 and 100 (i.e., the message was classified as Spam). A Rule Maker may 290 decide to act with an appropriate action on a certain level of Spam 291 marking. 293 Authenticated Identities: 295 Initial VoIP provider are likely to secure their SIP signaling 296 using Transport Layer Security (TLS) or IP security (IPsec) 297 between neighboring providers and use P-Asserted-ID [RFC3325]. 299 Note: SIP Identity is comparable to DomainKeys Identified Mail 300 (DKIM) [I-D.ietf-dkim-overview] used for associating a 301 "responsible" identity with an email message and provides a 302 means of verifying that the association is legitimate. 304 SIP Identity [RFC4474] is a proposal for stronger security 305 mechanisms used to provide the verification service with the 306 authenticated identity. SIP Identity is a reasonably simple 307 specification and does not rely on a huge amount of infrastructure 308 support. 310 This framework does not assume a specific mechanism for asserting 311 identities to be used but a strong identity mechanism is a pre- 312 requisity for authorization policy handling to be successful. 314 Authorization Policies: 316 Even if policy decision making and policy enforcement is done 317 outside the SIP UA client then still there might not be a need to 318 standardize an authorization policy language if the policies can 319 be modified via a webpage. This approach of policy handling is 320 done in many cases today already for various applications. 322 Unfortunately, this approach tends to become cumbersome for end 323 users and therefore it is better to hide a lot of policy details 324 from the end user itself and to make use of context information, 325 for example, address books and authorization policies available 326 already created for presence based systems. 328 Additionally, a user may have multiple devices and a consistent 329 view of the policies should be provided. 331 An example solution for authorization policies for dealing with 332 reducing unwanted communication is described in 333 [I-D.tschofenig-sipping-spit-policy] with the requirements 334 detailed in [I-D.froment-sipping-spit-requirements]. 336 There is still one significant problem unsolved: since white lists 337 need to be created somehow and hence there is an introduction 338 problem. Section 4 discusses this aspect in more details. 340 4. Communication Patterns and User Groups 342 When communication takes place then at least three types of groups 343 can be identified. 345 4.1. Closed Groups 347 People in this group communicate only with the peers in their group. 348 They do not appreciate communication attempts from outside. 349 Communication is possible only for people within this list. Here is 350 an example of a closed group: Consider parents that do not want their 351 children from getting contacted by strangers. Hence, they may want 352 to create a white list containing the identifies of known friends, 353 parents and other relatives on behalf of their kids. 355 The usage of authorization policies for usage with closed groups is 356 straight forward. The introduction problem is also not considered 357 very large given that the identities of the individual entities are 358 typically known in an out-of-band fashion. 360 4.2. Semi-Open Groups 362 In a semi-open environment all members of the same group are allowed 363 to get in contact with everyone else (e.g., persons working within 364 the same company are allowed to contact each other without 365 restrictions). For the communication with persons outside the 366 company the communication patters depend on the role of the specific 367 person (e.g., standardization people, sales people, etc.) and on the 368 work style of the person. 370 For this category we distinguish a number of (non-spam) message 371 sources based on their characteristics: 373 o "friends" or "acquaintances", i.e., those we have communicated 374 with before. 375 o strangers, divided into 'interesting' and 'uninteresting'. The 376 latter are messages from people that someone does not care to have 377 a conversation with or respond to, at least at that particular 378 moment. 380 Strangers can be defined by individual names or whole domains. A 381 special class of 'stranger' messages are transaction-related 382 communications, such as automated messages or calls from an airline 383 or shipping company. 385 One way to deal with the introduction problem is to make use of 386 techniques like hash cash [I-D.jennings-sip-hashcash] or Completely 387 Automated Public Turing Test to Tell Computers and Humans Apart 388 (CAPTCHA) based robot challenges [I-D.tschofenig-sipping-captcha]. 389 Alternatively, a communication attempt may also be forwarded to an 390 answering maschine or alternative ways of establishing the initial 391 interaction may be proposed. 393 The usage of authorization policies for usage with Semi-Open Groups 394 is challenging but is considered manageable. 396 4.3. Open Groups 398 People in this type of group are not allowed to limit communication 399 attempts. Help desks, certain people in governmental agencies, 400 banks, insurance companies, etc. 402 For open groups a solution for providing SPIT prevention is far more 403 complicated. Consider a person working on a customer support 404 helpdesk. Ideally, they would like to receive only calls from 405 friendly customers (although the motivation for calling is most 406 likely a problem they experience) and the topic of the calls only 407 relates to problems they are able to solve. Without listening to the 408 caller they will have a hard time to know whether the call could be 409 classified as SPIT or not. Another extreme case is a Public Safety 410 Answering Point where emergency service personell is not allowed to 411 reject calls either. 413 Many SPIT prevention techniques might not be applicable since 414 blocking callers is likely not possible and applying other 415 techniques, such as turing tests, might not be ideal in an case of 416 open groups. 418 Providing additional information about the caller may be helpful from 419 the called party VoIP provider but cannot be considered sufficient. 420 A more promising approach is the ability to provide abuse reporting 421 in the style of [XEP-0161] to provide the ability for punishment in 422 case of misuse. This approach is helpful if an honest VoIP provider 423 has to deal with a small number of adversaries within their network 424 and the abuse reporting entity is trusted by that VoIP provider as 425 well. This technique is not helpful when VoIP provider itself is 426 convolated in sending spam messages or has some other financial 427 benefits from not holding the adversary accountable. Another 428 possible approach is to establish blacklisted domains within a 429 federation, as this is common practice within the email domain. 431 4.4. Summary 433 Based on the discussions regarding communication patters and groups 434 the following observations can be made: 436 o A single person very likely has many roles and they may have an 437 impact on the communication patterns. 438 For example, consider a person who is working in a company but 439 also want to be available for family members. 440 o The context in which a person is may change at any time. For 441 example, a person might be available for family members while at 442 work except during an important meeting where communication 443 attempts may be rejected. Switching a context has an impact for 444 reachability and the means for communicating with a specific 445 recipient, based on enabled rule sets. 447 From an authorization policy point of view it is important to be able 448 to express a sphere (i.e., the state a user is in) and to switch 449 between different spheres easily by thereby switching to a different 450 rule set. 452 4.5. Usability 454 An important aspect in the usage of authorization policies is to 455 assist the user when creating policies. Ideally, the policies should 456 be established automatically. Below, there are a couple of examples 457 to illustrate the idea given that these aspects are largely 458 implementation issues: 460 o It must be possible for the proxy to automatically add addresses 461 on outbound messages and calls to the rule set. This approach is 462 similar to stateful packet filtering firewalls where outbound 463 packets establish state at the firewall to allow inbound packets 464 to traverse it again. 465 o Already available information in the address book can be used for 466 building the policy rules there is quite likely already a 467 relationship available with these persons existent. 468 o A large amount of email is non-personal, automated communication, 469 such as newsletters, confirmations and legitimate advertisements. 470 These are often tagged as spam by content filters. This type of 471 correspondence is usually initiated by a transaction over the web, 472 such as a purchase or signing up for a service. 473 [I-D.shacham-http-corr-uris], for example, defines an HTTP header 474 for conveying future correspondence addresses that can be 475 integrated in the rule set. 477 5. Protocol Interactions 479 This section describes the necessary building blocks that are 480 necessary to tie the framework together. 482 5.1. Rule Enforcement via a Trusted Intermediary 484 o Some from of strong identity assurance is required to build the 485 basis for identity-based authorization. SIP Identity [RFC4474] or 486 P-Asserted-ID [RFC3325] are examples of available mechanisms. 487 These mechanisms allow the authenticated identity of the sending 488 party to be determined. 489 o Authorization Policies based on the Common Policy framework 490 [RFC4745], as extended in [I-D.tschofenig-sipping-spit-policy] for 491 the purpose of SPIT prevention, are mandatory to implement at the 492 end host side and at the trusted intermediary. The implementation 493 of the rule evaluation engine might only be necessary on the 494 trusted VoIP proxy. Harmonization with the work done for presence 495 authorization [RFC5025], which is based on Common Policy 496 [RFC4745], can be accomplished and is highly desirable. 497 o XML Configuration Access Protocol (XCAP) [RFC4825] is used to 498 create, modify and delete authorization policies and is mandatory 499 to implement at the end host side and at the trusted intermediary. 501 5.2. Incremental Deployment 503 An important property is incremental deployment of additional 504 solution components that can be added and used when they become 505 available. This section aims to illustrate how the extensibility is 506 accomplished, based on an example. 508 Consider a VoIP provider that provides authorization policies that 509 provide the following functionality equivalent to the Common Policy 510 framework, i.e., identity-based, sphere and validity based conditions 511 initially. For actions only 'redirection' and 'blocking' is 512 provided. In our example we give this basic functionality the AUID 513 'new-spit-policy-example' with the namespace 514 'urn:ietf:params:xml:ns:new-spit-policy-example'. 516 When a client queries the capabilities of a SIP proxy in the VoIP 517 providers network using XCAP the following exchange may take place. 519 GET /xcap-caps/global/index HTTP/1.1 520 Host: xcap.example.com 522 Figure 3: Initial XCAP Query for Capabilities 524 HTTP/1.1 200 OK 525 Etag: "wwhha" 526 Content-Type: application/xcap-caps+xml 528 529 530 531 new-spit-policy-example 532 xcap-caps 533 534 535 urn:ietf:params:xml:ns:xcap-caps 536 urn:ietf:params:xml:ns:spit-policy 537 urn:ietf:params:xml:ns:common-policy 538 539 541 Figure 4: Initial XCAP Response with the supported Capabilities 543 As shown in the example above, Common Policy and the example SPIT 544 extension is implemented and the client can upload rules according to 545 the definition of the rule set functionality. 547 Later, when the VoIP provider updates the functionality of 548 authorization policies as more sophisticated mechanisms become 549 available and get implemented the functionality of the authorization 550 policy engine is enhanced with, for example, hashcash and the ability 551 to perform statistical analysis of signaling message. The latter 552 functionality comes with the ability to mark messages are Spam and 553 the ability for end users to enable/disable this functionality. We 554 use the namespaces 'urn:ietf:params:xml:ns:hashcash' and 555 'urn:ietf:params:xml:ns:statistical-analysis' for those. 557 A end user could now make use of these new functions and a capability 558 query of the SIP proxy would provide the following response. 560 GET /xcap-caps/global/index HTTP/1.1 561 Host: xcap.example.com 563 Figure 5: Second XCAP Query for Capabilities 565 HTTP/1.1 200 OK 566 Etag: "wwhha" 567 Content-Type: application/xcap-caps+xml 569 570 571 572 spit-policy 573 xcap-caps 574 hashcash 575 statistical-analysis 576 577 578 urn:ietf:params:xml:ns:spit-policy 579 urn:ietf:params:xml:ns:common-policy 580 urn:ietf:params:xml:ns:hashcash 581 urn:ietf:params:xml:ns:statistical-analysis 582 583 585 Figure 6: Second XCAP Response with the supported Capabilities 587 New SPIT handling functionality may extend condition, actions and/or 588 transformation elements of a rule. 590 5.3. Botnets 592 A botnet is a large number of compromised maschines that are used to 593 create and send spam or viruses or flood a network with messages as a 594 denial of service attack. 596 Such a botnet represents a significant challenge for a VoIP 597 infrastructure and also for the mechanisms proposed in this document. 598 Recently observed attacks indicated that some botnets tried to steal 599 credentials to distribute messages with "real" identities. To deal 600 with the threat it is useful to classify the behavior of these bots 601 into three categories, namely 603 o The botnet does not have access to the user's credentials. In 604 this case identity-based white lists provides adequate protection. 605 o The botnets does have access to user's credentials of compromised 606 maschines but distributes messages in a random fashion. In this 607 case identity-based white lists provides adequate protection since 608 it is unlikely that the recipient will have that person in their 609 whitelist. 610 o In this category the botnet has access to the user's credentials 611 and utilizes addresses from the user's addressbook. In this case 612 whitelists do not provide a proper protection. Since the 613 recipient knows the sender of the message it would, in many cases, 614 be able to get in contact with him or her and report the observed 615 problem. This approach does not work with a pure maschine-to- 616 maschine communication environment without user involvement. 618 6. Privacy Considerations 620 This document does not propose to distribute the user's authorization 621 policies to other VoIP providers nor is the configuration of policies 622 at SIP proxies other than the trusted user's VoIP provider necessary. 623 Furthemore, if blocking or influencing of the message processing is 624 executed by the VoIP provider then they have to be explicitly enabled 625 by the end user. Blocking of messages, even if it is based on 626 "super-clever" machine learning techniques often introduces 627 unpredictability. 629 Legal norms from fields of law can take regulative effects in the 630 context of SPIT processing, such as constitutional law, data 631 protection law, telecommunication law, teleservices law, criminal 632 law, and possibly administrative law. See, for example, [Law1], 633 [Law2] and [Law3]. For example, it is mandatory to pass full control 634 of SPIT filtering to the end user, as this minimises legal problems. 636 An overview about regulatory aspects can be found in [Spit-AL]. 638 7. Example 640 This section shows an example whereby we consider a user 641 Bob@company-example.com that writes (most likely via a nice user 642 interface) the following policies. We use a high-level language to 643 show the main idea of the policies. 645 RULE 1: 646 IF identity=alice@foo.example.com THEN ACCEPT 647 IF identity=tony@bar.example.com THEN ACCEPT 649 RULE 2: 650 IF domain=company-example.com THEN ACCEPT 652 RULE 3: 653 IF unauthenticated THEN 654 EXECUTE hashcash 656 RULE 4: 657 IF 658 THEN 659 REDIRECT sip:voicebox@company-example.com 661 RULE 5: 662 IF 663 THEN 664 block 666 Figure 7: Example of Bob's Rule Set 668 At some point in time Bob uploads his policies to the SIP proxy at 669 his VoIP providers SIP proxy. 671 PUT 672 /spit-policy/users/sip:bob@company-example.com/index/~~/ruleset 674 HTTP/1.1 675 Content-Type:application/spit+xml 676 Host: proxy.home-example.com 678 <<<< Added policies go in here. >>>> 680 Figure 8: Uploading Policies using XCAP 682 When BoB receives a call from his friends, alice@foo.example and 683 tony@bar.example.com, then all the rules related to the spit policy 684 are checked. Only the first rule (rule 1) matches and is applied. 685 Thus, the call is forwarded without any further checks based on Rule 686 1. The rules assume that the authenticated identity of the caller 687 has been verified. 689 When Bob receives a call from a co-worker, 690 Charlie@company-example.com, Rule 2 is applied since the domain part 691 in the rule matches the domain part of Charlie's identity. 693 Now, when Bob receives a contact from an unknown user, called Mallice 694 in this example. Rule 3 indicates that an extended return- 695 routability test using hashcash [I-D.jennings-sip-hashcash] is used 696 with the call being redirected to Bob's voicebox afterwards. This 697 exchange is shown in Figure 9. 699 UA Bob's 700 Malice Proxy Voicebox 701 | INVITE | | 702 |------------------------->|Puzzle: work=15; | 703 | |pre="VgVGYixbRg0mdSwTY3YIfCBuAAA="; | 704 | 419 with Puzzle |image="NhhMQ2l7SE0VBmZFKksUC19ia04="; | 705 | |value=160 | 706 |<-------------------------| | 707 | | | 708 | ACK | | 709 |------------------------->| | 710 | |Puzzle: work=0; | 711 | |pre="VgVGYixbRg0mdSwTY3YIfCBuYmg="; | 712 | |image="NhhMQ2l7SE0VBmZFKksUC19ia04=" | 713 | INVITE with Solution |value=160 | 714 |------------------------->| INVITE | 715 | |------------------------------------->| 716 | | | 717 | | 180 Ringing | 718 | 180 Ringing |<-------------------------------------| 719 |<-------------------------| | 720 | | 200 OK | 721 | 200 OK |<-------------------------------------| 722 |<-------------------------| | 723 | | ACK | 724 |---------------------------------------------------------------->| 725 | | | 727 Figure 9: Example Exchange: Malice contacts Bob 729 Depending on the outcome of the exchange the call is forwarded to a 730 mailbox sip:voicebox@company-example.com (in case Malory returned the 731 correct solution, see Rule 4) or blocked in case an incorrect 732 response was provided. It might be quite easy to see how this rule 733 set can be extended to support other SPIT handling mechanisms as well 734 (e.g., CAPTCHAs, SIP Pay, etc.). 736 8. Security Considerations 738 This document aims to describe a framework for addressing Spam for 739 Internet Telephony (SPIT) in order to make it simple for users to 740 influence the behavior of SIP message routing with an emphasis on 741 SPIT prevention. 743 The framework relies on three building blocks, namely SIP Identity, 744 authorization policies based on Common Policy and Presence 745 Authorization Policy, and XCAP. 747 As a high-level overview, the framework allows the user to control 748 end-to-end connectivity at the SIP message routing level whereby the 749 glue that lets all parts fit together is based on authorization 750 policies. Several other solution components can be developed 751 independently and can be plugged into the framework as soon as 752 available. 754 It must be avoided to introduce Denial of Service attacks against the 755 recipient by misguiding him or her to install authorization policies 756 that allow senders to bypass the policies although that was never 757 intended by the recipient. Additionally, it must not be possible by 758 extensions to the authorization policy framework to create policies 759 to block legitimate senders or to stall the processing of the 760 authorization policy engine. 762 9. Acknowledgments 764 We would like to thank 766 Jeremy Barkan, Dan York, Alexey Melnikov, Thomas Schreck, Eva 767 Leppanen, Cullen Jennings, Marit Hansen and Markus Hansen for 768 their review comments to a pre-00 version. 769 Jeremy Barkan, Eva Leppanen, Michaela Greiler, Joachim Charzinski, 770 Saverio Niccolini, Albert Caruana, and Juergen Quittek for their 771 comments to the 00 version. 772 Otmar Lendl, Jan Seedorf, Saverio Niccolini, Kai Fischer, Joachim 773 Charzinski, Dan York, Peter Saint-Andre, Brian Azzopardi, Martin 774 Stiemerling, and Juergen Quittek for their comments to the -01/-02 775 version. 777 10. References 779 10.1. Normative References 781 10.2. Informative References 783 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 784 Initiation Protocol (SIP)", RFC 3323, November 2002. 786 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 787 Authenticated Identity Management in the Session 788 Initiation Protocol (SIP)", RFC 4474, August 2006. 790 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 791 Polk, J., and J. Rosenberg, "Common Policy: A Document 792 Format for Expressing Privacy Preferences", RFC 4745, 793 February 2007. 795 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 796 Extensions to the Session Initiation Protocol (SIP) for 797 Asserted Identity within Trusted Networks", RFC 3325, 798 November 2002. 800 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 801 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 803 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 804 Protocol (SIP) and Spam", RFC 5039, January 2008. 806 [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, 807 December 2007. 809 [I-D.jennings-sip-hashcash] 810 Jennings, C., "Computational Puzzles for SPAM Reduction in 811 SIP", draft-jennings-sip-hashcash-06 (work in progress), 812 July 2007. 814 [I-D.wing-sipping-spam-score] 815 Wing, D., Niccolini, S., Stiemerling, M., and H. 816 Tschofenig, "Spam Score for SIP", 817 draft-wing-sipping-spam-score-02 (work in progress), 818 February 2008. 820 [I-D.ietf-sipping-consent-framework] 821 Rosenberg, J., "A Framework for Consent-Based 822 Communications in the Session Initiation Protocol (SIP)", 823 draft-ietf-sipping-consent-framework-05 (work in 824 progress), June 2006. 826 [I-D.ietf-dkim-overview] 827 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 828 Identified Mail (DKIM) Service Overview", 829 draft-ietf-dkim-overview-10 (work in progress), July 2008. 831 [I-D.tschofenig-sipping-spit-policy] 832 Tschofenig, H., Wing, D., Schulzrinne, H., Froment, T., 833 and G. Dawirs, "A Document Format for Expressing 834 Authorization Policies to tackle Spam and Unwanted 835 Communication for Internet Telephony", 836 draft-tschofenig-sipping-spit-policy-03 (work in 837 progress), July 2008. 839 [I-D.schwartz-sipping-spit-saml] 840 Schwartz, D., "SPAM for Internet Telephony (SPIT) 841 Prevention using the Security Assertion Markup Language 842 (SAML)", draft-schwartz-sipping-spit-saml-01 (work in 843 progress), June 2006. 845 [I-D.shacham-http-corr-uris] 846 Shacham, R. and H. Schulzrinne, "HTTP Header for Future 847 Correspondence Addresses", draft-shacham-http-corr-uris-00 848 (work in progress), May 2007. 850 [I-D.jennings-sipping-pay] 851 Jennings, C., "Payment for Services in Session Initiation 852 Protocol (SIP)", draft-jennings-sipping-pay-06 (work in 853 progress), July 2007. 855 [I-D.froment-sipping-spit-requirements] 856 Tschofenig, H., Dawirs, G., Froment, T., Wing, D., and H. 857 Schulzrinne, "Requirements for Authorization Policies to 858 tackle Spam and Unwanted Communication for Internet 859 Telephony", draft-froment-sipping-spit-requirements-03 860 (work in progress), July 2008. 862 [I-D.niccolini-sipping-feedback-spit] 863 Niccolini, S., "SIP Extensions for SPIT identification", 864 draft-niccolini-sipping-feedback-spit-03 (work in 865 progress), February 2007. 867 [I-D.tschofenig-sipping-captcha] 868 Tschofenig, H., Leppanen, E., Niccolini, S., and M. 869 Arumaithurai, "Completely Automated Public Turing Test to 870 Tell Computers and Humans Apart (CAPTCHA) based Robot 871 Challenges for SIP", draft-tschofenig-sipping-captcha-01 872 (work in progress), February 2008. 874 [I-D.ietf-sip-ua-privacy] 875 Munakata, M., Schubert, S., and T. Ohba, "UA-Driven 876 Privacy Mechanism for SIP", draft-ietf-sip-ua-privacy-01 877 (work in progress), February 2008. 879 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 880 Package for the Session Initiation Protocol (SIP)", 881 RFC 3857, August 2004. 883 [I-D.ietf-sip-saml] 884 Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. 885 Sicker, "SIP SAML Profile and Binding", 886 draft-ietf-sip-saml-03 (work in progress), November 2007. 888 [Spit-AL] Hansen, M., Hansen, M., Moeller, J., Rohwer, T., Tolkmitt, 889 C., and H. Waack, "Developing a Legally Compliant 890 Reachability Management System as a Countermeasure against 891 SPIT, Third Annual VoIP Security Workshop, Berlin, 892 available at 893 https://tepin.aiki.de/blog/uploads/spit-al.pdf", 894 June 2006. 896 [Law1] "Bundesnetzagentur: Eckpunkte der regulatorischen 897 Behandlung von Voice over IP (VoIP), available at 898 http://www.bundesnetzagentur.de/media/archive/3186.pdf", 899 September 2005. 901 [Law2] "70. Konferenz der Datenschutzbeauftragten des Bundes und 902 der Laender: Entschliessung Telefonieren mit 903 Internettechnologie (Voice over IP - VoIP), available at 904 http://www.datenschutzzentrum.de/material/themen/press 905 e/20051028-dsbk-voip.htm", Oktober 2005. 907 [Law3] "Working Party 29 Opinion 2/2006 on privacy issues related 908 to the provision of email screening services, WP 118, 909 available at http://ec.europa.eu/justice_home/fsj/privacy/ 910 docs/wpdocs/2006/wp118_en.pdf", February 2006. 912 [XEP-0161] 913 Saint-Andre, P., "Abuse Reporting", XSF XEP 0161, 914 May 2007. 916 Appendix A. Authorization Engine in SIP UA 918 When white lists are stored and managed only at the SIP UA client 919 then the authorization policies language and the protocol to modify 920 the policies do not need to be standardized; they are purely 921 implementation specific details. 923 While this appears to be an advantage there are various drawbacks 924 including the inability to synchronize policies among different 925 devices. Additionally, some information that is typically available 926 to the Policy Decision Point may not be available to the end host. 927 To avoid standardizing the exchange of such type of information an 928 abstract form of Spam marking is proposed in 929 [I-D.wing-sipping-spam-score]. 931 Authors' Addresses 933 Hannes Tschofenig 934 Nokia Siemens Networks 935 Linnoitustie 6 936 Espoo 02600 937 Finland 939 Phone: +358 (50) 4871445 940 Email: Hannes.Tschofenig@gmx.net 941 URI: http://www.tschofenig.priv.at 943 Henning Schulzrinne 944 Columbia University 945 Department of Computer Science 946 450 Computer Science Building 947 New York, NY 10027 948 US 950 Phone: +1 212 939 7004 951 Email: hgs@cs.columbia.edu 952 URI: http://www.cs.columbia.edu 954 Dan Wing 955 Cisco Systems, Inc. 956 170 West Tasman Drive 957 San Jose, CA 95134 958 USA 960 Email: dwing@cisco.com 962 Jonathan Rosenberg 963 Cisco Systems, Inc. 964 600 Lanidex Plaza 965 Parsippany, New York 07054 966 USA 968 Email: jdrosen@cisco.com 969 URI: http://www.jdrosen.net 970 David Schwartz 971 XConnect 972 Malcha Technology Park 973 Jerusalem, 96951 974 Israel 976 Email: dschwartz@xconnect.net 978 Full Copyright Statement 980 Copyright (C) The IETF Trust (2008). 982 This document is subject to the rights, licenses and restrictions 983 contained in BCP 78, and except as set forth therein, the authors 984 retain all their rights. 986 This document and the information contained herein are provided on an 987 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 988 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 989 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 990 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 991 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 992 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 994 Intellectual Property 996 The IETF takes no position regarding the validity or scope of any 997 Intellectual Property Rights or other rights that might be claimed to 998 pertain to the implementation or use of the technology described in 999 this document or the extent to which any license under such rights 1000 might or might not be available; nor does it represent that it has 1001 made any independent effort to identify any such rights. Information 1002 on the procedures with respect to rights in RFC documents can be 1003 found in BCP 78 and BCP 79. 1005 Copies of IPR disclosures made to the IETF Secretariat and any 1006 assurances of licenses to be made available, or the result of an 1007 attempt made to obtain a general license or permission for the use of 1008 such proprietary rights by implementers or users of this 1009 specification can be obtained from the IETF on-line IPR repository at 1010 http://www.ietf.org/ipr. 1012 The IETF invites any interested party to bring to its attention any 1013 copyrights, patents or patent applications, or other proprietary 1014 rights that may cover technology that may be required to implement 1015 this standard. Please address the information to the IETF at 1016 ietf-ipr@ietf.org.