<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XML Spy v4.4 U (http://www.xmlspy.com) by foo (bar) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC5039 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5039.xml'>
	<!ENTITY I-D.ietf-sipping-app-interaction-framework PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-app-interaction-framework.xml'>
	<!ENTITY I-D.jennings-sip-hashcash PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-sip-hashcash.xml'>
	<!ENTITY I-D.tschofenig-sipping-framework-spit-reduction PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-sipping-framework-spit-reduction.xml'>
	<!ENTITY rfc3688 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml'>
	<!ENTITY rfc3023 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3023.xml'>
	<!ENTITY rfc2048 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2048.xml'>
	<!ENTITY rfc2648 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2648.xml'>
	<!ENTITY rfc2141 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml'>
	<!ENTITY RFC5025 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5025.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc ipr="full3978" category="std" docName="draft-tschofenig-sipping-captcha-01.txt">
	<front>
	   
		<title abbrev="CAPTCHA based Robot Challenges for SIP">Completely Automated Public Turing
			Test to Tell Computers and Humans Apart (CAPTCHA) based Robot Challenges for SIP</title>
	   
		<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
			<organization>Nokia Siemens Networks</organization>
			<address>
				<postal>
					<street>Linnoitustie 6</street>
					<city>Espoo</city>
					<code>02600</code>
					<country>Finland</country>
				</postal>
				<phone>+358 (50) 4871445</phone>
				<email>Hannes.Tschofenig@nsn.com</email>
				<uri>http://www.tschofenig.com</uri>
			</address>
		</author>
		<author fullname="Eva Leppanen" surname="Leppanen" initials="E.">
			<organization>Individual</organization>
			<address>
				<postal>
					<street>
					</street>
					<city/>
					<country>Finland</country>
				</postal>
				<!--phone></phone-->
				<email>eva.leppanen@hukassa.com</email>
			</address>
		</author>
		<author initials="S." surname="Niccolini" fullname="Saverio Niccolini">
			<organization abbrev="NEC">NEC Laboratories Europe, NEC Europe Ltd.</organization>
			<address>
				<postal>
					<street>Kurfuersten-Anlage 36</street>
					<city>Heidelberg</city>
					<code>69115</code>
					<country>Germany</country>
				</postal>
				<phone>+49 (0) 6221 4342 118</phone>
				<email>saverio.niccolini@nw.neclab.eu</email>
				<uri>http://www.nw.neclab.eu</uri>
			</address>
		</author>
		<author fullname="Mayutan Arumaithurai" surname="Arumaithurai" initials="M.">
			<organization>University of Goettingen</organization>
			<address>
				<email>mayutan.arumaithurai@gmail.com</email>
				<uri>http://www.mayutan.org</uri>
			</address>
		</author>
		<date year="2008"/>
		<area>RAI</area>
		<workgroup>SIPPING</workgroup>
		<abstract>
			<t>A common approach to deal with unwanted communication attempts is to rely on some
				form of authorization policies, typically whitelists. In order to populate the
				entries in such an access control list it is helpful to have a way to challenge the
				entity willing to engage in a conversation (unless they are already pre-authorized).
				One reason why this is desired is to deal with robots that are aggressively
				distributing messages.</t>
			<t> This document describes how "Completely Automated Public Turing Test to Tell
				Computers and Humans Apart" (CAPTCHA) tests, which require human interaction, are
				applied to SIP.</t>
		</abstract>
	</front>
	<middle>
		<!-- ////////////////////////////////////////////////////////////////////////////////// -->
		<section title="Introduction" anchor="introduction">
			<t> The problem of unwanted communication is an imminent challenge and only the
				combination of several techniques can provide some degree of protection. <xref
					target="RFC5039"/> provides four recommendations that should to be considered
				for an overall solution, namely, </t>
			<t>
				<list style="symbols">
					<t>Strong Identity</t>
					<t>White Lists</t>
					<t>Solve the Introduction Problem</t>
					<t>Don't Wait Until its Too Late.</t>
				</list>
			</t>
			<t> The human interaction required challenges are mainly used for solving the
				introduction problem targeting to handle requests from user agents with whom the
				recipient do not have former relations. For example, the challenge is initiated
				towards user agents that are not yet white or black-listed, or based on some other
				criteria. </t>
			<t> The <xref target="I-D.tschofenig-sipping-framework-spit-reduction"/> provides a
				framework for dealing with unwanted communication. The policy contains rules that
				are applied to requests if the conditions of a given rule matche. The actions of the
				matching rules are executed and one of the actions could be to provide a challenge
				that must be soved by a human before the request is forwarded to the called party
				triggering the corresponding user interface notifications to the user.</t>
			<t> There are different techniques already developed for challenging user agents.
				&quot;Completely Automated Public Turing Test to Tell Computes and Humans
				Apart&quot; (CAPTCHA) <xref target="captcha"/> typically provides a human a task
				either to recognize something or a question to be answered using different media
				types. <xref target="Inaccessibility-of-CAPTCHA"/> provides alternatives to visual
				test for allowing systems to test for human users while preserving access by users
				with disabilities. Hashcash challenge <xref target="hashcash"/> requires user agents
				to perform CPU-intensive computational puzzles making it difficult to send large
				amounts of requests. The hashcash concept has been proposed for usage with SIP in
					<xref target="I-D.jennings-sip-hashcash"/>. </t>

			<t> Using CAPTCHA techniques for SIP communication requires a mechanism for enabling
				user interaction to be associated with SIP requests. When a proxy or user agent
				server (UAS) server receives a SIP request that needs to be challenged, the proxy or
				UAS sends a challenge to the originator of the SIP request before continue handling
				of the request. After getting the answer to the challenge from the user, the user
				agent client (UAC) needs to provide the answer back towards the UAS in order to get
				the initial request passed to the recipient. </t>
			<t> The challenge should offer multiple choices for the UACs to select depending on the
				capabilities of the device where the UAC is running. Also, the UAC should be able to
				authenticate and authorize the source of challenge. The UAC may receive the
				challenge via a URL or as direct media compoment(s). </t>
			<t> The main goal is to support SIP dialog creating request such as SIP INVITE, but
				ideally the solution should also cover non-dialog creating requests, e.g., SIP
				MESSAGE.
				<!-- It is also important that the mechanism works with the existing UAC
					implementations.-->
			</t>


			<t>Note that this document presents several different solution approaches, see <xref
					target="alternatives"/>. The solution presented in the main part of the document
				is aligned with the work done with <xref target="XEP-0158"/> on CAPTCHAs for XMPP.</t>


		</section>
		<!-- ////////////////////////////////////////////////////////////////////////////////// -->
		<section title="Terminology" anchor="Terminology">
			<t> In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
				NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
				interpreted as described in RFC 2119 <xref target="RFC2119"/> and indicate
				requirement levels for compliant implementations. </t>
			<t> This document makes also use of the vocabulary defined in RFC 3261 <xref
					target="RFC3261"/>. </t>
		</section>
		<!-- ////////////////////////////////////////////////////////////////////////////////// -->

		<section title="UAC, UAS and Proxy Behavior" anchor="behavior">
			<t> </t>
			<section title="Operation of a SIP Proxy or SIP UAS" anchor="SPIT-proxy-oper">
				<t> When a SIP proxy or a SIP UAS receives a SIP request from a UAC, its
					authorization engine may apply the policy to the SIP request, as, for example,
					defined in <xref target="RFC5025"/>. This authorization policy execution may
					result in the need for the proxy (or the UAS) to generate a challenge to the
					UAC, the proxy (or the UAS) can send the challenge directly, can send a URI of
					the challenge, or can redirect the request to a special CAPTCHA UA. </t>
			</section>
			<section title="Operation of UAC" anchor=" UAC-oper">
				<t> The UAC either receives a CAPTCHA challenge or a URI of the challenge. The UAC
					is expected to solve the CAPTCHA puzzle and send the answer back to the SIP
					proxy server or to send a token to indicate that it has successfully solved the
					puzzle. </t>
			</section>
		</section>
		<section title="Description of the CAPTCHA XML Doument" anchor="xml_structure">
			<t>This section describes the content of the CAPTCHA XML document. The XML schema for it
				can be found in <xref target="schema"/>.</t>
			<section title="Structure of XML-Encoded CAPTCHA Challenge" anchor="xml_general">
				<t>A CAPTCHA challenge is an XML document <xref target="XML"/> that MUST be
					well-formed and MUST be valid according to the schema defined in this document,
					including extension schemas available to the validater and applicable to the XML
					document. The XML documents MUST be based on XML 1.0 and MUST be encoded using
					UTF-8.</t>
				<t>The namespace identifier for elements defined by this specification is a URN
						<xref target="RFC2141"/>, using the namespace identifier 'ietf' defined by
						<xref target="RFC2648"/> and extended by <xref target="RFC3688"/>. This URN
					is: urn:ietf:params:xml:ns:captcha. </t>
			</section>
			<section title="MIME Type for CAPTCHA Challenge Document">
				<t>The MIME type for the XML document is 'application/capcha-challenge+xml'.</t>
			</section>
			<section title="The &lt;challenge&gt; Root Element">
				<t>The root element of the XML document is &lt;challenge&gt;.</t>
				<t>The &lt;challenge&gt; element contains the namespace definition mentioned
					in <xref target="xml_general"/>. It also contains a mandatory 'id' attribute for
					correlating the challenge and the answer, and the 'min-tests' attribute with the
					default value set to 1. With the 'min-tests' attribute, it is possible to define
					the minimum amount of tests that need to be solved.</t>
				<t>The &lt;challenge&gt; element MUST have at least one child element. This
					document defines the &lt;media&gt; element as a child element. The
					&lt;challenge&gt; element may contain one or more &lt;media&gt;
					elements. </t>
				<t>The &lt;challenge&gt; element may also be extended by XML elements or
					attributes defined with other namespaces.</t>
			</section>
			<section title="The &lt;media&gt; Element">
				<t>The &lt;media&gt; element contains one child element. This document
					defines the &lt;uri&gt; and &lt;data&gt; elements as child
					elements for allowing the CAPTCHA challenge be provided directly as content or
					as a reference to an external content. </t>
				<t>The &lt;media&gt; element contains a mandatory 'var' attribute indicating
					the type of the challenge (see values from the 'var' column of <xref
						target="captcha-values"/>). It may also contain optional 'width' and
					'height' attributes for providing the size of the content. In addition, the
					element may contain an 'instr' attribute which purpose is to provide
					instructions related to the challenge (see the 'example generic instruction'
					column from <xref target="captcha-values"/>). The required tests can be
					indicated by setting the value of the 'required' attribute to 'true'.</t>

				<t>The &lt;media&gt; element may also be extended by XML elements or
					attributes defined with other namespaces.</t>

			</section>
			<section title="The &lt;uri&gt; element">
				<t>The &lt;uri&gt; element contains a mandatory 'type' attribute indicating
					the MIME type of the challenge. See values from the 'MIME type' column of <xref
						target="captcha-values"/>. The value of the &lt;uri&gt; element is a
					URL where the challenge can be fetched.</t>
				<t>The &lt;uri&gt; element may also be extended by XML attributes defined
					with other namespaces. </t>
			</section>
			<section title="The &lt;data&gt; element">
				<t>The &lt;data&gt; element contains a mandatory 'type' attribute indicating
					the MIME type of the challenge. See typical values from the 'MIME type' column
					of <xref target="captcha-values"/>. </t>
				<t>The value of the &lt;data&gt; element is the content of the challenge.</t>
				<t>The &lt;data&gt; element may also be extended by XML attributes defined
					with other namespaces.</t>
			</section>
			<section title="Values">
				<t>The following table copied from <xref target="XEP-0158"/> presents typical values
					for the CAPTCHA challenge. The 'var' column lists values for the 'var' attribute
					of the &lt;media&gt; element. The 'MIME type' column contains values of
					the corresponding 'type' attribute of the &lt;uri&gt; or
					&lt;data&gt; elements.</t>
				<t>
					<figure title="Information of CAPTCHA challenges" anchor="captcha-values">
						<artwork><![CDATA[
+---------------+-------------+-------+--------+------------------------+
| 'var'         | Name        | Media | MIME   | Example generic        |
|               |             | type  | type   | instructions           |
+---------------+-------------+-------+--------+------------------------+
| ocr*          | Optical Char| image | image/ | Enter the code         |
|               | Recognition |       | jpeg   | you see                |
+---------------+-------------+-------+--------+------------------------+
| picture_recog | Picture     | image | image/ | Describe               |
|               | Recognition |       | jpeg   | the picture            |
+---------------+-------------+-------+--------+------------------------+
| video_recog   | Video       | video | video/ | Describe               |
|               | Recognition |       | mpeg   | the video              |
+---------------+-------------+-------+--------+------------------------+
| speech_recog  | Speech      | audio | audio/ | Enter the              |
|               | Recognition |       | x-wav  | words you hear         |
+---------------+-------------+-------+--------+------------------------+
| audio_recog   | Audio       | audio | audio/ | Describe the           |
|               | Recognition |       | x-wav  | sound you hear         |
+---------------+-------------+-------+--------+------------------------+
| picture_q     | Picture     | image | image/ | Answer the             |
|               | Question    |       | jpeg   | question you see       |
+---------------+-------------+-------+--------+------------------------+
| video_q       | Video       | video | video/ | Answer the             |
|               | Question    |       | mpeg   | question in video      |
+---------------+-------------+-------+--------+------------------------+
| speech_q      | Speech      | audio | audio/ | Answer the             |
|               | Question    |       | x-wav  | question you hear      |
+---------------+-------------+-------+--------+------------------------+
| qa            | Text Q & A  | text  | text/  | Answer the question    |
|               |             |       | plain  |                        |
+---------------+-------------+-------+--------+------------------------+

* The image portrays random characters that humans can read but OCR 
software cannot. To pass the challenge, the user must simply type the 
characters. The correct answer SHOULD NOT depend on the language 
specified by the 'xml:lang' attribute of the challenge.

					]]></artwork>
					</figure>
				</t>
			</section>
		</section>
		<section title="Syntax" anchor="syntax_header">
			<t>The Captcha header field carries the solution information. It has parameters called
				'id' and 'answer'. The 'id' parameter value is set to the same as the 'id' attribute
				of the CAPTCHA challenge sent to the UAC. The 'answer' parameter value is set to the
				answer of the CAPTCHA challenge.</t>
			<!--		<t>
				<list style="empty">
					<t>OPEN ISSUE: the answer parameter to be thought more, e.g. whether there can
						be several answers? And if possible, then also 'var' information should be
						provided.</t>
				</list>
			</t>
	-->
			<t>Example:</t>
			<t> Captcha: id="rjffe32"; answer="2";</t>
			<t/>
			<t>The ABNF for the header is: <figure>
					<artwork><![CDATA[
 Captcha       = "Captcha" HCOLON captcha-parm *(COMMA captcha-param)
 captcha-param =  captcha-id SEMI captcha-answer *(SEMI generic-param)
 captcha-id   = "id" EQUAL quoted-string
 captcha-answer = "answer" EQUAL quoted-string
						]]></artwork>
				</figure>
			</t>
			<t>This document updates the Table 2 of <xref target="RFC3261"/> by adding the
				following: <figure>
					<artwork><![CDATA[

    Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
    ------------         -----   -----   ---  ---  ---  ---  ---  ---
    Captcha               R       dr      o    o    -    o    o    o

                                         SUB  NOT  REF  INF  UPD  PRA
                                         ---  ---  ---  ---  ---  ---
                                          o    o    o    o    o    o
       	                        		]]></artwork>
				</figure>
			</t>
		</section>
		<!-- ////////////////////////////////////////////////////////////////////////////////// -->
		<section title="Example" anchor="example">
			<t>The following XML document shows the content that is provided of a CAPTCHA the
				challenge message sent towards the sending party as shown in message (2) of <xref
					target="FIG2"/>.</t>
			<t>
				<figure>
					<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<challenge xmlns="urn:ietf:params:xml:ns:captcha"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    id="73DE28A2">

    <media var="urn:ietf:params:xml:ns:captcha:ocr" 
		width="290" height="80">
        <uri type="image/jpeg">
		http://www.example.com/challenges/ocr.jpeg?F3A6292C
	</uri>
    </media>
    
    <media var="urn:ietf:params:xml:ns:captcha:audio_recog">
        <uri type="audio/x-wav">
		http://www.example.com/challenges/audio.wav?F3A6292C
	</uri>
    </media>
    
    <media var="urn:ietf:params:xml:ns:captcha:qa">
        <data type="text/plain">Type the color of a stop light</data>
    </media>

</challenge>
					]]></artwork>
				</figure>
			</t>
		</section>
		<!-- ////////////////////////////////////////////////////////////////////////////////// -->
		<section title="XML Schema" anchor="schema">
			<t>This document defines the XML Schema based on the schema defined in Section 12 of
					<xref target="XEP-0158"/>. </t>
			<!--			<t>OPEN ISSUE: should it be possible to define which tests are mandatory, and the
				minimun amount of tests to be executed?</t>
