One document matched: draft-thomson-httpbis-cant-01.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-thomson-httpbis-cant-01">
<front>
<title abbrev="CANT">
Client Authentication over New TLS Connection
</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization>
<address>
<postal>
<street>331 E Evelyn Street</street>
<city>Mountain View</city>
<region>CA</region>
<code>94041</code>
<country>US</country>
</postal>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<!--
<author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
<organization>RTFM, Inc.</organization>
<address>
<postal>
<street>2064 Edgewood Drive</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>USA</country>
</postal>
<phone>+1 650 678 2350</phone>
<email>ekr@rtfm.com</email>
</address>
</author>
-->
<date year="2014"/>
<area>APPS</area>
<workgroup>HTTPBIS</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Client</keyword>
<keyword>Authentication</keyword>
<keyword>Certificate</keyword>
<keyword>TLS</keyword>
<keyword>Header</keyword>
<abstract>
<t>
This document defines an HTTP authentication scheme that can be added to an error response
to indicate to a client that a successful response will only be provided over a new TLS
connection, and only if the client has provided a certificate on that connection.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Client authentication in HTTP sometimes relies on certificate-based authentication of
clients in Transport Layer Security (TLS) (<xref target="RFC5246"/>, <xref
target="I-D.ietf-tls-tls13"/>). Some existing uses of client authentication rely on TLS
renegotiation, triggering renegotiation and a request for a client certificate in response
to a request for a particular resource.
</t>
<t>
<xref target="I-D.ietf-httpbis-http2">HTTP/2</xref> forbids the use of renegotiation, except
for at the very beginning of a connection. <xref target="I-D.ietf-tls-tls13">TLS 1.3</xref>
does not support renegotiation at all. Both of these restrictions result in a server being
unable to use renegotiation to conditionally request certificate-based authentication for
clients in those protocol versions.
</t>
<t>
This document defines a new authentication scheme, <spanx
style="verb">ClientCertificate</spanx>, for use in <xref
target="I-D.ietf-httpbis-p7-auth">HTTP authentication challenges</xref>. In combination
with the 401 (Unauthorized) status code, this indicates that client authentication at the
TLS layer is required in order to access the resource.
</t>
<section title="Conventions and Terminology" anchor="terminology">
<t>
At times, this document falls back on shorthands for establishing interoperability
requirements on implementations: the capitalized words "MUST", "SHOULD" and "MAY". These
terms are defined in <xref target="RFC2119"/>.
</t>
</section>
</section>
<section title="Client Certificate Challenge">
<t>
A new authentication scheme (<xref target="I-D.ietf-httpbis-p7-auth"/>) for the <spanx
style="verb">WWW-Authenticate</spanx> and <spanx style="verb">Proxy-Authenticate</spanx>
header fields is defined with the name <spanx style="verb">ClientCertificate</spanx>.
</t>
<t>
This challenge cannot be satisfied by constructing an <xref
target="I-D.ietf-httpbis-p7-auth">Authorization header field</xref>, it can only be
satisfied by making the request on a TLS connection where an appropriate certificate has
been provided by the client.
</t>
<t>
This authentication scheme cannot be used for <spanx style="verb">http</spanx> URIs.
</t>
<t>
To effectively use this authentication scheme, a new connection is needed for every
protection space used by a given origin server. A client can use the <spanx
style="verb">ClientCertificate</spanx> challenge as a trigger to open a new connection and
to use client authentication on that connection.
</t>
<t>
For the new connection, a client can use the mechanism in <xref
target="I-D.thomson-tls-care"/> to prompt the server to request a client certificate, to
avoid the problem where the server doesn't know to make a CertificateRequest.
</t>
<t>
[[TBD: In TLS 1.3 a client can unilaterally provide authentication information without a
request from the server.]]
</t>
<t>
[[TBD For versions of TLS prior to 1.3,]] a client can immediately request renegotiation
immediately after the initial handshake. A server that supports conditional client
authentication MUST request a client certificate if it receives a renegotiation request
prior to receiving any application data.
</t>
</section>
<section title="Client Certificate Challenge Parameters">
<t>
In addition to the <spanx style="verb">realm</spanx> parameter, a challenge with this
authentication scheme MAY include parameters that provide a client with information that
assists with selecting an appropriate certificate to offer. This can be necessary, since
the necessary context that the server relies on is derived from the request and this is not
available at the server when establishing a new connection.
</t>
<section title="Distinguished Name Parameter ("dn")">
<t>
The <spanx style="verb">dn</spanx> attribute includes a distinguished name for the
certificate authority. This matches the <spanx
style="verb">certificate_authorities</spanx> value sent in a TLS CertificateRequest
handshake message. The <spanx style="verb">dn</spanx> parameter is repeated for every
distinguished name that is permitted.
</t>
<t>
A distinguished name is defined in Abstract Syntax Notation number 1 (ASN.1) <xref
target="X680"/> and encoded using Distinguished Encoding Rules (DER) <xref target="X690"/>
when used in TLS. The value of the <spanx style="verb">dn</spanx> parameter is a
DER-encoded distinguished name that is further encoded using <xref target="RFC4648">base
64</xref> with the URL and filename safe alphabet. Multiple alternative distinguished
names are carried by repeating the <spanx style="verb">dn</spanx> parameter.
</t>
<figure><artwork type="abnf"><![CDATA[
dn-parameter = base64url
base64url = ALPHA / DIGIT / "_" / "~"
]]></artwork></figure>
<t>
[[ Issue: We could use the string encoding defined in RFC 4514, which could be friendlier
for production and consumption. That means that this would need to use quoted-string, RFC
4514 escaping would need to be escaped twice, and non-ASCII characters in the DN would
need to be escaped. Since the fingerprint parameters are strictly better anyway, and it's
also highly likely that selection criteria are unnecessary due to clients rarely having
more than one certificate for any given site, I'm not inclined to support that level of
complication. ]]
</t>
</section>
<section title="Fingerprint Parameters ("sha-256", ...)">
<t>
A server can instead include the fingerprint of a certificate that is on the certificate
chain of an acceptable client certificate. For instance, this might include the
fingerprint of an acceptable end-entity certificate, though what is more likely is that
this includes the fingerprint of a certificate issuer.
</t>
<t>
The name of fingerprint parameters is taken from the hash function textual names registry
defined in <xref target="RFC4572"/>. Clients MUST support a "sha-256" parameter, which
indicates that the fingerprint is calculated using <xref target="RFC6234">SHA-256</xref>.
The value of a fingerprint parameter is encoded using <xref target="RFC4648">base
64</xref> with the URL and filename safe alphabet.
</t>
<figure><artwork type="abnf"><![CDATA[
sha-256-parameter = base64url
]]></artwork></figure>
<t>
Like the <spanx style="verb">dn</spanx> parameter, fingerprint parameters can be repeated
to provide clients with alternative values.
</t>
<figure>
<preamble>
For example, a server could indicate that a set of permissible certificates based on a
SHA-256 fingerprint, as follows:
</preamble>
<artwork type="inline"><![CDATA[
WWW-Authenticate: ClientCertificate realm="home",
sha-256=NjUwZjA0Mzcy..., sha-256=MzJiMTQ3ODF...
]]></artwork>
<postamble>
These fingerprint values could be matched against an end-entity certificate or any
issuer in the certificate chain. Note that line breaks are added to this example for
formatting reasons only.
</postamble>
</figure>
<t>
Where fingerprints are provided with multiple hash function names, a client can use any of
the provided algorithms to determine which certificate to provide.
</t>
<t>
Note that strong collision-resistance is not important for the hash function that is used
for certificate fingerprints, since clients only use this value to select between
available certificates. The only consequence of a collision is that it becomes more
difficult for the client to select the correct certificate.
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
Clients that support this authentication scheme will create a new connection each time that
they see a challenge. This could be exploited in order to generate additional load from
connections on both server and client. This authentication scheme MUST only be used for
<spanx style="verb">https</spanx> URIs.
</t>
<t>
Using new connections for client authentication has additional processing costs to the
client in proving access to the private keys associated with the client certificate; and to
the server in proving access to the private keys associated with their certificate twice in
the case that the client opts for confidentiality protection on the client certificate
(though only for TLS versions prior to 1.3, see <xref target="privacy"/>).
</t>
<t>
<xref target="I-D.ietf-httpbis-http2">HTTP/2</xref> allows clients to use the same
connection for multiple domains. Certificate-based client authentication as defined by this
specification is bound to a single canonical root URI (see <xref
target="I-D.ietf-httpbis-p7-auth"/>). This could create issues where the security
properties of a connection become unclear. Clients MUST ensure that a client-authenticated
connection is only used for the canonical root URI for which it was created.
</t>
</section>
<section anchor="privacy" title="Privacy Considerations">
<t>
TLS version 1.2 and prior do not provide confidentiality protection for client certificates
in the initial handshake. Confidentiality protection for handshake messages, including the
client certificate, is provided only for renegotiation handshakes.
</t>
<t>
Clients can initiate renegotiation immediately after the TLS connection is established to
ensure that passive observers aren't able to view the selected certificate.
</t>
<t>
Revealing that a certificate is in use could alert a passive observer to the fact that a
client has requested particular resources, thereby aiding traffic analysis. While
renegotiation hides the contents of a client certificate, the presence of a new connection
could reveal that some form of client authentication is being used. This is an especially
strong signal in HTTP/2, where new connections are discouraged and are therefore
exceptional.
</t>
<t>
Clients MUST avoid offering their client certificate if it will lack confidentiality
protection, unless they are explicitly configured to send credentials in the clear.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
IANA is requested to create an entry in the HTTP Authentication Scheme Registry with the
following information:
<list style="hanging">
<t hangText="Authentication Scheme Name:">ClientCertificate</t>
<t hangText="Pointer to specification text:">This document</t>
<t hangText="Notes">This scheme does not rely on the Authorization header field.</t>
</list>
</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>
Eric Rescorla helped identify the problem and formulate this mechanism. Julian Reschke and
Michael Koeller provided excellent feedback. Andrei Popov observed that the information in
the TLS CertificateRequest message is needed so that clients can select an appropriate
certificate.
</t>
</section>
<!--
<appendix title="Change Log">
<t>[[The RFC Editor is requested to remove this section at publication.]]</t>
<t>Changes since -0-1:
<list style="symbols">
<t>Document created.</t>
</list>
</t>
</appendix>
-->
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4572.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6234.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-tls13.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-p7-auth.xml"?>
<reference anchor="X680">
<front>
<title>
Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic
notation
</title>
<author><organization>ITU-T</organization></author>
<date year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="8824-1:2002"/>
</reference>
<reference anchor="X690">
<front>
<title>
Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
</title>
<author><organization>ITU-T</organization></author>
<date year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="8825-1:2002"/>
</reference>
</references>
<references title="Informational References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-http2.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-tls-care.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 02:47:42 |