Re: FYI: proposal for client authentication in TLS

On Tue, Mar 11, 2014 at 10:22 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> I think that Julian covered some of the points here.
>
> > 2. I'm wondering if the message sent to the client can be expanded
> enough so
> > that the browser sometimes does not need to pop up a certificate picker.
> For
> > example, suppose I use a certificate with DN "CN=ynir,OU=users" to log
> in to
> > my SSL-VPN portal. The portal has stored this information in my browser
> via
> > a cookie. If a string representation of this DN in sent in the 401
> message,
> > the browser can open the new connection without bothering the user.
>
> I considered a number of options, but none seemed particularly useful.
>  The CertificateRequest in TLS already has a set of DNs.
>

Yes, but those DNs are for the CAs. I was thinking about something like
WWW-Authenticate: ClientCertificate RDN="CN=jsmith"

Thinking it over, though, this could have the undesired side-effect of
logging into other people's account when using a computer they had used
before (go to a business center in a hotel, and surf to "facebook.com" for
some fun)


>
> > 3. There is the issue of discovery. With current browsers (and TLS
> 1.0-1.2)
> > the server initiates a renegotiation. A new browser (with TLS 1.0-1.3)
> would
> > use this new mechanism. How does the server tell an old browser from a
> new
> > one?
>
> This can be very simple.  The server initiates renegotiation.  A
> browser that doesn't support this feature will accept the
> renegotiation and whatever happens today, happens.
>

Any browser coming out in the next 10 years will support renegotiation.
It's the new authentication method that you need to test for.

>
> A browser that supports this feature will reject the renegotiation (a
> no_renegotiation alert in response to the hello request) and the
> server can send its 401 response.
>