-->
			<t>
				<figure>
					<artwork><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="urn:ietf:params:xml:ns:captcha" 
    xmlns="urn:ietf:params:xml:ns:captcha"
    elementFormDefault="qualified">

    <xs:element name="challenge" type="challengeType"/>

    <xs:complexType name="challengeType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:sequence>
                    <xs:element ref="media" 
                        minOccurs="1" maxOccurs="unbounded"/>
                    <xs:any namespace="##other" 
                        minOccurs="0" processContents="lax"/>
                </xs:sequence>
                <xs:attribute name="id" 
                    use="required" type="xs:string"/>
                <xs:attribute name="min_tests" type="xs:unsignedInt"
                    default="1" use="optional" />
                
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>

    <xs:element name="media" type="mediaType"/>

    <xs:complexType name="mediaType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice minOccurs="1" maxOccurs="1">
                    <xs:element ref="uri" 
                        minOccurs="0" maxOccurs="unbounded"/>
                    <xs:element ref="data" 
                        minOccurs="0" maxOccurs="unbounded"/>
                    <xs:any namespace="##other" minOccurs="0" 
                        processContents="lax"/>
                </xs:choice>
                <xs:attribute name="var" 
                    use="required" type="xs:anyURI"/>
                <xs:attribute name="required" type="xs:boolean"
                    default="false" use="optional"/>
                <xs:attribute name="height" 
                    type="xs:string" use="optional"/>
                <xs:attribute name="width" 
                    type="xs:string" use="optional"/>
                <xs:attribute name="instr"
                    type="xs:string" use="optional"/>
                <xs:anyAttribute namespace="##any"
                    processContents="lax"/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>

    <xs:element name="uri">
        <xs:complexType>
            <xs:simpleContent>
                <xs:extension base="xs:string">
                    <xs:attribute name="type" use="required"/>
                    <xs:anyAttribute namespace="##any"
                        processContents="lax"/>
                </xs:extension>
            </xs:simpleContent>
        </xs:complexType>
    </xs:element>

    <xs:element name="data">
        <xs:complexType>
            <xs:simpleContent>
                <xs:extension base="xs:string">
                    <xs:attribute name="type" use="required"/>
                    <xs:anyAttribute namespace="##any"
                        processContents="lax"/>
                </xs:extension>
            </xs:simpleContent>
        </xs:complexType>
    </xs:element>

