One document matched: draft-tschofenig-sipping-captcha-01.xml
<?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.
"Completely Automated Public Turing Test to Tell Computes and Humans
Apart" (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 <challenge> Root Element">
<t>The root element of the XML document is <challenge>.</t>
<t>The <challenge> 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 <challenge> element MUST have at least one child element. This
document defines the <media> element as a child element. The
<challenge> element may contain one or more <media>
elements. </t>
<t>The <challenge> element may also be extended by XML elements or
attributes defined with other namespaces.</t>
</section>
<section title="The <media> Element">
<t>The <media> element contains one child element. This document
defines the <uri> and <data> 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 <media> 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 <media> element may also be extended by XML elements or
attributes defined with other namespaces.</t>
</section>
<section title="The <uri> element">
<t>The <uri> 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 <uri> element is a
URL where the challenge can be fetched.</t>
<t>The <uri> element may also be extended by XML attributes defined
with other namespaces. </t>
</section>
<section title="The <data> element">
<t>The <data> 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 <data> element is the content of the challenge.</t>
<t>The <data> 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 <media> element. The 'MIME type' column contains values of
the corresponding 'type' attribute of the <uri> or
<data> 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
"Request Failure 4xx" 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
′application/captcha-challenge+xml′. </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 "presentation capable" and "presentation
free" 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>
| PAFTECH AB 2003-2026 | 2026-04-22 15:42:56 |