Internet DRAFT - draft-thomson-httpbis-cant
draft-thomson-httpbis-cant
HTTPBIS M. Thomson
Internet-Draft Mozilla
Intended status: Standards Track July 4, 2014
Expires: January 5, 2015
Client Authentication over New TLS Connection
draft-thomson-httpbis-cant-01
Abstract
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.
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 http://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 January 5, 2015.
Copyright Notice
Copyright (c) 2014 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
(http://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.
Thomson Expires January 5, 2015 [Page 1]
Internet-Draft CANT July 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
2. Client Certificate Challenge . . . . . . . . . . . . . . . . 3
3. Client Certificate Challenge Parameters . . . . . . . . . . . 3
3.1. Distinguished Name Parameter ("dn") . . . . . . . . . . . 3
3.2. Fingerprint Parameters ("sha-256", ...) . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informational References . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Client authentication in HTTP sometimes relies on certificate-based
authentication of clients in Transport Layer Security (TLS)
([RFC5246], [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.
HTTP/2 [I-D.ietf-httpbis-http2] forbids the use of renegotiation,
except for at the very beginning of a connection. TLS 1.3
[I-D.ietf-tls-tls13] 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.
This document defines a new authentication scheme,
"ClientCertificate", for use in HTTP authentication challenges
[I-D.ietf-httpbis-p7-auth]. 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.
1.1. Conventions and Terminology
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
[RFC2119].
Thomson Expires January 5, 2015 [Page 2]
Internet-Draft CANT July 2014
2. Client Certificate Challenge
A new authentication scheme ([I-D.ietf-httpbis-p7-auth]) for the
"WWW-Authenticate" and "Proxy-Authenticate" header fields is defined
with the name "ClientCertificate".
This challenge cannot be satisfied by constructing an Authorization
header field [I-D.ietf-httpbis-p7-auth], it can only be satisfied by
making the request on a TLS connection where an appropriate
certificate has been provided by the client.
This authentication scheme cannot be used for "http" URIs.
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 "ClientCertificate" challenge as a trigger to open
a new connection and to use client authentication on that connection.
For the new connection, a client can use the mechanism in
[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.
[[TBD: In TLS 1.3 a client can unilaterally provide authentication
information without a request from the server.]]
[[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.
3. Client Certificate Challenge Parameters
In addition to the "realm" 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.
3.1. Distinguished Name Parameter ("dn")
The "dn" attribute includes a distinguished name for the certificate
authority. This matches the "certificate_authorities" value sent in
a TLS CertificateRequest handshake message. The "dn" parameter is
repeated for every distinguished name that is permitted.
Thomson Expires January 5, 2015 [Page 3]
Internet-Draft CANT July 2014
A distinguished name is defined in Abstract Syntax Notation number 1
(ASN.1) [X680] and encoded using Distinguished Encoding Rules (DER)
[X690] when used in TLS. The value of the "dn" parameter is a DER-
encoded distinguished name that is further encoded using base 64
[RFC4648] with the URL and filename safe alphabet. Multiple
alternative distinguished names are carried by repeating the "dn"
parameter.
dn-parameter = base64url
base64url = ALPHA / DIGIT / "_" / "~"
[[ 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. ]]
3.2. Fingerprint Parameters ("sha-256", ...)
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.
The name of fingerprint parameters is taken from the hash function
textual names registry defined in [RFC4572]. Clients MUST support a
"sha-256" parameter, which indicates that the fingerprint is
calculated using SHA-256 [RFC6234]. The value of a fingerprint
parameter is encoded using base 64 [RFC4648] with the URL and
filename safe alphabet.
sha-256-parameter = base64url
Like the "dn" parameter, fingerprint parameters can be repeated to
provide clients with alternative values.
Thomson Expires January 5, 2015 [Page 4]
Internet-Draft CANT July 2014
For example, a server could indicate that a set of permissible
certificates based on a SHA-256 fingerprint, as follows:
WWW-Authenticate: ClientCertificate realm="home",
sha-256=NjUwZjA0Mzcy..., sha-256=MzJiMTQ3ODF...
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.
Where fingerprints are provided with multiple hash function names, a
client can use any of the provided algorithms to determine which
certificate to provide.
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.
4. Security Considerations
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 "https" URIs.
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
Section 5).
HTTP/2 [I-D.ietf-httpbis-http2] 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 [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.
Thomson Expires January 5, 2015 [Page 5]
Internet-Draft CANT July 2014
5. Privacy Considerations
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.
Clients can initiate renegotiation immediately after the TLS
connection is established to ensure that passive observers aren't
able to view the selected certificate.
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.
Clients MUST avoid offering their client certificate if it will lack
confidentiality protection, unless they are explicitly configured to
send credentials in the clear.
6. IANA Considerations
IANA is requested to create an entry in the HTTP Authentication
Scheme Registry with the following information:
Authentication Scheme Name: ClientCertificate
Pointer to specification text: This document
Notes This scheme does not rely on the Authorization header field.
7. Acknowledgements
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.
8. References
Thomson Expires January 5, 2015 [Page 6]
Internet-Draft CANT July 2014
8.1. Normative References
[I-D.ietf-httpbis-p7-auth]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-26
(work in progress), February 2014.
[I-D.ietf-tls-tls13]
Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.3", draft-ietf-tls-tls13-01 (work
in progress), April 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[X680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ISO/IEC
8824-1:2002, 2002.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2002, 2002.
8.2. Informational References
[I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-13 (work in
progress), June 2014.
[I-D.thomson-tls-care]
Thomson, M., "Client Authentication Request Extension for
(D)TLS", draft-thomson-tls-care-00 (work in progress),
March 2014.
Thomson Expires January 5, 2015 [Page 7]
Internet-Draft CANT July 2014
Author's Address
Martin Thomson
Mozilla
331 E Evelyn Street
Mountain View, CA 94041
US
Email: martin.thomson@gmail.com
Thomson Expires January 5, 2015 [Page 8]
