idnits 2.17.1 draft-peterson-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 (March 5, 2018) is 2242 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-acme-star' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-stir-passport' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-stir-rfc4474bis' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'I-D.rescorla-stir-fallback' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 356, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-09 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-03 == Outdated reference: A later version (-04) exists of draft-ietf-modern-problem-framework-03 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: September 6, 2018 iconectiv 6 D. Hancock 7 C. Wendt 8 Comcast 9 March 5, 2018 11 ACME Challenges Using an Authority Token 12 draft-peterson-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 different identifiers or namespaces that can 21 be defined to represent a specific application 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 September 6, 2018. 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 . . . . . . . . . . . . . . . . . 5 62 3.2. Authority Token Type for ATC . . . . . . . . . . . . . . 6 63 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. Informative References . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 ACME [I-D.ietf-acme-acme] is a mechanism for automating certificate 72 management on the Internet. It enables administrative entities to 73 prove effective control over resources like domain names, and 74 automates the process of generating and issuing certificates. 76 In some cases, proving effective control over an identifier requires 77 an attestation from a third party who has authority over the 78 resource, for example, an external policy administrator for a 79 namespace other than the DNS application ACME was originally designed 80 to support. In order to automate the process of issuing certificates 81 for those resources, this specification defines a generic Authority 82 Token challenge that ACME servers can issue in order to acquire such 83 a token. The challenge contains a type indication that tells the 84 client what sort of token it needs to acquire. It is expected that 85 the Authority Token challenge will be usable for a variety of 86 identifier types. 88 For example, the system of [I-D.ietf-acme-service-provider] provides 89 a mechanism that allows service providers to acquire certificates 90 corresponding to a Service Provider Code (SPC) as defined in 91 [I-D.ietf-stir-certificates] by consulting an external authority 92 responsible for those codes. Furthermore, Communications Service 93 Providers (CSPs) can delegate authority over numbers to their 94 customers, and those CSPs who support ACME can then help customers to 95 acquire certificates for those numbering resources with ACME. This 96 can permit number acquisition flows compatible with those shown in 98 [I-D.ietf-modern-problem-framework]. Another, similar example would 99 a mechanism that permits CSPs to delegate authority for particular 100 telephone numbers to customers, as described in 101 [I-D.ietf-acme-telephone]. 103 2. Terminology 105 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 106 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 107 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 108 described in [RFC2119]. 110 3. Challenges for an Authority Token 112 Proving that a device on the Internet has effective control over a 113 non-Internet resource is not as straightforward as proving control 114 over an Internet resources like a DNS zone or a web page. There has 115 been considerable interest in using ACME to issue certificates 116 associated with telephone numbers and service provider identifiers 117 used in the telephone network, for example. Provided that the issuer 118 of identifiers in a namespace, or someone acting on the issuer's 119 behalf, can implement a service that grants Authority Tokens to the 120 people to whom it has issued identifiers, a generic token could be 121 used as a response to an ACME challenge. This specification, 122 therefore, defines an Authority Token issued by authority over a 123 namespace to an ACME client for delivery to a CA in response to a 124 challenge. Authority over a hierarchical namespace can also be 125 delegated, so that delegates of a root authority can themselves act 126 as Token Authorities for certain types of names. 128 This architecture assumes a trust relationship between CAs and Token 129 Authorities: that CAs are willing to accept the attestation of Token 130 Authorities for particular types of identifiers as sufficient proof 131 to issue a credential. It furthermore assumes that ACME clients have 132 a relationship with Token Authorities which permits them to 133 authenticate and authorize the issuance of Authority Tokens to the 134 proper entities. This ACME challenge has no applicability to 135 identifiers or authorities where those pre-associations cannot be 136 assumed. 138 ACME challenges that support Authority Tokens therefore need to 139 specify the type of tkauth token they require; CAs can even provide a 140 hint in their challenges to ACME clients that tells them how to find 141 a Token Authority who can issue tokens for a given namespace. This 142 challenge type thus requires a new "tkauth-type" element, and may 143 optionally supply a "token-authority" designating a location where 144 tokens can be acquired. The set of "tkauth-type" values and the 145 semantic requirements for those tokens are tracked by an IANA 146 registry. Here we as an example we use a token type of "ATC", for 147 the Authority Token Challenge, which is further documented below. 148 Taking the identifier example of TNAuthList from 149 [I-D.ietf-acme-service-provider], a challenge might look as follows: 151 HTTP/1.1 200 OK 152 Content-Type: application/json 153 Link: ;rel="directory" 155 { 156 "status": "pending", 158 "identifier": { 159 "type": "TNAuthList", 160 "value": ["1234"] 161 }, 162 "challenges": [ 163 { 164 "type": "tkauth-01", 165 "tkauth-type": "ATC", 166 "token-authority": "https://authority.example.org/authz", 167 "url": "https://boulder.example.com/authz/asdf/0" 168 "token": "IlirfxKKXAsHtmzK29Pj8A" } 169 ], 170 } 172 Entities receiving this challenge know that they can as a proof 173 acquire a ATC token from the designated token authority, and that 174 this authority can provide tokens corresponding the identifier type 175 of "TNAuthList". Once the ATC has been acquired by the ACME Client, 176 it can be posted back to the URL given by the ACME challenge. 178 POST /acme/authz/asdf/0 HTTP/1.1 179 Host: boulder.example.com 180 Content-Type: application/jose+json 182 { 183 "protected": base64url({ 184 "alg": "ES256", 185 "kid": "https://boulder.example.com/acme/reg/asdf", 186 "nonce": "Q_s3MWoqT05TrdkM2MTDcw", 187 "url": "https://boulder.example.com/acme/authz/asdf/0" 188 }), 189 "payload": base64url({ 190 "ATC": "evaGxfADs...62jcerQ" 191 }), 192 "signature": "5wUrDI3eAaV4wl2Rfj3aC0Pp--XB3t4YYuNgacv_D3U" 193 } 195 The "ATC" field in this response contains the Authority Token. 197 3.1. Token Type Requirements 199 The IANA will control a registry of token-types under a policy of 200 Specification Required. In order to register a new token-type, 201 specifications must meet the following requirements. 203 While Authority Token types do not need to be specific to a 204 namespace, every token must carry enough information for a CA to 205 determine the name that it will issue a certificate for. Some types 206 of Authority Tokens might be reusable for a number of different 207 namespaces; other authority tokens might be specific to a particular 208 type of name. Therefore, in defining token-types, future 209 specifications must indicate how a token conveys to the CA the name 210 that the Token Authority is attesting that the ACME client controls. 212 In most cases, an ACME client will need a protocol to request and 213 retrieve an Authority Token. The Token Authority will require 214 certain information from an ACME client in order to ascertain that it 215 is the right entity to request a certificate for a particular name. 216 The protocols used to request an Authority Token MUST convey to the 217 Token Authority the identifier type and value from the ACME 218 challenge, as well as the nonce, and those MUST be reflected in the 219 Authority Token. Exactly how the Token Authority authenticates and 220 authorizes ACME clients to receive Authority Tokens is out of the 221 scope of this document. 223 Because the assignment of resources can change over time, 224 demonstrations of authority must be regularly refreshed. Definitions 225 of a token-type MUST specify how they manage the freshness of 226 authority assignments. Typically, a CA will expect a regular 227 refreshing of the token. 229 3.2. Authority Token Type for ATC 231 This specification pre-populates the token-type registry with a 232 token-type for "ATC". 234 Here the "ATC" token-type signifies a standard JWT token [RFC7519] 235 using a JWS-defined signature string [RFC7515]. This may be used for 236 any number of different identifier types given in ACME challenges. 238 For this ACME Authority Token usage of JWT, the payload of the JWT 239 OPTIONALLY contain an "iss" indicating the Token Authority that 240 generated the token, if the "x5u" element in the header does not 241 already convey that information; typically, this will be the same 242 location that appeared in the "token-authority" field of the ACME 243 challenge. In order to satisfy the requirement for replay prevention 244 the JWT MUST contain a "jti" element, and an "exp" claim. 246 The JWT payload must also contain a new JWT claim, "atc", for 247 Authority Token Challenge, which contains three elements in an array: 248 the identifier type, the identifier value, and the nonce. The 249 identifier type and value are those given in the ACME challenge and 250 conveyed to the Token Authority by the ACME client. Again, following 251 the example of [I-D.ietf-acme-service-provider], this could be the 252 TNAuthList, as defined in [RFC8226], that the Token Authority is 253 attesting. Practically speaking, that may contain a list of Service 254 Provider Code elements, telephone number range elements, and/or 255 individual telephone numbers. The nonce is taken from the original 256 Replay-Nonce header field of the ACME challenge. 258 So for example: 260 { "typ":"JWT", 261 "alg":"ES256", 262 "x5u":"https://authority.example.org/cert"} 263 { 264 "iss":"https://authority.example.org/authz", 265 "exp":1300819380, 266 "jti":"id6098364921", 267 "atc":{"TnAuthList","1234","Q_s3MWoqT05TrdkM2MTDcw"} } 269 [More TBD. Need to add how the JWT reflects that the resource is 270 delegatable. Need to show the request to the Token Authority as 271 well.] 273 4. Acknowledgments 275 We would like to thank you for your contributions to this problem 276 statement and framework. 278 5. IANA Considerations 280 Future versions of this specification will include registrations for 281 the ACME Challenge type registries here. It will also create a 282 registry for "token types" as used in these challenges. 284 6. Security Considerations 286 The capture of Authority Tokens by an adversary could enable an 287 attacker to acquire a certificate from a CA. Therefore, all 288 Authority Tokens MUST contain a field that identifies to the CA which 289 ACME client requested the token from the authority. All Authority 290 Tokens must specify an expiry (of the token itself as proof for a CA, 291 as opposed to the expiry of the name), and for some application, it 292 may make sense of that expiry to be quite short. Authority Tokens 293 must also contain a nonce that will enable a CA to detect a replayed 294 Authority Token. Any protocol used to retrieve Authority Tokens from 295 an authority MUST use confidentiality to prevent eavesdroppers from 296 acquiring an Authority Token. 298 More TBD. 300 7. Informative References 302 [I-D.ietf-acme-acme] 303 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 304 Kasten, "Automatic Certificate Management Environment 305 (ACME)", draft-ietf-acme-acme-09 (work in progress), 306 December 2017. 308 [I-D.ietf-acme-service-provider] 309 Barnes, M. and C. Wendt, "ACME Identifiers and Challenges 310 for VoIP Service Providers", draft-ietf-acme-service- 311 provider-02 (work in progress), October 2017. 313 [I-D.ietf-acme-star] 314 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 315 Fossati, "Support for Short-Term, Automatically-Renewed 316 (STAR) Certificates in Automated Certificate Management 317 Environment (ACME)", draft-ietf-acme-star-03 (work in 318 progress), March 2018. 320 [I-D.ietf-acme-telephone] 321 Peterson, J. and R. Barnes, "ACME Identifiers and 322 Challenges for Telephone Numbers", draft-ietf-acme- 323 telephone-01 (work in progress), October 2017. 325 [I-D.ietf-modern-problem-framework] 326 Peterson, J. and T. McGarry, "Modern Problem Statement, 327 Use Cases, and Framework", draft-ietf-modern-problem- 328 framework-03 (work in progress), July 2017. 330 [I-D.ietf-stir-certificates] 331 Peterson, J. and S. Turner, "Secure Telephone Identity 332 Credentials: Certificates", draft-ietf-stir- 333 certificates-18 (work in progress), December 2017. 335 [I-D.ietf-stir-passport] 336 Wendt, C. and J. Peterson, "Personal Assertion Token 337 (PASSporT)", draft-ietf-stir-passport-11 (work in 338 progress), February 2017. 340 [I-D.ietf-stir-rfc4474bis] 341 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 342 "Authenticated Identity Management in the Session 343 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 344 (work in progress), February 2017. 346 [I-D.rescorla-stir-fallback] 347 Rescorla, E. and J. Peterson, "STIR Out of Band 348 Architecture and Use Cases", draft-rescorla-stir- 349 fallback-02 (work in progress), June 2017. 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, 354 . 356 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 357 Telephone Identity Problem Statement and Requirements", 358 RFC 7340, DOI 10.17487/RFC7340, September 2014, 359 . 361 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 362 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 363 2015, . 365 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 366 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 367 . 369 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 370 Credentials: Certificates", RFC 8226, 371 DOI 10.17487/RFC8226, February 2018, 372 . 374 Authors' Addresses 376 Jon Peterson 377 Neustar, Inc. 378 1800 Sutter St Suite 570 379 Concord, CA 94520 380 US 382 Email: jon.peterson@team.neustar 384 Mary Barnes 385 iconectiv 387 Email: mary.ietf.barnes@gmail.com 389 David Hancock 390 Comcast 392 Email: davidhancock.ietf@gmail.com 394 Chris Wendt 395 Comcast 396 One Comcast Center 397 Philadelphia, PA 19103 398 USA 400 Email: chris-ietf@chriswendt.net