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