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