idnits 2.17.1 draft-tschofenig-sipping-spit-policy-03.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1113. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1124. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1131. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1137. 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 (July 12, 2008) is 5767 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-04) exists of draft-tschofenig-sipping-framework-spit-reduction-03 -- Obsolete informational reference (is this intentional?): RFC 2445 (Obsoleted by RFC 5545) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 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: Standards Track D. Wing 5 Expires: January 13, 2009 Cisco 6 H. Schulzrinne 7 Columbia University 8 T. Froment 9 Alcatel-Lucent 10 G. Dawirs 11 University of Namur 12 July 12, 2008 14 A Document Format for Expressing Authorization Policies to tackle Spam 15 and Unwanted Communication for Internet Telephony 16 draft-tschofenig-sipping-spit-policy-03.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 13, 2009. 43 Abstract 45 SPAM, defined as sending unsolicited messages to someone in bulk, 46 might be a problem on SIP open-wide deployed networks. The 47 responsibility for filtering or blocking calls can belong to 48 different elements in the call flow and may depend on various 49 factors. This document defines an authorization based policy 50 language that allows end users to upload anti-SPIT policies to 51 intermediaries, such as SIP proxies. These policies mitigate 52 unwanted SIP communications. It extends the Common Policy 53 authorization framework with additional conditions and actions. The 54 new conditions match a particular Session Initiation Protocol (SIP) 55 communication pattern based on a number of attributes. The range of 56 attributes includes information provided, for example, by SIP itself, 57 by the SIP identity mechanism, by information carried within SAML 58 assertions. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Structure of SPIT Authorization Documents . . . . . . . . 5 66 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Condition Elements . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1.1. Acceptable Forms of Authentication . . . . . . . . . . 6 70 4.1.2. Computing a URI for the Sender . . . . . . . . . . . . 7 71 4.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. SPIT Handling . . . . . . . . . . . . . . . . . . . . . . 9 73 4.4. Presence Status . . . . . . . . . . . . . . . . . . . . . 9 74 4.5. Time Period Condition . . . . . . . . . . . . . . . . . . 9 75 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.1. Execute Action . . . . . . . . . . . . . . . . . . . . . . 11 77 5.2. Forward To . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.1. Identity and Time-Based Policy . . . . . . . . . . . . . . 12 80 6.2. Extended Time-Based Policy . . . . . . . . . . . . . . . . 13 81 6.3. Policy for triggering Captcha and Hashcash Challenges . . 14 82 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 8. XCAP USAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 19 85 8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 19 86 8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 20 87 8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 20 88 8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 20 89 8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 20 90 8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 20 91 8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 20 92 8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 20 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 94 9.1. Anti-SPIT Policy XML Schema Registration . . . . . . . . . 21 95 9.2. Anti-SPIT Policy Namespace Registration . . . . . . . . . 21 96 9.3. XCAP Application Usage ID . . . . . . . . . . . . . . . . 21 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 98 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 102 13.2. Informative References . . . . . . . . . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 104 Intellectual Property and Copyright Statements . . . . . . . . . . 27 106 1. Introduction 108 The problem of SPAM for Internet Telephony (SPIT) is an imminent 109 challenge and only the combination of several techniques can provide 110 a framework for dealing with unwanted communication, as stated in 111 [I-D.jennings-sip-hashcash]. 113 One important building block is to have a mechanism that can instruct 114 SIP intermediaries to react differently on incoming requests based on 115 policies. Different entities, such as end users, parents on behalf 116 of their children, system administrators in enterprise networks, 117 etc., might create and modify authorization policies. The conditions 118 in these policies can be created from many sources but some 119 information elements are more important than others. For example, 120 there is reason to believe that applying authorization policies based 121 on the authenticated identity is an effective way to accept a 122 communication attempt to deal with unsolicited communication. 123 Authentication based on the SIP identity mechanism, see [RFC4474], is 124 one important concept. 126 The requirements for the authorization policies described in this 127 document are outlined in [I-D.froment-sipping-spit-requirements]. A 128 framework document is available at 129 [I-D.tschofenig-sipping-framework-spit-reduction]. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 This document reuses the terminology from RFC 4745 [RFC4745]: 139 Rule maker: 141 The RM is an entity that creates the authorization policies that 142 react to unwanted connection attempts. The rule maker might be an 143 end user that owns the device, a VoIP service provider, a person 144 with a relationship to the end user (e.g., the parents of a child 145 using a mobile phone). A standardized policy language is needed 146 when the creation, modification and deletion of authorization 147 policies are not only a local matter. 149 Authorization policy: 151 An authorization policy is given by a rule set. A rule set 152 contains an unordered list of rules. Each rule has a condition, 153 an action and a transformation component. The terms 154 'authorization policy', 'policy', 'rule set', 'authorization 155 policy rule', 'policy rule' and 'rule' are used interchangeably. 156 Authorization policies can be applied at the end host and/or by 157 intermediaries. 159 Permission: 161 The term permission refers to the action and transformation 162 components of a rule. 164 We use the term 'Recipient' for the entity that is target of the 165 communication attempt of a sender. 167 3. Generic Processing 169 3.1. Structure of SPIT Authorization Documents 171 A SPIT authorization document is an XML document, formatted according 172 to the schema defined in RFC 4745 [RFC4745]. SPIT authorization 173 documents inherit the MIME type of common policy documents, 174 application/auth-policy+xml. As described in [RFC4745], this 175 document is composed of rules which contain three parts - conditions, 176 actions, and transformations. Each action or transformation, which 177 is also called a permission, has the property of being a positive 178 grant to the authorization server to perform the resulting actions, 179 be it allow, block etc . As a result, there is a well-defined 180 mechanism for combining actions and transformations obtained from 181 several sources. This mechanism therefore can be used to filter 182 connection attempts thus leading to effective SPIT prevention. 184 3.2. Rule Transport 186 Policies are XML documents that are stored at a Proxy Server or a 187 dedicated device. The Rule Maker therefore needs to use a protocol 188 to create, modify and delete the authorization policies defined in 189 this document. Such a protocol is available with the Extensible 190 Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825]. 192 4. Condition Elements 194 This section describes the additional enhancements of the conditions- 195 part of the rule. This document inherits the Common Policy 196 functionality, including , , and 197 conditions. 199 Note that, as discussed in [RFC4745], a permission document applies 200 to a translation if all the expressions in its conditions part 201 evaluate to TRUE. 203 4.1. Identity 205 Although the element is defined in [RFC4745], that 206 specification indicates that the specific usages of the framework 207 document need to define details that are protocol and usage specific. 208 In particular, it is necessary for a usage of the common policy 209 framework to: 211 o Define acceptable means of authentication. 212 o Define the procedure for representing the identity as a URI or IRI 213 [RFC3987]. 215 This sub-section defines those details for systems based on 216 [RFC3856]. 218 4.1.1. Acceptable Forms of Authentication 220 When used with SIP, a request is considered authenticated if one of 221 the following techniques is used: 223 SIP Digest: 225 The proxy has authenticated the sender using SIP [RFC3261] digest 226 authentication [RFC2617]. However, if the anonymous 227 authentication described on page 194 of RFC 3261 [RFC3261] was 228 used, the sender is not considered authenticated. 230 Asserted Identity: 232 If a request contains a P-Asserted-ID header field [RFC3325] and 233 the request is coming from a trusted element, the sender is 234 considered authenticated. 236 Cryptographically Verified Identity: 238 If a request contains an Identity header field as defined in 239 [RFC4474], and it validates the From header field of the request, 240 the request is considered to be authenticated. Note that this is 241 true even if the request contained a From header field of the form 242 sip:anonymous@example.com. As long as the signature verifies that 243 the request legitimately came from this identity, it is considered 244 authenticated. 246 An anonymous From header field with RFC 4474 [RFC4474] is considered 247 authenticated, while anonymous digest is not considered 248 authenticated, because the former still involves the usage of an 249 actual username and credential as part of an authentication operation 250 in the originating domain. 252 4.1.2. Computing a URI for the Sender 254 For messages that are authenticated using SIP Digest, the identity of 255 the sender is set equal to the address of record (AoR) for the user 256 that has authenticated themselves. The AoR is always a URI, and can 257 be either a SIP URI or tel URI [RFC3966]. For example, consider the 258 following "user record" in a database: 260 SIP AOR: sip:alice@example.com 261 digest username: ali 262 digest password: f779ajvvh8a6s6 263 digest realm: example.com 265 If the proxy server receives an INVITE, challenges it with the realm 266 set to "example.com", and the subsequent INVITE contains an 267 Authorization header field with a username of "ali" and a digest 268 response generated with the password "f779ajvvh8a6s6", the identity 269 used in matching operations is "sip:alice@example.com". 271 For messages that are authenticated using RFC 3325 [RFC3325], the 272 identity of the sender is equal to the URI in the P-Asserted-ID 273 header field. If there are multiple values for the P-Asserted-ID 274 header field (there can be one sip URI and one tel URI [RFC3966]), 275 then each of them is used for the comparisons outlined in [RFC4745], 276 and if either of them match a or element, it is 277 considered a match. 279 For messages that are authenticated using the SIP Identity mechanism 280 [RFC4474], identity of the sender is equal to the SIP URI in the From 281 header field of the request, assuming that the signature in the 282 Identity header field has been validated. 284 In SIP systems, it is possible for a user to have aliases - that is, 285 there are multiple SIP AoRs "assigned" to a single user. In terms of 286 this specification, there is no relationship between those aliases. 287 Each would look like a different user. This will be the consequence 288 for systems where the sender is in a different domain than the 289 recipient. However, even if the sender and recipient are in the same 290 domain, and the proxy server knows that there are aliases for the 291 sender, these aliases are not mapped to each other or used in any 292 way. 294 SIP also allows for anonymous identities. If a message is anonymous 295 because the digest challenge/response used the "anonymous" username, 296 the message is considered unauthenticated and will match only an 297 empty element. If a message is anonymous because it 298 contains a Privacy header field [RFC3323], but still contains a 299 P-Asserted-ID header field, the identity in the P-Asserted-ID header 300 field is still used in the authorization computations; the fact that 301 the message was anonymous has no impact on the identity processing. 302 However, if the message had traversed a trust boundary and the 303 P-Asserted-ID header field and the Privacy header field had been 304 removed, the message will be considered unauthenticated when it 305 arrives at the proxy server. Finally, if a message contained an 306 Identity header field that was validated, and the From header field 307 contained a URI of the form sip:anonymous@example.com, then the 308 sender is considered authenticated, and it will have an identity 309 equal to sip:anonymous@example.com. Had such an identity been placed 310 into a or element, there will be a match. 312 It is important to note that SIP frequently uses both SIP URI and tel 313 URI [RFC3966] as identifiers, and to make matters more confusing, a 314 SIP URI can contain a phone number in its user part, in the same 315 format used in a tel URI. The sender's identity that is a SIP URI 316 with a phone number will not match the and conditions 317 whose 'id' is a tel URI with the same number. The same is true in 318 the reverse. If the sender's identity is a tel URI, this will not 319 match a SIP URI in the or conditions whose user part 320 is a phone number. URIs of different schemes are never equivalent. 322 4.2. Sphere 324 The element is defined in [RFC4745]. However, each 325 application making use of the common policy specification needs to 326 determine how the policy server computes the value of the sphere to 327 be used in the evaluation of the condition. 329 To compute the value of , the proxy server interacts with a 330 presence server who knows whether at least one of the published 331 presence documents includes the element [RFC4480] as part of 332 the person data component [RFC4479], and all of those containing the 333 element have the same value for it, that is the value used for the 334 sphere in policy policy processing. If, however, the 335 element was not available to the presence server (and hence not for 336 the proxy server), or it was present but had inconsistent values, its 337 value is considered undefined in terms of policy processing. 339 4.3. SPIT Handling 341 The element is a way to react on the execution of 342 certain SPIT handling mechanisms. For example, a rule might indicate 343 that a CAPTCHA has to be sent to the sender and the sender 344 subsequently has to return the result. Depending on the outcome of 345 the robot test the rules might enforce different actions. This 346 element provides such a condition capability. 348 The condition evaluates to TRUE if any of its child 349 elements evaluate to TRUE, i.e., the results of the individual child 350 element are combined using a logical OR. 352 The element MAY contain zero or more 353 elements. The elements has an attribute 'result' that 354 either contains "SUCCESS" or "FAILURE". 356 4.4. Presence Status 358 This condition evaluates to TRUE when the called user's current 359 presence activity status is equal to the value in the element. Otherwise the condition evaluates to FALSE. 362 4.5. Time Period Condition 364 The element allows to make decisions based on the time, 365 date and timezone. It defines an extended version of the 366 element. 368 The element may contain the following attributes: 370 dtstart: 372 Start of interval (RFC 2445 [RFC2445] DATE-TIME). This attribute 373 is MANDATORY. 375 dtend: 377 End of interval (RFC 2445 [RFC2445] DATE-TIME). This attribute is 378 MANDATORY. 380 timestart: 382 Start of time interval in a particular day. It is of the TIME 383 data type as mentioned in Section 4.3.12 of RFC 2445 [RFC2445]. 384 This attribute is OPTIONAL. The default value is 000000. 386 timeend: 388 End of time interval in a particular day. It is of the TIME data 389 type as mentioned in Section 4.3.12 of RFC 2445 [RFC2445]. This 390 attribute is OPTIONAL. The default value is 235959. 392 byweekday: List of days of the week. This attribute is OPTIONAL. 394 The is based on the description in CPL [RFC3880] but 395 with a reduced feature set. 397 The "dtstart" and "dtend" attributes are formatted as iCalendar COS 398 DATE-TIME values, as specified in Section 4.3.5 of RFC 2445 399 [RFC2445]. Only floating or UTC times can be used with time zones. 400 The DATE-TIME is a subset of the corresponding syntaxes from ISO 8601 401 [ISO8601]. 403 The "timestart" specifes a time value to indicate the beginning of 404 every day. The default value is 000000 representing the beginning of 405 the day. 407 The "timeend" specifes a time value to indicate the end of every day. 408 The default value is 235959 representing the end of the day. 410 The "byweekday" attribute specifies a comma-separated list of days of 411 the week. "MO" indicates Monday, "TU" indicates Tuesday, "WE" 412 indicates Wednesday, "TH" indicates Thursday, "FR" indicates Friday, 413 "SA" indicates Saturday, and "SU" indicates Sunday. These values are 414 not case-sensitive. 416 Here is an example of the time-period element. 418