idnits 2.17.1 draft-ietf-stir-certificates-16.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 9, 2017) is 2331 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 993 -- Looks like a reference, but probably isn't: '1' on line 994 -- Looks like a reference, but probably isn't: '2' on line 995 == Missing Reference: 'RFCTBD' is mentioned on line 732, 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 12, 2018 sn3rd 6 December 9, 2017 8 Secure Telephone Identity Credentials: Certificates 9 draft-ietf-stir-certificates-16 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 12, 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 overflows a TelephoneNumber digit boundary (i.e., a 591 TelephoneNumberRange with TelephoneNumber=10 with a count=91 will 592 address numbers 10-99). 594 3. A single telephone number can be listed (as a TelephoneNumber). 596 Note that because large-scale service providers may want to associate 597 many numbers, possibly millions of numbers, with a particular 598 certificate, optimizations are required for those cases to prevent 599 the certificate size from becoming unmanageable. In these cases, the 600 TN Authorization List may be given by reference rather than by value, 601 through the presence of a separate certificate extension that permits 602 verifiers to either (1) securely download the list of numbers 603 associated with a certificate or (2) verify that a single number is 604 under the authority of this certificate. For more on this 605 optimization, see Section 10.1. 607 10. Certificate Freshness and Revocation 609 Regardless of which of the approaches in Section 3 is followed for 610 using certificates, a certificate verification mechanism is required. 611 However, the traditional problem of certificate freshness gains a new 612 wrinkle when using the TN Authorization List extension with telephone 613 numbers or number ranges (as opposed to SPCs), because verifiers must 614 establish not only that a certificate remains valid but also that the 615 certificate's scope contains the telephone number that the verifier 616 is validating. Dynamic changes to number assignments can occur due 617 to number portability, for example. So, even if a verifier has a 618 valid cached certificate for a telephone number (or a range 619 containing the number), the verifier must determine that the entity 620 that created the PASSporT, which includes a digital signature, is 621 still a proper authority for that number. 623 To verify the status of such a certificate, the verifier needs to 624 acquire the certificate if necessary (via the methods described in 625 Section 7) and then would need to either: 627 a. Rely on short-lived certificates and not check the certificate's 628 status, or 630 b. Rely on status information from the authority (e.g., the Online 631 Certificate Status Protocol (OCSP)). 633 The trade-off between short-lived certificates and using status 634 information is that the former's burden is on the front end (i.e., 635 enrollment) and the latter's burden is on the back end (i.e., 636 verification). Both impact call setup time, but some approaches to 637 generating a short-lived certificate, like requiring one for each 638 call, would incur a greater operational cost than acquiring status 639 information. This document makes no particular recommendation for a 640 means of determining certificate freshness for STIR, as this requires 641 further study and implementation experience. Acquiring online status 642 information for certificates has the potential to disclose private 643 information [RFC7258] if proper precautions are not taken. Future 644 specifications that define certificate freshness mechanisms for STIR 645 MUST note any such risks and provide countermeasures where possible. 647 10.1. Acquiring the TN List by Reference 649 One alternative to checking certificate status for a particular 650 telephone number is simply acquiring the TN Authorization List by 651 reference, that is, through dereferencing a URL in the certificate, 652 rather than including the value of the TN Authorization List in the 653 certificate itself. 655 Acquiring a list of the telephone numbers associated with a 656 certificate or its subject lends itself to an application-layer 657 query/response interaction outside of certificate status, one that 658 could be initiated through a separate URI included in the 659 certificate. The AIA extension (see [RFC5280]) supports such a 660 mechanism: it designates an OID to identify the accessMethod and an 661 accessLocation, which would most likely be a URI. A verifier would 662 then follow the URI to ascertain whether the TNs in the list are 663 authorized for use by the caller. As with the certificate extension 664 defined in Section 9, a URI dereferenced from an end entity 665 certificate will indicate the TNs which the caller has been 666 authorized. Verifiers MUST support the AIA extension and the 667 dereferenced URI from a CA certificate limits the the set of TNs for 668 certification paths that include this certificate. 670 HTTPS is the most obvious candidate for a protocol to be used for 671 fetching the list of telephone numbers associated with a particular 672 certificate. This document defines a new AIA accessMethod, called 673 "id-ad-stirTNList", which uses the following AIA OID: 675 id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } 677 When the "id-ad-stirTNList" accessMethod is used, the accessLocation 678 MUST be an HTTPS URI. Dereferencing the URI will return the complete 679 DER encoded TN Authorization List (see Section 9) for the certificate 680 with a Content-Type of application/tnauthlist (see Section 11.2). 682 Delivering the entire list of telephone numbers associated with a 683 particular certificate will divulge to STIR verifiers information 684 about telephone numbers other than the one associated with the 685 particular call that the verifier is checking. In some environments, 686 where STIR verifiers handle a high volume of calls, maintaining an 687 up-to-date and complete cache for the numbers associated with crucial 688 certificate holders could give an important boost to performance. 690 11. IANA Considerations 692 11.1. ASN.1 Registrations 694 This document makes use of object identifiers for the TN certificate 695 extension defined in Section 9, the "TN List by reference" AIA access 696 descriptor defined in Section 10.1, and the ASN.1 module identifier 697 defined in Appendix A. Therefore, per this document, IANA has made 698 the following assignments, as shown on 699 : 701 o TN Authorization List certificate extension in the "SMI Security 702 for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry: 704 26 id-pe-TNAuthList 706 o JWT Claim Constraints certificate extension in the "SMI Security 707 for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry: 709 27 id-pe-JWTClaimConstraints 711 o TN List by reference access descriptor in the "SMI Security for 712 PKIX Access Descriptor" (1.3.6.1.5.5.7.48) registry: 714 14 id-ad-stirTNList 716 o The TN ASN.1 module in the "SMI Security for PKIX Module 717 Identifier" (1.3.6.1.5.5.7.0) registry: 719 89 id-mod-tn-module 721 11.2. Media Type Registrations 723 Type name: application 724 Subtype name: tnauthlist 725 Required parameters: None. 726 Optional parameters: None. 727 Encoding considerations: Binary. 728 Security considerations: See Section 12 of [RFCTBD]. 729 Interoperability considerations: 730 The TN Authorization List inside this media type MUST be 731 DER-encoded TNAuthorizationList. 732 Published specification: [RFCTBD]. 733 Applications that use this media type: 734 Issuers and relying parties of secure telephone identity 735 certificates, to limit the subject's authority to a 736 particular telephone number or telephone number range. 737 Additional information: 738 Magic number(s): None 739 File extension(s): None 740 Macintosh File Type Code(s): None 741 Person & email address to contact for further information: 742 Jon Peterson 743 Intended usage: COMMON 744 Restrictions on usage: none 745 Author: Sean Turner 746 Change controller: The IESG 748 [RFC editor's instruction: Please replace RFCTBD with the 749 RFC number when this document is published.] 751 12. Security Considerations 753 This document is entirely about security. For further information on 754 certificate security and practices, see [RFC5280], in particular its 755 Security Considerations section. 757 If a certification authority issues a certificate attesting authority 758 over many telephone numbers, the TNAuthList element can divulge to 759 relying parties extraneous telephone numbers associated with the 760 certificate which have no bearing on any given call in progress. The 761 potential privacy risk can be exacerbated by the use of AIA, as 762 described in Section 10.1, to link many thousand of numbers to a 763 single certificate. Even an SPC in a certificate can be used to link 764 a certificate to a particular carrier and, with access to industry 765 databases, potentially the set of numbers associated with that SPC. 766 While these practices may not cause concern in some environments, in 767 other scenarios alternative approaches could minimize the data 768 revealed to relying parties. For example, a service provider with 769 authority over a large block of numbers could generate short-lived 770 certificates for individual TNs that are not so easily linked to the 771 service provider or any other numbers that the service provider 772 controls. Optimizations to facilitate acquiring short-lived 773 certificates are a potential area of future work for STIR. 775 The TN Authorization List returned through a dereferenced URI is 776 served over HTTPS; the TN Authorization List is therefore protected 777 in transit. But, the TN Authorization List served is not a signed 778 object and therefore the server is trusted to faithfully return the 779 TN Authorization List provided to it by the list generator. 781 13. References 783 13.1. Normative References 785 [ATIS-0300251] 786 ATIS Recommendation 0300251, "Codes for Identification of 787 Service Providers for Information Exchange", 2007. 789 [DSS] National Institute of Standards and Technology, U.S. 790 Department of Commerce, "Digital Signature Standard 791 (DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, 792 July 2013, . 795 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 796 Requirement Levels", BCP 14, RFC 2119, 797 DOI 10.17487/RFC2119, March 1997, . 800 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 801 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 802 . 804 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 805 Resource Identifier (URI): Generic Syntax", STD 66, 806 RFC 3986, DOI 10.17487/RFC3986, January 2005, 807 . 809 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 810 Housley, R., and W. Polk, "Internet X.509 Public Key 811 Infrastructure Certificate and Certificate Revocation List 812 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 813 . 815 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 816 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 817 DOI 10.17487/RFC5912, June 2010, . 820 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 821 DOI 10.17487/RFC5958, August 2010, . 824 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 825 Protocol (HTTP/1.1): Message Syntax and Routing", 826 RFC 7230, DOI 10.17487/RFC7230, June 2014, 827 . 829 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 830 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 831 2014, . 833 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 834 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 835 . 837 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 838 "PKCS #1: RSA Cryptography Specifications Version 2.2", 839 RFC 8017, DOI 10.17487/RFC8017, November 2016, 840 . 842 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 843 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 844 May 2017, . 846 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 847 "Authenticated Identity Management in the Session 848 Initiation Protocol (SIP)", RFC 8224, 849 DOI 10.17487/RFC8224, November 2017, . 852 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 853 Token", RFC 8225, DOI 10.17487/RFC8225, November 2017, 854 . 856 [X.509] International Telecommunication Union, "Information 857 technology - Open Systems Interconnection - The Directory: 858 Public-key and attribute certificate frameworks", ITU-T 859 Recommendation X.509, ISO/IEC 9594-8, October 2016, 860 . 862 [X.680] International Telecommunication Union, "Information 863 Technology - Abstract Syntax Notation One (ASN.1): 864 Specification of basic notation", ITU-T Recommendation 865 X.680, ISO/IEC 8824-1, August 2015, 866 . 868 [X.681] International Telecommunication Union, "Information 869 Technology - Abstract Syntax Notation One (ASN.1): 870 Information object specification", ITU-T Recommendation 871 X.681, ISO/IEC 8824-2, August 2015, 872 . 874 [X.682] International Telecommunication Union, "Information 875 Technology - Abstract Syntax Notation One (ASN.1): 876 Constraint specification", ITU-T Recommendation 877 X.682, ISO/IEC 8824-3, August 2015, 878 . 880 [X.683] International Telecommunication Union, "Information 881 Technology - Abstract Syntax Notation One (ASN.1): 882 Parameterization of ASN.1 specifications", ITU-T 883 Recommendation X.683, ISO/IEC 8824-4, August 2015, 884 . 886 13.2. Informative References 888 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 889 Extensions (MIME) Part Two: Media Types", RFC 2046, 890 DOI 10.17487/RFC2046, November 1996, . 893 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 894 Wu, "Internet X.509 Public Key Infrastructure Certificate 895 Policy and Certification Practices Framework", RFC 3647, 896 DOI 10.17487/RFC3647, November 2003, . 899 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 900 Telephone Identity Problem Statement and Requirements", 901 RFC 7340, DOI 10.17487/RFC7340, September 2014, 902 . 904 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 905 RFC 7375, DOI 10.17487/RFC7375, October 2014, 906 . 908 [X.520] International Telecommunication Union, "Information 909 technology - Open Systems Interconnection - The Directory: 910 Selected attribute types", ITU-T Recommendation 911 X.520, ISO/IEC 9594-6, October 2016, 912 . 914 Appendix A. ASN.1 Module 916 This appendix provides the normative ASN.1 [X.680] definitions for 917 the structures described in this specification using ASN.1, as 918 defined in [X.680], [X.681], [X.682], and [X.683]. 920 The modules defined in this document are compatible with the most 921 current ASN.1 specifications published in 2015 (see [X.680], [X.681], 922 [X.682], and [X.683]). None of the newly defined tokens in the 2008 923 ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, 924 RELATIVE-OID-IRI, TIME, TIME-OF-DAY) are currently used in any of the 925 ASN.1 specifications referred to here. 927 This ASN.1 module imports ASN.1 from [RFC5912]. 929 TN-Module-2016 930 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 931 mechanisms(5) pkix(7) id-mod(0) id-mod-tn-module(89) } 933 DEFINITIONS EXPLICIT TAGS ::= BEGIN 935 IMPORTS 937 id-ad, id-pe 938 FROM PKIX1Explicit-2009 -- From [RFC5912] 939 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 940 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } 942 EXTENSION 943 FROM PKIX-CommonTypes-2009 -- From [RFC5912] 944 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 945 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } 947 ; 949 -- 950 -- JWT Claim Constraints Certificate Extension 951 -- 952 ext-jwtClaimConstraints EXTENSION ::= { 953 SYNTAX JWTClaimConstraints IDENTIFIED BY id-pe-JWTClaimConstraints 954 } 956 id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 27 } 958 JWTClaimConstraints ::= SEQUENCE { 959 mustInclude [0] JWTClaimNames OPTIONAL, 960 -- The listed claim names MUST appear in the PASSporT 961 -- in addition to iat, orig, and dest. If absent, iat, orig, 962 -- and dest MUST appear in the PASSporT. 963 permittedValues [1] JWTClaimPermittedValuesList OPTIONAL } 964 -- If the claim name is present, the claim MUST contain one of 965 -- the listed values. 966 ( WITH COMPONENTS { ..., mustInclude PRESENT } | 967 WITH COMPONENTS { ..., permittedValues PRESENT } ) 969 JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) Of 970 JWTClaimPermittedValues 972 JWTClaimPermittedValues ::= SEQUENCE { 973 claim JWTClaimName, 974 permitted SEQUENCE SIZE (1..MAX) OF UTF8String } 976 JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName 978 JWTClaimName ::= IA5String 980 -- 981 -- Telephony Number Authorization List Certificate Extension 982 -- 984 ext-tnAuthList EXTENSION ::= { 985 SYNTAX TNAuthorizationList IDENTIFIED BY id-pe-TNAuthList 986 } 988 id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 } 990 TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry 992 TNEntry ::= CHOICE { 993 spc [0] ServiceProviderCode, 994 range [1] TelephoneNumberRange, 995 one [2] TelephoneNumber 996 } 998 ServiceProviderCode ::= IA5String 999 -- SPCs may be OCNs, various SPIDs, or other SP identifiers 1000 -- from the telephone network. 1002 TelephoneNumberRange ::= SEQUENCE { 1003 start TelephoneNumber, 1004 count INTEGER (2..MAX), 1005 ... 1006 } 1008 TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*")) 1010 -- TN Access Descriptor 1012 id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } 1014 END 1016 Acknowledgments 1018 Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave 1019 Crocker, Tony Rutkowski, John Braunberger, Eric Rescorla, and Martin 1020 Thomson provided key input to the discussions leading to this 1021 document. Russ Housley provided some direct assistance and text 1022 surrounding the ASN.1 module. 1024 Authors' Addresses 1026 Jon Peterson 1027 Neustar, Inc. 1029 Email: jon.peterson@neustar.biz 1031 Sean Turner 1032 sn3rd 1034 Email: sean@sn3rd.com