idnits 2.17.00 (12 Aug 2021) /tmp/idnits8376/draft-tschofenig-sipping-captcha-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 877. 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 : ---------------------------------------------------------------------------- ** There are 31 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 474 has weird spacing: '... where prox...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2, 2007) is 5436 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) == Missing Reference: 'RFC-XXXX' is mentioned on line 634, but not defined ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' == Outdated reference: draft-ietf-sipping-app-interaction-framework has been published as RFC 5629 == Outdated reference: draft-ietf-sipping-spam has been published as RFC 5039 == Outdated reference: A later version (-06) exists of draft-jennings-sip-hashcash-05 == Outdated reference: A later version (-04) exists of draft-tschofenig-sipping-framework-spit-reduction-00 -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING H. Tschofenig 3 Internet-Draft E. Leppanen 4 Intended status: Standards Track Nokia Siemens Networks 5 Expires: January 3, 2008 July 2, 2007 7 Completely Automated Public Turing Test to Tell Computers and Humans 8 Apart (CAPTCHA) based Robot Challenges for the Session Initiation 9 Protocol (SIP) 10 draft-tschofenig-sipping-captcha-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 3, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 Spam over Internet Telephony (SPIT) is one of the foreseen future 44 forms of spamming that SIP networks may have to handle. SPIT also 45 has more impact on users than email spam since it is more intrusive. 46 Email as a store-and-forward communication mechanism allows for 47 several filtering mechanisms to be applied to the full content before 48 being presented to the user. Session Initiation Protocol (SIP) 49 interaction is, in contrast, real-time communication and therefore 50 does not provide much information prior to the transmission of the 51 content, making it both harder to filter and more annoying to users. 52 The responsibility for filtering, blocking calls, or taking any other 53 preventive action can belong to different elements in the call flow 54 and may depend on various factors. 56 This document concentrates on "Completely Automated Public Turing 57 Test to Tell Computers and Humans Apart" (CAPTCHA) tests, which 58 require human interaction. The document proposes an approach how to 59 apply those challenges to SIP communication for handling the SPIT 60 problem. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Technical requirements and available solutions . . . . . . 5 68 3.2. Overview of the Proposed Solution . . . . . . . . . . . . 6 69 4. Client and Proxy Operations . . . . . . . . . . . . . . . . . 8 70 4.1. Operation of SPIT Proxy . . . . . . . . . . . . . . . . . 8 71 4.2. Operation of UAC . . . . . . . . . . . . . . . . . . . . . 8 72 5. XML Structure . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.1. Structure of XML-Encoded CAPTCHA challenge . . . . . . . . 9 74 5.2. MIME Type for CAPTCHA Challenge Document . . . . . . . . . 9 75 5.3. The Root Element . . . . . . . . . . . . . . . 9 76 5.4. The element . . . . . . . . . . . . . . . . . . . 10 77 5.5. The element . . . . . . . . . . . . . . . . . . . . 10 78 5.6. The element . . . . . . . . . . . . . . . . . . . . 10 79 5.7. Values . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 9. Internationalization Support . . . . . . . . . . . . . . . . . 15 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 11.1. Captcha Header . . . . . . . . . . . . . . . . . . . . . . 15 87 11.2. 4xx Response . . . . . . . . . . . . . . . . . . . . . . . 16 88 11.3. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 16 89 11.4. Content-Type registration for 90 'application/captcha-challenge+xml' . . . . . . . . . . . 16 91 11.5. CAPTCHA Schema Registration . . . . . . . . . . . . . . . 18 92 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 13.1. Normative references . . . . . . . . . . . . . . . . . . . 18 95 13.2. Informative references . . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 98 Intellectual Property and Copyright Statements . . . . . . . . . . 21 100 1. Introduction 102 The problem of Spam for Internet Telephony (SPIT) is an imminent 103 challenge and only the combination of several techniques can provide 104 a framework for dealing with unwanted communication attempts. 105 [I-D.ietf-sipping-spam] provides four core recommendations that need 106 to be considered for a SPIT solution, namely, 107 o Strong Identity 108 o White Lists 109 o Solve the Introduction Problem 110 o Don't Wait Until its Too Late. 112 The human interaction required challenges are mainly used for solving 113 the introduction problem targeting to handle requests from user 114 agents with whom the recipient do not have former relations. E.g., 115 the challenge is initiated towards user agents that are not yet white 116 or black-listed, or based on some other criteria. 118 The [I-D.tschofenig-sipping-framework-spit-reduction] provides a 119 framework for defining SPIT prevention policy. The policy contains 120 rules which are applied to requests if the conditions of a given rule 121 matches. The actions of the matching rules are executed. One of the 122 actions could be to provide a challenge which must be soved by a 123 human before the request is forwarded to the destination. 125 There are different techniques already developed for challenging user 126 agents. "Completely Automated Public Turing Test to Tell Computes 127 and Humans Apart" (CAPTCHA) [captcha] typically provides a human a 128 task either to recognize something or a question to be answered using 129 different media types. [Inaccessibility-of-CAPTCHA] provides 130 alternatives to visual test for allowing systems to test for human 131 users while preserving access by users with disabilities. Hashcash 132 challenge [hashcash] requires user agents to perform CPU-intensive 133 computational puzzles making it difficult to send large amounts of 134 requests. The hashcash concept has been proposed for usage with SIP 135 in [I-D.jennings-sip-hashcash]. XMPP has already adopted some of the 136 techiques as extensions, see [XEP-0158]. 138 The Session Initiation Protocol (SIP) [RFC3261] provides the ability 139 for the users to initiate, manage and terminate communication 140 sessions. The scope of this document is to provide a mechanism for 141 SIP based communication to apply SPIT reduction related challenges 142 requiring human interaction. 144 2. Terminology 146 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 147 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 148 and "OPTIONAL" are to be interpreted as described in RFC 2119 149 [RFC2119] and indicate requirement levels for compliant 150 implementations. 152 This document makes also use of the vocabulary defined in RFC3261 153 [RFC3261]. 155 3. Overview 157 This section describes the technical requirements, available 158 solutions and gives an overview of the proposed solution. The 159 section is informational in nature. It does not contain any 160 normative statements. 162 3.1. Technical requirements and available solutions 164 Adopting CAPTCHA or Hashcash type of techniques for SIP communication 165 requires a mechanism for enabling user interaction type of function 166 to be associated with SIP requests. When a proxy or user agent 167 server (UAS) server receives a SIP request which needs to be 168 challenged, the proxy or UAS sends a challenge to the originator of 169 the SIP request before continue handling of the request. After 170 getting the answer to the challenge from the user, the user agent 171 client (UAC) needs to provide the answer to the proxy or UAS in order 172 to get the request passed to the recipient. 174 The challenge should offer multiple choices for the UACs to select 175 depending on the capabilities of the device where the UAC is running. 176 Also, the UAC should be able to authenticate and authorize the source 177 of challenge. The UAC may receive the challenge via a URL or as 178 direct media compoment(s). 180 The main target is to support SIP dialog creating request such as SIP 181 INVITE, but ideally the solution should also cover non-dialog 182 creating requests, e.g., SIP MESSAGE. It is also important that the 183 mechanism functions with the existing UAC implementations. 185 There are existing mechanisms specified to be considered as a 186 solution for the technical requirements discussed above. 188 [I-D.ietf-sipping-app-interaction-framework] defines a framework for 189 interaction between users and SIP based applications. The framework 190 covers both the "presentation capable" and "presentation free" user 191 interfaces (UI) having different solutions to both. The user 192 interaction with the presentation capable UI is handled by using SIP 193 REFER and HTTP while the presentation free UI case utilize SIP events 195 [RFC3265] (SIP SUBSCRIBE and NOTIFY). Since there are different 196 solutions for different cases, the UAC needs to indicate the 197 supported application user interaction mechamisms when issuing a SIP 198 request. This might be too a heavy requirement for solving the user 199 interaction needs related to SPIT challenges. Also, the application 200 interaction framework requires that a dialog exists before initiating 201 or accepting any user interaction requests. In case of SPIT 202 challenges the user interaction must happen during the dialog 203 establishment so it seems that the application interaction framework 204 cannot be directly used as a solution. 206 [XEP-0158] provides a XMPP based solution for SPIT challenges. The 207 XML format defined for CAPTCHAs and Hashcash can be considered as 208 basis also for the SIP based approach. 210 3.2. Overview of the Proposed Solution 212 The Figure 1 and Figure 2 present high level messages flows for 213 conveying a challenge (e.g., CAPTCHA) to the SIP UAC which initiated 214 a dialog forming SIP request. In Figure 1 the challenge is included 215 in the body of the SIP 4xx response while in Figure 2 describes a 216 case when the challenge is fetched via URL which was provided with 217 the response. After the user has managed to solve the challenge the 218 UAC re-issues the request with the solution. The SPIT proxy removes 219 the solution before proxying the request to the SIP UAS. 221 SIP SPIT SIP 222 UAC Proxy UAS 224 | 1) SIP INVITE | | 225 |------------------------>| | 226 | | | 227 | 2) 4xx + CAPTCHA | | 228 |<------------------------| | 229 | | | 230 | | | 231 | | | 232 | | | 233 | | | 234 | | | 235 | 3) Re-INVITE + Solution| | 236 |------------------------>| 4) SIP INVITE | 237 | |------------------------>| 238 | | 5) 200 OK | 239 | 6) 200 OK |<------------------------| 240 |<------------------------| | 242 Figure 1: A case where the SPIT Proxy returns the CAPTCHA directly 243 with the response 245 SIP SPIT SIP 246 UAC Proxy UAS 248 | 1) SIP INVITE | | 249 |------------------------>| | 250 | | | 251 | 2) 4xx + CAPTCHA-Ref. | | 252 |<------------------------| | 253 | | | 254 +---+----+ | | 255 |3) Fetch| | | 256 |CAPTCHA | | | 257 +---+----+ | | 258 | | | 259 | 4) Re-INVITE + Solution | | 260 |------------------------>| 5) SIP INVITE | 261 | |------------------------>| 262 | | 6) 200 OK | 263 | 7) 200 OK |<------------------------| 264 |<------------------------| | 266 Figure 2: A case where the SPIT Proxy returns a link to the CAPTCHA. 267 The UAC fetches the CAPTCHA e.g. using HTTP. 269 4. Client and Proxy Operations 271 4.1. Operation of SPIT Proxy 273 When the SPIT Proxy receives a SIP request from a UAC, its 274 authorization engine applies the authorization policy to the SIP 275 request as defined in 276 [I-D.tschofenig-sipping-framework-spit-reduction]. When the actions 277 of the authorization policy results to request the proxy to generate 278 a challenge to the UAC, the proxy sends a 4xx response with an XML 279 document containing the challenge in the body. The Content-Type used 280 for the XML document is 'application/captcha-challenge+xml'. 282 OPEN ISSUE: define the value of the new response code. 284 When the SPIT Proxy receives a re-issued SIP request from the UAC, it 285 validates the answer provided by the UAC in the Captcha header field. 286 In case the answer and other possible policies allow the request to 287 get proxied further to the UAS, the SPIT Proxy removes the Captcha 288 header. Depending on the policies and functionality of the SPIT 289 Proxy, the proxy may update the authorization policy according to the 290 decision, e.g., insert the AoR of the user of the UAC to a white or 291 block list. In case the answer was not satisfactory, the UAS acts 292 according to a defined policy, e.g., rejects the request. 294 If the SPIT proxy does not get a re-issued SIP request and/or because 295 of a timeout the SPIT proxy may consider the request ignored. The 296 proxy might in some cases also consider adding the AoR of the user of 297 the UAC to a block or observation list as a potential SPIT address. 299 4.2. Operation of UAC 301 When the UAC receives a 4xx response with a MIME type 'application/ 302 captcha-challenge+xml' in the body to be solved, the UAC first 303 authenticates and authorizes the sender of the challenge. 305 TODO: describe the authentication and authorization more. 307 The UAC selects the challenges marked as mandatory and possibly some 308 additional ones for UAC's execution or to be rendered to the user 309 based on e.g. the device capabilities. The UAC may also need to 310 fetch the challenges from which URL links were provided. When the 311 challenge gets solved, the UAC provides an answer in the Captcha 312 header field by re-issuing the SIP request, e.g. by sending a SIP re- 313 INVITE. 315 TODO: describe the selection more when solution details known. 317 5. XML Structure 319 The XML Schema for the CAPTCHA challenge XML document is defined in 320 Section 8. 322 5.1. Structure of XML-Encoded CAPTCHA challenge 324 A CAPTCHA challenge is an XML document [XML] that MUST be well-formed 325 and MUST be valid according to schemas, including extension schemas 326 available to the validater and applicable to the XML document. The 327 XML documents MUST be based on XML 1.0 and MUST be encoded using 328 UTF-8. 330 The namespace identifier for elements defined by this specification 331 is a URN [RFC2141], using the namespace identifier 'ietf' defined by 332 [RFC2648] and extended by [RFC3688]. This urn is: 333 urn:ietf:params:xml:ns:captcha. 335 5.2. MIME Type for CAPTCHA Challenge Document 337 The MIME type for the XML document is 'application/ 338 capcha-challenge+xml'. 340 OPEN ISSUE: is there a need to indicate support for the MIME type 341 in the initial request? 343 5.3. The Root Element 345 The root element of the XML document is . 347 The element contains the namespace definition mentioned 348 in Section 5.1. It also contains a mandatory 'id' attribute for 349 correlating the challenge and the answer, and the 'min-tests' 350 attribute which default value is 1. With the 'min-tests' attribute, 351 it is possible to define the minimum amount of tests which needs to 352 be solved. 354 The element MUST have at least one child element. This 355 document defines the element as a child element. The 356 element may contain one or more elements. 358 The element may also be extended by XML elements or 359 attributes defined with other namespaces. 361 5.4. The element 363 The element contains one child element. This document 364 defines the and elements as child elements for allowing 365 the CAPTCHA challenge be provided directly as content or as a 366 reference to an external content. 368 The element contains a mandatory 'var' attribute indicating 369 the type of the challenge (see values from the 'var' column of 370 Figure 3). It may also contain optional 'width' and 'height' 371 attributes for providing the size of the content. In addition, the 372 element may contain an 'instr' attribute which purpose is to provide 373 instructions related to the challenge (see the 'example generic 374 instruction' column from Figure 3). The required tests can be 375 indicated by setting the value of the 'required' attribute to 'true'. 377 The element may also be extended by XML elements or 378 attributes defined with other namespaces. 380 5.5. The element 382 The element contains a mandatory 'type' attribute indicating 383 the MIME type of the challenge. See values from the 'MIME type' 384 column of Figure 3. The value of the element is a URL where 385 the challenge can be fetched. 387 The element may also be extended by XML attributes defined with 388 other namespaces. 390 5.6. The element 392 The element contains a mandatory 'type' attribute indicating 393 the MIME type of the challenge. See typical values from the 'MIME 394 type' column of Figure 3. 396 The value of the element is the content of the challenge. 398 The element may also be extended by XML attributes defined 399 with other namespaces. 401 5.7. Values 403 The following table copied from [XEP-0158] presents typical values 404 for the CAPTCHA challenge. The 'var' column lists values for the 405 'var' attribute of the element. The 'MIME type' column 406 contains values of the corresponding 'type' attribute of the or 407 elements. 409 +---------------+-------------+-------+--------+------------------------+ 410 | 'var' | Name | Media | MIME | Example generic | 411 | | | type | type | instructions | 412 +---------------+-------------+-------+--------+------------------------+ 413 | ocr* | Optical Char| image | image/ | Enter the code | 414 | | Recognition | | jpeg | you see | 415 +---------------+-------------+-------+--------+------------------------+ 416 | picture_recog | Picture | image | image/ | Describe | 417 | | Recognition | | jpeg | the picture | 418 +---------------+-------------+-------+--------+------------------------+ 419 | video_recog | Video | video | video/ | Describe | 420 | | Recognition | | mpeg | the video | 421 +---------------+-------------+-------+--------+------------------------+ 422 | speech_recog | Speech | audio | audio/ | Enter the | 423 | | Recognition | | x-wav | words you hear | 424 +---------------+-------------+-------+--------+------------------------+ 425 | audio_recog | Audio | audio | audio/ | Describe the | 426 | | Recognition | | x-wav | sound you hear | 427 +---------------+-------------+-------+--------+------------------------+ 428 | picture_q | Picture | image | image/ | Answer the | 429 | | Question | | jpeg | question you see | 430 +---------------+-------------+-------+--------+------------------------+ 431 | video_q | Video | video | video/ | Answer the | 432 | | Question | | mpeg | question in video | 433 +---------------+-------------+-------+--------+------------------------+ 434 | speech_q | Speech | audio | audio/ | Answer the | 435 | | Question | | x-wav | question you hear | 436 +---------------+-------------+-------+--------+------------------------+ 437 | qa | Text Q & A | text | text/ | Answer the question | 438 | | | | plain | | 439 +---------------+-------------+-------+--------+------------------------+ 441 * The image portrays random characters that humans can read but OCR 442 software cannot. To pass the challenge, the user must simply type the 443 characters. The correct answer SHOULD NOT depend on the language 444 specified by the 'xml:lang' attribute of the challenge. 446 Figure 3: Information of CAPTCHA challenges 448 6. Syntax 450 The Captcha header field carries the solution information. It has 451 parameters called 'id' and 'answer'. The 'id' parameter value is set 452 to the same as the 'id' attribute of the CAPTCHA challenge sent to 453 the UAC. The 'answer' parameter value is set to the answer of the 454 CAPTCHA challenge. 456 OPEN ISSUE: the answer parameter to be thought more, e.g. whether 457 there can be several answers? And if possible, then also 'var' 458 information should be provided. 460 Example: 462 Captcha: id="rjffe32"; answer="2"; 464 The ABNF for the header is: 466 Captcha = "Captcha" HCOLON captcha-parm *(COMMA captcha-param) 467 captcha-param = captcha-id SEMI captcha-answer *(SEMI generic-param) 468 captcha-id = "id" EQUAL quoted-string 469 captcha-answer = "answer" EQUAL quoted-string 471 This document updates the Table 2 of [RFC3261] by adding the 472 following: 474 Header field where proxy ACK BYE CAN INV OPT REG 475 ------------ ----- ----- --- --- --- --- --- --- 476 Captcha R dr o o - o o o 478 SUB NOT REF INF UPD PRA 479 --- --- --- --- --- --- 480 o o o o o o 482 7. Example 484 The following XML document shows the content that is provided of a 485 CAPTCHA the challenge message sent towards the sending party as shown 486 in message (2) of Figure 2. 488 489 493 495 496 http://www.example.com/challenges/ocr.jpeg?F3A6292C 497 498 500 501 502 http://www.example.com/challenges/audio.wav?F3A6292C 503 504 506 507 Type the color of a stop light 508 510 512 8. XML Schema 514 This document defines the XML Schema based on the schema defined in 515 Section 12 of [XEP-0158]. 517 OPEN ISSUE: should it be possible to define which tests are 518 mandatory, and the minimun amount of tests to be executed? 520 522 527 529 530 531 532 533 535 537 538 540 543 544 545 547 549 550 551 552 553 555 557 559 560 562 564 566 568 570 572 573 574 576 577 578 579 580 581 583 584 585 586 588 589 590 591 592 593 595 596 597 598 600 602 9. Internationalization Support 604 [Editor's Note: A future version of this document will describe 605 internationalization considerations.] 607 10. Security Considerations 609 [Editor's Note: A future version of this document will describe 610 security considerations.] 612 11. IANA Considerations 614 This specification registers a new header and a new response code. 615 IANA is requested to make the following updates in the registry at: 616 http://www.iana.org/assignments/sip-parameters. It also registers a 617 new namespace and a content type. 619 OPEN ISSUE: A registry for the 'var' tokens is needed. 621 11.1. Captcha Header 623 Add the following entry to the header sub-registry. 625 Header Name compact Reference 626 ----------------- ------- --------- 627 Captcha [RFC-XXXX] 629 11.2. 4xx Response 631 Add the following entry to the response code sub-registry under the 632 "Request Failure 4xx" heading. 634 4xx CAPTCHA required [RFC-XXXX] 636 11.3. Namespace 638 This section registers a new XML namespace per the procedures in 639 [RFC3688]. 641 URI: urn:ietf:params:xml:ns:captcha 643 Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig 644 (hannes.tschofenig@nsn.com). 646 XML: 648 BEGIN 649 650 652 653 654 656 Namespace for CAPTCHA Challenge 657 658 659

