Internet DRAFT - draft-peterson-mimi-idprover
draft-peterson-mimi-idprover
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]
