Network Working Group J. Peterson
Internet-Draft Neustar
Intended status: Standards Track 21 April 2022
Expires: 23 October 2022
Short-Lived Certificates for Secure Telephone Identity
draft-peterson-stir-certificates-shortlived-03
Abstract
When certificates are used as credentials to attest the assignment of
ownership of telephone numbers, some mechanism is required to provide
certificate freshness. This document specifies short-lived
certificates as a means of guaranteeing certificate freshness for
secure telephone identity (STIR), in particular relying on the
Automated Certificate Management Environment (ACME) to allow signers
to acquire certifcates as needed.
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 23 October 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Peterson Expires 23 October 2022 [Page 1]
Internet-Draft STIR Certs Short April 2022
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
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. Short-lived certificates for STIR . . . . . . . . . . . . . . 3
4. Certificate Acquisition with ACME . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The STIR problem statement [RFC7340] discusses many attacks on the
telephone network that are enabled by impersonation, including
various forms of robocalling, voicemail hacking, and swatting. One
of the most important components of a system to prevent impersonation
is the implementation of credentials which identify the parties who
control telephone numbers. The STIR certificates [RFC8226]
specification describes a credential system based on [X.509] version
3 certificates in accordance with [RFC5280] for that purpose. Those
credentials can then be used by STIR authentication services
[RFC8224] to sign PASSporT objects [RFC8225] carried in a SIP
[RFC3261] request.
Peterson Expires 23 October 2022 [Page 2]
Internet-Draft STIR Certs Short April 2022
The STIR certificates document specifies an extension to X.509 that
defines a Telephony Number (TN) Authorization List that may be
included by certificate authorities in certificates. This extension
provides additional information that relying parties can use when
validating transactions with the certificate: either in the form of
Service Provider Codes (SPCs) or telephone numbers. Telephone
numbers or number ranges are commonly used in delegate STIR
certificates [RFC9060]. When a SIP request, for example, arrives at
a terminating administrative domain, the calling number attested by
the SIP request can be compared to the TN Authorization List of the
delegate certificate that signed the request to determine if the
caller is authorized to use that calling number in SIP.
No specific recommendation is made in the STIR certificates document
for a means of determining the freshness of certificates with a TN
Authorization List. This document explores how short-lived
certificates could be used as a means of preserving that freshness.
Short-lived certificates also have a number of other desirable
properties that fulfill important operational requirements for
network operators. The use of the Automated Certificate Management
Environment (ACME) [RFC8555] to manage these short-lived certificates
is the focus of the architecture specified, in particular adapting
the Short-Term Automatically Renewed (STAR) [RFC8739] mechanism to
STIR. The interaction of STIR with ACME has already been explored in
[I-D.ietf-acme-authority-token-tnauthlist].
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. Short-lived certificates for STIR
While there is no easy definition of what constitutes a "short-lived"
certificate, the term typically refers to certificates that are valid
only for days or even hours, as opposed to the months or years common
in traditional public key infrastructures. When the private keying
material associated with that has an expiry of months or years is
compromised by an adversary, the issuing authority must revoke the
certificate, which requires relying parties to review certificate
revocation lists or to access real-time status information with
protocols such as OCSP. Short-lived certificates offer an
alternative where, if compromised, certificates will shortly expire
anyway, and rather than revoking and reissuing the certificate in
response to a crisis, certificates routinely roll-over and cannot be
Peterson Expires 23 October 2022 [Page 3]
Internet-Draft STIR Certs Short April 2022
cached for a long term by relying parties, minimizing their value to
attackers.
One of the additional benefits of using short-lived certificates is
that they do not require relying parties to perform any certificate
freshness check. The trade-off is that the signer must acquire new
certificates frequently, so the cost of round-trip times to the
certificate authority is paid on the signer's side rather than the
verifier's side; however, in environments where many parties may rely
on a single certificate, or at least where a single certificate will
be used to sign many transactions during its short lifetime, the
overall architecture will incur fewer round-trip times to the
certificate authority and thus less processing delay.
In the STIR context, the TN Authorization List defined in [RFC8226]
adds a new wrinkle to the behavior of short-lived certificates,
especially when it is populated with telephone numbers or number
ranges instead of Service Provider Codes (SPCs). A subject may have
authority over multiple telephone numbers, but a particular
certificate issued to that subject could attest the authority over
all, some, or just one of those telephone numbers. Short-lived
certificates permit a more on-demand certification process, where
subjects acquire certificates as needed, potentially in reaction to
calls being placed. A STIR authentication service could even acquire
a new certificate on a per-call basis that can only sign for the
calling party number of the call in question. At the other end of
the spectrum, a large enterprise service provider could acquire a
certificate valid for millions of numbers, but expire the certificate
after a very short duration - on the order of hours - to reduce the
risk that the certificate would be compromised.
This inherent flexibility in the short-lived certificate architecture
would also permit authentication services to implement very narrow
policies for certificate usage. A large service provider who wanted
to avoid revealing which phone numbers they controlled, for example,
could provide no information in the certificate that signs a call
other than just the single telephone number that corresponds to the
calling party's number. How frequently the service provider feels
that they need to expire that certificate and acquire a new one is
entirely a matter of policy to them. This makes it much harder for
entities monitoring signatures over calls to guess who owns which
numbers, and provides a much more complicated threat surface for
attackers trying to compromise the service.
In order to reduce the burden on verification services, an
authentication service could also piggyback a short-lived certificate
onto the signed SIP request, so that no network lookup and consequent
round-trip delay would be required on the terminating side to acquire
Peterson Expires 23 October 2022 [Page 4]
Internet-Draft STIR Certs Short April 2022
the new certificate. [RFC8224] already provides a way of pointing to
a certificate in a MIME body associated with the SIP request. Future
work could specify other means of carrying certificates within SIP
requests via a header rather than a body, to optimize for
intermediaries adding and extracting these certificates.
4. Certificate Acquisition with ACME
One of the primary challenges facing short-lived certificates is
building an operational system that allows signers to acquire new
certificates and put them to immediate use. ACME [RFC8555] is
designed for exactly this purpose. After a client registers with an
ACME server, and the authority of the client for the names in
question is established (through means such as
[I-D.ietf-acme-authority-token-tnauthlist]), the client can at any
time apply for a certificate to be issued by sending an appropriate
JSON request to the server. That request will contain a CSR
[RFC2986] indicating the intended scope of authority as well the
validity interval of the certificate in question. Ultimately, this
will enable the client to download the certificate from a certificate
URL designated by the server.
ACME is based on the concept that clients establish accounts at an
ACME server, and that through challenges, the server learns which
identifiers it will issue for certificates requested for an account.
Any given certificate issued for an account can be for just one of
those identifiers, or potentially for more: this is determined by the
CSR that an ACME client creates for a particular order. Thus, a
service provider with authority for millions of identifiers - that
is, millions of telephone numbers - could create a CSR for an ACME
order that requests a certificate only associated with one of those
telephone numbers if it so desired. The same would be true of
certificates based on Service Provider Codes (SPCs) as described in
[RFC8226]: a service provider might have just one SPC or perhaps
many. ACME thus puts needed flexibility into the hands of the
clients requesting certificates to determine how much of their
authority they want to invest in any given certificate.
ACME also provides a mechanism that allows the assignee of a number
to delegate temporary authority for it to a user. ACME Short-Term
Automatically-Renewed (STAR [RFC8739]) certificates provide a
property of automatic renewal for ACME orders, one that assumes that
certificates issuance is based on a hierarchical delegation. A
short-term certificate attesting authority for a particular
identifier might be issued for an interval of 72 hours, for example,
by the owner of the identifier to a delegate. In the STAR model, the
interface used by the owner of the identifier and the delegate is out
of the scope of ACME, as it would be for an adaptation of STAR to
Peterson Expires 23 October 2022 [Page 5]
Internet-Draft STIR Certs Short April 2022
telephone numbers (likely it would be an interface similar to MODERN
[RFC8396]). STAR permits the delegate to acquire new certificates
directly from the ACME server at each renewal interval. Because the
owner of the identifier in STAR actually fulfills the ACME challenge
and retrieves the Order ID for the certificate, the owner may at any
time send a certificate termination request to the ACME server, which
will prevent the certificate from being renewed by the delegate at
the next renewal interval.
[I-D.ietf-acme-authority-token-tnauthlist] uses the ATC framework of
[I-D.ietf-acme-authority-token] to generate tokens that are provided
to the CA in response to ACME challenges. For a usage with short-
term certificates, it may make sense for the ATC tokens to have a
relatively long expiry, so that the ACME client does not have to
constantly return to the Token Authority for new tokens.
[TBD: More alignment on ACME and STAR in particular]
5. IANA Considerations
This document contains no actions for the IANA.
6. Privacy Considerations
Short-lived certificates provide attractive privacy properties when
compared to real-time status query protocols like OCSP, which require
relying parties to perform a network dip that can reveal a great deal
about the source and destination of communications. For STIR, these
problems are compounded by the presence of the TN Authorization List
extension to certificates. Short-lived certificates can minimize the
data that needs to appear in the TN Authorization List, and
consequently reduce the amount of information about the caller leaked
by certificate usage to an amount equal to what is leaked by the call
signaling itself.
[More TBD]
7. Security Considerations
This document is entirely about security. For further information on
certificate security and practices, see [RFC5280], in particular its
Security Considerations.
8. Acknowledgments
Stephen Farrell provided key input to the discussions leading to this
document.
Peterson Expires 23 October 2022 [Page 6]
Internet-Draft STIR Certs Short April 2022
9. References
9.1. Normative References
[ATIS-0300251]
ATIS Recommendation 0300251, "Codes for Identification of
Service Providers for Information Exchange", 2007.
[DSS] National Institute of Standards and Technology, U.S.
Department of Commerce | NIST FIPS PUB 186-4, "Digital
Signature Standard, version 4", 2013.
[I-D.ietf-acme-authority-token]
Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME
Challenges Using an Authority Token", Work in Progress,
Internet-Draft, draft-ietf-acme-authority-token-07, 25
October 2021, <https://www.ietf.org/archive/id/draft-ietf-
acme-authority-token-07.txt>.
[I-D.ietf-acme-authority-token-tnauthlist]
Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", Work in
Progress, Internet-Draft, draft-ietf-acme-authority-token-
tnauthlist-08, 27 March 2021,
<https://www.ietf.org/archive/id/draft-ietf-acme-
authority-token-tnauthlist-08.txt>.
[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>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
Peterson Expires 23 October 2022 [Page 7]
Internet-Draft STIR Certs Short April 2022
[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, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <https://www.rfc-editor.org/info/rfc3447>.
[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,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005,
<https://www.rfc-editor.org/info/rfc4055>.
[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online
Certificate Status Protocol (OCSP) Profile for High-Volume
Environments", RFC 5019, DOI 10.17487/RFC5019, September
2007, <https://www.rfc-editor.org/info/rfc5019>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>.
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January
2013, <https://www.rfc-editor.org/info/rfc6818>.
Peterson Expires 23 October 2022 [Page 8]
Internet-Draft STIR Certs Short April 2022
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods
for Generating Key Identifiers Values", RFC 7093,
DOI 10.17487/RFC7093, December 2013,
<https://www.rfc-editor.org/info/rfc7093>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[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>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.
[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>.
Peterson Expires 23 October 2022 [Page 9]
Internet-Draft STIR Certs Short April 2022
[RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor
Perales, A., and T. Fossati, "Support for Short-Term,
Automatically Renewed (STAR) Certificates in the Automated
Certificate Management Environment (ACME)", RFC 8739,
DOI 10.17487/RFC8739, March 2020,
<https://www.rfc-editor.org/info/rfc8739>.
[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
September 2021, <https://www.rfc-editor.org/info/rfc9060>.
[X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8,
"Information technology - Open Systems Interconnection -
The Directory: Public-key and attribute certificate
frameworks", 2012.
[X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1,
"Information Technology - Abstract Syntax Notation One:
Specification of basic notation".
[X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2,
"Information Technology - Abstract Syntax Notation One:
Information Object Specification".
[X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2,
"Information Technology - Abstract Syntax Notation One:
Constraint Specification".
[X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3,
"Information Technology - Abstract Syntax Notation One:
Parameterization of ASN.1 Specifications".
9.2. Informative References
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>.
Peterson Expires 23 October 2022 [Page 10]
Internet-Draft STIR Certs Short April 2022
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
Polk, "Server-Based Certificate Validation Protocol
(SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007,
<https://www.rfc-editor.org/info/rfc5055>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<https://www.rfc-editor.org/info/rfc6961>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model",
RFC 7375, DOI 10.17487/RFC7375, October 2014,
<https://www.rfc-editor.org/info/rfc7375>.
[RFC8396] Peterson, J. and T. McGarry, "Managing, Ordering,
Distributing, Exposing, and Registering Telephone Numbers
(MODERN): Problem Statement, Use Cases, and Framework",
RFC 8396, DOI 10.17487/RFC8396, July 2018,
<https://www.rfc-editor.org/info/rfc8396>.
[X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6,
"Information technology - Open Systems Interconnection -
The Directory: Selected Attribute Types", 2012.
Author's Address
Jon Peterson
Neustar, Inc.
Email: jon.peterson@team.neustar
Peterson Expires 23 October 2022 [Page 11]