Internet-Draft MIMI GLADOS July 2023
Rosenberg Expires 11 January 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-rosenberg-mimi-glados-00
Published:
Intended Status:
Informational
Expires:
Author:
J. Rosenberg
Five9

Global Lookup and Discovery of Services (GLADOS)

Abstract

This document proposes a solution for the discovery problem in MIMI (More Instant Messaging Interoperability). The discovery problem is the technique by which a user in one messaging provider can determine the preferred messaging provider for a target user identified by an email address or phone number. The discovery problem has been the subject of numerous - largely failed - standardization attempts at the IETF. This document outlines these attempts and hypothesizes the reasons for their failure, using that to define a set of requirements to avoid these failures in a next attempt. The new proposed solution, called the Global Lookup and Discovery of Services (GLADOS) protocol, is a centralized internet-wide provider that interfaces with application providers.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on 11 January 2024.

▲

Table of Contents

1. Introduction

The More Instant Messaging Interoperability (MIMI) working group is chartered to enable federated messaging, voice, and video service between application providers, such as WhatsApp, Facebook Messenger, and other vendors. The MIMI protocols cover the exchange of encrypted content [I-D.ietf-mimi-content] through transfer protocols [I-D.ralston-mimi-linearized-matrix]. These protocols allow a user in one provider to initiate 1-1 and group messaging with a user in a second provider. The protocol requires that the originator of the communication know two things about the target user - their messaging provider, and a unique identifier for that user within that provider. The specifications recognize that the originator will not always know the provider for the target user, or the provider-specific identifier for that user on that provider. The problem is further complicated by the fact that a users often make use of multiple messaging applications, in which case the preferences of the target user need to be taken into account as well. These preferences are even less likely to be known by the originator of communications.

The MIMI framework hypothesizes the existence of a discovery or directory service to solve this problem. The discovery service would allow the originator to take a servide independent identifier for a target - such as a mobile phone number or email address - and perform a lookup to determine the preferred service of the target user, along with their identifier within that service.

This document proposes a specific solution for the discovery service, a new protocol called the Global Lookup and Discovery of Services (GLADOS). GLADOS is a centralized internet service, serving the common good of Internet users. It provides REST-based APIs that support the registration and lookup of mappings. GLADOS is not meant to be directly accessed by consumers. Rather, it is accessed by communications applications operating on a user's behalf.

2. Definitions

3. Prior Efforts

Discovery services are far from new on the Internet.

The whois protocol, originally specified in [RFC0954] and later revised by [RFC3912], was largely focused on the mapping of domain names, to services associated with those domain names, and was one of the first discovery services deployed on the Internet. The DNS SRV record was specified in [RFC2782] and allows a similar discovery process - given a domain name, allows a querier to learn the set of services, such as VOIP based on the Session Initiation Protocol (SIP) [RFC3261] [RFC3263]. Whois and DNS SRV records both assumed that the lookup was keyed by a domain name, and thus they were not that useful for looking up an identifier that is not domain scoped, such as a mobile phone number.

This was first addressed through the specification of ENUM [RFC3761] in 2004. ENUM defined the usage of DNS to lookup phone numbers, by convering a phone number to a DNS name by reversing the digits and adding the suffix "e164.arpa". This allowed portions of the namespace to be delegated to telco providers that owned the number prefix in question. Though technically simple to define, its deployment was hampered by the challenges of establishing authority for the prefixes. It also had a network effects challenge - its utility was limited until there was a critical mass of numbers in the system. It thus became hard to justify the investment of contributing numbers to ENUM. It also suffered from an incentive problem - what was the business value for the telcos to participate in the activity? These challenges resulted in a failure of ENUM adoption.

Another attempt was made with ViPR (Verification Involving PSTN Reahability) [I-D.rosenberg-dispatch-vipr-overview] [I-D.petithuguenin-vipr-pvp]. VIPR made used of a peer-to-peer network based on RELOAD (Resource Location and Discovery) [RFC6940], running between enterprises. It solved the problem of authority problem by authorizing records based on proof of forward routability. However, it had the same network effects problem as ENUM. It also addressed the incentive problem, by focusing on enterprises for which bypassing the phone network would provide cost savings. However, the network effects problem proved insurmountable (amongst other challenges unrelated to the protocol), and it was never widely deployed.

