<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!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'>
<!ENTITY RFC2459 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2459.xml'>
<!ENTITY I-D.darilion-sip-e164-enum PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.darilion-sip-e164-enum.xml'>
]>


<rfc ipr="full3978" docName="draft-schwartz-sip-e164-ownership-01.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@nsn.com</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>This document largely relies on the terminology introduced by <xref target="RFC4474"
         />.</t>
      </section>

      <!-- ******************************************************************** -->

      <section title="The End-to-End Picture">


         <t>In the context of "ownership" it is hard to speak of the end-to-end picture without
            first identifying four possible use-cases for this e2e communication. The first two
            start AND end on IP and the second two start OR end on IP. Please refer to <xref
               target="fig1"/> below for the first two cases.</t>



         <t>

            <figure anchor="fig1" title="Federation based IP-to-IP Communication">

               <artwork><![CDATA[
                                      --------
                                  ////        \\\\
           +------------+        |      PSTN      |------------+
           |  IP-based  |        |                |            |
           |  SIP Phone |<--+     \\\\        ////       +------------+
           |  of Bob    |   |         --------           | PSTN-based |
           |+19175551234|   |             ^  |           |   Phone    |
           +------------+   |             |  |           |  of Carl   |
                            |             |  |           |+15167654321|
  +------------+            |             |  |           +------------+
  |  IP-based  |            |             |  |            
  |  SIP Phone |       ------------       |  |      +------------+
  |  of Alice  |      /            \      |  |      |  IP-based  |  
  |+12121234567|    //  Federation  \\    |  |      |   Phone    |  
  +------------+   //                \\\  |  v      |  of Dan    |      
      |          ///  - - - - - - - -   -----       |+12039994321|    
      |       ////                          \\\\    +------------+   
      |      /                                  \       ^
      |     |                                    |      |
      +---->|              IP-based              |------+
            |              Network               |
             \                                  /
              \\\\                         ////
                  -------------------------
                                   ]]></artwork>

            </figure>

         </t>



         <section title="IP-IP Case">

            <t>The first use case is that of a call that originates and terminates on the IP network
               without ever touching the PSTN but that uses E.164 addressing instead of the
               preferred URI. This case is quite prevalent today in some of the private peering
               federations. These federations are seen as a first choice (if I can terminate to an
               IP great - otherwise let me know and I will failover or route advance to the PSTN)
               for outbound routing of E.164 numbers. Since these federations are being used in
               conjunction with the PSTN it is quite logical that the addressing will be E.164 and
               not SIP URI based.</t>



            <t>As can be seen in <xref target="fig1"/> if Alice calls Bob the call will be IP based
               end-to-end while if she calls Carl it will exit to the PSTN. Ownership, therefore
               needs to be considered in the context of this use-case. Does the COR play any role in
               this case? Can these numbers be treated as private plan numbers placing all onus
               solely on the respective VSPs servicing Alice and Bob? </t>

         </section>



         <section title="IP-PSTN-IP Case">

            <t>In this case Dan’s VSP is not a member of the federation that is shared by Alice and
               Bob and as such so far as Alice is concerned Dan is not accessible via IP.</t>



            <t>What considerations should be discussed in this case? In reality both origination and
               termination are IP, however, the transit is PSTN and who know what happens in that
               world. What is the notion of ownership here? Since any "domain" information will be
               stripped by the PSTN is there any advantage whatsoever to including it?</t>

         </section>


         <section title="PSTN-to-IP Case">


            <t>Consider <xref target="fig3"/> where Carl is using a PSTN phone and initiates calls
               to Alice. Alice is using an IP-based phone. The call of Carl traverses the PSTN and
               enters the Internet via some PSTN/VoIP gateway. This gateway applies SIP Identity to
               the call. What does the signed identity mean? Can the gateway in typical deployment
               cases verify the caller id in any meaningful way? Later, when Alice's SIP UA receives
               the call it may run some authorization procedure against the received identity. It
               may "outsource" the decision to the user by just displaying anything received. Unless
               the calling domain itself operates the gateway it is less likely that the domain part
               that may have been added to the E.164 number contains information that can be
               associated meaningfully with the calling party. For example, a bank might use the
               PSTN within their branches and operate their own gateway to the IP-based network and
               hence the domain part of the identity could in fact indicate, for example,
               mybank-example.com. If this gate is operated by an entirely different entity then the
               domain might show something like gateway.operator-example.com. Without a binding
               between the E.164 number and the domain of the authentication service attacks are
               possible. </t>
            <t>
               <figure anchor="fig3" title="PSTN-to-IP Communication">
                  <artwork><![CDATA[
             --------
         ////        \\\\
     +->|      PSTN      |--+
     |  |                |  |
     |   \\\\        ////   |
     |       --------       |
     |                      |
     |                      v
     |                 +----+-------+
 +---+------+          |PSTN / VoIP |              +-----+
 |PSTN Phone|          |Gateway     |              |SIP  |
 |of Carl   |          +----+-------+              |UA   |
 +----------+               |                      |Alice|
                          Invite                   +-----+
                            |                         ^
                            V                         |
                       +-------------+              Invite
                       |VoIP         |                |
                       |Service      |   Invite   +-------+
                       |Provider(s)  |----------->+       |
                       +-------------+            |       |
                                                  |Verif. |
                                                  |Service|
                                                  |       |
                                                  +-------+
                                                 |---------|
                                                    called
                                                    party
                                                    domain
                     ]]></artwork>
               </figure>
            </t>

         </section>


         <section title="IP-to-PSTN Case">

            <t> Consider <xref target="fig4"/> where Alice calls Carl. Carl uses a PSTN phone and
               Alice an IP-based phone. When Alice initiates the call the E.164 number needs to get
               translated, for example using ENUM, to a SIP URI and subsequently to an IP address.
               The call of Alice traverses her VoIP provider where the SIP Identity signature is
               added. It then hits the PSTN/VoIP gateway. What would the gateway do with the SIP
               Identity header? Can he do anything meaningful with it? Ideally, Alice would like to
               know whether she, for example, talks to someone at her bank rather than to someone
               intercepting the call. Would Connected Identity help her? What would the quality of
               the subsequently established media security between the gateway and Alice's SIP UA
               be? </t>
            <t>
               <figure anchor="fig4" title="IP-to-PSTN Communication">
                  <artwork><![CDATA[
  +-------+                                        +-----+  -C
  |PSTN   |                                        |SIP  |  |a
  |Phone  |<----------------+                      |UA   |  |l
  |of Carl|                 |                      |Alice|  |l
  +-------+                 |                      +-----+  |i
             ---------------------------              |     |n
         ////                           \\\\          |     |g
        |               PSTN                |       Invite  |
        |                                   |         |     |P
         \\\\                           ////          |     |a
             ---------------------------              |     |r
                            ^                         |     |t
                            |                         v     |y
                       +------------+             +--------+|
                       |PSTN / VoIP |<--Invite----|VoIP    ||D
                       |Gateway     |             |Service ||o
                       +------------+             |Provider||m
                                                  |   Y    ||a
                                                  +--------+|i
                                                            -n
            ]]></artwork>
               </figure>
            </t>

         </section>


         <!--

         <t><xref target="fig1"/> highlights two 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 the calling party?</t>
               <t>Can the authenticated identity be used for authorization and what is the quality
                  of it? 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 or E.164 number usage.
            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]. 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>When the username and the domain name are tightly bound together then there is no
            question whether a particular authentication service operating at a specific domain is
            administratively reponsible for a specific username part. However, if this binding is
            relaxed or even removed then there is a question of which authentication service is
            allowed to warrant for which usernames. </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>The problem is compounded by the fact that there may be more than one legitimate owner.
            Consider if you will the case where an enterprise (PBX) uses a Voice Service Provider
            (VSP) for IP communication services and the VSP acquires E.164 numbers from an exchange
            who in turn acquires the numbers from the Carrier of Record (COR). This is illustrated
            in <xref target="ownership-example"/>.</t>

         <figure anchor="ownership-example" title="Will the real 'Owner' please stand up?">
            <preamble/>

            <artwork align="center"><![CDATA[
+-----------------------------------+
|                COR                |
|  +-----------------------------+  |
|  |      E.164 Exchnage         |  |
|  |   +---------------------+   |  |
|  |   |        VSP          |   |  |
|  |   |   +-----------+     |   |  |
|  |   |   |    PBX    |     |   |  |
|  |   |   +-----------+     |   |  |
|  |   |                     |   |  |
|  |   +---------------------+   |  |
|  |                             |  |
|  +-----------------------------+  |
|                                   |
+-----------------------------------+
        ]]></artwork>
         </figure>

         <t>If one was to compare this to the path validation approach used in chain-of-trust
            certificate validation schemes, the COR would be the trust anchor and would sign the
            exchange cert who in turn would sign the VSP cert who in turn would sign the PBX cert
            which would be used in 4474 <xref target="RFC4474"/>. While the steps needed to traverse
            up the chain and check all the certs are seemingly quite expensive (performance wise for
            calls at least) one must realize that calling patterns are quite determanistic and as
            such caching is believed to alleviate this issue and make it tolerable. Without this
            chain-of-trust approach it is hard to give credibility to any "ownership" assertion.</t>

         <t>Looking at "ownership" in this way may necessitate an Authority Information Access (AIA)
               <xref target="RFC2459"/> equivalent so that a URI scoping an E.164 number would
            provide the pointer back up the tree for complete validation. If the number is ported
            from one COR to another all that would be needed is to modify the AIA information
            starting with the anchor and down to where relevant.</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. 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. Imagine if the SIP Identity authentication service would have to sign
            calling parties SIP URIs that do not belong to the domain the authentication service is
            responsible for. The corresponding verification check would be far more complicated --
            the authentication service would have to show that it is indeed entitled to act on
            behalf of someone else.</t>

         <t>A couple of other ownership approaches have been used in IETF protocols. These examples
            are not meant to claim that the problem is easy to solve (in the style of just pick one)
            or that there is even a satisfactory solution at all. They are just listed to illustrate
            the different flavors and the quality of the warrants:</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>Needless to say 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>The authors argue that the problem scope and the envisioned technical properties are not
            yet understood enough. Furthermore, it is necessary to investigate deployment challenges
            imposed by the existing infrastructure and deployment incentives for various
         approaches.</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>We would like to thank Joel M. Halpern, Paul Kyzivat, Dale Worley, Jonathan Rosenberg,
            and Henry Sinnreich for their feedback on the mailing list.</t>
      </section>

      <!-- ****************************************************************************** -->

   </middle>

   <back>

      <references title="Normative References"> &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;
         &RFC2459; &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; &I-D.darilion-sip-e164-enum; </references>

   </back>

</rfc>
