idnits 2.17.1 draft-ietf-acme-authority-token-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 22, 2018) is 2006 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-acme-service-provider' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-acme-star' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-stir-passport' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-stir-rfc4474bis' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 439, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-16 == Outdated reference: A later version (-13) exists of draft-ietf-acme-authority-token-tnauthlist-00 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-04 Summary: 0 errors (**), 0 flaws (~~), 10 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: April 25, 2019 iconectiv 6 D. Hancock 7 C. Wendt 8 Comcast 9 October 22, 2018 11 ACME Challenges Using an Authority Token 12 draft-ietf-acme-authority-token-01.txt 14 Abstract 16 A number of proposed challenges for the Automated Certificate 17 Management Environment (ACME) effectively rely on an external 18 authority issuing a token according to a particular policy. This 19 document specifies a generic Authority Token challenge for ACME which 20 supports subtype claims for different identifiers or namespaces that 21 can be defined separately for specific applications of this Authority 22 Token challenge. 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 April 25, 2019. 41 Copyright Notice 43 Copyright (c) 2018 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. Registration . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. 'ATC' Token Type . . . . . . . . . . . . . . . . . . . . 7 66 5. Acquiring a Token . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 9. Informative References . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 ACME [I-D.ietf-acme-acme] is a mechanism for automating certificate 77 management on the Internet. It enables administrative entities to 78 prove effective control over resources like domain names, and 79 automates the 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 [I-D.ietf-stir-certificates] by consulting an external 97 authority responsible for those codes. Furthermore, Communications 98 Service Providers (CSPs) can delegate authority over numbers to their 99 customers, and those CSPs who support ACME can then help customers to 100 acquire certificates for those numbering resources with ACME. This 101 can permit number acquisition flows compatible with those shown in 102 [I-D.ietf-modern-problem-framework]. Another, similar example would 103 a mechanism that permits CSPs to delegate authority for particular 104 telephone numbers to customers, as described in 105 [I-D.ietf-acme-telephone]. 107 2. Terminology 109 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 110 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 111 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 112 described in [RFC2119]. 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. There has 119 been considerable interest in using ACME to issue certificates 120 associated with telephone numbers and service provider identifiers 121 used in the telephone network, for example. Provided that the issuer 122 of identifiers in a namespace, or someone acting on the issuer's 123 behalf, can implement a service that grants Authority Tokens to the 124 people to whom it has issued identifiers, a generic token could be 125 used as a response to an ACME challenge. This specification, 126 therefore, defines an Authority Token issued by authority over a 127 namespace to an ACME client for delivery to a CA in response to a 128 challenge. Authority over a hierarchical namespace can also be 129 delegated, so that delegates of a root authority can themselves act 130 as Token Authorities for certain types of names. 132 This architecture assumes a trust relationship between CAs and Token 133 Authorities: that CAs are willing to accept the attestation of Token 134 Authorities for particular types of identifiers as sufficient proof 135 to issue a credential. It furthermore assumes that ACME clients have 136 a relationship with Token Authorities which permits them to 137 authenticate and authorize the issuance of Authority Tokens to the 138 proper entities. This ACME challenge has no applicability to 139 identifiers or authorities where those pre-associations cannot be 140 assumed. 142 ACME challenges that support Authority Tokens therefore need to 143 specify the type of token they require; CAs can even provide a hint 144 in their challenges to ACME clients that tells them how to find a 145 Token Authority who can issue tokens for a given namespace. This 146 challenge type thus requires a new "tkauth-type" element, and may 147 optionally supply a "token-authority" designating a location where 148 tokens can be acquired. The set of "tkauth-type" values and the 149 semantic requirements for those tokens are tracked by an IANA 150 registry. 152 3.1. Token Type Requirements 154 The IANA will control a registry of tkauth-types under a policy of 155 Specification Required. In order to register a new tkauth-type, 156 specifications must address the following requirements. 158 While Authority Token types do not need to be specific to a 159 namespace, every token must carry enough information for a CA to 160 determine the name that it will issue a certificate for. Some types 161 of Authority Token types might be reusable for a number of different 162 namespaces; other might be specific to a particular type of name. 163 Therefore, in defining tkauth-types, future specifications must 164 indicate how a token conveys to the CA the name that the Token 165 Authority is attesting that the ACME client controls. 167 In most cases, an ACME client will need a protocol to request and 168 retrieve an Authority Token. The Token Authority will require 169 certain information from an ACME client in order to ascertain that it 170 is the right entity to request a certificate for a particular name. 171 The protocols used to request an Authority Token MUST convey to the 172 Token Authority the identifier type and value from the ACME 173 challenge, as well as the binding (see Section 3.3), and those MUST 174 be reflected in the Authority Token. A baseline mechanism for how 175 the Token Authority authenticates and authorizes ACME clients to 176 receive Authority Tokens is given in Section 5. 178 Because the assignment of resources can change over time, 179 demonstrations of authority must be regularly refreshed. Definitions 180 of a tkauth-type MUST specify how they manage the freshness of 181 authority assignments. Typically, a CA will expect a regular 182 refreshing of the token. 184 3.2. Authority Token Scope 186 An Authority Token is used to answer a challenge from an ACME server, 187 upon a request for the issuance of a certificate. A Token Authority 188 could grant to a client a Token that has the exact same scope as the 189 requested certificate; alternatively, an Authority Token could attest 190 to all of the resources that the client is eligible to receive 191 certificates for, which could be a superset of the scope of the 192 requested certificate. 194 For example, imagine a case where an Authority for DNS names knows 195 that a client is eligible to receive certificates for "example.com" 196 and "example.net". The client asks an ACME server for a certificate 197 for "example.com", the server directs the client to acquire an 198 Authority Token from the Authority. When the client sends an 199 acquisition request (see Section 5) to the Authority, the Authority 200 could issue a token scoped just to "example.com", or a token that 201 attests the client is eligible to receive certificates for both 202 "example.com" or "example.net". The advantage of the latter is that 203 if, at a later time (but one within the expiry of the JWT), the 204 client wanted to acquire a certificate for "example.net", it would 205 not have to return to the Authority, as the Token effectively pre- 206 authorized the issuance of that certificate. 208 Applications of the Authority Token to different identifier types 209 might require different scopes, so registrations of tkauth-types 210 should be clear if and how a scope greater than that of the requested 211 certificate would be conveyed in a token. 213 3.3. Binding Challenges 215 Applications that use the Authority Token need a way to correlate 216 tokens issued by an Authority with the proper ACME client, to prevent 217 replay or cut-and-paste attacks using a token issued for a different 218 purpose. To mitigate this, Authority Tokens contain a binding signed 219 by an Authority; an ACME server can use the binding to determine that 220 a Token presented by a client was in fact granted by the Authority 221 based on a request from the client, and not from some other entity. 223 Binding an Authority Token to a particular ACME account entails that 224 the Token could be reused up until its expiry for multiple challenges 225 issued by an ACME server. This might be a desirable property when 226 using short-lived certificates, for example, or in any cases where 227 the ACME server issues challenges more frequently that an Authority 228 Token can or should issue tokens, or in cases where the Authority 229 Token scope (see Section 3.2) is broad, so certificates with a more 230 narrow scope may periodically be issued. 232 For some identifier types, it may be more appropriate to bind the 233 Authority Token to a nonce specific to the challenge rather than to 234 an ACME account fingerprint. Any specification of the use of the 235 nonce for this purpose is left to the identifier type profile for the 236 Authority Token. 238 4. Registration 240 This draft registers a tkauth-type of "ATC", for the Authority Token 241 Challenge, a JWT usage which is further documented below. Taking the 242 identifier example of TNAuthList from 243 [I-D.ietf-acme-authority-token-tnauthlist], an ACME for this tkauth- 244 type challenge might for example look as follows: 246 HTTP/1.1 200 OK 247 Content-Type: application/json 248 Link: ;rel="directory" 250 { 251 "status": "pending", 253 "identifier": { 254 "type": "TNAuthList", 255 "value": "F83n2a...avn27DN3==" 256 }, 257 "challenges": [ 258 { 259 "type": "tkauth-01", 260 "tkauth-type": "ATC", 261 "token-authority": "https://authority.example.org/authz", 262 "url": "https://boulder.example.com/authz/asdf/0" 263 "token": "IlirfxKKXAsHtmzK29Pj8A" } 264 ], 265 } 267 Entities receiving this challenge know that they can, as a proof, 268 acquire an ATC token from the designated Token Authority (specified 269 in the "token-authority" field), and that this authority can provide 270 tokens corresponding to the identifier type of "TNAuthList". 272 Once the ATC has been acquired by the ACME Client, it can be posted 273 back to the URL given by the ACME challenge. 275 POST /acme/authz/asdf/0 HTTP/1.1 276 Host: boulder.example.com 277 Content-Type: application/jose+json 279 { 280 "protected": base64url({ 281 "alg": "ES256", 282 "kid": "https://boulder.example.com/acme/reg/asdf", 283 "nonce": "Q_s3MWoqT05TrdkM2MTDcw", 284 "url": "https://boulder.example.com/acme/authz/asdf/0" 285 }), 286 "payload": base64url({ 287 "ATC": "evaGxfADs...62jcerQ" 288 }), 289 "signature": "5wUrDI3eAaV4wl2Rfj3aC0Pp--XB3t4YYuNgacv_D3U" 290 } 292 The "ATC" field in this response contains the Authority Token. 294 4.1. 'ATC' Token Type 296 This specification pre-populates the tkauth-type registry with a type 297 for "ATC". 299 Here the "ATC" tkauth-type signifies a standard JWT token [RFC7519] 300 using a JWS-defined signature string [RFC7515]. This may be used for 301 any number of different identifier types given in ACME challenges. 302 The "atc" element (defined below) lists the identifier type used by 303 tokens based on ATC. The use of "ATC" is restricted to JWTs, if non- 304 JWT tokens were desired for ACME challenges, a different tkauth-type 305 should be defined for them. 307 For this ACME Authority Token usage of JWT, the payload of the JWT 308 OPTIONALLY contain an "iss" indicating the Token Authority that 309 generated the token, if the "x5u" element in the header does not 310 already convey that information; typically, this will be the same 311 location that appeared in the "token-authority" field of the ACME 312 challenge. In order to satisfy the requirement for replay prevention 313 the JWT MUST contain a "jti" element, and an "exp" claim. In 314 addition to helping to manage replay, the "jti" provides a convenient 315 way to reliably track with the same "ATC" Authority Token is being 316 used for multiple challenges over time within its set expiry. 318 The JWT payload must also contain a new JWT claim, "atc", for 319 Authority Token Challenge, which contains three elements in an array: 320 the identifier type, the identifier value, and the binding. The 321 identifier type and value are those given in the ACME challenge and 322 conveyed to the Token Authority by the ACME client. Again, following 323 the example of [I-D.ietf-acme-authority-token-tnauthlist], this could 324 be the TNAuthList, as defined in [RFC8226], that the Token Authority 325 is attesting. Practically speaking, that may contain a list of 326 Service Provider Code elements, telephone number range elements, and/ 327 or individual telephone numbers. For the purposes of the "ATC" 328 tkauth-type, the binding is assumed to be a fingerprint of the ACME 329 credential for the account used to request the certificate, but the 330 specification of how the binding is generated is left to the 331 identifier type profile for the Authority Token. 333 So for example: 335 { "typ":"JWT", 336 "alg":"ES256", 337 "x5u":"https://authority.example.org/cert"} 338 { 339 "iss":"https://authority.example.org/authz", 340 "exp":1300819380, 341 "jti":"id6098364921", 342 "atc":{"TnAuthList","F83n2a...avn27DN3==", 343 "SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: 344 9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} } 346 5. Acquiring a Token 348 [TBD. Show protocol flow for token acquisition.] 350 5.1. Example 352 [TBD.] 354 6. Acknowledgements 356 We would like to thank you for your contributions to this problem 357 statement and framework. 359 7. IANA Considerations 361 Future versions of this specification will include registrations for 362 the ACME Challenge type registries here. It will also create a 363 registry for "token types" as used in these challenges, following the 364 requirements in Section 3.1, pre-populated with the value for "ATC" 365 per Section 4.1. 367 8. Security Considerations 369 The capture of Authority Tokens by an adversary could enable an 370 attacker to acquire a certificate from a CA. Therefore, all 371 Authority Tokens MUST contain a field that identifies to the CA which 372 ACME client requested the token from the authority; here that is the 373 fingerprint specified in Section 4.1). All Authority Tokens must 374 specify an expiry (of the token itself as proof for a CA, as opposed 375 to the expiry of the name), and for some application, it may make 376 sense of that expiry to be quite short. Any protocol used to 377 retrieve Authority Tokens from an authority MUST use confidentiality 378 to prevent eavesdroppers from acquiring an Authority Token. 380 More TBD. 382 9. Informative References 384 [I-D.ietf-acme-acme] 385 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 386 Kasten, "Automatic Certificate Management Environment 387 (ACME)", draft-ietf-acme-acme-16 (work in progress), 388 October 2018. 390 [I-D.ietf-acme-authority-token-tnauthlist] 391 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 392 "TNAuthList profile of ACME Authority Token", draft-ietf- 393 acme-authority-token-tnauthlist-00 (work in progress), 394 July 2018. 396 [I-D.ietf-acme-service-provider] 397 Barnes, M. and C. Wendt, "ACME Identifiers and Challenges 398 for VoIP Service Providers", draft-ietf-acme-service- 399 provider-02 (work in progress), October 2017. 401 [I-D.ietf-acme-star] 402 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 403 Fossati, "Support for Short-Term, Automatically-Renewed 404 (STAR) Certificates in Automated Certificate Management 405 Environment (ACME)", draft-ietf-acme-star-04 (work in 406 progress), October 2018. 408 [I-D.ietf-acme-telephone] 409 Peterson, J. and R. Barnes, "ACME Identifiers and 410 Challenges for Telephone Numbers", draft-ietf-acme- 411 telephone-01 (work in progress), October 2017. 413 [I-D.ietf-modern-problem-framework] 414 Peterson, J. and T. McGarry, "Modern Problem Statement, 415 Use Cases, and Framework", draft-ietf-modern-problem- 416 framework-04 (work in progress), March 2018. 418 [I-D.ietf-stir-certificates] 419 Peterson, J. and S. Turner, "Secure Telephone Identity 420 Credentials: Certificates", draft-ietf-stir- 421 certificates-18 (work in progress), December 2017. 423 [I-D.ietf-stir-passport] 424 Wendt, C. and J. Peterson, "Personal Assertion Token 425 (PASSporT)", draft-ietf-stir-passport-11 (work in 426 progress), February 2017. 428 [I-D.ietf-stir-rfc4474bis] 429 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 430 "Authenticated Identity Management in the Session 431 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 432 (work in progress), February 2017. 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, 436 DOI 10.17487/RFC2119, March 1997, 437 . 439 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 440 Telephone Identity Problem Statement and Requirements", 441 RFC 7340, DOI 10.17487/RFC7340, September 2014, 442 . 444 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 445 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 446 2015, . 448 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 449 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 450 . 452 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 453 Credentials: Certificates", RFC 8226, 454 DOI 10.17487/RFC8226, February 2018, 455 . 457 Authors' Addresses 459 Jon Peterson 460 Neustar, Inc. 461 1800 Sutter St Suite 570 462 Concord, CA 94520 463 US 465 Email: jon.peterson@team.neustar 467 Mary Barnes 468 iconectiv 470 Email: mary.ietf.barnes@gmail.com 472 David Hancock 473 Comcast 475 Email: davidhancock.ietf@gmail.com 477 Chris Wendt 478 Comcast 479 One Comcast Center 480 Philadelphia, PA 19103 481 USA 483 Email: chris-ietf@chriswendt.net