One document matched: draft-darilion-sip-e164-enum-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'>
]>
<rfc ipr="full3978" docName="draft-darilion-sip-e164-enum-00.txt" category="std">
<?rfc toc='yes' ?>
<?rfc tocompact='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<front>
<title abbrev="E.164 Ownership using ENUM">E.164 Ownership using Public Keys stored in ENUM</title>
<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 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 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>Domainkeys</keyword>
<keyword>Signature</keyword>
<abstract>
<t>To determine which domain is allowed to claim ownership of a certain telephone number
is difficult. This may cause problems when to authenticate endpoints that use
telephone number URIs and domain names in their From address. This document
investigates a proposal that stores a public key below the corresponding ENUM tree
in the DNS. The verifier can determine ownership by performing an ENUM lookup to
retrieve the public key from the DNS and to use it for verifying the signature
created as part of the SIP Identity mechanism.</t>
<t>This document is a contribution to the ongoing discussion on RFC 4474 when used in
combination with E.164 numbers. </t>
</abstract>
</front>
<middle>
<!-- ***************************************************************************** -->
<section anchor="intro" title="Introduction">
<t> RFC 4474 <xref target="RFC4474"/> defines a mechanism whereby an authentication
service authenticates a SIP UAC (possibly by sending a Digest authentication
challenge) and verifies whether he or she is authorized to use the identity that is
populated in the From header field. 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. </t>
<t> 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 a specific user is
authorized to claim the identity (the SIP address-of-record) that appears in the
From header field. 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) it is not
clear how to populate the domain name. </t>
<t>When SIP Identity <xref target="RFC4474"/> is applied to E.164 numbers <xref
target="E164"/> then there is the question what the identity assertion actually
means. Additionally, the usage of the domain for an E.164 number is not useful as
described in <xref target="I-D.elwell-sip-e164-problem-statement"/>. This document
does not make use of a domain field attached to an E.164 number.</t>
<t>
<list style="empty">
<t>******************************************************************</t>
<t> The authors of this document do not claim that the question of what
ownership of E.164 numbers means is sufficiently well understood at this
point to be fully confident that any solution actually helps to improve the
current state-of-the-art. In fact, the entire end-to-end security story when
a call originates in the PSTN and terminates somewhere on the Internet may
weaken the security of the call to such an extend that additional security
mechanisms applied to the communication on the Internet leg of the call may
not improve the overall security based on "security is as good as the
weakest link". However, strawman proposals (like this one) might help to
better understand the different forms of E.164 address ownership. The
authors have received a large number of intesting comments after
distributing an initial proposal. </t>
<t>******************************************************************</t>
</list>
</t>
<t>This document investigates the ability to store a public key in the ENUM database.
The private key corresponding to that public key is then used by the authentication
service to compute the digital signature for the 'Identity' header. Additionally, an
indication is provided for the verifier inside the Identity-Info header so that it
is apparent that the public key is not available at a given URI but rather in the
DNS used by ENUM. When the verifier receives a SIP message that contains the
'Identity' header instead of obtaining the certificate it performs a DNS lookup to
determine the public key used for the specific E.164 number. Possessing the public
key stored with the E.164 number allows verification of the digital signature.</t>
<t>From a design point of view we would like to make the following note: </t>
<t>
<list style="empty">
<t>This document does not define new SIP headers. Instead, it re-uses existing
headers from the SIP Identity specification. The 'Identity-Info' header is
reused to convey a so-called selector and the ENUM root. Both are required
for the verification procedure. The selector allows the authentication
service to support multiple concurrent public keys per signing domain and
the ENUM root allows to use different ENUM trees. This document suggests to
store the selector and the ENUM root as a URI in the 'Identity-Info' even
though a new and more flexible header is already required by the SIP SAML
specification.</t>
</list>
</t>
<t>To summarize the proposed changes; this document suggests an alternative method for
storing public keys, namely one based on the DNS in relationship to the ENUM
database. This method is conceptually similar to the approach used by DKIM <xref
target="RFC4871"/>. As a consequence, the mechanism to look-up the public key by
the verifier is different to the one proposed in <xref target="RFC4474"/>. The
suggested modifications are intentially kept at a minimum and only applicable when
an E.164 number is signed by an authentication service.</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 anchor="enum" title="ENUM">
<t> ENUM comes in different deployment variations. The incentives for storing public
keys in ENUM with these deployments are different. Mostly, they can be distinguished
by the root domain and whether access is restricted or unrestricted.</t>
<section title="User ENUM">
<t>User ENUM is defined in <xref target="RFC3761"/>. It uses the root domain
e164.arpa and access is not restricted. The right to provison DNS records is
given to the user of the corresponding E.164 number.</t>
<t>Use cases for putting the public key into user ENUM are the following. A user who
has registered its E.164 number into ENUM and has its own SIP infrastructure
(like companies have) or users utilizing their own open SIP infrastructure
(similar to users running an SMTP server).</t>
</section>
<section title="Infrastructure ENUM">
<t>There is no exact definition for Infrastructure ENUM (also called Carrier ENUM).
Infrastrucure ENUM is often understood as a public accessible ENUM tree (for
example ie164.arpa) where the "carrier-of-record" (the carrier which provide
telephony service to the end-user) is allowed to provision the DNS records. It
can also be seen as federations of private ENUM. </t>
<t>The use case for infrastructure ENUM is similar to user ENUM except that now
carriers are able to relate the "carrier of record" to the E.164 number. For
example, if a call is routed from carrier A to carrier B via transit carrier T,
T will trust A and B will trust T. There is no way for B to verify that the
caller is really allowed to use the indicated caller id.</t>
</section>
<section title="Private ENUM trees">
<t>Private ENUM trees choose just any available domain as root domain (e.g.,
e164.example.com) and provide ENUM services below this root domain. Whether
access is restricited or not, and the policy for provisioning of DNS records, is
defined by the holder of that domain. An example of a private ENUM tree with
restricted access is the 3GPP ENUM tree (e164enum.net).</t>
<t>Use cases are similar to before, except that the owner of the root domain can
decide who is allowed to use the ENUM tree. Furthermore, private ENUM trees can
be used if user ENUM is not available in the respective country (for example by
using nrenum.net).</t>
</section>
<t>The main drawback of this proposal is the fact that public ENUM does not enjoy a lot
of deployment (see http://enumdata.org/). This document is, however, particularly
useful for environments that make use of public ENUM. Private and infrastructure
ENUM only need SIP Identity alike mechanisms when interacting with the "external"
world since they follow a sort of wallet garden model with a chain-of-trust. There
is non-neglectable deployment incentive challenge. As such, this proposal will live
or die with the ability to come up with a lucrative deployment story.</t>
</section>
<!-- ************************************************************************** -->
<section anchor="authbehave" title="Authentication Service Behavior">
<t> The authentication service behavior proposed in this document is almost identical to
the authentication service described in <xref target="RFC4474"/>. </t>
<t>Thus, the authentication service behavior is identical to the description in Section
5 of <xref target="RFC4474"/> when TEL URIs are used with the following addition for
step 4: </t>
<t>
<list style="empty">
<t> When a TEL URI scheme is used in context of SIP Identity then the
'Identity-Info' header field does not contain a URI pointing to a
certificate but rather contains the DomainKeys selector and the ENOM root
domain since the procedure described in <xref target="verifybehave"/> allows
the verifier to determine the location of the public key associated with a
particular TEL URI. </t>
</list>
</t>
<t>The mechanism for storing a public key in the DNS is re-used from DKIM <xref
target="RFC4871"/>.</t>
</section>
<!-- ****************************************************************************** -->
<section anchor="verifybehave" title="Verifier Behavior">
<t>When a verifier receives a SIP message containing an Identity-Info header, it may
inspect the signature to verify the identity of the sender of the message.
Typically, the results of a verification are provided as input to an authorization
process which is outside the scope of this document. If an Identity-Info header is
not present in a request, and one is required by either local policy (for example,
based on a per-sending-domain policy, or a per-sending-user policy) or remote
policy, then 'Use Identity Header' response code MUST be sent. </t>
<t> The steps executed by the verifier are outlined in Section 6 of <xref
target="RFC4474"/> with the exception that step 1 is different primarily because
SIP Identity relies on certificates whereas this document stores public keys in the
DNS. The following paragraph replaces the text the text in Section 6/step 1 of <xref
target="RFC4474"/>. This document does not make use of the 'Unsupported
Certificate' and the 'Bad Identity-Info' response code. </t>
<t> Step 1: <vspace blankLines="1"/>
<list style="empty">
<t>The verifier MUST obtain the ENUM root domain from the Identity-Info header
and apply local policies to find out if the specified ENUM root domain
points to a trusted ENUM tree. If the specified ENUM tree is not trusted,
the verifier has to cancel the signature verification and the message MUST
be treated like an unsigned message.</t>
</list>
</t>
<t> Step 2: <vspace blankLines="1"/>
<list style="empty">
<t>The verifier MUST acquire the public key for the signing domain. This
document suggests to store the public key in the DNS. <vspace blankLines="1"
/> This document is only applicable for the usage of tel URIs in the From:
header. When the tel URI contains a 'global-number', i.e., a phone number in
E.164 format starting with the '+' sign, the domain for retrieving the
public key will be constructed according to the following algorithm: <vspace
blankLines="1"/>
<list style="numbers">
<t>remove the 'visual-separators' and all parameters from the tel URI </t>
<t>remove the leading "+" sign </t>
<t>put dots (".") between each digit </t>
<t>reverse the order of the digits </t>
<t>append the ENUM root domain (for example ".e164.arpa") to the end </t>
<t>prepend the string "._domainkey." </t>
<t>prepend the selector</t>
</list>
<vspace blankLines="1"/> For example, given the tel URI
"tel:+43-1-5056416-36;mobile=false", the selector "2008-02" and the root
domain ".e164.arpa", the domain under which the public key is stored is:
<vspace blankLines="1"/>
2008-02._domainkey.6.3.6.1.4.6.5.0.5.1.3.4.e164.arpa <vspace blankLines="1"/>
<vspace blankLines="1"/> Non global-numbers cannot be stored in ENUM and
thus they cannot be used in the From: header when signing the request by the
authentication service. <vspace blankLines="1"/> The 'Unable to retrieve
Public Key from DNS' response code is used when an error in fetching the
public key from the DNS occurs. </t>
</list>
</t>
</section>
<!-- ****************************************************************************** -->
<section anchor="considua" title="Considerations for User Agent">
<t>There are no additional considerations beyond those described in Section 8 of <xref
target="RFC4474"/>.</t>
</section>
<!-- ****************************************************************************** -->
<section anchor="considproxy" title="Considerations for Proxy Servers">
<t>There are no additional considerations beyond those described in Section 8 of <xref
target="RFC4474"/>.</t>
</section>
<!-- ****************************************************************************** -->
<section anchor="example" title="Examples">
<t>The following message exchange highlights the interaction.</t>
<t>
<figure anchor="example-1" title="Example Exchange">
<artwork>
<![CDATA[
Calling Auth. Called
UA Service proxies Verifier UA
------- ------- -------- -------- ------ --------
| | | | | ^
| INVITE | | | | |
|--------->| | | | |
| | | | | |
| (signs request) | | | |
| | | | | | Steps
|100 | INVITE | | | | largely
|<---------|--------->| | | | based
| | | | | | on normal
| |100 | INVITE | | | RFC4474
| |<---------|--------->| | | processing
| | | | | |
| | |100 | | |
| | |<---------| | V
| | | | | ----------
| | | | | ^
| | | (retrieve | |
| | | public key | This
| | | from DNS) | document
| | | | | |
| | | | | v
| | | | | --------
| | | (validates | ^
| | | signature) | | steps
| | | | | | which are
| | | | | | part of
| | | | | | normal
| | | | INVITE | | RFC4474
| | | |--------->| V
| | | | | ----------
| | | | |
| | | | |display
| | | | |E.164 number
]]>
</artwork>
</figure>
</t>
</section>
<!-- ****************************************************************************** -->
<section anchor="caching" title="Caching and Scalability">
<t>When the verifier needs to determine the public key of a specific E.164 number then
it needs to perform a DNS lookup. This lookup might be cached in the DNS but the
lookup is specific for a certain E.164 number and not for a domain. The verifier may
cache the public key corresponding to a particular E.164 number but there is no
guarantee that the same key will be used by any other E.164 number. Furthermore, a
specific E.164 number may have multiple public keys associated with it based on the
selector concept that is useful when revocating keys or when delegating the signing
process.</t>
</section>
<!-- ****************************************************************************** -->
<section anchor="privacy" title="Privacy Considerations">
<t> The mechanism presented in this draft is compatible with the standard SIP practices
for privacy, described in RFC 3323 <xref target="RFC3323"/> and also with the
privacy considerations of RFC 4474 <xref target="RFC4474"/>. </t>
</section>
<!-- ****************************************************************************** -->
<section anchor="security" title="Security Considerations">
<t>The mechanism described in this document has different authorization properties than
RFC 4474 <xref target="RFC4474"/>. A SIP message (including the 'Identity' and the
'Identity-Info' header) with an E.164 number in the From: header field has the
following property (if successfully processed by the verifier): </t>
<t>
<list style="empty">
<t>The entity that uses the private key for creating the SIP Identity header is
authorized to attach the corresponding public key to the ENUM database of
the respective E.164 number used during the lookup.</t>
</list>
</t>
<t>When using PKI infrastructure, the signature verifier trusts the certificate
authority, which attest the identity of the certificate holder. Using ENUM, the
signature verifier has to trust the ENUM registry and the registrars. The ENUM
registrar typically has to validate that the user who tries to register an ENUM
domain is the number right holder. The validation methods usually will be different
between user ENUM (the validation methods can be approved by official buddies) and
private ENUM trees.</t>
<t>It is important to note that with this proposal public keys are essentially for
individual users rather than for the entire domain. As such, the authentication
service needs to have access to the private keys corresponding to the respective
public key. Note, however, that there is nothing special about these key pairs as
such and there is no relationship to other (long-term) asymmetric credentials
potentially possessed by the user. They are rather used only as a technical vehicle
to accomplished the ownership requirement described in this document.</t>
<t>This proposal also does not address the case where a call originates in the PSTN and
enters the Internet via provider that does not possess the private key corresponding
to the public key stored with the E.164 number in the ENUM tree. This is, in some
sense, desired since Caller-ID spoofing is very easy in the PSTN and is difficult to
differentiate from a call that enters the Internet through a provider that has no
relationship with the calling party. This asymmetric routing scenario is, however,
quite common today.</t>
<t>Additional security considerations can be found in <xref
target="I-D.schwartz-sip-e164-ownership"/>. </t>
</section>
<!-- ****************************************************************************** -->
<section anchor="iana" title="IANA Considerations">
<t>This document requests IANA to register a new response code. </t>
<section title="TBD 'Unable to retrieve Public Key from DNS' Response Code">
<t> This document registers a new SIP response code, which is described in <xref
target="verifybehave"/>. It is used when a verifier tries to retrieve the
public key from the DNS and does not succeed and the DNS lookup fails. This
response code is defined by the following information, which has been added to
the method and response-code sub-registry under
http://www.iana.org/assignments/sip-parameters. </t>
<t> Response Code Number: TBD </t>
<t>Default Reason Phrase: Unable to retrieve Public Key from DNS </t>
</section>
<section title="URI Scheme Registration">
<t>[Editor's Note: A future version of this document may register a URI scheme that
allows the SIP 'Identity-Info' header to be reused in order to convey parameters
from the authentication service to the verifier.]</t>
</section>
</section>
<!-- ****************************************************************************** -->
<section anchor="acknow" title="Acknowledgments">
<t>We would like to thank Dan Wing for raising the problems associated with E.164
number-usage in SIP Identity and the discussion during writing of this draft.
Further we would like to thank Alexander Mayrhofer for his ideas in
[draft-mayrhofer-enum-domainkeys-00].</t>
<t>We would also like to thank Kai Fischer, John Elwell, Hadriel Kaplan, David Schwartz,
and Jon Peterson for their off-list comments. </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;
<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.schwartz-sip-e164-ownership">
<front>
<title>E.164 Ownership Problem Statement</title>
<author initials="D." surname="Schwartz" fullname="David Schwartz">
<organization>XConnect</organization>
</author>
<date month="Feb" year="2008"/>
</front>
<seriesInfo name="Std" value="draft-schwartz-sip-e164-ownership-00.txt"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:05:47 |