One document matched: draft-rosenberg-dispatch-vipr-sip-antispam-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?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-rosenberg-dispatch-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></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>
<date day="9" month="November" year="2009" />
<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 a 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 techqnique for
blocking spam - a SIP caller is only authorized when they're
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"></xref> 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="I-D.rosenberg-dispatch-vipr-overview"></xref> 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="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 issued-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 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 E164, the request must
be rejected with a 403. Only E164 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 routs and the information needed to construct the ticket
from the <xref target="I-D.draft-rosenberg-dispatch-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>
<t>This header field MUST be utilized in all INVITE requests and all
out-of-dialog requests. It is not utilized in responses. The
ticket-value is a 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"></xref>. 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 E164 number, included the "+", which may be called using this
ticket. 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 nodeID 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 16 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.</t>
</list></t>
<t>The base64 encoding uses the bas64url 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>
</middle>
<back>
<references title="Normative References">
<reference anchor="I-D.rosenberg-dispatch-vipr-overview">
<front>
<title abbrev="VIPR Overview">Verification Involving PSTN
Reachability: Requirements and Architecture Overview</title>
<author fullname="Jonathan Rosenberg" initials="J.R."
surname="Rosenberg">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city>Edison</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>
<date day="2" month="November" year="2009" />
<area>RAI</area>
<workgroup>dispatch</workgroup>
</front>
</reference>
<?rfc include="reference.RFC.2898"?>
<?rfc include="reference.RFC.4122"?>
<?rfc include="reference.RFC.4648"?>
</references>
<references title="Informative References">
<reference anchor="I-D.draft-rosenberg-dispatch-vipr-vap">
<front>
<title abbrev="VIPR VAP Protocol">Validation Access Protocol
(VAP)</title>
<author fullname="Jonathan Rosenberg" initials="J.R."
surname="Rosenberg">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city>Edison</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>
<date day="2" month="November" year="2009" />
<area>RAI</area>
<workgroup>dispatch</workgroup>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:20:43 |