idnits 2.17.1 draft-tschofenig-sipping-captcha-01.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 993. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1000. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1006. 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 35 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 350 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 (February 25, 2008) is 5905 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 502, 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: A later version (-04) exists of draft-tschofenig-sipping-framework-spit-reduction-02 -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 9 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 E. Leppanen 5 Expires: August 28, 2008 Individual 6 S. Niccolini 7 NEC 8 M. Arumaithurai 9 University of Goettingen 10 February 25, 2008 12 Completely Automated Public Turing Test to Tell Computers and Humans 13 Apart (CAPTCHA) based Robot Challenges for SIP 14 draft-tschofenig-sipping-captcha-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 28, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 A common approach to deal with unwanted communication attempts is to 48 rely on some form of authorization policies, typically whitelists. 50 In order to populate the entries in such an access control list it is 51 helpful to have a way to challenge the entity willing to engage in a 52 conversation (unless they are already pre-authorized). One reason 53 why this is desired is to deal with robots that are aggressively 54 distributing messages. 56 This document describes how "Completely Automated Public Turing Test 57 to Tell Computers and Humans Apart" (CAPTCHA) tests, which require 58 human interaction, are applied to SIP. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. UAC, UAS and Proxy Behavior . . . . . . . . . . . . . . . . . 5 65 3.1. Operation of a SIP Proxy or SIP UAS . . . . . . . . . . . 5 66 3.2. Operation of UAC . . . . . . . . . . . . . . . . . . . . . 5 67 4. Description of the CAPTCHA XML Doument . . . . . . . . . . . . 6 68 4.1. Structure of XML-Encoded CAPTCHA Challenge . . . . . . . . 6 69 4.2. MIME Type for CAPTCHA Challenge Document . . . . . . . . . 6 70 4.3. The Root Element . . . . . . . . . . . . . . . 6 71 4.4. The Element . . . . . . . . . . . . . . . . . . . 6 72 4.5. The element . . . . . . . . . . . . . . . . . . . . 7 73 4.6. The element . . . . . . . . . . . . . . . . . . . . 7 74 4.7. Values . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 9.1. Captcha Header . . . . . . . . . . . . . . . . . . . . . . 12 81 9.2. 4xx Response . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.3. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 13 83 9.4. Content-Type registration for 84 'application/captcha-challenge+xml' . . . . . . . . . . . 13 85 9.5. CAPTCHA Schema Registration . . . . . . . . . . . . . . . 15 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 87 11. Alternative Solution Approaches . . . . . . . . . . . . . . . 15 88 11.1. Challenge by Proxy . . . . . . . . . . . . . . . . . . . . 15 89 11.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 90 11.1.2. Operation of Proxy when it issues a challenge 91 directly . . . . . . . . . . . . . . . . . . . . . . 17 92 11.1.3. Operation of UAC on receiving a CAPTCHA challenge 93 from the SIP . . . . . . . . . . . . . . . . . . . . 17 94 11.2. SIP request redirected by the SIP Proxy . . . . . . . . . 17 95 11.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 17 96 11.2.2. Operation of Proxy when it redirects the INVITE 97 to a CAPTCHA UA . . . . . . . . . . . . . . . . . . . 20 98 11.2.3. Operation of UAC when it recieves a challenge 99 from a CAPTCHA UA . . . . . . . . . . . . . . . . . . 20 100 11.3. SIP Application Interaction Framework . . . . . . . . . . 20 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 102 12.1. Normative references . . . . . . . . . . . . . . . . . . . 21 103 12.2. Informative references . . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 105 Intellectual Property and Copyright Statements . . . . . . . . . . 24 107 1. Introduction 109 The problem of unwanted communication is an imminent challenge and 110 only the combination of several techniques can provide some degree of 111 protection. [RFC5039] provides four recommendations that should to 112 be considered for an overall solution, namely, 114 o Strong Identity 115 o White Lists 116 o Solve the Introduction Problem 117 o Don't Wait Until its Too Late. 119 The human interaction required challenges are mainly used for solving 120 the introduction problem targeting to handle requests from user 121 agents with whom the recipient do not have former relations. For 122 example, the challenge is initiated towards user agents that are not 123 yet white or black-listed, or based on some other criteria. 125 The [I-D.tschofenig-sipping-framework-spit-reduction] provides a 126 framework for dealing with unwanted communication. The policy 127 contains rules that are applied to requests if the conditions of a 128 given rule matche. The actions of the matching rules are executed 129 and one of the actions could be to provide a challenge that must be 130 soved by a human before the request is forwarded to the called party 131 triggering the corresponding user interface notifications to the 132 user. 134 There are different techniques already developed for challenging user 135 agents. "Completely Automated Public Turing Test to Tell Computes 136 and Humans Apart" (CAPTCHA) [captcha] typically provides a human a 137 task either to recognize something or a question to be answered using 138 different media types. [Inaccessibility-of-CAPTCHA] provides 139 alternatives to visual test for allowing systems to test for human 140 users while preserving access by users with disabilities. Hashcash 141 challenge [hashcash] requires user agents to perform CPU-intensive 142 computational puzzles making it difficult to send large amounts of 143 requests. The hashcash concept has been proposed for usage with SIP 144 in [I-D.jennings-sip-hashcash]. 146 Using CAPTCHA techniques for SIP communication requires a mechanism 147 for enabling user interaction to be associated with SIP requests. 148 When a proxy or user agent server (UAS) server receives a SIP request 149 that needs to be challenged, the proxy or UAS sends a challenge to 150 the originator of the SIP request before continue handling of the 151 request. After getting the answer to the challenge from the user, 152 the user agent client (UAC) needs to provide the answer back towards 153 the UAS in order to get the initial request passed to the recipient. 155 The challenge should offer multiple choices for the UACs to select 156 depending on the capabilities of the device where the UAC is running. 157 Also, the UAC should be able to authenticate and authorize the source 158 of challenge. The UAC may receive the challenge via a URL or as 159 direct media compoment(s). 161 The main goal is to support SIP dialog creating request such as SIP 162 INVITE, but ideally the solution should also cover non-dialog 163 creating requests, e.g., SIP MESSAGE. 165 Note that this document presents several different solution 166 approaches, see Section 11. The solution presented in the main part 167 of the document is aligned with the work done with [XEP-0158] on 168 CAPTCHAs for XMPP. 170 2. Terminology 172 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 173 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 174 and "OPTIONAL" are to be interpreted as described in RFC 2119 175 [RFC2119] and indicate requirement levels for compliant 176 implementations. 178 This document makes also use of the vocabulary defined in RFC 3261 179 [RFC3261]. 181 3. UAC, UAS and Proxy Behavior 183 3.1. Operation of a SIP Proxy or SIP UAS 185 When a SIP proxy or a SIP UAS receives a SIP request from a UAC, its 186 authorization engine may apply the policy to the SIP request, as, for 187 example, defined in [RFC5025]. This authorization policy execution 188 may result in the need for the proxy (or the UAS) to generate a 189 challenge to the UAC, the proxy (or the UAS) can send the challenge 190 directly, can send a URI of the challenge, or can redirect the 191 request to a special CAPTCHA UA. 193 3.2. Operation of UAC 195 The UAC either receives a CAPTCHA challenge or a URI of the 196 challenge. The UAC is expected to solve the CAPTCHA puzzle and send 197 the answer back to the SIP proxy server or to send a token to 198 indicate that it has successfully solved the puzzle. 200 4. Description of the CAPTCHA XML Doument 202 This section describes the content of the CAPTCHA XML document. The 203 XML schema for it can be found in Section 7. 205 4.1. Structure of XML-Encoded CAPTCHA Challenge 207 A CAPTCHA challenge is an XML document [XML] that MUST be well-formed 208 and MUST be valid according to the schema defined in this document, 209 including extension schemas available to the validater and applicable 210 to the XML document. The XML documents MUST be based on XML 1.0 and 211 MUST be encoded using UTF-8. 213 The namespace identifier for elements defined by this specification 214 is a URN [RFC2141], using the namespace identifier 'ietf' defined by 215 [RFC2648] and extended by [RFC3688]. This URN is: 216 urn:ietf:params:xml:ns:captcha. 218 4.2. MIME Type for CAPTCHA Challenge Document 220 The MIME type for the XML document is 'application/ 221 capcha-challenge+xml'. 223 4.3. The Root Element 225 The root element of the XML document is . 227 The element contains the namespace definition mentioned 228 in Section 4.1. It also contains a mandatory 'id' attribute for 229 correlating the challenge and the answer, and the 'min-tests' 230 attribute with the default value set to 1. With the 'min-tests' 231 attribute, it is possible to define the minimum amount of tests that 232 need to be solved. 234 The element MUST have at least one child element. This 235 document defines the element as a child element. The 236 element may contain one or more elements. 238 The element may also be extended by XML elements or 239 attributes defined with other namespaces. 241 4.4. The Element 243 The element contains one child element. This document 244 defines the and elements as child elements for allowing 245 the CAPTCHA challenge be provided directly as content or as a 246 reference to an external content. 248 The element contains a mandatory 'var' attribute indicating 249 the type of the challenge (see values from the 'var' column of 250 Figure 1). It may also contain optional 'width' and 'height' 251 attributes for providing the size of the content. In addition, the 252 element may contain an 'instr' attribute which purpose is to provide 253 instructions related to the challenge (see the 'example generic 254 instruction' column from Figure 1). The required tests can be 255 indicated by setting the value of the 'required' attribute to 'true'. 257 The element may also be extended by XML elements or 258 attributes defined with other namespaces. 260 4.5. The element 262 The element contains a mandatory 'type' attribute indicating 263 the MIME type of the challenge. See values from the 'MIME type' 264 column of Figure 1. The value of the element is a URL where 265 the challenge can be fetched. 267 The element may also be extended by XML attributes defined with 268 other namespaces. 270 4.6. The element 272 The element contains a mandatory 'type' attribute indicating 273 the MIME type of the challenge. See typical values from the 'MIME 274 type' column of Figure 1. 276 The value of the element is the content of the challenge. 278 The element may also be extended by XML attributes defined 279 with other namespaces. 281 4.7. Values 283 The following table copied from [XEP-0158] presents typical values 284 for the CAPTCHA challenge. The 'var' column lists values for the 285 'var' attribute of the element. The 'MIME type' column 286 contains values of the corresponding 'type' attribute of the or 287 elements. 289 +---------------+-------------+-------+--------+------------------------+ 290 | 'var' | Name | Media | MIME | Example generic | 291 | | | type | type | instructions | 292 +---------------+-------------+-------+--------+------------------------+ 293 | ocr* | Optical Char| image | image/ | Enter the code | 294 | | Recognition | | jpeg | you see | 295 +---------------+-------------+-------+--------+------------------------+ 296 | picture_recog | Picture | image | image/ | Describe | 297 | | Recognition | | jpeg | the picture | 298 +---------------+-------------+-------+--------+------------------------+ 299 | video_recog | Video | video | video/ | Describe | 300 | | Recognition | | mpeg | the video | 301 +---------------+-------------+-------+--------+------------------------+ 302 | speech_recog | Speech | audio | audio/ | Enter the | 303 | | Recognition | | x-wav | words you hear | 304 +---------------+-------------+-------+--------+------------------------+ 305 | audio_recog | Audio | audio | audio/ | Describe the | 306 | | Recognition | | x-wav | sound you hear | 307 +---------------+-------------+-------+--------+------------------------+ 308 | picture_q | Picture | image | image/ | Answer the | 309 | | Question | | jpeg | question you see | 310 +---------------+-------------+-------+--------+------------------------+ 311 | video_q | Video | video | video/ | Answer the | 312 | | Question | | mpeg | question in video | 313 +---------------+-------------+-------+--------+------------------------+ 314 | speech_q | Speech | audio | audio/ | Answer the | 315 | | Question | | x-wav | question you hear | 316 +---------------+-------------+-------+--------+------------------------+ 317 | qa | Text Q & A | text | text/ | Answer the question | 318 | | | | plain | | 319 +---------------+-------------+-------+--------+------------------------+ 321 * The image portrays random characters that humans can read but OCR 322 software cannot. To pass the challenge, the user must simply type the 323 characters. The correct answer SHOULD NOT depend on the language 324 specified by the 'xml:lang' attribute of the challenge. 326 Figure 1: Information of CAPTCHA challenges 328 5. Syntax 330 The Captcha header field carries the solution information. It has 331 parameters called 'id' and 'answer'. The 'id' parameter value is set 332 to the same as the 'id' attribute of the CAPTCHA challenge sent to 333 the UAC. The 'answer' parameter value is set to the answer of the 334 CAPTCHA challenge. 336 Example: 338 Captcha: id="rjffe32"; answer="2"; 340 The ABNF for the header is: 342 Captcha = "Captcha" HCOLON captcha-parm *(COMMA captcha-param) 343 captcha-param = captcha-id SEMI captcha-answer *(SEMI generic-param) 344 captcha-id = "id" EQUAL quoted-string 345 captcha-answer = "answer" EQUAL quoted-string 347 This document updates the Table 2 of [RFC3261] by adding the 348 following: 350 Header field where proxy ACK BYE CAN INV OPT REG 351 ------------ ----- ----- --- --- --- --- --- --- 352 Captcha R dr o o - o o o 354 SUB NOT REF INF UPD PRA 355 --- --- --- --- --- --- 356 o o o o o o 358 6. Example 360 The following XML document shows the content that is provided of a 361 CAPTCHA the challenge message sent towards the sending party as shown 362 in message (2) of Figure 12. 364 365 369 371 372 http://www.example.com/challenges/ocr.jpeg?F3A6292C 373 374 376 377 378 http://www.example.com/challenges/audio.wav?F3A6292C 379 380 382 383 Type the color of a stop light 384 386 388 7. XML Schema 390 This document defines the XML Schema based on the schema defined in 391 Section 12 of [XEP-0158]. 393 395 400 402 403 404 405 406 408 411 412 414 417 418 419 421 423 424 425 426 427 429 431 433 434 436 438 440 442 444 446 447 448 450 451 452 453 454 455 457 458 460 461 463 464 465 466 467 468 470 471 472 473 475 477 8. Security Considerations 479 [Editor's Note: A future version of this document will describe 480 security considerations.] 482 9. IANA Considerations 484 This specification registers a new header and a new response code. 485 IANA is requested to make the following updates in the registry at: 486 http://www.iana.org/assignments/sip-parameters. It also registers a 487 new namespace and a content type. 489 9.1. Captcha Header 491 Add the following entry to the header sub-registry. 493 Header Name compact Reference 494 ----------------- ------- --------- 495 Captcha [RFC-XXXX] 497 9.2. 4xx Response 499 Add the following entry to the response code sub-registry under the 500 "Request Failure 4xx" heading. 502 4xx CAPTCHA required [RFC-XXXX] 504 9.3. Namespace 506 This section registers a new XML namespace per the procedures in 507 [RFC3688]. 509 URI: urn:ietf:params:xml:ns:captcha 511 Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig 512 (hannes.tschofenig@nsn.com). 514 XML: 516 BEGIN 517 518 520 521 522 524 Namespace for CAPTCHA Challenge 525 526 527

