idnits 2.17.1 draft-peterson-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 (October 31, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.peterson-modern-teri' is defined on line 274, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-03 == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-10 == Outdated reference: A later version (-11) exists of draft-ietf-stir-passport-09 == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-14 == Outdated reference: A later version (-04) exists of draft-peterson-modern-teri-01 == Outdated reference: A later version (-02) exists of draft-rescorla-stir-fallback-00 Summary: 0 errors (**), 0 flaws (~~), 9 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 4, 2017 Mozilla 6 October 31, 2016 8 ACME Identifiers and Challenges for Telephone Numbers 9 draft-peterson-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 May 4, 2017. 34 Copyright Notice 36 Copyright (c) 2016 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. Web-Based Telephone Number Routability Validation . . . . 4 56 4.2. Advanced Routability Validation . . . . . . . . . . . . . 5 57 4.3. Telephone Number Range Validation . . . . . . . . . . . . 5 58 4.4. Authority-Based Validation . . . . . . . . . . . . . . . 5 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 8. Informative References . . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 [I-D.ietf-acme-acme] is a mechanism for automating certificate 68 management on the Internet. It enables administrative entities to 69 prove effective control over resources like domain names, and 70 automtes the process of generating and issuing certificates. 72 The STIR problem statement [RFC7340] identifies the need for Internet 73 credentials that can attest authority for telephone numbers in order 74 to detect impersonation, which is currently an enabler for common 75 attacks associated with illegal robocalling, voicemail hacking, and 76 swatting. These credentials are used to sign PASSporTs 77 [I-D.ietf-stir-passport], which may be carried in using protocols 78 such as SIP [I-D.ietf-stir-rfc4474bis] or delivered outside of the 79 signaling channel of call setup [I-D.rescorla-stir-fallback]. 80 Currently, the only defined credentials for this purpose are the 81 certificates specified in [I-D.ietf-stir-certificates]. 83 [I-D.ietf-stir-certificates] describes certificate extensions 84 suitable for associating telephone numbers with certificates. To 85 help enable certificate authorities to issue certificates with these 86 extensions, this specification defines extensions to ACME suitable to 87 enable certificate authorities to validate effective control of 88 numbering resources and to issue corresponding certificates. 90 Note that the aim of the initial challenges specified in this 91 document is not to prove the assignment and delegation of resources 92 in the telephone network: it is instead to establish whether 93 Internet-enabled entites have effective control over the devices 94 associated with those resources. Such credentials are not mutually 95 exclusive with credentials delegated from national authorities, and 96 future versions of this specification will explore issuance of those 97 credentials as well. For the purposes of a call set-up protocol like 98 SIP, there may be multiple attestations (for example, multiple SIP 99 Identity header fields) signed by different parties. 101 2. Terminology 103 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 104 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 105 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 106 described in [RFC2119]. 108 3. Telephone Number Identifier Type 110 In order to issue certificates for telephone numbers with ACME, a new 111 ACME identifier type for telephone numbers is required for use in 112 ACME authorization objects. The baseline ACME specification only 113 defines one type of identifier, for a fully-qualified domain name 114 ("dns"). This document thus defines a new ACME identifier type for 115 telephone numbers ("tn"). This represents a telephone number, 116 specifically a number of the type that is specified in the TN 117 Authorization List certificate extension of 118 [I-D.ietf-stir-certificates] for E164Number. 120 { 121 "status": "valid", 122 "expires": "2015-03-01T14:09:00Z", 123 "identifier": { 124 "type": "tn", 125 "value": "2125551212" 126 }, 127 "challenges": [ 128 { 129 "type": "sms-link-00", 130 "status": "valid", 131 "validated": "2014-12-01T12:05:00Z", 132 "keyAuthorization": "SXQe-2XODaDxNR...vb29HhjjLPSggwiE" 133 } 134 ] 135 } 137 4. Challenges for Telephone Numbers 139 Proving that a device on the Internet has effective control over a 140 telephone number is not as easy as proving control over an Internet 141 resources like a DNS zone or a resource on the web. Issuing 142 certificates for telephone numbers is perhaps most closely analogous 143 to certificates for email addresses: end user control over an email 144 address boils down to the capabilities to read and send email 145 associated with that address. While a user typically has control 146 over an email address for a long period of time, control over email 147 addresses can change when users leave companies or other 148 institutions, and addresses may subsequently end up in the control of 149 another party. Moreover, while it is relatively easy to spoof the 150 sender of any email address, as it unfortunately is with telephone 151 numbers, it is harder to intercept traffic to a target email address 152 or telephone number. 154 The likely challenges for proving effective control over a telephone 155 number therefore rely largely on routing some kind of secret to the 156 telephone number in question and requesting that the receiving device 157 play that secret back to the ACME server. The Short Message Service 158 (SMS) provides a key building block for challenges because of its 159 ability to route a secret addressed to a telephone number to a user- 160 controlled device. However, because of the diverse capabilities of 161 Internet-connected devices that control telephone numbers, an SMS 162 could be used in different ways for different challenges. Some 163 devices will be able to interrogate their operating system to learn 164 their own telephone number, for example, while others cannot. Some 165 devices will be able to receive a text message and suppress it from 166 being rendered to the user, while others cannot. 168 Because the assignment of numbering resources can change over time, 169 demonstrations of effective control must be regularly refreshed -- 170 though again, because of the diverse capabilities of the devices 171 involved, different schemes for refreshing the challenge, ones that 172 require less direct user supervision, may be available to some 173 devices and not others. 175 4.1. Web-Based Telephone Number Routability Validation 177 With web-based telephone number routability validation, the client in 178 an ACME transaction proves its control over a telephone number by 179 proving that it can receive traffic sent to that number over the 180 PSTN. The ACME server challenges the client to dereference a URL 181 containing a token that is sent to the client over SMS. Typically 182 that token will be embedded in a URL that the end user will visit in 183 order to be guided to a web resource that will enable account 184 creation with the CA. By allowing a user action to complete the 185 challenge, this validation method supports the use of ACME with SMS 186 endpoints that do not support automated response to challenges. 188 type (required, string): The string "sms-link-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": "sms-link-00", 198 } 200 A client's response to this challenge simply acknowledges that it is 201 ready to receive the validation SMS from the server. 203 On receiving a response, the server sends an SMS message to the TN 204 being validated containing a URL that the client must have a user 205 access in order to complete the challenge. This URL is intended to 206 be opened in a web browser so that the user can have an interaction 207 with the CA; it is not sufficient for the client to simply send a GET 208 request to the URL. 210 To validate an "sms-link" challenge, the server verifies that a user 211 has visited the URL included in the SMS message and completed any 212 steps specified there. 214 4.2. Advanced Routability Validation 216 Future versions of this specification will explore ways to increase 217 the automation of the challenge process when the client device has an 218 application capable of creating ACME accounts and requesting 219 certificates to be issued. This will likely follow the token / key- 220 authorization pattern of the challenges defined for DNS names, except 221 that the token and key authoriation will be passed in SMS instead of 222 HTTP, TLS, or DNS. 224 4.3. Telephone Number Range Validation 226 Future versions of this specification will explore ways to validate 227 bulk allocations of telephone numbers such as those used by IP PBXs. 229 4.4. Authority-Based Validation 231 Future versions of this specification will also explore ways that 232 various numbering authorities could attest ownership over numbering 233 resources, and ways that the assignees of numbers could coordinate 234 with those authorities to satisfy ACME challenges and receive 235 certificates. 237 5. Acknowledgments 239 We would like to thank you for your contributions to this problem 240 statement and framework. 242 6. IANA Considerations 244 Future versions of this specification will include registrations for 245 the ACME Identifier type and ACME Challenge type registries here. 247 7. Security Considerations 249 TBD. 251 8. Informative References 253 [I-D.ietf-acme-acme] 254 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 255 Certificate Management Environment (ACME)", draft-ietf- 256 acme-acme-03 (work in progress), July 2016. 258 [I-D.ietf-stir-certificates] 259 Peterson, J. and S. Turner, "Secure Telephone Identity 260 Credentials: Certificates", draft-ietf-stir- 261 certificates-10 (work in progress), October 2016. 263 [I-D.ietf-stir-passport] 264 Wendt, C. and J. Peterson, "Personal Assertion Token 265 (PASSporT)", draft-ietf-stir-passport-09 (work in 266 progress), October 2016. 268 [I-D.ietf-stir-rfc4474bis] 269 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 270 "Authenticated Identity Management in the Session 271 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-14 272 (work in progress), October 2016. 274 [I-D.peterson-modern-teri] 275 Peterson, J., "An Architecture and Information Model for 276 Telephone-Related Information (TeRI)", draft-peterson- 277 modern-teri-01 (work in progress), July 2016. 279 [I-D.rescorla-stir-fallback] 280 Rescorla, E., "Secure Caller-ID Fallback Mode", draft- 281 rescorla-stir-fallback-00 (work in progress), July 2013. 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 289 Telephone Identity Problem Statement and Requirements", 290 RFC 7340, DOI 10.17487/RFC7340, September 2014, 291 . 293 Authors' Addresses 295 Jon Peterson 296 Neustar, Inc. 297 1800 Sutter St Suite 570 298 Concord, CA 94520 299 US 301 Email: jon.peterson@neustar.biz 303 Richard Barnes 304 Mozilla 306 Email: rlb@ipv.sx