idnits 2.17.1 draft-ietf-acme-ip-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 24 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 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 (September 18, 2017) is 2405 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7230' is defined on line 285, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-07 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACME Working Group R. Shoemaker 3 Internet-Draft ISRG 4 Intended status: Standards Track September 18, 2017 5 Expires: March 22, 2018 7 ACME IP Identifier Validation Extension 8 draft-ietf-acme-ip-01 10 Abstract 12 This document specifies identifiers and challenges required to enable 13 the Automated Certificate Management Environment (ACME) to issue 14 certificates for IP addresses. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 22, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. IP Identifier . . . . . . . . . . . . . . . . . . . . . . . . 2 53 4. Identifier Validation Challenges . . . . . . . . . . . . . . 3 54 4.1. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . 3 55 4.2. Existing Challenges . . . . . . . . . . . . . . . . . . . 5 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 5.1. Identifier Types . . . . . . . . . . . . . . . . . . . . 5 58 5.2. Challenge Types . . . . . . . . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 6.1. Certificate Lifetime . . . . . . . . . . . . . . . . . . 5 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 The Automatic Certificate Management Environment (ACME) 68 [I-D.ietf-acme-acme] only defines challenges for validating control 69 of DNS host name identifiers which limits its use to being used for 70 issuing certificates for these identifiers. In order to allow 71 validation of IPv4 and IPv6 identifiers for inclusion in X.509 72 certificates this document defines a new challenge type and specifies 73 how challenges defined in the original ACME specification can be used 74 to validate IP identifiers. 76 2. Terminology 78 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 79 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 80 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 81 [RFC2119]. 83 3. IP Identifier 85 ACME only defines the identifier type "dns" which is used to refer to 86 fully qualified domain names. If a ACME server wishes to request 87 proof that a user controls a IPv4 or IPv6 address it MUST create an 88 authorization with the identifier type "ip". The value field of the 89 identifier MUST contain the textual form of the address as defined in 90 RFC 1123 [RFC1123] Section 2.1 for IPv4 and in RFC 4291 [RFC4291] 91 Section 2.2 for IPv6. 93 An identifier for the IPv6 address 2001:db8::1 would be formatted 94 like so: 96 {"type": "ip", "value": "2001:db8::1"} 98 4. Identifier Validation Challenges 100 When creating an authorization for a identifier with the type "ip" 101 the following challenge types MAY be used to perform validation. 103 4.1. Reverse DNS 105 With Reverse DNS validation the client proves control of an IP 106 address by provisioning a TXT resource record containing a designated 107 value for a specific validation domain name constructed using the 108 value of the PTR record for the reverse mapping of the address. 110 type (required, string): The string "reverse-dns-01". 112 token (required, string): A random value that uniquely identifies 113 the challenge. This value MUST have at least 128 bits of entropy, 114 in order to prevent an attacker from guessing it. It MUST NOT 115 contain any characters outside the base64url [RFC4648] alphabet, 116 including padding characters ("="). 118 GET /acme/authz/1234/2 HTTP/1.1 119 Host: example.com 121 HTTP/1.1 200 OK 122 { 123 "type": "reverse-dns-01", 124 "url": "https://example.com/acme/authz/1234/2", 125 "status": "pending", 126 "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA" 127 } 129 A client responds to this challenge by constructing a key 130 authorization from the "token" value provided in the challenge and 131 the client's ACME account key. The client then computes the SHA-256 132 digest [FIPS180-4] of the key authorization. The record provisioned 133 to the authoritative DNS server is the base64url encoding of this 134 digest. 136 The client constructs the validation domain name by prepending the 137 label "_acme-challenge" to the domain name referenced in the PTR 138 resource record for the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] 139 reverse mapping of the IP address. The client then provisions a TXT 140 record with the digest for this name. 142 For example, if the IP address being validated is 2001:db8::1 and its 143 IP6.ARPA mapping had the following PTR record: 145 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 300 IN PTR example.com 147 then the client would provision the following DNS record: 149 _acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM" 151 The response to the Reverse DNS challenge provides the computed key 152 authorization to acknowledge that the client is ready to fulfill this 153 challenge. 155 keyAuthorization (required, string): The key authorization for this 156 challenge. 158 POST /acme/authz/1234/2 159 Host: example.com 160 Content-Type: application/jose+json 162 { 163 "protected": base64url({ 164 "alg": "ES256", 165 "kid": "https://example.com/acme/acct/1", 166 "nonce": "JHb54aT_KTXBWQOzGYkt9A", 167 "url": "https://example.com/acme/authz/1234/2" 168 }), 169 "payload": base64url({ 170 "keyAuthorization": "evaGxfADs...62jcerQ" 171 }), 172 "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4" 173 } 175 On receiving a response, the server MUST verify that the key 176 authorization in the response matches the "token" value in the 177 challenge and the client's ACME account key. If they do not match, 178 then the server MUST return an HTTP error in response to the POST 179 request in which the client sent the challenge. 181 To validate a DNS challenge, the server performs the following steps: 183 1. Compute the SHA-256 digest of the key authorization 185 2. Query for a PTR record for the IP identifier's relevant reverse 186 mapping based on its version 188 3. Query for TXT records for the computed validation domain name 190 4. Verify that the contents of one of the TXT records matches the 191 digest value 193 If all of the above verifications succeed, then the validation is 194 successful. If no PTR or TXT DNS records are found, or the returned 195 TXT records do not contain the expected key authorization digest, 196 then the validation fails. 198 4.2. Existing Challenges 200 IP identifiers MAY be used with the existing "http-01" and "tls-sni- 201 02" challenges from draft-ietf-acme-acme Sections 8.3 and 8.4 202 respectively. To use IP identifiers with these challenges their 203 initial DNS resolution step MUST be skipped and the address used for 204 validation MUST be the value of the identifier. For the "http-01" 205 challenge the Host header should be set to the IP address being used 206 for validation per RFC 7230. 208 The existing "dns-01" challenge MUST NOT be used to validate IP 209 identifiers. 211 5. IANA Considerations 213 5.1. Identifier Types 215 Adds a new type to the Identifier list defined in Section 9.7.5 of 216 draft-ietf-acme-acme with the label "ip" and reference draft-ietf- 217 acme-ip. 219 5.2. Challenge Types 221 Adds a new type to the Challenge list defined in Section 9.7.6 of 222 draft-ietf-acme-acme with the label "reverse-dns-01", identifier type 223 "ip", and reference draft-ietf-acme-ip. 225 Add the value "ip" to the identifier type column for the "http-01" 226 and "tls-sni-02" challenges. 228 6. Security Considerations 230 6.1. Certificate Lifetime 232 Given the often short delegation periods for IP addresses provided by 233 various service providers CAs MAY want to impose shorter lifetimes 234 for certificates which contain IP identifiers. They MAY also impose 235 restrictions on IP identifiers which are in CIDRs known to be 236 assigned to service providers who dynamically assign addresses to 237 users for indeterminate periods of time. 239 7. Acknowledgments 241 The author would like to thank those who contributed to this document 242 and offered editorial advice, especially: Jacob Hoffman-Andrews and 243 Daniel McCarney. 245 8. Normative References 247 [FIPS180-4] 248 Department of Commerce, National., "NIST FIPS 180-4, 249 Secure Hash Standard", March 2012, 250 . 253 [I-D.ietf-acme-acme] 254 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 255 Certificate Management Environment (ACME)", draft-ietf- 256 acme-acme-07 (work in progress), June 2017. 258 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 259 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 260 . 262 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 263 Application and Support", STD 3, RFC 1123, 264 DOI 10.17487/RFC1123, October 1989, . 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, 269 DOI 10.17487/RFC2119, March 1997, . 272 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 273 "DNS Extensions to Support IP Version 6", STD 88, 274 RFC 3596, DOI 10.17487/RFC3596, October 2003, 275 . 277 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 278 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 279 2006, . 281 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 282 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 283 . 285 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 286 Protocol (HTTP/1.1): Message Syntax and Routing", 287 RFC 7230, DOI 10.17487/RFC7230, June 2014, 288 . 290 Author's Address 292 Roland Bracewell Shoemaker 293 Internet Security Research Group 295 Email: roland@letsencrypt.org