Network Working Group P. Panburana Internet-Draft M. Pritikin Intended status: Standards Track P. Beal Expires: April 21, 2016 Cisco October 19, 2015 ACME Proxy Mode of Operation draft-pepanbur-acme-proxy-00 Abstract This document proposes an addition to the Automatic Certificate Management Environment (ACME) draft describing the ability for a publicly facing ACME client to operate as an enrollment proxy for hosts on its private network as defined by [RFC1918] and [RFC4193]. ACME clients acting as a proxy are identified using the cmcRA flag [RFC6402]. 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 http://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 21, 2016. Copyright Notice Copyright (c) 2015 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 (http://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 Panburana, et al. Expires April 21, 2016 [Page 1] Internet-Draft ACME Proxy October 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. Proposed Operation . . . . . . . . . . . . . . . . . . . . . 2 2.1. Automated ACME Proxy Registration . . . . . . . . . . . . 2 2.2. Client Enrollment via ACME Proxy . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Currently, there is no clear path for hosts behind a private network [RFC1918][RFC4193] to enroll for a certificate with a public ACME CA (namely Let's Encrypt) [ACME]. Also, hosts behind a private network do not possess the ability or information to be able to respond to ACME proofs issued by a public ACME CA. This document describes the proposed operation of an ACME proxy placed at the border of a network to enroll for certificates with a public ACME CA on behalf of hosts on its private network. Through the use of the cmcRA extended key usage bit defined in [RFC6402] and an additional authorization identifier to be recognized by an ACME CA, an ACME client will have the ability to automatically request rights to act as a proxy, prove ownership of a domain, and enroll for certificates on behalf of hosts in its private network. 1.1. 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 [RFC2119]. 2. Proposed Operation The interactions between entities in the ACME proxy mode of operation is described in this section. The process can be broken down into two parts: proxy registration with the ACME CA and client enrollment via the ACME proxy. 2.1. Automated ACME Proxy Registration Panburana, et al. Expires April 21, 2016 [Page 2] Internet-Draft ACME Proxy October 2015 The process beings with the host that wishes to act as an ACME proxy initiating the account key registration process with a public ACME CA. It is RECOMMENDED that the registration process follows the registration procedure defined in [ACME]. +---------+ +------------+ | ACME | | ACME | | Proxy | | CA | | | | (Internet) | +---------+ +------------+ | | | | |---Registration Request---->| |<--Recovery Information-----| | | | | |-----Proxy Authz Request--->| |<----Challenges-------------| |-----Challenge Response---->| | | | [does requester] | [control the domain?] | | |-Polling for Authz Status-->| | | | [approve authorization] | | |-Polling for Authz Status-->| | | |----CSR submission--------->| | | |<---Certificate Issuance----| | | Figure 1 The registration process MAY be done manually for stricter control of certificates issued with the cmcRA extension. During automated proxy registration, the proxy device creates a partial authorization object per section 6.5 of [ACME] to begin the ACME key authorization process. In this partial authorization object, the "identifier" object SHOULD be declared as type "domain proxy" with the "value" set to the domain it desires to prove ownership of as shown below: POST /acme/new-authorization HTTP/1.1 Host: example.com Panburana, et al. Expires April 21, 2016 [Page 3] Internet-Draft ACME Proxy October 2015 { "resource": "new-authz", "identifier": { "type": "domain proxy", "value": "example.org" } } /* Signed as JWS */ The ACME CA SHALL recognize the "domain proxy" identifier as an additional authorization object per section 5.3 in [ACME]. The public ACME CA SHOULD then determine if it is willing to issue a certificate that would identify the requesting host as a proxy, granting it the ability to submit CSRs on behalf of clients behind it. If the ACME CA is willing to continue, it SHALL issue challenges for the ACME proxy to complete to establish proof of domain ownership. These challenges MAY be the ones specified in section 7 of [ACME]. If a host can demonstrate control over a given domain then that host has the ability to individually enroll for other certificates for its subdomains since the host has control over the same resources that would be used by each subdomain to prove ownership to the ACME server. Allowing a host to proxy enrollment requests for a given domain does not challenge the integrity of authorizations from the ACME server's perspective since the proxy uses the same set of resources that would be used by an ACME CA to validate each subdomain in a given domain. By granting the ability to allow an ACME proxy to field enrollment requests on behalf of hosts in a domain, hosts on a private network can have certificates issued by a public ACME CA. Panburana, et al. Expires April 21, 2016 [Page 4] Internet-Draft ACME Proxy October 2015 Once the host wishing to act as an ACME proxy completes the challenges, it SHOULD poll the public ACME CA for its authorization status as described in section 6.5 of [ACME]. When the proxy determines that it has been authorized, it can then submit a CSR for it's own certificate that MUST contain the key usage extension cmcRA bit defined in [RFC6402] by POSTing the CSR as described in section 6.6 of [ACME]. The presence of this bit in subsequent mutually authenticated TLS connections will allow the public ACME CA to determine that it has previously granted proxy authority to a host. The public ACME CA SHOULD then issue a certificate with the cmcRA key usage bit enabled to the requesting proxy. Upon issuing a certificate with the cmcRA bit to the ACME proxy, the ACME CA MUST make an association between the newly issued certificate and all identifiers for the proxy's account on the ACME server and the account key for the proxy. The association between the proxy's cmcRA certificate and the information in its account on the ACME server MUST be used to link the proxy's JWS signature account key on JWS objects containing new certificate request from the proxy's clients. 2.2. Client Enrollment via ACME Proxy Figure 2 illustrates client enrollment via the ACME proxy: +---------+ +----------+ +-----------+ | Client | | ACME | | ACME | | Entity | | Proxy | | CA | | | | | | (Internet)| +---------+ +----------+ +-----------+ |----CSR submission-------->| | | | | | [client authorized to get a certificate?] | | | | | |---Client CSR submission--->| | | | | | [name constraint] | | [check/cmcRA check] | | | | |<----Client certificate-----| | | | |<----Client certificate----| | | | | | | | Figure 2 After a certificate with the cmcRA bit has been issued to the ACME proxy, it can now take CSR submissions on of behalf clients behind it. These clients are free to use any mechanism to submit their CSRs Panburana, et al. Expires April 21, 2016 [Page 5] Internet-Draft ACME Proxy October 2015 to the ACME proxy. The ACME proxy SHOULD perform all authentication and authorization on clients prior to submitting their CSRs to the public ACME CA. The ACME proxy MUST submit a client's CSR to a public ACME CA by first creating a JWS object as described in section 6.6 of [ACME]. It SHALL contain the CSR it received from the client and the ACME proxy MUST sign it with the account key associated with the cmcRA certificate issued by the public ACME CA. When establishing the TLS connection [RFC5246] to POST the JWS object containing a client's CSR, the ACME proxy MUST present its cmcRA certificate to the ACME CA in the TLS connection. The ACME CA SHOULD now accept and validate peer certificates on TLS connections used to request new certificates. However, the ACME CA MUST accept and validate TLS peer certificates if the account key used to sign the POSTed JWS object is associated with a "domain proxy" identifier and it also MUST check for the presence of the cmcRA bit in the presented certificate. A check on the subject name contained in the POSTed client CSR MUST be done by the ACME CA to ensure that the request is for a certificate within the domain of the ACME proxy. This name constraint check SHOULD be done as described in [RFC5280] section 4.2.1.10. To determine if a subject name in a CSR received from an ACME proxy for one of its clients is a valid subdomain of the proxy's domain, the ACME CA SHOULD refer to the value associated with the authorized "domain proxy" identifier it keeps for the ACME proxy's account. For example, if an ACME proxy obtains an authorization as a "domain proxy" for the "example.com" domain the ACME CA MUST ensure that all CSRs submitted on behalf of the ACME proxy's clients have subject names and subject alt names that satisfy the expression "*.example.com". After the ACME CA validates the information contained within a CSR submitted by the proxy, it MAY issue a certificate for the requesting client. If the ACME CA decides to issue the certificate, the ACME proxy can then retrieve the issued certificate from the URI specified in the JWS message returned from the ACME CA or from the JWS object itself as described in section 6.6 of [ACME]. It is then up to the ACME proxy to deliver the certificate issued by the ACME CA to the client it enrolled on behalf of. 3. Security Considerations Consider an organization with control over the domain "example.com". This organization has configured its local DNS infrastructure to grant the DNS binding of a public IP address with "sales.example.com" to a server on its network and DNS binding of a public IP address with "test.sales.example.com" to another server on its network. Panburana, et al. Expires April 21, 2016 [Page 6] Internet-Draft ACME Proxy October 2015 Suppose the server in control of "sales.example.com" goes through the process to become an ACME proxy for the "sales.example.com" domain. It is now possible for the "sales.example.com" server to request a certificate as a proxy for "test.sales.example.com" despite not having been granted the domain name from the local DNS infrastructure. This situation presents a problem for the true owner of the "test.sales.example.com" domain as a certificate for that domain can now be requested by an another entity that was not assigned ownership of the domain by the local DNS infrastructure. It is because of the local policy in the organization's authoritative name server [RFC1035] for the domain "example.com" that the hierarchical domain names indicated by the "." [RFC1034] "test.sales.example.com" and "sales.example.com" were assigned to internal name servers that are not actually hierarchically related. However, in the same vein as section 9.2 of [ACME], from an outside world perspective the integrity of "test.sales.example.com" is not compromised since the subdomain is under the control of the owner of the top level "example.com" domain. Even without an ACME proxy providing the ability to automatically enroll for certificates within a subdomain, the possibility still exists for a certificate to be issued to an incorrect entity in a given domain if the local DNS authority performs no validation on the hierarchical relationship between entities in its network. The resulting domain validation confusion from this scenario is beyond the scope of the ACME protocol. 4. Acknowledgements I would like to extend a thank you to John Foley for reviewing this document. 5. Normative References [ACME] Barnes, , Eckersley, , Schoen, , Halderman, , and Kasten, "Automatic Certificate Management Environment (ACME)", December 2009, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", Panburana, et al. Expires April 21, 2016 [Page 7] Internet-Draft ACME Proxy October 2015 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, . [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, . [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . Authors' Addresses Peter Panburana Cisco Email: pepanbur@cisco.com Max Pritikin Cisco Email: pritikin@cisco.com Panburana, et al. Expires April 21, 2016 [Page 8] Internet-Draft ACME Proxy October 2015 Pete Beal Cisco Email: pbeal@cisco.com Panburana, et al. Expires April 21, 2016 [Page 9]