Automated Certificate Management Environment (ACME) Extension for Single Sign On Challenges
draft-biggs-acme-sso-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Andrew Biggs , Richard Barnes | ||
| Last updated | 2020-12-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-biggs-acme-sso-00
ACME WG A. Biggs
Internet-Draft R.L. Barnes
Intended status: Informational Cisco
Expires: 11 June 2021 8 December 2020
Automated Certificate Management Environment (ACME) Extension for Single
Sign On Challenges
draft-biggs-acme-sso-00
Abstract
This document specifies an extension to the ACME protocol [RFC8555]
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 [RFC8659] 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.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/bifurcation/acme-sso.
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 11 June 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Biggs & Barnes Expires 11 June 2021 [Page 1]
Internet-Draft ACME-SSO December 2020
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. ACME email Identifier Type . . . . . . . . . . . . . . . . . 6
5. ACME sso-01 Challenge Type . . . . . . . . . . . . . . . . . 6
6. CAA for Email Address Certificates . . . . . . . . . . . . . 7
6.1. CAA issueemail property . . . . . . . . . . . . . . . . . 8
6.2. Usage of the CAA validationmethods Parameter . . . . . . 8
6.3. CAA ssoproviders Parameter . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Collaboration applications are increasingly using end-to-end
encryption to protect user content. These applications 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.
Biggs & Barnes Expires 11 June 2021 [Page 2]
Internet-Draft ACME-SSO December 2020
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.
Biggs & Barnes Expires 11 June 2021 [Page 3]
Internet-Draft ACME-SSO December 2020
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 URL 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).
Biggs & Barnes Expires 11 June 2021 [Page 4]
Internet-Draft ACME-SSO December 2020
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
Figure 1: Overview of the SSO Challenge Flow
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 response) 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 URL that was
optionally provided as a parameter on the initial SSO start request.
The navigation of the browser back to the redirect URL 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.
Biggs & Barnes Expires 11 June 2021 [Page 5]
Internet-Draft ACME-SSO December 2020
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.
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.
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.
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_url (optional, string): If present, the client will be
redirected to the given URL on completion of the "sso-01"
challenge.
Biggs & Barnes Expires 11 June 2021 [Page 6]
Internet-Draft ACME-SSO December 2020
The "redirect_url" 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_url" 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".
6. 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.
Biggs & Barnes Expires 11 June 2021 [Page 7]
Internet-Draft ACME-SSO December 2020
A certificate request MAY specify more than one email address.
Issuers MUST verify authorization for all email addresses specified
in the request.
6.1. CAA issueemail property
The 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:
1. Perform CAA issue restriction processing for the FQDN, and
2. 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.
example.com. IN CAA 0 issueemail "ca1.example.net"
example.com. IN CAA 0 issueemail "ca2.example.net"
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.
6.2. Usage of the CAA validationmethods Parameter
As 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
[I-D.ietf-acme-email-smime] and Section 5).
For example:
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"
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.
Biggs & Barnes Expires 11 June 2021 [Page 8]
Internet-Draft ACME-SSO December 2020
6.3. CAA ssoproviders Parameter
This 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 [RFC5234]:
provider-domain-name = issuer-domain-name ; see RFC 8659
ssoproviders = [\*(provider-domain-name ",") provider-domain-name]
Extending the previous example to constrain "ca2.example.net" to only
use two specific SSO providers:
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"
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".
Biggs & Barnes Expires 11 June 2021 [Page 9]
Internet-Draft ACME-SSO December 2020
7. 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.
Biggs & Barnes Expires 11 June 2021 [Page 10]
Internet-Draft ACME-SSO December 2020
8. IANA Considerations
[[ TODO ]]
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
"DNS Certification Authority Authorization (CAA) Resource
Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
<https://www.rfc-editor.org/info/rfc8659>.
9.2. Informative References
[I-D.ietf-acme-email-smime]
Melnikov, A., "Extensions to Automatic Certificate
Management Environment for end-user S/MIME certificates",
Work in Progress, Internet-Draft, draft-ietf-acme-email-
smime-13, 20 November 2020, <http://www.ietf.org/internet-
drafts/draft-ietf-acme-email-smime-13.txt>.
[OPENID] Sakimura, N., Bradley, J., Jones, M., De Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", November 2014,
<https://openid.net/specs/openid-connect-core-1_0.html>.
Biggs & Barnes Expires 11 June 2021 [Page 11]
Internet-Draft ACME-SSO December 2020
[SAML] Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security
Assertion", March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
[W3C.REC-webauthn-1-20190304]
Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones,
M., Kumar, A., Liao, H., Lindemann, R., and E. Lundberg,
"Web Authentication:An API for accessing Public Key
Credentials Level 1", World Wide Web Consortium
Recommendation REC-webauthn-1-20190304, 4 March 2019,
<https://www.w3.org/TR/2019/REC-webauthn-1-20190304>.
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
Andrew Biggs
Cisco
Email: adb@cisco.com
Richard L. Barnes
Cisco
Email: rlb@ipv.sx
Biggs & Barnes Expires 11 June 2021 [Page 12]