| TOC |
|
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 August 28, 2008.
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.
1.
Introduction
2.
Terminology
3.
The End-to-End Picture
3.1.
IP-IP Case
3.2.
IP-PSTN-IP Case
3.3.
PSTN-to-IP Case
3.4.
IP-to-PSTN Case
4.
Authenticating and Authorizing the Calling Party Identity
5.
Verifying Ownership: What does it mean?
6.
Security Considerations
7.
Contributors
8.
IANA Considerations
9.
Acknowledgments
10.
References
10.1.
Normative References
10.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
RFC 4474 [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) 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.
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.
The use of phone numbers with SIP was introduced with the TEL URL scheme [RFC3966] (Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.) whereby domain names were not used with the phone numbers. SIP URIs always have domain names. In SIP [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), 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 [E164] (ITU-T, “The international public telecommunication numbering plan,” May 1997.)) it is not clear how to populate the domain name.
When SIP Identity [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) 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 [I‑D.elwell‑sip‑e164‑problem‑statement] (Elwell, J., “SIP E.164 Problem Statement,” October 2008.). 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.
| TOC |
This document largely relies on the terminology introduced by [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.).
| TOC |
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 Figure 1 (Federation based IP-to-IP Communication) below for the first two cases.
--------
//// \\\\
+------------+ | 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 |
\ /
\\\\ ////
-------------------------
| Figure 1: Federation based IP-to-IP Communication |
| TOC |
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.
As can be seen in Figure 1 (Federation based IP-to-IP Communication) 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?
| TOC |
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.
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?
| TOC |
Consider Figure 2 (PSTN-to-IP Communication) 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.
--------
//// \\\\
+->| 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
| Figure 2: PSTN-to-IP Communication |
| TOC |
Consider Figure 3 (IP-to-PSTN Communication) 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?
+-------+ +-----+ -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
| Figure 3: IP-to-PSTN Communication |
| TOC |
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 [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) says:
"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.
...
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. "
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?
There are problems with this step:
| TOC |
Imagine a verification service at Alice's VoIP provider network receives a SIP message with an 'Identity' and an 'Identity-Info' header.
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.
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.
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 Figure 4 (Will the real 'Owner' please stand up?).
+-----------------------------------+ | COR | | +-----------------------------+ | | | E.164 Exchnage | | | | +---------------------+ | | | | | VSP | | | | | | +-----------+ | | | | | | | PBX | | | | | | | +-----------+ | | | | | | | | | | | +---------------------+ | | | | | | | +-----------------------------+ | | | +-----------------------------------+
| Figure 4: Will the real 'Owner' please stand up? |
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 [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.). 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.
Looking at "ownership" in this way may necessitate an Authority Information Access (AIA) [RFC2459] (Housley, R., Ford, W., Polk, T., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile,” January 1999.) 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.
There are various owership verification steps that got used in the IETF within other protocols. RFC 4474 [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.), for example, uses the following verification step for SIP URIs:
"6. Verifier Behavior
Step 2:
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.
13.4. Domain Names and Subordination
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."
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 [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.).
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.
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:
- 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 [I‑D.wing‑sip‑e164‑rrc] (Wing, D., “SIP E.164 Return Routability Check (RRC),” February 2008.).
- Authorization Certificates:
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 [I‑D.ietf‑sip‑saml] (Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. Sicker, “SIP SAML Profile and Binding,” March 2010.)) and [RFC3554] (Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, “On the Use of Stream Control Transmission Protocol (SCTP) with IPsec,” July 2003.) 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.
- Distributed Databases:
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 [I‑D.darilion‑sip‑e164‑enum] (Darilion, K. and H. Tschofenig, “E.164 Ownership using Public Keys stored in ENUM,” February 2008.). The usage of TRIP [RFC3219] (Rosenberg, J., Salama, H., and M. Squire, “Telephony Routing over IP (TRIP),” January 2002.) (with extensions with information about E.164 numbers that are authorized for usage by a specific provider) has been discussed as well.
- Cryptographic Addresses and Hash Chains:
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, [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.)).
Needless to say that each mechanism has different scalability, security and deployment properties.
| TOC |
With the work on this subject it is important to keep two quotes in mind:
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.
| TOC |
We would like to thank the following individuals for their contributions to this document:
| TOC |
There are no IANA considerations with this document.
| TOC |
We would like to thank Joel M. Halpern, Paul Kyzivat, Dale Worley, Jonathan Rosenberg, and Henry Sinnreich for their feedback on the mailing list.
| TOC |
| TOC |
| [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 (TXT). |
| [RFC4474] | Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” RFC 4474, August 2006 (TXT). |
| [RFC4871] | Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” RFC 4871, May 2007 (TXT). |
| [RFC3966] | Schulzrinne, H., “The tel URI for Telephone Numbers,” RFC 3966, December 2004 (TXT). |
| [RFC3761] | Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” RFC 3761, April 2004 (TXT). |
| TOC |
| [I-D.elwell-sip-e164-problem-statement] | Elwell, J., “SIP E.164 Problem Statement,” draft-elwell-sip-e164-problem-statement-01 (work in progress), October 2008 (TXT). |
| [I-D.ietf-sip-saml] | Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. Sicker, “SIP SAML Profile and Binding,” draft-ietf-sip-saml-07 (work in progress), March 2010 (TXT). |
| [I-D.wing-sip-e164-rrc] | Wing, D., “SIP E.164 Return Routability Check (RRC),” draft-wing-sip-e164-rrc-01 (work in progress), February 2008 (TXT). |
| [RFC3972] | Aura, T., “Cryptographically Generated Addresses (CGA),” RFC 3972, March 2005 (TXT). |
| [RFC3219] | Rosenberg, J., Salama, H., and M. Squire, “Telephony Routing over IP (TRIP),” RFC 3219, January 2002 (TXT). |
| [RFC2459] | Housley, R., Ford, W., Polk, T., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile,” RFC 2459, January 1999 (TXT). |
| [RFC3554] | Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, “On the Use of Stream Control Transmission Protocol (SCTP) with IPsec,” RFC 3554, July 2003 (TXT). |
| [E164] | ITU-T, “The international public telecommunication numbering plan,” Recommendation E.164, May 1997. |
| [RFC3323] | Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” RFC 3323, November 2002 (TXT). |
| [I-D.darilion-sip-e164-enum] | Darilion, K. and H. Tschofenig, “E.164 Ownership using Public Keys stored in ENUM,” draft-darilion-sip-e164-enum-00 (work in progress), February 2008 (TXT). |
| TOC |
| David Schwartz | |
| XConnect | |
| Malcha Technology Park | |
| Jerusalem, 96951 | |
| Israel | |
| Email: | dschwartz@xconnect.net |
| Hadriel Kaplan | |
| Acme Packet | |
| 71 Third Ave. | |
| Burlington, MA 01803 | |
| USA | |
| Phone: | |
| Fax: | |
| Email: | hkaplan@acmepacket.com |
| URI: | |
| Klaus Darilion | |
| enum.at GmbH | |
| Karlsplatz 1/9 | |
| Wien A-1010 | |
| Austria | |
| Phone: | +43 1 5056416 36 |
| Email: | klaus.darilion@enum.at |
| URI: | http://www.enum.at/ |
| Hannes Tschofenig | |
| Nokia Siemens Networks | |
| Linnoitustie 6 | |
| Espoo 02600 | |
| Finland | |
| Phone: | +358 (50) 4871445 |
| Email: | Hannes.Tschofenig@nsn.com |
| URI: | http://www.tschofenig.com |
| TOC |
Copyright © 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.
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.