idnits 2.17.1 draft-ietf-acme-authority-token-tnauthlist-07.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 date (February 22, 2021) is 1159 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) == Outdated reference: A later version (-09) exists of draft-ietf-acme-authority-token-05 == Outdated reference: A later version (-04) exists of draft-ietf-stir-cert-delegation-03 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 3 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: Standards Track Comcast 5 Expires: August 26, 2021 M. Barnes 6 Independent 7 J. Peterson 8 Neustar Inc. 9 February 22, 2021 11 TNAuthList profile of ACME Authority Token 12 draft-ietf-acme-authority-token-tnauthlist-07 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 August 26, 2021. 39 Copyright Notice 41 Copyright (c) 2021 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 . . . . . . . . . . . . . 5 60 5. TNAuthList Authority Token . . . . . . . . . . . . . . . . . 7 61 5.1. "iss" claim . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.2. "exp" claim . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.3. "jti" claim . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.4. "atc" claim . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.5. Acquiring the token from the Token Authority . . . . . . 9 66 5.6. Token Authority Responsibilities . . . . . . . . . . . . 10 67 5.7. Scope of the TNAuthList token authority . . . . . . . . . 10 68 6. Validating the TNAuthList Authority Token . . . . . . . . . . 11 69 7. Usage Considerations . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Large number of Non-contiguous TNAuthList values . . . . 11 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 11.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 [RFC8555] is a mechanism for automating certificate management on the 82 Internet. It enables administrative entities to prove effective 83 control over resources like domain names, and automates the process 84 of generating and issuing certificates. 85 [I-D.ietf-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 Token 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 (SPCs), Telephone Numbers 105 (TNs), or Telephone Number ranges (TN ranges). Typically, these 106 identifiers have been assigned 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 to-CSP associations. 113 This document also describes the ability for a telephone authority to 114 authorize the creation of CA types of certificates for delegation as 115 defined in [I-D.ietf-stir-cert-delegation]. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. ACME new-order identifiers for TNAuthList 125 In [RFC8555], Section 7.4 defines the procedure that an ACME client 126 uses to order a new certificate from a Certification Authority. The 127 new-order request contains an identifier field that specifies the 128 identifier objects the order corresponds to. This draft defines a 129 new type of identifier object called TNAuthList. A TNAuthList 130 identifier contains the identity information to be populated in the 131 TN Authorization List of the new certificate. For the TNAuthList 132 identifier, the new-order request MUST include a type set to the 133 string "TNAuthList". The value of the TNAuthList identifier MUST be 134 set to the details of the TNAuthList requested. 136 The format of the string that represents the TNAuthList MUST be 137 constructed as a base64 [RFC4648] encoding of the TN Authorization 138 List certificate extension ASN.1 object. The TN Authorization List 139 certificate extension ASN.1 syntax is defined in [RFC8226] section 9. 141 An example of an ACME order object "identifiers" field containing a 142 TNAuthList certificate would look as follows, 144 "identifiers": [{"type":"TNAuthList","value":"F83n2a...avn27DN3=="}] 146 where the "value" object string represents the arbitrary length 147 base64 encoded string. 149 A full new-order request would look as follows, 151 POST /acme/new-order HTTP/1.1 152 Host: example.com 153 Content-Type: application/jose+json 155 { 156 "protected": base64url({ 157 "alg": "ES256", 158 "kid": "https://example.com/acme/acct/1", 159 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 160 "url": "https://example.com/acme/new-order" 161 }), 162 "payload": base64url({ 163 "identifiers": [{"type:"TNAuthList","value":"F83n...n27DN3=="}], 164 "notBefore": "2021-01-01T00:00:00Z", 165 "notAfter": "2021-01-08T00:00:00Z" 166 }), 167 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 168 } 170 On receiving a valid new-order request, the CA creates an 171 authorization object containing the challenge that the ACME client 172 must satisfy to demonstrate authority for the identifiers specified 173 by the new order (in this case, the TNAuthList identifier). The CA 174 adds the authorization object URL to the "authorizations" field of 175 the order object, and returns the order object to the ACME client in 176 the body of a 201 (Created) response. 178 HTTP/1.1 201 Created 179 Replay-Nonce: MYAuvOpaoIiywTezizk5vw 180 Location: https://example.com/acme/order/1234 182 { 183 "status": "pending", 184 "expires": "2015-03-01T14:09:00Z", 186 "notBefore": "2021-01-01T00:00:00Z", 187 "notAfter": "2021-01-08T00:00:00Z", 188 "identifiers":[{"type:"TNAuthList", 189 "value":"F83n2a...avn27DN3=="}], 191 "authorizations": [ 192 "https://example.com/acme/authz/1234" 193 ], 194 "finalize": "https://example.com/acme/order/1234/finalize" 195 } 197 4. TNAuthList Identifier Authorization 199 On receiving the new-order response, the ACME client queries the 200 referenced authorization object to obtain the challenges for the 201 identifier contained in the new-order request as shown in the 202 following example request and response. 204 POST /acme/authz/1234 HTTP/1.1 205 Host: example.com 206 Content-Type: application/jose+json 208 { 209 "protected": base64url({ 210 "alg": "ES256", 211 "kid": " https://example.com/acme/acct/1", 212 "nonce": "uQpSjlRb4vQVCjVYAyyUWg", 213 "url": "https://example.com/acme/authz/1234", 214 }), 215 "payload": "", 216 "signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps" 217 } 219 HTTP/1.1 200 OK 220 Content-Type: application/json 221 Link: ;rel="index" 223 { 224 "status": "pending", 225 "expires": "2018-03-03T14:09:00Z", 227 "identifier": { 228 "type:"TNAuthList", 229 "value":"F83n2a...avn27DN3==" 230 }, 232 "challenges": [ 233 { 234 "type": "tkauth-01", 235 "tkauth-type": "atc", 236 "token-authority": "https://authority.example.org/authz", 237 "url": "https://boulder.example.com/authz/asdf/0" 238 "token": "IlirfxKKXAsHtmzK29Pj8A" 239 } 240 ] 241 } 243 When processing a certificate order containing an identifier of type 244 "TNAuthList", a CA MUST use the Authority Token challenge type of 245 "tkauth-01" with a "tkauth-type" of "atc" in 246 [I-D.ietf-acme-authority-token] to verify that the requesting ACME 247 client has authenticated and authorized control over the requested 248 resources represented by the "TNAuthList" value. 250 The challenge "token-authority" parameter is optional and only used 251 in cases where the VoIP telephone network requires the CA to identify 252 the Token Authority. This is currently not the case for the SHAKEN 253 [ATIS-1000080] certificate framework governance, but may be used by 254 other frameworks. If a "token-authority" parameter is present, then 255 the ACME client MAY use the "token-authority" value to identify the 256 URL representing the Token Authority that will provide the TNAuthList 257 Authority Token response to the challenge. If the "token-authority" 258 parameter is not present, then the ACME client MUST identify the 259 Token Authority based on locally configured information or local 260 policies. 262 The ACME client MUST respond to the challenge by posting the 263 TNAuthList Authority Token to the challenge URL identified in the 264 returned ACME authorization object, an example of which follows. 266 POST /acme/authz/asdf/0 HTTP/1.1 267 Host: boulder.example.com 268 Content-Type: application/jose+json 270 { 271 "protected": base64url({ 272 "alg": "ES256", 273 "kid": "https://example.com/acme/acct/1", 274 "nonce": "Q_s3MWoqT05TrdkM2MTDcw", 275 "url": "https://boulder.example.com/acme/authz/asdf/0" 276 }), 277 "payload": base64url({ 278 "atc": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE" 279 }), 280 "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" 281 } 283 The specifics of the construction of the TNAuthList specific "atc" 284 token is defined in the next section. 286 5. TNAuthList Authority Token 288 The Telephone Number Authority List Authority Token (TNAuthList 289 Authority Token) is an extension of the ACME Authority Token defined 290 in [I-D.ietf-acme-authority-token]. 292 The TNAuthList Authority Token Protected header MUST comply with the 293 Authority Token Protected header as defined in 294 [I-D.ietf-acme-authority-token]. 296 The TNAuthList Authority Token Payload MUST include the mandatory 297 claims "exp", "jti", and "atc", and MAY include the optional claims 298 defined for the Authority Token detailed in the next subsections. 300 5.1. "iss" claim 302 The "iss" claim is an optional claim. It can be used as a URL 303 identifying the Token Authority that issued the TNAuthList Authority 304 Token beyond the "x5u" Header claim that identifies the location of 305 the certificate of the Token Authority used to validate the 306 TNAuthList Authority Token. 308 5.2. "exp" claim 310 The "exp" claim contains the DateTime value of the ending date and 311 time that the TNAuthList Authority Token expires. 313 5.3. "jti" claim 315 The "jti" claim contains a unique identifier for this TNAuthList 316 Authority Token transaction. 318 5.4. "atc" claim 320 The "atc" claim is the only claim specifically defined in this 321 document. It contains a JSON object of three elements. 323 o a "tktype" key that is required with a string value equal to 324 "TNAuthList" to represent a TNAuthList profile of the authority 325 token [I-D.ietf-acme-authority-token] defined by this document. 327 o a "tkvalue" key with a string value equal to the TNAuthList 328 identifier "value" string which MUST contain the base64 encoding 329 of the TN Authorization List certificate extension ASN.1 object. 330 "tkvalue" is a required key and MUST be included. 332 o a "ca" key with a boolean value set to either true when the 333 requested certificate is allowed to be a CA cert for delegation 334 uses or false when the requested certificate MUST NOT be a CA cert 335 and only an end-entity certificate. "ca" is an optional key, if it 336 not included the "ca" value is considered false by default. 338 o a "fingerprint" key with a fingerprint value equal to the 339 fingerprint, as defined in [RFC4949], of the ACME account 340 credentials. Specifically, the fingerprint value is a secure one- 341 way hash of the Distinguished Encoding Rules (DER) form of the 342 public key corresponding to the key pair the SP used to create the 343 account with the ACME server. The fingerprint value consists of 344 the name of the hash function, which shall be 'SHA256' for this 345 specification, followed by the hash value itself. The hash value 346 is represented as a sequence of uppercase hexadecimal bytes, 347 separated by colons. The number of bytes is defined by the hash 348 function. "fingerprint" is a required key and MUST be included. 350 An example of the TNAuthList Authority Token is as follows, 351 { 352 "protected": base64url({ 353 "typ":"JWT", 354 "alg":"ES256", 355 "x5u":https://authority.example.org/cert 356 }), 357 "payload": base64url({ 358 "iss":"https://authority.example.org/authz", 359 "exp":1300819380, 360 "jti":"id6098364921", 361 "atc":{"tktype":"TNAuthList", 362 "tkvalue":"F83n2a...avn27DN3==", 363 "ca":false, 364 "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71: 365 D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} 366 }), 367 "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" 368 } 370 5.5. Acquiring the token from the Token Authority 372 Following [I-D.ietf-acme-authority-token] Section 5, the authority 373 token should be acquired using a RESTful HTTP POST transaction as 374 follows 376 POST /at/account/:id/token HTTP/1.1 377 Host: authority.example.com 378 Content-Type: application/json 380 The request will pass the account id as a string in the request 381 parameter "id". This string will be managed as an identifier 382 specific to the Token Authority's relationship with a CSP. There is 383 assumed to also be a corresponding authentication procedure that can 384 be verified for the success of this transaction. For example, an 385 HTTP authorization header containing a valid authorization 386 credentials as defined in [RFC7231] Section 14.8. 388 The body of the POST request MUST contain the "atc" JSON object that 389 should be embedded in the token that is requested, for example the 390 body should contain a JSON object as shown: 392 { 393 "atc":{"tktype":"TNAuthList", 394 "tkvalue":"F83n2a...avn27DN3==", 395 "ca":false, 396 "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3 397 :BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} 398 } 400 The response to the POST request if successful MUST return a 200 OK 401 with a JSON body that contains, at a minimum, the TNAuthList 402 Authority Token as a JSON object with a key of "token" and the base64 403 encoded string representing the atc token. JSON is easily 404 extensible, so users of this specification may want to pass other 405 pieces of information relevant to a specific application, however, 406 the "token" key MUST be passed at a minimum. 408 An example successful response would be as follows: 410 HTTP/1.1 200 OK 411 Content-Type: application/json 413 {"token": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"} 415 If the request is not successful, the response should indicate the 416 error condition. Specifically, for the case that the authorization 417 credentials are invalid, the response code MUST be 403 - Forbidden. 418 If the Account ID provided does not exist or does not match 419 credentials in Authorization header, the response MUST be 404 - 420 Invalid account ID. Other 4xx and 5xx responses SHOULD follow 421 standard [RFC7231] HTTP error condition conventions. 423 5.6. Token Authority Responsibilities 425 When the Token Authority creates the TNAuthList Authority Token, it 426 is the responsibility of the Token Authority to validate that the 427 information contained in the ASN.1 TNAuthList accurately represents 428 the SPC or telephone number resources the ACME client is authorized 429 to represent. 431 5.7. Scope of the TNAuthList token authority 433 Because this specification specifically involves the TNAuthList 434 defined in [RFC8226] which involves SPC, TNBlock, and individual TNs, 435 the client may also request an Authority Token with some subset of 436 its own authority the TNAuthList provided in the "tkvalue" element in 437 the "atc" JSON object. Generally, the scope of authority 438 representing a communications service provider is represented by a 439 particular SPC (e.g. in North America, an OCN or SPID) which is 440 associated with a particular set of different TN Blocks and/or TNs, 441 although more often the former typically through a set of regulated 442 authoritative registries or databases. TNAuthList can be constructed 443 to define a limited scope of the TNBlocks or TNs either associated 444 with an SPC or with the scope of TN Blocks or TNs the client has 445 authority over. 447 6. Validating the TNAuthList Authority Token 449 Upon receiving a response to the challenge, the ACME server MUST 450 perform the following steps to determine the validity of the 451 response. 453 o Verify that the token contained in the Payload "atc" field is an 454 TNAuthList Authority Token. 456 o Verify the TNAuthList Authority Token signature using the public 457 key of the certificate referenced by the token's "x5u" parameter. 459 o Verify that "atc" claim contains an identifier type of 460 "TNAuthList". 462 o Verify that the "atc" claim contains the equivalent base64 encoded 463 TNAuthList certificate extension string value as the Identifier 464 specified in the original challenge. 466 o Verify that the remaining claims are valid (e.g., verify that 467 token has not expired) 469 o Verify that the "atc" claim "fingerprint" is valid 471 o Verify that the "ca" claim boolean corresponds to the CSR request 472 for either CA certificate or end-entity certificate 474 If all steps in the token validation process pass, then the CA MUST 475 set the challenge object "status" to "valid". If any step of the 476 validation process fails, the "status" in the challenge object MUST 477 be set to "invalid". 479 7. Usage Considerations 481 7.1. Large number of Non-contiguous TNAuthList values 483 There are many scenarios and reasons to have various combinations of 484 SPCs, TNs, and TN Ranges. [RFC8226] has provided a somewhat 485 unbounded set of combinations. It's possible that a complex non- 486 contiguous set of telephone numbers are being managed by a CSP. Best 487 practice may be simply to split a set of non-contiguous numbers under 488 management into multiple STI certificates to represent the various 489 contiguous parts of the greater non-contiguous set of TNs, 490 particularly if length of the set of values in identifier object 491 grows to be too large. 493 8. Security Considerations 495 The token represented by this document has the credentials to 496 represent the scope of a telephone number, a block of telephone 497 numbers, or an entire set of telephone numbers represented by a SPC. 498 The creation, transport, and any storage of this token MUST follow 499 the strictest of security best practices beyond the recommendations 500 of the use of encrypted transport protocols in this document to 501 protect it from getting in the hands of bad actors with illegitimate 502 intent to impersonate telephone numbers. 504 This document inherits the security properties of 505 [I-D.ietf-acme-authority-token]. 507 9. IANA Considerations 509 This document requests the addition of a new identifier object type 510 to the "ACME Identifier Types" registry defined in Section 9.7.7 of 511 [RFC8555]. 513 +------------+-----------+ 514 | Label | Reference | 515 +------------+-----------+ 516 | TNAuthList | RFCThis | 517 +------------+-----------+ 519 10. Acknowledgements 521 We would like to thank Richard Barnes and Russ Housley for valuable 522 contributions to this document. 524 11. References 526 11.1. Normative References 528 [I-D.ietf-acme-authority-token] 529 Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME 530 Challenges Using an Authority Token", draft-ietf-acme- 531 authority-token-05 (work in progress), March 2020. 533 [I-D.ietf-stir-cert-delegation] 534 Peterson, J., "STIR Certificate Delegation", draft-ietf- 535 stir-cert-delegation-03 (work in progress), July 2020. 537 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 538 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 539 . 541 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 542 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 543 DOI 10.17487/RFC7231, June 2014, 544 . 546 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 547 "Authenticated Identity Management in the Session 548 Initiation Protocol (SIP)", RFC 8224, 549 DOI 10.17487/RFC8224, February 2018, 550 . 552 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 553 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 554 . 556 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 557 Credentials: Certificates", RFC 8226, 558 DOI 10.17487/RFC8226, February 2018, 559 . 561 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 562 Kasten, "Automatic Certificate Management Environment 563 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 564 . 566 11.2. Informative References 568 [ATIS-1000080] 569 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 570 of Asserted information using toKENs (SHAKEN) Governance 571 Model and Certificate Management 572 ", July 2017. 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, 577 DOI 10.17487/RFC2119, March 1997, 578 . 580 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 581 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 582 . 584 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 585 Telephone Identity Problem Statement and Requirements", 586 RFC 7340, DOI 10.17487/RFC7340, September 2014, 587 . 589 Authors' Addresses 591 Chris Wendt 592 Comcast 593 One Comcast Center 594 Philadelphia, PA 19103 595 USA 597 Email: chris-ietf@chriswendt.net 599 David Hancock 600 Comcast 602 Email: davidhancock.ietf@gmail.com 604 Mary Barnes 605 Independent 607 Email: mary.ietf.barnes@gmail.com 609 Jon Peterson 610 Neustar Inc. 611 1800 Sutter St Suite 570 612 Concord, CA 94520 613 US 615 Email: jon.peterson@neustar.biz