One document matched: draft-petithuguenin-vipr-sip-antispam-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-petithuguenin-vipr-sip-antispam-00" ipr="trust200902">
<front>
<title abbrev="ViPR SPAM Blocking">Session Initiation Protocol (SIP)
Extensions for Blocking VoIP Spam Using PSTN Validation</title>
<author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
<organization>jdrosen.net</organization>
<address>
<postal>
<street/>
<city>Monmouth</city>
<region>NJ</region>
<country>US</country>
</postal>
<email>jdrosen@jdrosen.net</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<street>MS: SJC-21/2</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Marc Petit-Huguenin" initials="M." surname="Petit-Huguenin">
<organization>Stonyfish</organization>
<address>
<email>marc@stonyfish.com</email>
</address>
</author>
<date day="1" month="April" year="2011"/>
<area>RAI</area>
<workgroup>dispatch</workgroup>
<abstract>
<t>Verification Involving PSTN Reachability (ViPR) is a new
technique for inter-domain federation of SIP calls. ViPR makes
use of the PSTN as an introduction mechanism to verify the
correctness of mappings from phone numbers to domains. The PSTN
introduction mechanism can also be used as a technique for
blocking spam - a SIP caller is only authorized when its
calling domain has previously called that same number over the
PSTN. This document describes an extension to SIP which enables
authorization of SIP calls based on a prior PSTN introduction.
</t>
</abstract>
<note title="Legal">
<t>This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The anti-spam tickets described in this specification are the key
security mechanism in ViPR for mitigation of SPAM. The domain
originating a call inserts a ticket in the SIP INVITE sent to the other
domain. The Border Element in the domain receiving the call (see <xref target="fig-arch"/>) can check the ticket to ensure that this
originating domain has been authorized by the terminating domain. This
document relies heavily on the concepts and terminology defined in <xref target="VIPR-OVERVIEW"/> and will not make
sense if you have not read that document first.</t>
<figure anchor="fig-arch" title="Architecture ">
<artwork><![CDATA[
+-+ +-+
| | | | +------+
| | +-----| |---|Enroll|
| | | | | +------+
|I| | |I|
|n| +-----+ |n|
VAP |t| | ViPR| |t|
+----------|r|---|Srvr |--|e|-----------------
| |a| | | |r| P2P-Validation
| |n| +-----+ |n|
| |e| |e|
| |t| |t|
+-----+ SIP | | +-----+ | |
| CA |-------|F|---| |--|F| ---------------
+-----+ |i| | | |i| SIP/TLS
. |r| | . | |r|
SIP/ . |e| | | |e|
MGCP/ . |w| | BE | |w|
TDM . |a| | | |a|
. |l| | | |l|
+-----+ |l| | | |l|
| UA |-------| |---| |--| |-----------------
+-----+ | | +-----+ | | SRTP
| | | |
+-+ +-+
| |
+--------------------+-----------------+
|
Single administrative domain
]]></artwork>
</figure>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section title="Terminating Side Procedures">
<t>The Border Element will receive the TLS ClientHello which begins
the TLS handshake. The Border Element will present its own configured
cert. Once TLS handshaking is complete, the Border Element notes the
domain from the SubjectAltName on the other side of the TLS connection,
and associates it with that connection.</t>
<t>Next, the Border Element will receive an INVITE. This INVITE will
contain a ticket in the X-Cisco-ViPR-Ticket header field value. The
Border Element extracts this header field. This call flow assumes it is
present. The Border Element parses it, and obtains the epoch value
encoded in the ticket. This is matched against the current epoch value
for the configured password. If they match, processing continues. The
Border Element verifies the signature is correct. Next, it examines the
start and stop time of the validity. If the current time is between the
start and stop times, the check is passed. Next, the Border Element
checks the granted-to domain in the ticket. It compares that domain
against the domain name in the SubjectAltName of the peer on the other
side of the TLS connection, as noted above. Next, it takes the
Request-URI of the SIP INVITE. That will be of the form
sip:+number@domain. If it is not in that form, and if the number does
not begin with a plus, the request is dropped. The value, including the
plus, is then compared to the number in the ticket. If it is equal, the check
has passed. The Border Element leaves the header field in the request,
but forwards to the Call Agent.</t>
<t>In addition, the Border Element will typically be configured to apply
its SIP message validation logic, and enforce restrictions on the sizes
of various SIP header fields. This provides an additional layer of
security in case malicious SIP messages are sent.</t>
<t>The Border Element will also apply port forwarding in the case of
NAT, so that the incoming request is forwarded to the appropriate Call
Agent node.</t>
<t>The Call Agent will receive incoming SIP INVITEs.
The Request-URI of the INVITE will contain an E.164 number as indicated
by a leading plus. If the Request-URI is not an E.164, the request must
be rejected with a 403. Only E.164 numbers can be accepted on a ViPR
trunk.</t>
</section>
<section title="Originating Side Procedures">
<t>The routes stored to other domains in the Call Agent will each store
a ticket to utilize with calls to that route. The Call Agent learns
about these routes and the information needed to construct the ticket
from the <xref target="VIPR-VAP">VAP
protocol</xref>. When sending a SIP request to one of these domains, the
Call Agent MUST include the ticket in any dialog forming request or
request that is not in an existing dialog. </t>
</section>
<section title="Tickets">
<t>This ticket is a sequence of characters. These MUST be placed into a
X-Cisco-ViPR-Ticket SIP header field value. Consequently the format for
this header field is:</t>
<figure>
<artwork><![CDATA[Ticket = "X-Cisco-ViPR-Ticket" HCOLON ticket-val
ticket-val = 1*(alphanum / "-" / "_" / ".")
]]></artwork>
</figure>
<t/>
<t>This header field MUST be utilized in all dialog forming requests and all
out-of-dialog requests. It is not utilized in responses. The
ticket-value is a modified base64 encoded version of an object that is composed
of a series of TLVs. Each TLV is a 16 bit type, a 16 bit length, and a
variable length value. The length field refers to the length of the
value portion of the TLV, measured in bytes. The following TLV types are
defined:</t>
<t>
<list style="numbers">
<t>Ticket Unique ID: This TLV has a type of 0x0001. It contains a
128 bit ID that has a unique identifier for this ticket. The value
MUST contain a 128 bit UUID defined by <xref target="RFC4122"/>. This TLV MUST be present. However at this
time it is used for diagnostic purposes only.</t>
<t>Salt: This TLV has a type of 0x0002. It contains a value which
MUST be at least 32 bits, and contains a random number. Its presence
ensures that each ticket contains sufficient randomness. This TLV
MUST be present.</t>
<t>Validity: This TLV has a type of 0x0003. It contains two 64 bit
NTP times. The first is the start of the validity of the ticket, the
next is the end time for the validity of the ticket. This TLV MUST
be present.</t>
<t>Number: This TLV has a type of 0x0004. It contains a string which
has an E.164 number, included the "+", which may be called using this
ticket. The TLV has variable length. This TLV MUST be present.</t>
<t>Granting Node: This TLV has a type of 0x0005. It contains a 128
bit value which is the Node-ID of the node which granted the ticket.
This TLV MUST be present.</t>
<t>Granting Domain: This TLV has a type of 0x0006. The domain which
granted the ticket. A string, up to 256 characters, each of which
must be a valid domain name character. The TLV has variable length.
This TLV MUST be present.</t>
<t>Granted-To Domain: This TLV has a type of 0x0007. The domain to
which the ticket is granted. A string, up to 256 characters, each of
which must be a valid domain name character. The TLV has a variable
length. This TLV MUST be present.</t>
<t>Epoch: This TLV has a type of 0x0008. It contains a 32 bit epoch
value. It is used to select a key. This TLV MUST be present.</t>
<t>Integrity: This TLV has a type of 0x0009. It contains a 160 bit
integrity value, computed using HMAC-SHA1. This TLV MUST be
present and MUST be the last TLV in the object.</t>
</list>
</t>
<t>The base64 encoding uses the base64url encoding from <xref target="RFC4648">RFC4648</xref>, with the exception of the pad
character, which is a "." instead of an "=". This ensures that the
output is a valid SIP token.</t>
<t>To compute the MAC, the following is done. First, the key is
obtained. The key is actually a 128 bit key, configured into the system.
The key, P, is then used to compute Km:</t>
<t>Km = HMAC-SHA1(P, S | Epoch)</t>
<t>Based on PBKDF2 from <xref target="RFC2898">PKCS #5</xref> with
HMAC-SHA1 as PRF and iteration count of 1. Where S is the 32 bit salt
and Epoch is the 32 bit Epoch, from the ticket. This produces a 160 bit
Km. The MAC is then computed as another HMAC-SHA1, over the entire
ticket up to but not including the Integrity itself, using Km as the
key. This produces the 160 bit MAC.</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>TBD - Register SIP Header</t>
<t>TBD - Form IANA registry for Ticket TLVs</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Patrice Bruno for his comments, suggestions and questions that helped to improve this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t>
</list>
</t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT"/>
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
<reference anchor="RFC2898">
<front>
<title>PKCS #5: Password-Based Cryptography Specification Version 2.0</title>
<author fullname="B. Kaliski" initials="B." surname="Kaliski">
<organization/>
</author>
<date month="September" year="2000"/>
<abstract>
<t>This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2898"/>
<format octets="68692" target="http://www.rfc-editor.org/rfc/rfc2898.txt" type="TXT"/>
</reference>
<reference anchor="RFC4122">
<front>
<title abbrev="UUID URN">A Universally Unique IDentifier (UUID) URN Namespace</title>
<author fullname="Paul J. Leach" initials="P." surname="Leach">
<organization>Microsoft</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<phone>+1 425-882-8080</phone>
<email>paulle@microsoft.com</email>
</address>
</author>
<author fullname="Michael Mealling" initials="M." surname="Mealling">
<organization>Refactored Networks, LLC</organization>
<address>
<postal>
<street>1635 Old Hwy 41</street>
<street>Suite 112, Box 138</street>
<city>Kennesaw</city>
<region>GA</region>
<code>30152</code>
<country>US</country>
</postal>
<phone>+1-678-581-9656</phone>
<email>michael@refactored-networks.com</email>
<uri>http://www.refactored-networks.com</uri>
</address>
</author>
<author fullname="Rich Salz" initials="R." surname="Salz">
<organization>DataPower Technology, Inc.</organization>
<address>
<postal>
<street>1 Alewife Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>
<phone>+1 617-864-0455</phone>
<email>rsalz@datapower.com</email>
<uri>http://www.datapower.com</uri>
</address>
</author>
<date month="July" year="2005"/>
<keyword>URN, UUID</keyword>
<abstract>
<t>This specification defines a Uniform Resource Name namespace for
UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally
Unique IDentifier). A UUID is 128 bits long, and can
guarantee uniqueness across space and time. UUIDs were originally
used in the Apollo Network Computing System and later in the Open
Software Foundation's (OSF) Distributed Computing Environment (DCE),
and then in Microsoft Windows platforms.</t>
<t>This specification is derived from the DCE specification with the
kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been
incorporated into this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4122"/>
<format octets="59319" target="http://www.rfc-editor.org/rfc/rfc4122.txt" type="TXT"/>
<format octets="82717" target="http://xml.resource.org/public/rfc/html/rfc4122.html" type="HTML"/>
<format octets="62931" target="http://xml.resource.org/public/rfc/xml/rfc4122.xml" type="XML"/>
</reference>
<reference anchor="RFC4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson">
<organization/>
</author>
<date month="October" year="2006"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<format octets="35491" target="http://www.rfc-editor.org/rfc/rfc4648.txt" type="TXT"/>
</reference>
<reference anchor="VIPR-OVERVIEW">
<front xmlns:xi="http://www.w3.org/2001/XInclude">
<title>Verification Involving PSTN Reachability:
Requirements and Architecture Overview</title>
<author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
<organization/>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization/>
</author>
<author fullname="Marc Petit-Huguenin" initials="M." surname="Petit-Huguenin">
<organization/>
</author>
<date day="1" month="April" year="2011"/>
<area>RAI</area>
<workgroup>dispatch</workgroup>
<abstract>
<t>
The Session Initiation Protocol (SIP) has seen widespread deployment
within individual domains, typically supporting voice and video
communications. Though it was designed from the outset to support
inter-domain federation over the public Internet, such federation has
not materialized. The primary reasons for this are the complexities of
inter-domain phone number routing and concerns over security. This
document reviews this problem space, outlines requirements, and then
describes a new model and technique for inter-domain federation with
SIP, called Verification Involving PSTN Reachability (ViPR). ViPR
addresses the problems that have prevented inter-domain federation
over the Internet. It provides fully distributed inter-domain routing
for phone numbers, authorized mappings from phone numbers to domains,
a new technique for automated VoIP anti-spam, and privacy of number
ownership, all while preserving the trapezoidal model of SIP.
</t>
</abstract>
<note title="Legal">
<t>This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</note>
</front>
<seriesInfo name="Internet-Draft" value="draft-jennings-vipr-overview-00"/>
<format target="http://www.ietf.org/internet-drafts/draft-jennings-vipr-overview-00.txt" type="TXT"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="VIPR-VAP">
<front xmlns:xi="http://www.w3.org/2001/XInclude">
<title> Verification Involving PSTN Reachability:
The ViPR Access Protocol (VAP)</title>
<author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
<organization/>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization/>
</author>
<author fullname="Marc Petit-Huguenin" initials="M." surname="Petit-Huguenin">
<organization/>
</author>
<date day="1" month="April" year="2011"/>
<area>RAI</area>
<workgroup>dispatch</workgroup>
<abstract>
<t> Verification Involving PSTN Reachability (ViPR) is a
technique for inter-domain SIP federation. ViPR hybridizes the
PSTN, P2P networks, and SIP, and in doing so, addresses the
phone number routing and VoIP spam problems that have been a
barrier to federation. The ViPR architecture uses a server, the
ViPR server, which performs P2P and validation services on
behalf of call agents, which acts as clients to the
server. Such an architecture requires a client/server protocol
between call agents and the ViPR server. That protocol, defined
here, is called the ViPR Access Protocol (VAP).</t>
</abstract>
<note title="Legal">
<t>This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</note>
</front>
<seriesInfo name="Internet-Draft" value="draft-jennings-vipr-vap-00"/>
<format target="http://www.ietf.org/internet-drafts/draft-jennings-vipr-vap-00.txt" type="TXT"/>
</reference>
</references>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="Modifications between vipr-00 and dispatch-03">
<t>
<list style="symbols">
<t>Moved to new Working Group.</t>
</list>
</t>
</section>
<section title="Modifications between dispatch-03 and dispatch-02">
<t>
<list style="symbols">
<t>Added terminology section.</t>
<t>Nits</t>
<t>Shorter I-Ds references.</t>
<t>Changed issued-to to granted-to.</t>
<t>Fixed the ABNF.</t>
<t>The tickets is used in all dialog forming requests, not only INVITE.</t>
<t>The Number TLV has a variable length.</t>
<t>The Integrity TLV MUST be the last in the object.</t>
<t>Fixed a discrepancy in the epoch length.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 22:23:54 |