An Identitifier Proof-of-Possession Mechanism
draft-peterson-mimi-idprover-00

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,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              barnes-mimi-arch/>.

   [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, <https://datatracker.ietf.org/doc/html/draft-ietf-
              acme-telephone-01>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-mahy-mimi-
              identity-02>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-rosenberg-
              mimi-discovery-reqs-00>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc8224>.

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,
              <https://www.rfc-editor.org/info/rfc8555>.

   [RFC8823]  Melnikov, A., "Extensions to Automatic Certificate
              Management Environment for End-User S/MIME Certificates",
              RFC 8823, DOI 10.17487/RFC8823, April 2021,
              <https://www.rfc-editor.org/info/rfc8823>.

   [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,
              <https://www.rfc-editor.org/info/rfc9448>.

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]