ENUM acct: Enumservice Registration for 'acct' URI
Map telephone numbers to online account identifiers using DNS.
Goix, L. and K. Li, "Enumservice Registration for 'acct' URI", RFC 7566, DOI 10.17487/RFC7566, June 2015, <https://www.rfc-editor.org/info/rfc7566>.
@misc{rfc7566,
series = {Request for Comments},
number = 7566,
howpublished = {RFC 7566},
publisher = {RFC Editor},
doi = {10.17487/RFC7566},
url = {https://www.rfc-editor.org/info/rfc7566},
author = {L. Goix and K. Li},
title = {{Enumservice Registration for 'acct' URI}},
pagetotal = 8,
year = 2015,
month = jun,
} RFC text
Contents
Independent Submission L. Goix
Request for Comments: 7566 Econocom-Osiatis Ingenierie
Category: Experimental K. Li
ISSN: 2070-1721 Individual
June 2015
Enumservice Registration for 'acct' URI
Abstract
This document registers an E.164 Number Mapping (ENUM) service for
'acct' URIs (Uniform Resource Identifiers).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This is a contribution to the RFC Series, independently
of any other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7566.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Use Cases .......................................................2
3.1. Reverse Phone Lookup .......................................2
3.2. Routing of Mobile Social Communications ....................3
4. IANA Registration ...............................................4
5. Examples ........................................................5
6. DNS Considerations ..............................................5
7. Security Considerations .........................................6
8. IANA Considerations .............................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................8
Acknowledgements ...................................................8
Authors' Addresses .................................................8
1. Introduction
ENUM (E.164 Number Mapping, [RFC6116]) is a system that uses DNS
(Domain Name Service, [RFC1034]) to translate telephone numbers, such
as '+44 1632 960123', into URIs (Uniform Resource Identifiers,
[RFC3986]), 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.
[RFC7565] 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.
2. Terminology
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 [RFC2119].
3. Use Cases
3.1. Reverse Phone Lookup
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).
3.2. Routing of Mobile Social Communications
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 [OMA-SNeW] 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.
4. IANA Registration
As defined in [RFC6117], the following is a template covering
information needed for the registration of the Enumservice specified
in this document:
<record>
<class>Application-Based, Ancillary</class>
<type>acct</type>
<urischeme>acct</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
can be identified by the associated 'acct' URI
<xref target='RFC7565'/>.
</paragraph>
</functionalspec>
<security>
For DNS considerations in avoiding loops when
searching for "acct" NAPTRs, see
<xref type="rfc" data="7566"/>, Section 6.
For security considerations, see
<xref type="rfc" data="7566"/>, Section 7.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="7566"/>
</registrationdocs>
<requesters>
<xref type="person" data="Laurent_Walter_Goix"/>
</requesters>
</record>
<people>
<person id="Laurent_Walter_Goix">
<name>Laurent-Walter Goix</name>
<org>Econocom-Osiatis Ingenierie</org>
<uri>mailto:laurent.goix@econocom-osiatis.com</uri>
<updated>2014-06-18</updated>
</person>
</people>
Note that the registry maintained by IANA is definitive. For the
most recent version of the registration, please see the online
registry <http://www.iana.org/assignments/enum-services>.
5. Examples
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.
$ORIGIN 3.2.1.0.6.9.2.3.6.1.4.4.e164.arpa.
IN NAPTR 10 100 "u" "E2U+acct" "!^.*$!acct:441632960123@foo.com!" .
IN NAPTR 10 101 "u" "E2U+acct" "!^.*$!acct:john.doe@example.com!" .
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.
6. DNS Considerations
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 [RFC3966] (e.g.,
"voice:tel", "pstn:tel", "sms:tel", or "mms:tel" -- see [RFC6118])
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 [RFC6116], 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.
7. Security Considerations
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 [RFC6116], 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.
8. IANA Considerations
Per this document, IANA has registered the Enumservice with Type
"acct" according to the definitions in this document, [RFC6116], and
[RFC6117].
Details of the registration are given in Section 4.
9. References
9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004,
<http://www.rfc-editor.org/info/rfc3966>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116,
DOI 10.17487/RFC6116, March 2011,
<http://www.rfc-editor.org/info/rfc6116>.
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
Registration of Enumservices: Guide, Template, and IANA
Considerations", RFC 6117, DOI 10.17487/RFC6117,
March 2011, <http://www.rfc-editor.org/info/rfc6117>.
[RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA
Registrations of Enumservices", RFC 6118,
DOI 10.17487/RFC6118, March 2011,
<http://www.rfc-editor.org/info/rfc6118>.
[RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565,
DOI 10.17487/RFC7565, May 2015,
<http://www.rfc-editor.org/info/rfc7565>.
9.2. Informative References
[OMA-SNeW]
Open Mobile Alliance, OMA-ER-SNeW-V1_0, "Social Network
Web Enabler", August 2013,
<http://technical.openmobilealliance.org/Technical/
release_program/snew_v1_0.aspx>.
Acknowledgements
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.
Authors' Addresses
Laurent-Walter Goix
Econocom-Osiatis Ingenierie
75 cours Albert Thomas
69003 Lyon
France
EMail: laurent.goix@econocom-osiatis.com
Kepeng Li
Individual
969 Wenyixi Road
311121 Hangzhou
China
EMail: kepeng.likp@gmail.com
AI ELI5
On this page
§1Introduction
ENUM (E.164 Number Mapping) is a DNS-based system for translating telephone numbers like +44 1632 960123 into URIs such as acct:user@example.com. ENUM exists primarily to interconnect systems that rely on telephone numbers with those that use URIs to identify resources.
RFC 7565 defines the acct URI scheme, which identifies a user's account at a service provider using the format acct:localpart@domain. This document registers an Enumservice for the acct scheme, allowing ENUM lookups to return acct URIs associated with a telephone number. This enables applications to discover account identifiers directly from phone numbers using standard DNS queries.
ENUM is a phone book in DNS. This document adds a new kind of information you can look up: an account name, not just a phone call.
§2Use Cases
The first major use case is reverse phone lookup. An address book application can issue ENUM queries for acct URIs corresponding to phone numbers, displaying the account identifier and an icon based on the service provider. An endpoint can trigger this during inbound and outbound calls to discover the account associated with the remote party. Businesses and professionals may use ENUM acct records to identify themselves publicly, similar to existing vCard ENUM records.
The second use case involves routing of mobile social communications. The Open Mobile Alliance defines social networking services (SNeW) that let mobile subscribers identified by their MSISDN (Mobile Subscriber Integrated Services Digital Network number) follow each other's activities across service providers. When a user wants to follow another user's social activities, their home SNeW server can use ENUM to resolve the target user's MSISDN to their account URI, identify the target user's service provider, and route the follow request to the correct endpoint. This provides a globally accessible mechanism for discovering account endpoints without relying on proprietary systems.
Two main ways to use this: first, when you look up a phone number in your address book, also show the person's username. Second, help one social media service find a user on another service by looking up their phone number.
§3IANA Registration
This RFC registers an Enumservice with IANA named 'acct'. The registration follows RFC 6117, which defines the template for registering Enumservices. The registered type is 'acct', matching the acct URI scheme defined in RFC 7565. The Enumservice is classified as Application-Based and Ancillary, and its usage is marked as COMMON.
The registration document (this RFC) serves as the authoritative source for the Enumservice definition. The IANA registry itself is maintained at http://www.iana.org/assignments/enum-services and is the definitive reference for the most current registration details.
IANA (the number assignment authority for the internet) now has a rule saying "acct" is a valid type of information you can look up alongside a phone number in ENUM.
§4Examples and DNS Considerations
A DNS NAPTR resource record for the phone number +44 1632 960123 using the acct Enumservice might look like:
3.2.1.0.6.9.2.3.6.1.4.4.e164.arpa IN NAPTR 10 100 "u" "E2U+acct" "!^.*$!acct:441632960123@foo.com!" .
The example shows that the userpart can simply replicate the phone number with limited information, or it can contain a full account name like john.doe@example.com.
When applications query for acct records, they may also receive other terminal ENUM records (such as tel: URLs for voice or SMS). If the application chooses to submit ENUM queries for telephone numbers found in those results, it risks entering a query loop if the results point back to numbers already queried. Applications SHOULD detect and abort such loops, potentially by limiting the chain to no more than 5 queries without finding an acct record.
The DNS record format tells where to look up a phone number and what account name to return. You have to be careful not to get stuck looking up the same numbers over and over.
§5Security and Privacy
ENUM is a public, global DNS database. If acct Enumservice records are published in the public e164.arpa tree, they are visible to anyone. Carriers and service providers may choose to publish acct records only in internal ENUM infrastructure accessible only to trusted network elements, limiting privacy risks.
An acct URI itself does not inherently contain personal information but is merely a pointer to an account identifier. Depending on the structure of the URI (for example, if it includes a full name or employer), revealing it could expose personal information. Using anonymous or pseudonymous URIs mitigates this risk.
Unlike a traditional telephone number, an endpoint identified by an acct URI can require requesting entities to provide cryptographic credentials for authentication and authorization before messages are exchanged. This can provide stronger protection from unwanted requests than the PSTN.
The underlying systems that acct URIs point to should implement their own security controls including authentication, integrity, and confidentiality measures to prevent attacks.
Publishing a phone-to-username mapping is public and visible to everyone. You might not want people to know your real name from your phone number, so you can use a fake username or keep the records private.