</xs:schema>
			]]></artwork>
				</figure>
			</t>
		</section>
		<!-- ////////////////////////////////////////////////////////////////////////////////// -->
		<!--		<section title="Internationalization Support" anchor="internationalization-support">
			<t>[Editor's Note: A future version of this document will describe internationalization
				considerations.]</t>
		</section>
-->
		<!-- ////////////////////////////////////////////////////////////////////////////////// -->
		<section title="Security Considerations" anchor="Security-Considerations">
			<t>[Editor's Note: A future version of this document will describe security
				considerations.]</t>
		</section>
		<!-- ////////////////////////////////////////////////////////////////////////////////// -->
		<section title="IANA Considerations" anchor="IANA-Considerations">
			<t>This specification registers a new header and a new response code. IANA is requested
				to make the following updates in the registry at:
				http://www.iana.org/assignments/sip-parameters. It also registers a new namespace
				and a content type.</t>
			<!--
			<t>OPEN ISSUE: A registry for the 'var' tokens is needed. </t>
			-->
			<section title="Captcha Header" anchor="IANA_captcha-header">
				<t>Add the following entry to the header sub-registry. <figure>
						<artwork><![CDATA[
     Header Name        compact    Reference
     -----------------  -------    ---------
     Captcha                       [RFC-XXXX]
			]]></artwork>
					</figure>
				</t>
			</section>
			<section title="4xx Response" anchor="IANA_resp-4xx">
				<t>Add the following entry to the response code sub-registry under the
					&quot;Request Failure 4xx&quot; heading. </t>
				<t> 4xx CAPTCHA required [RFC-XXXX] </t>
			</section>
			<section title="Namespace" anchor="IANA_ns">
				<t>This section registers a new XML namespace per the procedures in <xref
						target="RFC3688"/>. <figure>
						<artwork><![CDATA[
URI: urn:ietf:params:xml:ns:captcha

   Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig
      (hannes.tschofenig@nsn.com).

   XML:

   BEGIN
   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
     <meta http-equiv="content-type"
           content="text/html;charset=iso-8859-1"/>
     <title>Namespace for CAPTCHA Challenge</title>
   </head>
   <body>
     <h1>Namespace for providing CAPTCHA challenge</h1>
     <h2>urn:ietf:params:xml:ns:captcha</h2>
   <p>See <a href="[URL of published RFC]">RFCXXXX
       [NOTE TO IANA/RFC-EDITOR:
        Please replace XXXX with the RFC number of this
       specification.]</a>.</p>
   </body>
   </html>
   END
						]]></artwork>
					</figure>
				</t>
			</section>
			<section title="Content-Type registration for 'application/captcha-challenge+xml'"
				anchor="IANA_ct">
				<t>This specification requests the registration of a new MIME type according to the
					procedures of RFC 2048 <xref target="RFC2048"/> and guidelines in RFC 3023 <xref
						target="RFC3023"/>. <figure>
						<artwork><![CDATA[

   MIME media type name: application

   MIME subtype name: captcha-challenge+xml
   Mandatory parameters: none
   Optional parameters: charset
     Indicates the character encoding of enclosed XML. Default is UTF-8.
   Encoding considerations:

      Uses XML, which can employ 8-bit characters, depending on the
      character encoding used. See RFC 3023 <xref target="RFC3023"/>, 
      Section 3.2.

   Security considerations:

      This content type is designed to carry challenges for 
      the user agent clients to solve in order to give a proof 
      of being a human behind the generated request. This 
      action is a part of a spam preventing mechanism. 
      Appropriate precautions should be adopted to limit 
      disclosure of this information. Please refer to RFCXXXX 
      [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 
      with the RFC number of this specification.] 
      Security Considerations section for more information.

   Interoperability considerations: none

   Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: 
   Please replace XXXX with the RFC number of this specification.]
   this document

   Applications which use this media type: SIP applications

   Additional information:

      Magic Number: None
      File Extension: .xml
      Macintosh file type code: 'TEXT'

   Personal and email address for further information: Hannes
      Tschofenig, Hannes.Tschofenig@nsn.com
   Intended usage: LIMITED USE

   Author/Change controller:

      This specification is a work item of the IETF SIPPING working
      group, with mailing list address <xxxxx @ietf.org>.
						]]></artwork>
					</figure>
				</t>
			</section>
			<section title="CAPTCHA Schema Registration">
				<t>
					<list style="hanging">
						<t hangText="URI:">urn:ietf:params:xml:schema:captcha</t>
						<t hangText="Registrant Contact:">IETF SIPPING Working Group, Hannes
							Tschofenig (Hannes.Tschofenig@nsn.com).</t>
						<t hangText="XML:">The XML schema to be registered is contained in <xref
								target="schema"/>. Its first line is <figure>
								<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
]]></artwork>
							</figure> and its last line is<figure>
								<artwork><![CDATA[
</xs:schema>
]]></artwork>
							</figure>
						</t>
					</list>
				</t>
			</section>
		</section>
		<!-- ////////////////////////////////////////////////////////////////////////////////// -->
		<section title="Acknowledgments" anchor="Acknowledgements">
			<t>Years ago CAPTCHAs have been introduced for XMPP, see 'XEP-0158: Robot Challenges'
					<xref target="XEP-0158"/>. The authors of this document believe that there is
				value in re-using it for SIP for Spam prevention. Hence, the authors would like to
				thank the XMPP community for their work on this subject. In particular, all credits
				go to Ian Paterson (ian.paterson@clientside.co.uk), the author of <xref
					target="XEP-0158"/>. </t>
			<t>We would like to thank Jonathan Rosenberg for his feedback to this draft.</t>

		</section>

		<!-- ////////////////////////////////////////////////////////////////////////////////// -->

		<section title="Alternative Solution Approaches" anchor="alternatives">

			<t> This section shows alternative solution approaches that can be used by a proxy to
				perform CAPTCHA tests. </t>

			<section title="Challenge by Proxy" anchor="challenge-sip-proxy">

				<section title="Overview" anchor="challenge-sip-proxy-outline">
					<t>
						<xref target="FIG1"/> and <xref target="FIG2"/> present high level messages
						flows for conveying a challenge (e.g., CAPTCHA) to the SIP UAC that
						initiated a dialog forming SIP request. In <xref target="FIG1"/> the
						challenge is included in the body of the SIP 4xx response while <xref
							target="FIG2"/> describes a case when the challenge is fetched via an
						URL that was provided with the response. After the user has managed to solve
						the challenge the UAC re-issues the request with the solution. The proxy
						removes the solution before forwarding the request to the SIP UAS. </t>
					<t>
						<figure title="Proxy returns the CAPTCHA directly with the response"
							anchor="FIG1">
							<artwork><![CDATA[
SIP                                                SIP
UAC                       Proxy                     UAS
 |  1) SIP INVITE          |                         |
 |------------------------>|                         |
 |                         |                         |
 |  2) 4xx + CAPTCHA       |                         |
 |<------------------------|                         |
 |                         |                         |
 |                         |                         |
 |                         |                         |
 |                         |                         |
 |                         |                         |
 |                         |                         |
 |  3) Re-INVITE + Solution|                         |
 |------------------------>|  4) SIP INVITE          |
 |                         |------------------------>|
 |                         |  5) 200 OK              |
 |  6) 200 OK              |<------------------------|
 |<------------------------|                         |
					]]></artwork>
						</figure>
					</t>
					<t>
						<figure title="Proxy returns URL to the CAPTCHA" anchor="FIG2">
							<artwork><![CDATA[
    SIP                                                 SIP
    UAC                       Proxy                     UAS
     |  1) SIP INVITE          |                         |
     |------------------------>|                         |
     |                         |                         |
     |  2) 4xx + CAPTCHA-Ref.  |                         |
     |<------------------------|                         |
     |                         |                         |
 +---+----+                    |                         |
 |3) Fetch|                    |                         |
 |CAPTCHA |                    |                         |
 +---+----+                    |                         |
     |                         |                         |
     | 4) Re-INVITE + Solution |                         |
     |------------------------>|  5) SIP INVITE          |
     |                         |------------------------>|
     |                         |  6) 200 OK              |
     |  7) 200 OK              |<------------------------|
     |<------------------------|                         | 
	                         	]]></artwork>
						</figure>
					</t>
				</section>
				<section title="Operation of Proxy when it issues a challenge directly"
					anchor="SPIT-proxy-oper-direct-challenge">
					<t> The proxy sends a 4xx response with an XML document containing the challenge
						in the body. The Content-Type used for the XML document is
						&prime;application/captcha-challenge+xml&prime;. </t>
					<!-- 					<t>OPEN ISSUE: define the value of the new response code. </t> -->
					<t> When the proxy receives a re-issued SIP request from the UAC, it validates
						the answer provided by the UAC in the CAPTCHA header field. In case the
						answer and other possible policies allow the request to get proxied further
						to the UAS, the proxy removes the CAPTCHA header. Depending on the policies
						and functionality of the proxy, the proxy may update the authorization
						policy according to the decision, e.g., insert the AoR of the user of the
						UAC to a white or black list. In case the answer was not satisfactory, the
						UAS acts according to a defined policy, e.g., rejects the request. </t>
				</section>

				<section title="Operation of UAC on receiving a CAPTCHA challenge from the SIP "
					anchor="UAC-Oper-direct-challenge">
					<t> When the UAC receives a 4xx response with a MIME type
						'application/captcha-challenge+xml' in the body to be solved, the UAC first
						authenticates and authorizes the sender of the challenge.</t>
					<!--				   <t>
					<list style="empty">
						<t>TODO: describe the authentication and authorization more.</t>
					</list>
				   </t> -->
					<t> The UAC selects the challenges marked as mandatory and possibly some
						additional ones for UAC's execution or to be rendered to the user based on,
						e.g., the device capabilities. The UAC may also need to fetch the challenges
						from which URL links were provided. When the challenge gets solved, the UAC
						provides an answer in the CAPTCHA header field by re-issuing the SIP
						request, e.g., by sending a SIP re-INVITE. </t>
					<!--				   <t>
					<list style="empty">
						<t>TODO: describe the selection more when solution details known.</t>
					</list>
				   </t> 
