idnits 2.17.1 draft-ietf-acme-authority-token-tnauthlist-04.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 (September 30, 2019) is 1670 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) == Unused Reference: 'ATIS-1000074' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC8588' is defined on line 576, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-acme-authority-token-03 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Downref: Normative reference to an Informational RFC: RFC 7340 Summary: 3 errors (**), 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: Standards Track Comcast 5 Expires: April 2, 2020 M. Barnes 6 iconectiv 7 J. Peterson 8 Neustar Inc. 9 September 30, 2019 11 TNAuthList profile of ACME Authority Token 12 draft-ietf-acme-authority-token-tnauthlist-04 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 April 2, 2020. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . 10 69 7. Usage Considerations . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Large number of Non-contiguous TNAuthList values . . . . 11 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 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 will also incorporate the ability for a telephone 114 authority to authorize the creation of CA types of certificates for 115 delegation as defined in [I-D.peterson-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":"F83n2a...avn27DN3=="}], 164 "notBefore": "2016-01-01T00:00:00Z", 165 "notAfter": "2016-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": "2016-01-01T00:00:00Z", 187 "notAfter": "2016-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 mechanism 245 defined in [I-D.ietf-acme-authority-token] to verify that the 246 requesting ACME client has authenticated and authorized control over 247 the requested resources represented by the "TNAuthList" value. 249 The challenge "token-authority" parameter is optional and only used 250 in cases where the VoIP telephone network requires the CA to identify 251 the Token Authority. This is currently not the case for the SHAKEN 252 [ATIS-1000080] certificate framework governance, but may be used by 253 other frameworks. If a "token-authority" parameter is present, then 254 the ACME client MAY use the "token-authority" value to identify the 255 URL representing the Token Authority that will provide the TNAuthList 256 Authority Token response to the challenge. If the "token-authority" 257 parameter is not present, then the ACME client MUST identify the 258 Token Authority based on locally configured information or local 259 policies. 261 The ACME client MUST respond to the challenge by posting the 262 TNAuthList Authority Token to the challenge URL identified in the 263 returned ACME authorization object, an example of which follows. 265 POST /acme/authz/asdf/0 HTTP/1.1 266 Host: boulder.example.com 267 Content-Type: application/jose+json 269 { 270 "protected": base64url({ 271 "alg": "ES256", 272 "kid": "https://example.com/acme/acct/1", 273 "nonce": "Q_s3MWoqT05TrdkM2MTDcw", 274 "url": "https://boulder.example.com/acme/authz/asdf/0" 275 }), 276 "payload": base64url({ 277 "atc": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE" 278 }), 279 "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" 280 } 282 The specifics of the construction of the TNAuthList specific "atc" 283 token is defined in the next section. 285 5. TNAuthList Authority Token 287 The Telephone Number Authority List Authority Token (TNAuthList 288 Authority Token) is an extension of the ACME Authority Token defined 289 in [I-D.ietf-acme-authority-token]. 291 The TNAuthList Authority Token Protected header MUST comply with the 292 Authority Token Protected header as defined in 293 [I-D.ietf-acme-authority-token]. 295 The TNAuthList Authority Token Payload MUST include the mandatory 296 claims and MAY include the optional claims defined for the Authority 297 Token detailed in the next subsections. 299 5.1. "iss" claim 301 The "iss" claim is an optional claim. It can be used as a URL 302 identifying the Token Authority that issued the TNAuthList Authority 303 Token beyond the "x5u" Header claim that identifies the location of 304 the certificate of the Token Authority used to validate the 305 TNAuthList Authority Token. 307 5.2. "exp" claim 309 The "exp" claim contains the DateTime value of the ending date and 310 time that the TNAuthList Authority Token expires. 312 5.3. "jti" claim 314 The "jti" claim contains a unique identifier for this TNAuthList 315 Authority Token transaction. 317 5.4. "atc" claim 319 The "atc" claim is the only claim specifically defined in this 320 document. It contains a JSON object of three elements. 322 o a "tktype" key that is required with a string value equal to 323 "TNAuthList" to represent a TNAuthList profile of the authority 324 token [I-D.ietf-acme-authority-token] defined by this document. 326 o a "tkvalue" key with a string value equal to the TNAuthList 327 identifier "value" string which MUST contain the base64 encoding 328 of the TN Authorization List certificate extension ASN.1 object. 329 "tkvalue" is a required key and MUST be included. 331 o a "ca" key with a boolean value set to either true when the 332 requested certificate is allowed to be a CA cert for delegation 333 uses or false when the requested certificate MUST NOT be a CA cert 334 and only an end-entity certificate. "ca" is an optional key. 336 o a "fingerprint" key with a fingerprint value equal to the 337 fingerprint, as defined in [RFC4949], of the ACME account 338 credentials. Specifically, the fingerprint value is a secure one- 339 way hash of the Distinguished Encoding Rules (DER) form of the 340 public key corresponding to the key pair the SP used to create the 341 account with the ACME server. The fingerprint value consists of 342 the name of the hash function, which shall be 'SHA256' for this 343 specification, followed by the hash value itself. The hash value 344 is represented as a sequence of uppercase hexadecimal bytes, 345 separated by colons. The number of bytes is defined by the hash 346 function. "fingerprint" is a required key and MUST be included. 348 An example of the TNAuthList Authority Token is as follows, 349 { "typ":"JWT", 350 "alg":"ES256", 351 "x5u":https://authority.example.org/cert 352 } 354 { "iss":"https://authority.example.org/authz", 355 "exp":1300819380, 356 "jti":"id6098364921", 357 "atc":{"tktype":"TNAuthList", 358 "tkvalue":"F83n2a...avn27DN3==", 359 "ca":false, 360 "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71: 361 D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} 362 } 364 5.5. Acquiring the token from the Token Authority 366 Following [I-D.ietf-acme-authority-token] Section 5, the authority 367 token should be acquired using a RESTful HTTP POST transaction as 368 follows 370 POST /at/account/:id/token HTTP/1.1 371 Host: authority.example.com 372 Content-Type: application/json 374 The request will pass the account id as a string in the request 375 parameter "id". This string will be managed as an identifier 376 specific to the authorities relationship with a CSP. There is 377 assumed to also be a corresponding authentication procedure that can 378 be verified for the success of this transaction. For example, an 379 HTTP authorization header containing a valid authorization 380 credentials as defined in [RFC2616] Section 14.8. 382 The body of the POST request MUST contain the "atc" JSON object that 383 should be embedded in the token that is requested, for example the 384 body should contain a JSON object as shown: 386 { 387 "atc":{"tktype":"TNAuthList", 388 "tkvalue":"F83n2a...avn27DN3==", 389 "ca":false, 390 "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3 \ 391 :BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} 392 } 394 The response to the POST request if successful MUST return a 200 OK 395 with a JSON body that contains the TNAuthList Authority Token as a 396 JSON object with a single key of "atc" and the base64 encoded string 397 representing the atc token. 399 An example successful response would be as follows: 401 HTTP/1.1 200 OK 402 Content-Type: application/json 404 {"atc": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"} 406 If the request is not successful, the response should indicate the 407 error condition. Specifically, for the case that the authorization 408 credentials are invalid, the response code MUST be 403 - Forbidden. 409 If the Account ID provided does not exist or does not match 410 credentials in Authorization header, the response MUST be 404 - 411 Invalid account ID. Other 4xx and 5xx responses SHOULD follow 412 standard [RFC2616] HTTP error condition conventions. 414 5.6. Token Authority Responsibilities 416 When the Token Authority creates the TNAuthList Authority Token, it 417 is the responsibility of the Token Authority to validate that the 418 information contained in the ASN.1 TNAuthList accurately represents 419 the SPC or telephone number resources the ACME client is authorized 420 to represent. 422 5.7. Scope of the TNAuthList token authority 424 Because this specification specifically involves the TNAuthList 425 defined in [RFC8226] which involves SPC, TNBlock, and individual TNs, 426 the client may also request an Authority Token with some subset of 427 its own authority the TNAuthList provided in the "tkvalue" element in 428 the "atc" JSON object. Generally, the scope of authority of 429 telephone numbers is that a communications service provider which is 430 represented by a particular SPC (e.g. OCN or SPID) is associated 431 with a particular set of different TN Blocks and/or TNs, although 432 more often the former. TNAuthList can be constructed to define a 433 limited scope of the TNBlocks or TNs either associated with an SPC or 434 with the scope of TN Blocks or TNs the client has authority over. 436 6. Validating the TNAuthList Authority Token 438 Upon receiving a response to the challenge, the ACME server MUST 439 perform the following steps to determine the validity of the 440 response. 442 o Verify that the token contained in the Payload "atc" field is an 443 TNAuthList Authority Token. 445 o Verify the TNAuthList Authority Token signature using the public 446 key of the certificate referenced by the token's "x5u" parameter. 448 o Verify that "atc" claim contains an identifier type of 449 "TNAuthList", 451 o Verify that the "atc" claim contains the equivalent base64 encoded 452 TNAuthList certificate extension string value as the Identifier 453 specified in the original challenge. 455 o Verify that the remaining claims are valid (e.g., verify that 456 token has not expired) 458 o Verify that the "atc" claim "fingerprint" is valid 460 o Verify that the "ca" claim boolean corresponds to the CSR request 461 for either CA certificate or end-entity certificate 463 If all steps in the token validation process pass, then the CA MUST 464 set the challenge object "status" to "valid". If any step of the 465 validation process fails, the "status" in the challenge object MUST 466 be set to "invalid". 468 7. Usage Considerations 470 7.1. Large number of Non-contiguous TNAuthList values 472 There are many scenarios and reasons to have various combinations of 473 SPCs, TNs, and TN Ranges. [RFC8226] has provided a somewhat 474 unbounded set of combinations. It's possible that a complex non- 475 contiguous set of telephone numbers are being managed by a CSP. Best 476 practice may be simply to split a set of non-contiguous numbers under 477 management into multiple STI certificates to represent the various 478 contiguous parts of the greater non-contiguous set of TNs, 479 particularly if length of the set of values in identifier object 480 grows to be too large. 482 8. Security Considerations 484 TBD 486 9. IANA Considerations 488 This document requests the addition of a new identifier object type 489 that can be present in the identifier field of the ACME authorization 490 object defined in [RFC8555]. 492 +------------+-----------+ 493 | Label | Reference | 494 +------------+-----------+ 495 | TNAuthList | RFCThis | 496 +------------+-----------+ 498 10. Acknowledgements 500 We would like to thank Richard Barnes and Russ Housley for valuable 501 contributions to this document. 503 11. References 505 11.1. Normative References 507 [I-D.ietf-acme-authority-token] 508 Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME 509 Challenges Using an Authority Token", draft-ietf-acme- 510 authority-token-03 (work in progress), March 2019. 512 [I-D.peterson-stir-cert-delegation] 513 Peterson, J., "STIR Certificate Delegation", draft- 514 peterson-stir-cert-delegation-00 (work in progress), March 515 2019. 517 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 518 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 519 Transfer Protocol -- HTTP/1.1", RFC 2616, 520 DOI 10.17487/RFC2616, June 1999, 521 . 523 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 524 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 525 . 527 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 528 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 529 . 531 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 532 Telephone Identity Problem Statement and Requirements", 533 RFC 7340, DOI 10.17487/RFC7340, September 2014, 534 . 536 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 537 "Authenticated Identity Management in the Session 538 Initiation Protocol (SIP)", RFC 8224, 539 DOI 10.17487/RFC8224, February 2018, 540 . 542 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 543 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 544 . 546 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 547 Credentials: Certificates", RFC 8226, 548 DOI 10.17487/RFC8226, February 2018, 549 . 551 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 552 Kasten, "Automatic Certificate Management Environment 553 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 554 . 556 11.2. Informative References 558 [ATIS-1000074] 559 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 560 of Asserted information using toKENs (SHAKEN) 561 ", January 2017. 564 [ATIS-1000080] 565 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 566 of Asserted information using toKENs (SHAKEN) Governance 567 Model and Certificate Management 568 ", July 2017. 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, 573 DOI 10.17487/RFC2119, March 1997, 574 . 576 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 577 (PaSSporT) Extension for Signature-based Handling of 578 Asserted information using toKENs (SHAKEN)", RFC 8588, 579 DOI 10.17487/RFC8588, May 2019, 580 . 582 Authors' Addresses 584 Chris Wendt 585 Comcast 586 One Comcast Center 587 Philadelphia, PA 19103 588 USA 590 Email: chris-ietf@chriswendt.net 592 David Hancock 593 Comcast 595 Email: davidhancock.ietf@gmail.com 597 Mary Barnes 598 iconectiv 600 Email: mary.ietf.barnes@gmail.com 602 Jon Peterson 603 Neustar Inc. 604 1800 Sutter St Suite 570 605 Concord, CA 94520 606 US 608 Email: jon.peterson@neustar.biz