idnits 2.17.00 (12 Aug 2021) /tmp/idnits64548/draft-ietf-stir-certificates-09.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2016) is 2052 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: '1' on line 1040 -- Looks like a reference, but probably isn't: '2' on line 1024 -- Looks like a reference, but probably isn't: '0' on line 1039 -- Possible downref: Non-RFC (?) normative reference: ref. 'ATIS-0300050' == Outdated reference: draft-ietf-stir-passport has been published as RFC 8225 == Outdated reference: draft-ietf-stir-rfc4474bis has been published as RFC 8224 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 3647 ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Obsolete normative reference: RFC 6961 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 7093 ** Downref: Normative reference to an Informational RFC: RFC 7340 ** Downref: Normative reference to an Informational RFC: RFC 7375 Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: April 9, 2017 sn3rd 6 October 6, 2016 8 Secure Telephone Identity Credentials: Certificates 9 draft-ietf-stir-certificates-09.txt 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 April 9, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 . . . . . . . . . . . . 12 66 10.1. Choosing a Verification Method . . . . . . . . . . . . . 13 67 10.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 14 68 10.2.1. OCSP Extension Specification . . . . . . . . . . . . 15 69 10.3. Acquiring TN Lists By Reference . . . . . . . . . . . . 17 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 71 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 73 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 21 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 77 1. Introduction 79 The STIR problem statement [RFC7340] identifies the primary enabler 80 of robocalling, vishing, swatting and related attacks as the 81 capability to impersonate a calling party number. The starkest 82 examples of these attacks are cases where automated callees on the 83 PSTN rely on the calling number as a security measure, for example to 84 access a voicemail system. Robocallers use impersonation as a means 85 of obscuring identity; while robocallers can, in the ordinary PSTN, 86 block (that is, withhold) their caller identity, callees are less 87 likely to pick up calls from blocked identities, and therefore 88 appearing to calling from some number, any number, is preferable. 89 Robocallers however prefer not to call from a number that can trace 90 back to the robocaller, and therefore they impersonate numbers that 91 are not assigned to them. 93 One of the most important components of a system to prevent 94 impersonation is the implementation of credentials which identify the 95 parties who control telephone numbers. With these credentials, 96 parties can assert that they are in fact authorized to use telephony 97 numbers, and thus distinguish themselves from impersonators unable to 98 present such credentials. For that reason the STIR threat model 99 [RFC7375] stipulates, "The design of the credential system envisioned 100 as a solution to these threats must, for example, limit the scope of 101 the credentials issued to carriers or national authorities to those 102 numbers that fall under their purview." This document describes 103 credential systems for telephone numbers based on [X.509] version 3 104 certificates in accordance with [RFC5280]. While telephone numbers 105 have long been part of the X.509 standard (X.509 supports arbitrary 106 naming attributes to be included in a certificate; the 107 telephoneNumber attribute was defined in the 1988 [X.520] 108 specification) this document provides ways to determine authority 109 more aligned with telephone network requirements, including extending 110 X.509 with a Telephone Number Authorization List certificate 111 extension which binds certificates to asserted authority for 112 particular telephone numbers, or potentially telephone number blocks 113 or ranges. 115 In the STIR in-band architecture specified in 116 [I-D.ietf-stir-rfc4474bis], two basic types of entities need access 117 to these credentials: authentication services, and verification 118 services (or verifiers). An authentication service must be operated 119 by an entity enrolled with the certification authority (CA, see 120 Section 5), whereas a verifier need only trust the trust anchor of 121 the authority, and have a means to access and validate the public 122 keys associated with these certificates. Although the guidance in 123 this document is written with the STIR in-band architecture in mind, 124 the credential system described in this document could be useful for 125 other protocols that want to make use of certificates to assert 126 authority over telephone numbers on the Internet. 128 This document specifies only the credential syntax and semantics 129 necessary to support this architecture. It does not assume any 130 particular CA or deployment environment. We anticipate that some 131 deployment experience will be necessary to determine optimal 132 operational models. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in RFC 139 2119 [RFC2119]. 141 3. Authority for Telephone Numbers in Certificates 143 At a high level, this specification details two non-exclusive 144 approaches that can be employed to determine authority over telephone 145 numbers with certificates. 147 The first approach is to leverage the existing subject of the 148 certificate to ascertain that the holder of the certificate is 149 authorized to claim authority over a telephone number. The subject 150 might be represented as a domain name in the subjectAltName, such as 151 an "example.net" where that domain is known to relying parties as a 152 carrier, or represented with other identifiers related to the 153 operation of the telephone network including Service Provider 154 Identifiers (SPIDs) via the TN Authorization List specified in this 155 document. A relying party could then employ an external data set or 156 service that determines whether or not a specific telephone number is 157 under the authority of the carrier identified as the subject of the 158 certificate, and use that to ascertain whether or not the carrier 159 should have authority over a telephone number. Potentially, a 160 certificate extension to convey the URI of such an information 161 service trusted by the issuer of the certificate could be developed 162 (though this specification does not propose one). Alternatively, 163 some relying parties could form bilateral or multilateral trust 164 relationships with peer carriers, trusting one another's assertions 165 just as telephone carriers in the SS7 network today rely on 166 transitive trust when displaying the calling party telephone number 167 received through SS7 signaling. 169 The second approach is to extend the syntax of certificates to 170 include a new attribute, defined here as TN Authorization List, which 171 contains a list of telephone numbers defining the scope of authority 172 of the certificate. Relying parties, if they trust the issuer of the 173 certificate as a source of authoritative information on telephone 174 numbers, could therefore use the TN Authorization List instead of the 175 subject of the certificate to make a decision about whether or not 176 the signer has authority over a particular telephone number. The TN 177 Authorization List could be provided in one of two ways: as a literal 178 value in the certificate, or as a network service that allows relying 179 parties to query in real time to determine that a telephone number is 180 in the scope of a certificate. Using the TN Authorization list 181 rather than the certificate subject makes sense when, for example, 182 for privacy reasons, the certificate owner would prefer not to be 183 identified, or in cases where the holder of the certificate does not 184 participate in the sort of traditional carrier infrastructure that 185 the first approach assumes. 187 The first approach requires little change to existing Public Key 188 Infrastructure (PKI) certificates; for the second approach, we must 189 define an appropriate enrollment and authorization process. For the 190 purposes of STIR, the over-the-wire format specified in 191 [I-D.ietf-stir-rfc4474bis] accommodates either of these approaches: 192 the methods for canonicalizing, signing, for identifying and 193 accessing the certificate and so on remain the same; it is only the 194 verifier behavior and authorization decision that will change 195 depending on the approach to telephone number authority taken by the 196 certificate. For that reason, the two approaches are not mutually 197 exclusive, and in fact a certificate issued to a traditional 198 telephone network service provider could contain a TN Authorization 199 List or not, were it supported by the CA issuing the credential. 200 Regardless of which approach is used, certificates that assert 201 authority over telephone numbers are subject to the ordinary 202 operational procedures that govern certificate use per [RFC5280]. 203 This means that verification services must be mindful of the need to 204 ensure that they trust the trust anchor that issued the certificate, 205 and that they have some means to determine the freshness of the 206 certificate (see Section 10). 208 4. Certificate Usage with STIR 210 [I-D.ietf-stir-rfc4474bis] Section 7.4 requires that all credential 211 systems used by STIR explain how they address the requirements 212 enumerated below. Certificates as described in this document address 213 the STIR requirements as follows: 215 1. The URI schemes permitted in the SIP Identity header "info" 216 parameter, as well as any special procedures required to 217 dereference the URIs: while normative text is given below in 218 Section 7, this mechanism permits the HTTP, CID and SIP URI 219 schemes to appear in the "info" parameter. 221 2. Procedures required to extract keying material from the resources 222 designated by the URI: implementations perform no special 223 procedures beyond dereferencing the "info" URI. See Section 7. 225 3. Procedures used by the verification service to determine the 226 scope of the credential: this specification effectively proposes 227 two methods, as outlined in Section 3: one where the subject (or 228 more properly subjectAltName) of the certificate indicates the 229 scope of authority through a domain name, and relying parties 230 either trust the subject entirely or have some direct means of 231 determining whether or not a number falls under a subject's 232 authority; and another where an extension to the certificate as 233 described in Section 9 identifies the scope of authority of the 234 certificate. 236 4. The cryptographic algorithms required to validate the 237 credentials: for this specification, that means the signature 238 algorithms used to sign certificates. This specification 239 REQUIRES that implementations support both ECDSA with the P-256 240 curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447] 241 Section 8.2) for certificate signatures. Implementers are 242 advised that RS256 is mandated only as a transitional mechanism, 243 due to its widespread use in existing PKI, but we anticipate that 244 this mechanism will eventually be deprecated. 246 5. Finally, note that all certificates compliant with this 247 specification: 249 * MUST provide cryptographic keying material sufficient to 250 generate the ECDSA using P-256 and SHA-256 signatures 251 necessary to support the ES256 hashed signatures required by 252 PASSporT [I-D.ietf-stir-passport], which in turn follows JSON 253 Web Token (JWT) [RFC7519]. 255 * MUST support both ECDSA with P-256 and RSA PKCS#1 v1.5 for 256 certificate signature verification. 258 This document also includes additional certificate-related 259 requirements: 261 o See Section 5.1 for requirements related to the certificate 262 policies extension. 264 o See Section 7 for requirements related to relying parties 265 acquiring credentials. 267 o See Section 10.2 and Section 10.3 for requirements related to the 268 Authority Information Access (AIA) certificate extension. 270 o See Section 10.2.1 for requirements related to the authority key 271 identifier and subject key identifier certificate extensions. 273 5. Enrollment and Authorization using the TN Authorization List 275 This document covers three models for enrollment when using the TN 276 Authorization List extension. 278 The first enrollment model is one where the CA acts in concert with 279 national numbering authorities to issue credentials to those parties 280 to whom numbers are assigned. In the United States, for example, 281 telephone number blocks are assigned to Local Exchange Carriers 282 (LECs) by the North American Numbering Plan Administrator (NANPA), 283 who is in turn directed by the national regulator. LECs may also 284 receive numbers in smaller allocations, through number pooling, or 285 via an individual assignment through number portability. LECs assign 286 numbers to customers, who may be private individuals or organizations 287 - and organizations take responsibility for assigning numbers within 288 their own enterprise. This model requires top-down adoption of the 289 model from regulators through to carriers. Assignees of E.164 290 numbering resources participating in this enrollment model should 291 take appropriate steps to establish trust anchors. 293 The second enrollment model is a bottom-up approach where a CA 294 requires that an entity prove control by means of some sort of test, 295 which, as with certification authorities for web PKI, might either be 296 automated or a manual administrative process. As an example of an 297 automated process, an authority might send a text message to a 298 telephone number containing a URL (which might be dereferenced by the 299 recipient) as a means of verifying that a user has control of 300 terminal corresponding to that number. Checks of this form are 301 frequently used in commercial systems today to validate telephone 302 numbers provided by users. This is comparable to existing enrollment 303 systems used by some certificate authorities for issuing S/MIME 304 credentials for email by verifying that the party applying for a 305 credential receives mail at the email address in question. 307 The third enrollment model is delegation: that is, the holder of a 308 certificate (assigned by either of the two methods above) might 309 delegate some or all of their authority to another party. In some 310 cases, multiple levels of delegation could occur: a LEC, for example, 311 might delegate authority to a customer organization for a block of 312 100 numbers used by an IP PBX, and the organization might in turn 313 delegate authority for a particular number to an individual employee. 314 This is analogous to delegation of organizational identities in 315 traditional hierarchical PKIs who use the name constraints extension 316 [RFC5280]; the root CA delegates names in sales to the sales 317 department CA, names in development to the development CA, etc. As 318 lengthy certificate delegation chains are brittle, however, and can 319 cause delays in the verification process, this document considers 320 optimizations to reduce the complexity of verification. 322 Future work might explore methods of partial delegation, where 323 certificate holders delegate only part of their authority. For 324 example, individual assignees may want to delegate to a service 325 authority for text messages associated with their telephone number, 326 but not for other functions. 328 5.1. Constraints on Signing PASSporTs 330 The public key in the certificate is used to validate the signature 331 on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions 332 specified in PASSporT [I-D.ietf-stir-passport]. This specification 333 supports constraints on the JWT claims, which allows the CA to 334 differentiate those enrolled from proof-of-possession versus 335 delegation. A Certification Policy and a Certification Practice 336 Statement [RFC3647] are produced as part of the normal PKI 337 bootstrapping process, (i.e., the CP is written first and then the CA 338 says how it conforms to the CP in the CPS). A CAs that wishes to 339 place constraints on the JWT claims MUST include the JWT Claim 340 Constraints certificate extension in issued certificates. See 341 Section 8 for information about the certificate extension. 343 5.2. Certificate Extension Scope and Structure 345 This specification places no limits on the number of telephone 346 numbers that can be associated with any given certificate. Some 347 service providers may be assigned millions of numbers, and may wish 348 to have a single certificate that can be applied to signing for any 349 one of those numbers. Others may wish to compartmentalize authority 350 over subsets of the numbers they control. 352 Moreover, service providers may wish to have multiple certificates 353 with the same scope of authority. For example, a service provider 354 with several regional gateway systems may want each system to be 355 capable of signing for each of their numbers, but not want to have 356 each system share the same private key. 358 The set of telephone numbers for which a particular certificate is 359 valid is expressed in the certificate through a certificate 360 extension; the certificate's extensibility mechanism is defined in 361 [RFC5280] but the TN Authorization List extension is specified in 362 this document. 364 The subjects of certificates containing the TN Authorization List 365 extension are typically the administrative entities to whom numbers 366 are assigned or delegated. For example, a LEC might hold a 367 certificate for a range of telephone numbers. In some cases, the 368 organization or individual issued such a certificate may not want to 369 associate themselves with a certificate; for example, a private 370 individual with a certificate for a single telephone number might not 371 want to distribute that certificate publicly if every verifier 372 immediately knew their name. The certification authorities issuing 373 certificates with the TN Authorization List extensions may, in 374 accordance with their policies, obscure the identity of the subject, 375 though mechanisms for doing so are outside the scope of this 376 document. 378 6. Provisioning Private Keying Material 380 In order for authentication services to sign calls via the procedures 381 described in [I-D.ietf-stir-rfc4474bis], they must hold a private key 382 corresponding to a certificate with authority over the calling 383 number. [I-D.ietf-stir-rfc4474bis] does not require that any 384 particular entity in a SIP deployment architecture sign requests, 385 only that it be an entity with an appropriate private key; the 386 authentication service role may be instantiated by any entity in a 387 SIP network. For a certificate granting authority only over a 388 particular number which has been issued to an end user, for example, 389 an end user device might hold the private key and generate the 390 signature. In the case of a service provider with authority over 391 large blocks of numbers, an intermediary might hold the private key 392 and sign calls. 394 The specification RECOMMENDS distribution of private keys through 395 PKCS#8 objects signed by a trusted entity, for example through the 396 CMS package specified in [RFC5958]. 398 7. Acquiring Credentials to Verify Signatures 400 This specification documents multiple ways that a verifier can gain 401 access to the credentials needed to verify a request. As the 402 validity of certificates does not depend on the method of their 403 acquisition, there is no need to standardize any single mechanism for 404 this purpose. All entities that comply with 405 [I-D.ietf-stir-rfc4474bis] necessarily support SIP, and consequently 406 SIP itself can serve as a way to deliver certificates. 407 [I-D.ietf-stir-rfc4474bis] provides an "info" parameter of the 408 Identity header which contains a URI for the credential used to 409 generate the Identity header; [I-D.ietf-stir-rfc4474bis] also 410 requires documents which define credential systems list the URI 411 schemes that may be present in the "info" parameter. For 412 implementations compliant with this specification, three URI schemes 413 are REQUIRED: the CID URI, the SIP URI, and the HTTP URI. 415 The simplest way for a verifier to acquire the certificate needed to 416 verify a signature is for the certificate be conveyed in a SIP 417 request along with the signature itself. In SIP, for example, a 418 certificate could be carried in a multipart MIME body [RFC2046], and 419 the URI in the Identity header "info" parameter could specify that 420 body with a CID URI [RFC2392]. However, in many environments this is 421 not feasible due to message size restrictions or lack of necessary 422 support for multipart MIME. 424 The Identity header "info" parameter in a SIP request may contain a 425 URI that the verifier dereferences. Implementations of this 426 specification are required to support the use of SIP for this 427 function (via the SUBSCRIBE/NOTIFY mechanism), as well as HTTP, via 428 the Enrollment over Secure Transport mechanisms described in RFC 7030 429 [RFC7030]. 431 Note well that as an optimization, a verifier may have access to a 432 service, a cache or other local store that grants access to 433 certificates for a particular telephone number. However, there may 434 be multiple valid certificates that can sign a call setup request for 435 a telephone number, and as a consequence, there needs to be some 436 discriminator that the signer uses to identify their credentials. 437 The Identity header "info" parameter itself can serve as such a 438 discriminator, provided implementations use that parameter as a key 439 when accessing certificates from caches or other sources. 441 8. JWT Claim Constraints Syntax 443 The subjects of certificates containing the JWT Claim Constraints 444 certificate extension are specifies values for claims that are 445 permitted, values for claims that are excluded, or both. When a 446 verifier is validating PASSporT claims, the JWT claim MUST contain 447 permitted values, and MUST NOT contain excluded values. The JWT 448 Claim Constraints certificate extension is included in the extension 449 field of the certificate [RFC5280]. The extension is defined with 450 ASN.1 [X.680][X.681][X.682] [X.683]. 452 The JWT Claim Constraints certificate extension is identified by the 453 following object identifier (OID), which is defined under the id-ce 454 OID arc defined in [RFC5280] and managed by IANA (see Section 11): 456 id-ce-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-ce TBD1 } 458 The JWT Claim Constraints certificate extension has the following 459 syntax: 461 JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint 463 JWTClaimConstraint ::= SEQUENCE { 464 claim IA5String, 465 permitted [1] SEQUENCE OF IA5String OPTIONAL, 466 excluded [2] SEQUENCE OF IA5String OPTIONAL } 467 ( WITH COMPONENTS { ..., permitted PRESENT } | 468 WITH COMPONENTS { ..., excluded PRESENT } ) 470 The JWT Claim Constraints certificate extension places constraints on 471 the values that are allowed in particular JWT claims. The extension 472 provides claim values that the call setup signer is permitted to 473 include, excluded from including, or both. 475 9. TN Authorization List Syntax 477 The subjects of certificates containing the TN Authorization List 478 extension are the administrative entities to whom numbers are 479 assigned or delegated. When a verifier is validating a caller's 480 identity, local policy always determines the circumstances under 481 which any particular subject may be trusted, but the purpose of the 482 TN Authorization List extension in particular is to allow a verifier 483 to ascertain when the CA has designated that the subject has 484 authority over a particular telephone number or number range. The 485 Telephony Number (TN) Authorization List certificate extension is 486 included in the Certificate's extension field [RFC5280]. The 487 extension is defined with ASN.1 [X.680][X.681][X.682] [X.683]. What 488 follows is the syntax and semantics of the extension. 490 The Telephony Number (TN) Authorization List certificate extension is 491 identified by the following object identifier (OID), which is defined 492 under the id-ce OID arc defined in [RFC5280] and managed by IANA (see 493 Section 11). 495 id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD2 } 497 The TN Authorization List certificate extension has the following 498 syntax: 500 TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry 502 TNEntry ::= CHOICE { 503 spid [0] ServiceProviderIdentifierList, 504 range [1] TelephoneNumberRange, 505 one E164Number } 507 ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF 508 OCTET STRING 510 -- Allows SPID, Alt SPID, and Last Alt SPID to be present 512 TelephoneNumberRange ::= SEQUENCE { 513 start E164Number, 514 count INTEGER } 516 E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789")) 518 The TN Authorization List certificate extension indicates the 519 authorized phone numbers for the call setup signer. It indicates one 520 or more blocks of telephone number entries that have been authorized 521 for use by the call setup signer. There are three ways to identify 522 the block: 524 1. A Service Provider Identifier (SPID, also known as an Operating 525 Company Number (OCN) or Carrier Identification Code (CIC), as 526 specified in [ATIS-0300050]) can be used to indirectly name all 527 of the telephone numbers associated with that service provider, 529 2. Telephone numbers can be listed in a range (in the 530 TelephoneNumberRange format), or 532 3. A single telephone number can be listed (as an E164Number). 534 Note that because large-scale service providers may want to associate 535 many numbers, possibly millions of numbers, with a particular 536 certificate, optimizations are required for those cases to prevent 537 certificate size from becoming unmanageable. In these cases, the TN 538 Authorization List may be given by reference rather than by value, 539 through the presence of a separate certificate extension that permits 540 verifiers to either securely download the list of numbers associated 541 with a certificate, or to verify that a single number is under the 542 authority of this certificate. This optimization is left for future 543 work. 545 10. Certificate Freshness and Revocation 547 Regardless of which of the approaches in Section 3 is followed for 548 using certificates, a certificate verification mechanism is required. 549 However, the traditional problem of certificate freshness gains a new 550 wrinkle when using the TN Authorization List extension with telephone 551 numbers or number ranges (as opposed to SPIDs), because verifiers 552 must establish not only that a certificate remains valid, but also 553 that the certificate's scope contains the telephone number that the 554 verifier is validating. Dynamic changes to number assignments can 555 occur due to number portability, for example. So even if a verifier 556 has a valid cached certificate for a telephone number (or a range 557 containing the number), the verifier must determine that the entity 558 that signed is still a proper authority for that number. 560 To verify the status of the certificate, the verifier needs to 561 acquire the certificate if necessary (via the methods described in 562 Section 7), and then would need to either: 564 (a) Rely on short-lived certificates and not check the certificate's 565 status, or 567 (b) Rely on status information from the authority (e.g. OCSP, see 568 Section 10.2) 570 The tradeoff between short lived certificates and using status 571 information is that the former's burden is on the front end (i.e., 572 enrollment) and the latter's burden is on the back end (i.e., 573 verification). Both impact call setup time, but it is assumed that 574 generating a short-lived certificate for each call, and consequently 575 performing enrollment for each call, is more of an impact than 576 acquiring status information. This document therefore details an 577 approach for relying on status information. 579 10.1. Choosing a Verification Method 581 There are three common certificate verification mechanisms employed 582 by CAs: 584 1. Certificate Revocation Lists (CRLs) [RFC5280] 586 2. Online Certificate Status Protocol (OCSP) [RFC6960], and 588 3. Server-based Certificate Validation Protocol (SCVP) [RFC5055]. 590 When relying on status information, the verifier needs to obtain the 591 status information - but before that can happen, the verifier needs 592 to know where to locate it. Placing the location of the status 593 information in the certificate makes the certificate larger, but it 594 eases the client workload. The CRL Distribution Point certificate 595 extension includes the location of the CRL and the Authority 596 Information Access certificate extension includes the location of 597 OCSP and/or SCVP servers; both of these extensions are defined in 598 [RFC5280]. In all cases, the status information location is provided 599 in the form of an URI. 601 CRLs are an obviously attractive solution because they are supported 602 by every CA. CRLs have a reputation of being quite large (10s of 603 MBytes), because CAs maintain and issue one monolithic CRL with all 604 of their revoked certificates, but CRLs do support a variety of 605 mechanisms to scope the size of the CRLs based on revocation reasons 606 (e.g., key compromise vs CA compromise), user certificates only, and 607 CA certificates only as well as just operationally deciding to keep 608 the CRLs small. However, scoping the CRL introduces other issues 609 (i.e., does the RP have all of the CRL partitions). 611 CAs in the STIR architecture will likely all create CRLs for audit 612 purposes, but it NOT RECOMMENDED that they be relied upon for status 613 information. Instead, one of the two "online" options is preferred. 614 Between the two, OCSP is much more widely deployed and this document 615 therefore RECOMMENDS the use of OCSP in high-volume environments 616 (HVE) for validating the freshness of certificates, based on 617 [RFC6960], incorporating some (but not all) of the optimizations of 618 [RFC5019]. CRLs MUST be signed with the same algorithm as the 619 certificate. 621 10.2. Using OCSP with TN Auth List 623 Certificates compliant with this specification therefore SHOULD 624 include a URL pointing to an OCSP service in the Authority 625 Information Access (AIA) certificate extension, via the "id-ad-ocsp" 626 accessMethod specified in [RFC5280]. It is RECOMMENDED that entities 627 that issue certificates with the Telephone Number Authorization List 628 certificate extension run an OCSP server for this purpose. Baseline 629 OCSP however supports only three possible response values: good, 630 revoked, or unknown. Without some extension, OCSP would not indicate 631 whether the certificate is authorized for a particular telephone 632 number that the verifier is validating. 634 At a high level, there are two ways that a client might pose this 635 authorization question: 637 For this certificate, is the following number currently in its 638 scope of validity? 640 What are all the telephone numbers associated with this 641 certificate, or this certificate subject? 643 Only the former lends itself to piggybacking on the OCSP status 644 mechanism; since the verifier is already asking an authority about 645 the certificate's status, that mechanism can be reused instead of 646 creating a new service that requires additional round trips? Like 647 most PKIX-developed protocols, OCSP is extensible; OCSP supports 648 request extensions (including sending multiple requests at once) and 649 per-request extensions. It seems unlikely that the verifier will be 650 requesting authorization checks on multiple telephone numbers in one 651 request, so a per-request extension is what is needed. 653 The requirement to consult OCSP in real time results in a network 654 round-trip time of day, which is something to consider because it 655 will add to the call setup time. OCSP server implementations 656 commonly pre-generate responses, and to speed up HTTPS connections, 657 servers often provide OCSP responses for each certificate in their 658 hierarchy. If possible, both of these OCSP concepts should be 659 adopted for use with STIR. 661 10.2.1. OCSP Extension Specification 663 The extension mechanism for OCSP follows X.509 v3 certificate 664 extensions, and thus requires an OID, a criticality flag, and ASN.1 665 syntax as defined by the OID. The criticality specified here is 666 optional: per [RFC6960] Section 4.4, support for all OCSP extensions 667 is optional. If the OCSP server does not understand the requested 668 extension, it will still provide the baseline validation of the 669 certificate itself. Moreover, in practical STIR deployments, the 670 issuer of the certificate will set the accessLocation for the OCSP 671 AIA extension to point to an OCSP service that supports this 672 extension, so the risk of interoperability failure due to lack of 673 support for this extension is minimal. 675 The OCSP TNQuery extension is included as one of the request's 676 singleRequestExtensions. It may also appear in the response's 677 singleExtensions. When an OCSP server includes a number in the 678 response's singleExtensions, this informs the client that the 679 certificate is still valid for the number that appears in the TNQuery 680 extension field. If the TNQuery is absent from a response to a query 681 containing a TNQuery in its singleRequestExtension, then the server 682 is not able to validate that the number is still in the scope of 683 authority of the certificate. 685 id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD } 687 TNQuery ::= E164Number 689 The HVE OCSP profile [RFC5019] prohibits the use of per-request 690 extensions. As it is anticipated that STIR will use OCSP in a high- 691 volume environment, many of the optimizations recommended by HVE are 692 desirable for the STIR environment. This document therefore uses the 693 HVE optimizations augmented as follows: 695 o Implementations MUST use SHA-256 as the hashing algorithm for the 696 CertID.issuerNameHash and the CertID.issuerKeyHash values. That 697 is CertID.hashAlgorithm is id-sha256 [RFC4055] and the values are 698 truncated to 160-bits as specified Option 1 in Section 2 of 699 [RFC7093]. 701 o Clients MUST include the OCSP TNQuery extension in requests' 702 singleRequestExtensions. 704 o Servers MUST include the OCSP TNQuery extension in responses' 705 singleExtensions. 707 o Servers SHOULD return responses that would otherwise have been 708 "unknown" as "not good" (i.e., return only "good" and "not good" 709 responses). 711 o Clients MUST treat returned "unknown" responses as "not good". 713 o If the server uses ResponderID, it MUST generate the KeyHash using 714 SHA-256 and truncate the value to 160-bits as specified in Option 715 1 in Section 2 of [RFC7093]. 717 o Implementations MUST support ECDSA using P-256 and SHA-256. Note 718 that [RFC6960] requires RSA with SHA-256 be supported. 720 o There is no requirement to support SHA-1, RSA with SHA-1, or DSA 721 with SHA-1. 723 OCSP responses MUST be signed using the same algorithm as the 724 certificate being checked. 726 To facilitate matching the authority key identifier values found in 727 CA certificates with the KeyHash used in the OCSP response, 728 certificates compliant with this specification MUST generate 729 authority key identifiers and subject key identifiers using the 730 SHA-256 and truncate the value to 160-bits as specified in Option 1 731 in Section 2 of [RFC7093]. 733 Ideally, once a certificate has been acquired by a verifier, some 734 sort of asynchronous mechanism could notify and update the verifier 735 if the scope of the certificate changes so that verifiers could 736 implement a cache. While not all possible categories of verifiers 737 could implement such behavior, some sort of event-driven notification 738 of certificate status is another potential subject of future work. 739 One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based 740 accessMethod for AIA might be defined (which would also be applicable 741 to the method described in the following section) by some future 742 specification. 744 Strategies for stapling OCSP [RFC6961] have become common in some web 745 PKI environments as an optimization which allows web servers to send 746 up-to-date certificate status information acquired from OCSP to 747 clients as TLS is negotiated. A similar mechanism could be 748 implemented for SIP requests, in which the authentication service 749 adds status information for its certificate to the SIP request, which 750 would save the verifier the trouble of performing the OCSP dip 751 itself. Especially for high-volume authentication and verification 752 services, this could result in significant performance improvements. 753 This is left as an optimization for future work. 755 10.3. Acquiring TN Lists By Reference 757 Acquiring a list of the telephone numbers associated with a 758 certificate or its subject lends itself to an application-layer 759 query/response interaction outside of OCSP, one which could be 760 initiated through a separate URI included in the certificate. The 761 AIA extension (see [RFC5280]) supports such a mechanism: it 762 designates an OID to identify the accessMethod and an accessLocation, 763 which would most likely be a URI. A verifier would then follow the 764 URI to ascertain whether the list of TNs are authorized for use by 765 the caller. 767 HTTPS is the most obvious candidate for a protocol to be used for 768 fetching the list of telephone numbers associated with a particular 769 certificate. This document defines a new AIA accessMethod, called 770 "id-ad-stir-tn", which uses the following AIA OID: 772 id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD } 774 When the "id-ad-stir-tn" accessMethod is used, the accessLocation 775 MUST be an HTTPS URI. The document returned by dereferencing that 776 URI will contain the complete TN Authorization List (see Section 9) 777 for the certificate. 779 Delivering the entire list of telephone numbers associated with a 780 particular certificate will divulge to STIR verifiers information 781 about telephone numbers other than the one associated with the 782 particular call that the verifier is checking. In some environments, 783 where STIR verifiers handle a high volume of calls, maintaining an 784 up-to-date and complete cache for the numbers associated with crucial 785 certificate holders could give an important boost to performance. 787 11. IANA Considerations 789 This document makes use of object identifiers for the TN Certificate 790 Extension defined in Section 9, TN-HVE OCSP extension in 791 Section 10.2.1, the TN by reference AIA access descriptor defined in 792 Section 10.3, and the ASN.1 module identifier defined in Appendix A. 793 It therefore requests that the IANA make the following assignments: 795 o JWT Claim Constraints Certificate Extension in the SMI Security 796 for PKIX Certificate Extension registry: 797 http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 798 numbers-1.3.6.1.5.5.7.1 800 o TN Certificate Extension in the SMI Security for PKIX Certificate 801 Extension registry: http://www.iana.org/assignments/smi-numbers/ 802 smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 804 o TN-HVE OCSP extension in the SMI Security for PKIX Online 805 Certificate Status Protocol (OCSP) registry: 806 http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 807 numbers-1.3.6.1.5.5.7.48.1 809 o TNS by reference access descriptor in the SMI Security for PKIX 810 Access Descriptor registry: http://www.iana.org/assignments/smi- 811 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48 813 o The TN ASN.1 module in SMI Security for PKIX Module Identifier 814 registry: http://www.iana.org/assignments/smi-numbers/smi- 815 numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0 817 12. Security Considerations 819 This document is entirely about security. For further information on 820 certificate security and practices, see [RFC5280], in particular its 821 Security Considerations. For OCSP-related security considerations 822 see [RFC6960] and [RFC5019] 824 13. Acknowledgments 826 Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave 827 Crocker, Tony Rutkowski, John Braunberger, and Eric Rescorla provided 828 key input to the discussions leading to this document. Russ Housley 829 provided some direct assistance and text surrounding the ASN.1 830 module. 832 14. References 834 [ATIS-0300050] 835 ATIS Recommendation 0300050, "Carrier Identification Code 836 (CIC) Assignment Guidelines", 2012. 838 [I-D.ietf-stir-passport] 839 Wendt, C. and J. Peterson, "Personal Assertion Token 840 (PASSporT)", draft-ietf-stir-passport-08 (work in 841 progress), September 2016. 843 [I-D.ietf-stir-rfc4474bis] 844 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 845 "Authenticated Identity Management in the Session 846 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-13 847 (work in progress), September 2016. 849 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 850 Extensions (MIME) Part Two: Media Types", RFC 2046, 851 DOI 10.17487/RFC2046, November 1996, 852 . 854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 855 Requirement Levels", BCP 14, RFC 2119, 856 DOI 10.17487/RFC2119, March 1997, 857 . 859 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 860 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 861 . 863 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 864 Standards (PKCS) #1: RSA Cryptography Specifications 865 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 866 2003, . 868 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 869 Wu, "Internet X.509 Public Key Infrastructure Certificate 870 Policy and Certification Practices Framework", RFC 3647, 871 DOI 10.17487/RFC3647, November 2003, 872 . 874 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 875 Algorithms and Identifiers for RSA Cryptography for use in 876 the Internet X.509 Public Key Infrastructure Certificate 877 and Certificate Revocation List (CRL) Profile", RFC 4055, 878 DOI 10.17487/RFC4055, June 2005, 879 . 881 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 882 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 883 RFC 4754, DOI 10.17487/RFC4754, January 2007, 884 . 886 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 887 Certificate Status Protocol (OCSP) Profile for High-Volume 888 Environments", RFC 5019, DOI 10.17487/RFC5019, September 889 2007, . 891 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 892 Polk, "Server-Based Certificate Validation Protocol 893 (SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007, 894 . 896 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 897 Housley, R., and W. Polk, "Internet X.509 Public Key 898 Infrastructure Certificate and Certificate Revocation List 899 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 900 . 902 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 903 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 904 DOI 10.17487/RFC5912, June 2010, 905 . 907 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 908 DOI 10.17487/RFC5958, August 2010, 909 . 911 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 912 Galperin, S., and C. Adams, "X.509 Internet Public Key 913 Infrastructure Online Certificate Status Protocol - OCSP", 914 RFC 6960, DOI 10.17487/RFC6960, June 2013, 915 . 917 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 918 Multiple Certificate Status Request Extension", RFC 6961, 919 DOI 10.17487/RFC6961, June 2013, 920 . 922 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 923 "Enrollment over Secure Transport", RFC 7030, 924 DOI 10.17487/RFC7030, October 2013, 925 . 927 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 928 for Generating Key Identifiers Values", RFC 7093, 929 DOI 10.17487/RFC7093, December 2013, 930 . 932 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 933 Telephone Identity Problem Statement and Requirements", 934 RFC 7340, DOI 10.17487/RFC7340, September 2014, 935 . 937 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 938 RFC 7375, DOI 10.17487/RFC7375, October 2014, 939 . 941 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 942 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 943 . 945 [X.509] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-8, 946 "Information technology - Open Systems Interconnection - 947 The Directory: Public-key and attribute certificate 948 frameworks", 2012. 950 [X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6, 951 "Information technology - Open Systems Interconnection - 952 The Directory: Selected Attribute Types", 2012. 954 [X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, 955 "Information Technology - Abstract Syntax Notation One: 956 Specification of basic notation". 958 [X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, 959 "Information Technology - Abstract Syntax Notation One: 960 Information Object Specification". 962 [X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, 963 "Information Technology - Abstract Syntax Notation One: 964 Constraint Specification". 966 [X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, 967 "Information Technology - Abstract Syntax Notation One: 968 Parameterization of ASN.1 Specifications". 970 Appendix A. ASN.1 Module 972 This appendix provides the normative ASN.1 [X.680] definitions for 973 the structures described in this specification using ASN.1, as 974 defined in [X.680] through [X.683]. 976 The modules defined in this document are compatible with the most 977 current ASN.1 specification published in 2015 (see [X.680], [X.681], 978 [X.682], [X.683]). None of the newly defined tokens in the 2008 979 ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE- 980 OID-IRI, TIME, TIME-OF-DAY)) are currently used in any of the ASN.1 981 specifications referred to here. 983 This ASN.1 module imports ASN.1 from [RFC5912]. 985 TN-Module-2016 { 986 iso(1) identified-organization(3) dod(6) internet(1) 987 security(5) mechanisms(5) pkix(7) id-mod(0) 988 id-mod-tn-module(TBD) } 990 DEFINITIONS EXPLICIT TAGS ::= BEGIN 991 IMPORTS 992 id-ad, id-ad-ocsp -- From [RFC5912] 993 FROM PKIX1Explicit-2009 { 994 iso(1) identified-organization(3) dod(6) internet(1) security(5) 995 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } 997 id-ce -- From [RFC5912] 998 FROM PKIX1Implicit-2009 { 999 iso(1) identified-organization(3) dod(6) internet(1) security(5) 1000 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } 1002 EXTENSION -- From [RFC5912] 1003 FROM PKIX-CommonTypes-2009 { 1004 iso(1) identified-organization(3) dod(6) internet(1) 1005 security(5) mechanisms(5) pkix(7) id-mod(0) 1006 id-mod-pkixCommon-02(57) } 1008 ; 1010 -- 1011 -- JWT Claim Constraints Certificate Extension 1012 -- 1014 ext-jwtClaimConstraints EXTENSION ::= { 1015 SYNTAX JWTClaimConstraints IDENTIFIED BY id-ce-JWTClaimConstraints } 1017 id-ce-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-ce TBD1 } 1019 JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint 1021 JWTClaimConstraint ::= SEQUENCE { 1022 claim IA5String, 1023 permitted [1] SEQUENCE OF IA5String OPTIONAL, 1024 excluded [2] SEQUENCE OF IA5String OPTIONAL } 1025 ( WITH COMPONENTS { ..., permitted PRESENT } | 1026 WITH COMPONENTS { ..., excluded PRESENT } ) 1028 -- 1029 -- Telephone Number Authorization List Certificate Extension 1030 -- 1032 ext-tnAuthList EXTENSION ::= { 1033 SYNTAX TNAuthorizationList IDENTIFIED BY id-ce-TNAuthList } 1035 id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD2 } 1037 TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry 1038 TNEntry ::= CHOICE { 1039 spid [0] ServiceProviderIdentifierList, 1040 range [1] TelephoneNumberRange, 1041 one E164Number } 1043 ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF 1044 OCTET STRING 1046 -- Allows SPID, Alt SPID, and Last Alt SPID to be present 1048 TelephoneNumberRange ::= SEQUENCE { 1049 start E164Number, 1050 count INTEGER } 1052 E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789")) 1054 -- 1055 -- Telephone Number Query OCSP Extension 1056 -- 1058 re-ocsp-tn-query EXTENSION ::= { 1059 SYNTAX TNQuery IDENTIFIED BY id-ad-stir-tn } 1061 TNQuery ::= E164Number 1063 id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD3 } 1065 END 1067 Authors' Addresses 1069 Jon Peterson 1070 Neustar, Inc. 1072 Email: jon.peterson@neustar.biz 1074 Sean Turner 1075 sn3rd 1077 Email: sean@sn3rd.com