Discovery and lookup services are now common place on the Internet but are scoped entirely within large providers, such as Facebook, Twitter, WhatsApp and other providers.

The MIMI discovery service requires a solution that spans across providers.

4. Core Requirements

There are four key requirements:

  1. Mapping: The service must provide a way to map from a SII to a SSI.

  2. Validity: The mappings provided by the service must be represent the wishes of the user associated with the SII, mapping to an application they are a user of, and the mapped SSI must be the one associated with this user. The core issue is one of trust, and how to determine that the mappings provided by the service are accurate.

  3. Critical Mass: The network effects problem is perhaps the hardest to solve. But, to be viable, any solution must be able to reach a critical mass of mappings so that it becomes useful to consume, and thus useful to further populate.

  4. Incentive Alignment: There must be an incentive structure which motivates the population of mappings into the service, and for the consumption of those mappings.

Beyond these, there are many other requirements related to security and information privacy.

5. GLADOS Overview

Global Lookup and Discovery of Services (GLADOS) involves a central provider - simply called glados - that provides the needed mapping function. This mapping function is provided by a REST API. The most important idea behind glados is that this mapping function is not accessed directly by consumers. Instead, it is accessed indirectly - via communications applications that act on the user's behalf - the same providers that would participate in MIMI. In addition to providing a mapping API, glados provides two sets of APIs for registering mappings. The first is a bulk API, enabling a messaging provider to register mappings it already has. The second is an API by which glados can construct the mapping through forwarding routability - sending an SMS or an email - on behalf of the provider. A high level view of it can be seen in the following figure:

            +--------+
            | glados |
            +--------+
                 |
      +----------+----------+
      |          |          |
 +--------+ +--------+ +--------+
 |  App   | |  App   | |  App   |
 |Provider| |Provider| |Provider|
 |   1    | |   2    | |   3    |
 +--------+ +--------+ +--------+
  |      |        |     |      |
  |      |        |     |      |
+----+ +----+  +----+  +----+ +----+
|User| |User|  |User|  |User| |User|
|  1 | | 2  |  | 3  |  | 4  | | 5  |
+----+ +----+  +----+  +----+ +----+
Figure 1: GLADOS Architecture

The end users never see glados. No end user has an account on it; they dont see it as a brand or know of it. It is rather a service largely invisible to end users, similar to the DNS.

The entities that access glados are application providers. Through an enrollment process, an app provider obtains authorization to access glados for mappings, and to register mappings through either the bulk API or the mapping creation API. As part of this process, an OAuth ClientID and secret are generated, and provided to the app provider. The app provider can uses these to obtain access tokens needed for accessing the glados APIs. Glados APIs are accessed via server-to-server communications, and make use of mutual TLS to provide an additional layer of authentication as well as ensuring that the glados client ID, secret and access tokens remain on servers and dont make their way to the clients provided by the providers.

5.1. Creation

GLADOS is meant to be a singleton provider - there is only one on the entire Internet. GLADOS would be established as new non-profit organization, or perhaps established as a new division of an existing non-profit (for example, LetsEncrypt). The IETF would publish an RFC which defines a set of requirements and processes for selection of a corporation to act as the GLADOS provider, and then an IETF administrative function would perform that RFP process and select a vendor.

There are multiple techniques for funding, including having ISOC fund it, having it be its own charity, or by having it charge the providers for its services. The strawman proposal is that it would charge providers for its service, with pricing that is set just enough to cover costs. Any profit would be given to ISOC as charity. The benefit of charging for access is that the costs would scale with the size of the provider, so that larger providers (like a Facebook or Google) would pay more, while smaller providers (like Wire), would pay less.

The vendor would then run the glados service globally, implementing the protocols and processes defined by the IETF.

An alternative model is one that is closer to domain name registrations. There can be multiple vendors who provide APIs for creation of mappings, and then all of these vendors share their mappings with each other. The sharing process is of course complicated, and it runs the risk of malicious providers that dont respect the privacy, security or other aspects of the specifications. With the singleton provider model, the IETF can establish processes for audit and reporting, which are enforced by the IETF administrative function and required for continued approval of that vendor to act as the single glados provider.

5.2. Enrollment

