idnits 2.17.1 draft-shoemaker-acme-ip-00.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 (March 27, 2017) is 2558 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Shoemaker 3 Internet-Draft ISRG 4 Intended status: Standards Track March 27, 2017 5 Expires: September 28, 2017 7 ACME IP Identifier Validation Extension 8 draft-shoemaker-acme-ip-00 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 September 28, 2017. 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. Normative References . . . . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The Automatic Certificate Management Environment (ACME) 67 [I-D.ietf-acme-acme] only defines challenges for validating control 68 of DNS host name identifiers which limits its use to being used for 69 issuing certificates for these identifiers. In order to allow 70 validation of IPv4 and IPv6 identifiers for inclusion in X.509 71 certificates this document defines a new challenge type and specifies 72 how challenges defined in the original ACME specification can be used 73 to validate IP identifiers. 75 2. Terminology 77 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 78 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 79 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 80 [RFC2119] and indicate requirement levels for compliant ACME-Wildcard 81 implementations. 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 identifiers 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 RFC XXXX Sections XXX and XXX respectively. To 202 use IP identifiers with these challenges their initial DNS resolution 203 step MUST be skipped and the address used for validation MUST be the 204 value of the identifier. 206 The existing "dns-01" challenge MUST NOT be used to validate IP 207 identifiers. 209 5. IANA Considerations 211 5.1. Identifier Types 213 Adds a new type to the Identifier list defined in Section XXX of RFC 214 XXXX with the label "ip" and reference RFC XXXX. 216 5.2. Challenge Types 218 Adds a new type to the Challenge list defined in Section XXX of RFC 219 XXXX with the label "reverse-dns-01", identifier type "ip", and 220 reference RFC XXXX. 222 Add the value "ip" to the identifier type column for the "http-01" 223 and "tls-sni-02" challenges. 225 6. Security Considerations 227 6.1. Certificate Lifetime 229 Given the often short delegation periods for IP addresses provided by 230 various service providers CAs MAY want to impose shorter lifetimes 231 for certificates which contain IP identifiers. They MAY also impose 232 restrictions on IP identifiers which are in CIDRs known to be 233 assigned to service providers who dynamically assign addresses to 234 users for indeterminate periods of time. 236 7. Normative References 238 [FIPS180-4] 239 Department of Commerce, National., "NIST FIPS 180-4, 240 Secure Hash Standard", March 2012, 241 . 244 [I-D.ietf-acme-acme] 245 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 246 Certificate Management Environment (ACME)", draft-ietf- 247 acme-acme-06 (work in progress), March 2017. 249 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 250 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 251 . 253 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 254 Application and Support", STD 3, RFC 1123, DOI 10.17487/ 255 RFC1123, October 1989, 256 . 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 260 RFC2119, March 1997, 261 . 263 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 264 "DNS Extensions to Support IP Version 6", RFC 3596, DOI 265 10.17487/RFC3596, October 2003, 266 . 268 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 269 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 270 2006, . 272 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 273 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 274 . 276 Author's Address 278 Roland Bracewell Shoemaker 279 Internet Security Research Group 281 Email: roland@letsencrypt.org