Namespace for providing CAPTCHA challenge

528

urn:ietf:params:xml:ns:captcha

529

See RFCXXXX 530 [NOTE TO IANA/RFC-EDITOR: 531 Please replace XXXX with the RFC number of this 532 specification.].

533 534 535 END 537 9.4. Content-Type registration for 'application/captcha-challenge+xml' 539 This specification requests the registration of a new MIME type 540 according to the procedures of RFC 2048 [RFC2048] and guidelines in 541 RFC 3023 [RFC3023]. 543 MIME media type name: application 545 MIME subtype name: captcha-challenge+xml 546 Mandatory parameters: none 547 Optional parameters: charset 548 Indicates the character encoding of enclosed XML. Default is UTF-8. 549 Encoding considerations: 551 Uses XML, which can employ 8-bit characters, depending on the 552 character encoding used. See RFC 3023 , 553 Section 3.2. 555 Security considerations: 557 This content type is designed to carry challenges for 558 the user agent clients to solve in order to give a proof 559 of being a human behind the generated request. This 560 action is a part of a spam preventing mechanism. 561 Appropriate precautions should be adopted to limit 562 disclosure of this information. Please refer to RFCXXXX 563 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 564 with the RFC number of this specification.] 565 Security Considerations section for more information. 567 Interoperability considerations: none 569 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: 570 Please replace XXXX with the RFC number of this specification.] 571 this document 573 Applications which use this media type: SIP applications 575 Additional information: 577 Magic Number: None 578 File Extension: .xml 579 Macintosh file type code: 'TEXT' 581 Personal and email address for further information: Hannes 582 Tschofenig, Hannes.Tschofenig@nsn.com 583 Intended usage: LIMITED USE 585 Author/Change controller: 587 This specification is a work item of the IETF SIPPING working 588 group, with mailing list address . 590 9.5. CAPTCHA Schema Registration 592 URI: urn:ietf:params:xml:schema:captcha 593 Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig 594 (Hannes.Tschofenig@nsn.com). 595 XML: The XML schema to be registered is contained in Section 7. Its 596 first line is 598 600 and its last line is 602 604 10. Acknowledgments 606 Years ago CAPTCHAs have been introduced for XMPP, see 'XEP-0158: 607 Robot Challenges' [XEP-0158]. The authors of this document believe 608 that there is value in re-using it for SIP for Spam prevention. 609 Hence, the authors would like to thank the XMPP community for their 610 work on this subject. In particular, all credits go to Ian Paterson 611 (ian.paterson@clientside.co.uk), the author of [XEP-0158]. 613 We would like to thank Jonathan Rosenberg for his feedback to this 614 draft. 616 11. Alternative Solution Approaches 618 This section shows alternative solution approaches that can be used 619 by a proxy to perform CAPTCHA tests. 621 11.1. Challenge by Proxy 623 11.1.1. Overview 625 Figure 11 and Figure 12 present high level messages flows for 626 conveying a challenge (e.g., CAPTCHA) to the SIP UAC that initiated a 627 dialog forming SIP request. In Figure 11 the challenge is included 628 in the body of the SIP 4xx response while Figure 12 describes a case 629 when the challenge is fetched via an URL that was provided with the 630 response. After the user has managed to solve the challenge the UAC 631 re-issues the request with the solution. The proxy removes the 632 solution before forwarding the request to the SIP UAS. 634 SIP SIP 635 UAC Proxy UAS 636 | 1) SIP INVITE | | 637 |------------------------>| | 638 | | | 639 | 2) 4xx + CAPTCHA | | 640 |<------------------------| | 641 | | | 642 | | | 643 | | | 644 | | | 645 | | | 646 | | | 647 | 3) Re-INVITE + Solution| | 648 |------------------------>| 4) SIP INVITE | 649 | |------------------------>| 650 | | 5) 200 OK | 651 | 6) 200 OK |<------------------------| 652 |<------------------------| | 654 Figure 11: Proxy returns the CAPTCHA directly with the response 656 SIP SIP 657 UAC Proxy UAS 658 | 1) SIP INVITE | | 659 |------------------------>| | 660 | | | 661 | 2) 4xx + CAPTCHA-Ref. | | 662 |<------------------------| | 663 | | | 664 +---+----+ | | 665 |3) Fetch| | | 666 |CAPTCHA | | | 667 +---+----+ | | 668 | | | 669 | 4) Re-INVITE + Solution | | 670 |------------------------>| 5) SIP INVITE | 671 | |------------------------>| 672 | | 6) 200 OK | 673 | 7) 200 OK |<------------------------| 674 |<------------------------| | 676 Figure 12: Proxy returns URL to the CAPTCHA 678 11.1.2. Operation of Proxy when it issues a challenge directly 680 The proxy sends a 4xx response with an XML document containing the 681 challenge in the body. The Content-Type used for the XML document is 682 'application/captcha-challenge+xml'. 684 When the proxy receives a re-issued SIP request from the UAC, it 685 validates the answer provided by the UAC in the CAPTCHA header field. 686 In case the answer and other possible policies allow the request to 687 get proxied further to the UAS, the proxy removes the CAPTCHA header. 688 Depending on the policies and functionality of the proxy, the proxy 689 may update the authorization policy according to the decision, e.g., 690 insert the AoR of the user of the UAC to a white or black list. In 691 case the answer was not satisfactory, the UAS acts according to a 692 defined policy, e.g., rejects the request. 694 11.1.3. Operation of UAC on receiving a CAPTCHA challenge from the SIP 696 When the UAC receives a 4xx response with a MIME type 'application/ 697 captcha-challenge+xml' in the body to be solved, the UAC first 698 authenticates and authorizes the sender of the challenge. 700 The UAC selects the challenges marked as mandatory and possibly some 701 additional ones for UAC's execution or to be rendered to the user 702 based on, e.g., the device capabilities. The UAC may also need to 703 fetch the challenges from which URL links were provided. When the 704 challenge gets solved, the UAC provides an answer in the CAPTCHA 705 header field by re-issuing the SIP request, e.g., by sending a SIP 706 re-INVITE. 708 11.2. SIP request redirected by the SIP Proxy 710 11.2.1. Overview 712 In this case, the SIP proxy redirects the INVITE from a SIP UAC to a 713 CAPTCHA UAS. The CAPTCHA UA acknowledges the request for service and 714 then, contacts the SIP UAC directly to issue the challenge. On 715 performing the CAPTCHA tests, it initimates the SIP server of the 716 result. 718 The redirect of the INVITE by the SIP server to a CAPTCHA UA is a 719 simple call redirect, negotiation of the parameters for the CAPTCHA 720 is done using the standard SDP negotiation. From the caller point of 721 view this is just a call setup, the caller will be presented the 722 CAPTCHA test depending on the media it supports (audio, video, text). 723 In this way there is no need for additional signaling that would 724 reveal the caller that a CAPTCHA needs to be solved. 726 Figure 13 presents a high level message flow showing a successful 727 CAPTCHA test and Figure 14 presents a high level message flow 728 conveying a unsuccessful CAPTCHA challenge by a UA. 730 SIP SIP Proxy CAPTCHA SIP 731 UAC or UA UA UAS 732 | | | | 733 | | | | 734 |INVITE(Callee) | | | 735 +------------------->| | | 736 | |INVITE(Re-Directed to | | 737 | |CAPTCHA UA) | | 738 | +------------------------>| | 739 | | | | 740 | | | | 741 | | 200 OK| | 742 | |<------------------------+ | 743 | | | | 744 | 200 OK| | | 745 |<-------------------+ | | 746 | / | \ | | 747 |//------------------------------------------\\| | 748 / \ | 749 \ RTP ( AUDIO/ VIDEO Test Performed ) / | 750 |\\------------------------------------------//| | 751 | \ | / | | 752 | | | | 753 | | | | 754 | | REFER TO Callee + | | 755 | | Crypto cookie | | 756 | |<------------------------+ | 757 | | | | 758 | REFER TO Callee + | | | 759 | Crypto cookie | | | 760 |<-------------------+ | | 761 | | | | 762 |INVITE(Callee) + | | | 763 |Crypto cookie | | | 764 +------------------->| | 765 | | INVITE (Callee) + Crypto cookie | 766 | +---------------------------------------------| 767 | | | 768 | | 200 OK| 769 | |<--------------------------------------------+ 770 | | | | 771 | 200 OK| | | 772 |<-------------------+ | | 773 | | | | 774 | / | | \ | 775 |//--------------------------------------------------------------\\| 776 / \ 777 \ RTP ( REAL CONVERSATION ) / 778 |\\--------------------------------------------------------------//| 779 | \ | | / | 780 | | | | 782 Figure 13: A case where the Proxy redirects the INVITE to a CAPTCHA 783 UA and gets a SUCCCESS repsonse 785 SIP SIP Proxy CAPTCHA SIP 786 UAC or UA UA UAS 787 | | | | 788 | | | | 789 |INVITE(Callee) | | | 790 +------------------->| | | 791 | |INVITE(Re-Directed to | | 792 | |CAPTCHA UA) | | 793 | +------------------------>| | 794 | | | | 795 | | | | 796 | | 200 OK| | 797 | |<------------------------+ | 798 | | | | 799 | 200 OK| | | 800 |<-------------------+ | | 801 | / | \ | | 802 |//------------------------------------------\\| | 803 / \ | 804 \ RTP ( AUDIO/ VIDEO Test Performed ) / | 805 |\\------------------------------------------//| | 806 | \ | / | | 807 | | | | 808 | | | | 810 | | Bye / 4xx | | 811 | |<------------------------+ | 812 | | | | 813 | | | | 814 | Bye / 4xx| | | 815 |<-------------------+ | | 816 | | | | 817 Figure 14: A case where the Proxy redirects the INVITE to a CAPTCHA 818 UA and gets a NOT SUCCCESS repsonse 820 11.2.2. Operation of Proxy when it redirects the INVITE to a CAPTCHA UA 822 The SIP server redirects the INVITE to a CAPTCHA UA. The CAPTCHA UA, 823 acknowledges the request for service by sending a "200 OK" message. 824 The CAPTCHA UA, then proceeds to issue the CAPTCHA challenge to the 825 user. 827 If the user is successful in solving the CAPTCHA challenge, the 828 CAPTCHA UA issues a reference to the Callee along with crypto cookie 829 to ensure that a replay attack isn't possible. The SIP server passes 830 this information to the SIP UAC. The SIP UAC issues a new INVITE 831 along with the obtained crypto cookie. Figure 13 presents the 832 message flow. 834 If the user is not successful in solving the CAPTCHA challenge, the 835 CAPTCHA UA issues a Bye message or a 4xx RESPONSE with an appropriate 836 error message. Figure 14 presents the message flow. 838 11.2.3. Operation of UAC when it recieves a challenge from a CAPTCHA UA 840 When the UAC receives a challenge from a CAPTCHA UA, the UAC selects 841 the challenges marked as mandatory and possibly some additional ones 842 for UAC's execution or to be rendered to the user based on e.g. the 843 device capabilities. When the challenge gets solved, the UAC 844 provides an answer to the CAPTCHA UA. 846 11.3. SIP Application Interaction Framework 848 [I-D.ietf-sipping-app-interaction-framework] defines a framework for 849 interaction between users and SIP based applications. The framework 850 covers both the "presentation capable" and "presentation free" user 851 interfaces (UI) having different solutions to both. The user 852 interaction with the presentation capable UI is handled by using SIP 853 REFER and HTTP while the presentation free UI case utilize SIP events 854 [RFC3265] (SIP SUBSCRIBE and NOTIFY). Since there are different 855 solutions for different cases, the UAC needs to indicate the 856 supported application user interaction mechamisms when issuing a SIP 857 request. 859 12. References 860 12.1. Normative references 862 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 863 Internet Mail Extensions (MIME) Part Four: Registration 864 Procedures", BCP 13, RFC 2048, November 1996. 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, March 1997. 869 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 871 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 872 August 1999. 874 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 875 Types", RFC 3023, January 2001. 877 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 878 A., Peterson, J., Sparks, R., Handley, M., and E. 879 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 880 June 2002. 882 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 883 January 2004. 885 [XML] Bray, T., "Exensible Markup Language (XML) 1.0 (Second 886 Edition)", W3C CR CR-xml11-20011006, October 2000. 888 12.2. Informative references 890 [I-D.ietf-sipping-app-interaction-framework] 891 Rosenberg, J., "A Framework for Application Interaction in 892 the Session Initiation Protocol (SIP)", 893 draft-ietf-sipping-app-interaction-framework-05 (work in 894 progress), July 2005. 896 [I-D.jennings-sip-hashcash] 897 Jennings, C., "Computational Puzzles for SPAM Reduction in 898 SIP", draft-jennings-sip-hashcash-06 (work in progress), 899 July 2007. 901 [I-D.tschofenig-sipping-framework-spit-reduction] 902 Tschofenig, H., Schulzrinne, H., Wing, D., Rosenberg, J., 903 and D. Schwartz, "A Framework to tackle Spam and Unwanted 904 Communication for Internet Telephony", 905 draft-tschofenig-sipping-framework-spit-reduction-02 (work 906 in progress), November 2007. 908 [Inaccessibility-of-CAPTCHA] 909 May, M., "Inaccessibility of CAPTCHA; Alternatives to 910 Visual Turing Tests on the Web", 911 html http://www.w3.org/TR/turingtest/, November 2005. 913 [RFC3265] Roach, A., "SIP-Specific Event Notification", RFC 3265, 914 June 2002. 916 [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, 917 December 2007. 919 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 920 Protocol (SIP) and Spam", RFC 5039, January 2008. 922 [XEP-0158] 923 Paterson, I., "XEP-0158: Robot Challenges", 924 html http://wiki.jabber.org/index.php/Robot Challenges 925 (XEP-0158), October 2006. 927 [captcha] von Ahn, L., Blum, M., and J. Langford, "Telling Humans 928 and Computers Apart Automatically", 929 html http://www.captcha.net, February 2004. 931 [hashcash] 932 Back, A., "Hashcash - A Denial of Service Counter- 933 Measure", html http://hashcash.org, August 2002. 935 Authors' Addresses 937 Hannes Tschofenig 938 Nokia Siemens Networks 939 Linnoitustie 6 940 Espoo 02600 941 Finland 943 Phone: +358 (50) 4871445 944 Email: Hannes.Tschofenig@nsn.com 945 URI: http://www.tschofenig.com 947 Eva Leppanen 948 Individual 949 Finland 951 Email: eva.leppanen@hukassa.com 952 Saverio Niccolini 953 NEC Laboratories Europe, NEC Europe Ltd. 954 Kurfuersten-Anlage 36 955 Heidelberg 69115 956 Germany 958 Phone: +49 (0) 6221 4342 118 959 Email: saverio.niccolini@nw.neclab.eu 960 URI: http://www.nw.neclab.eu 962 Mayutan Arumaithurai 963 University of Goettingen 965 Email: mayutan.arumaithurai@gmail.com 966 URI: http://www.mayutan.org 968 Full Copyright Statement 970 Copyright (C) The IETF Trust (2008). 972 This document is subject to the rights, licenses and restrictions 973 contained in BCP 78, and except as set forth therein, the authors 974 retain all their rights. 976 This document and the information contained herein are provided on an 977 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 978 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 979 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 980 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 981 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 982 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 984 Intellectual Property 986 The IETF takes no position regarding the validity or scope of any 987 Intellectual Property Rights or other rights that might be claimed to 988 pertain to the implementation or use of the technology described in 989 this document or the extent to which any license under such rights 990 might or might not be available; nor does it represent that it has 991 made any independent effort to identify any such rights. Information 992 on the procedures with respect to rights in RFC documents can be 993 found in BCP 78 and BCP 79. 995 Copies of IPR disclosures made to the IETF Secretariat and any 996 assurances of licenses to be made available, or the result of an 997 attempt made to obtain a general license or permission for the use of 998 such proprietary rights by implementers or users of this 999 specification can be obtained from the IETF on-line IPR repository at 1000 http://www.ietf.org/ipr. 1002 The IETF invites any interested party to bring to its attention any 1003 copyrights, patents or patent applications, or other proprietary 1004 rights that may cover technology that may be required to implement 1005 this standard. Please address the information to the IETF at 1006 ietf-ipr@ietf.org. 1008 Acknowledgment 1010 Funding for the RFC Editor function is provided by the IETF 1011 Administrative Support Activity (IASA).