idnits 2.17.1 draft-peterson-stir-cert-delegation-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1866 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) == Unused Reference: 'RFC7044' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'RFC7519' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'ATIS-0300251' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC5806' is defined on line 337, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-acme-authority-token-01 == Outdated reference: A later version (-13) exists of draft-ietf-acme-authority-token-tnauthlist-01 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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 March 11, 2019 5 Expires: September 12, 2019 7 STIR Certificate Delegation 8 draft-peterson-stir-cert-delegation-00.txt 10 Abstract 12 The Secure Telephone Identity Revisited (STIR) certificate profile 13 provides a way to attest authority over telephone nunbers and related 14 identifiers for the purpose of preventing telephone number spoofing. 15 This specification details how that authority can be delegated from a 16 parent certificate to a subordinate certificate, in cases where 17 service providers grant credentials to enterprises or other customers 18 capable of signing calls with STIR. 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 https://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 12, 2019. 37 Copyright Notice 39 Copyright (c) 2019 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 (https://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. Delegation of STIR Certificates . . . . . . . . . . . . . . . 3 57 3.1. Authentication Services Signing with Delegate 58 Certificates . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Verification Service Behavior for Delegate Certificate 60 Signatures . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Acquiring Certificate Chains in STIR . . . . . . . . . . . . 5 62 5. ACME and Delegation . . . . . . . . . . . . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 10.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The STIR problem statement [RFC7340] reviews the difficulties facing 75 the telephone network that are enabled by impersonation, including 76 various forms of robocalling, voicemail hacking, and swatting. One 77 of the most important components of a system to prevent impersonation 78 is the implementation of credentials which identify the parties who 79 control telephone numbers. The STIR certificates [RFC8226] 80 specification describes a credential system based on [X.509] version 81 3 certificates in accordance with [RFC5280] for that purpose. Those 82 credentials can then be used by STIR authentication services 83 [RFC8224] to sign PASSporT objects [RFC8225] carried in SIP [RFC3261] 84 requests. 86 [RFC8226] specifies an extension to X.509 that defines a Telephony 87 Number (TN) Authorization List that may be included by certificate 88 authorities in certificates. This extension provides additional 89 information that relying parties can use when validating transactions 90 with the certificate. When a SIP request, for example, arrives at a 91 terminating administrative domain, the calling number attested by the 92 SIP request can be compared to the TN Authorization List of the 93 certificate that signed the PASSporT to determine if the caller is 94 authorized to use that calling number. 96 Initial deployment of [RFC8226] has focused on the use of Service 97 Provider Codes (SPCs) to attest the scope of authority of a 98 certificate. Typically, these codes are internal telephone network 99 identifiers such as the Operating Company Numbers (OCNs) assigned to 100 carriers in the United States. Allocations at finer levels of 101 granularity, to blocks of telephone numbers or even to individual 102 numbers, are also desirable for enterprise use cases. [RFC8226] gave 103 an overview of a certificate enrollment model based on "delegation," 104 whereby the holder of certificate might allocate a subset of that 105 certificates authority to another party. This specification details 106 how delegation of authority works for STIR certificates. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in RFC 113 2119 [RFC2119]. 115 3. Delegation of STIR Certificates 117 STIR delegate certificates are certificates containing a TNAuthList 118 object that have been signed with the private key of a parent 119 certificate that itself contains a TNAuthList object. The parent 120 certificate needs to have its CA boolean set to "true", indicating 121 that that it can sign certificates. Every STIR delegate certificate 122 identifies its parent certificate with a standard [RFC5280] Authority 123 Key Identifier. 125 The authority bestowed on the holder of the delegate certificate by 126 the parent certificate is recorded in the delegate certificate's 127 TNAuthList. Because STIR certificates use the TNAuthList object 128 rather than the Subject Name for indicating the scope of their 129 authority, traditional [RFC5280] name constraints are not directly 130 applicable to STIR. In a manner similar to the RPKI [RFC6480] 131 "encompassing" semantics, each delegate certificate must have a 132 TNAuthList scope that is equal to or a subset of its parent 133 certificate's scope: it must be "encompassed." For example, a parent 134 certificate with a TNAuthList that attested authority for the 135 numbering range +1-212-555-1000 through 1999 could issue a 136 certificate to one delegate attesting authority for the range 137 +1-212-555-1500 through 1599, and to another delegate a certificate 138 for the individual number +1-212-555-1824. 140 Delegate certificates may themselves be issued with the CA boolean 141 set to "true" so that they can serve as parent certificates to 142 further delegates; effectively, this delegate certificate is a cross- 143 certificate, as its issuer is not the same as its subject. In the 144 STIR ecosystem, certification authority certificates may be used to 145 sign PASSporTs; this removes the need for creating a redundant end- 146 entity certificate with an identical TNAuthList to its parent, though 147 if for operational or security reasons certificate holders wish to do 148 so, they may. 150 Parent certificates may have a TNAuthList containing one or more 151 SPCs, one or more telephone number ranges, or both. Delegations from 152 a parent certificate that contains only SPCs to a delegate 153 certificate containing a telephone number or number range are 154 permitted. Ascertaining whether or not a given telephone number 155 belongs to the service provider identified by an SPC requires access 156 to industry numbering databases that are outside the scope of this 157 specification; entities that are constructing a certificate path who 158 have access to those resources can validate those delegations. 160 3.1. Authentication Services Signing with Delegate Certificates 162 Authentication service behavior for delegate certificates is little 163 changed from baseline STIR behavior. The same checks are performed 164 by the authentication service, comparing the calling party number 165 attested in call signaling with the scope of the authority of the 166 signing certificate. Authentication services SHOULD NOT use a 167 delegate certificate without validating that its scope of authority 168 is encompassed by that of its parent certificate, and if that 169 certificate in turn has its own parent, the entire certificate path 170 should be validated. 172 Note that authentication services creating a PASSporT for a call 173 signed with a delegate certificate MUST provide an "x5u" link 174 corresponding to the entire certificate chain, rather than just the 175 delegate certificate used to sign the call, as described in 176 Section 4. 178 3.2. Verification Service Behavior for Delegate Certificate Signatures 180 The responsibility of a verification service validating PASSporTs 181 signed with delegate certificates, while largely following baseline 182 [RFC8224] and [RFC8225], requires some additional procedures. When 183 the verification service dereferences the "x5u" parameter, it will 184 acquire a certificate list rather than a single certificate. It MUST 185 then validate all of the credentials in the list, identifying the 186 parent certificate for each delegate through its AKID object. 188 While ordinarily, relying parties have significant latitude in path 189 construction when validating a certificate chain, STIR assumes a more 190 rigid hierarchical subordination model, rather than one where relying 191 parties may want to derive their own chains to particular trust 192 anchors. If the certificate chain acquired from the "x5u" element of 193 a PASSporT does not lead to an anchor that the verification service 194 trusts, it treats the validation no differently than it would when a 195 non-delegated certificate was issued by an untrust root; in SIP, it 196 MAY return a 437 "Unsupported Credential" response if the call should 197 be failed for lack of a valid Identity header. 199 4. Acquiring Certificate Chains in STIR 201 PASSporT [RFC8225] uses the "x5u" element to convey the URL where 202 verification services can acquire the certificate used to sign a 203 PASSporT. This value is mirrored by the "info" parameter of the 204 Identity header when a PASSporT is conveyed via SIP. Commonly, this 205 is an HTTPS URI. 207 When a STIR delegate certificate is used to sign a PASSporT, the 208 "x5u" element in the PASSporT will contain a URI indicating where a 209 certificate list is available. That list will be a concatenation of 210 PEM encoded certificates of the type "application/pem-certificate- 211 chain" defined in [I-D.ietf-acme-acme]. The list begins with the 212 certificate used to sign the PASSporT, followed by its parent, and 213 then any subsequent grandparents, great-grandparents, and so on. The 214 ordering MUST conform to the AKID/SKID order chain encoded in the 215 certs themselves. Note that ACME requires the first element in a 216 pem-certificate-chain to be an end-entity certificate; STIR relaxes 217 this requirement, as CA certificates are permitted to sign PASSporTs, 218 so the first element in a pem-certificate-chain used for STIR MAY be 219 a CA certificate. 221 5. ACME and Delegation 223 STIR deployments commonly use ACME [I-D.ietf-acme-acme] for 224 certificate acquisition, and it is anticipated that delegate 225 certificates as well will be acquired through an ACME interface. An 226 entity that wishes to acquire a certificate from a particular CA will 227 request an Authority Token [I-D.ietf-acme-authority-token] from the 228 parent with the desired TNAuthList 229 [I-D.ietf-acme-authority-token-tnauthlist] object. Note that if the 230 client wishes to do further subdelegation of its own, it should 231 request a token with the "ca" Authority Token flag set. 233 The entity then presents that Authority Token to a certificate 234 authority to acquire a STIR delegate certificate. ACME returns an 235 "application/pem-certificate-chain" object with suitable for 236 publishing as an HTTPS resource for retrieval with the PASSporT "x5u" 237 mechanism as discussed in Section 4. If the CSR presented to the 238 ACME server is for a certificate with the CA boolean set to "true", 239 then the ACME server makes a policy decision to determine whether or 240 not it is appropriate to issue that certificate to the requesting 241 entity. In most ACME cases, that policy decision will be made based 242 on the "ca" flag in the Authority Token. 244 6. IANA Considerations 246 This document contains no actions for the IANA. 248 7. Privacy Considerations 250 [TBD.] 252 8. Security Considerations 254 This document is entirely about security. For further information on 255 certificate security and practices, see [RFC5280], in particular its 256 Security Considerations. 258 9. Acknowledgments 260 We would like to thank Richard Barnes, Chris Wendt, Dave Hancock, 261 Russ Housley, and Sean Turner for key input to the discussions 262 leading to this document. 264 10. References 266 10.1. Normative References 268 [I-D.ietf-acme-acme] 269 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 270 Kasten, "Automatic Certificate Management Environment 271 (ACME)", draft-ietf-acme-acme-18 (work in progress), 272 December 2018. 274 [I-D.ietf-acme-authority-token] 275 Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME 276 Challenges Using an Authority Token", draft-ietf-acme- 277 authority-token-01 (work in progress), October 2018. 279 [I-D.ietf-acme-authority-token-tnauthlist] 280 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 281 "TNAuthList profile of ACME Authority Token", draft-ietf- 282 acme-authority-token-tnauthlist-01 (work in progress), 283 October 2018. 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 291 A., Peterson, J., Sparks, R., Handley, M., and E. 292 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 293 DOI 10.17487/RFC3261, June 2002, 294 . 296 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 297 C. Holmberg, "An Extension to the Session Initiation 298 Protocol (SIP) for Request History Information", RFC 7044, 299 DOI 10.17487/RFC7044, February 2014, 300 . 302 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 303 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 304 . 306 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 307 "Authenticated Identity Management in the Session 308 Initiation Protocol (SIP)", RFC 8224, 309 DOI 10.17487/RFC8224, February 2018, 310 . 312 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 313 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 314 . 316 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 317 Credentials: Certificates", RFC 8226, 318 DOI 10.17487/RFC8226, February 2018, 319 . 321 10.2. Informative References 323 [ATIS-0300251] 324 ATIS Recommendation 0300251, "Codes for Identification of 325 Service Providers for Information Exchange", 2007. 327 [DSS] National Institute of Standards and Technology, U.S. 328 Department of Commerce | NIST FIPS PUB 186-4, "Digital 329 Signature Standard, version 4", 2013. 331 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 332 Housley, R., and W. Polk, "Internet X.509 Public Key 333 Infrastructure Certificate and Certificate Revocation List 334 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 335 . 337 [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in 338 SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, 339 . 341 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 342 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 343 February 2012, . 345 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 346 Telephone Identity Problem Statement and Requirements", 347 RFC 7340, DOI 10.17487/RFC7340, September 2014, 348 . 350 [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, 351 "Information technology - Open Systems Interconnection - 352 The Directory: Public-key and attribute certificate 353 frameworks", 2012. 355 [X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6, 356 "Information technology - Open Systems Interconnection - 357 The Directory: Selected Attribute Types", 2012. 359 [X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, 360 "Information Technology - Abstract Syntax Notation One: 361 Specification of basic notation". 363 [X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, 364 "Information Technology - Abstract Syntax Notation One: 365 Information Object Specification". 367 [X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, 368 "Information Technology - Abstract Syntax Notation One: 369 Constraint Specification". 371 [X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, 372 "Information Technology - Abstract Syntax Notation One: 373 Parameterization of ASN.1 Specifications". 375 Author's Address 377 Jon Peterson 378 Neustar, Inc. 380 Email: jon.peterson@team.neustar