One document matched: draft-sheffer-acme-star-lurk-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.36 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="o-*+"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<rfc ipr="trust200902" docName="draft-sheffer-acme-star-lurk-00" category="std">
<front>
<title abbrev="ACME STAR LURK">Use of Short-Term, Automatically-Renewed (STAR) Certificates to address the LURK problem</title>
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
<organization>Intuit</organization>
<address>
<email>yaronf.ietf@gmail.com</email>
</address>
</author>
<author initials="D." surname="Lopez" fullname="Diego Lopez">
<organization>Telefonica I+D</organization>
<address>
<email>diego@telefonica.es</email>
</address>
</author>
<author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez de Dios">
<organization>Telefonica I+D</organization>
<address>
<email>oscar.gonzalezdedios@telefonica.com</email>
</address>
</author>
<author initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization>Nokia</organization>
<address>
<email>thomas.fossati@nokia.com</email>
</address>
</author>
<date year="2016" month="October" day="25"/>
<area>Security</area>
<workgroup>ACME Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This memo proposes two mechanisms that work in concert to address the LURK problem statement, allowing a third party (e.g., a content delivery network) to terminate TLS sessions on behalf of a domain name owner (e.g., a content provider).</t>
<t>The proposed mechanisms are:</t>
<t><list style="numbers">
<t>An extension to the ACME protocol to enable the issuance of short-term and automatically renewed certificates, and</t>
<t>A protocol that allows a domain name owner to delegate to a third party control over a certificate that bears its own name.</t>
</list></t>
<t>It should be noted that these are in fact independent building blocks that could be used separately to solve completely different problems.</t>
</abstract>
</front>
<middle>
<section anchor="a-solution-for-the-https-cdn-use-case" title="A Solution for the HTTPS CDN Use Case">
<t>A content provider, and Domain Name Owner (DNO), has agreements in place with one or more Content Delivery Networks (CDN) that are contracted to serve its content over HTTPS. The CDN terminates the HTTPS connection at one of its edge cache servers and needs to present its clients (browsers, set-top-boxes) a certificate whose name matches the authority of the URL that is requested, i.e. that of the DNO. However, many DNOs balk at sharing their long-term private keys with another organization and, equally, CDN providers would rather not have to handle other parties’ long-term secrets. This problem has been discussed at the IETF under the LURK (limited use of remote keys) title.</t>
<t>This document proposes a solution to the above problem that involves the use of short-term certificates with a DNO’s name on them, and a scheme for handling the naming delegation from the DNO to the CDN. The generated short-term credentials are automatically renewed by an ACME Certification Authority (CA) <xref target="I-D.ietf-acme-acme"/> and routinely rotated by the CDN on its edge cache servers. The DNO can end the delegation at any time by simply instructing the CA to stop the automatic renewal and let the certificate expire shortly after.</t>
<t>Using short-term certificates makes revocation cheap and effective <xref target="Topalovic"/> <xref target="I-D.iab-web-pki-problems"/> in case of key compromise or of termination of the delegation; seamless certificate issuance and renewal enable the level of workflow automation that is expected in today’s cloud environments. Also, compared to other keyless-TLS solutions <xref target="I-D.cairns-tls-session-key-interface"/> <xref target="I-D.erb-lurk-rsalg"/>, the proposed approach doesn’t suffer from scalability issues or increase in connection setup latency, while requiring virtually no changes to existing COTS caching software used by the CDN.</t>
</section>
<section anchor="conventions-used-in-this-document" title="Conventions used in this document">
<t>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 <xref target="RFC2119"/>.</t>
<t>TODO: glossary.</t>
</section>
<section anchor="protocol-flow" title="Protocol Flow">
<t>The protocol flow can be split into two: a LURK interface, used by CDN and DNO to agree on the name delegation, and the ACME STAR interface, used by DNO to obtain the short-term and automatically renewed certificate from the CA, which is eventually consumed by the CDN. The latter is also used to terminate the delegation, if so needed.</t>
<t>The following subsections describe the preconditions (<xref target="proto-preconditions"/>), and the three main phases of the protocol:</t>
<t><list style="symbols">
<t>Bootstrap: the CDN requests from the DNO the delegation of a specific name and in turn DNO asks an ACME CA to create the corresponding short-term and auto-renewed (STAR) certificate (<xref target="proto-bootstrap"/>);</t>
<t>Auto-renewal: the ACME CA periodically re-issues the short-term certificate and posts it to a public URL (<xref target="proto-auto-renewal"/>);</t>
<t>Termination: the DNO (indirectly) stops name delegation by explicitly requesting the ACME CA to discontinue the automatic renewal of the certificate (<xref target="proto-termination"/>).</t>
</list></t>
<section anchor="proto-preconditions" title="Preconditions">
<t>The protocol assumes the following preconditions are met:</t>
<t><list style="symbols">
<t>A mutually authenticated channel between CDN and DNO pre-exists. This is called “LURK channel” and all LURK protocol exchanges between CDN and DNO are run over it. It provides the guarantee that the LURK requests and responses are authentic
<cref anchor="_1" source="tf">Note that, under this assumption, the key used to authenticate the CDN to the DNO becomes a critical asset for the security of the proposed protocol, and that certain interactions (e.g., CSR submission) might require a stronger authentication mechanism. For example, stacking a further authentication factor on top of CDN’s LURK key would allow to distinguish an attacker that has only managed to successfully attack the CDN’s LURK key from the legitimate CDN.</cref>.</t>
<t>CDN and DNO have agreed on a “CSR template” to use, including at a minimum:
<list style="symbols">
<t>Subject name (e.g., “somesite.DNO.com”),</t>
<t>Validity (e.g., 24 to 72 hours),</t>
<t>Requested algorithms,</t>
<t>Key length,</t>
<t>Key usage.</t>
</list>
The CDN is required to use this template for every CSR created under the same delegation.</t>
<t>DNO has registered through the ACME interface exposed by the Certificate Authority (CA) using the usual ACME registration procedure. The DNO shall, at the registration stage, query the ACME server for the supported STAR capabilities – for example: the minimum validity period of the issued certificate, the maximum duration of the automatic renewal process (either as a maximum number of renewal events, or as its maximum absolute life-span).</t>
</list></t>
</section>
<section anchor="proto-bootstrap" title="Bootstrap">
<t>CDN (LURK client) generates a key-pair, wraps it into a Certificate Signing Request (CSR) according to the agreed CSR template, and sends it to the DNO (LURK server) over the pre-established LURK channel. The DNO uses the CDN identity provided on the LURK channel to look up the CSR template that applies to the requesting CDN and decides whether or not to accept the request. (TBD: This is probably a case that would require a further authentication stage over the one provided by the mutual-authenticated LURK channel?) Assuming everything is in order, it then “forwards” the CDN request to the ACME CA by means of the usual ACME application procedure. Specifically, DNO, in its role as a ACME/STAR client, requests the CA a STAR certificate, i.e., one that:</t>
<t><list style="symbols">
<t>Has a short validity (e.g., 24 to 72 hours);</t>
<t>Is automatically renewed by the CA for a certain period of time;</t>
<t>Is downloadable from a (highly available) public link without requiring any special authorisation.</t>
</list></t>
<t>Other than that, the ACME protocol flows as normal between DNO and CA, in particular DNO is responsible for satisfying the requested ACME challenges until the CA is willing to issue the requested certificate.
The DNO is given back a unique identifier for the issued STAR certificate to be used in subsequent interaction with the CA (e.g., if the certificate needs to be terminated.)</t>
<t>Concurrently, a 202 response has been sent back to the CDN with an endpoint to poll for completion of the certificate generation process.</t>
<t>The bootstrap phase ends when the DNO obtains the OK from the ACME CA and posts the certificate’s URL to the “completion endpoint” where the CDN can retrieve it. The information that is passed on to the CDN at this stage also includes details about how much time before the certificate expires can the CDN expect the replacement to be ready.</t>
<figure title="Bootstrap" anchor="figprotoboot"><artwork><![CDATA[
...........................
LURK : LURK ACME/STAR: ACME/STAR
Client : Server Client : Server
| : | | : |
| : | | ACME registration |
+-------. : | |<--------------------->|
| | : | | STAR capabilities |
| generate CSR : | | : |
| | : | | : |
|<------' : | | : |
| : | | : |
| Request new : | | : |
+---------------------->| | : |
| cert for CSR : | | : |
| : +-------. | : |
| : | | | : |
| : | Verify CSR | : |
| : | | | : |
| : +<------' | : |
| Accepted, poll at | | : |
|<----------------------+ | : |
| "completion URL" |- - - - - - - >| Application for |
| : | +---------------------->|
| : | | STAR certificate |
| : | | : |
| GET "completion URL" | | : Challenge |
|<--------------------->| |<--------------------->|
| 202, in progress | | : Response |
| : | | : |
| : | | Finalize/Certificate |
| : | |<----------------------+
| GET "completion URL" |< - - - - - - -| : + STAR Id |
+---------------------->| | : |
| : | | : |
| 200, certificate URL | | : |
|<----------------------+ | : |
| and other metadata | | : |
| : | | : |
`.........................'
]]></artwork></figure>
</section>
<section anchor="proto-auto-renewal" title="Refresh">
<t>The CA automatically re-issues the certificate (using the same CSR) before it expires and publishes it to the URL that the CDN has come to know at the end of the bootstrap phase. The CDN downloads and installs it. This process goes on until either:</t>
<t><list style="symbols">
<t>DNO terminates the delegation, or</t>
<t>Automatic renewal expires.</t>
</list></t>
<figure title="Auto renewal" anchor="figprotorefresh"><artwork><![CDATA[
LURK ACME/STAR
Client Server
| Retrieve cert | [...]
|<--------------------->| |
| +------. /
| | | /
| | Automatic renewal :
| | | \
| |<-----' \
| Retrieve cert | |
|<--------------------->| 72 hours
| | |
| +------. /
| | | /
| | Automatic renewal :
| | | \
| |<-----' \
| Retrieve cert | |
|<--------------------->| 72 hours
| | |
| +------. /
| | | /
| | Automatic renewal :
| | | \
| |<-----' \
| | |
| [...] | [...]
]]></artwork></figure>
</section>
<section anchor="proto-termination" title="Termination">
<t>DNO requests termination of the STAR certificate by including the previously obtained identifier in a STAR certificate termination request to the ACME interface.
After CA receives and verifies the request, it shall:</t>
<t><list style="symbols">
<t>Cancel the automatic renewal process for the LURK certificate;</t>
<t>Change the certificate publication resource to return an error indicating the termination of the delegation to external clients, including the CDN;</t>
</list></t>
<t>Note that it is not necessary to explicitly revoke the short-term certificate.</t>
<figure title="Termination" anchor="figprototerm"><artwork><![CDATA[
LURK ACME/STAR ACME/STAR
Client Client Server
| | |
| | Terminate STAR Id |
| +---------------------->|
| | +-------.
| | | |
| | | End auto renewal
| | | Remove cert link
| | | etc.
| | | |
| | Done |<------'
| |<----------------------+
| | |
| |
| Retrieve cert |
+---------------------------------------------->|
| Error: terminated |
|<----------------------------------------------+
| |
]]></artwork></figure>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t><list style="symbols">
<t>CDN’s client certificate key is first order security asset and MUST be protected. Absent 2FA/MFA, an attacker that can compromise the key might be able to obtain certificates bearing DNO’s identity.</t>
<t>Consider collusion of two or more CDNs with contracts with the same DNO (?)</t>
</list></t>
<section anchor="restricting-cdns-to-the-delegation-mechanism" title="Restricting CDNs to the Delegation Mechanism">
<t>Currently there are no standard methods for the DNO to ensure that
the CDN cannot issue a certificate through mechanisms other than the one described here,
for the URLs under the CDN’s control. For example, regardless of the STAR solution, a rogue CDN employee
can use the ACME protocol (or proprietary mechanisms used by various CAs) to create a fake certificate
for the DNO’s content.</t>
<t>The best solution currently being worked on would consist of several related
configuration steps:</t>
<t><list style="symbols">
<t>Make sure that the CDN cannot modify the DNS records for the domain.
Typically this would mean that the content owner establishes a CNAME resource record
from a subdomain into a CDN-managed domain.</t>
<t>Restrict certificate issuance for the domain to specific CAs that comply
with ACME. This assumes
universal deployment of CAA <xref target="RFC6844"/> by CAs, which is not the case yet.</t>
<t>Deploy ACME-specific methods to restrict issuance to a specific authorization
key which is controlled by the content owner <xref target="I-D.landau-acme-caa"/>, and/or to specific
ACME authorization methods.</t>
</list></t>
<t>This solution is recommended in general, even if an alternative to the
mechanism described here is used.</t>
</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI). This support does not imply endorsement.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='I-D.ietf-acme-acme'>
<front>
<title>Automatic Certificate Management Environment (ACME)</title>
<author initials='R' surname='Barnes' fullname='Richard Barnes'>
<organization />
</author>
<author initials='J' surname='Hoffman-Andrews' fullname='Jacob Hoffman-Andrews'>
<organization />
</author>
<author initials='J' surname='Kasten' fullname='James Kasten'>
<organization />
</author>
<date month='July' day='8' year='2016' />
<abstract><t>Certificates in the Web's X.509 PKI (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certificate authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-acme-acme-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-acme-acme-03.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC6844' target='http://www.rfc-editor.org/info/rfc6844'>
<front>
<title>DNS Certification Authority Authorization (CAA) Resource Record</title>
<author initials='P.' surname='Hallam-Baker' fullname='P. Hallam-Baker'><organization /></author>
<author initials='R.' surname='Stradling' fullname='R. Stradling'><organization /></author>
<date year='2013' month='January' />
<abstract><t>The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6844'/>
<seriesInfo name='DOI' value='10.17487/RFC6844'/>
</reference>
<reference anchor='I-D.iab-web-pki-problems'>
<front>
<title>Problems with the Public Key Infrastructure (PKI) for the World Wide Web</title>
<author initials='R' surname='Housley' fullname='Russ Housley'>
<organization />
</author>
<author initials='K' surname='O'Donoghue' fullname='Karen O'Donoghue'>
<organization />
</author>
<date month='September' day='23' year='2016' />
<abstract><t>The Public Key Infrastructure (PKI) used for the World Wide Web (Web PKI) is a vital component of trust in the Internet. In recent years, there have been a number of improvements made to this infrastructure, including improved certificate status checking, automation, and transparency of governance. However, additional improvements necessary. This document identifies continuing areas of concerns and provides recommendations to the Internet community for additional improvements, moving toward a more robust and secure Web PKI.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-iab-web-pki-problems-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-iab-web-pki-problems-03.txt' />
</reference>
<reference anchor='I-D.cairns-tls-session-key-interface'>
<front>
<title>Session Key Interface (SKI) for TLS and DTLS</title>
<author initials='K' surname='Cairns' fullname='Kelsey Cairns'>
<organization />
</author>
<author initials='J' surname='Mattsson' fullname='John Mattsson'>
<organization />
</author>
<author initials='R' surname='Skog' fullname='Robert Skog'>
<organization />
</author>
<author initials='D' surname='Migault' fullname='Daniel Migault'>
<organization />
</author>
<date month='October' day='19' year='2015' />
<abstract><t>This document describes a session key interface that can be used for TLS and DTLS. The Heartbleed attack has clearly illustrated the security problems with storing private keys in the memory of the TLS server. Hardware Security Modules (HSM) offer better protection but are inflexible, especially as more (D)TLS servers are running on virtualized servers in data centers.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-cairns-tls-session-key-interface-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-cairns-tls-session-key-interface-01.txt' />
</reference>
<reference anchor='I-D.erb-lurk-rsalg'>
<front>
<title>A PFS-preserving protocol for LURK</title>
<author initials='S' surname='Erb' fullname='Samuel Erb'>
<organization />
</author>
<author initials='R' surname='Salz' fullname='Rich Salz'>
<organization />
</author>
<date month='May' day='28' year='2016' />
<abstract><t>This document defines a protocol between a content provider and an external key owner that enables the provider to act as a TLS termination end-point for the key owner, without having the key actually being provisioned at the provider. The protocol between the two preserves forward secrecy, and is also designed to prevent the use of the key owner as a general-purpose signing oracle which would make it complicit in attacks against uses of the very keys it is trying to protect.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-erb-lurk-rsalg-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-erb-lurk-rsalg-01.txt' />
</reference>
<reference anchor='I-D.landau-acme-caa'>
<front>
<title>CA Account URI Binding for CAA Records</title>
<author initials='H' surname='Landau' fullname='Hugo Landau'>
<organization />
</author>
<date month='October' day='18' year='2016' />
<abstract><t>The CAA DNS record allows a domain to communicate issuance policy to CAs, but only allows a domain to define policy with CA-level granularity. However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy. This specification defines two such parameters, one allowing specific accounts of a CA to be identified by URI and one allowing specific methods of domain control validation as defined by the ACME protocol to be required.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-landau-acme-caa-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-landau-acme-caa-01.txt' />
</reference>
<reference anchor="Topalovic" target="http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf">
<front>
<title>Towards Short-Lived Certificates</title>
<author initials="E." surname="Topalovic" fullname="Emin Topalovic">
<organization>Stanford University</organization>
</author>
<author initials="B." surname="Saeta" fullname="Brennan Saeta">
<organization>Stanford University</organization>
</author>
<author initials="L." surname="Huang" fullname="Lin-Shung Huang">
<organization>Carnegie Mellon University</organization>
</author>
<author initials="C." surname="Jackson" fullname="Colling Jackson">
<organization>Carnegie Mellon University</organization>
</author>
<author initials="D." surname="Boneh" fullname="Dan Boneh">
<organization>Stanford University</organization>
</author>
<date year="2012"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:27:19 |