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]