Internet DRAFT - draft-fiebig-acme-esecacme
draft-fiebig-acme-esecacme
ACME Working Group T. Fiebig
Internet-Draft TU Delft
Intended status: Standards Track K. Borgolte
Expires: April 24, 2019 Princeton University
October 21, 2018
Extended Security Considerations for the Automatic Certificate
Management Environment (ESecACME)
draft-fiebig-acme-esecacme-00
Abstract
By now, most Public Key Infrastructure X.509 (PKIX) certificates are
issued via the ACME protocol. Recently, several attacks against
domain validation (DV) have been published, including IP-use-after-
free, (forced) on-path attacks, and attacks on protocols used for
validation. In general, these attacks can be mitigated by
(selectively) requirering additional challenges, e.g., DNS
validation, proof of prior-key-ownership, or in severe cases even
extended validation (EV) instead of DV. This document provides a
list of critical cases and describes which mitigations can be used to
reduce the threat of issuing a certificate to an unauthorized party.
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 April 24, 2019.
Copyright Notice
Copyright (c) 2018 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
Fiebig & Borgolte Expires April 24, 2019 [Page 1]
Internet-Draft ESecACME October 2018
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IP/Resource-use-after-free . . . . . . . . . . . . . . . 3
2.1.1. Detection . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Defense . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. (Forced)-on-path Attacks . . . . . . . . . . . . . . . . 4
2.2.1. Detection . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Defense . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. DNS Cache Poisoning Attacks . . . . . . . . . . . . . . . 5
2.3.1. Detection . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2. Defense . . . . . . . . . . . . . . . . . . . . . . . 5
3. Summary Indicators for Additional Validation . . . . . . . . 5
3.1. High-Resource-Reuse Source / Cloud Provider . . . . . . . 5
3.2. Multi-Vantagepoint Validation Mismatch . . . . . . . . . 5
3.3. BGP monitoring . . . . . . . . . . . . . . . . . . . . . 6
3.4. DNS Fragmentation . . . . . . . . . . . . . . . . . . . . 6
3.5. Failed DNSSEC Validation . . . . . . . . . . . . . . . . 6
3.6. Recent Domain Transfer . . . . . . . . . . . . . . . . . 6
3.7. High-Risk Domains . . . . . . . . . . . . . . . . . . . . 6
4. Additional Validation Options . . . . . . . . . . . . . . . . 6
4.1. Proof of Prior Key Ownership . . . . . . . . . . . . . . 6
4.1.1. Limitations . . . . . . . . . . . . . . . . . . . . . 7
4.2. Additional Use of a DNS Challenge . . . . . . . . . . . . 7
4.2.1. Limitations . . . . . . . . . . . . . . . . . . . . . 7
4.3. Additional Use of an Email Challenge . . . . . . . . . . 7
4.3.1. Limitations . . . . . . . . . . . . . . . . . . . . . 7
4.3.2. Limitations . . . . . . . . . . . . . . . . . . . . . 7
4.4. Out-of-Band and offline validation . . . . . . . . . . . 7
4.4.1. Limitations . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Fiebig & Borgolte Expires April 24, 2019 [Page 2]
Internet-Draft ESecACME October 2018
1. Introduction
By now, most Public Key Infrastructure X.509 (PKIX) certificates are
issued via the ACME protocol. The automated nature of ACME and its
heavy use of Domain Validation (DV) make it susceptible to a variety
of attacks. These include IP-use-after-free [CSTRIFE], (forced) on-
path attacks [BAMBOO], and attacks on protocols used for validation
[DVP], e.g., DNS. In general, these attacks can be mitigated by
(selectively) requirering additional challenges, e.g., DNS
validation, proof of prior-key-ownership, or in severe cases even
extended validation (EV) instead of DV.
This document provides a list of potential attacks and how they can
be detected. In addition, it describes which mitigations can be used
to reduce the threat of issuing a certificate to an unauthorized
party in case a potential attack has been detected. This section
also holds information on how these mitigations may impact the
usability of CAs using ACME to issue certificates.
2. Attacks
In this section we describe common attacks against DV, how they can
be detected, and which additional verification methods should be used
in case they are detected.
2.1. IP/Resource-use-after-free
IP- and Resource-use-after-free attacks occur if a domain owner
points a DNS record to a resource, which they later vacate without
deleting the DNS record. The resource, usually in cloud scenarios,
can then be allocated by another party.
For example, one might run a service for www.example.com on a virtual
machine hosted with a cloud provider. One then points the AAAA
record of www.example.com to the IPv6 address of that virtual
machine, 2001:DB8:1234:1234::1. However, when the operator
discontinues the service, they do not delete this DNS record, leading
to a stale record. If another client of the cloud provider now
allocates a virtual machine, and receives the same IPv6 address, they
can proof ownership of www.example.com to an ACME compliant CA.
These observations similarly hold for DNS records pointing to legacy
IPv4 resources (A records), mail servers in case of email
verification using the ACME protocol (MX records), http and https
delegations (SRV records), and DNS delegations if DNSSEC is not being
used (NS records).
Fiebig & Borgolte Expires April 24, 2019 [Page 3]
Internet-Draft ESecACME October 2018
2.1.1. Detection
This attack type is difficult to detect from the CAs site, without
operators taking precautions themselves, which we describe in the
following section. Heuristics CAs could use depend on the
availability of cooperation from operators, or require proof of prior
key ownership.
Ideally, operators will use TLSA records to pin the TLS public key
for a name, allowing a CA to match the TLSA record to the key for
which a certificate is requested.
If a DNS challenge is used, failed DNSSEC validation may point at a
resource-use-after-free attack.
A heuristic which does not require prior cooperation by operators is
using Certificate Transparency (CT) logs to identify prior
certificate issuances. Furthermore, CAA records could be used to
limit the number of CT logs which have to be searched by the ACME
compliant CA. Furthermore, if the CA with which a certificate has
been requested is also the only CA allowed in the CAA, it could check
the ACME account ID of prior requests vs. the one used in the current
request.
2.1.2. Defense
On a mismatch between the TLSA public key and the public key used in
the request, the CA must deny the requested certificate. In case of
pre-existing certificates, or a mismatch in the ACME account ID, the
operator should use an additional validation technique. If DNSSEC is
being used, the DNS challenge is an option. Given that NS and MX
records may also suffer from resource-use-after-free attacks,
unauthenticated DNS and email challenges are not an option.
Due to the usability implications of the available defense options a
CA may opt to only perform mitigation on high-risk resources, e.g.,
known cloud operators and operators with a high customer churn.
2.2. (Forced)-on-path Attacks
If an attacker can perform a Monkey-in-the-Middle (MitM) attack by
controlling a part of the network path between the CA and the
resource used for validation, they can also impersonate an operator
and illegitimately obtain a certificate for a domain. Attackers may
force this on-path situation, e.g., using BGP shorter-prefix attacks
[BAMBOO].
Fiebig & Borgolte Expires April 24, 2019 [Page 4]
Internet-Draft ESecACME October 2018
2.2.1. Detection
To detect on-path attacks, CAs should validate challenges from
multiple vantage points. For this purpose, the CA should operate a
geographically and topologically distributed system for verification.
This system should contain at least one validator per IP region
(AfriNIC, APNIC, ARIN, LACNIC, RIPE). Similarly, a CA may monitor
the BGP prefix from which it received a request with a service
similar to https://bgpmon.net [1]. Note that, depending how close
the attacker is to the victim, no path without malicious activity may
remain, generalizing the detection issue to that outlined for
resource-use-after-free attacks.
2.2.2. Defense
The same defense options as for resource-use-after-free attacks
apply.
2.3. DNS Cache Poisoning Attacks
Paper just appeared; will be included in the next version of this
draft.
2.3.1. Detection
2.3.2. Defense
3. Summary Indicators for Additional Validation
In this section, we summarize indicators for using an extended
validation machanism.
3.1. High-Resource-Reuse Source / Cloud Provider
If the validation target for a challenge (A/AAAA/NS/MX) is located in
a network with a high resources churn, e.g., a cloud or hosting
provider, or a residential ISP, extended validation requirements
should be considered.
3.2. Multi-Vantagepoint Validation Mismatch
If at least one of an CAs validation notes does not match the results
of the other nodes, the CA must consider the requested domain to be
under attack, necessitating either DNSSEC signed DNS validation,
proof of prior-key-ownership or EV.
Fiebig & Borgolte Expires April 24, 2019 [Page 5]
Internet-Draft ESecACME October 2018
3.3. BGP monitoring
If any prefix for either the A, AAAA, MX, or NS records (or
intermediate names and CNAMEs) is considered to be under a BGP MitM
attack by a service similar to https://bgpmon.net [2], the CA must
consider the requested domain to be under attack, necessitating
either DNSSEC signed DNS validation, proof of prior-key-ownership or
EV.
3.4. DNS Fragmentation
Paper just appeared; will be included in the next version of this
draft.
3.5. Failed DNSSEC Validation
If DNSSEC validation for a domain for which a certificate is
requested fails, the CA must consider the domain to be under attack,
necessitating either proof of prior-key-ownership or EV.
3.6. Recent Domain Transfer
If a domain has been transfered during the last 72 hours, the CA
should consider the domains ownership-state as insufficiently
defined, and reuire either proof of prior-key-ownership or EV.
3.7. High-Risk Domains
If a domain is a high-risk domain, CAs should only offer DNSSEC
signed DNS validation, proof of prior-key-ownership DV, or EV.
Domains are high risk domains if they are part of the Alexa top
10,000, belong to a CA, a software or hardware vendor, or a payment
provider.
4. Additional Validation Options
If one or multiple of the indicators above are detected by a CA, it
can employ one of the following additional validation options.
4.1. Proof of Prior Key Ownership
If a CA detects an attack, it can require the requesting party to
proof that it has access to the private key for a previously issued
certificate. This can be done implicitly, by requirering DV over
HTTPS, using a validating certificate, or, explicitly, by using a
dedicated ACME-challenge.
Fiebig & Borgolte Expires April 24, 2019 [Page 6]
Internet-Draft ESecACME October 2018
4.1.1. Limitations
This option has several operational challenges. An operator's
infrastructure may not be design in a way that preserves prior
private keys, for example in large container setups. Similarly, the
prior key might have been lost due to data-loss, or because the
systems holding it have been discontinued. Similarly, prior
certificates may have expired.
Furthermore, an attacker may have obtained a prior private key by
compromising a system, or by having had legitimate authority over the
domain before.
4.2. Additional Use of a DNS Challenge
If the CA detects an attack on one validation, e.g., web based DV, it
may use ACME-DNS instead.
4.2.1. Limitations
This challenge does not provide full resillience against all attacks.
It however increases the effort an adversary has to put into an
attack significantly.
4.3. Additional Use of an Email Challenge
If the CA detects an attack on one validation, e.g., web based DV, it
may use ACME-EMAIL instead.
4.3.1. Limitations
This challenge does not provide full resillience against all attacks.
It however increases the effort an adversary has to put into an
attack significantly.
4.3.2. Limitations
4.4. Out-of-Band and offline validation
If a party is unable to proof prior-key-ownership, and any of the
attack indicators outlined before is detected by the CA, the CA
should perform a traditional extended validation, requesting
appropriate documentation from the requesting party.
Fiebig & Borgolte Expires April 24, 2019 [Page 7]
Internet-Draft ESecACME October 2018
4.4.1. Limitations
EV is a manual process which prevents ACME from being used. It is
significantly more costly and smaller CAs may be unable to provide
the necessary infrastructure to support EV.
5. IANA Considerations
There are no IANA considerations.
6. Security Considerations
This document itself serves as a summary of additional security
considerations. Operators of CAs should carefully follow the
recommendations made in this document to prevent issuing certificates
to unauthorized parties.
7. Acknowledgements
8. References
8.1. Normative References
[BAMBOO] Mittal, P., "Bamboozling Certificate Authorities with
BGP", August 2018,
<https://www.usenix.org/conference/usenixsecurity18/
presentation/birge-lee>.
[CSTRIFE] Vigna, G., "Cloud Strife: Mitigating the Security Risks of
Domain-Validated Certificates", February 2018,
<http://dx.doi.org/10.14722/ndss.2018.23327>.
[DVP] Waidner, M.,
"https://www.usenix.org/conference/usenixsecurity18/
presentation/birge-lee", n.d..
8.2. URIs
[1] https://bgpmon.net
[2] https://bgpmon.net
Authors' Addresses
Tobias Fiebig
TU Delft
Email: t.fiebig@tudelft.nl
Fiebig & Borgolte Expires April 24, 2019 [Page 8]
Internet-Draft ESecACME October 2018
Kevin Borgolte
Princeton University
Email: kevinbo@iseclab.org
Fiebig & Borgolte Expires April 24, 2019 [Page 9]
