idnits 2.17.1 draft-ietf-acme-telephone-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 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 (July 3, 2017) is 2487 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-acme-star' is defined on line 314, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-07 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-00 == Outdated reference: A later version (-04) exists of draft-ietf-modern-problem-framework-02 == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-14 Summary: 0 errors (**), 0 flaws (~~), 7 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: Informational R. Barnes 5 Expires: January 4, 2018 Mozilla 6 July 3, 2017 8 ACME Identifiers and Challenges for Telephone Numbers 9 draft-ietf-acme-telephone-00.txt 11 Abstract 13 This document specifies identifiers and challenges required to enable 14 the Automated Certificate Management Environment (ACME) to issue 15 certificate for telephonoe numbers. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 4, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Telephone Number Identifier Type . . . . . . . . . . . . . . 3 54 4. Challenges for Telephone Numbers . . . . . . . . . . . . . . 3 55 4.1. Service Provider Validation . . . . . . . . . . . . . . . 4 56 4.2. Web-Based Telephone Number Routability Validation . . . . 5 57 4.3. Advanced Routability Validation . . . . . . . . . . . . . 6 58 4.4. Authority-Based Validation . . . . . . . . . . . . . . . 6 59 4.5. Telephone Number Range Validation . . . . . . . . . . . . 6 60 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. Informative References . . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 ACME [I-D.ietf-acme-acme] is a mechanism for automating certificate 69 management on the Internet. It enables administrative entities to 70 prove effective control over resources like domain names, and 71 automtes the process of generating and issuing certificates. 73 The STIR problem statement [RFC7340] identifies the need for Internet 74 credentials that can attest authority for telephone numbers in order 75 to detect impersonation, which is currently an enabler for common 76 attacks associated with illegal robocalling, voicemail hacking, and 77 swatting. These credentials are used to sign PASSporTs 78 [I-D.ietf-stir-passport], which may be carried in using protocols 79 such as SIP [I-D.ietf-stir-rfc4474bis] or delivered outside of the 80 signaling channel of call setup [I-D.rescorla-stir-fallback]. 81 Currently, the only defined credentials for this purpose are the 82 certificates specified in [I-D.ietf-stir-certificates]. 84 [I-D.ietf-stir-certificates] describes certificate extensions 85 suitable for associating telephone numbers with certificates. To 86 help enable certificate authorities to issue certificates with these 87 extensions, this specification defines extensions to ACME suitable to 88 enable certificate authorities to validate effective control of 89 numbering resources and to issue corresponding certificates. 91 Note that the aim of the initial challenges specified in this 92 document is not to prove the assignment and delegation of resources 93 in the telephone network: it is instead to establish whether 94 Internet-enabled entites have effective control over the devices 95 associated with those resources. Such credentials are not mutually 96 exclusive with credentials delegated from national authorities, and 97 future versions of this specification will explore issuance of those 98 credentials as well. For the purposes of a call set-up protocol like 99 SIP, there may be multiple attestations (for example, multiple SIP 100 Identity header fields) signed by different parties. 102 2. Terminology 104 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 105 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 106 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 107 described in [RFC2119]. 109 3. Telephone Number Identifier Type 111 In order to issue certificates for telephone numbers with ACME, a new 112 ACME identifier type for telephone numbers is required for use in 113 ACME authorization objects. The baseline ACME specification only 114 defines one type of identifier, for a fully-qualified domain name 115 ("dns"). This document thus defines a new ACME identifier type for 116 telephone numbers ("tn"). This represents a telephone number, 117 specifically a number of the type that is specified in the TN 118 Authorization List certificate extension of 119 [I-D.ietf-stir-certificates] for E164Number. 121 { 122 "status": "valid", 123 "expires": "2015-03-01T14:09:00Z", 124 "identifier": { 125 "type": "tn", 126 "value": "2125551212" 127 }, 128 "challenges": [ 129 { 130 "type": "sms-link-00", 131 "status": "valid", 132 "validated": "2014-12-01T12:05:00Z", 133 "keyAuthorization": "SXQe-2XODaDxNR...vb29HhjjLPSggwiE" 134 } 135 ] 136 } 138 4. Challenges for Telephone Numbers 140 Proving that a device on the Internet has effective control over a 141 telephone number is not as easy as proving control over an Internet 142 resources like a DNS zone or a resource on the web. Issuing 143 certificates for telephone numbers is perhaps most closely analogous 144 to certificates for email addresses: end user control over an email 145 address boils down to the capabilities to read and send email 146 associated with that address. While a user typically has control 147 over an email address for a long period of time, control over email 148 addresses can change when users leave companies or other 149 institutions, and addresses may subsequently end up in the control of 150 another party. Moreover, while it is relatively easy to spoof the 151 sender of any email address, as it unfortunately is with telephone 152 numbers, it is harder to intercept traffic to a target email address 153 or telephone number. 155 The likely challenges for proving effective control over a telephone 156 number therefore rely largely on routing some kind of secret to the 157 telephone number in question and requesting that the receiving device 158 play that secret back to the ACME server. The Short Message Service 159 (SMS) provides a key building block for challenges because of its 160 ability to route a secret addressed to a telephone number to a user- 161 controlled device. However, because of the diverse capabilities of 162 Internet-connected devices that control telephone numbers, an SMS 163 could be used in different ways for different challenges. Some 164 devices will be able to interrogate their operating system to learn 165 their own telephone number, for example, while others cannot. Some 166 devices will be able to receive a text message and suppress it from 167 being rendered to the user, while others cannot. 169 Because the assignment of numbering resources can change over time, 170 demonstrations of effective control must be regularly refreshed -- 171 though again, because of the diverse capabilities of the devices 172 involved, different schemes for refreshing the challenge, ones that 173 require less direct user supervision, may be available to some 174 devices and not others. 176 4.1. Service Provider Validation 178 Communications Service Providers (CSPs) can delegate authority over 179 numbers to their customers, and those CSPs who support ACME can then 180 help customers to acquire certificates for those numbering resources 181 with ACME. The system of [I-D.barnes-acme-service-provider] for 182 example gives a mechanism that allows service providers to acquire 183 certificates corresponding to a Service Provider Code (SPC) as 184 defined in [I-D.ietf-stir-certificates]. This can permit number 185 acquisition flows compatible with those shown in 186 [I-D.ietf-modern-problem-framework]. 188 type (required, string): The string "spc-delegate-00" 190 token (required, string): A random value that uniquely identifies 191 the challenge. This value MUST have at least 128 bits of entropy, 192 in order to prevent an attacker from guessing it. It MUST NOT 193 contain any characters outside the URL-safe Base64 alphabet and 194 MUST NOT contain any padding characters ("="). 196 { 197 "type": "spc-delegate-00", 198 } 200 A client's response to this challenge will contain a token issued by 201 the CSP at the time of delegation, perhaps a token issued through a 202 MODERN-like [I-D.ietf-modern-problem-framework] acquisition 203 interface. The token must contain the delegated telephone number or 204 number range, the SPC of the CSP, a nonce, the signature of the CSP 205 with its SPC credential, and a link to a resource where relying 206 parties can acquire the SPC credential. 208 [TBD token format] 210 An ACME server supporting the Service Provider Validation for 211 telephone number certificates must have some way to determine whether 212 or not a telephone number falls within a particular SPC. This may 213 involve consulting a local or external database that maps SPCs to 214 TNs. Without this check, CSPs would be able to issue credentials for 215 numbers owned by other CSPs. The order should only be validated if 216 the telephone number in the order actually falls under the SPC that 217 signed the token. 219 4.2. Web-Based Telephone Number Routability Validation 221 With web-based telephone number routability validation, the client in 222 an ACME transaction proves its control over a telephone number by 223 proving that it can receive traffic sent to that number over the 224 PSTN. The ACME server challenges the client to dereference a URL 225 containing a token that is sent to the client over SMS. Typically 226 that token will be embedded in a URL that the end user will visit in 227 order to be guided to a web resource that will enable account 228 creation with the CA. By allowing a user action to complete the 229 challenge, this validation method supports the use of ACME with SMS 230 endpoints that do not support automated response to challenges. 232 type (required, string): The string "sms-link-00" 234 token (required, string): A random value that uniquely identifies 235 the challenge. This value MUST have at least 128 bits of entropy, 236 in order to prevent an attacker from guessing it. It MUST NOT 237 contain any characters outside the URL-safe Base64 alphabet and 238 MUST NOT contain any padding characters ("="). 240 { 241 "type": "sms-link-00", 242 } 244 A client's response to this challenge simply acknowledges that it is 245 ready to receive the validation SMS from the server. 247 On receiving a response, the server sends an SMS message to the TN 248 being validated containing a URL that the client must have a user 249 access in order to complete the challenge. This URL is intended to 250 be opened in a web browser so that the user can have an interaction 251 with the CA; it is not sufficient for the client to simply send a GET 252 request to the URL. 254 To validate an "sms-link" challenge, the server verifies that a user 255 has visited the URL included in the SMS message and completed any 256 steps specified there. 258 Because SMS return routability tests are becoming more common in two- 259 factor authentication systems, they have also become an attractive 260 target for attackers to try to compromise. Using short-lived 261 certificates for this function, and requiring the client to perform 262 this validation repeatedly, would help to mitigate associated risks. 264 4.3. Advanced Routability Validation 266 Future versions of this specification will explore ways to increase 267 the automation of the challenge process when the client device has an 268 application capable of creating ACME accounts and requesting 269 certificates to be issued. This will likely follow the token / key- 270 authorization pattern of the challenges defined for DNS names, except 271 that the token and key authoriation will be passed in SMS instead of 272 HTTP, TLS, or DNS. 274 4.4. Authority-Based Validation 276 Future versions of this specification will also explore ways that 277 various numbering authorities could attest ownership over numbering 278 resources, and ways that the assignees of numbers could coordinate 279 with those authorities to satisfy ACME challenges and receive 280 certificates. This would likely work much the same way as the 281 Service Provider case in Section 4.1. 283 4.5. Telephone Number Range Validation 285 Future versions of this specification will explore ways to validate 286 bulk allocations of telephone numbers such as those used by IP PBXs. 288 5. Acknowledgments 290 We would like to thank you for your contributions to this problem 291 statement and framework. 293 6. IANA Considerations 295 Future versions of this specification will include registrations for 296 the ACME Identifier type and ACME Challenge type registries here. 298 7. Security Considerations 300 TBD. 302 8. Informative References 304 [I-D.barnes-acme-service-provider] 305 Barnes, M. and C. Wendt, "ACME Identifiers and Challenges 306 for VoIP Service Providers", draft-barnes-acme-service- 307 provider-01 (work in progress), June 2017. 309 [I-D.ietf-acme-acme] 310 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 311 Certificate Management Environment (ACME)", draft-ietf- 312 acme-acme-07 (work in progress), June 2017. 314 [I-D.ietf-acme-star] 315 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 316 Fossati, "Use of Short-Term, Automatically-Renewed (STAR) 317 Certificates to Delegate Authority over Web Sites", draft- 318 ietf-acme-star-00 (work in progress), June 2017. 320 [I-D.ietf-modern-problem-framework] 321 Peterson, J. and T. McGarry, "Modern Problem Statement, 322 Use Cases, and Framework", draft-ietf-modern-problem- 323 framework-02 (work in progress), March 2017. 325 [I-D.ietf-stir-certificates] 326 Peterson, J. and S. Turner, "Secure Telephone Identity 327 Credentials: Certificates", draft-ietf-stir- 328 certificates-14 (work in progress), May 2017. 330 [I-D.ietf-stir-passport] 331 Wendt, C. and J. Peterson, "Personal Assertion Token 332 (PASSporT)", draft-ietf-stir-passport-11 (work in 333 progress), February 2017. 335 [I-D.ietf-stir-rfc4474bis] 336 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 337 "Authenticated Identity Management in the Session 338 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 339 (work in progress), February 2017. 341 [I-D.rescorla-stir-fallback] 342 Rescorla, E. and J. Peterson, "STIR Out of Band 343 Architecture and Use Cases", draft-rescorla-stir- 344 fallback-02 (work in progress), June 2017. 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, 348 DOI 10.17487/RFC2119, March 1997, 349 . 351 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 352 Telephone Identity Problem Statement and Requirements", 353 RFC 7340, DOI 10.17487/RFC7340, September 2014, 354 . 356 Authors' Addresses 358 Jon Peterson 359 Neustar, Inc. 360 1800 Sutter St Suite 570 361 Concord, CA 94520 362 US 364 Email: jon.peterson@neustar.biz 366 Richard Barnes 367 Mozilla 369 Email: rlb@ipv.sx