idnits 2.17.1 draft-ietf-stir-certificates-07.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 == Line 786 has weird spacing: '... Name foo-l...' -- The document date (July 8, 2016) is 2848 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 978 -- Looks like a reference, but probably isn't: '1' on line 979 == Outdated reference: A later version (-11) exists of draft-ietf-stir-passport-03 == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-09 ** 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 ** Downref: Normative reference to an Informational RFC: RFC 6711 ** 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: 9 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: January 9, 2017 sn3rd 6 July 8, 2016 8 Secure Telephone Identity Credentials: Certificates 9 draft-ietf-stir-certificates-07.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 proves 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 January 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 . . . . . . . 3 57 4. Certificate Usage . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Enrollment and Authorization using the TN Authorization List 6 59 5.1. Levels Of Assurance . . . . . . . . . . . . . . . . . . . 7 60 5.2. Certificate Extension Scope and Structure . . . . . . . . 8 61 6. Provisioning Private Keying Material . . . . . . . . . . . . 8 62 7. Acquiring Credentials to Verify Signatures . . . . . . . . . 9 63 8. Verifying Certificate Scope with TN Authorization List . . . 10 64 9. Certificate Freshness and Revocation . . . . . . . . . . . . 11 65 9.1. Choosing a Verification Method . . . . . . . . . . . . . 12 66 9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 13 67 9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13 68 9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 15 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 76 1. Introduction 78 The STIR problem statement [RFC7340] identifies the primary enabler 79 of robocalling, vishing, swatting and related attacks as the 80 capability to impersonate a calling party number. The starkest 81 examples of these attacks are cases where automated callees on the 82 PSTN rely on the calling number as a security measure, for example to 83 access a voicemail system. Robocallers use impersonation as a means 84 of obscuring identity; while robocallers can, in the ordinary PSTN, 85 block (that is, withhold) their caller identity, callees are less 86 likely to pick up calls from blocked identities, and therefore 87 appearing to calling from some number, any number, is preferable. 88 Robocallers however prefer not to call from a number that can trace 89 back to the robocaller, and therefore they impersonate numbers that 90 are not assigned to them. 92 One of the most important components of a system to prevent 93 impersonation is the implementation of credentials which identify the 94 parties who control telephone numbers. With these credentials, 95 parties can prove that they are in fact authorized to use telephony 96 numbers, and thus distinguish themselves from impersonators unable to 97 present such credentials. For that reason the STIR threat model 98 [RFC7375] stipulates, "The design of the credential system envisioned 99 as a solution to these threats must, for example, limit the scope of 100 the credentials issued to carriers or national authorities to those 101 numbers that fall under their purview." This document describes 102 credential systems for telephone numbers based on X.509 version 3 103 certificates in accordance with [RFC5280]. While telephone numbers 104 have long been a part of the X.509 standard, this document provides 105 ways to determine authority more aligned with telephone network 106 requirements, including extending X.509 with a Telephone Number 107 Authorization List which binds certificates to authority for 108 particular telephone numbers, or potentially telephone number blocks 109 or ranges. 111 In the STIR in-band architecture specified in 112 [I-D.ietf-stir-rfc4474bis], two basic types of entities need access 113 to these credentials: authentication services, and verification 114 services (or verifiers). An authentication service must be operated 115 by an entity enrolled with the certification authority (CA, see 116 Section 5), whereas a verifier need only trust the trust anchor of 117 the authority, and have a means to access and validate the public 118 keys associated with these certificates. Although the guidance in 119 this document is written with the STIR in-band architecture in mind, 120 the credential system described in this document could be useful for 121 other protocols that want to make use of certificates to prove 122 authority over telephone numbers on the Internet. 124 This document specifies only the credential syntax and semantics 125 necessary to support this architecture. It does not assume any 126 particular CA or deployment environment. We anticipate that some 127 deployment experience will be necessary to determine optimal 128 operational models. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in RFC 135 2119 [RFC2119]. 137 3. Authority for Telephone Numbers in Certificates 139 At a high level, this specification details two non-exclusive 140 approaches that can be employed to determine authority over telephone 141 numbers with certificates. 143 The first approach is to leverage the subject of the certificate to 144 ascertain that the holder of the certificate is authorized to claim 145 authority over a telephone number. The subject might be represented 146 as a domain name in the SubjectAltName, such as an "example.net" 147 where that domain is known to relying parties as a carrier, or 148 represented with other identifiers related to the operation of the 149 telephone network including Service Provider Identifiers (SPIDs) 150 could serve as a subject as well. A relying party could then employ 151 an external data set or service that determines whether or not a 152 specific telephone number is under the authority of the carrier 153 identified as the subject of the certificate, and use that to 154 ascertain whether or not the carrier should have authority over a 155 telephone number. Potentially, a certificate extension to convey the 156 URI of such an information service trusted by the issuer of the 157 certificate could be developed (though this specification does not 158 propose one). Alternatively, some relying parties could form 159 bilateral or multilateral trust relationships with peer carriers, 160 trusting one another's assertions just as telephone carriers in the 161 SS7 network today rely on transitive trust when displaying the 162 calling party telephone number received through SS7 signaling. 164 The second approach is to extend the syntax of certificates to 165 include a new attribute, defined here as TN Authorization List, which 166 contains a list of telephone numbers defining the scope of authority 167 of the certificate. Relying parties, if they trust the issuer of the 168 certificate as a source of authoritative information on telephone 169 numbers, could therefore use the TN Authorization List instead of the 170 subject of the certificate to make a decision about whether or not 171 the signer has authority over a particular telephone number. The TN 172 Authorization List could be provided in one of two ways: as a literal 173 value in the certificate, or as a network service that allows relying 174 parties to query in real time to determine that a telephone number is 175 in the scope of a certificate. Using the TN Authorization list 176 rather than the certificate subject makes sense when, for example, 177 for privacy reasons, the certificate owner would prefer not to be 178 identified, or in cases where the holder of the certificate does not 179 participate in the sort of traditional carrier infrastructure taht 180 the first approach assumes. 182 The first approach requires little change to existing Public Key 183 Infrastructure (PKI) certificates; for the second approach, we must 184 define an appropriate enrollment and authorization process. For the 185 purposes of STIR, the over-the-wire format specified in 186 [I-D.ietf-stir-rfc4474bis] accommodates either of these approaches: 187 the methods for canonicalizing, signing, for identifying and 188 accessing the certificate and so on remain the same; it is only the 189 verifier behavior and authorization decision that will change 190 depending on the approach to telephone number authority taken by the 191 certificate. For that reason, the two approaches are not mutually 192 exclusive, and in fact a certificate issued to a traditional 193 telephone network service provider could contain a TN Authorization 194 List or not, depending on the CA issuing the credential. Regardless 195 of which approach is used, certificates that assert authority over 196 telephone numbers are subject to the ordinary operational procedures 197 that govern certificate use per [RFC5280]. This means that 198 verification services must be mindful of the need to ensure that they 199 trust the trust anchor that issued the certificate, and that they 200 have some means to determine the freshness of the certificate (see 201 Section 9). 203 4. Certificate Usage 205 [I-D.ietf-stir-rfc4474bis] requires that all credential systems used 206 for signing the Identity header in SIP detail the following: 208 1. The URI schemes permitted in the SIP Identity header "info" 209 parameter, as well as any special procedures required to 210 dereference the URIs. While normative text is given below in 211 Section 7, this mechanism permits the HTTP, CID and SIP URI 212 schemes to appear in the "info" parameter. 214 2. Procedures required to extract keying material from the resources 215 designated by the URI. Implementations perform no special 216 procedures beyond dereferencing the "info" URI. See Section 7. 218 3. Procedures used by the verification service to determine the 219 scope of the credential. This specification effectively proposes 220 two methods, as outlined in Section 3: one where the subject (or 221 more properly subjectAltName) of the certificate indicates the 222 scope of authority through a domain name, and relying parties 223 either trust the subject entirely or have some direct means of 224 determining whether or not a number falls under a subject's 225 authority; and another where an extension to the certificate as 226 described in Section 8 identifies the scope of the certificate. 228 4. The cryptographic algorithms required to validate the 229 credentials. For this specification, that means the signature 230 algorithms used to sign certificates. This specification 231 REQUIRES that implementations support both ECDSA with the P-256 232 curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447] 233 Section 8.2) for certificate signatures. Implementers are 234 advised that RS256 is mandated only as a transitional mechanism, 235 due to its widespread use in existing PKI, but we anticipate that 236 this mechanism will eventually be deprecated. 238 5. Finally, note that all certificates compliant with this 239 specification: 241 * MUST provide cryptographic keying material sufficient to 242 generate the ECDSA using P-256 and SHA-256 signatures 243 necessary to support the ES256 hashed signatures required by 244 PASSporT [I-D.ietf-stir-passport], which in turn follows JSON 245 Web Token (JWT) [RFC7519]. 247 * MUST support both ECDSA with P-256 and RSA PKCS#1 v1.5 for 248 certificate signature verification. 250 This document also includes additional certificate-related 251 requirements: 253 o See Section 5.1 for requirements related to the certificate 254 policies extension. 256 o See Section 7 for requirements related to the TN Query certificate 257 extension. 259 o See Section 9.2 and Section 9.3 for requirements related to the 260 Authority Information Access (AIA) certificate extension. 262 o See Section 9.2.1 for requirements related to the authority key 263 identifier and subject key identifier certificate extensions. 265 5. Enrollment and Authorization using the TN Authorization List 267 This document assumes a threefold model for certificate enrollment 268 when using the TN Authorization List extension. 270 The first enrollment model is one where the CA acts in concert with 271 national numbering authorities to issue credentials to those parties 272 to whom numbers are assigned. In the United States, for example, 273 telephone number blocks are assigned to Local Exchange Carriers 274 (LECs) by the North American Numbering Plan Administrator (NANPA), 275 who is in turn directed by the national regulator. LECs may also 276 receive numbers in smaller allocations, through number pooling, or 277 via an individual assignment through number portability. LECs assign 278 numbers to customers, who may be private individuals or organizations 279 - and organizations take responsibility for assigning numbers within 280 their own enterprise. This model requires top-down adoption of the 281 model from regulators through to carriers. 283 The second enrollment model is a bottom-up approach where a CA 284 requires that an entity prove control by means of some sort of test, 285 which, as with certification authorities for web PKI, might either be 286 automated or a manual administrative process. As an example of an 287 automated process, an authority might send a text message to a 288 telephone number containing a URL (which might be dereferenced by the 289 recipient) as a means of verifying that a user has control of 290 terminal corresponding to that number. Checks of this form are 291 frequently used in commercial systems today to validate telephone 292 numbers provided by users. This is comparable to existing enrollment 293 systems used by some certificate authorities for issuing S/MIME 294 credentials for email by verifying that the party applying for a 295 credential receives mail at the email address in question. 297 The third enrollment model is delegation: that is, the holder of a 298 certificate (assigned by either of the two methods above) might 299 delegate some or all of their authority to another party. In some 300 cases, multiple levels of delegation could occur: a LEC, for example, 301 might delegate authority to a customer organization for a block of 302 100 numbers used by an IP PBX, and the organization might in turn 303 delegate authority for a particular number to an individual employee. 304 This is analogous to delegation of organizational identities in 305 traditional hierarchical PKIs who use the name constraints extension 306 [RFC5280]; the root CA delegates names in sales to the sales 307 department CA, names in development to the development CA, etc. As 308 lengthy certificate delegation chains are brittle, however, and can 309 cause delays in the verification process, this document considers 310 optimizations to reduce the complexity of verification. 312 Future versions of this specification may also discuss methods of 313 partial delegation, where certificate holders delegate only part of 314 their authority. For example, individual assignees may want to 315 delegate to a service authority for text messages associated with 316 their telephone number, but not for other functions. 318 5.1. Levels Of Assurance 320 This specification supports different level of assurance (LOA). The 321 LOA indications, which are Object Identifiers (OIDs) included in the 322 certificate's certificate policies extension [RFC5280], allow CAs to 323 differentiate those enrolled from proof-of-possession versus 324 delegation. A Certification Policy and a Certification Practice 325 Statement [RFC3647] are produced as part of the normal PKI 326 bootstrapping process (i.e., the CP is written first and then the CAs 327 say how they conform to the CP in the CPS). OIDs are used to 328 reference the CP and if the CA wishes it can also include a reference 329 to the CPS with the certificate policies extension. CAs that wish to 330 express different LOAs MUST include the certificate policies 331 extension in issued certificates. See Section 11 for additional 332 information about the LOA registry. 334 5.2. Certificate Extension Scope and Structure 336 This specification places no limits on the number of telephone 337 numbers that can be associated with any given certificate. Some 338 service providers may be assigned millions of numbers, and may wish 339 to have a single certificate that is capable of signing for any one 340 of those numbers. Others may wish to compartmentalize authority over 341 subsets of the numbers they control. 343 Moreover, service providers may wish to have multiple certificates 344 with the same scope of authority. For example, a service provider 345 with several regional gateway systems may want each system to be 346 capable of signing for each of their numbers, but not want to have 347 each system share the same private key. 349 The set of telephone numbers for which a particular certificate is 350 valid is expressed in the certificate through a certificate 351 extension; the certificate's extensibility mechanism is defined in 352 [RFC5280] but the TN Authorization List extension is specified in 353 this document. 355 The subjects of certificates containing the TN Authorization List 356 extension are typically the administrative entities to whom numbers 357 are assigned or delegated. For example, a LEC might hold a 358 certificate for a range of telephone numbers. In some cases, the 359 organization or individual issued such a certificate may not want to 360 associate themselves with a certificate; for example, a private 361 individual with a certificate for a single telephone number might not 362 want to distribute that certificate publicly if every verifier 363 immediately knew their name. The certification authorities issuing 364 certificates with the TN Authorization List extensions may, in 365 accordance with their policies, obscure the identity of the subject, 366 though mechanisms for doing so are outside the scope of this 367 document. 369 6. Provisioning Private Keying Material 371 In order for authentication services to sign calls via the procedures 372 described in [I-D.ietf-stir-rfc4474bis], they must hold a private key 373 corresponding to a certificate with authority over the calling 374 number. This specification does not require that any particular 375 entity in a SIP deployment architecture sign requests, only that it 376 be an entity with an appropriate private key; the authentication 377 service role may be instantiated by any entity in a SIP network. For 378 a certificate granting authority only over a particular number which 379 has been issued to an end user, for example, an end user device might 380 hold the private key and generate the signature. In the case of a 381 service provider with authority over large blocks of numbers, an 382 intermediary might hold the private key and sign calls. 384 The specification recommends distribution of private keys through 385 PKCS#8 objects signed by a trusted entity, for example through the 386 CMS package specified in [RFC5958]. 388 7. Acquiring Credentials to Verify Signatures 390 This specification documents multiple ways that a verifier can gain 391 access to the credentials needed to verify a request. As the 392 validity of certificates does not depend on the method of their 393 acquisition, there is no need to standardize any single mechanism for 394 this purpose. All entities that comply with 395 [I-D.ietf-stir-rfc4474bis] necessarily support SIP, and consequently 396 SIP itself can serve as a way to acquire certificates. 397 [I-D.ietf-stir-rfc4474bis] provides an "info" parameter of the 398 Identity header which contains a URI where the credential used to 399 generate the Identity header, and requires documents which define 400 credential systems to list the URI schemes that may be present in the 401 "info" parameter. For implementations compliant with this 402 specification, three URI schemes are REQUIRED: the CID URI, the SIP 403 URI, and the HTTP URI. 405 The simplest way for a verifier to acquire the certificate needed to 406 verify a signature is for the certificate be conveyed in a SIP 407 request along with the signature itself. In SIP, for example, a 408 certificate could be carried in a multipart MIME body [RFC2046], and 409 the URI in the Identity header "info" parameter could specify that 410 body with a CID URI [RFC2392]. However, in many environments this is 411 not feasible due to message size restrictions or lack of necessary 412 support for multipart MIME. 414 More commonly, the Identity header "info" parameter in a SIP request 415 may contain a URI that the verifier dereferences with a network call. 416 Implementations of this specification are required to support the use 417 of SIP for this function (via the SUBSCRIBE/NOTIFY mechanism), as 418 well as HTTP, via the Enrollment over Secure Transport mechanisms 419 described in RFC 7030 [RFC7030]. 421 Note well that as an optimization, a verifier may have access to a 422 service, a cache or other local store that grants access to 423 certificates for a particular telephone number. However, there may 424 be multiple valid certificates that can sign a call setup request for 425 a telephone number, and as a consequence, there needs to be some 426 discriminator that the signer uses to identify their credentials. 427 The Identity header "info" parameter itself can serve as such a 428 discriminator, provided implementations use that parameter as a key 429 when accessing certificates from caches or other sources. 431 8. Verifying Certificate Scope with TN Authorization List 433 The subjects of certificates containing the TN Authorization List 434 extension are the administrative entities to whom numbers are 435 assigned or delegated. When a verifier is validating a caller's 436 identity, local policy always determines the circumstances under 437 which any particular subject may be trusted, but the purpose of the 438 TN Authorization List extension particular is to allow a verifier to 439 ascertain when the CA has designed that the subject has authority 440 over a particular telephone number or number range. 442 The Telephony Number (TN) Authorization List certificate extension is 443 identified by the following object identifier: 445 id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD } 447 The TN Authorization List certificate extension has the following 448 syntax: 450 TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization 452 TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry 454 TNEntry ::= CHOICE { 455 spid [0] ServiceProviderIdentifierList, 456 range [1] TelephoneNumberRange, 457 one E164Number } 459 ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF 460 OCTET STRING 462 -- When all three are present: SPID, Alt SPID, and Last Alt SPID 464 TelephoneNumberRange ::= SEQUENCE { 465 start E164Number, 466 count INTEGER } 468 E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789")) 470 The TN Authorization List certificate extension indicates the 471 authorized phone numbers for the call setup signer. It indicates one 472 or more blocks of telephone number entries that have been authorized 473 for use by the call setup signer. There are three ways to identify 474 the block: 476 1. A Service Provider Identifier (SPID) can be used to indirectly 477 name all of the telephone numbers associated with that service 478 provider, 480 2. Telephone numbers can be listed in a range, and 482 3. A single telephone number can be listed. 484 Note that because large-scale service providers may want to associate 485 many numbers, possibly millions of numbers, with a particular 486 certificate, optimizations are required for those cases to prevent 487 certificate size from becoming unmanageable. In these cases, the TN 488 Authorization List may be given by reference rather than by value, 489 through the presence of a separate certificate extension that permits 490 verifiers to either securely download the list of numbers associated 491 with a certificate, or to verify that a single number is under the 492 authority of this certificate. This optimization will be detailed in 493 future version of this specification. 495 9. Certificate Freshness and Revocation 497 Regardless of which of the approaches in Section 3 is followed for 498 using certificates, some sort of certificate verification mechanism 499 is required. However, the traditional problem of certificate 500 freshness gains a new wrinkle when using the TN Authorization List 501 extension, because verifiers must establish not only that a 502 certificate remains valid, but also that the certificate's scope 503 contains the telephone number that the verifier is validating. 504 Dynamic changes to number assignments can occur due to number 505 portability, for example. So even if a verifier has a valid cached 506 certificate for a telephone number (or a range containing the 507 number), the verifier must determine that the entity that signed is 508 still a proper authority for that number. 510 To verify the status of the certificate, the verifier needs to 511 acquire the certificate if necessary (via the methods described in 512 Section 7), and then would need to either: 514 (a) Rely on short-lived certificates and not check the certificate's 515 status, or 517 (b) Rely on status information from the authority 519 The tradeoff between short lived certificates and using status 520 information is the former's burden is on the front end (i.e., 521 enrollment) and the latter's burden is on the back end (i.e., 522 verification). Both impact call setup time, but it is assumed that 523 performing enrollment for each call is more of an impact that using 524 status information. This document therefore recommends relying on 525 status information. 527 9.1. Choosing a Verification Method 529 There are three common certificate verification mechanisms employed 530 by CAs: 532 1. Certificate Revocation Lists (CRLs) [RFC5280] 534 2. Online Certificate Status Protocol (OCSP) [RFC6960], and 536 3. Server-based Certificate Validation Protocol (SCVP) [RFC5055]. 538 When relying on status information, the verifier needs to obtain the 539 status information - but before that can happen, the verifier needs 540 to know where to locate it. Placing the location of the status 541 information in the certificate makes the certificate larger, but it 542 eases the client workload. The CRL Distribution Point certificate 543 extension includes the location of the CRL and the Authority 544 Information Access certificate extension includes the location of 545 OCSP and/or SCVP servers; both of these extensions are defined in 546 [RFC5280]. In all cases, the status information location is provided 547 in the form of an URI. 549 CRLs are an obviously attractive solution because they are supported 550 by every CA. CRLs have a reputation of being quite large (10s of 551 MBytes), because CAs maintain and issue one monolithic CRL with all 552 of their revoked certificates, but CRLs do support a variety of 553 mechanisms to scope the size of the CRLs based on revocation reasons 554 (e.g., key compromise vs CA compromise), user certificates only, and 555 CA certificates only as well as just operationally deciding to keep 556 the CRLs small. However, scoping the CRL introduces other issues 557 (i.e., does the RP have all of the CRL partitions). 559 CAs in the STIR architecture will likely all create CRLs for audit 560 purposes, but it NOT RECOMMENDED that they be relying upon for status 561 information. Instead, one of the two "online" options is preferred. 562 Between the two, OCSP is much more widely deployed and this document 563 therefore recommends the use of OCSP in high-volume environments 564 (HVE) for validating the freshness of certificates, based on 565 [RFC6960], incorporating some (but not all) of the optimizations of 566 [RFC5019]. CRLs MUST be signed with the same algorithm as the 567 certificate. 569 9.2. Using OCSP with TN Auth List 571 Certificates compliant with this specification therefore SHOULD 572 include a URL pointing to an OCSP service in the Authority 573 Information Access (AIA) certificate extension, via the "id-ad-ocsp" 574 accessMethod specified in [RFC5280]. Baseline OCSP however supports 575 only three possible response values: good, revoked, or unknown. 576 Without some extension, OCSP would not indicate whether the 577 certificate is authorized for a particular telephone number that the 578 verifier is validating. 580 At a high level, there are two ways that a client might pose this 581 authorization question: 583 For this certificate, is the following number currently in its 584 scope of validity? 586 What are all the telephone numbers associated with this 587 certificate, or this certificate subject? 589 Only the former lends itself to piggybacking on the OCSP status 590 mechanism; since the verifier is already asking an authority about 591 the certificate's status, why not reuse that mechanism, instead of 592 creating a new service that requires additional round trips? Like 593 most PKIX-developed protocols, OCSP is extensible; OCSP supports 594 request extensions (including sending multiple requests at once) and 595 per-request extensions. It seems unlikely that the verifier will be 596 requesting authorization checks on multiple telephone numbers in one 597 request, so a per-request extension is what is needed. 599 The requirement to consult OCSP in real time results in a network 600 round-trip time of day, which is something to consider because it 601 will add to the call setup time. OCSP server implementations 602 commonly pre-generate responses, and to speed up HTTPS connections, 603 servers often provide OCSP responses for each certificate in their 604 hierarchy. If possible, both of these OCSP concepts should be 605 adopted for use with STIR. 607 9.2.1. OCSP Extension Specification 609 The extension mechanism for OCSP follows X.509 v3 certificate 610 extensions, and thus requires an OID, a criticality flag, and ASN.1 611 syntax as defined by the OID. The criticality specified here is 612 optional: per [RFC6960] Section 4.4, support for all OCSP extensions 613 is optional. If the OCSP server does not understand the requested 614 extension, it will still provide the baseline validation of the 615 certificate itself. Moreover, in practical STIR deployments, the 616 issuer of the certificate will set the accessLocation for the OCSP 617 AIA extension to point to an OCSP service that supports this 618 extension, so the risk of interoperability failure due to lack of 619 support for this extension is minimal. 621 The OCSP TNQuery extension is included as one of the request's 622 signlerequestExtensions. It may also appear in the response's 623 singleExtensions. When an OCSP server includes a number in the 624 response's singleExtensions, this informs the client that the 625 certificate is still valid for the number that appears in the TNQuery 626 extension field. If the TNQuery is absent from a response to a query 627 containing a TNQuery in its singleRequestExtension, then the server 628 is not able to validate that the number is still in the scope of 629 authority of the certificate. 631 id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD } 633 TNQuery ::= E164Number 635 The HVE OCSP profile [RFC5019] prohibits the use of per-request 636 extensions. As it is anticipated that STIR will use OCSP in a high- 637 volume environment, many of the optimizations recommended by HVE are 638 desirable for the STIR environment. This document therefore uses the 639 HVE optimizations augmented as follows: 641 o Implementations MUST use SHA-256 as the hashing algorithm for the 642 CertID.issuerNameHash and the CertID.issuerKeyHash values. That 643 is CertID.hashAlgorithm is id-sha256 [RFC4055] and the values are 644 truncated to 160-bits as specified Option 1 in Sectin 2 of as per 645 in [RFC7093]. 647 o Clients MUST include the OCSP TNQuery extension in requests' 648 singleRequestExtensions. 650 o Servers MUST include the OCSP TNQuery extension in responses' 651 singleExtensions. 653 o Servers SHOULD return responses that would otherwise have been 654 "unknown" as "not good" (i.e., return only "good" and "not good" 655 responses). 657 o Clients MUST treat returned "unknown" responses as "not good". 659 o If the server uses ResponderID, it MUST generate the KeyHash using 660 SHA-256 and truncate the value to 160-bits as specified in Option 661 1 in Section 2 of [RFC7093]. 663 o Implementations MUST support ECDSA using P-256 and SHA-256. Note 664 that [RFC6960] requires RSA with SHA-256 be supported. 666 o There is no requirement to support SHA-1, RSA with SHA-1, or DSA 667 with SHA-1. 669 OCSP responses MUST be signed using the same algorithm as the 670 certificate being checked. 672 To facilitate matching the authority key identifier values found in 673 CA certificates with the KeyHash used in the OCSP response, 674 certificates compliant with this specification MUST generate 675 authority key identifiers and subject key identifers using the 676 SHA-256 and truncate the value to 160-bits as specified in Option 1 677 in Section 2 of [RFC7093]. 679 Ideally, once a certificate has been acquired by a verifier, some 680 sort of asynchronous mechanism could notify and update the verifier 681 if the scope of the certificate changes so that verifiers could 682 implement a cache. While not all possible categories of verifiers 683 could implement such behavior, some sort of event-driven notification 684 of certificate status is another potential subject of future work. 685 One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based 686 accessMethod for AIA might be defined (which would also be applicable 687 to the method described in the following section) by some future 688 specification. 690 Strategies for stapling OCSP [RFC6961] have become common in some web 691 PKI environments as an optimization which allows web servers to send 692 up-to-date certificate status information acquired from OCSP to 693 clients as TLS is negotiated. A similar mechanism could be 694 implemented for SIP requests, in which the authentication service 695 adds status information for its certificate to the SIP request, which 696 would save the verifier the trouble of performing the OCSP dip 697 itself. Especially for high-volume authentication and verification 698 services, this could result in significant performance improvements. 699 This is left as an optimization for future work. 701 9.3. Acquiring TN Lists By Reference 703 Acquiring a list of the telephone numbers associated with a 704 certificate or its subject lends itself to an application-layer 705 query/response interaction outside of OCSP, one which could be 706 initiated through a separate URI included in the certificate. The 707 AIA extension (see [RFC5280]) supports such a mechanism: it 708 designates an OID to identify the accessMethod and an accessLocation, 709 which would most likely be a URI. A verifier would then follow the 710 URI to ascertain whether the list of TNs authorized for use by the 711 caller. 713 HTTPS is the most obvious candidate for a protocol to be used for 714 fetching the list of telephone number associated with a particular 715 certificate. This document defines a new AIA accessMethod, called 716 "id-ad-stir-tn", which uses the following AIA OID: 718 id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD } 720 When the "id-ad-stir-tn" accessMethod is used, the accessLocation 721 MUST be an HTTPS URI. The document returned by dereferencing that 722 URI will contain the complete TN Authorization List (see Section 8) 723 for the certificate. 725 Delivering the entire list of telephone numbers associated with a 726 particular certificate will divulge to STIR verifiers information 727 about telephone numbers other than the one associated with the 728 particular call that the verifier is checking. In some environments, 729 where STIR verifiers handle a high volume of calls, maintaining an 730 up-to-date and complete cache for the numbers associated with crucial 731 certificate holders could give an important boost to performance. 733 10. Acknowledgments 735 Russ Housley, Brian Rosen, Cullen Jennings and Eric Rescorla provided 736 key input to the discussions leading to this document. 738 11. IANA Considerations 740 This document makes use of object identifiers for the TN Certificate 741 Extension defined in Section 8, TN-HVE OCSP extension in 742 Section 9.2.1, the TN by reference AIA access descriptor defined in 743 Section 9.3, and the ASN.1 module identifier defined in Appendix A. 744 It therefore requests that the IANA make the following assignments: 746 o TN Certificate Extension in the SMI Security for PKIX Certificate 747 Extension registry: http://www.iana.org/assignments/smi-numbers/ 748 smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 750 o TN-HVE OCSP extension in the SMI Security for PKIX Online 751 Certificate Status Protocol (OCSP) registry: 752 http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 753 numbers-1.3.6.1.5.5.7.48.1 755 o TNS by reference access descriptor in the SMI Security for PKIX 756 Access Descriptor registry: http://www.iana.org/assignments/smi- 757 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48 759 o The TN ASN.1 module in SMI Security for PKIX Module Identifier 760 registry: http://www.iana.org/assignments/smi-numbers/smi- 761 numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0 763 This document also makes use of the Level of Assurance (LoA) Profiles 764 registry defined in [RFC6711] because as is stated in RFC 6711: "Use 765 of the registry by protocols other than SAML is encouraged." IANA is 766 requested to creae the STIR Levels of Assurance (LOA) sub-registry in 767 the Level of Assurance (LoA) Profile registry. Instead of 768 registering a SAML Context Class, the Certificate Policy's Object 769 Identifier representing the LOA is included in the registry. An 770 example registration is as follows: 772 To: loa-profiles-experts@icann.org 774 From: jrandom@example.com 776 1. Name of requester: J. Random User 778 2. Email address of requester: jrandom@example.com 780 3. Organization of requester: Example Trust Frameworks LLP 782 4. Requested registration: 784 URI http://foo.example.com/assurance/loa-1 786 Name foo-loa-1 788 Informational URL https://foo.example.com/assurance/ 790 Certificate Policy Object Identifier: 0.0.0.0 792 NOTE: Do not register this example. The OID is purposely invalid. 794 Experts are expected to ensure the reference CP includes the OID 795 being registered. 797 12. Security Considerations 799 This document is entirely about security. For further information on 800 certificate security and practices, see [RFC5280], in particular its 801 Security Considerations. For OCSP-related security considerations 802 see [RFC6960] and [RFC5019] 804 13. References 806 [I-D.ietf-stir-passport] 807 Wendt, C. and J. Peterson, "Persona Assertion Token", 808 draft-ietf-stir-passport-03 (work in progress), June 2016. 810 [I-D.ietf-stir-rfc4474bis] 811 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 812 "Authenticated Identity Management in the Session 813 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-09 814 (work in progress), May 2016. 816 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 817 Extensions (MIME) Part Two: Media Types", RFC 2046, 818 DOI 10.17487/RFC2046, November 1996, 819 . 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, 823 DOI 10.17487/RFC2119, March 1997, 824 . 826 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 827 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 828 . 830 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 831 Standards (PKCS) #1: RSA Cryptography Specifications 832 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 833 2003, . 835 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 836 Wu, "Internet X.509 Public Key Infrastructure Certificate 837 Policy and Certification Practices Framework", RFC 3647, 838 DOI 10.17487/RFC3647, November 2003, 839 . 841 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 842 Algorithms and Identifiers for RSA Cryptography for use in 843 the Internet X.509 Public Key Infrastructure Certificate 844 and Certificate Revocation List (CRL) Profile", RFC 4055, 845 DOI 10.17487/RFC4055, June 2005, 846 . 848 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 849 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 850 RFC 4754, DOI 10.17487/RFC4754, January 2007, 851 . 853 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 854 Certificate Status Protocol (OCSP) Profile for High-Volume 855 Environments", RFC 5019, DOI 10.17487/RFC5019, September 856 2007, . 858 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 859 Polk, "Server-Based Certificate Validation Protocol 860 (SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007, 861 . 863 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 864 Housley, R., and W. Polk, "Internet X.509 Public Key 865 Infrastructure Certificate and Certificate Revocation List 866 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 867 . 869 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 870 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 871 DOI 10.17487/RFC5912, June 2010, 872 . 874 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 875 DOI 10.17487/RFC5958, August 2010, 876 . 878 [RFC6711] Johansson, L., "An IANA Registry for Level of Assurance 879 (LoA) Profiles", RFC 6711, DOI 10.17487/RFC6711, August 880 2012, . 882 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 883 Galperin, S., and C. Adams, "X.509 Internet Public Key 884 Infrastructure Online Certificate Status Protocol - OCSP", 885 RFC 6960, DOI 10.17487/RFC6960, June 2013, 886 . 888 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 889 Multiple Certificate Status Request Extension", RFC 6961, 890 DOI 10.17487/RFC6961, June 2013, 891 . 893 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 894 "Enrollment over Secure Transport", RFC 7030, 895 DOI 10.17487/RFC7030, October 2013, 896 . 898 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 899 for Generating Key Identifiers Values", RFC 7093, 900 DOI 10.17487/RFC7093, December 2013, 901 . 903 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 904 Telephone Identity Problem Statement and Requirements", 905 RFC 7340, DOI 10.17487/RFC7340, September 2014, 906 . 908 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 909 RFC 7375, DOI 10.17487/RFC7375, October 2014, 910 . 912 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 913 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 914 . 916 [X.680] USC/Information Sciences Institute, "Information 917 Technology - Abstract Syntax Notation One.", ITU-T X.680, 918 ISO/IEC 8824-1:2002, 2002. 920 [X.681] USC/Information Sciences Institute, "Information 921 Technology - Abstract Syntax Notation One: Information 922 Object Specification", ITU-T X.681, ISO/IEC 8824-2:2002, 923 2002. 925 [X.682] USC/Information Sciences Institute, "Information 926 Technology - Abstract Syntax Notation One: Constraint 927 Specification", ITU-T X.682, ISO/IEC 8824-3:2002, 2002. 929 [X.683] USC/Information Sciences Institute, "Information 930 Technology - Abstract Syntax Notation One: 931 Parameterization of ASN.1 Specifications", ITU-T X.683, 932 ISO/IEC 8824-4:2002, 2002. 934 Appendix A. ASN.1 Module 936 This appendix provides the normative ASN.1 [X.680] definitions for 937 the structures described in this specification using ASN.1, as 938 defined in [X.680] through [X.683]. 940 This ASN.1 module imports ASN.1 from [RFC5912]. 942 TN-Module { 943 iso(1) identified-organization(3) dod(6) internet(1) 944 security(5) mechanisms(5) pkix(7) id-mod(0) 945 id-mod-tn-module(TBD) } 947 DEFINITIONS EXPLICIT TAGS ::= BEGIN 949 IMPORTS 950 id-ad, id-ad-ocsp -- From [RFC5912] 951 FROM PKIX1Explicit-2009 { 952 iso(1) identified-organization(3) dod(6) internet(1) security(5) 953 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } 955 id-ce -- From [RFC5912] 956 FROM PKIX1Implicit-2009 { 957 iso(1) identified-organization(3) dod(6) internet(1) security(5) 958 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } 960 EXTENSION -- From [RFC5912] 961 FROM PKIX-CommonTypes-2009 { 962 iso(1) identified-organization(3) dod(6) internet(1) 963 security(5) mechanisms(5) pkix(7) id-mod(0) 964 id-mod-pkixCommon-02(57) } 966 ; 968 -- TN Entry Certificate Extension 970 ext-tnAuthList EXTENSION ::= { 971 SYNTAX TNAuthorizationList IDENTIFIED BY id-ce-TNAuthList } 973 TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization 975 TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry 977 TNEntry ::= CHOICE { 978 spid [0] ServiceProviderIdentifierList, 979 range [1] TelephoneNumberRange, 980 one E164Number } 982 ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF 983 OCTET STRING 985 -- When all three are present: SPID, Alt SPID, and Last Alt SPID 987 TelephoneNumberRange ::= SEQUENCE { 988 start E164Number, 989 count INTEGER } 991 E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789")) 992 -- TN OCSP Extension 994 re-ocsp-tn-query EXTENSION ::= { 995 SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn } 997 TNQuery ::= E164Number 999 -- TN Access Descriptor 1001 id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD } 1003 -- 1004 -- Object Identifiers 1005 -- 1007 id-pkix-ocsp OBJECT IDENTIFIER ::= id-ad-ocsp 1008 id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD } 1009 id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD } 1011 END 1013 Authors' Addresses 1015 Jon Peterson 1016 Neustar, Inc. 1018 Email: jon.peterson@neustar.biz 1020 Sean Turner 1021 sn3rd 1023 Email: sean@sn3rd.com