An application provider that wishes to participate in the mimi federation enrolls with glados.

This enrollment is a manual process, and as part of it, the glados provider will provide a series of audit and validation steps to make sure the app provider is legitimate. This validation process would involve verifying that the app provider is a legitimate business, verifying that their applications are available to consumers on mobile platforms and/or web, validating that the application is indeed a messaging app by creating an account and using it, verifying that it has other users and has reasonable reviews and ratings within app stores. Most importantly, it will try to validate that the application provider is not a source of spam. The glados vendor would define these processes, and they would be made publically available to all.

Why are these checks needed?

The main problem they are trying to solve, is to reduce the risk of the mapping APIs being used for malicious purposes, including spam. Once fully populated, the glados database will contain entries for a significant percentage of the users on the planet, indicating what providers they are using for various communications services. This is valuable information, and could be used for ill. For example, a malicious provider might iterate through the mapping APIs using databases of user email addresses and phone numbers, to build its own directory of users and what apps they are on. It might then send those users spam messages on the various providers. Validating the app providers is one way this is prevented.

Once glados has approved the application vendor, they are provided a traditional OAuth ClientID and Secret, which can be used to obtain access tokens for using the glados APIs.

5.3. Mapping Query

The mapping Query API is a simple REST API that takes, as input, an SII. This is looked up in the glados database, and mapped to the preferred SSI for the user. The means by which preferences are established, is discussed below. The resulting SSI is returned to the requesting application provider.

The mapping API would include the access token from the provider, allowing it to know which provider is requesting the mapping.

A key requirement for glados is that it will impose rate controls to help prevent against the APIs being used maliciously. Glados knows, for any provider, how many users it has, because that provider will have to register its own users as described below. With knowledge of how many users the provider has, along with statistics on the typical number of messages sent between providers (and thus the number of mapping requests typically made), glados can dynamically create reasonable rate limits to make sure that the volume of mapping API requests is reasonable for the provider. This is a second way in which glados prevents the mapping APIs being used for malicious purposes.

Note that the mapping query API is not an enumeration API. It is not possible for a provider to list users. It requires the SII to be provided, and for that SII, it returns the mapped SSI. It is also important to note that the mapping query API is not a batch API either; it is one mapping request at a time. All of these help mitigate against spam and enumeration attacks.

5.4. Mapping Creation

The primary way in which mappings are created in glados are created, is via the mapping creation flow. This flow is shown below:


+-------+                   +-----------+       +---------+
| user  |                   | provider  |       | glados  |
+-------+                   +-----------+       +---------+
    |                             |                  |
    | access app                  |                  |
    |---------------------------->|                  |
    |                             |                  |
    |       enter email or number |                  |
    |<----------------------------|                  |
    |                             |                  |
    | SII                         |                  |
    |---------------------------->|                  |
    |                             | ---------------\ |
    |                             |-| create unique| |
    |                             | | userID       | |
    |                             | |--------------| |
    |                             |                  |
    |                             | create map(      |
    |                             |  userID, SII)    |
    |                             |----------------->|
    |                             |                  |
    |                             |   email or SMS   |
    |                             |   with code      |
    |<-----------------------------------------------|
    |                             |                  |
    | enter code                  |                  |
    |---------------------------->|                  |
    |                             |                  |
    |                             | validation code  |
    |                             |----------------->|
    |                             |                  | ----------\
    |                             |                  |-| store   |
    |                             |                  | |---------|
    |                             |                  |
    |                             | registered       |
    |                             |<-----------------|
    |                             |                  |
Figure 2: Mapping Operation

The mapping operation is best understood by considering the case of a brand new user creating an account on the provider. As part of the new user onboarding process in the app, the user will be prompted to enter their email or mobile number. The provider can choose whether to request email or phone number or both, as a matter of provider policy and design. This is something users are already used to doing as part of application onboarding. The flow described here replaces that flow, with one performed via glados instead whatever SMS or email provider the application provider would have used previously.

The application provider will create its own unique ID for the user, scoped within its own application. This ID need only be unique within the application provider. Once the application provider has collected the SII and generated this ID - they are sent to glados. Using the acccess token, glados will know who the application provider is, and thus be able to construct the SSI by combining the provider userID, with the providerID implied by the access token.

