idnits 2.17.1 draft-ietf-stir-certificates-03.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 6 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 21, 2016) is 2951 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) == Missing Reference: 'TBD' is mentioned on line 526, but not defined == Missing Reference: 'More TBD' is mentioned on line 570, but not defined == Unused Reference: 'I-D.peterson-sipping-retarget' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'RFC3263' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'RFC7299' is defined on line 752, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-07 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 4 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: September 22, 2016 Sn3rd 6 March 21, 2016 8 Secure Telephone Identity Credentials: Certificates 9 draft-ietf-stir-certificates-03.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 September 22, 2016. 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. Enrollment and Authorization using the TN Authorization List 5 58 4.1. Certificate Extension Scope and Structure . . . . . . . . 6 59 5. Provisioning Private Keying Material . . . . . . . . . . . . 7 60 6. Acquiring Credentials to Verify Signatures . . . . . . . . . 7 61 7. Verifying Certificate Scope with TN Authorization List . . . 8 62 8. Certificate Freshness and Revocation . . . . . . . . . . . . 10 63 8.1. Choosing a Verification Method . . . . . . . . . . . . . 10 64 8.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 11 65 8.2.1. OCSP Extension Specification . . . . . . . . . . . . 12 66 8.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 13 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 12. Informative References . . . . . . . . . . . . . . . . . . . 15 71 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 The STIR problem statement [I-D.ietf-stir-problem-statement] 77 identifies the primary enabler of robocalling, vishing, swatting and 78 related attacks as the capability to impersonate a calling party 79 number. The starkest examples of these attacks are cases where 80 automated callees on the PSTN rely on the calling number as a 81 security measure, for example to access a voicemail system. 82 Robocallers use impersonation as a means of obscuring identity; while 83 robocallers can, in the ordinary PSTN, block (that is, withhold) 84 their caller identity, callees are less likely to pick up calls from 85 blocked identities, and therefore appearing to calling from some 86 number, any number, is preferable. Robocallers however prefer not to 87 call from a number that can trace back to the robocaller, and 88 therefore they impersonate numbers that are not assigned to them. 90 One of the most important components of a system to prevent 91 impersonation is the implementation of credentials which identify the 92 parties who control telephone numbers. With these credentials, 93 parties can prove that they are in fact authorized to use telephony 94 numbers, and thus distinguish themselves from impersonators unable to 95 present such credentials. This document describes credential systems 96 for telephone numbers based on X.509 version 3 certificates in 97 accordance with [RFC5280]. While telephone numbers have long been a 98 part of the X.509 standard, this document extends X.509 with a 99 Telephone Number Authorization List which binds certificates to 100 authority for particular telephone numbers, or potentially telephone 101 number blocks or ranges. 103 In the STIR in-band architecture specified in 104 [I-D.ietf-stir-rfc4474bis], two basic types of entities need access 105 to these credentials: authentication services, and verification 106 services (or verifiers). An authentication service must be operated 107 by an entity enrolled with the certification authority (see 108 Section 4), whereas a verifier need only trust the root certificate 109 of the authority, and have a means to access and validate the public 110 keys associated with these certificates. Although the guidance in 111 this document is written with the STIR in-band architecture in mind, 112 the credential system described in this document could be useful for 113 other protocols that want to make use of certificates to prove 114 authority over telephone numbers on the Internet. 116 This document specifies only the credential syntax and semantics 117 necessary to support this architecture. It does not assume any 118 particular certification authority or deployment environment. We 119 anticipate that some deployment experience will be necessary to 120 determine optimal operational models. 122 2. Terminology 124 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 125 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 126 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 127 described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919]. 129 3. Authority for Telephone Numbers in Certificates 131 At a high level, this specification details two non-exclusive 132 approaches that can be employed to determine authority over telephone 133 numbers with certificates. 135 The first approach is to leverage the subject of the certificate to 136 ascertain that the holder of the certificate is authorized to claim 137 authority over a telephone number. The subject might be represented 138 as a domain name in the SubjectAltName, such as an "example.net" 139 where that domain is known to relying parties as a carrier, or 140 represented with other identifiers related to the operation of the 141 telephone network including Service Provider Identifiers (SPIDs) 142 could serve as a subject as well. A relying party could then employ 143 an external data set or service that determines whether or not a 144 specific telephone number is under the authority of the carrier 145 identified as the subject of the certificate, and use that to 146 ascertain whether or not the carrier should have authority over a 147 telephone number. Potentially, a certificate extension to convey the 148 URI of such an information service trusted by the issuer of the 149 certificate could be developed (though this specification does not 150 propose one). Alternatively, some relying parties could form 151 bilateral or multilateral trust relationships with peer carriers, 152 trusting one another's assertions just as telephone carriers in the 153 SS7 network today rely on transitive trust when displaying the 154 calling party telephone number received through SS7 signaling. 156 The second approach is to extend the syntax of certificates to 157 include a new attribute, defined here as TN Authorization List, which 158 contains a list of telephone numbers defining the scope of authority 159 of the certificate. Relying parties, if they trust the issuer of the 160 certificate as a source of authoritative information on telephone 161 numbers, could therefore use the TN Authorization List instead of the 162 subject of the certificate to make a decision about whether or not 163 the signer has authority over a particular telephone number. The TN 164 Authorization List could be provided in one of two ways: as a literal 165 value in the certificate, or as a network service that allows relying 166 parties to query in real time to determine that a telephone number is 167 in the scope of a certificate. Using the TN Authorization list 168 rather than the certificate subject makes sense when, for example, 169 for privacy reasons, the certificate owner would prefer not to be 170 identified, or in cases where the holder of the certificate does not 171 participate in the sort of traditional carrier infrastructure taht 172 the first approach assumes. 174 The first approach requires little change to existing PKI 175 certificates; for the second approach, we must define an appropriate 176 enrollment and authorization process. For the purposes of STIR, the 177 over-the-wire format specified in [I-D.ietf-stir-rfc4474bis] 178 accommodates either of these approaches: the methods for 179 canonicalizing, signing, for identifying and accessing the 180 certificate and so on remain the same; it is only the verifier 181 behavior and authorization decision that will change depending on the 182 approach to telephone number authority taken by the certificate. For 183 that reason, the two approaches are not mutually exclusive, and in 184 fact a certificate issued to a traditional telephone network service 185 provider could contain a TN Authorization List or not, depending on 186 the certification authority issuing the credential. Regardless of 187 which approaches is used, certificates that assert authority over 188 telephone numbers are subject to the ordinary operational procedures 189 that govern certificate use per [RFC5280]. This means that 190 verification services must be mindful of the need to ensure that they 191 trust the root certificate authority that issued the certificate, and 192 that they have some means to determine the freshness of the 193 certificate (see Section 8). 195 4. Enrollment and Authorization using the TN Authorization List 197 This document assumes a threefold model for certificate enrollment 198 when using the TN Authorization List extension. 200 The first enrollment model is one where the certification authority 201 acts in concert with national numbering authorities to issue 202 credentials to those parties to whom numbers are assigned. In the 203 United States, for example, telephone number blocks are assigned to 204 Local Exchange Carriers (LECs) by the North American Numbering Plan 205 Administrator (NANPA), who is in turn directed by the national 206 regulator. LECs may also receive numbers in smaller allocations, 207 through number pooling, or via an individual assignment through 208 number portability. LECs assign numbers to customers, who may be 209 private individuals or organizations - and organizations take 210 responsibility for assigning numbers within their own enterprise. 211 This model requires top-down adoption of the model from regulators 212 through to carriers. 214 The second enrollment model is a bottom-up approach where a 215 certification authority requires that an entity prove control by 216 means of some sort of test, which, as with certification authorities 217 for web PKI, might either be automated or a manual administrative 218 process. As an example of an automated process, an authority might 219 send a text message to a telephone number containing a URL (which 220 might be dereferenced by the recipient) as a means of verifying that 221 a user has control of terminal corresponding to that number. Checks 222 of this form are frequently used in commercial systems today to 223 validate telephone numbers provided by users. This is comparable to 224 existing enrollment systems used by some certificate authorities for 225 issuing S/MIME credentials for email by verifying that the party 226 applying for a credential receives mail at the email address in 227 question. 229 The third enrollment model is delegation: that is, the holder of a 230 certificate (assigned by either of the two methods above) might 231 delegate some or all of their authority to another party. In some 232 cases, multiple levels of delegation could occur: a LEC, for example, 233 might delegate authority to a customer organization for a block of 234 100 numbers used by an IP PBX, and the organization might in turn 235 delegate authority for a particular number to an individual employee. 236 This is analogous to delegation of organizational identities in 237 traditional hierarchical Public Key Infrastructures (PKIs) who use 238 the name constraints extension [RFC5280]; the root CA delegates names 239 in sales to the sales department CA, names in development to the 240 development CA, etc. As lengthy certificate delegation chains are 241 brittle, however, and can cause delays in the verification process, 242 this document considers optimizations to reduce the complexity of 243 verification. 245 [TBD] Future versions of this specification may address adding a 246 level of assurance indication to certificates to differentiate those 247 enrolled from proof-of-possession versus delegation. 249 [TBD] Future versions of this specification may also discuss methods 250 of partial delegation, where certificate holders delegate only part 251 of their authority. For example, individual assignees may want to 252 delegate to a service authority for text messages associated with 253 their telephone number, but not for other functions. 255 4.1. Certificate Extension Scope and Structure 257 This specification places no limits on the number of telephone 258 numbers that can be associated with any given certificate. Some 259 service providers may be assigned millions of numbers, and may wish 260 to have a single certificate that is capable of signing for any one 261 of those numbers. Others may wish to compartmentalize authority over 262 subsets of the numbers they control. 264 Moreover, service providers may wish to have multiple certificates 265 with the same scope of authority. For example, a service provider 266 with several regional gateway systems may want each system to be 267 capable of signing for each of their numbers, but not want to have 268 each system share the same private key. 270 The set of telephone numbers for which a particular certificate is 271 valid is expressed in the certificate through a certificate 272 extension; the certificate's extensibility mechanism is defined in 273 [RFC5280] but the TN Authorization List extension is specified in 274 this document. 276 The subjects of certificates containing the TN Authorization List 277 extension are typically the administrative entities to whom numbers 278 are assigned or delegated. For example, a LEC might hold a 279 certificate for a range of telephone numbers. In some cases, the 280 organization or individual issued such a certificate may not want to 281 associate themselves with a certificate; for example, a private 282 individual with a certificate for a single telephone number might not 283 want to distribute that certificate publicly if every verifier 284 immediately knew their name. The certification authorities issuing 285 certificates with the TN Authorization List extensions may, in 286 accordance with their policies, obscure the identity of the subject, 287 though mechanisms for doing so are outside the scope of this 288 document. 290 5. Provisioning Private Keying Material 292 In order for authentication services to sign calls via the procedures 293 described in [I-D.ietf-stir-rfc4474bis], they must hold a private key 294 corresponding to a certificate with authority over the calling 295 number. This specification does not require that any particular 296 entity in a SIP deployment architecture sign requests, only that it 297 be an entity with an appropriate private key; the authentication 298 service role may be instantiated by any entity in a SIP network. For 299 a certificate granting authority only over a particular number which 300 has been issued to an end user, for example, an end user device might 301 hold the private key and generate the signature. In the case of a 302 service provider with authority over large blocks of numbers, an 303 intermediary might hold the private key and sign calls. 305 The specification recommends distribution of private keys through 306 PKCS#8 objects signed by a trusted entity, for example through the 307 CMS package specified in [RFC5958]. 309 6. Acquiring Credentials to Verify Signatures 311 This specification documents multiple ways that a verifier can gain 312 access to the credentials needed to verify a request. As the 313 validity of certificates does not depend on the method of their 314 acquisition, there is no need to standardize any single mechanism for 315 this purpose. All entities that comply with 316 [I-D.ietf-stir-rfc4474bis] necessarily support SIP, and consequently 317 SIP itself can serve as a way to acquire certificates. 318 [I-D.ietf-stir-rfc4474bis] provides an "info" parameter of the 319 Identity header which contains a URI where the credential used to 320 generate the Identity header, and requires documents which define 321 credential systems to list the URI schemes that may be present in the 322 "info" parameter. For implementations compliant with this 323 specification, three URI schemes are REQUIRED: the CID URI, the SIP 324 URI, and the HTTP URI. 326 The simplest way for a verifier to acquire the certificate needed to 327 verify a signature is for the certificate be conveyed in a SIP 328 request along with the signature itself. In SIP, for example, a 329 certificate could be carried in a multipart MIME body [RFC2046], and 330 the URI in the Identity header "info" parameter could specify that 331 body with a CID URI [RFC2392]. However, in many environments this is 332 not feasible due to message size restrictions or lack of necessary 333 support for multipart MIME. 335 More commonly, the Identity header "info" parameter in a SIP request 336 may contain a URI that the verifier dereferences with a network call. 337 Implementations of this specification are required to support the use 338 of SIP for this function (via the SUBSCRIBE/NOTIFY mechanism), as 339 well as HTTP, via the Enrollment over Secure Transport mechanisms 340 described in RFC 7030 [RFC7030]. 342 Note well that as an optimization, a verifier may have access to a 343 service, a cache or other local store that grants access to 344 certificates for a particular telephone number. However, there may 345 be multiple valid certificates that can sign a call setup request for 346 a telephone number, and as a consequence, there needs to be some 347 discriminator that the signer uses to identify their credentials. 348 The Identity header "info" parameter itself can serve as such a 349 discriminator, provided implementations use that parameter as a key 350 when accessing certificates from caches or other sources. Verifiers 351 still 353 7. Verifying Certificate Scope with TN Authorization List 355 The subjects of certificates containing the TN Authorization List 356 extension are the administrative entities to whom numbers are 357 assigned or delegated. When a verifier is validating a caller's 358 identity, local policy always determines the circumstances under 359 which any particular subject may be trusted, but the purpose of the 360 TN Authorization List extension particular is to allow a verifier to 361 ascertain when the certification authority has designed that the 362 subject has authority over a particular telephone number or number 363 range. 365 The Telephony Number (TN) Authorization List certificate extension is 366 identified by the following object identifier: 368 id-ce-TNAuthList OBJECT IDENTIFIER ::= { TBD } 370 The TN Authorization List certificate extension has the following 371 syntax: 373 TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization 375 TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry 377 TNEntry ::= CHOICE { 379 spid ServiceProviderIdentifierList, 381 range TelephoneNumberRange, 383 one E164Number } 385 ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF 387 OCTET STRING 389 -- When all three are present: SPID, Alt SPID, and Last Alt SPID 391 TelephoneNumberRange ::= SEQUENCE { 393 start E164Number, 395 count INTEGER } 397 E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789")) 399 [TBD- do we really need to do IA5String? The alternative would be 400 UTF8String, e.g.: UTF8String (SIZE (1..15)) (FROM ("0123456789")) ] 402 The TN Authorization List certificate extension indicates the 403 authorized phone numbers for the call setup signer. It indicates one 404 or more blocks of telephone number entries that have been authorized 405 for use by the call setup signer. There are three ways to identify 406 the block: 1) a Service Provider Identifier (SPID) can be used to 407 indirectly name all of the telephone numbers associated with that 408 service provider, 2) telephone numbers can be listed in a range, and 409 3) a single telephone number can be listed. 411 Note that because large-scale service providers may want to associate 412 many numbers, possibly millions of numbers, with a particular 413 certificate, optimizations are required for those cases to prevent 414 certificate size from becoming unmanageable. In these cases, the TN 415 Authorization List may be given by reference rather than by value, 416 through the presence of a separate certificate extension that permits 417 verifiers to either securely download the list of numbers associated 418 with a certificate, or to verify that a single number is under the 419 authority of this certificate. This optimization will be detailed in 420 future version of this specification. 422 8. Certificate Freshness and Revocation 424 Regardless of which of the approaches in Section 3 is followed for 425 using certificates, some sort of certificate verification mechanism 426 is required. However, the traditional problem of certificate 427 freshness gains a new wrinkle when using the TN Authorization List 428 extension, because verifiers must establish not only that a 429 certificate remains valid, but also that the certificate's scope 430 contains the telephone number that the verifier is validating. 431 Dynamic changes to number assignments can occur due to number 432 portability, for example. So even if a verifier has a valid cached 433 certificate for a telephone number (or a range containing the 434 number), the verifier must determine that the entity that signed is 435 still a proper authority for that number. 437 To verify the status of the certificate, the verifier needs to 438 acquire the certificate if necessary (via the methods described in 439 Section 6), and then would need to either: 441 Rely on short-lived certificates and not check the certificate's 442 status, or 444 Rely on status information from the authority 446 The tradeoff between short lived certificates and using status 447 information is the former's burden is on the front end (i.e., 448 enrollment) and the latter's burden is on the back end (i.e., 449 verification). Both impact call setup time, but it is assumed that 450 performing enrollment for each call is more of an impact that using 451 status information. This document therefore recommends relying on 452 status information. 454 8.1. Choosing a Verification Method 456 There are three common certificate verification mechanisms employed 457 by CAs: 459 Certificate Revocation Lists (CRLs) [RFC5280] 461 Online Certificate Status Protocol (OCSP) [RFC6960], and 462 Server-based Certificate Validation Protocol (SCVP) [RFC5055]. 464 When relying on status information, the verifier needs to obtain the 465 status information - but before that can happen, the verifier needs 466 to know where to locate it. Placing the location of the status 467 information in the certificate makes the certificate larger, but it 468 eases the client workload. The CRL Distribution Point certificate 469 extension includes the location of the CRL and the Authority 470 Information Access certificate extension includes the location of 471 OCSP and/or SCVP servers; both of these extensions are defined in 472 [RFC5280]. In all cases, the status information location is provided 473 in the form of an URI. 475 CRLs are an obviously attractive solution because they are supported 476 by every CA. CRLs have a reputation of being quite large (10s of 477 MBytes), because CAs maintain and issue one monolithic CRL with all 478 of their revoked certificates, but CRLs do support a variety of 479 mechanisms to scope the size of the CRLs based on revocation reasons 480 (e.g., key compromise vs CA compromise), user certificates only, and 481 CA certificates only as well as just operationally deciding to keep 482 the CRLs small. However, scoping the CRL introduces other issues 483 (i.e., does the RP have all of the CRL partitions). 485 CAs in the STIR architecture will likely all create CRLs for audit 486 purposes, but it NOT RECOMMENDED that they be relying upon for status 487 information. Instead, one of the two "online" options is preferred. 488 Between the two, OCSP is much more widely deployed and this document 489 therefore recommends the use of OCSP in high-volume environments for 490 validating the freshness of certificates, based on [RFC6960], 491 incorporating some (but not all) of the optimizations of [RFC5019]. 493 8.2. Using OCSP with TN Auth List 495 Certificates compliant with this specification therefore SHOULD 496 include a URL pointing to an OCSP service in the Authority 497 Information Access (AIA) certificate extension, via the "id-ad-ocsp" 498 accessMethod specified in [RFC5280]. Baseline OCSP however supports 499 only three possible response values: good, revoked, or unknown. With 500 some extension, OCSP would not indicate whether the certificate is 501 authorized for a particular telephone number that the verifier is 502 validating. 504 [TBD] What would happen in the unknown case? Can we profile OCSP 505 usage so that unknown is never returned for our extension? 507 At a high level, there are two ways that a client might pose this 508 authorization question: 510 For this certificate, is the following number currently in its 511 scope of validity? 513 What are all the telephone numbers associated with this 514 certificate, or this certificate subject? 516 Only the former lends itself to piggybacking on the OCSP status 517 mechanism; since the verifier is already asking an authority about 518 the certificate's status, why not reuse that mechanism, instead of 519 creating a new service that requires additional round trips? Like 520 most PKIX-developed protocols, OCSP is extensible; OCSP supports 521 request extensions (including sending multiple requests at once) and 522 per-request extensions. It seems unlikely that the verifier will be 523 requesting authorization checks on multiple telephone numbers in one 524 request, so a per-request extension is what is needed. 526 [TBD] HVE OCSP requires SHA-1 be used as the hash algorithm, 527 we're6960 obviously going to change this to be SHA-256. 529 The requirement to consult OCSP in real time results in a network 530 round-trip time of day, which is something to consider because it 531 will add to the call setup time. OCSP server implementations 532 commonly pre-generate responses, and to speed up HTTPS connections, 533 servers often provide OCSP responses for each certificate in their 534 hierarchy. If possible, both of these OCSP concepts should be 535 adopted for use with STIR. 537 8.2.1. OCSP Extension Specification 539 The extension mechanism for OCSP follows X.509 v3 certificate 540 extensions, and thus requires an OID, a criticality flag, and ASN.1 541 syntax as defined by the OID. The criticality specified here is 542 optional: per [RFC6960] Section 4.4, support for all OCSP extensions 543 is optional. If the OCSP server does not understand the requested 544 extension, it will still provide the baseline validation of the 545 certificate itself. Moreover, in practical STIR deployments, the 546 issuer of the certificate will set the accessLocation for the OCSP 547 AIA extension to point to an OCSP service that supports this 548 extension, so the risk of interoperability failure due to lack of 549 support for this extension is minimal. 551 The OCSP TNQuery extension is included as one of the 552 requestExtensions in requests. It may also appear in the 553 responseExtensions. When an OCSP server includes a number in the 554 responseExtensions, this informs the client that the certificate is 555 still valid for the number that appears in the TNQuery extension 556 field. If the TNQuery is absent from a response to a query 557 containing a TNQuery in its requestExtensions, then the server is not 558 able to validate that the number is still in the scope of authority 559 of the certificate. 561 id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD } 563 TNQuery ::= E164Number 565 Note that HVE OCSP profile [RFC5019] prohibits the use of per-request 566 extensions. As it is anticipated that STIR will use OCSP in a high- 567 volume environment, many of the optimizations recommended by HVE are 568 desirable for the STIR environment. This document therefore uses 569 these extensions in a baseline OCSP environment with some HVE 570 optimizations. [More TBD] 572 Ideally, once a certificate has been acquired by a verifier, some 573 sort of asynchronous mechanism could notify and update the verifier 574 if the scope of the certificate changes so that verifiers could 575 implement a cache. While not all possible categories of verifiers 576 could implement such behavior, some sort of event-driven notification 577 of certificate status is another potential subject of future work. 578 One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based 579 accessMethod for AIA might be defined (which would also be applicable 580 to the method described in the following section) by some future 581 specification. 583 Strategies for stapling OCSP [RFC6961] have become common in some web 584 PKI environments as an optimization which allows web servers to send 585 up-to-date certificate status information acquired from OCSP to 586 clients as TLS is negotiated. A similar mechanism could be 587 implemented for SIP requests, in which the authentication service 588 adds status information for its certificate to the SIP request, which 589 would save the verifier the trouble of performing the OCSP dip 590 itself. Especially for high-volume authentication and verification 591 services, this could result in significant performance improvements. 592 This is left as an optimization for future work. 594 8.3. Acquiring TN Lists By Reference 596 Acquiring a list of the telephone numbers associated with a 597 certificate or its subject lends itself to an application-layer 598 query/response interaction outside of OCSP, one which could be 599 initiated through a separate URI included in the certificate. The 600 AIA extension (see [RFC5280]) supports such a mechanism: it 601 designates an OID to identify the accessMethod and an accessLocation, 602 which would most likely be a URI. A verifier would then follow the 603 URI to ascertain whether the list of TNs authorized for use by the 604 caller. 606 HTTPS is the most obvious candidate for a protocol to be used for 607 fetching the list of telephone number associated with a particular 608 certificate. This document defines a new AIA accessMethod, called 609 "id-ad-stir-tn", which uses the following AIA OID: 611 id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD } 613 When the "id-ad-stir-tn" accessMethod is used, the accessLocation 614 MUST be an HTTPS URI. The document returned by dereferencing that 615 URI will contain the complete TN Authorization List (see Section 7) 616 for the certificate. 618 Delivering the entire list of telephone numbers associated with a 619 particular certificate will divulge to STIR verifiers information 620 about telephone numbers other than the one associated with the 621 particular call that the verifier is checking. In some environments, 622 where STIR verifiers handle a high volume of calls, maintaining an 623 up-to-date and complete cache for the numbers associated with crucial 624 certificate holders could give an important boost to performance. 626 9. Acknowledgments 628 Russ Housley, Brian Rosen, Cullen Jennings and Eric Rescorla provided 629 key input to the discussions leading to this document. 631 10. IANA Considerations 633 This document makes use of object identifiers for the TN Certificate 634 Extension defined in Section 7, TN-HVE OCSP extension in 635 Section 8.2.1, and the TN by reference AIA access descriptor defined 636 in Section 8.3. It therefore requests that the IANA make the 637 following assignments: 639 - TN Certificate Extension in the SMI Security for PKIX 640 Certificate Extension registry: http://www.iana.org/assignments/ 641 smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 643 - TN-HVE OCSP extension in the SMI Security for PKIX Online 644 Certificate Status Protocol (OCSP) registry: 645 http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 646 numbers-1.3.6.1.5.5.7.48.1 647 - TNS by reference access descriptor in the SMI Security for PKIX 648 Access Descriptor registry: http://www.iana.org/assignments/smi- 649 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48 651 11. Security Considerations 653 This document is entirely about security. For further information on 654 certificate security and practices, see RFC 3280 [RFC3280], in 655 particular its Security Considerations. 657 12. Informative References 659 [I-D.ietf-stir-problem-statement] 660 Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 661 Telephone Identity Problem Statement and Requirements", 662 draft-ietf-stir-problem-statement-05 (work in progress), 663 May 2014. 665 [I-D.ietf-stir-rfc4474bis] 666 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 667 "Authenticated Identity Management in the Session 668 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-07 669 (work in progress), February 2016. 671 [I-D.peterson-sipping-retarget] 672 Peterson, J., "Retargeting and Security in SIP: A 673 Framework and Requirements", draft-peterson-sipping- 674 retarget-00 (work in progress), February 2005. 676 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 677 Extensions (MIME) Part Two: Media Types", RFC 2046, 678 DOI 10.17487/RFC2046, November 1996, 679 . 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, 683 DOI 10.17487/RFC2119, March 1997, 684 . 686 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 687 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 688 . 690 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 691 DOI 10.17487/RFC2818, May 2000, 692 . 694 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 695 A., Peterson, J., Sparks, R., Handley, M., and E. 696 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 697 DOI 10.17487/RFC3261, June 2002, 698 . 700 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 701 Protocol (SIP): Locating SIP Servers", RFC 3263, 702 DOI 10.17487/RFC3263, June 2002, 703 . 705 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 706 X.509 Public Key Infrastructure Certificate and 707 Certificate Revocation List (CRL) Profile", RFC 3280, 708 DOI 10.17487/RFC3280, April 2002, 709 . 711 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 712 Certificate Status Protocol (OCSP) Profile for High-Volume 713 Environments", RFC 5019, DOI 10.17487/RFC5019, September 714 2007, . 716 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 717 Polk, "Server-Based Certificate Validation Protocol 718 (SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007, 719 . 721 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 722 Housley, R., and W. Polk, "Internet X.509 Public Key 723 Infrastructure Certificate and Certificate Revocation List 724 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 725 . 727 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 728 DOI 10.17487/RFC5958, August 2010, 729 . 731 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 732 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 733 DOI 10.17487/RFC6919, April 2013, 734 . 736 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 737 Galperin, S., and C. Adams, "X.509 Internet Public Key 738 Infrastructure Online Certificate Status Protocol - OCSP", 739 RFC 6960, DOI 10.17487/RFC6960, June 2013, 740 . 742 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 743 Multiple Certificate Status Request Extension", RFC 6961, 744 DOI 10.17487/RFC6961, June 2013, 745 . 747 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 748 "Enrollment over Secure Transport", RFC 7030, 749 DOI 10.17487/RFC7030, October 2013, 750 . 752 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 753 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 754 . 756 [X.680] USC/Information Sciences Institute, "Information 757 Technology - Abstract Syntax Notation One.", ITU-T X.680, 758 ISO/IEC 8824-1:2002, 2002. 760 [X.681] USC/Information Sciences Institute, "Information 761 Technology - Abstract Syntax Notation One: Information 762 Object Specification", ITU-T X.681, ISO/IEC 8824-2:2002, 763 2002. 765 [X.682] USC/Information Sciences Institute, "Information 766 Technology - Abstract Syntax Notation One: Constraint 767 Specification", ITU-T X.682, ISO/IEC 8824-3:2002, 2002. 769 [X.683] USC/Information Sciences Institute, "Information 770 Technology - Abstract Syntax Notation One: 771 Parameterization of ASN.1 Specifications", ITU-T X.683, 772 ISO/IEC 8824-4:2002, 2002. 774 Appendix A. ASN.1 Module 776 This appendix provides the normative ASN.1 [X.680] definitions for 777 the structures described in this specification using ASN.1, as 778 defined in [X.680] through [X.683]. 780 TBD 782 Authors' Addresses 784 Jon Peterson 785 Neustar, Inc. 787 Email: jon.peterson@neustar.biz 788 Sean Turner 789 Sn3rd 791 Email: sean@sn3rd.com