One document matched: draft-schwartz-sip-e164-ownership-00.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY RFC4474 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml'>
<!ENTITY RFC4871 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4871.xml'>
<!ENTITY RFC3323 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3323.xml'>
<!ENTITY RFC3966 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml'>
<!ENTITY RFC3761 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3761.xml'>
<!ENTITY I-D.elwell-sip-e164-problem-statement PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.elwell-sip-e164-problem-statement.xml'>
<!ENTITY I-D.wing-sip-e164-rrc PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-sip-e164-rrc.xml'>
<!ENTITY I-D.ietf-sip-saml PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-saml.xml'>
<!ENTITY RFC3972 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml'>
<!ENTITY RFC3219 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3219.xml'>
<!ENTITY RFC3554 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3554.xml'>
]>
<rfc ipr="full3978" docName="draft-schwartz-sip-e164-ownership-00.txt" category="info">
<?rfc toc='yes' ?>
<?rfc tocompact='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<?rfc sortrefs="no" ?>
<front>
<title abbrev="E.164 Ownership Problem Statement">E.164 Ownership Problem Statement</title>
<author initials="D." surname="Schwartz" fullname="David Schwartz">
<organization>XConnect</organization>
<address>
<postal>
<street>Malcha Technology Park</street>
<city>Jerusalem</city>
<region/>
<code>96951</code>
<country>Israel</country>
</postal>
<email>dschwartz@xconnect.net</email>
</address>
</author>
<!--
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
-->
<author fullname="Hadriel Kaplan" initials="H." surname="Kaplan">
<organization>Acme Packet</organization>
<address>
<postal>
<street>71 Third Ave.</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>USA</country>
</postal>
<phone/>
<facsimile/>
<email>hkaplan@acmepacket.com</email>
<uri/>
</address>
</author>
<!--
<author initials="J." surname="Elwell" fullname="John Elwell">
<organization>Siemens</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country/>
</postal>
<phone/>
<email/>
</address>
</author>
<author initials="K." surname="Fischer" fullname="Kai Fischer">
<organization>Siemens</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country/>
</postal>
<phone/>
<email/>
</address>
</author>
-->
<author initials="K." surname="Darilion" fullname="Klaus Darilion">
<organization abbrev="enum.at"> enum.at GmbH </organization>
<address>
<postal>
<street>Karlsplatz 1/9</street>
<city>Wien</city>
<code>A-1010</code>
<country>Austria</country>
</postal>
<phone>+43 1 5056416 36</phone>
<email>klaus.darilion@enum.at</email>
<uri>http://www.enum.at/</uri>
</address>
</author>
<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@gmx.net</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<date year="2008"/>
<area>RAI</area>
<workgroup>SIP</workgroup>
<keyword>Authentication</keyword>
<keyword>SIP</keyword>
<keyword>Signature</keyword>
<abstract>
<t>When a call travels end-to-end relayed from the PSTN to SIP then problems occur with
E.164 number ownership. Additionally, there are security challenges when the
PSTN-VoIP gateway has to authenticate and authorize the calling party. Without
addressing these two aspects the overall security story is weak or non-existent.
This document aims to investigate these two aspect; it does, however, not
investigate current E.164 number handling with RFC 4474 ("SIP Identity"). Such an
analysis is provided by other documents already.</t>
</abstract>
</front>
<middle>
<!-- ***************************************************************************** -->
<section anchor="intro" title="Introduction">
<t> RFC 4474 <xref target="RFC4474"/> defines a mechanism whereby an authentication
service asserts the identity of a SIP UAC and determines whether he or she is
authorized to use that identity. The authentication service then computes a hash
over some particular headers, including the From header field and the bodies in the
message. This hash is signed with the certificate for the domain and inserted in the
'Identity' header field in the SIP message. The proxy also inserts a companion
header field, Identity-Info, that tells the verifying party how to acquire its
certificate, in case it is not yet known already. </t>
<t> When the verifier receives the SIP message, it verifies the signature provided in
the Identity header, and thus can determine whether the domain indicated by the host
portion of the AoR in the From header field authenticated the user, and permitted
the user to assert that From header field value. </t>
<t> The use of phone numbers with SIP was introduced with the TEL URL scheme <xref
target="RFC3966"/> whereby domain names were not used with the phone numbers.
SIP URIs always have domain names. In SIP <xref target="RFC3261"/>, a translation
between SIP URIs and TEL URLs is described: when translating from a SIP URI to a TEL
URL, the domain name from the SIP URI is simply dropped. When translating in the
other direction (or simply generating a SIP URI from an E.164 number <xref
target="E164"/>) it is not clear how to populate the domain name.</t>
<t>When SIP Identity <xref target="RFC4474"/> is applied to E.164 numbers then there is
the question what the identity assertion actually means. Additionally, the usage of
the domain for an E.164 number causes problems, as described in <xref
target="I-D.elwell-sip-e164-problem-statement"/>. This document will, however,
not focus on this aspect. Instead, we investigate the overall end-to-end security
story and the ownership problem for E.164 numbers. </t>
</section>
<!-- ******************************************************************** -->
<section title="Terminology">
<t>In this document, several words are used to signify the requirements of the
specification. These words are often capitalized. 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="The End-to-End Picture">
<t>Consider <xref target="fig1"/> where two end points, Bob and Joe, initiate calls to
Alice. Alice is using an IP-based phone and the same is true for Joe. The call of
Joe and Bob towards Alice traverse the PSTN; Bob is using a PSTN phone and the call
enters the Internet via a PSTN/VoIP gateway. Joe's call traverses the PSTN, for
example, because Joe's VoIP provider does not have a peering agreement with the
called party domain and uses the PSTN as a way to interconnect VoIP networks. This
is a common way of interacting between VoIP providers today. </t>
<t>
<figure anchor="fig1" title="PSTN to SIP Communication">
<artwork><![CDATA[
--------
//// \\\\
+->| PSTN |--+
| | | |
| \\\\ //// |
| -------- |
| ^ |
| | v
| | +----+-------+
+---+------+ | |PSTN / VoIP | +-----+
|PSTN Phone| | |Gateway | |SIP |
|of Bob | | +----+-------+ |UA |
+----------+ | | |Alice|
| Invite +-----+
| | ^
| V |
+----------+-+ +-------------+ Invite
|VoIP / PSTN | |VoIP | |
|Gateway | |Service | Invite +-------+
+----------+-+ |Provider(s) |----------->+ |
^ +-------------+ | |
| |Verif. |
| |Service|
+---------+ | | |
|IP-based | | +-------+
|SIP Phone| | |---------|
|of Joe | | called
+---------+ | party
| | domain
| -----
| //// \\\\
| / \
| | |
+---->| IP-based |
| Network |
\ /
\\\\ ////
-----
]]></artwork>
</figure>
</t>
<t><xref target="fig1"/> raises two important questions: </t>
<t>
<list style="numbers">
<t>How does the authentication service (for example an entity that is co-located
with the PSTN/VoIP gateway) authenticate and authorize the calling party?</t>
<t>How does the verification service determine ownership of an E.164 number?</t>
</list>
</t>
<t><xref target="q1"/> investigates the first question in more detail whereas <xref
target="q2"/> addresses the second question.</t>
</section>
<!-- ******************************************************************** -->
<section anchor="q1" title="Authenticating and Authorizing the Calling Party Identity">
<t>RFC 4474 rightfully makes some important assumptions about the behavior of the
authentication service that contribute significantly to the security of the overall
system. While some assumptions seem to be obvious for SIP usage, they are less
obvious when considering them in relationship with a PSTN interworking. Section 4 of
<xref target="RFC4474"/> says: </t>
<t>
<list style="empty">
<t>"The authentication service authenticates Alice (possibly by sending a Digest
authentication challenge) and validates that she is authorized to assert the
identity that is populated in the From header field. This value may be
Alice's AoR, or it may be some other value that the policy of the proxy
server permits her to use. <vspace blankLines="1"/> ... <vspace
blankLines="1"/>The proxy, as the holder of the private key of its
domain, is asserting that the originator of this request has been
authenticated and that she is authorized to claim the identity (the SIP
address- of-record) that appears in the From header field. "</t>
</list>
</t>
<t>The crutial question therefore is: In the generic case is the authentication service
able to authenticate the caller-ID used in the PSTN and to authorize it's usage? </t>
<t>There are problems with this step: </t>
<t>
<list style="numbers">
<t>The PSTN builds on a walled garden with a chain-of-trust security model. This
is "nice" as long as the participating parties are indeed honest.
Unfortunately, this is not true anymore (and has not been the case for a
long time already) [add-references-to-examples]. Caller-ID spoofing is
common and even transit providers are not trustworthy either. </t>
<t>A call originated on the PSTN is often times routed to a PSTN/VoIP gateway.
That PSTN gateway is operated by the owner of the called number, rather than
the owner of the calling number.</t>
</list>
</t>
</section>
<!-- ******************************************************************** -->
<section anchor="q2" title="Verifying Ownership: What does it mean? ">
<t>Imagine a verification service at Alice's VoIP provider network receives a SIP
message with an 'Identity' and an 'Identity-Info' header.</t>
<t>How would this verification service determine whether the signer of the message is
indeed authorized to claim ownership?</t>
<t>Ownership is an artificial construct but one could compare it with an oracle that
returns the name of a domain when asked who is authoritative for using a particular
E.164 number.</t>
<t>There are various owership verification steps that got used in the IETF within other
protocols. RFC 4474 <xref target="RFC4474"/>, for example, uses the following
verification step for SIP URIs: </t>
<t>
<list style="empty">
<t>"6. Verifier Behavior<vspace blankLines="1"/> Step 2: <vspace blankLines="1"/>
<vspace blankLines="1"/> The verifier MUST follow the process described in
Section 13.4 to determine if the signer is authoritative for the URI in the
From header field. <vspace blankLines="1"/> 13.4. Domain Names and
Subordination<vspace blankLines="1"/>
<vspace blankLines="1"/> When a verifier processes a request containing an
Identity-Info header, it must compare the domain portion of the URI in the
From header field of the request with the domain name that is the subject of
the certificate acquired from the Identity-Info header."</t>
</list>
</t>
<t>This is a concept of referential integrity where information of the protocol (in this
case the identity) is matched against information from the certificate. Still, the
signer and the verifier need to have a trust anchor in common. There are additional
aspects about the detailed matching procedure that are described in Section 13.4 of
<xref target="RFC4474"/>. </t>
<t>Unfortunately, this simple authorization check cannot be used with E.164 numbers
because of the missing domain concept in the identifier itself and because of number
portability.</t>
<t>A couple of other ownership approaches have been used in IETF protocols. A few
examples below: </t>
<t>
<list style="hanging">
<t hangText="Return Routability Check:">A form of check is to exploit the
topological properties of identifier routing and the possible placements of
adversaries with respect to a certain message interaction. RRT and various
other forms fall into that category. An example can be found in <xref
target="I-D.wing-sip-e164-rrc"/>.<vspace blankLines="1"/>
</t>
<t hangText="Authorization Certificates:"><vspace blankLines="1"/> A form of
check is to use authorization certificates. The basic idea is that one would
trust the entity that creates the authorization certificate (most likely in
a hierarchical form) then you also trust its content. SIP-SAML (see <xref
target="I-D.ietf-sip-saml"/>) and <xref target="RFC3554"/> belong to
this category. When the identity of the certificate is constructed in a
suitable way then together with a delegated signing the same effect could be
accomplished.<vspace blankLines="1"/>
</t>
<t hangText="Distributed Databases:"><vspace blankLines="1"/> Another form of
mechanism is to use an out-of-band database lookup, for example using the
DNS, in order to verify that the entity which uses the private key for
creating the SIP Identity header is authorized to attach the corresponding
public key to the this distributed database. The identity would be used for
the lookup to the database and the security of the system relies on ensuring
that only those entities add the public key that are also owner of the
corresponding E.164 number. An example of such an approach can be found in
<xref target="I-D.darilion-sip-e164-enum"/>. The usage of TRIP <xref
target="RFC3219"/> (with extensions with information about E.164 numbers
that are authorized for usage by a specific provider) has been discussed as
well.<vspace blankLines="1"/>
</t>
<t hangText="Cryptographic Addresses and Hash Chains:">
<vspace blankLines="1"/> These mechanisms utilize a temporal property by
creating a binding between the public key (or values from a hash chain) and
the identity be verified by re-computing the hash value and by comparing the
hash with the identifier. These mechanisms have found some excitment with
protocol work at lower layers (see, for example, <xref target="RFC3972"
/>).</t>
</list>
</t>
<t>It is quite obvious that each mechanism has different scalability, security and
deployment properties.</t>
</section>
<!-- ******************************************************************** -->
<section anchor="security" title="Security Considerations">
<t>With the work on this subject it is important to keep two quotes in mind: </t>
<t>
<list style="symbols">
<t>"The security of a system is as good as the weakest link."</t>
<t>"If you think cryptography is the solution to your problem, you don’t know
what your problem is." --- Roger Needham </t>
</list>
</t>
<t>We are still in an early phase to properly understand the problem domain even though
there are a couple of TECHNICAL solution proposals available to address the
ownership question. These technical approaches do, however, not help when there is
no deployment incentives. These approaches also do not help with the security of the
overall system when the identity of the calling party cannot be verified by the
authentication service. </t>
<t>As such, it is too early to conclusively argue that an RFC 4474 alike authentication
service should actually attempt to offer a solution for E.164 numbers even though
they are heavily used in today's networks.</t>
</section>
<!-- ****************************************************************************** -->
<section anchor="contributors" title="Contributors">
<t>We would like to thank the following individuals for their contributions to this
document: <list style="symbols">
<t>Dan Wing</t>
<t>John Elwell</t>
<t>Kai Fischer</t>
</list>
</t>
</section>
<!-- ****************************************************************************** -->
<section anchor="iana" title="IANA Considerations">
<t>There are no IANA considerations with this document.</t>
</section>
<!-- ****************************************************************************** -->
<section anchor="acknow" title="Acknowledgments">
<t>Add your name here. </t>
</section>
<!-- ****************************************************************************** -->
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC3261; &RFC4474;
&RFC4871; &RFC3966; &RFC3761;</references>
<references title="Informative References"> &I-D.elwell-sip-e164-problem-statement;
&I-D.ietf-sip-saml; &I-D.wing-sip-e164-rrc; &RFC3972; &RFC3219;
&RFC3554; <reference anchor="E164">
<front>
<title abbrev="E.164">The international public telecommunication numbering plan</title>
<author initials="" surname="" fullname="">
<organization abbrev="ITU-T">ITU-T</organization>
</author>
<date month="May" year="1997"/>
</front>
<seriesInfo name="Recommendation" value="E.164"/>
</reference> &RFC3323; <reference anchor="I-D.darilion-sip-e164-enum">
<front>
<title>E.164 Ownership using Public Keys stored in ENUM</title>
<author initials="K." surname="Darilion" fullname="Klaus Darilion ">
<organization>enum.at GmbH </organization>
</author>
<date month="Feb" year="2008"/>
</front>
<seriesInfo name="Info" value="draft-darilion-sip-e164-enum-00.txt"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:39:41 |