Automated Certificate Management Environment (ACME) Extension for Single Sign On ChallengesCiscoadb@cisco.comCiscorlb@ipv.sxCiscormoyniha@cisco.com
General
TODO Working GroupInternet-DraftThis document specifies an extension to the ACME protocol to enable
ACME servers to validate a client's control of an email identifier using single
sign-on (SSO) technologies. An extension to the CAA resource
record specification is also defined to provide domain owners a means to declare
a set of SSO providers that ACME servers may rely upon when employing SSO for
identifier validation on their domain.IntroductionApplications 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 . ACME has since
been extended to support validation email identifiers
, 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 and OpenID Connect . 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.Conventions and DefinitionsThe 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 when, and only when, they
appear in all capitals, as shown here.Protocol OverviewThe 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).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.ACME email Identifier TypeThe 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" . Implementations MUST NOT present
challenges of type sso-01 as options for validation of non-email type
identifiers.ACME sso-01 Challenge TypeThe 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 . 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.Single Sign-On & Order fulfillmentThe 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 or Open ID 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 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.Guidance for Email VerificationIn 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.SAMLIn the case where SAML is the preferred protocol it is recommended that the 'SSO Profiles of SAML' be used as guidance when implementing the ability to get and handle SAML assertions. In this scenario, an identity provider will act as the asserting party that will generate SAML assertions about a subject (user). The ACME server acts as the relying party that receives assertions from the identity provider. The ACME server should use the relaystate parameter to track order requests between it and the relevant identity provider. When the ACME server receives SAML assertions from the identity provider it should use the afforementioned relaystate to find the order request for which the assertion has been returned. Then using the assertion the ACME server extracts the asserted email identifier and verifies that it matches exactly the email address for which has been specififed in the order. The email address is defined by NameID or specified by the NameIdentifier in the received SAML assertion. This is dependent on the specific SAML configuration for the identity provider. See also .
Note that there may be specific configuration required to ensure that the email address is appropriately asserted in the SAML assertion generated by the identity provider.OpenIDIn this scenario, an OpenID provider will act as the asserting party that will generate ID Tokens about a subject (user). The ACME server acts as the relying party that receives ID Tokens from the OpenID provider. The ACME server only requires ID Tokens with Claims which identify a user - it does not require codes or any other token types and should not request them. It should use the state parameter of the authorize request to track order requests between it OpenID providers. The ACME server on receipt of ID tokens uses the state parameter value to find the appropriate order information. The claims within the ID Token are then used to verify that the email identifier matches exactly the email address for which has been specififed in the order. Specifically the email address will be defined by the email attribute of the ID Token. The server MUST also check that the email_verified attribute of the token is set. The order state is updated with the appropriate valid or invalid state indicating the outcome of this verification.CAA for Email Address CertificatesThe 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
. 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 . The Relevant RRSet is the Relevant RRSet for
this FQDN, according to the algorithm defined in .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.CAA issueemail propertyThe CAA issueemail property has the same syntax as the issue property, and
similar semantics. The only difference is that the designated CA is being
authorized to issue email address certificates rather than domain name
certificates. The CA is requested to:
Perform CAA issue restriction processing for the FQDN, and
Grant authorization to issue certificates containing email addresses with
domain part equal to the FQDN to the holder of the issuer-domain-name or a
party acting under the explicit authority of the holder of the
issuer-domain-name.
A CA consulting CAA records in the process of issuing an email address
certificate MUST rely only on issueemail Property Tags. In particular, issue
Property Tags MUST be ignored. Presence of an issueemail Property Tag does not
authorize issuance of certificates containing the FQDN or related Wildcard
Domain Names.Usage of the CAA validationmethods ParameterAs with domain names, validation of email addresses can be controlled with the
validationmethods parameter. Validation methods SHOULD NOT be included in
this parameter if they are not applicable to email identifiers. As of this
writing, the only validation methods defined for email identifiers are
smime-01 and sso-01 (see and ).For example:The above CAA resource record set declares a policy whereby compliant CAs will
not issue certificates on the example.com domain unless they self-identify as
either ca1.example.net or ca2.example.net. In addition, if these are ACME CAs,
then ca1.example.net may only present smime-01 challenges, whereas
ca2.example.net may present both smime-01 and sso-01 challenges.CAA ssoproviders ParameterThis document also defines the ssoproviders CAA parameter for the issueemail
Properties. The value of this parameter, if specified, MUST be a comma-separated
string of zero or more domain names identifying SSO providers.These domain names correspond to the sso_provider attribute of an sso-01
challenge. The ssoproviders parameter SHOULD NOT be provided if sso-01 is
not an allowed challenge type (e.g., if the Property has a validationmethods
parameter that does not include sso-01).The presence of this parameter constrains the Property to which it is attached.
A CA MUST only consider a Property with the ssoproviders parameter to
authorize issuance validation with the sso-01 validation method if the SSO
provider being used is identified by one of the domain names in the
comma-separated list.The value of the ssoproviders parameter MUST comply with the following ABNF
:Extending the previous example to constrain ca2.example.net to only use two
specific SSO providers:The presence of this parameter MUST be regarded by compliant CAs as a
restriction on the set of providers they are allowed to rely upon for sso-01
type challenges. However, an implementation MAY choose to not rely upon any
one or all providers named in this property.If this parameter is present but has a zero-length value, implementations MUST
NOT rely on any SSO provider. Since the sso-01 challenge requires an SSO
provider, the effect is thus the same as if the validationmethods parameter
were present and did not include sso-01.Security ConsiderationsThis 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 .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 .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 ), 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.IANA Considerations[[ TODO ]]ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn 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.Automatic Certificate Management Environment (ACME)Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a 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.DNS Certification Authority Authorization (CAA) Resource RecordThe 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 name. CAA Resource Records allow a public CA 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 CAs.This document obsoletes RFC 6844.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Internet Message FormatThis document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Informative ReferencesAssertions and Protocol for the OASIS Security AssertionOpenID Connect Core 1.0Extensions to Automatic Certificate Management Environment for end-user S/MIME certificatesIsode Ltd This document specifies identifiers and challenges required to enable
the Automated Certificate Management Environment (ACME) to issue
certificates for use by email users that want to use S/MIME.
Web Authentication:An API for accessing Public Key Credentials Level 1AcknowledgementsThe 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.