From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8226.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc8226.txt (limited to 'doc/rfc/rfc8226.txt') diff --git a/doc/rfc/rfc8226.txt b/doc/rfc/rfc8226.txt new file mode 100644 index 0000000..3d3d061 --- /dev/null +++ b/doc/rfc/rfc8226.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Peterson +Request for Comments: 8226 Neustar +Category: Standards Track S. Turner +ISSN: 2070-1721 sn3rd + February 2018 + + + Secure Telephone Identity Credentials: Certificates + +Abstract + + In order to prevent the impersonation of telephone numbers on the + Internet, some kind of credential system needs to exist that + cryptographically asserts authority over telephone numbers. This + document describes the use of certificates in establishing authority + over telephone numbers, as a component of a broader architecture for + managing telephone numbers as identities in protocols like SIP. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8226. + +Copyright Notice + + Copyright (c) 2018 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 and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Peterson & Turner Standards Track [Page 1] + +RFC 8226 STIR Certs February 2018 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. Authority for Telephone Numbers in Certificates .................4 + 4. Certificate Usage with STIR .....................................5 + 5. Enrollment and Authorization Using the TN Authorization List ....6 + 5.1. Constraints on Signing PASSporTs ...........................8 + 5.2. Certificate Extension Scope and Structure ..................8 + 6. Provisioning Private Keying Material ............................9 + 7. Acquiring Credentials to Verify Signatures ......................9 + 8. JWT Claim Constraints Syntax ...................................10 + 9. TN Authorization List Syntax ...................................12 + 10. Certificate Freshness and Revocation ..........................14 + 10.1. Acquiring the TN List by Reference .......................15 + 11. IANA Considerations ...........................................16 + 11.1. ASN.1 Registrations ......................................16 + 11.2. Media Type Registrations .................................16 + 12. Security Considerations .......................................17 + 13. References ....................................................18 + 13.1. Normative References .....................................18 + 13.2. Informative References ...................................20 + Appendix A. ASN.1 Module ..........................................21 + Acknowledgments ...................................................24 + Authors' Addresses ................................................24 + +1. Introduction + + The Secure Telephone Identity Revisited (STIR) problem statement + [RFC7340] identifies the primary enabler of robocalling, vishing + (voicemail hacking), swatting, and related attacks as the capability + to impersonate a calling party number. The starkest examples of + these attacks are cases where automated callees on the Public + Switched Telephone Network (PSTN) rely on the calling number as a + security measure -- for example, to access a voicemail system. + Robocallers use impersonation as a means of obscuring identity. + While robocallers can, in the ordinary PSTN, block (that is, + withhold) their caller identity, callees are less likely to pick up + calls from blocked identities; therefore, appearing to call from some + number, any number, is preferable. Robocallers, however, prefer not + to call from a number that can trace back to the robocaller, and + therefore they impersonate numbers that are not assigned to them. + + One of the most important components of a system to prevent + impersonation is the implementation of credentials that identify the + parties who control telephone numbers. With these credentials, + parties can assert that they are in fact authorized to use telephony + numbers (TNs), and thus they distinguish themselves from + + + +Peterson & Turner Standards Track [Page 2] + +RFC 8226 STIR Certs February 2018 + + + impersonators unable to present such credentials. For that reason, + the STIR threat model [RFC7375] stipulates that "The design of the + credential system envisioned as a solution to these threats must, for + example, limit the scope of the credentials issued to carriers or + national authorities to those numbers that fall under their purview." + This document describes credential systems for telephone numbers + based on [X.509] version 3 certificates in accordance with [RFC5280]. + While telephone numbers have long been part of the X.509 standard + (X.509 supports arbitrary naming attributes to be included in a + certificate; the telephoneNumber attribute was defined in the 1988 + [X.520] specification), this document provides ways to determine + authority more aligned with telephone network requirements, including + extending X.509 with a Telephony Number Authorization List + certificate extension, which binds certificates to asserted authority + for particular telephone numbers or, potentially, telephone number + blocks or ranges. + + In the STIR in-band architecture specified in [RFC8224], two basic + types of entities need access to these credentials: authentication + services and verification services (or verifiers). An authentication + service must be operated by an entity enrolled with the certification + authority (CA) (see Section 5), whereas a verifier need only trust + the trust anchor of the authority and also have a means to access and + validate the public keys associated with these certificates. + Although the guidance in this document is written with the STIR + in-band architecture in mind, the credential system described in this + document could be useful for other protocols that want to make use of + certificates to assert authority over telephone numbers on the + Internet. + + This document specifies only the credential syntax and semantics + necessary to support this architecture. It does not assume any + particular CA or deployment environment. We anticipate that some + deployment experience will be necessary to determine optimal + operational models. + +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. + + + + + + + + +Peterson & Turner Standards Track [Page 3] + +RFC 8226 STIR Certs February 2018 + + +3. Authority for Telephone Numbers in Certificates + + At a high level, this specification details two non-exclusive + approaches that can be employed to determine authority over telephone + numbers with certificates. + + The first approach is to leverage the existing subject of the + certificate to ascertain that the holder of the certificate is + authorized to claim authority over a telephone number. The subject + might be represented as a domain name in the subjectAltName, such as + an "example.net" where that domain is known to relying parties as a + carrier, or represented with other identifiers related to the + operation of the telephone network, including Service Provider Codes + (SPCs) such as Operating Company Numbers (OCNs) or Service Provider + Identifiers (SPIDs) via the TN Authorization List specified in this + document. A relying party could then employ an external data set or + service that determines whether or not a specific telephone number is + under the authority of the carrier identified as the subject of the + certificate and use that to ascertain whether or not the carrier + should have authority over a telephone number. Potentially, a + certificate extension to convey the URI of such an information + service trusted by the issuer of the certificate could be developed + (though this specification does not propose one). Alternatively, + some relying parties could form bilateral or multilateral trust + relationships with peer carriers, trusting one another's assertions + just as telephone carriers in the Signaling System 7 (SS7) network + today rely on transitive trust when displaying the calling party + telephone number received through SS7 signaling. + + The second approach is to extend the syntax of certificates to + include a new attribute, defined here as the TN Authorization List, + which contains a list of telephone numbers defining the scope of + authority of the certificate. Relying parties, if they trust the + issuer of the certificate as a source of authoritative information on + telephone numbers, could therefore use the TN Authorization List + instead of the subject of the certificate to make a decision about + whether or not the signer has authority over a particular telephone + number. The TN Authorization List could be provided in one of two + ways: as a literal value in the certificate or as a network service + that allows relying parties to query in real time to determine that a + telephone number is in the scope of a certificate. Using the TN + Authorization List rather than the certificate subject makes sense + when, for example, for privacy reasons the certificate owner would + prefer not to be identified, or in cases where the holder of the + certificate does not participate in the sort of traditional carrier + infrastructure that the first approach assumes. + + + + + +Peterson & Turner Standards Track [Page 4] + +RFC 8226 STIR Certs February 2018 + + + The first approach requires little change to existing Public Key + Infrastructure (PKI) certificates; for the second approach, we must + define an appropriate enrollment and authorization process. For the + purposes of STIR, the over-the-wire format specified in [RFC8224] + accommodates either of these approaches: the methods for + canonicalizing, for signing, for identifying and accessing the + certificate, and so on remain the same; it is only the verifier + behavior and authorization decision that will change, depending on + the approach to telephone number authority taken by the certificate. + For that reason, the two approaches are not mutually exclusive, and + in fact a certificate issued to a traditional telephone network + service provider could contain a TN Authorization List or not, were + it supported by the CA issuing the credential. Regardless of which + approach is used, certificates that assert authority over telephone + numbers are subject to the ordinary operational procedures that + govern certificate use per [RFC5280]. This means that verification + services must be mindful of the need to ensure that they trust the + trust anchor that issued the certificate and that they have some + means to determine the freshness of the certificate (see Section 10). + +4. Certificate Usage with STIR + + [RFC8224], Section 7.4 requires that all credential systems used by + STIR explain how they address the requirements enumerated below. + Certificates as described in this document address the STIR + requirements as follows: + + 1. The URI [RFC3986] schemes permitted in the SIP Identity header + "info" parameter, as well as any special procedures required to + dereference the URIs: while normative text is given below in + Section 7, this mechanism permits the HTTP [RFC7230], CID + (Content-ID) [RFC2392], and SIP URI schemes to appear in the + "info" parameter. + + 2. Procedures required to extract keying material from the resources + designated by the URI: implementations perform no special + procedures beyond dereferencing the "info" URI. See Section 7. + + 3. Procedures used by the verification service to determine the + scope of the credential: this specification effectively proposes + two methods, as outlined in Section 3: one where the subject (or, + more properly, subjectAltName) of the certificate indicates the + scope of authority through a domain name, and relying parties + either trust the subject entirely or have some direct means of + determining whether or not a number falls under a subject's + authority; and another where an extension to the certificate as + described in Section 9 identifies the scope of authority of the + certificate. + + + +Peterson & Turner Standards Track [Page 5] + +RFC 8226 STIR Certs February 2018 + + + 4. The cryptographic algorithms required to validate the + credentials: for this specification, that means the signature + algorithms used to sign certificates. This specification + REQUIRES that implementations support both the Elliptic Curve + Digital Signature Algorithm (ECDSA) with the P-256 curve (see + [DSS]) and RSA PKCS #1 v1.5 ("PKCS" stands for "Public-Key + Cryptography Standards") (see [RFC8017], Section 8.2) for + certificate signatures. Implementers are advised that the latter + algorithm is mandated only as a transitional mechanism, due to + its widespread use in existing PKIs, but we anticipate that this + mechanism will eventually be deprecated. + + 5. Finally, note that all certificates compliant with this + specification: + + * MUST provide cryptographic keying material sufficient to + generate the ECDSA using P-256 and SHA-256 signatures + necessary to support the ES256 hashed signatures required by + PASSporT [RFC8225], which in turn follows the JSON Web Token + (JWT) [RFC7519]. + + * MUST support both ECDSA with P-256 and RSA PKCS #1 v1.5 for + certificate signature verification. + + This document also includes additional certificate-related + requirements: + + o See Section 5.1 for requirements related to the JWT Claim + Constraints certificate extension. + + o See Section 7 for requirements related to relying parties + acquiring credentials. + + o See Sections 10 and 10.1 for requirements related to certificate + freshness and the Authority Information Access (AIA) certificate + extension. + +5. Enrollment and Authorization Using the TN Authorization List + + This document covers three models for enrollment when using the TN + Authorization List extension. + + The first enrollment model is one where the CA acts in concert with + national numbering authorities to issue credentials to those parties + to whom numbers are assigned. In the United States, for example, + telephone number blocks are assigned to Local Exchange Carriers + (LECs) by the North American Numbering Plan Administration (NANPA), + who is in turn directed by the national regulator. LECs may also + + + +Peterson & Turner Standards Track [Page 6] + +RFC 8226 STIR Certs February 2018 + + + receive numbers in smaller allocations, through number pooling, or + via an individual assignment through number portability. LECs assign + numbers to customers, who may be private individuals or organizations + -- and organizations take responsibility for assigning numbers within + their own enterprise. This model requires top-down adoption of the + model from regulators through to carriers. Assignees of E.164 + numbering resources participating in this enrollment model should + take appropriate steps to establish trust anchors. + + The second enrollment model is a bottom-up approach where a CA + requires that an entity prove control by means of some sort of test + that, as with certification authorities for web PKI, might either be + (1) automated or (2) a manual administrative process. As an example + of an automated process, an authority might send a text message to a + telephone number containing a URL (which might be dereferenced by the + recipient) as a means of verifying that a user has control of a + terminal corresponding to that number. Checks of this form are + frequently used in commercial systems today to validate telephone + numbers provided by users. This is comparable to existing enrollment + systems used by some certificate authorities for issuing S/MIME + credentials for email by verifying that the party applying for a + credential receives mail at the email address in question. + + The third enrollment model is delegation: that is, the holder of a + certificate (assigned by either of the two methods above) might + delegate some or all of their authority to another party. In some + cases, multiple levels of delegation could occur: a LEC, for example, + might delegate authority to a customer organization for a block of + 100 numbers used by an IP PBX, and the organization might in turn + delegate authority for a particular number to an individual employee. + This is analogous to delegation of organizational identities in + traditional hierarchical PKIs who use the name constraints extension + [RFC5280]; the root CA delegates names in sales to the sales + department CA, names in development to the development CA, etc. As + lengthy certificate delegation chains are brittle, however, and can + cause delays in the verification process, this document considers + optimizations to reduce the complexity of verification. + + Future work might explore methods of partial delegation, where + certificate holders delegate only part of their authority. For + example, individual assignees may want to delegate to a service + authority for text messages associated with their telephone number + but not for other functions. + + + + + + + + +Peterson & Turner Standards Track [Page 7] + +RFC 8226 STIR Certs February 2018 + + +5.1. Constraints on Signing PASSporTs + + The public key in the certificate is used to validate the signature + on a JWT [RFC7519] that conforms to the conventions specified in + PASSporT [RFC8225]. This specification supports constraints on the + JWT claims, thereby allowing the CA to grant different permissions to + certificate holders -- for example, those enrolled from + proof-of-possession versus delegation. A Certificate Policy (CP) and + a Certification Practice Statement (CPS) [RFC3647] are produced as + part of the normal PKI bootstrapping process (i.e., the CP is written + first, and then the CA says how it conforms to the CP in the CPS). A + CA that wishes to place constraints on the JWT claims MUST include + the JWT Claim Constraints certificate extension in issued + certificates. See Section 8 for information about the certificate + extension. + +5.2. Certificate Extension Scope and Structure + + This specification places no limits on the number of telephone + numbers that can be associated with any given certificate. Some + service providers may be assigned millions of numbers and may wish to + have a single certificate that can be applied to signing for any one + of those numbers. Others may wish to compartmentalize authority over + subsets of the numbers they control. + + Moreover, service providers may wish to have multiple certificates + with the same scope of authority. For example, a service provider + with several regional gateway systems may want each system to be + capable of signing for each of their numbers but not want to have + each system share the same private key. + + The set of telephone numbers for which a particular certificate is + valid is expressed in the certificate through a certificate + extension; the certificate's extensibility mechanism is defined in + [RFC5280], but the TN Authorization List extension is specified in + this document. + + The subjects of certificates containing the TN Authorization List + extension are typically the administrative entities to whom numbers + are assigned or delegated. For example, a LEC might hold a + certificate for a range of telephone numbers. In some cases, the + organization or individual issued such a certificate may not want to + associate themselves with a certificate; for example, a private + individual with a certificate for a single telephone number might not + want to distribute that certificate publicly if every verifier + immediately knew their name. The certification authorities issuing + certificates with the TN Authorization List extensions may, in + + + + +Peterson & Turner Standards Track [Page 8] + +RFC 8226 STIR Certs February 2018 + + + accordance with their policies, obscure the identity of the subject, + though mechanisms for doing so are outside the scope of this + document. + +6. Provisioning Private Keying Material + + In order for authentication services to sign calls via the procedures + described in [RFC8224], they must hold a private key corresponding to + a certificate with authority over the calling number. [RFC8224] + does not require that any particular entity in a SIP deployment + architecture sign requests, only that it be an entity with an + appropriate private key; the authentication service role may be + instantiated by any entity in a SIP network. For a certificate + granting authority only over a particular number that has been issued + to an end user, for example, an end-user device might hold the + private key and generate the signature. In the case of a service + provider with authority over large blocks of numbers, an intermediary + might hold the private key and sign calls. + + The specification RECOMMENDS distribution of private keys through + PKCS #8 objects signed by a trusted entity -- for example, through + the Cryptographic Message Syntax (CMS) package specified in + [RFC5958]. + +7. Acquiring Credentials to Verify Signatures + + This specification documents multiple ways that a verifier can gain + access to the credentials needed to verify a request. As the + validity of certificates does not depend on the method of their + acquisition, there is no need to standardize any single mechanism for + this purpose. All entities that comply with [RFC8224] necessarily + support SIP, and consequently SIP itself can serve as a way to + deliver certificates. [RFC8224] provides an "info" parameter of the + Identity header; this parameter contains a URI for the credential + used to generate the Identity header. [RFC8224] also requires that + documents that define credential systems list the URI schemes that + may be present in the "info" parameter. For implementations + compliant with this specification, three URI schemes are REQUIRED: + the CID URI, the SIP URI, and the HTTP URI. + + The simplest way for a verifier to acquire the certificate needed to + verify a signature is for the certificate to be conveyed in a + SIP request along with the signature itself. In SIP, for example, a + certificate could be carried in a multipart MIME body [RFC2046], and + the URI in the Identity header "info" parameter could specify that + body with a CID URI [RFC2392]. However, in many environments this + is not feasible due to message size restrictions or lack of necessary + support for multipart MIME. + + + +Peterson & Turner Standards Track [Page 9] + +RFC 8226 STIR Certs February 2018 + + + The Identity header "info" parameter in a SIP request may contain a + URI that the verifier dereferences. Implementations of this + specification are REQUIRED to support the use of SIP for this + function (via the SUBSCRIBE/NOTIFY mechanism) as well as HTTP and + HTTPS. + + Note well that as an optimization, a verifier may have access to a + service, a cache, or other local store that grants access to + certificates for a particular telephone number. However, there may + be multiple valid certificates that can sign a call setup request for + a telephone number, and as a consequence, there needs to be some + discriminator that the signer uses to identify their credentials. + The Identity header "info" parameter itself can serve as such a + discriminator, provided implementations use that parameter as a key + when accessing certificates from caches or other sources. + +8. JWT Claim Constraints Syntax + + Certificate subjects are limited to specific values for PASSporT + claims with the JWT Claim Constraints certificate extension; issuers + permit all claims by omitting the JWT Claim Constraints certificate + extension from the certificate's extension field [RFC5280]. The + extension is non-critical, applicable only to end-entity + certificates, and defined with ASN.1 [X.680] [X.681] [X.682] [X.683] + later in this section. The syntax of the claims is given in + PASSporT; specifying new claims follows the procedures in [RFC8225], + Section 8.3. + + This certificate extension is optional, but if present, it constrains + the claims that authentication services may include in the PASSporT + objects they sign. Constraints are applied by issuers and enforced + by verifiers when validating PASSporT claims as follows: + + 1. mustInclude indicates claims that MUST appear in the PASSporT in + addition to iat, orig, and dest. The baseline claims of PASSporT + ("iat", "orig", and "dest") are considered to be permitted by + default and SHOULD NOT be included. If mustInclude is absent, + iat, orig, and dest MUST appear in the PASSporT. + + 2. permittedValues indicates that if the claim name is present, the + claim MUST contain one of the listed values. + + + + + + + + + + +Peterson & Turner Standards Track [Page 10] + +RFC 8226 STIR Certs February 2018 + + + Consider two examples with a PASSporT claim called "confidence" with + values "low", "medium", and "high": + + o If a CA issues to an authentication service a certificate that + contains the mustInclude JWTClaimName "confidence", then an + authentication service MUST include the "confidence" claim in all + PASSporTs it generates; a verification service will treat as + invalid any PASSporT it receives with a PASSporT claim that + does not include the "confidence" claim. + + o If a CA issues to an authentication service a certificate that + contains the permittedValues JWTClaimName "confidence" and a + permitted "high" value, then an authentication service will treat + as invalid any PASSporT it receives with a PASSporT claim that + does not include the "confidence" claim with a "high" value. + + The JWT Claim Constraints certificate extension is identified by the + following object identifier (OID), which is defined under the id-pe + OID arc defined in [RFC5280] and managed by IANA (see Section 11): + + id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 27 } + + The JWT Claim Constraints certificate extension has the following + syntax: + + JWTClaimConstraints ::= SEQUENCE { + mustInclude [0] JWTClaimNames OPTIONAL, + -- The listed claim names MUST appear in the PASSporT + -- in addition to iat, orig, and dest. If absent, iat, orig, + -- and dest MUST appear in the PASSporT. + permittedValues [1] JWTClaimPermittedValuesList OPTIONAL } + -- If the claim name is present, the claim MUST contain one of + -- the listed values. + ( WITH COMPONENTS { ..., mustInclude PRESENT } | + WITH COMPONENTS { ..., permittedValues PRESENT } ) + + JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) OF + JWTClaimPermittedValues + + JWTClaimPermittedValues ::= SEQUENCE { + claim JWTClaimName, + permitted SEQUENCE SIZE (1..MAX) OF UTF8String } + + JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName + + JWTClaimName ::= IA5String + + + + + +Peterson & Turner Standards Track [Page 11] + +RFC 8226 STIR Certs February 2018 + + +9. TN Authorization List Syntax + + The subjects of certificates containing the TN Authorization List + extension are the administrative entities to whom numbers are + assigned or delegated. When a verifier is validating a caller's + identity, local policy always determines the circumstances under + which any particular subject may be trusted, but the purpose of the + TN Authorization List extension in particular is to allow a verifier + to ascertain when the CA has designated that the subject has + authority over a particular telephone number or number range. The + non-critical TN Authorization List certificate extension is included + in the certificate's extension field [RFC5280]. The extension is + defined with ASN.1 [X.680] [X.681] [X.682] [X.683]. The syntax and + semantics of the extension are as follows. + + The subjects of certificates containing the TN Authorization List + extension are the administrative entities to whom numbers are + assigned or delegated. In an end-entity certificate, the TN + Authorization List indicates the TNs that it has authorized. In a CA + certificate, the TN Authorization List limits the set of TNs for + certification paths that include this certificate. + + The TN Authorization List certificate extension is identified by the + following object identifier (OID), which is defined under the id-pe + OID arc defined in [RFC5280] and managed by IANA (see Section 11): + + id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 } + + The TN Authorization List certificate extension has the following + syntax: + + TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry + + TNEntry ::= CHOICE { + spc [0] ServiceProviderCode, + range [1] TelephoneNumberRange, + one [2] TelephoneNumber + } + + ServiceProviderCode ::= IA5String + + -- SPCs may be OCNs, various SPIDs, or other SP identifiers + -- from the telephone network. + + + + + + + + +Peterson & Turner Standards Track [Page 12] + +RFC 8226 STIR Certs February 2018 + + + TelephoneNumberRange ::= SEQUENCE { + start TelephoneNumber, + count INTEGER (2..MAX), + ... + } + + TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*")) + + The TN Authorization List certificate extension indicates the + authorized phone numbers for the call setup signer. It indicates one + or more blocks of telephone number entries that have been authorized + for use by the call setup signer. There are three ways to identify + the block: + + 1. SPCs as described in this document are a generic term for the + identifiers used to designate service providers in telephone + networks today. In North American context, these would include + OCNs as specified in [ATIS-0300251], related SPIDs, or other + similar identifiers for service providers. SPCs can be used to + indirectly name all of the telephone numbers associated with that + identifier for a service provider. + + 2. Telephone numbers can be listed in a range (in the + TelephoneNumberRange format), which consists of a starting + telephone number and then an integer count of numbers within the + range, where the valid boundaries of ranges may vary according to + national policies. The count field is only applicable to start + fields whose values do not include "*" or "#" (i.e., a + TelephoneNumber that does not include "*" or "#"). count + MUST NOT make the number increase in length (i.e., a + TelephoneNumberRange with TelephoneNumber=10 and count=91 is + invalid); formally, given the inputs count and TelephoneNumber of + length D, TelephoneNumber + count MUST be less than 10^D. + + 3. A single telephone number can be listed (as a TelephoneNumber). + + Note that because large-scale service providers may want to associate + many numbers, possibly millions of numbers, with a particular + certificate, optimizations are required for those cases to prevent + the certificate size from becoming unmanageable. In these cases, the + TN Authorization List may be given by reference rather than by value, + through the presence of a separate certificate extension that permits + verifiers to either (1) securely download the list of numbers + associated with a certificate or (2) verify that a single number is + under the authority of this certificate. For more on this + optimization, see Section 10.1. + + + + + +Peterson & Turner Standards Track [Page 13] + +RFC 8226 STIR Certs February 2018 + + +10. Certificate Freshness and Revocation + + Regardless of which of the approaches in Section 3 is followed for + using certificates, a certificate verification mechanism is required. + However, the traditional problem of certificate freshness gains a new + wrinkle when using the TN Authorization List extension with telephone + numbers or number ranges (as opposed to SPCs), because verifiers must + establish not only that a certificate remains valid but also that the + certificate's scope contains the telephone number that the verifier + is validating. Dynamic changes to number assignments can occur due + to number portability, for example. So, even if a verifier has a + valid cached certificate for a telephone number (or a range + containing the number), the verifier must determine that the entity + that created the PASSporT, which includes a digital signature, is + still a proper authority for that number. + + To verify the status of such a certificate, the verifier needs to + acquire the certificate if necessary (via the methods described in + Section 7) and then would need to either: + + a. Rely on short-lived certificates and not check the certificate's + status, or + + b. Rely on status information from the authority (e.g., the Online + Certificate Status Protocol (OCSP)). + + The trade-off between short-lived certificates and using status + information is that the former's burden is on the front end (i.e., + enrollment) and the latter's burden is on the back end (i.e., + verification). Both impact call setup time, but some approaches to + generating a short-lived certificate, like requiring one for each + call, would incur a greater operational cost than acquiring status + information. This document makes no particular recommendation for a + means of determining certificate freshness for STIR, as this requires + further study and implementation experience. Acquiring online status + information for certificates has the potential to disclose private + information [RFC7258] if proper precautions are not taken. Future + specifications that define certificate freshness mechanisms for STIR + MUST note any such risks and provide countermeasures where possible. + + + + + + + + + + + + +Peterson & Turner Standards Track [Page 14] + +RFC 8226 STIR Certs February 2018 + + +10.1. Acquiring the TN List by Reference + + One alternative to checking certificate status for a particular + telephone number is simply acquiring the TN Authorization List by + reference, that is, through dereferencing a URL in the certificate, + rather than including the value of the TN Authorization List in the + certificate itself. + + Acquiring a list of the telephone numbers associated with a + certificate or its subject lends itself to an application-layer + query/response interaction outside of certificate status, one that + could be initiated through a separate URI included in the + certificate. The AIA extension (see [RFC5280]) supports such a + mechanism: it designates an OID to identify the accessMethod and an + accessLocation, which would most likely be a URI. A verifier would + then follow the URI to ascertain whether the TNs in the list are + authorized for use by the caller. As with the certificate extension + defined in Section 9, a URI dereferenced from an end-entity + certificate will indicate the TNs that the caller has been + authorized. Verifiers MUST support the AIA extension, and the + dereferenced URI from a CA certificate limits the set of TNs for + certification paths that include this certificate. + + HTTPS is the most obvious candidate for a protocol to be used for + fetching the list of telephone numbers associated with a particular + certificate. This document defines a new AIA accessMethod, called + "id-ad-stirTNList", which uses the following AIA OID: + + id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } + + When the "id-ad-stirTNList" accessMethod is used, the accessLocation + MUST be an HTTPS URI. Dereferencing the URI will return the complete + DER-encoded TN Authorization List (see Section 9) for the certificate + with a Content-Type of application/tnauthlist (see Section 11.2). + + Delivering the entire list of telephone numbers associated with a + particular certificate will divulge to STIR verifiers information + about telephone numbers other than the one associated with the + particular call that the verifier is checking. In some environments, + where STIR verifiers handle a high volume of calls, maintaining an + up-to-date and complete cache for the numbers associated with crucial + certificate holders could give an important boost to performance. + + + + + + + + + +Peterson & Turner Standards Track [Page 15] + +RFC 8226 STIR Certs February 2018 + + +11. IANA Considerations + +11.1. ASN.1 Registrations + + This document makes use of object identifiers for the TN certificate + extension defined in Section 9, the "TN List by reference" AIA access + descriptor defined in Section 10.1, and the ASN.1 module identifier + defined in Appendix A. Therefore, per this document, IANA has made + the following assignments, as shown on + : + + o TN Authorization List certificate extension in the "SMI Security + for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry: + + 26 id-pe-TNAuthList + + o JWT Claim Constraints certificate extension in the "SMI Security + for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry: + + 27 id-pe-JWTClaimConstraints + + o TN List by reference access descriptor in the "SMI Security for + PKIX Access Descriptor" (1.3.6.1.5.5.7.48) registry: + + 14 id-ad-stirTNList + + o The TN ASN.1 module in the "SMI Security for PKIX Module + Identifier" (1.3.6.1.5.5.7.0) registry: + + 89 id-mod-tn-module + +11.2. Media Type Registrations + + Type name: application + Subtype name: tnauthlist + Required parameters: None + Optional parameters: None + Encoding considerations: Binary + Security considerations: See Section 12 of RFC 8226 + Interoperability considerations: + The TN Authorization List inside this media type MUST be + DER-encoded TNAuthorizationList. + Published specification: RFC 8226 + Applications that use this media type: + Issuers and relying parties of secure telephone identity + certificates, to limit the subject's authority to a + particular telephone number or telephone number range. + Fragment identifier considerations: None + + + +Peterson & Turner Standards Track [Page 16] + +RFC 8226 STIR Certs February 2018 + + + Additional information: + Deprecated alias names for this type: None + Magic number(s): None + File extension(s): None + Macintosh File Type Code(s): None + Person & email address to contact for further information: + Jon Peterson + Intended usage: COMMON + Restrictions on usage: None + Author: Sean Turner + Change controller: The IESG + +12. Security Considerations + + This document is entirely about security. For further information on + certificate security and practices, see [RFC5280], in particular its + Security Considerations section. + + If a certification authority issues a certificate attesting authority + over many telephone numbers, the TNAuthList element can divulge to + relying parties extraneous telephone numbers associated with the + certificate that have no bearing on any given call in progress. The + potential privacy risk can be exacerbated by the use of AIA, as + described in Section 10.1, to link many thousands of numbers to a + single certificate. Even an SPC in a certificate can be used to link + a certificate to a particular carrier and, with access to industry + databases, potentially the set of numbers associated with that SPC. + While these practices may not cause concern in some environments, in + other scenarios alternative approaches could minimize the data + revealed to relying parties. For example, a service provider with + authority over a large block of numbers could generate short-lived + certificates for individual TNs that are not so easily linked to the + service provider or any other numbers that the service provider + controls. Optimizations to facilitate acquiring short-lived + certificates are a potential area of future work for STIR. + + The TN Authorization List returned through a dereferenced URI is + served over HTTPS; the TN Authorization List is therefore protected + in transit. But, the TN Authorization List served is not a signed + object and therefore the server is trusted to faithfully return the + TN Authorization List provided to it by the list generator. + + + + + + + + + + +Peterson & Turner Standards Track [Page 17] + +RFC 8226 STIR Certs February 2018 + + +13. References + +13.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, "Digital Signature Standard + (DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, + July 2013, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource + Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, + . + + [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, + . + + [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, + . + + [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, + . + + [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, + DOI 10.17487/RFC5958, August 2010, + . + + [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, + . + + + + +Peterson & Turner Standards Track [Page 18] + +RFC 8226 STIR Certs February 2018 + + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, + May 2014, . + + [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token + (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, + . + + [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, + "PKCS #1: RSA Cryptography Specifications Version 2.2", + RFC 8017, DOI 10.17487/RFC8017, November 2016, + . + + [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, + . + + [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion + Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, + . + + [X.509] International Telecommunication Union, "Information + technology - Open Systems Interconnection - The Directory: + Public-key and attribute certificate frameworks", ITU-T + Recommendation X.509, ISO/IEC 9594-8, October 2016, + . + + [X.680] International Telecommunication Union, "Information + Technology - Abstract Syntax Notation One (ASN.1): + Specification of basic notation", ITU-T Recommendation + X.680, ISO/IEC 8824-1, August 2015, + . + + [X.681] International Telecommunication Union, "Information + Technology - Abstract Syntax Notation One (ASN.1): + Information object specification", ITU-T Recommendation + X.681, ISO/IEC 8824-2, August 2015, + . + + + + + + +Peterson & Turner Standards Track [Page 19] + +RFC 8226 STIR Certs February 2018 + + + [X.682] International Telecommunication Union, "Information + Technology - Abstract Syntax Notation One (ASN.1): + Constraint specification", ITU-T Recommendation + X.682, ISO/IEC 8824-3, August 2015, + . + + [X.683] International Telecommunication Union, "Information + Technology - Abstract Syntax Notation One (ASN.1): + Parameterization of ASN.1 specifications", ITU-T + Recommendation X.683, ISO/IEC 8824-4, August 2015, + . + +13.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, + . + + [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, + . + + [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure + Telephone Identity Problem Statement and Requirements", + RFC 7340, DOI 10.17487/RFC7340, September 2014, + . + + [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", + RFC 7375, DOI 10.17487/RFC7375, October 2014, + . + + [X.520] International Telecommunication Union, "Information + technology - Open Systems Interconnection - The Directory: + Selected attribute types", ITU-T Recommendation + X.520, ISO/IEC 9594-6, October 2016, + . + + + + + + + + + + + + +Peterson & Turner Standards Track [Page 20] + +RFC 8226 STIR Certs February 2018 + + +Appendix A. ASN.1 Module + + This appendix provides the normative ASN.1 [X.680] definitions for + the structures described in this specification using ASN.1, as + defined in [X.680], [X.681], [X.682], and [X.683]. + + The modules defined in this document are compatible with the most + current ASN.1 specifications published in 2015 (see [X.680], [X.681], + [X.682], and [X.683]). None of the newly defined tokens in the 2008 + ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, + RELATIVE-OID-IRI, TIME, TIME-OF-DAY) are currently used in any of the + ASN.1 specifications referred to here. + + This ASN.1 module imports ASN.1 from [RFC5912]. + + TN-Module-2016 + { iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-tn-module(89) } + + DEFINITIONS EXPLICIT TAGS ::= BEGIN + + IMPORTS + + id-ad, id-pe + FROM PKIX1Explicit-2009 -- From RFC 5912 + { iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } + + EXTENSION + FROM PKIX-CommonTypes-2009 -- From RFC 5912 + { iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } + + ; + + + + + + + + + + + + + + + + + +Peterson & Turner Standards Track [Page 21] + +RFC 8226 STIR Certs February 2018 + + + -- + -- JWT Claim Constraints Certificate Extension + -- + + ext-jwtClaimConstraints EXTENSION ::= { + SYNTAX JWTClaimConstraints IDENTIFIED BY id-pe-JWTClaimConstraints + } + + id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 27 } + + JWTClaimConstraints ::= SEQUENCE { + mustInclude [0] JWTClaimNames OPTIONAL, + -- The listed claim names MUST appear in the PASSporT + -- in addition to iat, orig, and dest. If absent, iat, orig, + -- and dest MUST appear in the PASSporT. + permittedValues [1] JWTClaimPermittedValuesList OPTIONAL } + -- If the claim name is present, the claim MUST contain one of + -- the listed values. + ( WITH COMPONENTS { ..., mustInclude PRESENT } | + WITH COMPONENTS { ..., permittedValues PRESENT } ) + + JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) Of + JWTClaimPermittedValues + + JWTClaimPermittedValues ::= SEQUENCE { + claim JWTClaimName, + permitted SEQUENCE SIZE (1..MAX) OF UTF8String } + + JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName + + JWTClaimName ::= IA5String + + + + + + + + + + + + + + + + + + + + +Peterson & Turner Standards Track [Page 22] + +RFC 8226 STIR Certs February 2018 + + + -- + -- Telephony Number Authorization List Certificate Extension + -- + + ext-tnAuthList EXTENSION ::= { + SYNTAX TNAuthorizationList IDENTIFIED BY id-pe-TNAuthList + } + + id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 } + + TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry + + TNEntry ::= CHOICE { + spc [0] ServiceProviderCode, + range [1] TelephoneNumberRange, + one [2] TelephoneNumber + } + + ServiceProviderCode ::= IA5String + + -- SPCs may be OCNs, various SPIDs, or other SP identifiers + -- from the telephone network. + + TelephoneNumberRange ::= SEQUENCE { + start TelephoneNumber, + count INTEGER (2..MAX), + ... + } + + TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*")) + + -- TN Access Descriptor + + id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } + + END + + + + + + + + + + + + + + + +Peterson & Turner Standards Track [Page 23] + +RFC 8226 STIR Certs February 2018 + + +Acknowledgments + + Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave + Crocker, Tony Rutkowski, John Braunberger, Eric Rescorla, and Martin + Thomson provided key input to the discussions leading to this + document. Russ Housley provided some direct assistance and text + surrounding the ASN.1 module. + +Authors' Addresses + + Jon Peterson + Neustar, Inc. + + Email: jon.peterson@neustar.biz + + + Sean Turner + sn3rd + + Email: sean@sn3rd.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Peterson & Turner Standards Track [Page 24] + -- cgit v1.2.3