-->

				</section>


			</section>

			<section title="SIP request redirected by the SIP Proxy" anchor="redirected-sip-proxy">

				<section title="Overview" anchor="redirected-sip-proxy-overview">
					<t> In this case, the SIP proxy redirects the INVITE from a SIP UAC to a CAPTCHA
						UAS. The CAPTCHA UA acknowledges the request for service and then, contacts
						the SIP UAC directly to issue the challenge. On performing the CAPTCHA
						tests, it initimates the SIP server of the result. </t>

					<t> The redirect of the INVITE by the SIP server to a CAPTCHA UA is a simple
						call redirect, negotiation of the parameters for the CAPTCHA is done using
						the standard SDP negotiation. From the caller point of view this is just a
						call setup, the caller will be presented the CAPTCHA test depending on the
						media it supports (audio, video, text). In this way there is no need for
						additional signaling that would reveal the caller that a CAPTCHA needs to be
						solved. </t>
					<t><xref target="FIG3"/> presents a high level message flow showing a successful
						CAPTCHA test and <xref target="FIG4"/> presents a high level message flow
						conveying a unsuccessful CAPTCHA challenge by a UA. </t>
					<t>
						<figure
							title="A case where the Proxy redirects the INVITE to a CAPTCHA UA and gets a SUCCCESS repsonse"
							anchor="FIG3">
							<artwork><![CDATA[
   SIP                 SIP Proxy                CAPTCHA               SIP
   UAC                 or UA                      UA                  UAS
    |                    |                         |                   |
    |                    |                         |                   |
    |INVITE(Callee)      |                         |                   |
    +------------------->|                         |                   |
    |                    |INVITE(Re-Directed to    |                   |
    |                    |CAPTCHA UA)              |                   |
    |                    +------------------------>|                   |
    |                    |                         |                   |
    |                    |                         |                   |
    |                    |                   200 OK|                   |
    |                    |<------------------------+                   |
    |                    |                         |                   |
    |              200 OK|                         |                   |
    |<-------------------+                         |                   |
    |  /                 |                      \  |                   |
    |//------------------------------------------\\|                   |
    /                                              \                   |
    \    RTP ( AUDIO/ VIDEO Test Performed )       /                   |
    |\\------------------------------------------//|                   |
    |  \                 |                      /  |                   |
    |                    |                         |                   |
    |                    | <IF Test was Successful>|                   |
    |                    |  REFER TO Callee +      |                   |
    |                    |  Crypto cookie          |                   |
    |                    |<------------------------+                   |
    |                    |                         |                   |
    |  REFER TO Callee + |                         |                   |
    |  Crypto cookie     |                         |                   |
    |<-------------------+                         |                   |
    |                    |                         |                   |
    |INVITE(Callee) +    |                         |                   |
    |Crypto cookie       |                         |                   |
    +------------------->|                                             |
    |                    | INVITE (Callee) + Crypto cookie             |
    |                    +---------------------------------------------|
    |                    |                                             |
    |                    |                                       200 OK|
    |                    |<--------------------------------------------+
    |                    |                         |                   |
    |              200 OK|                         |                   |
    |<-------------------+                         |                   |
    |                    |                         |                   |
    |  /                 |                         |                \  |
    |//--------------------------------------------------------------\\|
    /                                                                  \
    \                    RTP ( REAL CONVERSATION )                     /
    |\\--------------------------------------------------------------//|
    |  \                 |                         |                /  |
    |                    |                         |                   |

					]]></artwork>
						</figure>
					</t>
					<t>
						<figure
							title="A case where the Proxy redirects the INVITE to a CAPTCHA UA and gets a NOT SUCCCESS repsonse"
							anchor="FIG4">
							<artwork><![CDATA[
 
   SIP                 SIP Proxy                CAPTCHA               SIP
   UAC                 or UA                      UA                  UAS
    |                    |                         |                   |
    |                    |                         |                   |
    |INVITE(Callee)      |                         |                   |
    +------------------->|                         |                   |
    |                    |INVITE(Re-Directed to    |                   |
    |                    |CAPTCHA UA)              |                   |
    |                    +------------------------>|                   |
    |                    |                         |                   |
    |                    |                         |                   |
    |                    |                   200 OK|                   |
    |                    |<------------------------+                   |
    |                    |                         |                   |
    |              200 OK|                         |                   |
    |<-------------------+                         |                   |
    |  /                 |                      \  |                   |
    |//------------------------------------------\\|                   |
    /                                              \                   |
    \    RTP ( AUDIO/ VIDEO Test Performed )       /                   |
    |\\------------------------------------------//|                   |
    |  \                 |                      /  |                   |
    |                    |                         |                   |
    |                    | <IF Test was NOT        |                   |
    |                    |  SUCCESSFUL >           |                   |
    |                    |  Bye / 4xx              |                   |
    |                    |<------------------------+                   |
    |                    |                         |                   |
    |                    |                         |                   |
    |           Bye / 4xx|                         |                   |
    |<-------------------+                         |                   |
    |                    |                         |                   |

	                         	]]></artwork>
						</figure>
					</t>
				</section>

				<section title="Operation of Proxy when it redirects the INVITE to a CAPTCHA UA"
					anchor="SPIT-proxy-oper-redirect">
					<t> The SIP server redirects the INVITE to a CAPTCHA UA. The CAPTCHA UA,
						acknowledges the request for service by sending a "200 OK" message. The
						CAPTCHA UA, then proceeds to issue the CAPTCHA challenge to the user. </t>

					<t> If the user is successful in solving the CAPTCHA challenge, the CAPTCHA UA
						issues a reference to the Callee along with crypto cookie to ensure that a
						replay attack isn't possible. The SIP server passes this information to the
						SIP UAC. The SIP UAC issues a new INVITE along with the obtained crypto
						cookie. <xref target="FIG3"/> presents the message flow.</t>

					<t> If the user is not successful in solving the CAPTCHA challenge, the CAPTCHA
						UA issues a Bye message or a 4xx RESPONSE with an appropriate error message.
							<xref target="FIG4"/> presents the message flow. </t>

					<!-- 
					    <t>OPEN ISSUE: define the value of the new response code. </t> 
				    -->
				</section>

				<section title="Operation of UAC when it recieves a challenge from a CAPTCHA UA"
					anchor="UAC-oper-redirect">
					<t> When the UAC receives a challenge from a CAPTCHA UA, the UAC selects the
						challenges marked as mandatory and possibly some additional ones for UAC's
						execution or to be rendered to the user based on e.g. the device
						capabilities. When the challenge gets solved, the UAC provides an answer to
						the CAPTCHA UA. </t>
					<!--	    
						<t> TODO: How does the CAPTCHA UA provide the challenge to the SIP UAC.</t>   
					-->
				</section>



			</section>

			<section title="SIP Application Interaction Framework" anchor="application-sip-proxy">
				<t>
					<xref target="I-D.ietf-sipping-app-interaction-framework"/> defines a framework
					for interaction between users and SIP based applications. The framework covers
					both the &quot;presentation capable&quot; and &quot;presentation
					free&quot; user interfaces (UI) having different solutions to both. The user
					interaction with the presentation capable UI is handled by using SIP REFER and
					HTTP while the presentation free UI case utilize SIP events <xref
						target="RFC3265"/> (SIP SUBSCRIBE and NOTIFY). Since there are different
					solutions for different cases, the UAC needs to indicate the supported
					application user interaction mechamisms when issuing a SIP request. </t>
				<!--	<t>TBD: More text describing the interaction goes in here.</t> -->

			</section>

		</section>

		<!-- ////////////////////////////////////////////////////////////////////////////////// -->

	</middle>
	<back>
		<references title="Normative references">
			<reference anchor="RFC2119">
				<front>
					<title>Key words for use in RFCs to Indicate Requirement Levels</title>
					<author initials="S." fullname="Bradner" surname="Bradner">
						<organization/>
					</author>
					<date year="1997" month="March"/>
				</front>
				<seriesInfo name="BCP" value="14"/>
				<seriesInfo name="RFC" value="2119"/>
			</reference> &rfc3688; &rfc2048; &rfc3023; &rfc2141; &rfc2648;
				<reference anchor="RFC3261">
				<front>
					<title>SIP: Session Initiation Protocol</title>
					<author initials="J." surname="Rosenberg">
						<organization/>
					</author>
					<author initials="H." surname="Schulzrinne">
						<organization/>
					</author>
					<author initials="G." surname="Camarillo">
						<organization/>
					</author>
					<author initials="A." surname="Johnston">
						<organization/>
					</author>
					<author initials="J." surname="Peterson">
						<organization/>
					</author>
					<author initials="R." surname="Sparks">
						<organization/>
					</author>
					<author initials="M." surname="Handley">
						<organization/>
					</author>
					<author initials="E." surname="Schooler">
						<organization/>
					</author>
					<date year="2002" month="June"/>
				</front>
				<seriesInfo name="RFC" value="3261"/>
			</reference>
			<reference anchor="XML">
				<front>
					<title>Exensible Markup Language (XML) 1.0 (Second Edition)</title>
					<author initials="T." surname="Bray">
						<organization/>
					</author>
					<date year="2000" month="October"/>
				</front>
				<seriesInfo name="W3C CR" value="CR-xml11-20011006"/>
			</reference>
		</references>
		<references title="Informative references"> &I-D.jennings-sip-hashcash;
			&I-D.tschofenig-sipping-framework-spit-reduction;
			&I-D.ietf-sipping-app-interaction-framework; &RFC5025; <reference
				anchor="XEP-0158">
				<front>
					<title>XEP-0158: Robot Challenges</title>
					<author initials="I." surname="Paterson">
						<organization/>
					</author>
					<date year="2006" month="October"/>
				</front>
				<seriesInfo name="html"
					value="http://wiki.jabber.org/index.php/Robot Challenges (XEP-0158)"/>
			</reference>
			<reference anchor="hashcash">
				<front>
					<title>Hashcash - A Denial of Service Counter-Measure</title>
					<author initials="A." surname="Back">
						<organization/>
					</author>
					<date year="2002" month="August"/>
				</front>
				<seriesInfo name="html" value="http://hashcash.org"/>
			</reference>
			<reference anchor="captcha">
				<front>
					<title>Telling Humans and Computers Apart Automatically</title>
					<author initials="L." surname="von Ahn">
						<organization/>
					</author>
					<author initials="M." surname="Blum">
						<organization/>
					</author>
					<author initials="J." surname="Langford">
						<organization/>
					</author>
					<date year="2004" month="February"/>
				</front>
				<seriesInfo name="html" value="http://www.captcha.net"/>
			</reference> &RFC5039; <reference anchor="Inaccessibility-of-CAPTCHA">
				<front>
					<title>Inaccessibility of CAPTCHA; Alternatives to Visual Turing Tests on the
						Web</title>
					<author initials="M." surname="May">
						<organization/>
					</author>
					<date year="2005" month="November"/>
				</front>
				<seriesInfo name="html" value="http://www.w3.org/TR/turingtest/"/>
			</reference>
			<reference anchor="RFC3265">
				<front>
					<title>SIP-Specific Event Notification</title>
					<author initials="A." surname="Roach">
						<organization/>
					</author>
					<date year="2002" month="June"/>
				</front>
				<seriesInfo name="RFC" value="3265"/>
			</reference>
		</references>
	</back>
</rfc>
