idnits 2.17.1 draft-ietf-acme-authority-token-05.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1506 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCThis' is mentioned on line 425, but not defined == Unused Reference: 'I-D.ietf-acme-service-provider' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-acme-star' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC8224' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC8225' is defined on line 500, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-acme-authority-token-tnauthlist-05 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar 4 Intended status: Informational M. Barnes 5 Expires: September 10, 2020 Independent 6 D. Hancock 7 C. Wendt 8 Comcast 9 March 9, 2020 11 ACME Challenges Using an Authority Token 12 draft-ietf-acme-authority-token-05 14 Abstract 16 Some proposed extensions to the Automated Certificate Management 17 Environment (ACME) rely on proving eligibility for certificates 18 through consulting an external authority that issues a token 19 according to a particular policy. This document specifies a generic 20 Authority Token challenge for ACME which supports subtype claims for 21 different identifiers or namespaces that can be defined separately 22 for specific applications. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Challenges for an Authority Token . . . . . . . . . . . . . . 3 61 3.1. Token Type Requirements . . . . . . . . . . . . . . . . . 4 62 3.2. Authority Token Scope . . . . . . . . . . . . . . . . . . 4 63 3.3. Binding Challenges . . . . . . . . . . . . . . . . . . . 5 64 4. ATC tkauth-type Registration . . . . . . . . . . . . . . . . 6 65 5. Acquiring a Token . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Basic REST Interface . . . . . . . . . . . . . . . . . . 7 67 6. Using an Authority Token in a Challenge . . . . . . . . . . . 8 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 ACME [RFC8555] is a mechanism for automating certificate management 77 on the Internet. It enables administrative entities to prove 78 effective control over resources like domain names, and automates the 79 process of generating and issuing certificates. 81 In some cases, proving effective control over an identifier requires 82 an attestation from a third party who has authority over the 83 resource, for example, an external policy administrator for a 84 namespace other than the DNS application ACME was originally designed 85 to support. In order to automate the process of issuing certificates 86 for those resources, this specification defines a generic Authority 87 Token challenge that ACME servers can issue in order to require 88 clients to return such a token. The challenge contains a type 89 indication that tells the client what sort of token it needs to 90 acquire. It is expected that the Authority Token challenge will be 91 usable for a variety of identifier types. 93 For example, the system of [I-D.ietf-acme-authority-token-tnauthlist] 94 provides a mechanism that allows service providers to acquire 95 certificates corresponding to a Service Provider Code (SPC) as 96 defined in [RFC8226] by consulting an external authority responsible 97 for those codes. Furthermore, Communications Service Providers 98 (CSPs) can delegate authority over numbers to their customers, and 99 those CSPs who support ACME can then help customers to acquire 100 certificates for those numbering resources with ACME. This can 101 permit number acquisition flows compatible with those shown in 102 [RFC8396]. Another, similar example would a mechanism that permits 103 CSPs to delegate authority for particular telephone numbers to 104 customers, as described in [I-D.ietf-acme-telephone]. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Challenges for an Authority Token 116 Proving that a device on the Internet has effective control over a 117 non-Internet resource is not as straightforward as proving control 118 over an Internet resources like a DNS zone or a web page. Provided 119 that the issuer of identifiers in a namespace, or someone acting on 120 the issuer's behalf, can implement a service that grants Authority 121 Tokens to the people to whom it has issued identifiers, a generic 122 token could be used as a response to an ACME challenge. This 123 specification, therefore, defines an Authority Token issued by an 124 authority over a namespace to an ACME client for delivery to a CA in 125 response to a challenge. Authority over a hierarchical namespace can 126 also be delegated, so that delegates of a root authority can 127 themselves act as Token Authorities for certain types of names. 129 This architecture assumes a trust relationship between CAs and Token 130 Authorities: that CAs are willing to accept the attestation of Token 131 Authorities for particular types of identifiers as sufficient proof 132 to issue a credential. It furthermore assumes that ACME clients have 133 a relationship with Token Authorities which permits them to 134 authenticate and authorize the issuance of Authority Tokens to the 135 proper entities. This ACME challenge has no applicability to 136 identifiers or authorities where those pre-associations cannot be 137 assumed. 139 ACME challenges that support Authority Tokens therefore need to 140 specify the type of token they require; CAs can even provide a hint 141 in their challenges to ACME clients that tells them how to find a 142 Token Authority who can issue tokens for a given namespace. This 143 challenge type thus requires a new "tkauth-type" element, and may 144 optionally supply a "token-authority" designating a location where 145 tokens can be acquired. The set of "tkauth-type" values and the 146 semantic requirements for those tokens are tracked by an IANA 147 registry. 149 3.1. Token Type Requirements 151 The IANA will maintain a registry of tkauth-types under a policy of 152 Specification Required. In order to register a new tkauth-type, 153 specifications must address the following requirements. 155 While Authority Token types do not need to be specific to a 156 namespace, every token must carry enough information for a CA to 157 determine the name that it will issue a certificate for. Some types 158 of Authority Token types might be reusable for a number of different 159 namespaces; other might be specific to a particular type of name. 160 Therefore, in defining tkauth-types, future specifications must 161 indicate how a token conveys to the CA the name(s) that the Token 162 Authority is attesting that the ACME client controls. 164 While nothing precludes use cases where an ACME client is itself a 165 Token Authority, an ACME client will typically need a protocol to 166 request and retrieve an Authority Token. The Token Authority will 167 require certain information from an ACME client in order to ascertain 168 that it is the right entity to request a certificate for a particular 169 name. The protocols used to request an Authority Token MUST convey 170 to the Token Authority the identifier type and value from the ACME 171 challenge, as well as the binding (see Section 3.3), and those MUST 172 be reflected in the Authority Token. A baseline mechanism for how 173 the Token Authority authenticates and authorizes ACME clients to 174 receive Authority Tokens is given in Section 5. 176 Because the assignment of resources can change over time, 177 demonstrations of authority must be regularly refreshed. Definitions 178 of a tkauth-type MUST specify how they manage the freshness of 179 authority assignments. Typically, a CA will expect a regular 180 refreshing of the token. 182 3.2. Authority Token Scope 184 An Authority Token is used to answer a challenge from an ACME server, 185 upon a request for the issuance of a certificate. It could be that 186 the AT is requested from the Token Authority after a challenge has 187 been received, or it could be that the AT was acquired prior to the 188 initial ACME client request. A Token Authority could grant to a 189 client a Token that has the exact same scope as the requested 190 certificate; alternatively, an Authority Token could attest to all of 191 the resources that the client is eligible to receive certificates 192 for, which could be a superset of the scope of the requested 193 certificate. 195 For example, imagine a case where an Authority for DNS names knows 196 that a client is eligible to receive certificates for "example.com" 197 and "example.net". The client asks an ACME server for a certificate 198 for "example.com", the server directs the client to acquire an 199 Authority Token from the Authority. When the client sends an 200 acquisition request (see Section 5) to the Authority, the Authority 201 could issue a token scoped just to "example.com", or a token that 202 attests the client is eligible to receive certificates for both 203 "example.com" or "example.net". The advantage of the latter is that 204 if, at a later time (but one within the expiry of the JWT), the 205 client wanted to acquire a certificate for "example.net", it would 206 not have to return to the Authority, as the Token effectively pre- 207 authorized the issuance of that certificate. 209 Applications of the Authority Token to different identifier types 210 might require different scopes, so registrations of tkauth-types 211 should be clear if and how a scope greater than that of the requested 212 certificate would be conveyed in a token. 214 3.3. Binding Challenges 216 Applications that use the Authority Token need a way to correlate 217 tokens issued by an Authority with the proper ACME client, to prevent 218 replay or cut-and-paste attacks using a token issued for a different 219 purpose. To mitigate this, Authority Tokens contain a binding signed 220 by an Authority; an ACME server can use the binding to determine that 221 a Token presented by a client was in fact granted by the Authority 222 based on a request from the client, and not from some other entity. 224 Binding an Authority Token to a particular ACME account entails that 225 the Token could be reused up until its expiry for multiple challenges 226 issued by an ACME server. This might be a desirable property when 227 using short-lived certificates, for example, or in any cases where 228 the ACME server issues challenges more frequently that an Authority 229 Token can or should issue tokens, or in cases where the Authority 230 Token scope (see Section 3.2) is broad, so certificates with a more 231 narrow scope may periodically be issued. 233 For some identifier types, it may be more appropriate to bind the 234 Authority Token to a nonce specific to the challenge rather than to 235 an ACME account fingerprint. Any specification of the use of the 236 nonce for this purpose is left to the identifier type profile for the 237 Authority Token. 239 4. ATC tkauth-type Registration 241 This draft registers a tkauth-type of "atc", for the Authority Token 242 Challenge. Here the "atc" tkauth-type signifies a standard JWT token 243 [RFC7519] using a JWS-defined signature string [RFC7515]. This may 244 be used for any number of different identifier types given in ACME 245 challenges. The "atc" element (defined below) lists the identifier 246 type used by tokens based on ATC. The use of "atc" is restricted to 247 JWTs, if non-JWT tokens were desired for ACME challenges, a different 248 tkauth-type should be defined for them. 250 For this ACME Authority Token usage of JWT, the payload of the JWT 251 OPTIONALLY contain an "iss" indicating the Token Authority that 252 generated the token, if the "x5u" element in the header does not 253 already convey that information; typically, this will be the same 254 location that appeared in the "token-authority" field of the ACME 255 challenge. In order to satisfy the requirement for replay prevention 256 the JWT MUST contain a "jti" element, and an "exp" claim. In 257 addition to helping to manage replay, the "jti" provides a convenient 258 way to reliably track with the same "atc" Authority Token is being 259 used for multiple challenges over time within its set expiry. 261 The JWT payload must also contain a new JWT claim, "atc", for 262 Authority Token Challenge, which contains three mandatory elements in 263 an array: the identifier type ("tktype"), the identifier value 264 ("tkvalue"), and the binding ("fingerprint"). The identifier type 265 and value are those given in the ACME challenge and conveyed to the 266 Token Authority by the ACME client. Following the example of 267 [I-D.ietf-acme-authority-token-tnauthlist], the "tkvalue" identifier 268 type could be the TNAuthList, with a "tkvalue" as defined in 269 [RFC8226] that the Token Authority is attesting. Practically 270 speaking, that scope may comprise a list of Service Provider Code 271 elements, telephone number range elements, and/or individual 272 telephone numbers. For the purposes of the "atc" tkauth-type, the 273 binding "fingerprint" is assumed to be a fingerprint of the ACME 274 credential for the account used to request the certificate, but the 275 specification of how the binding is generated is left to the 276 identifier type profile for the Authority Token. 278 So for example: 280 { "typ":"JWT", 281 "alg":"ES256", 282 "x5u":"https://authority.example.org/cert"} 283 { 284 "iss":"https://authority.example.org/authz", 285 "exp":1300819380, 286 "jti":"id6098364921", 287 "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","fingerprint": 288 "SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: 289 9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} } 291 Optionally, the "atc" element may contain a fourth element, "ca". If 292 set to "true", the "ca" element indicates that the Token Authority is 293 granting permission to issue a certification authority certificate 294 rather than an end-entity certificate for the names in question. 295 This permits subordinate delegations from the issued certificate. If 296 the "ca" element is absent, the Token Authority is explicitly 297 withholding permission. The "atc" object in the example above would 298 then look like: 300 "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","ca":true, 301 "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: 302 9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} } 304 Specifications of "tktype" identifier type may define additional 305 optional "atc" elements. 307 5. Acquiring a Token 309 The acquisition of a Authority Token requires a network interface, 310 apart from potential use cases where the entity that acts as an ACME 311 client itself also acts as a Token Authority trusted by the ACME 312 server. Implementations compliant with this specification MUST 313 support an HTTPS REST interface for Authority Token acquisition as 314 described below, though other interfaces MAY be supported as well. 316 5.1. Basic REST Interface 318 In order to request an Authority Token from a Token Authority, a 319 client sends an HTTPS POST request. Different services may organize 320 their web resources in domain-specific ways, but the resource locator 321 should specify the account of the client, an identifier for the 322 service provider, and finally a locator for the token. 324 POST /at/account/:id/token HTTP/1.1 325 Host: authority.example.com 326 Content-Type: application/json 328 The body of the POST request will contain the ATC element that the 329 client is requesting the Token Authority generate. 331 { 332 "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==", 333 "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: 334 9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} } 335 } 337 In common use cases, the "tkvalue" in this request is asking that the 338 Token Authority issue a token that attests the entire scope of 339 authority to which the client is entitled. The client may also 340 request an AT with some subset of its own authority via the "tkvalue" 341 element in the ATC object. The way that "tkvalue" is defined will 342 necessarily be specific to the identifier type. For the TNAuthlist 343 identifier type, for example, an object requesting an AT could 344 request authority for only a single telephone number in a way that is 345 defined in the TNAuthList specification. 347 Finally, the JSON object may also contain a optional boolean element 348 "ca" which signifies that the client is requesting that the Token 349 Authority issue an AT with the "ca" flag set, as described in 350 Section 4. 352 After an HTTPS-level challenge to verify the identity of the client 353 and subsequently making an authorization decision, in the success 354 case the Token Authority returns a 200 OK with a body of type 355 "application/json" containing the Authority Token. 357 6. Using an Authority Token in a Challenge 359 Taking the identifier example of TNAuthList from 360 [I-D.ietf-acme-authority-token-tnauthlist], an ACME for this tkauth- 361 type challenge might for example look as follows: 363 HTTP/1.1 200 OK 364 Content-Type: application/json 365 Link: ;rel="directory" 367 { 368 "status": "pending", 370 "identifier": { 371 "type": "TNAuthList", 372 "value": "F83n2a...avn27DN3==" 373 }, 374 "challenges": [ 375 { 376 "type": "tkauth-01", 377 "tkauth-type": "atc", 378 "token-authority": "https://authority.example.org/authz", 379 "url": "https://boulder.example.com/authz/asdf/0" 380 "token": "IlirfxKKXAsHtmzK29Pj8A" } 381 ], 382 } 384 Entities receiving this challenge know that they can, as a proof, 385 acquire an ATC token from the designated Token Authority (specified 386 in the "token-authority" field), and that this authority can provide 387 tokens corresponding to the identifier type of "TNAuthList". 389 Once the ATC has been acquired by the ACME Client, it can be posted 390 back to the URL given by the ACME challenge. 392 POST /acme/authz/asdf/0 HTTP/1.1 393 Host: boulder.example.com 394 Content-Type: application/jose+json 396 { 397 "protected": base64url({ 398 "alg": "ES256", 399 "kid": "https://boulder.example.com/acme/reg/asdf", 400 "nonce": "Q_s3MWoqT05TrdkM2MTDcw", 401 "url": "https://boulder.example.com/acme/authz/asdf/0" 402 }), 403 "payload": base64url({ 404 "atc": "evaGxfADs...62jcerQ" 405 }), 406 "signature": "5wUrDI3eAaV4wl2Rfj3aC0Pp--XB3t4YYuNgacv_D3U" 407 } 409 The "atc" field in this response contains the Authority Token. 411 7. Acknowledgements 413 We would like to thank you for your contributions to this problem 414 statement and framework. 416 8. IANA Considerations 418 This document requests that the IANA registers a new ACME identifier 419 type (per [RFC8555]) for the label "atc", for which the reference is 420 [RFCThis]. 422 This document further requests that the IANA create a registry for 423 "token types" as used in these challenges, following the requirements 424 in Section 3.1, pre-populated with the label of "atc" per Section 4 425 with a value of [RFCThis]. 427 9. Security Considerations 429 Per the guidance in [RFC8555], ACME transactions MUST use TLS, and 430 similarly the HTTPS REST transactions used to request and acquire 431 authority tokens MUST use TLS. These measures are intended to 432 prevent the capture of Authority Tokens by eavesdroppers. The 433 security considerations of [RFC8555] apply to the use of the 434 mechanism in this specification. 436 The capture of Authority Tokens by an adversary could enable an 437 attacker to acquire a certificate from a CA. Therefore, all 438 Authority Tokens MUST contain a field that identifies to the CA which 439 ACME client requested the token from the authority; here that is the 440 fingerprint specified in Section 4). All Authority Tokens must 441 specify an expiry (of the token itself as proof for a CA, as opposed 442 to the expiry of the name), and for some application, it may make 443 sense of that expiry to be quite short. Any protocol used to 444 retrieve Authority Tokens from an authority MUST use confidentiality 445 to prevent eavesdroppers from acquiring an Authority Token. 447 10. Normative References 449 [I-D.ietf-acme-authority-token-tnauthlist] 450 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 451 "TNAuthList profile of ACME Authority Token", draft-ietf- 452 acme-authority-token-tnauthlist-05 (work in progress), 453 November 2019. 455 [I-D.ietf-acme-service-provider] 456 Barnes, M. and C. Wendt, "ACME Identifiers and Challenges 457 for VoIP Service Providers", draft-ietf-acme-service- 458 provider-02 (work in progress), October 2017. 460 [I-D.ietf-acme-star] 461 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 462 Fossati, "Support for Short-Term, Automatically-Renewed 463 (STAR) Certificates in Automated Certificate Management 464 Environment (ACME)", draft-ietf-acme-star-11 (work in 465 progress), October 2019. 467 [I-D.ietf-acme-telephone] 468 Peterson, J. and R. Barnes, "ACME Identifiers and 469 Challenges for Telephone Numbers", draft-ietf-acme- 470 telephone-01 (work in progress), October 2017. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 478 Telephone Identity Problem Statement and Requirements", 479 RFC 7340, DOI 10.17487/RFC7340, September 2014, 480 . 482 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 483 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 484 2015, . 486 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 487 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 488 . 490 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 491 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 492 May 2017, . 494 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 495 "Authenticated Identity Management in the Session 496 Initiation Protocol (SIP)", RFC 8224, 497 DOI 10.17487/RFC8224, February 2018, 498 . 500 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 501 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 502 . 504 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 505 Credentials: Certificates", RFC 8226, 506 DOI 10.17487/RFC8226, February 2018, 507 . 509 [RFC8396] Peterson, J. and T. McGarry, "Managing, Ordering, 510 Distributing, Exposing, and Registering Telephone Numbers 511 (MODERN): Problem Statement, Use Cases, and Framework", 512 RFC 8396, DOI 10.17487/RFC8396, July 2018, 513 . 515 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 516 Kasten, "Automatic Certificate Management Environment 517 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 518 . 520 Authors' Addresses 522 Jon Peterson 523 Neustar, Inc. 524 1800 Sutter St Suite 570 525 Concord, CA 94520 526 US 528 Email: jon.peterson@team.neustar 530 Mary Barnes 531 Independent 533 Email: mary.ietf.barnes@gmail.com 535 David Hancock 536 Comcast 538 Email: davidhancock.ietf@gmail.com 540 Chris Wendt 541 Comcast 542 One Comcast Center 543 Philadelphia, PA 19103 544 USA 546 Email: chris-ietf@chriswendt.net