RFC 7566

Enumservice Registration for 'acct' URI

📅 published June 2015, from ietf

RFC 7566: Enumservice Registration for 'acct' URI 💖

🎀 Quick title check: Independent Submission, Experimental category, June 2015, ISSN 2070-1721. Authors are L. Goix (Econocom-Osiatis Ingenierie) and K. Li (Individual). It doesn't list any Obsoletes or Updates. 🧚

Abstract

okay so this doc registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers) ✨

Status of This Memo

bestie, this one is NOT an Internet Standards Track spec 🙈 it's published for examination, experimental implementation, and evaluation.

It's an Experimental Protocol for the Internet community 🧪 It's an independent contribution to the RFC Series, not tied to any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Anything the RFC Editor approves is not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 💅

For the current status, any errata, and how to leave feedback, check http://www.rfc-editor.org/info/rfc7566 🦋

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. ©️

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. Please actually read those, because they spell out your rights and restrictions 📜🫶

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 turn phone numbers, like '+44 1632 960123', into URIs (Uniform Resource Identifiers, [RFC3986]), like 'acct:user@example.com'. 📞➡️🔗 ENUM mainly exists so systems that run on phone numbers can talk to systems that use URIs to identify things. It's the bridge, bestie 🌉

[RFC7565] defines the 'acct' URI scheme as a way to identify a user's account at a service provider 🧑‍💻

And this doc registers an Enumservice for advertising 'acct' URI info tied to 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]. 📖 Those are the BCP 14 key words, so read them as RFC 2119 defines them.

3. Use Cases 🌸

3.1. Reverse Phone Lookup 📱

Picture this: an address book app runs ENUM queries looking for 'acct' URIs that match phone numbers 📇 It could then show the account identifier, plus an icon based on the host (domain) part of that URI. Cute, right? 🥰

Same energy for an endpoint. It can kick off this resolution during inbound and/or outbound calls to find the account behind the remote party 📞✨

Generally speaking, putting an ENUM record that maps a phone number to an account can be useful for businesses or professionals who want to identify themselves publicly. It's kind of like vCard ENUM records 💼💅

3.2. Routing of Mobile Social Communications 🌈

The Open Mobile Alliance (OMA) makes mobile service enabler specs. These help build interoperable end-to-end mobile services that don't care which wireless platform is underneath, like GSM (Global System for Mobile communications), UMTS (Universal Mobile Telecommunications System), and LTE (Long Term Evolution) networks 📶 The OMA Social Network Web (SNeW) Enabler Release [OMA-SNeW] added a bunch of social networking features for mobile subscribers identified by their MSISDN (Mobile Subscriber Integrated Services Digital Network number, which uniquely identifies a subscription in a mobile network). The big one is being able to follow each other's social activity across service providers 👀💕

That needs global resolution of an MSISDN to the matching account and provider, kind of like how Multimedia Messaging Service (MMS) routing works. The goal is to find the right endpoint for the messages 🎯 Other options exist (like stuff based on mobile network operations and/or proprietary lookup techniques). But ENUM gives you a globally accessible mechanism that network entities can use to resolve on behalf of an endpoint, or that an endpoint can use itself 🌍

Here's an example. A user of one provider wants to follow the social activity of user '+44 1632 960123'. The first user's home SNeW Server can run an ENUM query to find the 'acct' URI for that phone number 🔍 From that URI, the server can find the SNeW Server of the target user and route the original request to the right endpoint 🦋

The same kind of mechanism can work for other social networking messages, or any other communication aimed at a mobile subscriber 💌

4. IANA Registration 📋

As defined in [RFC6117], the following is a template with the info needed to register the Enumservice 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>

Quick heads up: the registry IANA keeps is the definitive one ✅ For the latest version, check http://www.iana.org/assignments/enum-services 💖

5. Examples 💅

Here's an example of the Enumservice from this doc in use. It's 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 only info revealed is the domain of the provider serving that user 🙈 The userpart of the 'acct' URI just copies the phone number, so there's nothing extra to see there 🔒

6. DNS Considerations 🧚

Soooo, there might not be any "E2U+acct" NAPTRs coming back from the original ENUM query on the requested number 🤷‍♀️ But you might still get other terminal ENUM NAPTRs that include tel: URLs [RFC3966] (like "voice:tel", "pstn:tel", "sms:tel", or "mms:tel", see [RFC6118]) 📲

The app that made that query may choose to resubmit ENUM queries for any E.164 numbers in those terminal NAPTRs. But watch out 👀 Doing that can cause a query loop, since records from later queries may point back at a number you already checked 🔁 If apps do follow-up queries using numbers pulled from earlier answers, they MUST be aware of the loop risk, and they MUST be ready to abort the set of queries if a loop shows up 🚨

This is basically the referential loop problem from processing non-terminal NAPTR queries, which Section 5.2.1 of [RFC6116] covers. A similar fix can help here too. An app searching for records with "acct" Enumservice may decide that a chain of more than 5 ENUM queries with no matching record means a referential loop was entered, and in that case the chain SHOULD be abandoned 🛑💜

7. Security Considerations 🔐💅

okay bestie, so DNS is the thing ENUM runs on, and DNS is a global, distributed database 🌍✨ which means it's basically public by design. If implementers use e164.arpa or any other publicly available domain as the tree for storing Public Switched Telephone Network (PSTN) Enumservice data, that info is visible to literally anyone, anonymously 👀 no cap.

Carriers, service providers, and other users can choose NOT to publish stuff in the public e164.arpa tree 🙅‍♀️ and instead keep it in an internal ENUM setup that only trusted elements of their network can query 🔒 that's how you keep threats lowkey down 🫶

For security stuff that applies to ALL Enumservices, go check [RFC6116], Section 7 📖 it's the source of truth for that.

Okay, the big reminder: the ENUM record itself doesn't need to hold any personal info 🙈 it only points to an account identifier. That identifier can be queried to find pointers to personal info endpoints (like social-network info 🦋), and an authorization mechanism can sit in that context with any level of granularity. Those topics are out of scope for this doc, so don't come looking for them here 💜

Technically, ENUM records could point to the same endpoints too 🤓 BUT the visibility of ENUM records can't be controlled based on who's asking. So even though the phone-number-to-account mapping is revealed, that simple mapping still makes it possible to reuse more advanced access policies 🎀

Revealing an 'acct' URI by itself is unlikely to cause many privacy issues 💖 although, depending on how the URI is structured, it might reveal the full name or employer of the target 😭 Using anonymous URIs helps lower that risk 🧚

Here's the big plot twist 🔥: unlike a traditional phone number, the endpoint identified by an 'acct' URI can require that requesting entities provide cryptographic credentials for authentication and authorization before messages get exchanged 🔐 ENUM can actually give way more protection from unwanted requesters than the existing PSTN does, even though ENUM records are publicly available 👑 iconic, periodt 💅

Now the serious part 🥺: the scarier concerns are about attacks against the underlying system (for example, a social-network system) that's using the 'acct' URI 💀 For that reason, the underlying system SHOULD have a bunch of security requirements calling for authentication, integrity, and confidentiality properties, plus similar measures to stop those attacks 🛡️ That's out of scope for this document, though ✨

Heads up: the underlying system is where the real danger lives, so don't skip those protections just because ENUM itself is out of the picture 💀

8. IANA Considerations 📋🌸

Per this document, IANA has registered the Enumservice with Type "acct" 🎉 following the definitions in this document, [RFC6116], and [RFC6117] ✨

The full details of that registration are 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 💖 literally the best group project credits ever 🌟

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
📦 where this page comes from