Automated Certificate Management Environment (ACME) Service Discovery
draft-tweedale-acme-discovery-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Fraser Tweedale | ||
| Last updated | 2020-10-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tweedale-acme-discovery-00
Network Working Group F. Tweedale
Internet-Draft Red Hat
Intended status: Standards Track 21 October 2020
Expires: 24 April 2021
Automated Certificate Management Environment (ACME) Service Discovery
draft-tweedale-acme-discovery-00
Abstract
This document specifies a service discovery mechanism that enables
capable clients to locate an Automated Certificate Management
Environment (ACME) server in their network environment.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 April 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Tweedale Expires 24 April 2021 [Page 1]
Internet-Draft ACME-SD October 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. DNS URI Record . . . . . . . . . . . . . . . . . . . . . . . 3
4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . 3
4.1. When to Perform Service Discovery . . . . . . . . . . . . 3
4.2. Candidate Parent Domains . . . . . . . . . . . . . . . . 3
4.3. DNS URI Queries and Validation . . . . . . . . . . . . . 4
4.4. ACME Operations . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. Underscored Node Name for ACME Service Discovery . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6.1. TLS and Certificate Validation . . . . . . . . . . . . . 5
6.2. Parent Domain Selection . . . . . . . . . . . . . . . . . 5
6.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Automatic Certificate Management Environment (ACME) [RFC8555]
specifies a protocol by which a client may, in an automatable way,
prove control of identifiers and obtain a certificate from an
Certificate Authority (the ACME server). However, it did not specify
a mechanism by which a client can locate a suitable ACME server. It
is assumed that a client will be configured to use a particular ACME
server, or else default to some well known, publicly accessible ACME
service.
In some environments, such as corporate networks, it may be
impossible for ACME clients to obtain certificates from a publicly
accessible ACME servers, or an organisation may prefer clients to use
a particular server. Explicitly configuring ACME clients to use a
particular ACME server presents an administrative burden.
This document specifies a mechanism by which ACME clients can locate
an ACME server using the Uniform Resource Identifier (URI) DNS
resource record [RFC7553].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Tweedale Expires 24 April 2021 [Page 2]
Internet-Draft ACME-SD October 2020
3. DNS URI Record
The URI resource record [RFC7553] facilitates client discovery of
ACME server(s) for a given DNS parent domain name ("parent domain"
having the meaning given in [RFC8552]). The owner name of the URI
record SHALL be the parent domain with the label "_acme-server"
prepended to it. The target of the URI record SHALL be the URI
[RFC3986] of the directory resource of the target ACME server,
enclosed in double quotes ("). For example:
$ORIGIN example.com.
_acme-server IN URI 10 1 "https://ca.example.com/acme/directory"
There MUST be exactly zero or one URI records for the "_acme-server"
node.
4. Client Behaviour
4.1. When to Perform Service Discovery
If an ACME client provides for explicit configuration of an ACME
server, and such configuration is provided, the client MUST use the
configured ACME server and MUST NOT perform service discovery.
Otherwise, if an ACME client supports service discovery, in the
absense of explicit configuration of an ACME server the client MAY
attempt to locate an ACME server using the mechanisms specified in
this document. A client MAY refuse to perform service discovery
unless its configuration explicitly enables it.
4.2. Candidate Parent Domains
To perform service discovery, the ACME client needs a list of
candidate parent domains. The client will query the associated URI
records for the candidate parent domains.
If an ACME client provides for explicit configuration of parent
domains to use for service discovery, and such configuration is
provided, the candidate parent domains SHALL be the configured
values.
Otherwise, there are a variety of ways an ACME client could choose
candidate parent domains, including:
* The host's fully-qualified domain name with one or more labels
removed from the left.
* The "search" domains from the host's DNS configuration.
Tweedale Expires 24 April 2021 [Page 3]
Internet-Draft ACME-SD October 2020
* The Kerberos [RFC4120] realm of the host.
* The result of a PTR lookup on one of the host's non-loopback IP
addresses, with one or more labels removed from the left.
An ACME client MAY use any or all of these or other suitable methods
for identifying candidate parent domains. If multiple candidate
parent domains are identified the client MUST establish an order of
preference among them. If any candidate parent domain A is a
subdomain of another candidate parent domain B, the client MUST
preference A higher than B.
4.3. DNS URI Queries and Validation
Service discovery begins with the most preferred candidate parent
domain.
The ACME client SHALL prepend the label "_acme-server" to the
candidate parent domain name and query the DNS URI record for the
resulting domain name. If any records are returned, the ACME client
SHALL select exactly one of the target URIs. The client SHALL
perform an HTTPS GET request for the target URI and SHALL attempt to
parse the response body as an ACME directory object. If successful,
service discovery has succeeded; the client SHALL use the target of
the URI record as the ACME server, and MUST NOT process the remaining
candidate parent domains.
Otherwise, service discovery for the current parent domain has
failed. Either there is no "_acme-server" URI record under the
parent domain, or the target URI value is not well formed, or the
HTTP request failed, or the HTTP response is not a valid ACME
directory object. In this case, the client MAY retry service
discovery with the next most preferred candidate parent domain. The
client MAY continue retrying until no candidate parent domains
remain, or MAY give up earlier (e.g. after a fixed number of
attempts).
If service discovery does not succeed, an ACME client MAY fall back
to a default ACME server (e.g. a publicly accessible ACME server).
4.4. ACME Operations
An ACME client MAY record (cache) the URI of the ACME server located
via service discovery and MAY use the cached server for new account
and new order operations, without performing service discovery each
time.
Tweedale Expires 24 April 2021 [Page 4]
Internet-Draft ACME-SD October 2020
When storing data about accounts and orders, ACME clients SHOULD
record the URI of the actual ACME server used. When retrieving or
revoking certificates or performing account operations, the client
SHOULD use the recorded URI to contact the ACME server and SHOULD NOT
perform service discovery.
When renewing or replacing a certificate, if the recorded ACME server
cannot be contacted or fails to issue a certificate, a client MAY
perform service discovery to attempt to locate an alternative ACME
server that may be able to issue the certificate.
5. IANA Considerations
5.1. Underscored Node Name for ACME Service Discovery
Per RFC 8552, please add the following entry to the "Underscored and
Globally Scoped DNS Node Names" registry:
+---------+--------------+-----------------+
| RR Type | _NODE NAME | Reference |
+---------+--------------+-----------------+
| URI | _acme-server | {this document} |
+---------+--------------+-----------------+
6. Security Considerations
6.1. TLS and Certificate Validation
Use of TLS is REQUIRED by the ACME specification [RFC8555]. X.509
[RFC5280] supports the Uniform Resource Identifier name type in the
Subject Alternative Name extension, but this name type is not widely
supported by TLS clients or certificates. HTTP Over TLS [RFC2818]
does not describe the use of a URI-ID for HTTP services. Therefore
when an ACME server was located via service discovery its certificate
MUST be validated according to both RFC 5280 and [RFC6125] and MUST
match the host from the target URI against the dNSName (if the host
is a reg-name) or iPAddress (if the host is an IP address) value(s)
in the Subject Alternative Name extension. The client SHOULD NOT use
a URI-ID when validating the server's certificate.
6.2. Parent Domain Selection
An attacker who is able to influence an ACME client's candidate
parent domains can influence which ACME server the client uses, or
cause service discovery to fail. The attacker could use this
capability to perform a denial of service against the ACME client
(i.e. the client cannot acquire or renew a certificate), or against
parties that validate certificates issued to the client (because they
Tweedale Expires 24 April 2021 [Page 5]
Internet-Draft ACME-SD October 2020
do not trust the issuing CA or because the certificate is invalid in
some way), or against a target ACME server (by directing many clients
to it). ACME client implementers should carefully consider which
methods of determining the parent domain(s) are appropriate for their
use cases, and the security implications of their chosen methods.
An ACME client may form candidate parent domains by removing one or
more labels from the left side of some other DNS name (e.g. the host
name of the client's machine). If too many labels are removed, the
ACME client could perform DNS queries in zones outside the control of
the organisation that operates the ACME client. As a result, the
ACME client could locate and use an ACME server that the organisation
does not intend.
To mitigate this risk, it is RECOMMENDED that clients limit the
amount of label pruning that occurs. It is not possible to make a
concrete recommendation that is suitable for all environments.
Implementers must consider what is appropriate for their use cases
and environments. The candidate parent domain ordering requirements
also mitigate this risk.
6.3. DNS Security
Without ACME service discovery, an ACME client must be configured or
hard-coded to use a particular ACME server, specified as the HTTPS
URI of the server's directory resource. Typically the host will be a
DNS name rather than an IP address, and one or more DNS queries are
necessary to resolve the host's DNS name to an IP address.
When service discovery is used, the URI of the ACME server is
obtained from a DNS URI record. If an attacker is able to spoof the
_acme-server URI record for a candidate parent domain name, the
attacker could cause service discovery to fail or could direct the
client to an ACME server of the attacker's choosing. This could
constitute a denial of service attack against the client, against
parties that validate certificates issued to the client, or against
the target server.
Therefore it is RECOMMENDED that URI records used for ACME service
discovery be secured using DNSSEC. It is RECOMMENDED that ACME
clients make DNS URI queries via DNSSEC-validating stub or recursive
resolvers.
Some methods of candidate parent domain selection may involve DNS
queries. For example, a client could query PTR records to find a
host name, from which it derives a candidate parent domain.
Implementers must consider the security of DNS data used for parent
domain selection.
Tweedale Expires 24 April 2021 [Page 6]
Internet-Draft ACME-SD October 2020
7. Normative References
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
8. Informative References
[RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource
Identifier (URI) DNS Resource Record", RFC 7553,
DOI 10.17487/RFC7553, June 2015,
<https://www.rfc-editor.org/info/rfc7553>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
Tweedale Expires 24 April 2021 [Page 7]
Internet-Draft ACME-SD October 2020
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005,
<https://www.rfc-editor.org/info/rfc4120>.
Author's Address
Fraser Tweedale
Red Hat
Email: ftweedal@redhat.com
Tweedale Expires 24 April 2021 [Page 8]