idnits 2.17.1 draft-ietf-stir-certificates-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2017) is 2323 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 997 -- Looks like a reference, but probably isn't: '1' on line 998 -- Looks like a reference, but probably isn't: '2' on line 999 == Missing Reference: 'RFCTBD' is mentioned on line 734, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ATIS-0300251' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Downref: Normative reference to an Informational RFC: RFC 8017 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar 4 Intended status: Standards Track S. Turner 5 Expires: June 17, 2018 sn3rd 6 December 14, 2017 8 Secure Telephone Identity Credentials: Certificates 9 draft-ietf-stir-certificates-17 11 Abstract 13 In order to prevent the impersonation of telephone numbers on the 14 Internet, some kind of credential system needs to exist that 15 cryptographically asserts authority over telephone numbers. This 16 document describes the use of certificates in establishing authority 17 over telephone numbers, as a component of a broader architecture for 18 managing telephone numbers as identities in protocols like SIP. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 17, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Authority for Telephone Numbers in Certificates . . . . . . . 4 57 4. Certificate Usage with STIR . . . . . . . . . . . . . . . . . 5 58 5. Enrollment and Authorization Using the TN Authorization List 6 59 5.1. Constraints on Signing PASSporTs . . . . . . . . . . . . 8 60 5.2. Certificate Extension Scope and Structure . . . . . . . . 8 61 6. Provisioning Private Keying Material . . . . . . . . . . . . 9 62 7. Acquiring Credentials to Verify Signatures . . . . . . . . . 9 63 8. JWT Claim Constraints Syntax . . . . . . . . . . . . . . . . 10 64 9. TN Authorization List Syntax . . . . . . . . . . . . . . . . 11 65 10. Certificate Freshness and Revocation . . . . . . . . . . . . 13 66 10.1. Acquiring the TN List by Reference . . . . . . . . . . . 14 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 11.1. ASN.1 Registrations . . . . . . . . . . . . . . . . . . 15 69 11.2. Media Type Registrations . . . . . . . . . . . . . . . . 16 70 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 73 13.2. Informative References . . . . . . . . . . . . . . . . . 19 74 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20 75 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 78 1. Introduction 80 The Secure Telephone Identity Revisited (STIR) problem statement 81 [RFC7340] identifies the primary enabler of robocalling, vishing 82 (voicemail hacking), swatting, and related attacks as the capability 83 to impersonate a calling party number. The starkest examples of 84 these attacks are cases where automated callees on the Public 85 Switched Telephone Network (PSTN) rely on the calling number as a 86 security measure -- for example, to access a voicemail system. 87 Robocallers use impersonation as a means of obscuring identity. 88 While robocallers can, in the ordinary PSTN, block (that is, 89 withhold) their caller identity, callees are less likely to pick up 90 calls from blocked identities; therefore, appearing to call from some 91 number, any number, is preferable. Robocallers, however, prefer not 92 to call from a number that can trace back to the robocaller, and 93 therefore they impersonate numbers that are not assigned to them. 95 One of the most important components of a system to prevent 96 impersonation is the implementation of credentials that identify the 97 parties who control telephone numbers. With these credentials, 98 parties can assert that they are in fact authorized to use telephony 99 numbers (TNs), and thus they distinguish themselves from 100 impersonators unable to present such credentials. For that reason, 101 the STIR threat model [RFC7375] stipulates that "The design of the 102 credential system envisioned as a solution to these threats must, for 103 example, limit the scope of the credentials issued to carriers or 104 national authorities to those numbers that fall under their purview." 105 This document describes credential systems for telephone numbers 106 based on [X.509] version 3 certificates in accordance with [RFC5280]. 107 While telephone numbers have long been part of the X.509 standard 108 (X.509 supports arbitrary naming attributes to be included in a 109 certificate; the telephoneNumber attribute was defined in the 1988 110 [X.520] specification), this document provides ways to determine 111 authority more aligned with telephone network requirements, including 112 extending X.509 with a Telephony Number Authorization List 113 certificate extension, which binds certificates to asserted authority 114 for particular telephone numbers or, potentially, telephone number 115 blocks or ranges. 117 In the STIR in-band architecture specified in [RFC8224], two basic 118 types of entities need access to these credentials: authentication 119 services and verification services (or verifiers). An authentication 120 service must be operated by an entity enrolled with the certification 121 authority (CA) (see Section 5), whereas a verifier need only trust 122 the trust anchor of the authority and also have a means to access and 123 validate the public keys associated with these certificates. 124 Although the guidance in this document is written with the STIR 125 in-band architecture in mind, the credential system described in this 126 document could be useful for other protocols that want to make use of 127 certificates to assert authority over telephone numbers on the 128 Internet. 130 This document specifies only the credential syntax and semantics 131 necessary to support this architecture. It does not assume any 132 particular CA or deployment environment. We anticipate that some 133 deployment experience will be necessary to determine optimal 134 operational models. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in 141 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 3. Authority for Telephone Numbers in Certificates 146 At a high level, this specification details two non-exclusive 147 approaches that can be employed to determine authority over telephone 148 numbers with certificates. 150 The first approach is to leverage the existing subject of the 151 certificate to ascertain that the holder of the certificate is 152 authorized to claim authority over a telephone number. The subject 153 might be represented as a domain name in the subjectAltName, such as 154 an "example.net" where that domain is known to relying parties as a 155 carrier, or represented with other identifiers related to the 156 operation of the telephone network, including Service Provider Codes 157 (SPCs) such as Operating Company Numbers (OCNs) or Service Provider 158 Identifiers (SPIDs) via the TN Authorization List specified in this 159 document. A relying party could then employ an external data set or 160 service that determines whether or not a specific telephone number is 161 under the authority of the carrier identified as the subject of the 162 certificate and use that to ascertain whether or not the carrier 163 should have authority over a telephone number. Potentially, a 164 certificate extension to convey the URI of such an information 165 service trusted by the issuer of the certificate could be developed 166 (though this specification does not propose one). Alternatively, 167 some relying parties could form bilateral or multilateral trust 168 relationships with peer carriers, trusting one another's assertions 169 just as telephone carriers in the Signaling System 7 (SS7) network 170 today rely on transitive trust when displaying the calling party 171 telephone number received through SS7 signaling. 173 The second approach is to extend the syntax of certificates to 174 include a new attribute, defined here as the TN Authorization List, 175 which contains a list of telephone numbers defining the scope of 176 authority of the certificate. Relying parties, if they trust the 177 issuer of the certificate as a source of authoritative information on 178 telephone numbers, could therefore use the TN Authorization List 179 instead of the subject of the certificate to make a decision about 180 whether or not the signer has authority over a particular telephone 181 number. The TN Authorization List could be provided in one of two 182 ways: as a literal value in the certificate or as a network service 183 that allows relying parties to query in real time to determine that a 184 telephone number is in the scope of a certificate. Using the TN 185 Authorization List rather than the certificate subject makes sense 186 when, for example, for privacy reasons the certificate owner would 187 prefer not to be identified, or in cases where the holder of the 188 certificate does not participate in the sort of traditional carrier 189 infrastructure that the first approach assumes. 191 The first approach requires little change to existing Public Key 192 Infrastructure (PKI) certificates; for the second approach, we must 193 define an appropriate enrollment and authorization process. For the 194 purposes of STIR, the over-the-wire format specified in [RFC8224] 195 accommodates either of these approaches: the methods for 196 canonicalizing, for signing, for identifying and accessing the 197 certificate, and so on remain the same; it is only the verifier 198 behavior and authorization decision that will change, depending on 199 the approach to telephone number authority taken by the certificate. 200 For that reason, the two approaches are not mutually exclusive, and 201 in fact a certificate issued to a traditional telephone network 202 service provider could contain a TN Authorization List or not, were 203 it supported by the CA issuing the credential. Regardless of which 204 approach is used, certificates that assert authority over telephone 205 numbers are subject to the ordinary operational procedures that 206 govern certificate use per [RFC5280]. This means that verification 207 services must be mindful of the need to ensure that they trust the 208 trust anchor that issued the certificate and that they have some 209 means to determine the freshness of the certificate (see Section 10). 211 4. Certificate Usage with STIR 213 [RFC8224], Section 7.4 requires that all credential systems used by 214 STIR explain how they address the requirements enumerated below. 215 Certificates as described in this document address the STIR 216 requirements as follows: 218 1. The URI [RFC3986] schemes permitted in the SIP Identity header 219 "info" parameter, as well as any special procedures required to 220 dereference the URIs: while normative text is given below in 221 Section 7, this mechanism permits the HTTP [RFC7230], CID 222 (Content-ID) [RFC2392], and SIP URI schemes to appear in the 223 "info" parameter. 225 2. Procedures required to extract keying material from the resources 226 designated by the URI: implementations perform no special 227 procedures beyond dereferencing the "info" URI. See Section 7. 229 3. Procedures used by the verification service to determine the 230 scope of the credential: this specification effectively proposes 231 two methods, as outlined in Section 3: one where the subject (or, 232 more properly, subjectAltName) of the certificate indicates the 233 scope of authority through a domain name, and relying parties 234 either trust the subject entirely or have some direct means of 235 determining whether or not a number falls under a subject's 236 authority; and another where an extension to the certificate as 237 described in Section 9 identifies the scope of authority of the 238 certificate. 240 4. The cryptographic algorithms required to validate the 241 credentials: for this specification, that means the signature 242 algorithms used to sign certificates. This specification 243 REQUIRES that implementations support both the Elliptic Curve 244 Digital Signature Algorithm (ECDSA) with the P-256 curve (see 245 [DSS]) and RSA PKCS #1 v1.5 ("PKCS" stands for "Public-Key 246 Cryptography Standards") (see [RFC8017], Section 8.2) for 247 certificate signatures. Implementers are advised that the latter 248 algorithm is mandated only as a transitional mechanism, due to 249 its widespread use in existing PKIs, but we anticipate that this 250 mechanism will eventually be deprecated. 252 5. Finally, note that all certificates compliant with this 253 specification: 255 * MUST provide cryptographic keying material sufficient to 256 generate the ECDSA using P-256 and SHA-256 signatures 257 necessary to support the ES256 hashed signatures required by 258 PASSporT [RFC8225], which in turn follows the JSON Web Token 259 (JWT) [RFC7519]. 261 * MUST support both ECDSA with P-256 and RSA PKCS #1 v1.5 for 262 certificate signature verification. 264 This document also includes additional certificate-related 265 requirements: 267 o See Section 5.1 for requirements related to the JWT Claim 268 Constraints certificate extension. 270 o See Section 7 for requirements related to relying parties 271 acquiring credentials. 273 o See Sections 10 and 10.1 for requirements related to certificate 274 freshness and the Authority Information Access (AIA) certificate 275 extension. 277 5. Enrollment and Authorization Using the TN Authorization List 279 This document covers three models for enrollment when using the TN 280 Authorization List extension. 282 The first enrollment model is one where the CA acts in concert with 283 national numbering authorities to issue credentials to those parties 284 to whom numbers are assigned. In the United States, for example, 285 telephone number blocks are assigned to Local Exchange Carriers 286 (LECs) by the North American Numbering Plan Administration (NANPA), 287 who is in turn directed by the national regulator. LECs may also 288 receive numbers in smaller allocations, through number pooling, or 289 via an individual assignment through number portability. LECs assign 290 numbers to customers, who may be private individuals or organizations 291 -- and organizations take responsibility for assigning numbers within 292 their own enterprise. This model requires top-down adoption of the 293 model from regulators through to carriers. Assignees of E.164 294 numbering resources participating in this enrollment model should 295 take appropriate steps to establish trust anchors. 297 The second enrollment model is a bottom-up approach where a CA 298 requires that an entity prove control by means of some sort of test 299 that, as with certification authorities for web PKI, might either be 300 (1) automated or (2) a manual administrative process. As an example 301 of an automated process, an authority might send a text message to a 302 telephone number containing a URL (which might be dereferenced by the 303 recipient) as a means of verifying that a user has control of a 304 terminal corresponding to that number. Checks of this form are 305 frequently used in commercial systems today to validate telephone 306 numbers provided by users. This is comparable to existing enrollment 307 systems used by some certificate authorities for issuing S/MIME 308 credentials for email by verifying that the party applying for a 309 credential receives mail at the email address in question. 311 The third enrollment model is delegation: that is, the holder of a 312 certificate (assigned by either of the two methods above) might 313 delegate some or all of their authority to another party. In some 314 cases, multiple levels of delegation could occur: a LEC, for example, 315 might delegate authority to a customer organization for a block of 316 100 numbers used by an IP PBX, and the organization might in turn 317 delegate authority for a particular number to an individual employee. 318 This is analogous to delegation of organizational identities in 319 traditional hierarchical PKIs who use the name constraints extension 320 [RFC5280]; the root CA delegates names in sales to the sales 321 department CA, names in development to the development CA, etc. As 322 lengthy certificate delegation chains are brittle, however, and can 323 cause delays in the verification process, this document considers 324 optimizations to reduce the complexity of verification. 326 Future work might explore methods of partial delegation, where 327 certificate holders delegate only part of their authority. For 328 example, individual assignees may want to delegate to a service 329 authority for text messages associated with their telephone number 330 but not for other functions. 332 5.1. Constraints on Signing PASSporTs 334 The public key in the certificate is used to validate the signature 335 on a JWT [RFC7519] that conforms to the conventions specified in 336 PASSporT [RFC8225]. This specification supports constraints on the 337 JWT claims, thereby allowing the CA to grant different permissions to 338 certificate holders -- for example, those enrolled from 339 proof-of-possession versus delegation. A Certificate Policy (CP) and 340 a Certification Practice Statement (CPS) [RFC3647] are produced as 341 part of the normal PKI bootstrapping process (i.e., the CP is written 342 first, and then the CA says how it conforms to the CP in the CPS). A 343 CA that wishes to place constraints on the JWT claims MUST include 344 the JWT Claim Constraints certificate extension in issued 345 certificates. See Section 8 for information about the certificate 346 extension. 348 5.2. Certificate Extension Scope and Structure 350 This specification places no limits on the number of telephone 351 numbers that can be associated with any given certificate. Some 352 service providers may be assigned millions of numbers and may wish to 353 have a single certificate that can be applied to signing for any one 354 of those numbers. Others may wish to compartmentalize authority over 355 subsets of the numbers they control. 357 Moreover, service providers may wish to have multiple certificates 358 with the same scope of authority. For example, a service provider 359 with several regional gateway systems may want each system to be 360 capable of signing for each of their numbers but not want to have 361 each system share the same private key. 363 The set of telephone numbers for which a particular certificate is 364 valid is expressed in the certificate through a certificate 365 extension; the certificate's extensibility mechanism is defined in 366 [RFC5280], but the TN Authorization List extension is specified in 367 this document. 369 The subjects of certificates containing the TN Authorization List 370 extension are typically the administrative entities to whom numbers 371 are assigned or delegated. For example, a LEC might hold a 372 certificate for a range of telephone numbers. In some cases, the 373 organization or individual issued such a certificate may not want to 374 associate themselves with a certificate; for example, a private 375 individual with a certificate for a single telephone number might not 376 want to distribute that certificate publicly if every verifier 377 immediately knew their name. The certification authorities issuing 378 certificates with the TN Authorization List extensions may, in 379 accordance with their policies, obscure the identity of the subject, 380 though mechanisms for doing so are outside the scope of this 381 document. 383 6. Provisioning Private Keying Material 385 In order for authentication services to sign calls via the procedures 386 described in [RFC8224], they must hold a private key corresponding to 387 a certificate with authority over the calling number. [RFC8224] 388 does not require that any particular entity in a SIP deployment 389 architecture sign requests, only that it be an entity with an 390 appropriate private key; the authentication service role may be 391 instantiated by any entity in a SIP network. For a certificate 392 granting authority only over a particular number that has been issued 393 to an end user, for example, an end-user device might hold the 394 private key and generate the signature. In the case of a service 395 provider with authority over large blocks of numbers, an intermediary 396 might hold the private key and sign calls. 398 The specification RECOMMENDS distribution of private keys through 399 PKCS #8 objects signed by a trusted entity -- for example, through 400 the Cryptographic Message Syntax (CMS) package specified in 401 [RFC5958]. 403 7. Acquiring Credentials to Verify Signatures 405 This specification documents multiple ways that a verifier can gain 406 access to the credentials needed to verify a request. As the 407 validity of certificates does not depend on the method of their 408 acquisition, there is no need to standardize any single mechanism for 409 this purpose. All entities that comply with [RFC8224] necessarily 410 support SIP, and consequently SIP itself can serve as a way to 411 deliver certificates. [RFC8224] provides an "info" parameter of the 412 Identity header; this parameter contains a URI for the credential 413 used to generate the Identity header. [RFC8224] also requires that 414 documents that define credential systems list the URI schemes that 415 may be present in the "info" parameter. For implementations 416 compliant with this specification, three URI schemes are REQUIRED: 417 the CID URI, the SIP URI, and the HTTP URI. 419 The simplest way for a verifier to acquire the certificate needed to 420 verify a signature is for the certificate to be conveyed in a 421 SIP request along with the signature itself. In SIP, for example, a 422 certificate could be carried in a multipart MIME body [RFC2046], and 423 the URI in the Identity header "info" parameter could specify that 424 body with a CID URI [RFC2392]. However, in many environments this 425 is not feasible due to message size restrictions or lack of necessary 426 support for multipart MIME. 428 The Identity header "info" parameter in a SIP request may contain a 429 URI that the verifier dereferences. Implementations of this 430 specification are REQUIRED to support the use of SIP for this 431 function (via the SUBSCRIBE/NOTIFY mechanism) as well as HTTP and 432 HTTPS. 434 Note well that as an optimization, a verifier may have access to a 435 service, a cache, or other local store that grants access to 436 certificates for a particular telephone number. However, there may 437 be multiple valid certificates that can sign a call setup request for 438 a telephone number, and as a consequence, there needs to be some 439 discriminator that the signer uses to identify their credentials. 440 The Identity header "info" parameter itself can serve as such a 441 discriminator, provided implementations use that parameter as a key 442 when accessing certificates from caches or other sources. 444 8. JWT Claim Constraints Syntax 446 Certificate subjects are limited to specific values for PASSporT 447 claims with the JWT Claim Constraints certificate extension; issuers 448 permit all claims by omitting the JWT Claim Constraints certificate 449 extension from the certificate's extension field [RFC5280]. The 450 extension is non-critical, applicable only to end-entity 451 certificates, and defined with ASN.1 [X.680] [X.681] [X.682] [X.683] 452 later in this section. The syntax of the claims is given in 453 PASSporT; specifying new claims follows the procedures in [RFC8225], 454 Section 8.3. 456 This certificate extension is optional, but if present, it constrains 457 the claims that authentication services may include in the PASSporT 458 objects they sign. Constraints are applied by issuers and enforced 459 by verifiers when validating PASSporT claims as follows: 461 1. mustInclude indicates claims that MUST appear in the PASSporT in 462 addition to iat, orig, and dest. The baseline claims of PASSporT 463 ("iat", "orig", and "dest") are considered to be permitted by 464 default and SHOULD NOT be included. If mustInclude is absent, 465 iat, orig, and dest MUST appear in the PASSporT. 467 2. permittedValues indicates that if the claim name is present, the 468 claim MUST contain one of the listed values. 470 Consider two examples with a PASSporT claim called "confidence" with 471 values "low", "medium", and "high": 473 o If a CA issues to an authentication service a certificate that 474 contains the mustInclude JWTClaimName "confidence", then an 475 authentication service MUST include the "confidence" claim in all 476 PASSporTs it generates; a verification service will treat as 477 invalid any PASSporT it receives with a PASSporT claim that 478 does not include the "confidence" claim. 480 o If a CA issues to an authentication service a certificate that 481 contains the permittedValues JWTClaimName "confidence" and a 482 permitted "high" value, then an authentication service will treat 483 as invalid any PASSporT it receives with a PASSporT claim that 484 does not include the "confidence" claim with a "high" value. 486 The JWT Claim Constraints certificate extension is identified by the 487 following object identifier (OID), which is defined under the id-pe 488 OID arc defined in [RFC5280] and managed by IANA (see Section 11): 490 id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 27 } 492 The JWT Claim Constraints certificate extension has the following 493 syntax: 495 JWTClaimConstraints ::= SEQUENCE { 496 mustInclude [0] JWTClaimNames OPTIONAL, 497 -- The listed claim names MUST appear in the PASSporT 498 -- in addition to iat, orig, and dest. If absent, iat, orig, 499 -- and dest MUST appear in the PASSporT. 500 permittedValues [1] JWTClaimPermittedValuesList OPTIONAL } 501 -- If the claim name is present, the claim MUST contain one of 502 -- the listed values. 503 ( WITH COMPONENTS { ..., mustInclude PRESENT } | 504 WITH COMPONENTS { ..., permittedValues PRESENT } ) 506 JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) OF 507 JWTClaimPermittedValues 509 JWTClaimPermittedValues ::= SEQUENCE { 510 claim JWTClaimName, 511 permitted SEQUENCE SIZE (1..MAX) OF UTF8String } 513 JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName 515 JWTClaimName ::= IA5String 517 9. TN Authorization List Syntax 519 The subjects of certificates containing the TN Authorization List 520 extension are the administrative entities to whom numbers are 521 assigned or delegated. When a verifier is validating a caller's 522 identity, local policy always determines the circumstances under 523 which any particular subject may be trusted, but the purpose of the 524 TN Authorization List extension in particular is to allow a verifier 525 to ascertain when the CA has designated that the subject has 526 authority over a particular telephone number or number range. The 527 non-critical TN Authorization List certificate extension is included 528 in the certificate's extension field [RFC5280]. The extension is 529 defined with ASN.1 [X.680] [X.681] [X.682] [X.683]. The syntax and 530 semantics of the extension are as follows. 532 The subjects of certificates containing the TN Authorization List 533 extension are the administrative entities to whom numbers are 534 assigned or delegated. In an end-entity certificate, the TN 535 Authorization List indicates the TNs that it has authorized. In a CA 536 certificate, the TN Authorization List limits the set of TNs for 537 certification paths that include this certificate. 539 The TN Authorization List certificate extension is identified by the 540 following object identifier (OID), which is defined under the id-pe 541 OID arc defined in [RFC5280] and managed by IANA (see Section 11): 543 id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 } 545 The TN Authorization List certificate extension has the following 546 syntax: 548 TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry 550 TNEntry ::= CHOICE { 551 spc [0] ServiceProviderCode, 552 range [1] TelephoneNumberRange, 553 one [2] TelephoneNumber 554 } 556 ServiceProviderCode ::= IA5String 558 -- SPCs may be OCNs, various SPIDs, or other SP identifiers 559 -- from the telephone network. 561 TelephoneNumberRange ::= SEQUENCE { 562 start TelephoneNumber, 563 count INTEGER (2..MAX), 564 ... 565 } 567 TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*")) 569 The TN Authorization List certificate extension indicates the 570 authorized phone numbers for the call setup signer. It indicates one 571 or more blocks of telephone number entries that have been authorized 572 for use by the call setup signer. There are three ways to identify 573 the block: 575 1. SPCs as described in this document are a generic term for the 576 identifiers used to designate service providers in telephone 577 networks today. In North American context, these would include 578 OCNs as specified in [ATIS-0300251], related SPIDs, or other 579 similar identifiers for service providers. SPCs can be used to 580 indirectly name all of the telephone numbers associated with that 581 identifier for a service provider. 583 2. Telephone numbers can be listed in a range (in the 584 TelephoneNumberRange format), which consists of a starting 585 telephone number and then an integer count of numbers within the 586 range, where the valid boundaries of ranges may vary according to 587 national policies. The count field is only applicable to start 588 fields' whose values do not include "*" or "#" (i.e., a 589 TelephoneNumber that does not include "*" or "#"). count never 590 makes the number increase in length (i.e., a TelephoneNumberRange 591 with TelephoneNumber=10 with a count=91 will address numbers 592 10-99); formally, given the inputs count and TelephoneNumber of 593 length D the end of the TelephoneNumberRange is: 594 MIN(TelephoneNumber + count, 10^D - 1). 596 3. A single telephone number can be listed (as a TelephoneNumber). 598 Note that because large-scale service providers may want to associate 599 many numbers, possibly millions of numbers, with a particular 600 certificate, optimizations are required for those cases to prevent 601 the certificate size from becoming unmanageable. In these cases, the 602 TN Authorization List may be given by reference rather than by value, 603 through the presence of a separate certificate extension that permits 604 verifiers to either (1) securely download the list of numbers 605 associated with a certificate or (2) verify that a single number is 606 under the authority of this certificate. For more on this 607 optimization, see Section 10.1. 609 10. Certificate Freshness and Revocation 611 Regardless of which of the approaches in Section 3 is followed for 612 using certificates, a certificate verification mechanism is required. 613 However, the traditional problem of certificate freshness gains a new 614 wrinkle when using the TN Authorization List extension with telephone 615 numbers or number ranges (as opposed to SPCs), because verifiers must 616 establish not only that a certificate remains valid but also that the 617 certificate's scope contains the telephone number that the verifier 618 is validating. Dynamic changes to number assignments can occur due 619 to number portability, for example. So, even if a verifier has a 620 valid cached certificate for a telephone number (or a range 621 containing the number), the verifier must determine that the entity 622 that created the PASSporT, which includes a digital signature, is 623 still a proper authority for that number. 625 To verify the status of such a certificate, the verifier needs to 626 acquire the certificate if necessary (via the methods described in 627 Section 7) and then would need to either: 629 a. Rely on short-lived certificates and not check the certificate's 630 status, or 632 b. Rely on status information from the authority (e.g., the Online 633 Certificate Status Protocol (OCSP)). 635 The trade-off between short-lived certificates and using status 636 information is that the former's burden is on the front end (i.e., 637 enrollment) and the latter's burden is on the back end (i.e., 638 verification). Both impact call setup time, but some approaches to 639 generating a short-lived certificate, like requiring one for each 640 call, would incur a greater operational cost than acquiring status 641 information. This document makes no particular recommendation for a 642 means of determining certificate freshness for STIR, as this requires 643 further study and implementation experience. Acquiring online status 644 information for certificates has the potential to disclose private 645 information [RFC7258] if proper precautions are not taken. Future 646 specifications that define certificate freshness mechanisms for STIR 647 MUST note any such risks and provide countermeasures where possible. 649 10.1. Acquiring the TN List by Reference 651 One alternative to checking certificate status for a particular 652 telephone number is simply acquiring the TN Authorization List by 653 reference, that is, through dereferencing a URL in the certificate, 654 rather than including the value of the TN Authorization List in the 655 certificate itself. 657 Acquiring a list of the telephone numbers associated with a 658 certificate or its subject lends itself to an application-layer 659 query/response interaction outside of certificate status, one that 660 could be initiated through a separate URI included in the 661 certificate. The AIA extension (see [RFC5280]) supports such a 662 mechanism: it designates an OID to identify the accessMethod and an 663 accessLocation, which would most likely be a URI. A verifier would 664 then follow the URI to ascertain whether the TNs in the list are 665 authorized for use by the caller. As with the certificate extension 666 defined in Section 9, a URI dereferenced from an end entity 667 certificate will indicate the TNs which the caller has been 668 authorized. Verifiers MUST support the AIA extension and the 669 dereferenced URI from a CA certificate limits the the set of TNs for 670 certification paths that include this certificate. 672 HTTPS is the most obvious candidate for a protocol to be used for 673 fetching the list of telephone numbers associated with a particular 674 certificate. This document defines a new AIA accessMethod, called 675 "id-ad-stirTNList", which uses the following AIA OID: 677 id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } 679 When the "id-ad-stirTNList" accessMethod is used, the accessLocation 680 MUST be an HTTPS URI. Dereferencing the URI will return the complete 681 DER encoded TN Authorization List (see Section 9) for the certificate 682 with a Content-Type of application/tnauthlist (see Section 11.2). 684 Delivering the entire list of telephone numbers associated with a 685 particular certificate will divulge to STIR verifiers information 686 about telephone numbers other than the one associated with the 687 particular call that the verifier is checking. In some environments, 688 where STIR verifiers handle a high volume of calls, maintaining an 689 up-to-date and complete cache for the numbers associated with crucial 690 certificate holders could give an important boost to performance. 692 11. IANA Considerations 694 11.1. ASN.1 Registrations 696 This document makes use of object identifiers for the TN certificate 697 extension defined in Section 9, the "TN List by reference" AIA access 698 descriptor defined in Section 10.1, and the ASN.1 module identifier 699 defined in Appendix A. Therefore, per this document, IANA has made 700 the following assignments, as shown on 701 : 703 o TN Authorization List certificate extension in the "SMI Security 704 for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry: 706 26 id-pe-TNAuthList 708 o JWT Claim Constraints certificate extension in the "SMI Security 709 for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry: 711 27 id-pe-JWTClaimConstraints 713 o TN List by reference access descriptor in the "SMI Security for 714 PKIX Access Descriptor" (1.3.6.1.5.5.7.48) registry: 716 14 id-ad-stirTNList 718 o The TN ASN.1 module in the "SMI Security for PKIX Module 719 Identifier" (1.3.6.1.5.5.7.0) registry: 721 89 id-mod-tn-module 723 11.2. Media Type Registrations 725 Type name: application 726 Subtype name: tnauthlist 727 Required parameters: None 728 Optional parameters: None 729 Encoding considerations: Binary 730 Security considerations: See Section 12 of [RFCTBD] 731 Interoperability considerations: 732 The TN Authorization List inside this media type MUST be 733 DER-encoded TNAuthorizationList. 734 Published specification: [RFCTBD] 735 Applications that use this media type: 736 Issuers and relying parties of secure telephone identity 737 certificates, to limit the subject's authority to a 738 particular telephone number or telephone number range. 739 Fragment identifier considerations: None 740 Additional information: 741 Deprecated alias names for this type: None 742 Magic number(s): None 743 File extension(s): None 744 Macintosh File Type Code(s): None 745 Person & email address to contact for further information: 746 Jon Peterson 747 Intended usage: COMMON 748 Restrictions on usage: None 749 Author: Sean Turner 750 Change controller: The IESG 752 [RFC editor's instruction: Please replace RFCTBD with the 753 RFC number when this document is published.] 755 12. Security Considerations 757 This document is entirely about security. For further information on 758 certificate security and practices, see [RFC5280], in particular its 759 Security Considerations section. 761 If a certification authority issues a certificate attesting authority 762 over many telephone numbers, the TNAuthList element can divulge to 763 relying parties extraneous telephone numbers associated with the 764 certificate which have no bearing on any given call in progress. The 765 potential privacy risk can be exacerbated by the use of AIA, as 766 described in Section 10.1, to link many thousand of numbers to a 767 single certificate. Even an SPC in a certificate can be used to link 768 a certificate to a particular carrier and, with access to industry 769 databases, potentially the set of numbers associated with that SPC. 770 While these practices may not cause concern in some environments, in 771 other scenarios alternative approaches could minimize the data 772 revealed to relying parties. For example, a service provider with 773 authority over a large block of numbers could generate short-lived 774 certificates for individual TNs that are not so easily linked to the 775 service provider or any other numbers that the service provider 776 controls. Optimizations to facilitate acquiring short-lived 777 certificates are a potential area of future work for STIR. 779 The TN Authorization List returned through a dereferenced URI is 780 served over HTTPS; the TN Authorization List is therefore protected 781 in transit. But, the TN Authorization List served is not a signed 782 object and therefore the server is trusted to faithfully return the 783 TN Authorization List provided to it by the list generator. 785 13. References 787 13.1. Normative References 789 [ATIS-0300251] 790 ATIS Recommendation 0300251, "Codes for Identification of 791 Service Providers for Information Exchange", 2007. 793 [DSS] National Institute of Standards and Technology, U.S. 794 Department of Commerce, "Digital Signature Standard 795 (DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, 796 July 2013, . 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, 801 DOI 10.17487/RFC2119, March 1997, . 804 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 805 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 806 . 808 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 809 Resource Identifier (URI): Generic Syntax", STD 66, 810 RFC 3986, DOI 10.17487/RFC3986, January 2005, 811 . 813 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 814 Housley, R., and W. Polk, "Internet X.509 Public Key 815 Infrastructure Certificate and Certificate Revocation List 816 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 817 . 819 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 820 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 821 DOI 10.17487/RFC5912, June 2010, . 824 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 825 DOI 10.17487/RFC5958, August 2010, . 828 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 829 Protocol (HTTP/1.1): Message Syntax and Routing", 830 RFC 7230, DOI 10.17487/RFC7230, June 2014, 831 . 833 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 834 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 835 2014, . 837 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 838 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 839 . 841 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 842 "PKCS #1: RSA Cryptography Specifications Version 2.2", 843 RFC 8017, DOI 10.17487/RFC8017, November 2016, 844 . 846 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 847 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 848 May 2017, . 850 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 851 "Authenticated Identity Management in the Session 852 Initiation Protocol (SIP)", RFC 8224, 853 DOI 10.17487/RFC8224, November 2017, . 856 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 857 Token", RFC 8225, DOI 10.17487/RFC8225, November 2017, 858 . 860 [X.509] International Telecommunication Union, "Information 861 technology - Open Systems Interconnection - The Directory: 862 Public-key and attribute certificate frameworks", ITU-T 863 Recommendation X.509, ISO/IEC 9594-8, October 2016, 864 . 866 [X.680] International Telecommunication Union, "Information 867 Technology - Abstract Syntax Notation One (ASN.1): 868 Specification of basic notation", ITU-T Recommendation 869 X.680, ISO/IEC 8824-1, August 2015, 870 . 872 [X.681] International Telecommunication Union, "Information 873 Technology - Abstract Syntax Notation One (ASN.1): 874 Information object specification", ITU-T Recommendation 875 X.681, ISO/IEC 8824-2, August 2015, 876 . 878 [X.682] International Telecommunication Union, "Information 879 Technology - Abstract Syntax Notation One (ASN.1): 880 Constraint specification", ITU-T Recommendation 881 X.682, ISO/IEC 8824-3, August 2015, 882 . 884 [X.683] International Telecommunication Union, "Information 885 Technology - Abstract Syntax Notation One (ASN.1): 886 Parameterization of ASN.1 specifications", ITU-T 887 Recommendation X.683, ISO/IEC 8824-4, August 2015, 888 . 890 13.2. Informative References 892 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 893 Extensions (MIME) Part Two: Media Types", RFC 2046, 894 DOI 10.17487/RFC2046, November 1996, . 897 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 898 Wu, "Internet X.509 Public Key Infrastructure Certificate 899 Policy and Certification Practices Framework", RFC 3647, 900 DOI 10.17487/RFC3647, November 2003, . 903 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 904 Telephone Identity Problem Statement and Requirements", 905 RFC 7340, DOI 10.17487/RFC7340, September 2014, 906 . 908 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 909 RFC 7375, DOI 10.17487/RFC7375, October 2014, 910 . 912 [X.520] International Telecommunication Union, "Information 913 technology - Open Systems Interconnection - The Directory: 914 Selected attribute types", ITU-T Recommendation 915 X.520, ISO/IEC 9594-6, October 2016, 916 . 918 Appendix A. ASN.1 Module 920 This appendix provides the normative ASN.1 [X.680] definitions for 921 the structures described in this specification using ASN.1, as 922 defined in [X.680], [X.681], [X.682], and [X.683]. 924 The modules defined in this document are compatible with the most 925 current ASN.1 specifications published in 2015 (see [X.680], [X.681], 926 [X.682], and [X.683]). None of the newly defined tokens in the 2008 927 ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, 928 RELATIVE-OID-IRI, TIME, TIME-OF-DAY) are currently used in any of the 929 ASN.1 specifications referred to here. 931 This ASN.1 module imports ASN.1 from [RFC5912]. 933 TN-Module-2016 934 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 935 mechanisms(5) pkix(7) id-mod(0) id-mod-tn-module(89) } 937 DEFINITIONS EXPLICIT TAGS ::= BEGIN 939 IMPORTS 941 id-ad, id-pe 942 FROM PKIX1Explicit-2009 -- From [RFC5912] 943 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 944 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } 946 EXTENSION 947 FROM PKIX-CommonTypes-2009 -- From [RFC5912] 948 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 949 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } 951 ; 953 -- 954 -- JWT Claim Constraints Certificate Extension 955 -- 956 ext-jwtClaimConstraints EXTENSION ::= { 957 SYNTAX JWTClaimConstraints IDENTIFIED BY id-pe-JWTClaimConstraints 958 } 960 id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 27 } 962 JWTClaimConstraints ::= SEQUENCE { 963 mustInclude [0] JWTClaimNames OPTIONAL, 964 -- The listed claim names MUST appear in the PASSporT 965 -- in addition to iat, orig, and dest. If absent, iat, orig, 966 -- and dest MUST appear in the PASSporT. 967 permittedValues [1] JWTClaimPermittedValuesList OPTIONAL } 968 -- If the claim name is present, the claim MUST contain one of 969 -- the listed values. 970 ( WITH COMPONENTS { ..., mustInclude PRESENT } | 971 WITH COMPONENTS { ..., permittedValues PRESENT } ) 973 JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) Of 974 JWTClaimPermittedValues 976 JWTClaimPermittedValues ::= SEQUENCE { 977 claim JWTClaimName, 978 permitted SEQUENCE SIZE (1..MAX) OF UTF8String } 980 JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName 982 JWTClaimName ::= IA5String 984 -- 985 -- Telephony Number Authorization List Certificate Extension 986 -- 988 ext-tnAuthList EXTENSION ::= { 989 SYNTAX TNAuthorizationList IDENTIFIED BY id-pe-TNAuthList 990 } 992 id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 } 994 TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry 996 TNEntry ::= CHOICE { 997 spc [0] ServiceProviderCode, 998 range [1] TelephoneNumberRange, 999 one [2] TelephoneNumber 1000 } 1002 ServiceProviderCode ::= IA5String 1003 -- SPCs may be OCNs, various SPIDs, or other SP identifiers 1004 -- from the telephone network. 1006 TelephoneNumberRange ::= SEQUENCE { 1007 start TelephoneNumber, 1008 count INTEGER (2..MAX), 1009 ... 1010 } 1012 TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*")) 1014 -- TN Access Descriptor 1016 id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } 1018 END 1020 Acknowledgments 1022 Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave 1023 Crocker, Tony Rutkowski, John Braunberger, Eric Rescorla, and Martin 1024 Thomson provided key input to the discussions leading to this 1025 document. Russ Housley provided some direct assistance and text 1026 surrounding the ASN.1 module. 1028 Authors' Addresses 1030 Jon Peterson 1031 Neustar, Inc. 1033 Email: jon.peterson@neustar.biz 1035 Sean Turner 1036 sn3rd 1038 Email: sean@sn3rd.com