idnits 2.17.00 (12 Aug 2021) /tmp/idnits50068/draft-ietf-stir-certificates-ocsp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 1894 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) == Outdated reference: draft-ietf-stir-certificates has been published as RFC 8226 == Outdated reference: draft-ietf-stir-passport has been published as RFC 8225 == Outdated reference: draft-ietf-stir-rfc4474bis has been published as RFC 8224 ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 7093 -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 14, 2017 sn3rd 6 March 13, 2017 8 OCSP Usage for Secure Telephone Identity Certificates 9 draft-ietf-stir-certificates-ocsp-00.txt 11 Abstract 13 When certificates are used as credentials to attest the assignment or 14 ownership of telephone numbers, some mechanism is required to convey 15 certificate freshness to relying parties. This document specifies 16 the use of the Online Certificate Status Protocol (OCSP) as a means 17 of retrieving real-time status information about such certificates, 18 defining new extensions to compensate for the dynamism of telephone 19 number assignments. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 14, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Certificate Verification Methods . . . . . . . . . . . . . . 3 58 3.1. Using OCSP with TN Auth List . . . . . . . . . . . . . . 4 59 3.1.1. OCSP Extension Specification . . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 8.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 The STIR problem statement [RFC7340] discusses many attacks on the 73 telephone network that are enabled by impersonation, including 74 various forms of robocalling, voicemail hacking, and swatting. One 75 of the most important components of a system to prevent impersonation 76 is the implementation of credentials which identify the parties who 77 control telephone numbers. The STIR certificates 78 [I-D.ietf-stir-certificates] specification describes a credential 79 system based on [X.509] version 3 certificates in accordance with 80 [RFC5280] for that purpose. Those credentials can then be used by 81 STIR authentication services [I-D.ietf-stir-rfc4474bis] to sign 82 PASSporT objects [I-D.ietf-stir-passport] carried in a SIP [RFC3261] 83 request. 85 The STIR certificates document specifies an extension to X.509 that 86 defines a Telephony Number (TN) Authorization List that may be 87 included by certificate authorities in certificates. This extension 88 provides additional information that relying parties can use when 89 validating transactions with the certificate. When a SIP request, 90 for example, arrives at a terminating administrative domain, the 91 calling number attested by the SIP request can be compared to the TN 92 Authorization List of the certificate that signed the request to 93 determine if the caller is authorized to use that calling number in 94 SIP. 96 However, there is significant dynamism in telephone number 97 assignment, and due to practices like number portability, information 98 about number assignment can suddenly become stale. This problem is 99 especially pronounced when a TN Authorization List extension 100 associates a large block of telephone numbers with a certificate, as 101 relying parties need a way to learn if any one of those telephone 102 numbers has been ported to a different administrative entity. 104 No specific recommendation is made in the STIR certificates document 105 for a means of determining the freshness of certificates with a TN 106 Authorization List. This document explores approaches to real-time 107 status information for such certificates, and recommends an approach. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in RFC 114 2119 [RFC2119]. 116 3. Certificate Verification Methods 118 For traditional certificate status information, there are three 119 common certificate verification mechanisms employed by CAs: 121 1. Certificate Revocation Lists (CRLs) [RFC5280] (and [RFC6818]) 123 2. Online Certificate Status Protocol (OCSP) [RFC6960], and 125 3. Server-based Certificate Validation Protocol (SCVP) [RFC5055]. 127 When relying on status information, the verifier needs to obtain the 128 status information - but before that can happen, the verifier needs 129 to know where to locate it. Placing the location of the status 130 information in the certificate makes the certificate larger, but it 131 eases the client workload. The CRL Distribution Point certificate 132 extension includes the location of the CRL and the Authority 133 Information Access certificate extension includes the location of 134 OCSP and/or SCVP servers; both of these extensions are defined in 135 [RFC5280]. In all cases, the status information location is provided 136 in the form of an URI. 138 CRLs are an attractive solution because they are supported by every 139 CA. CRLs have a reputation of being quite large (10s of MBytes), 140 because CAs maintain and issue one monolithic CRL with all of their 141 revoked certificates, but CRLs do support a variety of mechanisms to 142 scope the size of the CRLs based on revocation reasons (e.g., key 143 compromise vs CA compromise), user certificates only, and CA 144 certificates only as well as just operationally deciding to keep the 145 CRLs small. However, scoping the CRL introduces other issues (i.e., 146 does the RP have all of the CRL partitions). 148 CAs in the STIR architecture will likely all create CRLs for audit 149 purposes, but probably not for real-time status information. Any 150 such CRLs used MUST be signed with the same algorithm as the 151 certificate. We thus anticipate that one of the two "online" options 152 is preferred. Between the two, OCSP is much more widely deployed and 153 this document therefore RECOMMENDS the use of OCSP in high-volume 154 environments (HVE) for validating the freshness of certificates, 155 based on [RFC6960], incorporating some (but not all) of the 156 optimizations of [RFC5019]. 158 3.1. Using OCSP with TN Auth List 160 Certificates compliant with this specification SHOULD include a URL 161 [RFC3986] pointing to an OCSP service in the Authority Information 162 Access (AIA) certificate extension, via the "id-ad-ocsp" accessMethod 163 specified in [RFC5280]. It is RECOMMENDED that entities that issue 164 certificates with the Telephone Number Authorization List certificate 165 extension run an OCSP server for this purpose. Baseline OCSP however 166 supports only three possible response values: good, revoked, or 167 unknown. Without some extension, OCSP would not indicate whether the 168 certificate is authorized for a particular telephone number that the 169 verifier is validating. 171 At a high level, there are two ways that a client might pose this 172 authorization question: 174 For this certificate, is the following number currently in its 175 scope of validity? 177 What are all the telephone numbers associated with this 178 certificate, or this certificate subject? 180 Only the former lends itself to piggybacking on the OCSP status 181 mechanism; since the verifier is already asking an authority about 182 the certificate's status, that mechanism can be reused instead of 183 creating a new service that requires additional round trips? Like 184 most PKIX-developed protocols, OCSP is extensible; OCSP supports 185 request extensions (including sending multiple requests at once) and 186 per-request extensions. It seems unlikely that the verifier will be 187 requesting authorization checks on multiple telephone numbers in one 188 request, so a per-request extension is what is needed. 190 The requirement to consult OCSP in real time results in a network 191 round-trip delay, which is something to consider because it will add 192 to the call setup time. OCSP server implementations commonly pre- 193 generate responses, and to speed up HTTPS connections, servers often 194 provide OCSP responses for each certificate in their hierarchy. If 195 possible, both of these OCSP concepts should be adopted for use with 196 STIR. 198 3.1.1. OCSP Extension Specification 200 The extension mechanism for OCSP follows X.509 v3 certificate 201 extensions, and thus requires an OID, a criticality flag, and ASN.1 202 syntax as defined by the OID. The criticality specified here is 203 optional: per [RFC6960] Section 4.4, support for all OCSP extensions 204 is optional. If the OCSP server does not understand the requested 205 extension, it will still provide the baseline validation of the 206 certificate itself. Moreover, in practical STIR deployments, the 207 issuer of the certificate will set the accessLocation for the OCSP 208 AIA extension to point to an OCSP service that supports this 209 extension, so the risk of interoperability failure due to lack of 210 support for this extension is minimal. 212 The OCSP TNQuery extension is included as one of the request's 213 singleRequestExtensions. It may also appear in the response's 214 singleExtensions. When an OCSP server includes a number in the 215 response's singleExtensions, this informs the client that the 216 certificate is still valid for the number that appears in the TNQuery 217 extension field. If the TNQuery is absent from a response to a query 218 containing a TNQuery in its singleRequestExtension, then the server 219 is not able to validate that the number is still in the scope of 220 authority of the certificate. 222 id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp 10 } 224 TNQuery ::= E164Number 226 The HVE OCSP profile [RFC5019] prohibits the use of per-request 227 extensions. As it is anticipated that STIR will use OCSP in a high- 228 volume environment, many of the optimizations recommended by HVE are 229 desirable for the STIR environment. This document therefore uses the 230 HVE optimizations augmented as follows: 232 o Implementations MUST use SHA-256 as the hashing algorithm for the 233 CertID.issuerNameHash and the CertID.issuerKeyHash values. That 234 is CertID.hashAlgorithm is id-sha256 [RFC4055] and the values are 235 truncated to 160-bits as specified Option 1 in Section 2 of 236 [RFC7093]. 238 o Clients MUST include the OCSP TNQuery extension in requests' 239 singleRequestExtensions. 241 o Servers MUST include the OCSP TNQuery extension in responses' 242 singleExtensions. 244 o Servers SHOULD return responses that would otherwise have been 245 "unknown" as "not good" (i.e., return only "good" and "not good" 246 responses). 248 o Clients MUST treat returned "unknown" responses as "not good". 250 o If the server uses ResponderID, it MUST generate the KeyHash using 251 SHA-256 and truncate the value to 160-bits as specified in Option 252 1 in Section 2 of [RFC7093]. 254 o Implementations MUST support ECDSA using P-256 and SHA-256. Note 255 that [RFC6960] requires RSA with SHA-256 be supported. 257 o This removes the requirement to support SHA-1, RSA with SHA-1, or 258 DSA with SHA-1. 260 OCSP responses MUST be signed using the same algorithm as the 261 certificate being checked. 263 To facilitate matching the authority key identifier values found in 264 CA certificates with the KeyHash used in the OCSP response, 265 certificates compliant with this specification MUST generate 266 authority key identifiers and subject key identifiers using the 267 SHA-256 and truncate the value to 160-bits as specified in Option 1 268 in Section 2 of [RFC7093]. 270 Ideally, once a certificate has been acquired by a verifier, some 271 sort of asynchronous mechanism could notify and update the verifier 272 if the scope of the certificate changes so that verifiers could 273 implement a cache. While not all possible categories of verifiers 274 could implement such behavior, some sort of event-driven notification 275 of certificate status is another potential subject of future work. 276 One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based 277 accessMethod for AIA might be defined (which would also be applicable 278 to the method described in the following section) by some future 279 specification. 281 4. IANA Considerations 283 This document makes use of object identifiers for the TN-HVE OCSP 284 extension in Section 3.1.1 and the ASN.1 module identifier defined in 285 Appendix A. It therefore requests that the IANA make the following 286 assignments: 288 TN-HVE OCSP extension in the SMI Security for PKIX Online Certificate 289 Status Protocol (OCSP) registry: http://www.iana.org/assignments/smi- 290 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48.1 292 5. Privacy Considerations 294 Querying for real-time status information about certificates can 295 allow parties monitoring communications to gather information about 296 relying parties and the originators of communications. 297 Unfortunately, the TNQuery extension adds a new field that could 298 potentailly be monitored by OCSP eavesdroppers: the calling telephone 299 number provides a specific piece of additional data about the 300 originator of communications. Using OCSP over TLS is one potential 301 countermeasure to this threat, as described in [RFC6960] 302 Appendix A.1. 304 Another way to mitigate leaking information about relying parties is 305 to use OCSP stapling. Strategies for stapling OCSP [RFC6961] have 306 become common in some web PKI environments as an optimization which 307 allows web servers to send up-to-date certificate status information 308 acquired from OCSP to clients as TLS is negotiated. A similar 309 mechanism could be implemented for SIP requests, in which the 310 authentication service adds status information for its certificate to 311 the SIP request, which would save the verifier the trouble of 312 performing the OCSP dip itself. Especially for high-volume 313 authentication and verification services, this could furthermore 314 result in significant performance improvements. This would however 315 require work on a generic SIP capability to carry OCSP staples that 316 is outside the scope of this document. 318 6. Security Considerations 320 This document is entirely about security. For further information on 321 certificate security and practices, see [RFC5280], in particular its 322 Security Considerations. For OCSP-related security considerations 323 see [RFC6960] and [RFC5019]. 325 7. Acknowledgments 327 Stephen Farrell provided key input to the discussions leading to this 328 document. Russ Housley provided some direct assistance and text 329 surrounding the ASN.1 module. 331 8. References 332 8.1. Normative References 334 [I-D.ietf-stir-certificates] 335 Peterson, J. and S. Turner, "Secure Telephone Identity 336 Credentials: Certificates", draft-ietf-stir- 337 certificates-11 (work in progress), October 2016. 339 [I-D.ietf-stir-passport] 340 Wendt, C. and J. Peterson, "Personal Assertion Token 341 (PASSporT)", draft-ietf-stir-passport-11 (work in 342 progress), February 2017. 344 [I-D.ietf-stir-rfc4474bis] 345 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 346 "Authenticated Identity Management in the Session 347 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 348 (work in progress), February 2017. 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, 352 DOI 10.17487/RFC2119, March 1997, 353 . 355 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 356 A., Peterson, J., Sparks, R., Handley, M., and E. 357 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 358 DOI 10.17487/RFC3261, June 2002, 359 . 361 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 362 Resource Identifier (URI): Generic Syntax", STD 66, 363 RFC 3986, DOI 10.17487/RFC3986, January 2005, 364 . 366 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 367 Algorithms and Identifiers for RSA Cryptography for use in 368 the Internet X.509 Public Key Infrastructure Certificate 369 and Certificate Revocation List (CRL) Profile", RFC 4055, 370 DOI 10.17487/RFC4055, June 2005, 371 . 373 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 374 Certificate Status Protocol (OCSP) Profile for High-Volume 375 Environments", RFC 5019, DOI 10.17487/RFC5019, September 376 2007, . 378 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 379 Housley, R., and W. Polk, "Internet X.509 Public Key 380 Infrastructure Certificate and Certificate Revocation List 381 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 382 . 384 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 385 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 386 DOI 10.17487/RFC5912, June 2010, 387 . 389 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 390 Infrastructure Certificate and Certificate Revocation List 391 (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 392 2013, . 394 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 395 Galperin, S., and C. Adams, "X.509 Internet Public Key 396 Infrastructure Online Certificate Status Protocol - OCSP", 397 RFC 6960, DOI 10.17487/RFC6960, June 2013, 398 . 400 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 401 for Generating Key Identifiers Values", RFC 7093, 402 DOI 10.17487/RFC7093, December 2013, 403 . 405 [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, 406 "Information technology - Open Systems Interconnection - 407 The Directory: Public-key and attribute certificate 408 frameworks", 2012. 410 [X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, 411 "Information Technology - Abstract Syntax Notation One: 412 Specification of basic notation". 414 [X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, 415 "Information Technology - Abstract Syntax Notation One: 416 Information Object Specification". 418 [X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, 419 "Information Technology - Abstract Syntax Notation One: 420 Constraint Specification". 422 [X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, 423 "Information Technology - Abstract Syntax Notation One: 424 Parameterization of ASN.1 Specifications". 426 8.2. Informative References 428 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 429 Polk, "Server-Based Certificate Validation Protocol 430 (SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007, 431 . 433 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 434 Multiple Certificate Status Request Extension", RFC 6961, 435 DOI 10.17487/RFC6961, June 2013, 436 . 438 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 439 Telephone Identity Problem Statement and Requirements", 440 RFC 7340, DOI 10.17487/RFC7340, September 2014, 441 . 443 Appendix A. ASN.1 Module 445 This appendix provides the normative ASN.1 [X.680] definitions for 446 the structures described in this specification using ASN.1, as 447 defined in [X.680] through [X.683]. 449 The modules defined in this document are compatible with the most 450 current ASN.1 specification published in 2015 (see [X.680], [X.681], 451 [X.682], [X.683]). None of the newly defined tokens in the 2008 452 ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE- 453 OID-IRI, TIME, TIME-OF-DAY)) are currently used in any of the ASN.1 454 specifications referred to here. 456 This ASN.1 module imports ASN.1 from [RFC5912]. 458 [TO DO: this ASN.1 module is a stub and needs to be redone!] 460 TN-Module-2016-2 { 461 iso(1) identified-organization(3) dod(6) internet(1) 462 security(5) mechanisms(5) pkix(7) id-mod(0) 463 id-mod-tn-module(88) } 465 DEFINITIONS EXPLICIT TAGS ::= BEGIN 467 IMPORTS 468 id-ad, id-ad-ocsp, id-pe -- From [RFC5912] 469 FROM PKIX1Explicit-2009 { 470 iso(1) identified-organization(3) dod(6) internet(1) security(5) 471 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } 473 EXTENSION -- From [RFC5912] 474 FROM PKIX-CommonTypes-2009 { 475 iso(1) identified-organization(3) dod(6) internet(1) 476 security(5) mechanisms(5) pkix(7) id-mod(0) 477 id-mod-pkixCommon-02(57) } 479 ; 481 id-pkix-ocsp OBECT IDENTIFIER ::= id-ad-ocsp 483 -- 484 -- Telephone Number Query OCSP Extension 485 -- 487 re-ocsp-tn-query EXTENSION ::= { 488 SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn } 490 TNQuery ::= E164Number 492 id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp 10 } 494 END 496 Authors' Addresses 498 Jon Peterson 499 Neustar, Inc. 501 Email: jon.peterson@neustar.biz 502 Sean Turner 503 sn3rd 505 Email: sean@sn3rd.com