idnits 2.17.1 draft-ietf-acme-telephone-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 (October 30, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.peterson-acme-authority-token' is mentioned on line 188, but not defined == Unused Reference: 'I-D.ietf-acme-star' is defined on line 300, 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 (-02) exists of draft-ietf-acme-service-provider-01 == 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-03 == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-14 == Outdated reference: A later version (-07) exists of draft-ietf-stir-oob-00 Summary: 0 errors (**), 0 flaws (~~), 10 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: May 3, 2018 Mozilla 6 October 30, 2017 8 ACME Identifiers and Challenges for Telephone Numbers 9 draft-ietf-acme-telephone-01.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 https://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 May 3, 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 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.ietf-stir-oob]. Currently, the 81 only defined credentials for this purpose are the certificates 82 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.ietf-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]. Once service providers have 185 certificates for SPCs, those could be leveraged to enable number 186 acquisition flows compatible with those shown in 187 [I-D.ietf-modern-problem-framework], by using a token mechanism such 188 as the one described in [I-D.peterson-acme-authority-token]. 190 [TBD token type registration and format] 191 The token must contain the delegated telephone number or number 192 range, the SPC of the CSP, a nonce, the signature of the CSP with its 193 SPC credential, and a link to a resource where relying parties can 194 acquire the SPC credential. 196 An ACME server supporting the Service Provider Validation for 197 telephone number certificates must have some way to determine whether 198 or not a telephone number falls within a particular SPC. This may 199 involve consulting a local or external database that maps SPCs to 200 TNs. Without this check, CSPs would be able to issue credentials for 201 numbers owned by other CSPs. The order should only be validated if 202 the telephone number in the order actually falls under the SPC that 203 signed the token. 205 4.2. Web-Based Telephone Number Routability Validation 207 With web-based telephone number routability validation, the client in 208 an ACME transaction proves its control over a telephone number by 209 proving that it can receive traffic sent to that number over the 210 PSTN. The ACME server challenges the client to dereference a URL 211 containing a token that is sent to the client over SMS. Typically 212 that token will be embedded in a URL that the end user will visit in 213 order to be guided to a web resource that will enable account 214 creation with the CA. By allowing a user action to complete the 215 challenge, this validation method supports the use of ACME with SMS 216 endpoints that do not support automated response to challenges. 218 type (required, string): The string "sms-link-00" 220 token (required, string): A random value that uniquely identifies 221 the challenge. This value MUST have at least 128 bits of entropy, 222 in order to prevent an attacker from guessing it. It MUST NOT 223 contain any characters outside the URL-safe Base64 alphabet and 224 MUST NOT contain any padding characters ("="). 226 { 227 "type": "sms-link-00", 228 } 230 A client's response to this challenge simply acknowledges that it is 231 ready to receive the validation SMS from the server. 233 On receiving a response, the server sends an SMS message to the TN 234 being validated containing a URL that the client must have a user 235 access in order to complete the challenge. This URL is intended to 236 be opened in a web browser so that the user can have an interaction 237 with the CA; it is not sufficient for the client to simply send a GET 238 request to the URL. 240 To validate an "sms-link" challenge, the server verifies that a user 241 has visited the URL included in the SMS message and completed any 242 steps specified there. 244 Because SMS return routability tests are becoming more common in two- 245 factor authentication systems, they have also become an attractive 246 target for attackers to try to compromise. Using short-lived 247 certificates for this function, and requiring the client to perform 248 this validation repeatedly, would help to mitigate associated risks. 250 4.3. Advanced Routability Validation 252 Future versions of this specification will explore ways to increase 253 the automation of the challenge process when the client device has an 254 application capable of creating ACME accounts and requesting 255 certificates to be issued. This will likely follow the token / key- 256 authorization pattern of the challenges defined for DNS names, except 257 that the token and key authoriation will be passed in SMS instead of 258 HTTP, TLS, or DNS. 260 4.4. Authority-Based Validation 262 Future versions of this specification will also explore ways that 263 various numbering authorities could attest ownership over numbering 264 resources, and ways that the assignees of numbers could coordinate 265 with those authorities to satisfy ACME challenges and receive 266 certificates. This would likely work much the same way as the 267 Service Provider case in Section 4.1. 269 4.5. Telephone Number Range Validation 271 Future versions of this specification will explore ways to validate 272 bulk allocations of telephone numbers such as those used by IP PBXs. 274 5. Acknowledgments 276 We would like to thank you for your contributions to this problem 277 statement and framework. 279 6. IANA Considerations 281 Future versions of this specification will include registrations for 282 the ACME Identifier type and ACME Challenge type registries here. 284 7. Security Considerations 286 TBD. 288 8. Informative References 290 [I-D.ietf-acme-acme] 291 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 292 Certificate Management Environment (ACME)", draft-ietf- 293 acme-acme-07 (work in progress), June 2017. 295 [I-D.ietf-acme-service-provider] 296 Barnes, M. and C. Wendt, "ACME Identifiers and Challenges 297 for VoIP Service Providers", draft-ietf-acme-service- 298 provider-01 (work in progress), July 2017. 300 [I-D.ietf-acme-star] 301 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 302 Fossati, "Use of Short-Term, Automatically-Renewed (STAR) 303 Certificates to Delegate Authority over Web Sites", draft- 304 ietf-acme-star-00 (work in progress), June 2017. 306 [I-D.ietf-modern-problem-framework] 307 Peterson, J. and T. McGarry, "Modern Problem Statement, 308 Use Cases, and Framework", draft-ietf-modern-problem- 309 framework-03 (work in progress), July 2017. 311 [I-D.ietf-stir-certificates] 312 Peterson, J. and S. Turner, "Secure Telephone Identity 313 Credentials: Certificates", draft-ietf-stir- 314 certificates-14 (work in progress), May 2017. 316 [I-D.ietf-stir-oob] 317 Rescorla, E. and J. Peterson, "STIR Out of Band 318 Architecture and Use Cases", draft-ietf-stir-oob-00 (work 319 in progress), July 2017. 321 [I-D.ietf-stir-passport] 322 Wendt, C. and J. Peterson, "Personal Assertion Token 323 (PASSporT)", draft-ietf-stir-passport-11 (work in 324 progress), February 2017. 326 [I-D.ietf-stir-rfc4474bis] 327 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 328 "Authenticated Identity Management in the Session 329 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 330 (work in progress), February 2017. 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, 334 DOI 10.17487/RFC2119, March 1997, 335 . 337 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 338 Telephone Identity Problem Statement and Requirements", 339 RFC 7340, DOI 10.17487/RFC7340, September 2014, 340 . 342 Authors' Addresses 344 Jon Peterson 345 Neustar, Inc. 346 1800 Sutter St Suite 570 347 Concord, CA 94520 348 US 350 Email: jon.peterson@neustar.biz 352 Richard Barnes 353 Mozilla 355 Email: rlb@ipv.sx