Econocom-Osiatis Ingenierie

75 cours Albert Thomas 69003 Lyon France laurent.goix@econocom-osiatis.com

Individual

969 Wenyixi Road 311121 Hangzhou China kepeng.likp@gmail.com

This document registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers).

ENUM (E.164 Number Mapping, ) is a system that uses DNS (Domain Name Service, ) to translate telephone numbers, such as '+44 1632 960123', into URIs (Uniform Resource Identifiers, ), such as 'acct:user@example.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to identify resources. defines the 'acct' URI scheme as a way to identify a user's account at a service provider. This document registers an Enumservice for advertising 'acct' URI information associated with an E.164 number.

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 .

In this example, an address book application could issue ENUM queries looking for 'acct' URIs corresponding to phone numbers. This could be used to display the account identifier as well as an icon based on the host (domain) portion of that URI. Similarly, an endpoint could trigger this resolution process during inbound and/or outbound calls to discover an account associated with the remote party. In general, the provision of an ENUM record to map a phone number into an account may be useful for businesses or professional workers to identify themselves publicly (in a way similar to vCard ENUM records).

The Open Mobile Alliance (OMA) develops mobile service enabler specifications, which support the creation of interoperable end-to-end mobile services independent of the underlying wireless platforms, such as GSM (Global System for Mobile communications), UMTS (Universal Mobile Telecommunications System), and LTE (Long Term Evolution) mobile networks. The OMA Social Network Web (SNeW) Enabler Release has introduced a number of social networking functionalities for mobile subscribers identified by their MSISDN (Mobile Subscriber Integrated Services Digital Network number, a number uniquely identifying a subscription in a mobile network), amongst which is the ability to follow each other's social activities across service providers. Such functionality requires the global resolution of the MSISDN to the corresponding account and provider, in a way analogous to Multimedia Messaging Service (MMS) routing, to identify the target endpoint for the related messages. Although alternative solutions exist (e.g., based on mobile network operations and/or proprietary lookup techniques), ENUM provides a globally accessible mechanism for enabling resolution from network entities on behalf of an endpoint, or from an endpoint itself. For example, a user of a service provider could request to follow the social activities of user '+44 1632 960123'. The home SNeW Server of the former user could perform an ENUM query to identify the 'acct' URI corresponding to that phone number. Based on the resulting URI, the server could then identify the SNeW Server of the target user and route the original user's request to the appropriate endpoint. A similar mechanism can apply to other types of social networking-related messages or other communications targeted to a mobile subscriber.

As defined in , the following is a template covering information needed for the registration of the Enumservice specified in this document:

Application-Based, Ancillary acct acct This Enumservice indicates that the resource can be identified by the associated 'acct' URI . For DNS considerations in avoiding loops when searching for "acct" NAPTRs, see , Section 6. For security considerations, see , Section 7. COMMON Laurent-Walter Goix Econocom-Osiatis Ingenierie mailto:laurent.goix@econocom-osiatis.com 2015-06-03 ]]>

The following is an example of the use of the Enumservice registered by this document in a Naming Authority Pointer (NAPTR) resource record for phone number +44 1632 960123.

Note that in the first record, the revealed information is limited to the domain of the service provider serving that user, as the userpart of the 'acct' URI simply replicates the phone number.

There may not be any "E2U+acct" NAPTRs returned in response to the original ENUM query on the requested telephone number, but other terminal ENUM NAPTRs that include tel: URLs (e.g., "voice:tel", "pstn:tel", "sms:tel", or "mms:tel" -- see ) may be present. The application that made that ENUM query may choose to resubmit ENUM queries for any E.164 numbers included in those returned terminal NAPTRs. Doing so may cause a query loop (e.g., the ENUM records returned from subsequent queries may refer to the telephone number already considered). If applications choose to perform subsequent ENUM queries using telephone numbers retrieved from earlier queries, these applications MUST be aware of the potential for query loops and MUST be prepared to abort the set of queries if such a loop is detected. This issue is similar to the referential loop issue caused by processing non-terminal NAPTR queries, as mentioned in Section 5.2.1 of , and a similar technique to mitigate this issue can be used; an application searching for records with "acct" Enumservice may consider that submitting a chain of more than 5 ENUM queries without finding such a record indicates that a referential loop has been entered, and the chain of queries SHOULD be abandoned.

DNS, as used by ENUM, is a global, distributed database. Should implementers of this specification use e164.arpa or any other publicly available domain as the tree for maintaining Public Switched Telephone Network (PSTN) Enumservice data, this information would be visible to anyone anonymously. Carriers, service providers, and other users may choose not to publish such information in the public e164.arpa tree. They may instead simply publish this in an internal ENUM infrastructure that is only able to be queried by trusted elements of their network, thus limiting threats. For security considerations that apply to all Enumservices, please refer to , Section 7. It is important to note that the ENUM record itself does not need to contain any personal information but only contains a pointer to an account identifier. This identifier may be queried to discover pointers to personal information (e.g., social-network information) endpoints, and an authorization mechanism may be in place in that context with any level of granularity; these topics are out of scope for this document. Technically, ENUM records themselves could contain pointers to the same endpoints. However, the visibility of ENUM records cannot be controlled based on the requesting entity. In that context, the simple mapping of the phone number to the account identifier, notwithstanding the disclosure of the association itself, still enables the reuse of more advanced access policies. Revealing an 'acct' URI by itself is unlikely to introduce many privacy concerns, although, depending on the structure of the URI, it might reveal the full name or employer of the target. The use of anonymous URIs mitigates this risk. Unlike a traditional telephone number, the endpoint identified by an 'acct' URI may require that requesting entities provide cryptographic credentials for authentication and authorization before messages are exchanged. ENUM can actually provide far greater protection from unwanted requesting entities than does the existing PSTN, despite the public availability of ENUM records. More serious security concerns are associated with potential attacks against an underlying system (for example, a social-network system) using the 'acct' URI. For this reason, the underlying system should have a number of security requirements that call for authentication, integrity, and confidentiality properties, and similar measures to prevent such attacks. This is out of scope for this document.

Per this document, IANA has registered the Enumservice with Type "acct" according to the definitions in this document, , and . Details of the registration are given in .

Open Mobile Alliance, OMA-ER-SNeW-V1_0

The authors would like to thank Gonzalo Salgueiro, Paul Jones, Lawrence Conroy, Enrico Marocco, Bert Greevenbosch, and Bernie Hoeneisen for their valuable feedback to improve this document.