One document matched: draft-elwell-sip-e164-problem-statement-01.txt
Differences from draft-elwell-sip-e164-problem-statement-00.txt
SIP Working Group J. Elwell
Internet-Draft Siemens
Intended status: Informational October 25, 2008
Expires: April 28, 2009
SIP E.164 Problem Statement
draft-elwell-sip-e164-problem-statement-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 28, 2009.
Abstract
SIP has long supported the use of both email-style addresses
(user@host) and telephone-style addresses (number@host) in the
"From:" address. A significant number of SIP deployments use the
latter style with E.164 numbers. This document describes the
problems that occur when such E.164 numbers are used in SIP.
Elwell Expires April 28, 2009 [Page 1]
Internet-Draft SIP E.164 Problem Statement October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Domain part of a SIP URI . . . . . . . . . . . . . . . . . 3
2.2. E.164 numbers as From: URIs . . . . . . . . . . . . . . . . 4
2.3. Authenticating a From: URI . . . . . . . . . . . . . . . . 5
2.4. Using a received From: URI . . . . . . . . . . . . . . . . 5
3. Summary of problem . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Elwell Expires April 28, 2009 [Page 2]
Internet-Draft SIP E.164 Problem Statement October 2008
1. Introduction
The use of phone numbers with SIP was introduced with the TEL URL
scheme [RFC3966]. In particular, this covered the use of E.164
numbers [ITU.E164.1991], as used in the public switched telephone
network (PSTN). In RFC 3966, domain names were not used with fully-
qualified E.164 phone numbers.
SIP URIs always have domain names. In SIP [RFC3261], a translation
between SIP URIs and TEL URLs was 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.
For the purposes of this document, only fully qualified (global)
E.164 numbers are considered and URIs representing E.164 numbers are
assumed to be of the following forms:
tel:+123456789
sip:+123456789@example.com;user=phone
sips:+123456789@example.com;user=phone
2. Discussion
2.1. Domain part of a SIP URI
When an E.164 number is represented as a SIP URI, it includes a
domain part. Unfortunately there is no clear definition of what the
domain part should contain. On the one hand, it is clear that, in
common with any SIP URI, the domain denoted by the domain part should
at least be able to route the request onwards towards the
destination. Therefore if a SIP URI containing an E.164 number is
the target of a SIP request, the request can be routed to the domain
given in the domain part and that domain will be able to route the
request onwards.
However, this still leaves scope for putting different values into
the domain part, subject to the identified domain being able to route
requests onwards towards their correct destinations. It has been
suggested that the domain part should be the domain that "owns" the
E.164 number, but the concept of ownership is unclear. Does an
enterprise domain "own" the E.164 numbers assigned to it? Does a
public service provider "own" the E.164 numbers assigned to an
enterprise that it serves? What if the enterprise obtains services
Elwell Expires April 28, 2009 [Page 3]
Internet-Draft SIP E.164 Problem Statement October 2008
associated with these numbers from multiple public service providers?
Does a service provider "own" E.164 numbers assigned to an end user?
Who is the "owner" in number portability situations (in some
countries the E.164 number can be considered to be "owned" by the
entity to which it is assigned)?
In practice, for a given E.164 number, different domain names tend to
be used, although such use is perhaps not the original intent of
[RFC3261]. For example, a service provider might always use its own
domain name, regardless of whether the URI represents a number
assigned to one of its users, a number assigned to a different
service provider but served by that first service provider, or some
other number. A service provider that hosts enterprise users might
use the service provider's own domain name rather than that of the
hosted enterprise. An ENUM look-up on an E.164 number might yield a
SIP URI with a domain via which the user of that number can be
reached, but not necessarily the end domain of the user. When E.164
numbers are represented as SIP URIs in fields of SIP messages, the
domain part often changes as the message progresses through different
domains. These considerations have a number of consequences.
2.2. E.164 numbers as From: URIs
When a UA receives an E.164 number represented as a SIP URI in a From
header field, what does this say about the source of the request? Of
course, it should indicate that the request originated at a user who
has a right to use that E.164 number and who can be reached by
submitting a request targeted at that E.164 number. However, the
domain part means very little. At the most it means that the request
has, at some stage, passed through the domain, and that a return
request to that E.164 number can be routed via that domain. The
request did not necessarily originate at that domain, but could
simply have transited that domain. For example, a request could
originate with the following From URI:
sip:+123456789@example1.com;user=phone
The request then passes through the service provider domain
example2.com, which changes it to:
sip:+123456789@example2.com;user=phone
Furthermore the domain in the received From URI is not necessarily
the "owner" of that E.164 number.
Similar considerations apply to E.164 numbers received as SIP URIs in
the P-Asserted-Identity header field [RFC3325].
Elwell Expires April 28, 2009 [Page 4]
Internet-Draft SIP E.164 Problem Statement October 2008
In the PSTN world there is a concept of user-provided and network-
provided caller numbers. The two can differ when the user-provided
number has been provided by an enterprise network (PBX) and denotes
the particular enterprise user, whereas the network-provided number
(the only one that the public network is able to authenticate) is the
default number for the enterprise. It depends on the particular
operator whether a network delivers the user-provided number, the
network-provided number of both to the called user. The user-
provided number is more useful for making a return call. If a SIP
service provider modifies the From URI to provide the equivalent of a
network-provided number, the domain part might no longer reflect the
true identity of the originator of the request.
2.3. Authenticating a From: URI
SIP Identity [RFC4474] provides a means of authenticating a SIP URI
in the From header field. The Identity header field contains a
signature that can be generated only by the domain that appears in
the SIP URI in the From header field. This means the request must
have originated at or passed through that domain. If a domain
changes the From URI, any existing Identity signature will be
invalidated and should be removed, but of course that domain can
insert its own Identity signature, signing the new From URI.
Note that although changing the From URI can be a reason for
generating a new Identity signature, also the converse is true. An
Identity signature can be invalidated because other signed
information (e.g., IP addresses and ports in SDP) has changed, and
because a domain can sign only when its own domain name is in the
From URI, it must change the From URI before signing.
2.4. Using a received From: URI
Even when authenticated, a received From URI can only indicate a
domain through which a request has passed, not necessarily the domain
in which it has originated. This can be an issue if the UAS expects
it to indicate a particular originating domain but in fact it
indicates the domain of an intermediate service provider. For
example:
Suppose the UAS has a white list of particular URIs or domains
from which it accepts communications. The domain at which a
request originated might be in the white list, but if the From URI
indicates another domain through which the request passed, the
check against the white list might fail.
Requests from the same originating domain but all routed through
different intermediate domains might all arrive with different
Elwell Expires April 28, 2009 [Page 5]
Internet-Draft SIP E.164 Problem Statement October 2008
From URIs. Attempts to correlate these requests will probably
fail.
Any attempt by a UAS to correlate a received URI with that of a
known communication partner and as a result provide relevant
information to the user will fail if URIs are compared but the
domain part of the received URI is different from that expected.
If a user expects a particular communication to be to/from a
particular domain (e.g., the user's bank), yet the authenticated
From URI in an received request indicates a service provider's
domain, the user might not be prepared to proceed with that
communication, or might proceed but withhold information of a
sensitive nature.
Some of these issues can be resolved if the domain part is ignored
and only the E.164 number is used for comparison. However, the last
of these issues is a far more serious problem: the user expects a
communication partner to be from a particular domain (the E.164
number is not necessarily an important factor). Seeing that domain
in the From: URI, coupled with authentication by means of the
Identity header field, would satisfy the user's expectation. Seeing
a different domain, that of an intermediate service provider, which
may or may not be known to the user, would not satisfy the user's
expectation. The user might not be prepared to accept the unexpected
URI and might decide not to proceed with the communication.
This last point is particularly important when the media are to be
secured using SRTP. As a basis for this security, the communication
partner with which encrypted and integrity-protected RTP packets are
exchanged must be authenticated as the expected or an acceptable
communication partner. If this involves knowing the domain of the
communication partner, then it is important that the From URI
indicates the domain of the partner and not that of some intermediate
service provider. If the Identity signature also covers the
fingerprint of the certificate used by the partner for establishing
SRTP keys, then this binds the secure media stream to the From URI.
If the From URI is not acceptable, the media stream cannot be
regarded as secure.
3. Summary of problem
A SIP URI containing an E.164 number received in a From header field
is not a reliable source domain of a request, even when authenticated
by means of the Identity header field. Only the E.164 number itself
can be considered reliable, and only the E.164 itself is suitable for
comparing with known identities at the destination (e.g., in a white
Elwell Expires April 28, 2009 [Page 6]
Internet-Draft SIP E.164 Problem Statement October 2008
list, in an address book). The inability to depend on the domain
part of an E.164 SIP URI is a serious deficiency in some situations.
4. Requirements
A solution addressing the problem must satisfy the following
requirements:
REQ1: When a UAS receives a SIP request originated by a user
identified by an E.164 number, the UAS must receive a SIP or SIPS
URI containing that E.164 number and containing the originator's
domain in the domain part.
REQ2: When a UAS receives a SIP request that includes a SIP or SIPS
URI identifying the originating user, if that URI contains an
E.164 number that number alone, when placed in a TEL URI, must be
suitable for routing a request back to the originating user.
REQ3: When a UAS receives a SIP request that includes a SIP or SIPS
URI identifying the originating user, if that URI contains an
E.164 number and the originating domain it must be possible to
include in the request cryptographic evidence from that
originating domain that binds secure media to that SIP URI.
REQ1 is in principle met by the From URI, but not if it is modified
by intermediate domains between the originating domain and the UAS.
Obviously elimination of such practices would in theory be sufficient
to satisfy REQ1, but this might not be achievable. Therefore it
might require new techniques.
REQ2 requires new techniques.
REQ3 can in theory be met by the Identity header field, but this is
true only if intermediate domains do not modify the From URI or other
signed information, such as IP addresses and ports in SDP (these are
often changed by Session Border Controllers, SBCs) and contact URIs
(these too are often changed by SBCs and other B2BUAs). Therefore to
solve this in a way that will work in most practical situations
requires new techniques.
5. IANA Considerations
None; this document is informational.
Elwell Expires April 28, 2009 [Page 7]
Internet-Draft SIP E.164 Problem Statement October 2008
6. Security Considerations
[[This section will be completed in a later version of this
document.]]
7. Acknowledgements
The author thanks Dan Wing for encouraging the writing of this
document.
8. Informative References
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[ITU.E164.1991]
International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU-
T Recommendation E.164, 1991.
Author's Address
John Elwell
Siemens Enterprise Communications
Phone: +44 115 943 4989
Email: john.elwell@siemens.com
Elwell Expires April 28, 2009 [Page 8]
Internet-Draft SIP E.164 Problem Statement October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Elwell Expires April 28, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 06:43:22 |