idnits 2.17.1 draft-burger-stir-iana-cert-01.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 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 8, 2020) is 1509 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-D.Agencies' ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STIR E. Burger 3 Internet-Draft Georgetown University 4 Intended status: Standards Track March 8, 2020 5 Expires: September 9, 2020 7 Registry for Country-Specific Secure Telephone Identity (STIR) Trust 8 Anchors 9 draft-burger-stir-iana-cert-01 11 Abstract 13 National policy defines telephone numbering governance. One area of 14 such governance are the policies applied to the Secure Telephone 15 Identity Credentials defined in RFC 8226. Nations have policies for 16 the acceptable trust anchors for these credentials. This document 17 defines an IANA registry that enables a SIP call recipient in one 18 country to validate the signature, as defined in RFC 8224, that 19 originates in another country useing an appropriate trust anchor for 20 the signer's certification path, per the origination country's trust 21 anchor policy. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 9, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 One problem that plagues some communications applications is a caller 58 deliberately misrepresenting their identity with the intent to 59 defraud, cause harm, or wrongfully obtain anything of value. The 60 IETF Secure Telephone Identity Revisited (STIR) work group has 61 developed a series of RFCs specifying the mechanisms for 62 cryptographically signing the asserted identity and other elements in 63 Session Initiation Protocol (SIP) [RFC3261] messages. One kind of 64 identity used in SIP is an E.164 [E.164] telephone number. A 65 telephone number is a string of digits, where the first one to three 66 digits indicate a country code. The International Telecommunications 67 Union - Telecommunications Sector (ITU-T) defines country codes and 68 delegates the authority for numbers under a country code to the 69 respective national communications authority for that country, as 70 listed in E.164 Annex D [E.164D]. Note the country code does not 71 itself necessarily uniquely identify a country. For example, in 72 country codes +1 and +7, multiple countries share the country code. 73 In the cases of +1 and +7, further digits in the E.164 number, known 74 as national significant digits (also known as area codes in +1) 75 further identify the country. As well, there are non-geographic 76 services with country codes assigned to them. 78 Section 7 of Authenticated Identity Management in the Session 79 Initiation Protocol [RFC8224] describes the process for signing 80 identity tokens. Correspondingly, the STIR Certificates document 81 [RFC8226] describes the format of the signing certificate. The 82 protocol and formats are independent of and can have uses beyond that 83 of signing originating telephone numbers. As well, given that for 84 the most part governments are responsible for managing the numbering 85 resources within their country code, governmental policy may impact 86 who is authorized to issue signing certificates and what constitutes 87 a valid certification path. As such, the base STIR documents defer 88 certificate and validation policy to other documents. This document 89 describes a registry for finding a STIR trust anchor for a given 90 country code for signed telephone numbers. This document only 91 enables policies for E.164 number identity assertions. Moreover, 92 while this document describes the STIR trust anchor registry for 93 various national STIR trust anchors, it does not mandate any 94 particular policy regime. 96 Recalling the STIR problem statement [RFC7340], the goal is to 97 provide authenticated identity for the caller. When a SIP endpoint 98 receives a message with a signed STIR token, that endpoint needs to 99 know whether the signing certificate is, in fact, allowed to make 100 assertions for that identity. It does us no good for a caller with 101 ill intent to have a signed assertion that has a valid certification 102 path to an unauthorized trust anchor. Likewise, it does us no good 103 to use self-signed certificates to sign a SIP message, as even with 104 some limited verification, if there is the slightest chance of an 105 entity with nefarious intent to succeed in either spoofing or taking 106 over the identify of a caller, experience has shown they will do so. 108 As mentioned above, the ITU-T assigns telephone numbers, specifically 109 the responsibility to assign numbers beneath a country's country 110 code, to national communications authorities. A national regulator 111 can inform service providers under its authority which trust anchors 112 are authoritative for numbers under its control. This is 113 straightforward within a country. However, this does not work for 114 the global, interconnected communications network. When someone in a 115 first country calls someone in a second country, how is the service 116 provider or end user in the second country to know who is 117 authoritative for signing certificates in the first country? 119 To solve this problem, this document establishes an IANA registry of 120 STIR trust anchors, indexed by country codes. 122 2. Terminology 124 This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", 125 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 126 "OPTIONAL" as RFC 2119 [RFC2119] defines them. 128 As noted above, a country code may not sufficiently identify a 129 particular country. Likewise, national policy may assign different 130 STIR trust anchors for different sets of national significant numbers 131 (e.g., area codes). For example, while +7 generally identifies the 132 Russian Federation, +76 and +77 identify Kazakhstan. Likewise, +1 133 generally identifies the North American Numbering Plan (NANP), which 134 identifies countries by area code (the following three digits after 135 the country code). For example, +1869 identifies Saint Kitts and 136 Nevis while +1649 identifies Turks and Caicos. The term "country 137 code" appearing from this point forward in this document refers to 138 the country code and, if necessary, the subsequent digits that 139 identify a country or region. With the exception of ITU-T country 140 code +1, the ITU-T country code is the "country code" for the 141 purposes of this registry. In the NANP (+1) case, this means the 142 "country code" can be four digits long. Specifically, to identify a 143 specific country in the NANP, what this document terms the "country 144 code" will be the leading +1 and the following three-digit area code. 146 3. STIR Trust Anchor Registry 148 This registry maps E.164 country codes to STIR trust anchors. There 149 can be one or more STIR trust anchors per country code. 151 3.1. Numeric Country Code 153 E.164 [E.164] defines the country code as a one- to three-digit 154 string. However, there are some country codes that have different 155 country delegations beyond the country code. In these cases, we use 156 additional digits in the number to unambituously identify a country. 157 For example, footnote b of E.164 Annex D [E.164D] shows 25 countries 158 under country code +1 and two countries under country code +7. As 159 well, country code +881, for satellite services, and codes +882 and 160 +883, for international networks, are under the jurisdiction of 161 various national authorities. 163 To distinguish the various national authorities under a given country 164 code, the country code entry can contain these identity codes. 165 Currently, the longest entry can be seven digits, but this could 166 change in the future. As noted above, distinguishing the appropriate 167 certificate to use can be a matter of local policy. We suggest 168 longest match, but be aware that local policy may dictate another 169 policy within that jurisdiction. 171 3.2. STIR Trust Anchor 173 Each country can have zero or more STIR trust anchors. The trust 174 anchor is a self-signed certificate [RFC5280]. The STIR trust anchor 175 is the trust anchor for STIR (SIP) PKI in the given jurisdiction. In 176 the common Web browser situation, a Web server operator can purchase 177 a certificate issued by one of hundreds of certificate authorities 178 from anywhere in the world. The expectation is the authority for 179 signing the identity of a caller will be more strict than the 180 authority for signing the identity of, for example, a Web site. To 181 ensure interoperability, browser and operating system manufacturers 182 need to include the STIR trust anchors from those certificate 183 authorities so when a user in one part of the world accesses a Web 184 server in another part of the world that has a certificate issued by 185 a certificate authority in yet a different part of the world, the 186 site will validate. In the telephone number identity situation, for 187 the most part the individual national numbering authorities will 188 choose a very limited set of STIR trust anchors who they will allow 189 to issue signing certificates for numbers assigned to that country. 191 Within a single country, it would be a relatively easy matter for the 192 national communications regulator to impose and inform their domestic 193 service providers who is the designated certificate authority within 194 that country. However, given the large amount of international 195 telephone traffic (as an example, there were over 100,000,000,000 196 minutes of traffic between the U.S. and other countries in 2014, 197 including VoIP [FCC_intl]), there is a need for service providers and 198 users in different countries to validate that one of the proper 199 certificate authorities for that country has issued the signing 200 certificate. 202 The entry for each national STIR trust anchor is a text certificate 203 [RFC7468] that contains the public key of the STIR trust anchor, 204 matching the private key the STIR trust anchor uses to sign signing 205 keys used by its delegates, such as telecommunications service 206 providers. 208 4. IANA Considerations 210 Refer to [RFC8126] for a description of IANA Considerations terms and 211 their meanings. 213 4.1. Registry Policy: First Come First Served 215 This registry is First Come First Served, understanding there can be 216 multiple trust anchors registered for a given Country Code prefix. 217 The integrity of an originating nation's numbering system is 218 generally the purview of the respective national government. 219 Moreover, the integrity of a terminating network, including the 220 accuracy of received signaling, is generally the purview of the 221 government with jurisdiction over the terminating network. We do not 222 anticipate IANA to intervene in disputes of who has the authority for 223 entering and changing STIR trust anchors. In general, IANA SHOULD 224 validate the request originates from an entity authorized by the 225 recognized national authority for the country as specified in 226 [ITU-D.Agencies], unless it is not clear who the national authority 227 is. However, because it is likely the regulatory authorities in the 228 terminating country will determine the validity of the STIR trust 229 anchor found in the IANA registry, irrespective of the depth of 230 vetting IANA could perform, if IANA believes the registration is not 231 fraudulent, it SHOULD accept the registration even if it cannot 232 positively identify or contact the appropriate national authority. 234 4.2. Registry Elements 236 The STIR Trust Anchor registry consists of one or more entities 237 indicating the public keys of STIR trust anchors for a given country 238 code. With around 200 countries, each of which might have one to 239 four STIR trust anchors, results in a registry with a total 240 participation of about one thousand entries. The expectation is 241 there would be substantially fewer entries in practice. 243 4.2.1. Numeric Country Code 245 The numeric country code is a one- to eight-digit string indicating 246 the numeric country code and optional identity digits. Identity 247 digits are often known as an area code or city code. [E.164D] lists 248 country codes and the identity digits when there are overlapping 249 country codes (+1, +7, and some international codes). 251 IANA MUST verify the requested mapping includes a valid numeric 252 country code as specified in E.164 Annex D. 254 NOTE: The conventional leading + to indicate the string identifies a 255 country code is NOT part of the Country Code element in the registry. 257 4.2.2. STIR Trust Anchor 259 The STIR trust anchor is an RFC7468 [RFC7468] text file that contains 260 the public key of the authorized STIR trust anchor that signs the 261 certificates authorized to sign STIR signaling in the given country. 262 There can be one or more entries in the registry for a given ISO 263 country code to allow for multiple STIR trust anchors for a given 264 country. 266 IANA MUST verify the certificate is valid by using the provided 267 public key in the certificate to validate the signature in the 268 certificate. 270 IANA SHOULD remove a STIR trust anchor from the registry if the 271 certificate expires. 273 4.2.3. Domain of Authority 275 For traceback and reputation purposes, IANA MUST record the validated 276 domain of the entity that made the request to enter, delete, or 277 modify an entry in the STIR Trust Anchor Registry. The mechanism for 278 validating the domain is a matter of IANA policy. Mechanisms include 279 ensuring an emailed request uses DKIM [RFC6376] with secure 280 cryptographic algorithms [RFC8301], web requests have validated 281 client certificates identifying the domain of the requestor, or out 282 of band methods. Note that an unauthenticated inbound phone call is 283 not likely to be an acceptable mechanism of identifying the domain. 285 4.3. Other IANA Considerations 287 There is the potential for a malicious actor attempting to load a 288 trust anchor that could enable them to sign spoofed signaling. As 289 such, IANA SHOULD note who is making the request, to sufficient 290 detail to locate that party for referral to the relevant national 291 authorities. For most countries, it will be the national authority 292 itself or a clear delegate that will be making the registration. For 293 example, in the United States, the Federal Communications Commission 294 has delegated the governance of the STIR trust anchor to the U.S. 295 STI-GA, administered by ATIS, which is an identifiable, incorporated 296 entity with a fixed, physical address. 298 5. Security Considerations 300 The choice of having the STIR trust anchor stored by IANA means that 301 users accessing the certificates MUST use a source-authenticated 302 retrieval mechanism, such as HTTPS [RFC7231]. It almost goes without 303 saying implementers should be using the most up-to-date TLS 304 implementation (or its successor) when retrieving registry elements 305 from IANA. Likewise, the application resolving the URI MUST verify 306 the domain in the certificate matches the IANA domain. The 307 application resolving the URI MUST use DNSSEC [RFC4035] if it is 308 available to the client. Finally, during TLS negotiation the 309 application MUST verify the authority signing IANA's certificate 310 matches the application's understanding of who should sign IANA's 311 certificate. At the time of this writing, that trust anchor would be 312 the DigiCert High Assurance EV Root CA. 314 Because IANA takes no responsibility for the accuracy of any given 315 country's STIR trust anchor entry, this document presumes the 316 terminating provider or local authority will use local policy to 317 determine the trustworthiness of any given entry. ATIS [ATIS-Intl] 318 describes an example of such a local policy. 320 6. Acknowledgements 322 Russ Housley, Jim McEachern, and Sean Turner gave invaluable insight. 323 Ken Carlberg and Padma Krishnaswamy of the United States Federal 324 Communications Commission provided useful feedback in an incredibly 325 short time period. Finally, a huge thank-you to Michelle Cotton and 326 Kim Davies for helping normalize the registries and the procedures 327 for populating them. 329 7. References 331 7.1. Normative References 333 [E.164D] International Telecommunications Union, "List of ITU-T 334 Recommendation E.164 Assigned Country Codes", 335 ITU-T Recommendation E.164 Annex D, 11 2011, 336 . 339 [ITU-D.Agencies] 340 International Telecommunications Union - Development 341 Sector, "National Telecommunication Agencies", 12 2017, 342 . 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 351 Rose, "Protocol Modifications for the DNS Security 352 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 353 . 355 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 356 Housley, R., and W. Polk, "Internet X.509 Public Key 357 Infrastructure Certificate and Certificate Revocation List 358 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 359 . 361 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 362 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 363 RFC 6376, DOI 10.17487/RFC6376, September 2011, 364 . 366 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 367 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 368 DOI 10.17487/RFC7231, June 2014, 369 . 371 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 372 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 373 April 2015, . 375 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 376 Writing an IANA Considerations Section in RFCs", BCP 26, 377 RFC 8126, DOI 10.17487/RFC8126, June 2017, 378 . 380 [RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage 381 Update to DomainKeys Identified Mail (DKIM)", RFC 8301, 382 DOI 10.17487/RFC8301, January 2018, 383 . 385 7.2. Informative References 387 [ATIS-Intl] 388 Alliance for Telecommunications Industry Solutions, 389 "Mechanism for International Signature-based Handling of 390 Asserted information using toKENs (SHAKEN)", 391 . 394 [E.164] International Telecommunications Union, "The International 395 Public Telecommunication Numbering Plan", 396 ITU-T Recommendation E.164, 11 2010, 397 . 400 [FCC_intl] 401 Ashton, S. and L. Blake, "2014 U.S. International 402 Telecommunications Traffic and Revenue Data", 7 2016, 403 . 406 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 407 A., Peterson, J., Sparks, R., Handley, M., and E. 408 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 409 DOI 10.17487/RFC3261, June 2002, 410 . 412 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 413 Telephone Identity Problem Statement and Requirements", 414 RFC 7340, DOI 10.17487/RFC7340, September 2014, 415 . 417 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 418 "Authenticated Identity Management in the Session 419 Initiation Protocol (SIP)", RFC 8224, 420 DOI 10.17487/RFC8224, February 2018, 421 . 423 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 424 Credentials: Certificates", RFC 8226, 425 DOI 10.17487/RFC8226, February 2018, 426 . 428 Author's Address 430 Eric W. Burger 431 Georgetown University 432 37th & O St, NW 433 Washington, DC 20057 434 USA 436 Email: eburger@standardstrack.com