Network Working Group J. Peterson Internet-Draft TransUnion Intended status: Standards Track 4 March 2024 Expires: 5 September 2024 An Identitifier Proof-of-Possession Mechanism draft-peterson-mimi-idprover-00 Abstract This document specifies a means for a third-party service to prove and attest the association of a communications platform with a particular user's telephone number. This capability supports secure enrollment for users of messaging platforms or similar real-time communication applications, for cases where users assert telephone numbers as communication identifiers, and interoperating platforms need to verify that identifiers are being properly attested. This general approach can potentially work with other forms of Service Independent Identifiers (SIIs) in the More Instant Messaging Interoperability (MIMI) framework. 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 5 September 2024. Copyright Notice Copyright (c) 2024 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 (https://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 Peterson Expires 5 September 2024 [Page 1] Internet-Draft ID Prover March 2024 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operations . . . . . . . . . . . . . . . . . . . 3 4. ACME Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Many applications and platforms rely the receipt of a text message, typically a Short Messaging Service (SMS) (typically [SMPP]) message, to enable users to prove their control or ownership of a telephone number. During enrollment with a platform, services will send an SMS to the user's asserted telephone number containing a code or one-time URL; by interacting with that resource, the user proves receipt of the SMS, and thus validates the association of their telephone number with their account on that service. Resources sent via SMS may be used continually after enrollment as a two-factor authentication (TFA) systems. While this mechanism may be sufficient to prove to the service in question that a user controls a telephone number, it does not help services prove to other services that users control telephone numbers and can legitimately assert them as identifiers in communications systems. For example, if Alice enrolls a telephone number with Platform A, and uses that telephone number as her identifier for a messaging service communicating with Bob on Platform B, Platform B has no way of validating how or if Platform A verified Alice's telephone number. This issue arises in interoperable messaging systems that use Service Independent Identifiers (SIIs) as defined in [I-D.rosenberg-mimi-discovery-reqs], and in particular telephone numbers as SIIs. There is a need in interoperable messaging for Peterson Expires 5 September 2024 [Page 2] Internet-Draft ID Prover March 2024 users to be able to assert an SII as an identity, per [I-D.mahy-mimi-identity], in a way that multiple platforms can rely on. While this is often straightforward for Service Specific Identifiers (SSIs) of the form "user@example.com", where clearly "example.com" should can attest to the users of its service, it is more difficult for SIIs, as such identifiers are often not issued or controlled by the messaging platform. This specification thus describes a service that can be invoked by a communications platform to validate a platform user's control of an SII in order to create a publicly-verifiable credential asserting te platform's association with the SII. As prior work for X.509 credentials has been done along similar lines for ACME [RFC8555], this document builds on the existing ACME framework for telephone numbers [RFC9448]. This mechanism might be used to prove possession of SIIs other than telephone numbers, including email addresses. Moreover, this mechanism could be applied to proving identifiers for communications other than textual messaging, including most forms of real-time communications (e.g. STIR [RFC8224]). Note that the aim of this document is not to prove the assignment and delegation of resources in the telephone network: it is instead to establish whether Internet-enabled entites have effective control over the devices associated with those resources. Such credentials are not mutually exclusive with credentials delegated from national authorities. Because the assignment of numbering resources can change over time, demonstrations of effective control must be regularly refreshed -- though because of the diverse capabilities of the devices involved, different schemes for refreshing the challenge, ones that require less direct user supervision, may be available to some devices and not others. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Overview of Operations The following details the basic flow of this identity proving mechanism. Assume a case where a user, either a new user or an existing one updating their account, is interacting with a platform via an appp or over a web interface, and attempting to associate a new telephone number with their account. The exact methods that platforms use to communicate with users in steps 1, 2, and 6 below Peterson Expires 5 September 2024 [Page 3] Internet-Draft ID Prover March 2024 are outside the scope of this document. * A user enrolling with a communications platform asserts their ownership of the telephone number to the platform * The platform instructs the user to await an SMS with a code * Simultaneously, the platform contacts an ACME server with a new order for that telephone number * The ACME server issues a challenge to the platform that requires a code to complete * In parallel, the ACME server also sends an SMS with the code to the asserted telephone number (without sharing that code with the platform) * Upon receipt of the code, the user inputs the code to the communications platform * The platform then responds to the ACME challenge with the code * Provided the challenge is correctly answered, the ACME platform issues the certificate to the communications platform At the end of this process, the platform has a certificate that could be to assert that SII identity in communication (per [I-D.mahy-mimi-identity]), as well as in support of various discovery functions as described in [I-D.rosenberg-mimi-discovery-reqs]. Any relying parties who trust the identity proving service can trust that the platform can assert the telephone number in question, and that the user of that SII is reachable at the platform. Subordinate certificates of various kinds could then be issued to the enrolling user by the platform for various end-to-end security functions. 4. ACME Behavior New-order requests issued by platforms to ACME servers in this specification MUST utilize the TNAuthList ACME identifier type [RFC9448], with a TNAuthList value of a single telephone number. From there, the ACME flow follows that of [RFC8823], although it uses a new ACME challenge type identifier here, "sms-link-00." type (required, string): The string "sms-link-00" Peterson Expires 5 September 2024 [Page 4] Internet-Draft ID Prover March 2024 token (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it. It MUST NOT contain any characters outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). { "type": "sms-link-00", } A client's response to this challenge simply acknowledges that it is ready to receive the validation SMS from the server. On receiving a response, the identity proving service sends an SMS message to the TN being validated containing a code that the client must have a user access in order to complete the challenge. This code is intended to be relayed to the platform to complete the ACME challenge. By allowing a user action to complete the challenge, this validation method supports the use of ACME with SMS endpoints that do not support automated response to challenges; handset support for automated responses to these challenges is outside the scope of this document. The use of six-digit numeric codes is however weidely supported for automatic responses on handsets today. 5. Example TBD. 6. Acknowledgments This document incorporates ideas and text from [I-D.ietf-acme-telephone]. Thanks as well go to Jonathan Rosenberg for his work on these ideas. 7. IANA Considerations TBD. 8. Privacy Considerations TBD. 9. Security Considerations TBD. 10. References Peterson Expires 5 September 2024 [Page 5] Internet-Draft ID Prover March 2024 10.1. Normative References [I-D.barnes-mimi-arch] Barnes, R. L., "An Architecture for More Instant Messaging Interoperability (MIMI)", Work in Progress, Internet- Draft, draft-barnes-mimi-arch-03, 4 March 2024, . [I-D.ietf-acme-telephone] Peterson, J. and R. Barnes, "ACME Identifiers and Challenges for Telephone Numbers", Work in Progress, Internet-Draft, draft-ietf-acme-telephone-01, 30 October 2017, . [I-D.mahy-mimi-identity] Mahy, R., "More Instant Messaging Interoperability (MIMI) Identity Concepts", Work in Progress, Internet-Draft, draft-mahy-mimi-identity-02, 10 July 2023, . [I-D.rosenberg-mimi-discovery-reqs] Rosenberg, J., "MIMI Discovery Requirements and Considerations", Work in Progress, Internet-Draft, draft- rosenberg-mimi-discovery-reqs-00, 27 August 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . Peterson Expires 5 September 2024 [Page 6] Internet-Draft ID Prover March 2024 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [RFC8823] Melnikov, A., "Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates", RFC 8823, DOI 10.17487/RFC8823, April 2021, . [RFC9448] Wendt, C., Hancock, D., Barnes, M., and J. Peterson, "TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token", RFC 9448, DOI 10.17487/RFC9448, September 2023, . 10.2. Informative References [SMPP] SMS Forum v5.0 | 19 February 2003, "Short Message Peer to Peer Protocol Specification", 2003. Author's Address Jon Peterson TransUnion Email: jon.peterson@transunion.com Peterson Expires 5 September 2024 [Page 7]