idnits 2.17.1 draft-wendt-acme-authority-token-tnauthlist-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 05, 2018) is 2236 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ATIS-1000074' is defined on line 461, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-09 == Outdated reference: A later version (-01) exists of draft-peterson-acme-authority-token-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Wendt 3 Internet-Draft D. Hancock 4 Intended status: Informational Comcast 5 Expires: September 6, 2018 M. Barnes 6 iconectiv 7 J. Peterson 8 Neustar Inc. 9 March 05, 2018 11 TNAuthList profile of ACME Authority Token 12 draft-wendt-acme-authority-token-tnauthlist-00 14 Abstract 16 This document defines a profile of the Automated Certificate 17 Management Environment (ACME) Authority Token for the automated and 18 authorized creation of certificates for VoIP Telephone Providers to 19 support Secure Telephony Identity (STI) using the TNAuthList defined 20 by STI certificates. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 6, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. ACME new-order identifiers for TNAuthList . . . . . . . . . . 3 59 4. TNAuthList Identifier Authorization . . . . . . . . . . . . . 4 60 5. TNAuthList Authority Token . . . . . . . . . . . . . . . . . 6 61 5.1. "iss" claim . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.2. "exp" claim . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.3. "jti" claim . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.4. "atc" claim . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.5. Acquiring the token from the Authority . . . . . . . . . 7 66 6. Validating the TNAuthList Authority Token . . . . . . . . . . 7 67 7. Example TNAuthList Tokens . . . . . . . . . . . . . . . . . . 8 68 7.1. Example-1 . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.2. Example-2 . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.3. Example-3 . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. Large number of Non-contiguous TNAuthList values . . . . . . 9 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 11.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 [I-D.ietf-acme-acme] is a mechanism for automating certificate 82 management on the Internet. It enables administrative entities to 83 prove effective control over resources like domain names, and 84 automates the process of generating and issuing certificates. 85 [I-D.peterson-acme-authority-token] extends ACME to provide a general 86 method of extending the Authority and authorization of entities to 87 control a resource via a third party Authority beyond the 88 Certification Authority. 90 This document addresses the STIR problem statement [RFC7340] which 91 identifies the need for Internet credentials that can attest 92 authority for the originator of VoIP calls in order to detect 93 impersonation, which is currently an enabler for common attacks 94 associated with illegal robocalling, voicemail hacking, and swatting. 95 These credentials are used to sign PASSporTs [RFC8225], which can be 96 carried in using protocols such as SIP [RFC8224]. Currently, the 97 only defined credentials for this purpose are the certificates 98 specified in [RFC8226]. 100 [RFC8226] describes certificate extensions suitable for associating 101 telephone numbers and service provider codes with certificates. 102 Specifically, the TN Authorization List defined in [RFC8226] 103 Section 9, defines the ability to associate a STI certificate with a 104 specific set of Service Provider Codes (SPC), Telephone Numbers 105 (TNs), or Telephone Number ranges (TN ranges). Typically, these 106 identifiers have been associated to a Communications Service Provider 107 (CSP) that is authorized to use a set of telephone numbers or 108 telephone number ranges in association with a Service Provider Code 109 as defined in [RFC8226]. The SPC is a unique code or string managed 110 by a national regulatory body that has the authority over those code 111 associations. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. ACME new-order identifiers for TNAuthList 121 In [I-D.ietf-acme-acme], Section 7.4 defines the procedure that an 122 ACME client uses to order a new certificate from a Certificate 123 Authority. The new-order request contains an identifier object that 124 specifies the identifiers the order corresponds to. For the 125 TNAuthList identifier, the new-order request MUST include a type set 126 to the string "TNAuthList". The value of the identifier MUST be set 127 to the details of the TNAuthList requested. 129 The format of the string that represents the TNAuthList MUST be 130 constructed as follows. The TNAuthList as defined in [RFC8226] can 131 include three types of identifiers. 133 1. Service Provider Code (SPC) identified as "spc" 135 2. Telephone Number (TN) identified as "tn" 137 3. Telephone Number Range (TNRange) identified as "tnrange" 139 The above types of identifiers and the corresponding strings should 140 be used as a JSON key part of an array of JSON key and value pairs. 141 The JSON value would be the string representing the corresponding 142 SPC, TN, or TNRange values. 144 For example, a request for a TNAuthList certificate with a SPC value 145 of "1234" and a TN value of "2155551212" would look as follows, 147 "identifiers": [{"type":"TNAuthList","value":"["spc":"1234", 148 "tn","2155551212"]"}] 150 A full new-order request would look as follows, 152 POST /acme/new-order HTTP/1.1 153 Host: example.com 154 Content-Type: application/jose+json 156 { 157 "protected": base64url({ 158 "alg": "ES256", 159 "kid": "https://example.com/acme/acct/1", 160 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 161 "url": "https://example.com/acme/new-order" 162 }), 163 "payload": base64url({ 164 "identifiers": [{"type:"TNAuthList","value":"["spc":"1234", 165 "tn":"2155551212"]"}], 166 "notBefore": "2016-01-01T00:00:00Z", 167 "notAfter": "2016-01-08T00:00:00Z" 168 }), 169 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 170 } 172 4. TNAuthList Identifier Authorization 174 On receiving a valid new-order request, the CA creates an 175 authorization challenge and can be queried by the following example 176 request and response. 178 GET /acme/authz/1234 HTTP/1.1 179 Host: example.com 180 HTTP/1.1 200 OK 181 Content-Type: application/json 182 Link: ;rel="index" 184 { 185 "status": "pending", 186 "expires": "2018-03-03T14:09:00Z", 188 "identifier": { 189 "type:"TNAuthList", 190 "value":"["spc":"1234","tn":"2155551212"]" 191 }, 193 "challenges": [ 194 { 195 "type": "tkauth-01", 196 "tkauth-type": "ATC", 197 "token-authority": "https://authority.example.org/authz", 198 "url": "https://boulder.example.com/authz/asdf/0" 199 "token": "IlirfxKKXAsHtmzK29Pj8A" 200 } 201 ] 202 } 204 This follows [I-D.peterson-acme-authority-token] with a specific 205 identifier corresponding to the specific challenge as defined 206 previously in this document. 208 When processing a certificate order containing an identifier of type 209 "TNAuthList", a CA MUST use the Authority Token challenge mechanism 210 defined in [I-D.peterson-acme-authority-token] to verify that the 211 requesting ACME client has control over the requested "TNAuthList" 212 value. 214 The challenge "token-authority" parameter is optional and only used 215 in cases where the VoIP telephone network requires a CA to determine 216 the authority. This is currently not the case for the SHAKEN 217 [ATIS-1000080] certificate framework governance, but may be used by 218 other frameworks. If a "token-authority" parameter is present, then 219 the ACME client MAY use the "token-authority" value to identify the 220 URL representing the authority that will provide the TNAuthList 221 Authority Token response to the challenge. If the "token-authority" 222 parameter is not present, then the ACME client MUST identify the 223 Authority based on locally configured information or local policies. 225 A client responds to this challenge by providing an TNAuthList 226 Authority Token to the CA. The ACME client MUST respond to the 227 challenge by posting the TNAuthList Authority Token to the URL 228 identified in the ACME challenge with a request, an example of which 229 follows. 231 POST /acme/authz/asdf/0 HTTP/1.1 232 Host: sti-ca.com 233 Content-Type: application/jose+json 235 { 236 "protected": base64url({ 237 "alg": "ES256", 238 "kid": "https://sti-ca.com/acme/reg/asdf", 239 "nonce": "Q_s3MWoqT05TrdkM2MTDcw", 240 "url": "https://sti-ca.com/acme/authz/asdf/0" 241 }), 242 "payload": base64url({ 243 "ATC": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE" 244 }), 245 "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" 246 } 248 The specifics of the construction of the "ATC" token is defined in 249 the next section. 251 5. TNAuthList Authority Token 253 The Telephone Number Authority List Authority Token (TNAuthList 254 Authority Token) is an extension of the ACME Authority Token defined 255 in [I-D.peterson-acme-authority-token]. 257 The TNAuthList Authority Token Protected header MUST comply with the 258 Authority Token Protected header as defined in 259 [I-D.peterson-acme-authority-token]. 261 The TNAuthList Authority Token Payload MUST include the claims 262 defined for the Authority Token. These are detailed in the next 263 subsections. 265 5.1. "iss" claim 267 The "iss" claim is an optional claim. It can be used as a URL 268 identifying the Authority that issued the TNAuthList Authority Token 269 beyond the "x5u" Header claim that identifies the location of the 270 certificate of the Authority used to validate the Authority Token. 272 5.2. "exp" claim 274 The "exp" claim contains the DateTime value of the ending time and 275 date that the TNAuthList Authority Token expires. 277 5.3. "jti" claim 279 The "jti" claim contains a unique identifier for the TNAuthList 280 Authority Token transaction. 282 5.4. "atc" claim 284 The "atc" claim is the only claim specifically defined in this 285 document. It contains an array of three elements; a string set to 286 "TNAuthList", an identifier value which is an array of the 287 identifiers to be included in the TNAuthList of the requesting SP, 288 and a nonce. 290 An example of the TNAuthList Authority Token is as follows, 292 { "typ":"JWT", 293 "alg":"ES256", 294 "x5u":https://authority.example.org/cert 295 } 297 { 298 "iss":"https://authority.example.org/authz", 299 "exp":1300819380, 300 "jti":"id6098364921", 301 "atc":["TnAuthList","["spc":"1234","tn":"2155551212"]", 302 "Q_s3MWoqT05TrdkM2MTDcw"] 303 } 305 Similar to how the TNAuthList identifier value is defined, the 306 identifier value in the "atc" should also include the same JSON array 307 of TNAuthList values with key/value pairs representing each part of 308 the TNAuthList. 310 5.5. Acquiring the token from the Authority 312 The specifics of how the token is acquired from the authority is out 313 of the scope of this document. 315 6. Validating the TNAuthList Authority Token 317 Upon receiving a response to the challenge, the ACME server MUST 318 perform the following steps to determine the validity of the 319 response. 321 o Verify that the token contained in the Payload "ATC" field is an 322 TNAuthList Authority Token. 324 o Verify the TNAuthList Authority Token signature using the public 325 key of the certificate referenced by the token's "x5u" parameter. 327 o Verify that "atc" claim contains an identifier type of 328 "TNAuthList", 330 o Verify that the "atc" claim contains keys and values that matches 331 the keys and values of the Identifier specified in the original 332 challenge. 334 o Verify that the remaining claims are valid (e.g., verify that 335 token has not expired) 337 If all steps in the token validation process pass, then the CA MUST 338 set the challenge object "status" to "valid". If any step of the 339 validation process fails, the "status" in the challenge object MUST 340 be set to "invalid". 342 7. Example TNAuthList Tokens 344 This section provides some TNAuthList Authority Token examples. 346 7.1. Example-1 348 TNAuthList Authority Token authorizing a TNAuthList containing a 349 single SPC value 351 { 352 "typ":"JWT", 353 "alg":"ES256", 354 "x5u":https://authority.example.org/cert 355 } 357 { 358 "iss":"https://authority.example.org/authz", 359 "exp":1300819380, 360 "jti":"id6098364921", 361 "atc":["TnAuthList","["spc":"1234"]","Q_s3MWoqT05TrdkM2MTDcw"] 362 } 364 7.2. Example-2 366 TNAuthList Authority Token authorizing a TNAuthList identifier 367 containing an SPC value plus a range of TNs 369 { 370 "typ":"JWT", 371 "alg":"ES256", 372 "x5u":https://authority.example.org/cert 373 } 375 { 376 "iss":"https://authority.example.org/authz", 377 "exp":1300819380, 378 "jti":"id6098364921", 379 "atc":["TnAuthList", 380 ["spc":"1234","tn-range":{"start":"12155551212","count":"50"}], 381 "Q_s3MWoqT05TrdkM2MTDcw"] 382 } 384 7.3. Example-3 386 TNAuthList Authority Token authorizing a TNAuthList identifier 387 containing a single TN 389 { 390 "typ":"JWT", 391 "alg":"ES256", 392 "x5u":https://authority.example.org/cert 393 } 395 { 396 "iss":"https://authority.example.org/authz", 397 "exp":1300819380, 398 "jti":"id6098364921", 399 "atc":["TnAuthList", 400 ["tn":"12155551212"], 401 "Q_s3MWoqT05TrdkM2MTDcw"] 402 } 404 8. Large number of Non-contiguous TNAuthList values 406 There are many scenarios and reasons to have various combinations of 407 SPCs, TNs, and TN Ranges. [RFC8226] has provided a somewhat 408 unbounded set of combinations. It's possible that a complex non- 409 contiguous set of telephone numbers are being managed by a CSP. Best 410 practice may be simply to split a set of non-contiguous numbers under 411 management into multiple STI certificates to represent the various 412 contiguous parts of the greater non-contiguous set of TNs, 413 particularly if length of the set of values in identifier object 414 grows to be too large. 416 9. Security Considerations 418 TBD 420 10. Acknowledgements 422 We would like to thank you for your review of this document. 424 11. References 426 11.1. Normative References 428 [I-D.ietf-acme-acme] 429 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 430 Kasten, "Automatic Certificate Management Environment 431 (ACME)", draft-ietf-acme-acme-09 (work in progress), 432 December 2017. 434 [I-D.peterson-acme-authority-token] 435 Peterson, J., "ACME Challenges Using an Authority Token", 436 draft-peterson-acme-authority-token-00 (work in progress), 437 October 2017. 439 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 440 Telephone Identity Problem Statement and Requirements", 441 RFC 7340, DOI 10.17487/RFC7340, September 2014, 442 . 444 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 445 "Authenticated Identity Management in the Session 446 Initiation Protocol (SIP)", RFC 8224, 447 DOI 10.17487/RFC8224, February 2018, 448 . 450 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 451 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 452 . 454 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 455 Credentials: Certificates", RFC 8226, 456 DOI 10.17487/RFC8226, February 2018, 457 . 459 11.2. Informative References 461 [ATIS-1000074] 462 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 463 of Asserted information using toKENs (SHAKEN)", January 464 2017. 466 [ATIS-1000080] 467 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 468 of Asserted information using toKENs (SHAKEN) Governance 469 Model and Certificate Management", July 2017. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, 473 DOI 10.17487/RFC2119, March 1997, 474 . 476 Authors' Addresses 478 Chris Wendt 479 Comcast 480 One Comcast Center 481 Philadelphia, PA 19103 482 USA 484 Email: chris-ietf@chriswendt.net 486 David Hancock 487 Comcast 489 Email: davidhancock.ietf@gmail.com 491 Mary Barnes 492 iconectiv 494 Email: mary.ietf.barnes@gmail.com 496 Jon Peterson 497 Neustar Inc. 498 1800 Sutter St Suite 570 499 Concord, CA 94520 500 US 502 Email: jon.peterson@neustar.biz