SIPPING H. Tschofenig Internet-Draft Nokia Siemens Networks Intended status: Standards Track D. Wing Expires: January 13, 2009 Cisco H. Schulzrinne Columbia University T. Froment Alcatel-Lucent G. Dawirs University of Namur July 12, 2008 A Document Format for Expressing Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony draft-tschofenig-sipping-spit-policy-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 13, 2009. Abstract SPAM, defined as sending unsolicited messages to someone in bulk, might be a problem on SIP open-wide deployed networks. The responsibility for filtering or blocking calls can belong to different elements in the call flow and may depend on various Tschofenig, et al. Expires January 13, 2009 [Page 1] Internet-Draft Policies for Internet Telephony Spam July 2008 factors. This document defines an authorization based policy language that allows end users to upload anti-SPIT policies to intermediaries, such as SIP proxies. These policies mitigate unwanted SIP communications. It extends the Common Policy authorization framework with additional conditions and actions. The new conditions match a particular Session Initiation Protocol (SIP) communication pattern based on a number of attributes. The range of attributes includes information provided, for example, by SIP itself, by the SIP identity mechanism, by information carried within SAML assertions. Tschofenig, et al. Expires January 13, 2009 [Page 2] Internet-Draft Policies for Internet Telephony Spam July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Structure of SPIT Authorization Documents . . . . . . . . 5 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 5 4. Condition Elements . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Acceptable Forms of Authentication . . . . . . . . . . 6 4.1.2. Computing a URI for the Sender . . . . . . . . . . . . 7 4.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. SPIT Handling . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Presence Status . . . . . . . . . . . . . . . . . . . . . 9 4.5. Time Period Condition . . . . . . . . . . . . . . . . . . 9 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Execute Action . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Forward To . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Identity and Time-Based Policy . . . . . . . . . . . . . . 12 6.2. Extended Time-Based Policy . . . . . . . . . . . . . . . . 13 6.3. Policy for triggering Captcha and Hashcash Challenges . . 14 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. XCAP USAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 19 8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 19 8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 20 8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 20 8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 20 8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 20 8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 20 8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 20 8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.1. Anti-SPIT Policy XML Schema Registration . . . . . . . . . 21 9.2. Anti-SPIT Policy Namespace Registration . . . . . . . . . 21 9.3. XCAP Application Usage ID . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Tschofenig, et al. Expires January 13, 2009 [Page 3] Internet-Draft Policies for Internet Telephony Spam July 2008 1. Introduction The problem of SPAM for Internet Telephony (SPIT) is an imminent challenge and only the combination of several techniques can provide a framework for dealing with unwanted communication, as stated in [I-D.jennings-sip-hashcash]. One important building block is to have a mechanism that can instruct SIP intermediaries to react differently on incoming requests based on policies. Different entities, such as end users, parents on behalf of their children, system administrators in enterprise networks, etc., might create and modify authorization policies. The conditions in these policies can be created from many sources but some information elements are more important than others. For example, there is reason to believe that applying authorization policies based on the authenticated identity is an effective way to accept a communication attempt to deal with unsolicited communication. Authentication based on the SIP identity mechanism, see [RFC4474], is one important concept. The requirements for the authorization policies described in this document are outlined in [I-D.froment-sipping-spit-requirements]. A framework document is available at [I-D.tschofenig-sipping-framework-spit-reduction]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document reuses the terminology from RFC 4745 [RFC4745]: Rule maker: The RM is an entity that creates the authorization policies that react to unwanted connection attempts. The rule maker might be an end user that owns the device, a VoIP service provider, a person with a relationship to the end user (e.g., the parents of a child using a mobile phone). A standardized policy language is needed when the creation, modification and deletion of authorization policies are not only a local matter. Tschofenig, et al. Expires January 13, 2009 [Page 4] Internet-Draft Policies for Internet Telephony Spam July 2008 Authorization policy: An authorization policy is given by a rule set. A rule set contains an unordered list of rules. Each rule has a condition, an action and a transformation component. The terms 'authorization policy', 'policy', 'rule set', 'authorization policy rule', 'policy rule' and 'rule' are used interchangeably. Authorization policies can be applied at the end host and/or by intermediaries. Permission: The term permission refers to the action and transformation components of a rule. We use the term 'Recipient' for the entity that is target of the communication attempt of a sender. 3. Generic Processing 3.1. Structure of SPIT Authorization Documents A SPIT authorization document is an XML document, formatted according to the schema defined in RFC 4745 [RFC4745]. SPIT authorization documents inherit the MIME type of common policy documents, application/auth-policy+xml. As described in [RFC4745], this document is composed of rules which contain three parts - conditions, actions, and transformations. Each action or transformation, which is also called a permission, has the property of being a positive grant to the authorization server to perform the resulting actions, be it allow, block etc . As a result, there is a well-defined mechanism for combining actions and transformations obtained from several sources. This mechanism therefore can be used to filter connection attempts thus leading to effective SPIT prevention. 3.2. Rule Transport Policies are XML documents that are stored at a Proxy Server or a dedicated device. The Rule Maker therefore needs to use a protocol to create, modify and delete the authorization policies defined in this document. Such a protocol is available with the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825]. Tschofenig, et al. Expires January 13, 2009 [Page 5] Internet-Draft Policies for Internet Telephony Spam July 2008 4. Condition Elements This section describes the additional enhancements of the conditions- part of the rule. This document inherits the Common Policy functionality, including , , and conditions. Note that, as discussed in [RFC4745], a permission document applies to a translation if all the expressions in its conditions part evaluate to TRUE. 4.1. Identity Although the element is defined in [RFC4745], that specification indicates that the specific usages of the framework document need to define details that are protocol and usage specific. In particular, it is necessary for a usage of the common policy framework to: o Define acceptable means of authentication. o Define the procedure for representing the identity as a URI or IRI [RFC3987]. This sub-section defines those details for systems based on [RFC3856]. 4.1.1. Acceptable Forms of Authentication When used with SIP, a request is considered authenticated if one of the following techniques is used: SIP Digest: The proxy has authenticated the sender using SIP [RFC3261] digest authentication [RFC2617]. However, if the anonymous authentication described on page 194 of RFC 3261 [RFC3261] was used, the sender is not considered authenticated. Asserted Identity: If a request contains a P-Asserted-ID header field [RFC3325] and the request is coming from a trusted element, the sender is considered authenticated. Tschofenig, et al. Expires January 13, 2009 [Page 6] Internet-Draft Policies for Internet Telephony Spam July 2008 Cryptographically Verified Identity: If a request contains an Identity header field as defined in [RFC4474], and it validates the From header field of the request, the request is considered to be authenticated. Note that this is true even if the request contained a From header field of the form sip:anonymous@example.com. As long as the signature verifies that the request legitimately came from this identity, it is considered authenticated. An anonymous From header field with RFC 4474 [RFC4474] is considered authenticated, while anonymous digest is not considered authenticated, because the former still involves the usage of an actual username and credential as part of an authentication operation in the originating domain. 4.1.2. Computing a URI for the Sender For messages that are authenticated using SIP Digest, the identity of the sender is set equal to the address of record (AoR) for the user that has authenticated themselves. The AoR is always a URI, and can be either a SIP URI or tel URI [RFC3966]. For example, consider the following "user record" in a database: SIP AOR: sip:alice@example.com digest username: ali digest password: f779ajvvh8a6s6 digest realm: example.com If the proxy server receives an INVITE, challenges it with the realm set to "example.com", and the subsequent INVITE contains an Authorization header field with a username of "ali" and a digest response generated with the password "f779ajvvh8a6s6", the identity used in matching operations is "sip:alice@example.com". For messages that are authenticated using RFC 3325 [RFC3325], the identity of the sender is equal to the URI in the P-Asserted-ID header field. If there are multiple values for the P-Asserted-ID header field (there can be one sip URI and one tel URI [RFC3966]), then each of them is used for the comparisons outlined in [RFC4745], and if either of them match a or element, it is considered a match. For messages that are authenticated using the SIP Identity mechanism [RFC4474], identity of the sender is equal to the SIP URI in the From header field of the request, assuming that the signature in the Identity header field has been validated. Tschofenig, et al. Expires January 13, 2009 [Page 7] Internet-Draft Policies for Internet Telephony Spam July 2008 In SIP systems, it is possible for a user to have aliases - that is, there are multiple SIP AoRs "assigned" to a single user. In terms of this specification, there is no relationship between those aliases. Each would look like a different user. This will be the consequence for systems where the sender is in a different domain than the recipient. However, even if the sender and recipient are in the same domain, and the proxy server knows that there are aliases for the sender, these aliases are not mapped to each other or used in any way. SIP also allows for anonymous identities. If a message is anonymous because the digest challenge/response used the "anonymous" username, the message is considered unauthenticated and will match only an empty element. If a message is anonymous because it contains a Privacy header field [RFC3323], but still contains a P-Asserted-ID header field, the identity in the P-Asserted-ID header field is still used in the authorization computations; the fact that the message was anonymous has no impact on the identity processing. However, if the message had traversed a trust boundary and the P-Asserted-ID header field and the Privacy header field had been removed, the message will be considered unauthenticated when it arrives at the proxy server. Finally, if a message contained an Identity header field that was validated, and the From header field contained a URI of the form sip:anonymous@example.com, then the sender is considered authenticated, and it will have an identity equal to sip:anonymous@example.com. Had such an identity been placed into a or element, there will be a match. It is important to note that SIP frequently uses both SIP URI and tel URI [RFC3966] as identifiers, and to make matters more confusing, a SIP URI can contain a phone number in its user part, in the same format used in a tel URI. The sender's identity that is a SIP URI with a phone number will not match the and conditions whose 'id' is a tel URI with the same number. The same is true in the reverse. If the sender's identity is a tel URI, this will not match a SIP URI in the or conditions whose user part is a phone number. URIs of different schemes are never equivalent. 4.2. Sphere The element is defined in [RFC4745]. However, each application making use of the common policy specification needs to determine how the policy server computes the value of the sphere to be used in the evaluation of the condition. To compute the value of , the proxy server interacts with a presence server who knows whether at least one of the published presence documents includes the element [RFC4480] as part of Tschofenig, et al. Expires January 13, 2009 [Page 8] Internet-Draft Policies for Internet Telephony Spam July 2008 the person data component [RFC4479], and all of those containing the element have the same value for it, that is the value used for the sphere in policy policy processing. If, however, the element was not available to the presence server (and hence not for the proxy server), or it was present but had inconsistent values, its value is considered undefined in terms of policy processing. 4.3. SPIT Handling The element is a way to react on the execution of certain SPIT handling mechanisms. For example, a rule might indicate that a CAPTCHA has to be sent to the sender and the sender subsequently has to return the result. Depending on the outcome of the robot test the rules might enforce different actions. This element provides such a condition capability. The condition evaluates to TRUE if any of its child elements evaluate to TRUE, i.e., the results of the individual child element are combined using a logical OR. The element MAY contain zero or more elements. The elements has an attribute 'result' that either contains "SUCCESS" or "FAILURE". 4.4. Presence Status This condition evaluates to TRUE when the called user's current presence activity status is equal to the value in the element. Otherwise the condition evaluates to FALSE. 4.5. Time Period Condition The element allows to make decisions based on the time, date and timezone. It defines an extended version of the element. The element may contain the following attributes: dtstart: Start of interval (RFC 2445 [RFC2445] DATE-TIME). This attribute is MANDATORY. dtend: End of interval (RFC 2445 [RFC2445] DATE-TIME). This attribute is MANDATORY. Tschofenig, et al. Expires January 13, 2009 [Page 9] Internet-Draft Policies for Internet Telephony Spam July 2008 timestart: Start of time interval in a particular day. It is of the TIME data type as mentioned in Section 4.3.12 of RFC 2445 [RFC2445]. This attribute is OPTIONAL. The default value is 000000. timeend: End of time interval in a particular day. It is of the TIME data type as mentioned in Section 4.3.12 of RFC 2445 [RFC2445]. This attribute is OPTIONAL. The default value is 235959. byweekday: List of days of the week. This attribute is OPTIONAL. The is based on the description in CPL [RFC3880] but with a reduced feature set. The "dtstart" and "dtend" attributes are formatted as iCalendar COS DATE-TIME values, as specified in Section 4.3.5 of RFC 2445 [RFC2445]. Only floating or UTC times can be used with time zones. The DATE-TIME is a subset of the corresponding syntaxes from ISO 8601 [ISO8601]. The "timestart" specifes a time value to indicate the beginning of every day. The default value is 000000 representing the beginning of the day. The "timeend" specifes a time value to indicate the end of every day. The default value is 235959 representing the end of the day. The "byweekday" attribute specifies a comma-separated list of days of the week. "MO" indicates Monday, "TU" indicates Tuesday, "WE" indicates Wednesday, "TH" indicates Thursday, "FR" indicates Friday, "SA" indicates Saturday, and "SU" indicates Sunday. These values are not case-sensitive. Here is an example of the time-period element.