Glados will then construct a short live code, and either email or SMS it to the user. THe user will receive this text or email, and then copy the code into the app. It is important for the security of this solution that the provider - who is only partially trusted here - does not know this prior to the user entering it. Once the user has entered the code, the provider invokes another API on glados, providing the code along with the userID provided previously. Glados matches the code with what it had previously sent. If there is a match, it considers the mapping validated, and stores it. It informs the app provider that the code has been confirmed. This allows the app provider to retain its own mapping too, as they do today.

This flow is meant to protect against a malicious provider trying to register mappings that do not actually correspond to their own users. Consider a malicious provider who makes up a set of userIDs, and then tries to register made-up phone numbers or email addresses for those users. They might do this in order to steal messaging or calls targeted to users with those numbers or emails. Consider for example, a malicious provider that tries to register the emails of wealthy CEOs or political leaders, in order to receive messages targeted for them. Should a malicious provider do this, glados will send en email or SMS to that user with the code. The malicious provider does not have that code, and thus would not be able to complete the mapping creation operation.

There are several subcases worth considering.

5.4.1. Mapping Exists on Other Provider

Consider the case where provider 1 establishes a mapping for an SII, but a mapping already exists for that SII on a different provider.

In that case, glados needs to establish a preference, including termination of the prior mapping. To facilitate that, in the response provided to the new provider, it will include an indication that there is already a mapping in the old provider, and include that provider ID and name. The new provider would then render to the end user a choice - whether to invalidate the prior mapping, or to keep it and make this new application the preferred one. Using another REST API call, the new provider can then instruct glados to delete the old mapping or make the new one the preferred choice.

Through a webhook, the old provider will be notified that the mapping has been removed and/or preference established for the new provider. This will allow the old provider to update there databases, and also inform the user of this change in the old application.

The notification in the old application also helps deal with the case of a malicious provider that always promotes its own app as the preferred app and/or removes the old mapping, against the user's wishes. The old provider will be notified, and this can be shown to the user. If done malicisously, the user can request their old app to re-establish the mapping, change the preference back, or to report the change as malicious. All of those operations would be available to the old provider via API. In the case where the user reports the change as malicious, this would be a strike against the reputation of the new provider. With sufficient strikes, glados can further rate limit that provider or remove their access entirely.

5.4.2. Phone Number Moves

In this case, user A had a particular phone number, and a registration was made using their app provider. User A then gives up this phone number, and a few months later, it is allocated to user B. User B goes and enters this same phone number - with either the same or a different provider.

In practice, this case is indistinguishable from the prior one. User B would see, in the UI of their app, that a previous registration exists for a different provider. They would then select the option to remove that old mapping for user A.

At the point where user B has obtained the number from their telco, and begun to give it out to friends and family, but has NOT used it with any messaging application, new contact requests for that number will continue to be delivered to user A via their current application. This is definitely not a good thing, and is one of the main limitations of this proposal. It can be somewhat remediated by periodic refresh of the mapping, but this is bothersome to users and is not current practice.

That said, this same limitation exists within existing messaging providers. Glados doesnt make the problem worse, but it doesnt make it better.

5.5. Bulk Registration

A key problem that glados needs to solve is the network effect problem. The mapping creation API above works well, but if we were to depend on that, glados would begin day one with zero phone numbers.

To resolve this, glados will provide a bulk API that allows selected providers to upload mappings, and glados will just trust them without sending confirmation emails or SMS messages. This API would be made available selectively, only to the handful of known, large providers - Facebook Messenger, WhatsApp, iMessage - and perhaps that's it. With just those three, glados would have critical mass of mappings to bootstrap the ongoing registration process described above, which would be used by all of the other smaller providers.

The bulk registration process provides full trust in the provider, that they are only registering numbers and email addresses that they have actually verified. This is why it can only be done with the handful of highly known vendors.

The final piece of the puzzle is incentive. What is the incentive for the largest providers to do this? They are, in essence, giving up their crown jewels - a set of validated phone numbers and emails. The answer is the same as mimi as a whole. They would be compelled to do so through the regulatory actions of the EU or other bodies. WIthout that, it is unlikely that this proposal would work.

6. Security Considerations

Security is paramount and is at the center of this proposal.

6.1. Spam Prevention

