idnits 2.17.00 (12 Aug 2021) /tmp/idnits26192/draft-froment-sipping-spit-authz-policies-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 501. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 26, 2007) is 5562 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.jennings-sip-hashcash' is mentioned on line 374, but not defined == Missing Reference: 'I-D.ietf-sip-identity' is mentioned on line 363, but not defined == Missing Reference: 'I-D.ietf-simple-presence-rules' is mentioned on line 352, but not defined == Missing Reference: 'I-D.ietf-simple-xcap' is mentioned on line 357, but not defined == Missing Reference: 'I-D.ietf-webdav-rfc2518bis' is mentioned on line 369, but not defined ** Obsolete undefined reference: RFC 2518 (Obsoleted by RFC 4918) == Missing Reference: 'I-D.schwartz-sipping-spit-saml' is mentioned on line 385, but not defined == Missing Reference: 'I-D.rosenberg-sipping-consent-framework' is mentioned on line 379, but not defined == Missing Reference: 'I-D.ietf-geopriv-common-policy' is mentioned on line 346, but not defined Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING G. Dawirs 3 Internet-Draft University of Namur 4 Intended status: Informational T. Froment 5 Expires: August 30, 2007 Alcatel 6 H. Tschofenig 7 Siemens 8 February 26, 2007 10 Authorization Policies for Preventing SPIT 11 draft-froment-sipping-spit-authz-policies-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 30, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 SPAM, defined as sending unsolicited messages to someone in bulk, 45 might be a problem on SIP open-wide deployed networks. The 46 responsibility for filtering or blocking calls can belong to 47 different elements in the call flow and may depend on various 48 factors. This document discusses mechanisms to establish policies to 49 react on potentially unwanted communication attempts. 51 These policies match a particular Session Initiation Protocol (SIP) 52 communication pattern based on a number of attributes. The range of 53 attributes includes information provided, for example, by the SIP 54 itself, by the SIP identity mechanism, by information carried within 55 SAML assertions (as introduced with SIP-SAML) and by the SPIT-SAML 56 extensions. 58 This document raises the question whether it is worth to investigate 59 the aspect of authorization policy usage for SPIT prevention. If so, 60 then the choice of a policy language for describing authorization 61 policies and the details of the authorization policies becomes 62 important. Mechanisms to create, modify and delete authorization 63 policies that are stored in XML documents are already available with 64 XCAP or WEBDAV and they could be reused. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5. Discussion and Open Issues . . . . . . . . . . . . . . . . . . 10 73 5.1. Extending Geopriv Authorization Policies . . . . . . . . . 10 74 5.2. Hierarchical Authorization Policy Documents . . . . . . . 10 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 9.2. References . . . . . . . . . . . . . . . . . . . . . . . . 14 81 Appendix A. Sophisticated SPIT Filtering Scenario . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 83 Intellectual Property and Copyright Statements . . . . . . . . . . 18 85 1. Introduction 87 The problem of SPAM for VoIP seems to become a very big challenge and 88 only "the combination of several techniques can provide a framework 89 for dealing with spam in SIP" (as stated in 90 [I-D.jennings-sip-hashcash]). 92 One important building block is to provide a mechanism to instruct 93 some entities in the network to "filter" incoming requests according 94 to user or to network-wide policies. Different entities, such as 95 users or system administrators, might create and modify authorization 96 policies and might even share these policies between domains. 98 Some attributes in a SIP communication play a more important role 99 than others. For example, applying authorization policies based on 100 the authenticated identity is probably an effective way to accept a 101 communication attempt in order to compat SPIT. The same is true for 102 policies that are applied to deployment friendlier SIP security 103 solutions, such as the SIP identity mechanism 104 [I-D.ietf-sip-identity]. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 3. Framework 114 The framework of the discussed anti-SPIT authorization policies can 115 be shown as follows: 117 Policies Policies 118 || || 119 || || 120 || || 121 || || 122 VV VV 123 +-----------+ +-----------+ 124 |SIP | SIP |SIP | 125 +---------->|Proxy |<---------->|Proxy |<----------+ 126 | |Server X | |Server Y | | 127 | +-----------+ +-----------+ | 128 SIP| domain: example.com domain: otherdomain.com |SIP 129 | | 130 | | 131 | | 132 | | 133 v v 134 +-----------+ SIP +-----------+ 135 |SIP | <-----------------------------------------> |SIP | 136 |User Agent | RTP |User Agent | 137 |Alice | <=========================================> |Bob | 138 +-----------+ +-----------+ 139 ^^ ^^ 140 || || 141 || || 142 || || 143 || || 144 Policies Policies 146 Figure 1: Framework and Scenario 148 Authorization policies can be applied at the end host and/or by 149 intermediaries. The rule maker might be an end user that owns the 150 device, a VoIP service provider, a person with a relationship to the 151 end user (e.g., the parents of a child using a mobile phone). When 152 the creation, modification and deletion of authorization policies is 153 not only a local matter then a standardized policy language is 154 needed. 156 The subsequent text lists a few use cases. 158 The first use case that can be imagined is the case of a user that 159 asks its outbound proxy to offer protection of requests from a 160 particular SIP UA. He can create an authorization policy rule and 161 upload it to the SIP proxy within its own domain. Requests coming 162 from this SIP URI will then be blocked or treated differently. 164 Assuming "B@otherdomain.com" has added an authorization rule blocking 165 request coming from domain example.com. Here is a potential message 166 sequence: 168 A@example.com Proxy Proxy B@otherdomain.com 169 @example.com @otherdomain.com 170 | | | | 171 | | | Reject | 172 | | | @example.com | 173 | | |<---------------| 174 | | | OK | 175 | | |--------------->| 176 | | | | 177 | INVITE | | | 178 | B@otherdomain.com | | 179 |---------------->| | | 180 | | INVITE | | 181 | | B@otherdomain.com | 182 | |-------------->| | 183 | | 403 Forbidden | | 184 | |<--------------| | 185 | 403 Forbidden | | | 186 |<----------------| | | 188 Filtering at the Receiver's Network 190 If a solution has to be provided to enable SPIT filtering then the 191 following two sub-problems have to be solved: 193 o An authorization policy language that allows to expression the 194 conditions and actions. An example is 195 [I-D.ietf-simple-presence-rules]. 197 o A mechanism to create, delete, update, retrieve and upload XML 198 based authorization policy rules. XCAP [I-D.ietf-simple-xcap] is 199 a reasonable solution. Another one is WEBDAV 200 [I-D.ietf-webdav-rfc2518bis]. 202 4. Requirements 204 The design of anti-SPIT authorization policies is guided by the 205 following requirements. 207 1. The policies SHOULD allow filtering incoming requests depending 208 on several criteria's: 210 * Value of any SIP header attribute (e.g., From, To, Contact) 212 * Presence (or lack) of any SIP header attribute (e.g., From, 213 To, Contact) 215 * Method invoked by the caller (e.g., INVITE, MESSAGE) 217 * Value of parameters specified in 218 [I-D.schwartz-sipping-spit-saml] 220 + IdentityStrength 222 + CostOfCall 224 + AuthenticationMethod 226 + IdentityAssertion 228 + ConnectionSecurity 230 + SPITSuspected 232 + CallCenter 234 + AssertionStrength 236 * Request URI of a request 238 * Presence of a given expression in the body (subject for 239 further investigation) 241 2. The policies SHOULD support wildcards (e.g., entire domains) 243 3. The policies SHOULD support logical operations (and, or, not) 244 between individual elements in conditions 246 4. The policies SHOULD refer to all authenticated and 247 unauthenticated identities. 249 5. The policies SHOULD allow a number of actions to be specified, 250 such as: 252 * "block": stop forwarding the request and answer with a ``403 253 Forbidden'' 255 * "polite-block": drop the request without answering anything 257 * "mark": forward the request, putting a flag ``SPAM'' 259 * "allow": forward this message without conditions (this 260 mechanism is described further) 262 * and trigger other mechanism, such as: 264 + "puzzle": trigger the "Computational Puzzles" 265 [I-D.jennings-sip-hashcash] mechanism. 267 + "consent": trigger the "Consent Framework" 268 [I-D.rosenberg-sipping-consent-framework] mechanism 270 6. The policies SHOULD allow a default action to be specified. 272 7. It SHOULD be possible to allow a hierarchy of authorization 273 policies to be used. 275 5. Discussion and Open Issues 277 5.1. Extending Geopriv Authorization Policies 279 The work done in the Geopriv working group on authorization policies 280 seem to be a promising candate for these authorization policies. 282 To fulfill requirements (1) to (6), it is necessary to decide if 283 [I-D.ietf-geopriv-common-policy] and [I-D.ietf-simple-presence-rules] 284 can be extended. 286 The following open issues have been identified: 288 o The authorization policies defined by the Geopriv working group 289 focus on a whitelist approach. This document also raises the 290 question to what extend backlisting capability can be supported or 291 is necessary to support. 293 o The Geopriv Common Policy mechanism does not allow generic "deny" 294 actions to be defined. This aspect refers to requirements (4) 295 ("all") where (although "all except one" is supported by Common 296 Policy). 298 o Requirement 2 (wildcards) is provided by Common Policy in a 299 limited fashion by referring to the domain part of an identity. 300 Regular expressions are not supported to keep the policy language 301 simple. 303 5.2. Hierarchical Authorization Policy Documents 305 Requirement (7) might require a conflict resolution mechanism to be 306 specified. Geopriv Common Policy currently defines a very simple but 307 powerful conflict resolution mechanism but it is for further 308 investigation whether it is applicable to this problem domain. Other 309 policy languages define a more sophisticated set of conflict 310 resolution mechanisms with preceedence and weights for policies. 311 Although this might be an obviously solution for usage in the context 312 of hierarchical authorization policies it causes problems in other 313 places (such as preserving the order of rules). 315 6. IANA Considerations 317 This document does not require actions by IANA. 319 7. Security Considerations 321 The security concerns are related to the ability of certain entities 322 to create, update and delete authorization policies. If an 323 unauthorized entity is allowed to modify policies (and to distribute 324 them to other domains) then a denial of service attack is the 325 consequence with impact for more than a single end point. 327 Furthermore, SPIT prevention techniques often cross the border of 328 what is legally acceptable in certain countries (e.g., filtering SPIT 329 without the consent of the user). Hence, it is extremely important 330 to consider privacy laws in this work. 332 8. Acknowledgements 334 Acknowledgements to Yann Lopez for valuable input regarding the usage 335 of Common Policy in the problem domain of SPIT prevention. 337 9. References 339 9.1. Normative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", March 1997. 344 9.2. References 346 [I-D.ietf-geopriv-common-policy] 347 Schulzrinne, H., "Common Policy: A Document Format for 348 Expressing Privacy Preferences", 349 draft-ietf-geopriv-common-policy-11 (work in progress), 350 August 2006. 352 [I-D.ietf-simple-presence-rules] 353 Rosenberg, J., "Presence Authorization Rules", 354 draft-ietf-simple-presence-rules-08 (work in progress), 355 October 2006. 357 [I-D.ietf-simple-xcap] 358 Rosenberg, J., "The Extensible Markup Language (XML) 359 Configuration Access Protocol (XCAP)", 360 draft-ietf-simple-xcap-12 (work in progress), 361 October 2006. 363 [I-D.ietf-sip-identity] 364 Peterson, J. and C. Jennings, "Enhancements for 365 Authenticated Identity Management in the Session 366 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 367 (work in progress), October 2005. 369 [I-D.ietf-webdav-rfc2518bis] 370 Dusseault, L., "HTTP Extensions for Distributed Authoring 371 - WebDAV", draft-ietf-webdav-rfc2518bis-18 (work in 372 progress), February 2007. 374 [I-D.jennings-sip-hashcash] 375 Jennings, C., "Computational Puzzles for SPAM Reduction in 376 SIP", draft-jennings-sip-hashcash-04 (work in progress), 377 March 2006. 379 [I-D.rosenberg-sipping-consent-framework] 380 Rosenberg, J. and J. Rosenberg, "A Framework for Consent- 381 Based Communications in the Session Initiation Protocol 382 (SIP)", draft-rosenberg-sipping-consent-framework-00 (work 383 in progress), July 2004. 385 [I-D.schwartz-sipping-spit-saml] 386 Schwartz, D., "SPAM for Internet Telephony (SPIT) 387 Prevention using the Security Assertion Markup Language 388 (SAML)", draft-schwartz-sipping-spit-saml-01 (work in 389 progress), June 2006. 391 Appendix A. Sophisticated SPIT Filtering Scenario 393 In a more sophisticated scenario one might even consider the idea of 394 stopping SPIT as early as possible. Domains may agree to exchange 395 authorization policies in order to stop SPIT earlier (i.e., closer to 396 the source of the problem). The subsequent text describes this 397 scenario. 399 A@example.com Proxy Proxy B@otherdomain.com 400 @example.com @otherdomain.com 401 | | | | 402 | INVITE | | | 403 | B@otherdomain.com | | 404 |---------------->| | | 405 | 403 Forbidden | | | 406 |<----------------| | | 408 Filtering at the Sender's Network 410 This call flow illustrates the bandwidth-saving interest of this use 411 case. 413 Though, two scenarios could happen: 415 o In the good case, the sender's domain is honest and exchanges 416 authorization policies in order to apply rules that avoids 417 forwarding unsollicited requests. 419 o In the worst case, the sender's domain is not cooperative. It 420 will refuse to upload such documents. In this case, the presence 421 of rules in the recipient's domain will suffice to keep the 422 recipient "SPAM free", even if more traffic has been consumed 423 (since the request has been relayed at least until the first proxy 424 of the recipient's domain, exactly like in the first use case). 426 It might be desirable to use a hierarchy of authorization policy 427 documents that need to be combined when applying them to the SIP 428 signaling traffic. This raises the question of a merging algorithm, 429 particularly when authorization policy rules are conflicting or 430 contain blacklists. 432 This scenario is subject for further discussion since it might raise 433 privacy concerns when privacy policies are shared and potentially 434 applied to other communication partners traffic. 436 Authors' Addresses 438 Geoffrey Dawirs 439 University of Namur 440 21, rue Grandgagnage 441 Namur B-5000 442 Belgique 444 Email: gdawirs@gdawirs.be 446 Thomas Froment 447 Alcatel 448 1, rue Ampere - BP 80056 449 Massy, Paris 91302 450 France 452 Email: Thomas.Froment@alcatel-lucent.fr 454 Hannes Tschofenig 455 Siemens 456 Otto-Hahn-Ring 6 457 Munich, Bavaria 81739 458 Germany 460 Email: Hannes.Tschofenig@siemens.com 461 URI: http://www.tschofenig.com 463 Full Copyright Statement 465 Copyright (C) The IETF Trust (2007). 467 This document is subject to the rights, licenses and restrictions 468 contained in BCP 78, and except as set forth therein, the authors 469 retain all their rights. 471 This document and the information contained herein are provided on an 472 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 473 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 474 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 475 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 476 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 477 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 479 Intellectual Property 481 The IETF takes no position regarding the validity or scope of any 482 Intellectual Property Rights or other rights that might be claimed to 483 pertain to the implementation or use of the technology described in 484 this document or the extent to which any license under such rights 485 might or might not be available; nor does it represent that it has 486 made any independent effort to identify any such rights. Information 487 on the procedures with respect to rights in RFC documents can be 488 found in BCP 78 and BCP 79. 490 Copies of IPR disclosures made to the IETF Secretariat and any 491 assurances of licenses to be made available, or the result of an 492 attempt made to obtain a general license or permission for the use of 493 such proprietary rights by implementers or users of this 494 specification can be obtained from the IETF on-line IPR repository at 495 http://www.ietf.org/ipr. 497 The IETF invites any interested party to bring to its attention any 498 copyrights, patents or patent applications, or other proprietary 499 rights that may cover technology that may be required to implement 500 this standard. Please address the information to the IETF at 501 ietf-ipr@ietf.org. 503 Acknowledgment 505 Funding for the RFC Editor function is provided by the IETF 506 Administrative Support Activity (IASA).