E.164 Ownership Problem Statement

RFC 4474 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 whereby domain names were not used with the phone numbers. SIP URIs always have domain names. In SIP , 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. When SIP Identity 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 . 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.

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 .

Consider where two end points, Bob and Joe, initiate calls to Alice. Alice is using an IP-based phone and the same is true for Joe. The call of Joe and Bob towards Alice traverse the PSTN; Bob is using a PSTN phone and the call enters the Internet via a PSTN/VoIP gateway. Joe's call traverses the PSTN, for example, because Joe's VoIP provider does not have a peering agreement with the called party domain and uses the PSTN as a way to interconnect VoIP networks. This is a common way of interacting between VoIP providers today.

| PSTN |--+ | | | | | \\\\ //// | | -------- | | ^ | | | v | | +----+-------+ +---+------+ | |PSTN / VoIP | +-----+ |PSTN Phone| | |Gateway | |SIP | |of Bob | | +----+-------+ |UA | +----------+ | | |Alice| | Invite +-----+ | | ^ | V | +----------+-+ +-------------+ Invite |VoIP / PSTN | |VoIP | | |Gateway | |Service | Invite +-------+ +----------+-+ |Provider(s) |----------->+ | ^ +-------------+ | | | |Verif. | | |Service| +---------+ | | | |IP-based | | +-------+ |SIP Phone| | |---------| |of Joe | | called +---------+ | party | | domain | ----- | //// \\\\ | / \ | | | +---->| IP-based | | Network | \ / \\\\ //// ----- ]]> raises two important questions: How does the authentication service (for example an entity that is co-located with the PSTN/VoIP gateway) authenticate and authorize the calling party? How does the verification service determine ownership of an E.164 number? investigates the first question in more detail whereas addresses the second question.

RFC 4474 rightfully makes some important assumptions about the behavior of the authentication service that contribute significantly to the security of the overall system. While some assumptions seem to be obvious for SIP usage, they are less obvious when considering them in relationship with a PSTN interworking. Section 4 of 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: The PSTN builds on a walled garden with a chain-of-trust security model. This is "nice" as long as the participating parties are indeed honest. Unfortunately, this is not true anymore (and has not been the case for a long time already) [add-references-to-examples]. Caller-ID spoofing is common and even transit providers are not trustworthy either. 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.

Imagine a verification service at Alice's VoIP provider network receives a SIP message with an 'Identity' and an 'Identity-Info' header. How would this verification service determine whether the signer of the message is indeed authorized to claim ownership? 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. There are various owership verification steps that got used in the IETF within other protocols. RFC 4474 , 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. Still, the signer and the verifier need to have a trust anchor in common. There are additional aspects about the detailed matching procedure that are described in Section 13.4 of . 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. A couple of other ownership approaches have been used in IETF protocols. A few examples below: 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 . 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 ) and 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. 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 . The usage of TRIP (with extensions with information about E.164 numbers that are authorized for usage by a specific provider) has been discussed as well. 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, ). It is quite obvious that each mechanism has different scalability, security and deployment properties.

With the work on this subject it is important to keep two quotes in mind: "The security of a system is as good as the weakest link." "If you think cryptography is the solution to your problem, you don’t know what your problem is." --- Roger Needham We are still in an early phase to properly understand the problem domain even though there are a couple of TECHNICAL solution proposals available to address the ownership question. These technical approaches do, however, not help when there is no deployment incentives. These approaches also do not help with the security of the overall system when the identity of the calling party cannot be verified by the authentication service. As such, it is too early to conclusively argue that an RFC 4474 alike authentication service should actually attempt to offer a solution for E.164 numbers even though they are heavily used in today's networks.

We would like to thank the following individuals for their contributions to this document: Dan Wing John Elwell Kai Fischer

There are no IANA considerations with this document.

Add your name here.