The main security worry is that of a malicious messaging provider whose primary interest is the generation of spam. To generate that spam to different users, this malicious messaging provider would take a list of email addresses and phone numbers - all of which are readily obtained - and run a high volume of mapping request operations to obtain an SSI for those users. Using the MIMI protocols, the malicious provider would then spam the user.

This attack is partly mitigated by the MIMI protocols themselves, whih require a user to agree to a connection request from a new user (NOTE: this is not yet finalized as a feature of the protocols). However, this still enables the spamming of connection requests. These connection requests do convey content - a display name, a user identifier, and sometimes an avatar or perhaps even an initial message. More than enough to deliver content and thus an appealing vehicle. The glados protocols provide additional protection from this.

The protection is accomplished through the several aspects of the glados system. First, providers cannot invoke mapping request APIs unless they've enrolled. The enrollment process includes an audit and validation process which ensures the app is a legitimate messaging app. Should a malicious application anyway pass this gate, there is another protection via rate limiting of mapping request invocations. These are rate limited based on the number of enrolled users in the application. A malicious app would need to fake a large number of enrollments to obtain enough rate to usefully spam connection requests. Glados can additionally use analytics to look for odd patterns in registrations, including clearly fake or genreated email addresses, overlaps with existing email addresses and so on.

The spam prevention aspects of glados also make it attractive for app providers to enroll, as another form of incentive.

6.2. Stolen Provider Credentials

In this attack, a malicious provider has obtained credentials - clientiD and secret, or access token, for a valid provider.

This is prevented in part through normal techniques - encrypted connections for all glados REST API calls for example.

There is an additional risk - that the clientID and secret and/or access tokens are placed onto the mobile or web application for that provider. A malicious user might try to reverse engineer the client, or inspect memory or disk, in order to get access to these secrets. Given the high privelege associated with these APIs, that is a real risk.

To prevent that, glados adds a requirement for MTLS between the provider and glados. This makes it impossible to use from a web application. Though technically possible in a mobile client, it is unlikely that a legitimate provider would ever place such a certificate on a mobile device. (NOTE: not sure this is really an issue).

7. Informative References

[I-D.ietf-mimi-content]
Mahy, R., "More Instant Messaging Interoperability (MIMI) message content", Work in Progress, Internet-Draft, draft-ietf-mimi-content-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-mimi-content-00>.
[I-D.petithuguenin-vipr-pvp]
Petit-Huguenin, M., Rosenberg, J., and C. F. Jennings, "The Public Switched Telephone Network (PSTN) Validation Protocol (PVP)", Work in Progress, Internet-Draft, draft-petithuguenin-vipr-pvp-04, , <https://datatracker.ietf.org/doc/html/draft-petithuguenin-vipr-pvp-04>.
[I-D.ralston-mimi-linearized-matrix]
Ralston, T. and M. Hodgson, "Linearized Matrix", Work in Progress, Internet-Draft, draft-ralston-mimi-linearized-matrix-02, , <https://datatracker.ietf.org/doc/html/draft-ralston-mimi-linearized-matrix-02>.
[I-D.rosenberg-dispatch-vipr-overview]
Rosenberg, J., Jennings, C. F., and M. Petit-Huguenin, "Verification Involving PSTN Reachability: Requirements and Architecture Overview", Work in Progress, Internet-Draft, draft-rosenberg-dispatch-vipr-overview-04, , <https://datatracker.ietf.org/doc/html/draft-rosenberg-dispatch-vipr-overview-04>.
[RFC0954]
Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC 954, DOI 10.17487/RFC0954, , <https://www.rfc-editor.org/info/rfc954>.
[RFC2782]
Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, , <https://www.rfc-editor.org/info/rfc2782>.
[RFC3261]
Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, , <https://www.rfc-editor.org/info/rfc3261>.
[RFC3263]
Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, , <https://www.rfc-editor.org/info/rfc3263>.
[RFC3761]
Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, DOI 10.17487/RFC3761, , <https://www.rfc-editor.org/info/rfc3761>.
[RFC3912]
Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, , <https://www.rfc-editor.org/info/rfc3912>.
[RFC6940]
Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, , <https://www.rfc-editor.org/info/rfc6940>.

Author's Address

Jonathan Rosenberg
Five9