Internet DRAFT - draft-pepanbur-acme-proxy
draft-pepanbur-acme-proxy
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, <https://github.com/letsencrypt/acme-spec/
blob/master/draft-barnes-acme.md>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[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,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[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,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC)
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
<http://www.rfc-editor.org/info/rfc6402>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>.
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]
