idnits 2.17.00 (12 Aug 2021) /tmp/idnits51263/draft-tschofenig-sipping-spit-policy-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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1203. 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 (November 19, 2007) is 5297 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) == Unused Reference: 'RFC3428' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'RFC3840' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'RFC4412' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ecrit-service-urn' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mmusic-file-transfer-mech' is defined on line 1024, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-simple-message-sessions' is defined on line 1031, but no explicit reference was found in the text == Unused Reference: 'I-D.mahy-iptel-cpc' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'I-D.rosenberg-sipping-service-identification' is defined on line 1062, but no explicit reference was found in the text == Unused Reference: 'I-D.schubert-sipping-saml-cpc' is defined on line 1068, but no explicit reference was found in the text == Unused Reference: 'I-D.schwartz-sipping-spit-saml' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'OTZ' is defined on line 1103, but no explicit reference was found in the text == Unused Reference: 'RFC3266' is defined on line 1114, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-03) exists of draft-froment-sipping-spit-requirements-01 == Outdated reference: draft-ietf-ecrit-service-urn has been published as RFC 5031 == Outdated reference: draft-ietf-mmusic-file-transfer-mech has been published as RFC 5547 == Outdated reference: draft-ietf-simple-message-sessions has been published as RFC 4975 == Outdated reference: draft-ietf-simple-presence-rules has been published as RFC 5025 == Outdated reference: draft-ietf-sip-consent-framework has been published as RFC 5360 == Outdated reference: draft-ietf-sipping-spam has been published as RFC 5039 == Outdated reference: A later version (-01) exists of draft-tschofenig-sipping-captcha-00 == Outdated reference: A later version (-04) exists of draft-tschofenig-sipping-framework-spit-reduction-01 -- Obsolete informational reference (is this intentional?): RFC 2445 (Obsoleted by RFC 5545) -- Obsolete informational reference (is this intentional?): RFC 3028 (Obsoleted by RFC 5228, RFC 5429) -- Obsolete informational reference (is this intentional?): RFC 3266 (Obsoleted by RFC 4566) Summary: 4 errors (**), 0 flaws (~~), 22 warnings (==), 10 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: May 22, 2008 Cisco 6 H. Schulzrinne 7 Columbia University 8 T. Froment 9 Alcatel-Lucent 10 G. Dawirs 11 University of Namur 12 November 19, 2007 14 A Document Format for Expressing Authorization Policies to tackle Spam 15 and Unwanted Communication for Internet Telephony 16 draft-tschofenig-sipping-spit-policy-02.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 May 22, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 SPAM, defined as sending unsolicited messages to someone in bulk, 50 might be a problem on SIP open-wide deployed networks. The 51 responsibility for filtering or blocking calls can belong to 52 different elements in the call flow and may depend on various 53 factors. This document defines an authorization based policy 54 language that allows end users to upload anti-SPIT policies to 55 intermediaries, such as SIP proxies. These policies mitigate 56 unwanted SIP communications. It extends the Common Policy 57 authorization framework with additional conditions and actions. The 58 new conditions match a particular Session Initiation Protocol (SIP) 59 communication pattern based on a number of attributes. The range of 60 attributes includes information provided, for example, by SIP itself, 61 by the SIP identity mechanism, by information carried within SAML 62 assertions. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Structure of SPIT Authorization Documents . . . . . . . . 5 70 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Condition Elements . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1.1. Acceptable Forms of Authentication . . . . . . . . . . 6 74 4.1.2. Computing a URI for the Sender . . . . . . . . . . . . 7 75 4.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.3. SPIT Handling . . . . . . . . . . . . . . . . . . . . . . 9 77 4.4. Presence Status . . . . . . . . . . . . . . . . . . . . . 9 78 4.5. Time Period Condition . . . . . . . . . . . . . . . . . . 9 79 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.1. Execute Action . . . . . . . . . . . . . . . . . . . . . . 11 81 5.2. Forward To . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 6.1. Identity and Time-Based Policy . . . . . . . . . . . . . . 12 84 6.2. Extended Time-Based Policy . . . . . . . . . . . . . . . . 13 85 6.3. Policy for triggering Captcha and Hashcash Challenges . . 14 86 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 8. XCAP USAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 19 89 8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 19 90 8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 20 91 8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 20 92 8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 20 93 8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 20 94 8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 20 95 8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 20 96 8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 20 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 98 9.1. Anti-SPIT Policy XML Schema Registration . . . . . . . . . 21 99 9.2. Anti-SPIT Policy Namespace Registration . . . . . . . . . 21 100 9.3. XCAP Application Usage ID . . . . . . . . . . . . . . . . 21 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 102 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 104 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 105 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 106 13.2. Informative References . . . . . . . . . . . . . . . . . . 24 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 108 Intellectual Property and Copyright Statements . . . . . . . . . . 28 110 1. Introduction 112 The problem of SPAM for Internet Telephony (SPIT) is an imminent 113 challenge and only the combination of several techniques can provide 114 a framework for dealing with unwanted communication, as stated in 115 [I-D.jennings-sip-hashcash]. 117 One important building block is to have a mechanism that can instruct 118 SIP intermediaries to react differently on incoming requests based on 119 policies. Different entities, such as end users, parents on behalf 120 of their children, system administrators in enterprise networks, 121 etc., might create and modify authorization policies. The conditions 122 in these policies can be created from many sources but some 123 information elements are more important than others. For example, 124 there is reason to believe that applying authorization policies based 125 on the authenticated identity is an effective way to accept a 126 communication attempt to deal with unsolicited communication. 127 Authentication based on the SIP identity mechanism, see [RFC4474], is 128 one important concept. 130 The requirements for the authorization policies described in this 131 document are outlined in [I-D.froment-sipping-spit-requirements]. A 132 framework document is available at 133 [I-D.tschofenig-sipping-framework-spit-reduction]. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 This document reuses the terminology from RFC 4745 [RFC4745]: 143 Rule maker: 145 The RM is an entity that creates the authorization policies that 146 react to unwanted connection attempts. The rule maker might be an 147 end user that owns the device, a VoIP service provider, a person 148 with a relationship to the end user (e.g., the parents of a child 149 using a mobile phone). A standardized policy language is needed 150 when the creation, modification and deletion of authorization 151 policies are not only a local matter. 153 Authorization policy: 155 An authorization policy is given by a rule set. A rule set 156 contains an unordered list of rules. Each rule has a condition, 157 an action and a transformation component. The terms 158 'authorization policy', 'policy', 'rule set', 'authorization 159 policy rule', 'policy rule' and 'rule' are used interchangeably. 160 Authorization policies can be applied at the end host and/or by 161 intermediaries. 163 Permission: 165 The term permission refers to the action and transformation 166 components of a rule. 168 We use the term 'Recipient' for the entity that is target of the 169 communication attempt of a sender. 171 3. Generic Processing 173 3.1. Structure of SPIT Authorization Documents 175 A SPIT authorization document is an XML document, formatted according 176 to the schema defined in RFC 4745 [RFC4745]. SPIT authorization 177 documents inherit the MIME type of common policy documents, 178 application/auth-policy+xml. As described in [RFC4745], this 179 document is composed of rules which contain three parts - conditions, 180 actions, and transformations. Each action or transformation, which 181 is also called a permission, has the property of being a positive 182 grant to the authorization server to perform the resulting actions, 183 be it allow, block etc . As a result, there is a well-defined 184 mechanism for combining actions and transformations obtained from 185 several sources. This mechanism therefore can be used to filter 186 connection attempts thus leading to effective SPIT prevention. 188 3.2. Rule Transport 190 Policies are XML documents that are stored at a Proxy Server or a 191 dedicated device. The Rule Maker therefore needs to use a protocol 192 to create, modify and delete the authorization policies defined in 193 this document. Such a protocol is available with the Extensible 194 Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825]. 196 4. Condition Elements 198 This section describes the additional enhancements of the conditions- 199 part of the rule. This document inherits the Common Policy 200 functionality, including , , and 201 conditions. 203 Note that, as discussed in [RFC4745], a permission document applies 204 to a translation if all the expressions in its conditions part 205 evaluate to TRUE. 207 4.1. Identity 209 Although the element is defined in [RFC4745], that 210 specification indicates that the specific usages of the framework 211 document need to define details that are protocol and usage specific. 212 In particular, it is necessary for a usage of the common policy 213 framework to: 215 o Define acceptable means of authentication. 216 o Define the procedure for representing the identity as a URI or IRI 217 [RFC3987]. 219 This sub-section defines those details for systems based on 220 [RFC3856]. 222 4.1.1. Acceptable Forms of Authentication 224 When used with SIP, a request is considered authenticated if one of 225 the following techniques is used: 227 SIP Digest: 229 The proxy has authenticated the sender using SIP [RFC3261] digest 230 authentication [RFC2617]. However, if the anonymous 231 authentication described on page 194 of RFC 3261 [RFC3261] was 232 used, the sender is not considered authenticated. 234 Asserted Identity: 236 If a request contains a P-Asserted-ID header field [RFC3325] and 237 the request is coming from a trusted element, the sender is 238 considered authenticated. 240 Cryptographically Verified Identity: 242 If a request contains an Identity header field as defined in 243 [RFC4474], and it validates the From header field of the request, 244 the request is considered to be authenticated. Note that this is 245 true even if the request contained a From header field of the form 246 sip:anonymous@example.com. As long as the signature verifies that 247 the request legitimately came from this identity, it is considered 248 authenticated. 250 An anonymous From header field with RFC 4474 [RFC4474] is considered 251 authenticated, while anonymous digest is not considered 252 authenticated, because the former still involves the usage of an 253 actual username and credential as part of an authentication operation 254 in the originating domain. 256 4.1.2. Computing a URI for the Sender 258 For messages that are authenticated using SIP Digest, the identity of 259 the sender is set equal to the address of record (AoR) for the user 260 that has authenticated themselves. The AoR is always a URI, and can 261 be either a SIP URI or tel URI [RFC3966]. For example, consider the 262 following "user record" in a database: 264 SIP AOR: sip:alice@example.com 265 digest username: ali 266 digest password: f779ajvvh8a6s6 267 digest realm: example.com 269 If the proxy server receives an INVITE, challenges it with the realm 270 set to "example.com", and the subsequent INVITE contains an 271 Authorization header field with a username of "ali" and a digest 272 response generated with the password "f779ajvvh8a6s6", the identity 273 used in matching operations is "sip:alice@example.com". 275 For messages that are authenticated using RFC 3325 [RFC3325], the 276 identity of the sender is equal to the URI in the P-Asserted-ID 277 header field. If there are multiple values for the P-Asserted-ID 278 header field (there can be one sip URI and one tel URI [RFC3966]), 279 then each of them is used for the comparisons outlined in [RFC4745], 280 and if either of them match a or element, it is 281 considered a match. 283 For messages that are authenticated using the SIP Identity mechanism 284 [RFC4474], identity of the sender is equal to the SIP URI in the From 285 header field of the request, assuming that the signature in the 286 Identity header field has been validated. 288 In SIP systems, it is possible for a user to have aliases - that is, 289 there are multiple SIP AoRs "assigned" to a single user. In terms of 290 this specification, there is no relationship between those aliases. 291 Each would look like a different user. This will be the consequence 292 for systems where the sender is in a different domain than the 293 recipient. However, even if the sender and recipient are in the same 294 domain, and the proxy server knows that there are aliases for the 295 sender, these aliases are not mapped to each other or used in any 296 way. 298 SIP also allows for anonymous identities. If a message is anonymous 299 because the digest challenge/response used the "anonymous" username, 300 the message is considered unauthenticated and will match only an 301 empty element. If a message is anonymous because it 302 contains a Privacy header field [RFC3323], but still contains a 303 P-Asserted-ID header field, the identity in the P-Asserted-ID header 304 field is still used in the authorization computations; the fact that 305 the message was anonymous has no impact on the identity processing. 306 However, if the message had traversed a trust boundary and the 307 P-Asserted-ID header field and the Privacy header field had been 308 removed, the message will be considered unauthenticated when it 309 arrives at the proxy server. Finally, if a message contained an 310 Identity header field that was validated, and the From header field 311 contained a URI of the form sip:anonymous@example.com, then the 312 sender is considered authenticated, and it will have an identity 313 equal to sip:anonymous@example.com. Had such an identity been placed 314 into a or element, there will be a match. 316 It is important to note that SIP frequently uses both SIP URI and tel 317 URI [RFC3966] as identifiers, and to make matters more confusing, a 318 SIP URI can contain a phone number in its user part, in the same 319 format used in a tel URI. The sender's identity that is a SIP URI 320 with a phone number will not match the and conditions 321 whose 'id' is a tel URI with the same number. The same is true in 322 the reverse. If the sender's identity is a tel URI, this will not 323 match a SIP URI in the or conditions whose user part 324 is a phone number. URIs of different schemes are never equivalent. 326 4.2. Sphere 328 The element is defined in [RFC4745]. However, each 329 application making use of the common policy specification needs to 330 determine how the policy server computes the value of the sphere to 331 be used in the evaluation of the condition. 333 To compute the value of , the proxy server interacts with a 334 presence server who knows whether at least one of the published 335 presence documents includes the element [RFC4480] as part of 336 the person data component [RFC4479], and all of those containing the 337 element have the same value for it, that is the value used for the 338 sphere in policy policy processing. If, however, the 339 element was not available to the presence server (and hence not for 340 the proxy server), or it was present but had inconsistent values, its 341 value is considered undefined in terms of policy processing. 343 4.3. SPIT Handling 345 The element is a way to react on the execution of 346 certain SPIT handling mechanisms. For example, a rule might indicate 347 that a CAPTCHA has to be sent to the sender and the sender 348 subsequently has to return the result. Depending on the outcome of 349 the robot test the rules might enforce different actions. This 350 element provides such a condition capability. 352 The condition evaluates to TRUE if any of its child 353 elements evaluate to TRUE, i.e., the results of the individual child 354 element are combined using a logical OR. 356 The element MAY contain zero or more 357 elements. The elements has an attribute 'result' that 358 either contains "SUCCESS" or "FAILURE". 360 4.4. Presence Status 362 This condition evaluates to TRUE when the called user's current 363 presence activity status is equal to the value in the element. Otherwise the condition evaluates to FALSE. 366 4.5. Time Period Condition 368 The element allows to make decisions based on the time, 369 date and timezone. It defines an extended version of the 370 element. 372 The element may contain the following attributes: 374 dtstart: 376 Start of interval (RFC 2445 [RFC2445] DATE-TIME). This attribute 377 is MANDATORY. 379 dtend: 381 End of interval (RFC 2445 [RFC2445] DATE-TIME). This attribute is 382 MANDATORY. 384 timestart: 386 Start of time interval in a particular day. It is of the TIME 387 data type as mentioned in Section 4.3.12 of RFC 2445 [RFC2445]. 388 This attribute is OPTIONAL. The default value is 000000. 390 timeend: 392 End of time interval in a particular day. It is of the TIME data 393 type as mentioned in Section 4.3.12 of RFC 2445 [RFC2445]. This 394 attribute is OPTIONAL. The default value is 235959. 396 byweekday: List of days of the week. This attribute is OPTIONAL. 398 The is based on the description in CPL [RFC3880] but 399 with a reduced feature set. 401 The "dtstart" and "dtend" attributes are formatted as iCalendar COS 402 DATE-TIME values, as specified in Section 4.3.5 of RFC 2445 403 [RFC2445]. Only floating or UTC times can be used with time zones. 404 The DATE-TIME is a subset of the corresponding syntaxes from ISO 8601 405 [ISO8601]. 407 The "timestart" specifes a time value to indicate the beginning of 408 every day. The default value is 000000 representing the beginning of 409 the day. 411 The "timeend" specifes a time value to indicate the end of every day. 412 The default value is 235959 representing the end of the day. 414 The "byweekday" attribute specifies a comma-separated list of days of 415 the week. "MO" indicates Monday, "TU" indicates Tuesday, "WE" 416 indicates Wednesday, "TH" indicates Thursday, "FR" indicates Friday, 417 "SA" indicates Saturday, and "SU" indicates Sunday. These values are 418 not case-sensitive. 420 Here is an example of the time-period element. 422