Namespace for providing CAPTCHA challenge

660

urn:ietf:params:xml:ns:captcha

661

See RFCXXXX 662 [NOTE TO IANA/RFC-EDITOR: 663 Please replace XXXX with the RFC number of this 664 specification.].

665 666 667 END 669 11.4. Content-Type registration for 'application/captcha-challenge+xml' 671 This specification requests the registration of a new MIME type 672 according to the procedures of RFC 2048 [RFC2048] and guidelines in 673 RFC 3023 [RFC3023]. 675 MIME media type name: application 677 MIME subtype name: captcha-challenge+xml 678 Mandatory parameters: none 679 Optional parameters: charset 680 Indicates the character encoding of enclosed XML. Default is UTF-8. 681 Encoding considerations: 683 Uses XML, which can employ 8-bit characters, depending on the 684 character encoding used. See RFC 3023 , 685 Section 3.2. 687 Security considerations: 689 This content type is designed to carry challenges for 690 the user agent clients to solve in order to give a proof 691 of being a human behind the generated request. This 692 action is a part of a spam preventing mechanism. 693 Appropriate precautions should be adopted to limit 694 disclosure of this information. Please refer to RFCXXXX 695 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 696 with the RFC number of this specification.] 697 Security Considerations section for more information. 699 Interoperability considerations: none 701 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: 702 Please replace XXXX with the RFC number of this specification.] 703 this document 705 Applications which use this media type: SIP applications 707 Additional information: 709 Magic Number: None 710 File Extension: .xml 711 Macintosh file type code: 'TEXT' 713 Personal and email address for further information: Hannes 714 Tschofenig, Hannes.Tschofenig@nsn.com 715 Intended usage: LIMITED USE 717 Author/Change controller: 719 This specification is a work item of the IETF SIPPING working 720 group, with mailing list address . 722 11.5. CAPTCHA Schema Registration 724 URI: urn:ietf:params:xml:schema:captcha 725 Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig 726 (Hannes.Tschofenig@nsn.com). 727 XML: The XML schema to be registered is contained in Section 8. Its 728 first line is 730 732 and its last line is 734 736 12. Acknowledgments 738 Years ago CAPTCHAs have been introduced for XMPP, see 'XEP-0158: 739 Robot Challenges' [XEP-0158]. The authors of this document believe 740 that there is value in re-using it for SIP for Spam prevention. 741 Hence, the authors would like to thank the XMPP community for their 742 work on this subject. In particular, all credits go to Ian Paterson 743 (ian.paterson@clientside.co.uk), the author of [XEP-0158]. 745 13. References 747 13.1. Normative references 749 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 750 Internet Mail Extensions (MIME) Part Four: Registration 751 Procedures", BCP 13, RFC 2048, November 1996. 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, March 1997. 756 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 758 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 759 August 1999. 761 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 762 Types", RFC 3023, January 2001. 764 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 765 A., Peterson, J., Sparks, R., Handley, M., and E. 766 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 767 June 2002. 769 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 770 January 2004. 772 [XML] Bray, T., "Exensible Markup Language (XML) 1.0 (Second 773 Edition)", W3C CR CR-xml11-20011006, October 2000. 775 13.2. Informative references 777 [I-D.ietf-sipping-app-interaction-framework] 778 Rosenberg, J., "A Framework for Application Interaction in 779 the Session Initiation Protocol (SIP)", 780 draft-ietf-sipping-app-interaction-framework-05 (work in 781 progress), July 2005. 783 [I-D.ietf-sipping-spam] 784 Jennings, C. and J. Rosenberg, "The Session Initiation 785 Protocol (SIP) and Spam", draft-ietf-sipping-spam-04 (work 786 in progress), February 2007. 788 [I-D.jennings-sip-hashcash] 789 Jennings, C., "Computational Puzzles for SPAM Reduction in 790 SIP", draft-jennings-sip-hashcash-05 (work in progress), 791 June 2007. 793 [I-D.tschofenig-sipping-framework-spit-reduction] 794 Tschofenig, H., "A Framework for Reducing Spam for 795 Internet Telephony", 796 draft-tschofenig-sipping-framework-spit-reduction-00 (work 797 in progress), June 2007. 799 [Inaccessibility-of-CAPTCHA] 800 May, M., "Inaccessibility of CAPTCHA; Alternatives to 801 Visual Turing Tests on the Web", 802 html http://www.w3.org/TR/turingtest/, November 2005. 804 [RFC3265] Roach, A., "SIP-Specific Event Notification", RFC 3265, 805 June 2002. 807 [XEP-0158] 808 Paterson, I., "XEP-0158: Robot Challenges", 809 html http://wiki.jabber.org/index.php/Robot Challenges 810 (XEP-0158), October 2006. 812 [captcha] von Ahn, L., Blum, M., and J. Langford, "Telling Humans 813 and Computers Apart Automatically", 814 html http://www.captcha.net, February 2004. 816 [hashcash] 817 Back, A., "Hashcash - A Denial of Service Counter- 818 Measure", html http://hashcash.org, August 2002. 820 Authors' Addresses 822 Hannes Tschofenig 823 Nokia Siemens Networks 824 Otto-Hahn-Ring 6 825 Munich, Bavaria 81739 826 Germany 828 Email: Hannes.Tschofenig@nsn.com 829 URI: http://www.tschofenig.com 831 Eva Leppanen 832 Nokia Siemens Networks 833 P.O BOX 785 834 Tampere 835 Finland 837 Email: eva.leppanen@nsn.com 839 Full Copyright Statement 841 Copyright (C) The IETF Trust (2007). 843 This document is subject to the rights, licenses and restrictions 844 contained in BCP 78, and except as set forth therein, the authors 845 retain all their rights. 847 This document and the information contained herein are provided on an 848 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 849 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 850 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 851 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 852 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 853 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 855 Intellectual Property 857 The IETF takes no position regarding the validity or scope of any 858 Intellectual Property Rights or other rights that might be claimed to 859 pertain to the implementation or use of the technology described in 860 this document or the extent to which any license under such rights 861 might or might not be available; nor does it represent that it has 862 made any independent effort to identify any such rights. Information 863 on the procedures with respect to rights in RFC documents can be 864 found in BCP 78 and BCP 79. 866 Copies of IPR disclosures made to the IETF Secretariat and any 867 assurances of licenses to be made available, or the result of an 868 attempt made to obtain a general license or permission for the use of 869 such proprietary rights by implementers or users of this 870 specification can be obtained from the IETF on-line IPR repository at 871 http://www.ietf.org/ipr. 873 The IETF invites any interested party to bring to its attention any 874 copyrights, patents or patent applications, or other proprietary 875 rights that may cover technology that may be required to implement 876 this standard. Please address the information to the IETF at 877 ietf-ipr@ietf.org. 879 Acknowledgment 881 Funding for the RFC Editor function is provided by the IETF 882 Administrative Support Activity (IASA).