[Acme] Invalidation of authz after an account compromise
Jacob Hoffman-Andrews <jsha@eff.org> Mon, 30 January 2017 21:03 UTC
Return-Path: <jsha@eff.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278FB12960F for <acme@ietfa.amsl.com>; Mon, 30 Jan 2017 13:03:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.2
X-Spam-Level:
X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d858TSN_G0Or for <acme@ietfa.amsl.com>; Mon, 30 Jan 2017 13:03:30 -0800 (PST)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1551295FE for <acme@ietf.org>; Mon, 30 Jan 2017 13:03:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=dj+2JgTuvdP11W4XpXT951PvDSMbV6+5xD5Vii0A9RE=; b=0Q2dEXS0S24tShkvaLUpqz1vLRbrnKQ45Jz16fP/0ehv5PDa0l4y6iihwvKJ8V/M7snCVBrQQQ25BPhAEKthAhCVHMB4h9/bQoca4D92BNu9dyKDyn8BWqvlJbH1XyfGiZ/uWj+2F8hGmr6iAAdEAMjCEmCJMg57wLutSmchtN0=;
Received: ; Mon, 30 Jan 2017 13:03:30 -0800
To: "acme@ietf.org" <acme@ietf.org>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <0964d671-972a-1101-93ed-d9f64ece8e2a@eff.org>
Date: Mon, 30 Jan 2017 13:03:28 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/ye_F6gX-CVl1WQlGcncul04NQEM>
Subject: [Acme] Invalidation of authz after an account compromise
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2017 21:03:32 -0000
We've discussed in the past how a domain owner should recover from a host compromise. I believe we came to a rough consensus that solving a DV challenge should be sufficient authorization to invalidate extant authorization on other accounts, and that we can consider each newly validated authz to invalidate previous authzs for the same identifier. I've written this up as a PR: https://github.com/ietf-wg-acme/acme/pull/240 diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md index d2b1ca1..9ab10f2 100644 --- a/draft-ietf-acme-acme.md +++ b/draft-ietf-acme-acme.md @@ -1643,6 +1643,9 @@ for the identifier. If the final state is "valid", the server MUST add an "expires" field to the authorization. When finalizing an authorization, the server MAY remove challenges other than the one that was completed. The server SHOULD NOT remove challenges with status "invalid". +If the final state is "valid", the server SHOULD invalidate any other +currently-valid authorizations for the same identifier. See +{{security-considerations}} for reasoning. Usually, the validation process will take some time, so the client will need to poll the authorization resource to see when it is finalized. For challenges @@ -2688,6 +2691,23 @@ within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.). +## Recovery From Host Compromise + +If a host is compromised, once the owner regains exclusive control of the host, +they will want to take steps to revoke any certificates the attacker may have +issued, and to ensure that the attacker cannot issue new certificates for the +affected hostnames. + +If the attacker gained access to the private key for an ACME account, but has +not yet changed the ACME account keypair, the proper owner can use the key +rotation functionality to regain exclusive control of their ACME account. + +If the attacker did change the ACME account keypair, or if the attacker created +their own ACME account and authorized the hostname, the proper owner, after +regaining control of the host, can authorize that hostname on their own account +(which should invalidate previous authorizations for that hostname), and can use +that authorization to revoke any certificates the attacker may have issued. + # Acknowledgements In addition to the editors listed on the front page, this document has benefited
- [Acme] Invalidation of authz after an account com… Jacob Hoffman-Andrews