Automated Certificate Management Environment (ACME) Extension for Single Sign On Challenges

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 10 October 2021.¶

Copyright Notice

Copyright (c) 2021 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 (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

Applications are increasingly using end-to-end encryption to protect user content and frequently use email addresses to identify users. In such contexts, the use of X.509 certificates binding email addresses to public keys is a natural authentication mechanism. If the issuer of the certificate is separate from the application provider, and validates control of the email address independently of the application provider, then the resulting certificate can be used to provide end-to-end authentication, in the sense that the application provider is unable to impersonate the authenticated user.¶

Historically, certificates for email addresses have been difficult to obtain. Current end-to-end encrypted communications applications typically rely on laborious, error-prone manual authentication processes, often based on comparing opaque "security codes" or "safety numbers". Thus, in practice, end-to-end encrypted communications are usually vulnerable to impersonation attacks by the application provider.¶

When ACME was first introduced, its primary focus was on issuing certificates for domain names, and the base specification contains challenges for validating a client's control over a domain name identifier [RFC8555]. ACME has since been extended to support validation email identifiers [I-D.ietf-acme-email-smime], in support of the issuance of certificates containing email addresses. This latter specification defines a validation method using SMTP, which is unsuitable for applications other than MUAs.¶

This specification introduces a new ACME challenge type to enable validation of email identifiers using common web-oriented single sign on (SSO) identity standards such as SAML [SAML] and OpenID Connect [OPENID]. These standards generally follow a pattern whereby a client initiates authentication with a browser request to some service, the service redirects the client to an identity provider, the provider authenticates the client, the provider redirects the client back to the service along with some assertion as to the client's identity, and finally the service produces some credential or resource authorization to the client.¶

The details of the interaction described above can become complex, and are well documented in the aforementioned specifications. However, since these are web-based interactions, an ACME client need only know how to launch the initial authentication request by opening a given URL within a browser context, and then recognizing when that interaction has concluded. Once concluded, an ACME client can query the ACME server for the status of the challenge to determine whether or not it was successful and, if successful, complete the standard ACME issuance flow. When properly integrated with an application, this extension can allow fully automated certificate issuance, with no user interaction at all.¶

Note that all interactions between an ACME server and the identity providers it relies upon are governed by the specifications of the web-based authentication protocols supported by those services. These are therefore considered out of scope for this document.¶

This document also defines extensions to the Certificate Authority Authorization (CAA) DNS Resource Record type that allows the operators of email domains to express authorizations policies related to email certificates.¶

2. Conventions and Definitions

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Protocol Overview

The general flow of an SSO challenge is illustrated below, within the context of a standard ACME certificate issuance order. It begins with a new order request to the server, and a response that indicates the authorizations that must be satisfied by the client. The client performs a request on one of these authorizations, and the server response includes a series of challenges that may be used to satisfy the authorization. Among these may be one or more challenges of type sso-01, each with a distinct "start URL" for initiating a browser-based authentication flow.¶

If the client is already browser-based, it may simply navigate directly to the SSO start URL, providing a redirect URI as a query parameter such that control can eventually return to the client on completion of the authentication flow. If the client is not browser-based, it may launch a native or embedded browser and direct it to the SSO start URL. In many cases this initial request will be serviced directly by the ACME server, however this is not required. The initial request will ultimately redirect the client to an identity provider, along with a request object specific to the SSO standard being employed (e.g. a SAML request).¶

Client                                                    ACME Server

~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

request new order             ------->
                              <-------        required authorizations
request authorization         ------->
                              <-------   SSO challenge with start URL

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Browser ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

request on SSO start URL      ------->
                              <-------      ACME redirect to provider
                                            w/ authentication request

             provider authenticates client (not shown)

provider redirect to ACME     ------->
w/ identity assertion
                                          validate provider assertion
                                            record challenge as valid
                              <-------             redirect to client

~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

request challenge             ------->
                              <-------                          valid
request finalize (CSR)        ------->
                              <-------                   finalize URL
finalize                      ------->
                              <-------                    certificate

On successful authentication to the identity provider, the client is redirected back to the origin of the provider request, where the provider assertion (e.g. a SAML assertion) is verified, and the ACME server records the associated challenge as having been validated (or not). The client may then be redirected to a redirect URI that was optionally provided as a parameter on the initial SSO start request.¶

The navigation of the browser back to the redirect URI indicates to the client that the authentication flow has completed. At this point the client can invoke the challenge URL to determine whether or not it has been recorded as valid, and subsequently complete the usual ACME issuance flow.¶

4. ACME email Identifier Type

The sso-01 challenge type described in this document applies exclusively to order requests with identifiers of type "email", as described in detail in "Extensions to Automatic Certificate Management Environment for end-user S/MIME certificates" [I-D.ietf-acme-email-smime]. Implementations MUST NOT present challenges of type sso-01 as options for validation of non-email type identifiers.¶

"identifier": { "type": "email", "value":"alice@example.org"}

5. ACME sso-01 Challenge Type

The sso-01 challenge type challenges the client to prove control over an identifier by browsing to the indicated sso_url and completing an SSO login for that identifier. A challenge of this type MUST include all required fields described in section 8 of [RFC8555]. In addition, the following fields are defined for this specific type of challenge:¶

sso_url (required, string):

The URL from which a web-based identifier validation flow may be initiated. The server must include sufficient information in the URL to allow it to associate the request to a specific challenge so that the challenge status can be updated when the SSO provider redirects the client back to the server.¶

sso_provider (optional, string):

The domain of the SSO provider relied upon for this challenge. An ACME server MAY rely upon any number of providers for validating a given identifier, however each MUST be represented as a distinct entry in the challenges array. It allows clients to disambiguate lists of providers and choose the most appropriate one.¶

The optional sso_provider field is provided as a guide to the client in selecting which sso-01 challenge to fulfill. For example, a client with access to a browsing context that already has authentication state for a given SSO provider might choose to use a challenge for that provider in order to avoid the need for user interaction. If an sso_provider value is not specified, then the web page indicated in the sso_url field SHOULD allow the user to select which SSO provider is used for login. The server MUST NOT present more than one sso-01 challenge in a single authorization with the same sso_provider value, including the "value" in which the field is not provided (that is, at most one sso-01 challenge may omit the sso_provider field).¶

A client fulfills to the challenge by first sending an ACME response, then browsing to the SSO URL. The challenge response has a single, optional field:¶

redirect_uri (optional, string):

If present, the client will be redirected to the given URI on completion of the sso-01 challenge.¶

The redirect_uri value provides a means for recognizing and resuming client control at the conclusion of an sso-01 type challenge. For web-based clients, this may mean the redirection of the browser back to the client. For native clients, this may mean the redirection of the browser to a custom scheme handler. A client can also recognize that the SSO process has completed by polling the challenge resource; even a client that receives explicit notification via a redirect_uri callback SHOULD verify that the challenge is now valid.¶

The server MUST set the status of the challenge to processing after receiving a response from the client. If the client completes the required SSO interaction and the resulting identity assertion validates the claimed email identifier, then the status of the challenge is set to valid. If the client fails to complete the SSO interaction or the interaction fails to validates the claimed identifier, then the status of the challenge is set to invalid.¶

{
     "type": "sso-01",
     "url": "https://example.org/acme/chall/prV_B7yEyA4",
     "status": "pending",
     "sso_url": "https://example.org/acme/start-sso/",
     "sso_provider": "https://identity-provider.org/sso"
}

6. Single Sign-On & Order fulfillment

The SSO URL allows the client to initiate the SSO flow. It is recommended that this flow be executed in the user's browser. The server must accept GET requests for the SSO URL. On reciept of such a request the must redirect the client to the appropriate SSO provider so that the user may be appropriately authenticated. When the SSO provider has successfully authenticated the user it will redirect the client back to the CA, to a location provided by the CA when the SSO flow was initiated, with an appropriate attestation. The server MUST then verify the providers attestation is valid as specified in the SAML [SAML] or Open ID [OPENID] specifications. Additionally The server MUST verify that the IdP's attestation is valid for the email address the challenge is intended to validate. When the attestation verification is complete it must then update the order status accordingly based on the outcome of the verification. See the {Guidance} section for more information.¶

As defined in section 7.4 of [RFC8555] once the client has been authorized it can proceed with order finalisation. The client SHOULD include the users email identifier in subjectAltName, and if no other identifiers are included in the cert, put it in commonName of the CSR that is submitted to the server.¶

7. Guidance for Email Verification

In order to issue a certificate the ACME server requires that the email address be attested by an authoritative service for that email identifier. When the ACME server receives a response from the SSO provider it must verify the provider attestation for the user and then must update the apporpriate challenge status. If the verification of the provider attestation is successful the server updates the challenge status to valid; if not it updates the status to invalid. Any attestation service and method should employ methods to ensure the confidentiality and integrity using the guidance specific to the protocol and/or service chosen.¶

8. CAA for Email Address Certificates

The holder of a DNS domain can provision CAA resource records to control which CAs are authorized to issue certificates for the domain and its subdomains [RFC8659]. Here, we extend CAA to allow control over issuance of certificates for email addresses within that domain. The following controls are available:¶

• Which CAs may issue email certificates¶
• What validation methods they may use¶
• What SSO providers the CA may use (a new mechanism defined here)¶

The Relevant RRSet for an email address is located using the "domain" portion of the email address. CAA is only supported for email addresses using the "dot-atom" production for the domain portion, in which case the domain portion is a DNS domain name [RFC5322]. The Relevant RRSet is the Relevant RRSet for this FQDN, according to the algorithm defined in [RFC8659].¶

Before issuing a certificate, a compliant CA MUST check for publication of a Relevant RRset. If such an RRset exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies. If the Relevant RRset for an email address contains no Property Tags that restrict issuance (for instance, if it contains only iodef Property Tags or only Property Tags unrecognized by the CA), CAA does not restrict issuance.¶

A certificate request MAY specify more than one email address. Issuers MUST verify authorization for all email addresses specified in the request.¶

example.com. IN CAA 0 issueemail "ca1.example.net"
example.com. IN CAA 0 issueemail "ca2.example.net"

example.com. IN CAA 0 issueemail "ca1.example.net; validationmethods=email-reply-00"
example.com. IN CAA 0 issueemail "ca2.example.net; validationmethods=email-reply-00,sso-01"

provider-domain-name = issuer-domain-name ; see RFC 8659
        ssoproviders = [\*(provider-domain-name ",") provider-domain-name]

example.com. IN CAA 0 issueemail "ca1.example.net; validationmethods=email-reply-00"
example.com. IN CAA 0 issueemail "ca2.example.net; \
  validationmethods=smime-01,sso-01 \
  ssoproviders=idp1.example.net,idp2.example.net"

9. Security Considerations

This document is an extension to ACME to provide an additional validation method for email identifiers. For general security considerations related to the ACME certificate issuance process, see [RFC8555].¶

As usual with ACME validation methods, the security of SSO validation comes down to the risk of the validation process being subverted and the strength of the binding between the validation process and the ACME transaction.¶

The binding of the validation process to the ACME transaction is managed via the transaction association mechanisms built into the underlying SSO protocols. For example, in OpenID Connect, the relying party provides a state value in its authentication request, which the SSO provider returns alongside the authentication response [OPENID].¶

As to the security of the SSO-based authentication itself, the usual risks and mitigations associated with user login apply. If the authentication is based solely on passwords, then an attacker that can obtain a user's password can obtain certificates for that user's email address. Standard mitigations such as multi-factor authentication are common features of SSO providers. Especially to the degree that these mitigations provide protections against phishing (as for example with WebAuthentication [W3C.REC-webauthn-1-20190304]), they also protect against the risk that the CA could direct the client to a phishing site instead of the real SSO provider.¶

In SSO-based certificate issuance, the SSO provided is trusted to assert whether a given user owns a given email address. A malicious SSO provider could falsify these assertions to cause a CA relying on it to issue a bad certificate. This risk is especially acute given that the ACME client is trusted to choose which SSO provider is used for a given validation -- a malicious client can direct the CA to use an SSO provider that the client has subverted.¶

The CA's choice of trusted SSO providers is the first line of defense against these risks. The client can only choose from among the SSO providers offered by the CA, so if the CA is judicious in its choice of SSO providers, it can reduce the risk of misissuance. The ssoproviders CAA parameter provides a second line of defense, allowing an email domain operator to further restrict the client's choice to the specific set of SSO providers authorized by the email domain operator.¶

10. IANA Considerations

[[ TODO ]]¶

Appendix A. Acknowledgements

The authors would like to thank Eric Rescorla, Ryan Hurst, and J.C. Jones for providing feedback on this document and the ideas that went into it.¶

Authors' Addresses