Re: [TLS] Summary of discussion regarding spontaneuous authentication

I have the same concern as Joe: not all applications have a mechanism in place to request TLS client auth; such apps would not be able to use TLS1.3. Nor is it desirable to update all the application protocols that use TLS client auth. We need this mechanism in the TLS handshake, and perhaps we can do better than CertificateRequest: certificate type and trusted issuers list are not the only useful credential selection criteria.

Cheers,

Andrei

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey
Sent: Wednesday, October 22, 2014 9:52 AM
To: mrex@sap.com
Cc: tls@ietf.org
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication

On Wed, Oct 22, 2014 at 8:18 AM, Martin Rex <mrex@sap.com<mailto:mrex@sap.com>> wrote:
Martin Thomson wrote:
>
> We discussed the removal of the CertificateRequest and we will permit
> the client to unilaterally send authentication.
>
> The theory here is that clients tend to know whether they need to
> authenticate.

This looks like a bad idea to me.
The by far most important information in the current CertificateRequest
handshake message is the "certification_authorities" field, which indicates
certificate issuers which the server considers acceptable.
In SSLv3 and TLSv1.0 the certificate_authorities field was required
to be non-empty and no (server) behaviour was defined for the meaning
of an empty certification_authorities field in CertificateRequest.

The TLSv1.1 and TLSv1.2 specification contain a defect in that they
modified the PDU definition to allow an empty certification_authorities
field in CertificateRequest, but failed to define (require) a server
behaviour when the server does not send this information.
Without the requirement, that the serer MUST NOT abort the TLS handshake
when sending an empty certificate_authorities and receiving a certificate
which it does not trust, the use of an empty certificate_authorities
field does not make sense.

With recent versions of Lync, Microsoft seems to automatically create a
Lync-specific "SSL client identity" that works for nothing but Lync, but
will successfully interfere with SSL client credentials selections when
browsers are using an SSL client identity for accessing regular Web sites.

To make SSL client certificate authentication work reasonably
a CertificateRequest that conveys acceptable certificate_authorities
for the specific handshake is absolutely necessary.

Apple Safari seems to be notoriously broken when it comes to SSL client
certificate selection, because it fails to process the certificate_authorities
field from a CertificateRequest handshake message and remove obviously
unacceptable certs from the list of credentials that the user is
presented to select from.   I've had customers report connection
failures to our AppServers, and from the server-side error messages
I could see that the client was trying to connect with some appleid
certificate that our server didn't trust (and certainly never announced
in the CertificateRequest.certificate_authorities field.

Microsoft had a similar problem in WinHTTP in 2005
http://support.microsoft.com/kb/909425/en

After WinHTTP was fixed to provide the necessary information
to application callers, it is still necessary for application callers
to actually _use_ that information to select only acceptable certificates,
and that seems to take years to happen.
This is the fix for Office/WebDAV:
http://support.microsoft.com/kb/2647954/en

And Apple Safari 4 Windows also still has this bug today.

With the certificate_authorities field in the current CertificateRequest
handshake message, these are only (fixable) bugs.  With the removal
of the CertificateRequest handshake message, this problem would be
promoted to a TLSv1.3 protocol design flaw, and become unfixable.

[Joe]  I'm also concerned that removing the certificate request in favor of some application indication will leave behind applications that do not currently have a mechanism to communicate this.   If we are going to remove the certificate request I think we will need to communicate this information in the handshake itself or perhaps have a "reconnection request".

-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls