Subject: [TLS] Renegotiation and client authentication

From: Martin Thomson <[email-masked]>
Date: Sat, 8 Mar 2014 12:05:28 +0000

It seems like the main use case for renegotiation is client
authentication.  For two reasons:

 1. a need for client authentication is often discovered in the middle
of a session

 2. renegotiation provides confidentiality protection for the client certificate

I think that main user of this feature is HTTP.  If we are to get rid
of renegotiation (and we intend to for HTTP/2 if at all possible),
then we need some way to address these concerns.

It turns out that the main reason renegotiation causes issues is that
it can happen mid-stream, when you have the possibility for confusion
about the security properties of application data, particularly when
protocol atoms span the pair of ChangeCipherSpec messages associated
with the renegotiation.

A current proposal in HTTP/2 is to forbid renegotiation, except at the
very beginning of a connection, and only for client authentication.
(In TLS 1.3, we protect the client certificate, so the renegotiation
isn't needed at all.)  That addresses point 2.

We plan to have something in HTTP that causes a client to make a new,
client-authenticated connection, so that we can address point 1.

This results in a small problem.  In TLS, a server decides to request
client authentication.  On a new connection, there is no context
available at the server to decide to request that the client offer a
cert.

I've submitted a draft that describes a solution for this small part
of the problem.  Here:

http://datatracker.ietf.org/doc/draft-thomson-tls-care/

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 8 Mar 2014 08:19:12 -0800

There is a major requirement for renegotiation for protection of the client
credentials that is being used in various EAP methods as well.  HTTP is not
the only use of this.

Jim

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
> Sent: Saturday, March 08, 2014 4:05 AM
> To: [email-masked]
> Subject: [TLS] Renegotiation and client authentication
> 
authentication.  For
> two reasons:
> 
>  1. a need for client authentication is often discovered in the middle of
a
> session
> I think that main user of this feature is HTTP.  If we are to get rid of
> renegotiation (and we intend to for HTTP/2 if at all possible), then we
need
> some way to address these concerns.
> 
> It turns out that the main reason renegotiation causes issues is that it
can
> happen mid-stream, when you have the possibility for confusion about the
> security properties of application data, particularly when protocol atoms
span
> the pair of ChangeCipherSpec messages associated with the renegotiation.
> 
very
> beginning of a connection, and only for client authentication.
> (In TLS 1.3, we protect the client certificate, so the renegotiation isn't
needed
> at all.)  That addresses point 2.
> 
client-
> authenticated connection, so that we can address point 1.
> 
client
> authentication.  On a new connection, there is no context available at the
> server to decide to request that the client offer a cert.
> 
> I've submitted a draft that describes a solution for this small part of
the
> problem.  Here:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Sat, 8 Mar 2014 16:25:06 +0000

> credentials that is being used in various EAP methods as well.  HTTP is not

I'd be interested in learning whether a similar mechanism would suffice for you.

Nonetheless, this is a decision that is being made for HTTP.
Presumably EAP could continue to use renegotiation.

I recommend you explain your use case for renegotiation, since it's at
risk in TLS 1.3.

---

From: Adam Langley <[email-masked]>
Date: Sat, 8 Mar 2014 16:12:04 -0500

> client-authenticated connection, so that we can address point 1.

SPDY previously had the concept of a CREDENTIAL frame - a message that
contained a signature of a channel binding value. Obviously, channel
bindings are a bad idea until the master-secret is fixed, but that's
not a terminal problem. (HTTP/2 already requires ALPN support in the
TLS stack.)

The CREDENTIAL frame was dropped for complexity reasons, and it would
need some kind of request message to support the use-case suggested,
but it does offer the possibility of a nicer mechanism of client-auth
that doesn't tie deeply into the TLS stack.

Additionally, connection pooling in HTTP/2 complicates client-auth
because a TLS connection can only have a single client-cert.
CREDENTIAL had the client manage a logical space of possible
credentials at the server.

I'm not sure whether it's worth the complexity for something so rarely
used, but might be worth pondering.

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Martin Thomson <[email-masked]>
Date: Sun, 9 Mar 2014 07:46:03 +0000

> not a terminal problem. (HTTP/2 already requires ALPN support in the

Correct.  Since the whole point of this exercise is to address this
use case (client authentication) without relying renegotiation, I
think that we are safe in saying that we can rely on the master-secret
being stable.

Strangely enough, the CREDENTIAL frame did come up in discussions over
in HTTP-land.  The reaction wasn't that positive.  The perceived
complexity was too great.  That was the reason it was removed in the
first place.  There are still implementations out there that don't
have RFC 5705 support, or don't want to rely on it.

> because a TLS connection can only have a single client-cert.

Part of the proposed solution here would be to strongly recommend
(with MUST) that connections aren't pooled when client authentication
is requested.  See the HTTP part of the solution, here:

http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/

--Martin

p.s., I'm a little surprised that you didn't suggest ALPN for this one
too, a number of other people did :)

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 9 Mar 2014 18:13:14 +0100

> I recommend you explain your use case for renegotiation, since it's at

Btw, I have a use case for renegotiation that I would like to check here.
The WebID over TLS spec needs it as things stand at present:

http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence

It's all a question of politeness: of when one should ask a client for its identity.
We need to be able to allow a well behaved site to respect people's desire for anonymity
as long as possible.
	On many sites most pages may not need client authentication at all, and only a few 
pages (which may only be accessible after a longer browse through the site) may require it. Not
having client authentication renegotiation would require the client to authenticate to the 
site before even having seen the first page. This would be akin to not allowing someone 
into a shop before they showed their ID. It may be fine in a war/military situation, but not in a 
commercial  environment. In all shops I know of one allows people to browse what is available
without bothering them for their identity. Allowing a client to browser information is what
is going to allow the client to make a decision as to the value of revealing her identity.

Also some pages MUST NOT have client authentication. For the WebID protocol this would
be the WebID profile page. Having client authentication on that page could result in an
infinite loop, since servers can be clients too in that spec. Consider what would happen
in step 6 of the spec without renegotiation:
  If Alice's server was required to authenticate to get Bob's profile, and used the WebID
enabled certificate of Alice, then Bob's server would need to authenticate Alice. This would
require it to get Alice's profile. But if that also required authentication we'd be back at 
step 6 of the diagram mentioned above, and there would be deadlock.

----

But perhaps with "Client Authentication Request Extension for (D)TLS" [1] mentioned earlier in this
thread the HTTP2.0 spec could be updated to allow the server in a 401 to express it's capacity
to accept TLS authentication too - perhaps even WebID certificate authentication. 
In which case browsers would be able to offer that option to their end users.

-----

Perhaps this would also solve the current problem with the need for servers to be set up in WANT or NEED 
mode (which is also a problem of politeness) and which I think is tied to 
section 7.4.6 of RFC5246 [2]. If a server is in WANT mode and asks the client for a certificate,
but the client does not wish to authenticate, then the server can continue - by for example politely
returning an HTTP 401 and a human readable error message, or by redirecting to another page 
( a login page with username-password for example ). In NEED mode the server breaks down the connection
in an ugly way - since the error handling of TLS is much less advanced than that of HTTP.
I have not yet worked out why some clients - such as curl or Opera ) only send a certificate when 
the server is in NEED mode, and not in WANT mode. ( please let me know ).

But again with "Client Authentication Request Extension for DTLS" that could be left to the HTTP
layer to ask the client for authentication, and so perhaps that problem would go away too...

Henry

[1] http://datatracker.ietf.org/doc/draft-thomson-tls-care/
[2] http://tools.ietf.org/html/rfc5246#page-55

7.4.6.  Client Certificate

   When this message will be sent:

      This is the first message the client can send after receiving a
      ServerHelloDone message.  This message is only sent if the server
      requests a certificate.  If no suitable certificate is available,
      the client MUST send a certificate message containing no
      certificates.  That is, the certificate_list structure has a
      length of zero.  If the client does not send any certificates, the
      server MAY at its discretion either continue the handshake without
      client authentication, or respond with a fatal handshake_failure
      alert.  Also, if some aspect of the certificate chain was
      unacceptable (e.g., it was not signed by a known, trusted CA), the
      server MAY at its discretion either continue the handshake
      (considering the client unauthenticated) or send a fatal alert.

Social Web Architect
http://bblfish.net/

---

From: Martin Thomson <[email-masked]>
Date: Sun, 9 Mar 2014 18:34:22 +0100

> http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence

This looks like exactly the use case that this is intended to address.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 09 Mar 2014 16:55:25 -0400

> http://datatracker.ietf.org/doc/draft-thomson-tls-care/

this document seems sensible to me.

minor typo in the top of page 3:

   the client needs to provide some indication that it might
   need to be authentication

this should probably be:

   the client needs to provide some indication that it might
   need to be authenticated

Regards,

	--dkg

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Mar 2014 00:22:27 +0200

> http://datatracker.ietf.org/doc/draft-thomson-tls-care/

Hi, Martin

I was the one who described this use case at the TLS meeting. I agree that this would solve the use case. 

Thinking about it a bit further, a TLS server (could be a web server, but this mechanism in generic for TLS) would have three possible configurations:
 1. Always request a client certificate
 2. Never request a client certificate
 3. Only request a client certificate if the client offers the new extension.

For the banking and SSL-VPN websites that I talked about, #3 would be appropriate. 

You also need a document describing how HTML or HTTP is used to trigger such a connection
   <a href=“/loginwithcerts.html” clientauth=“yes”>Login with certificates</a>

Or maybe a new response code that says “retry with client auth”. 

Either way, we should think what would make better sense to application developers.

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Sun, 9 Mar 2014 15:54:22 -0700

>  3. Only request a client certificate if the client offers the new extension.

I don't get this last one. Why doesn't the client just show the
certificate and proof that it did the negotiation instead of telling
the server to ask for it? I'm sure there is a good reason for it which
I don't see, but as it stands it's like the recurrent laryngeal nerve
of the giraffe: the result of lots of small, sensible changes, leading
to a facially ridiculous result. (For those not aware of the details
of giraffe anatomy, this is a nerve that goes from the skull down to
the aorta in the chest of the giraffe, wraps around it, and comes back
up the neck to innervate the larynx, just a few inches away from the
start).

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 10 Mar 2014 01:25:47 +0200

On Sun, Mar 09, 2014 at 03:54:22PM -0700, Watson Ladd wrote:
> the server to ask for it? 

TLS Spec says that client MUST use one of the algos mentioned in
CertificateRequest (but there is no direct MUST NOT or SHOULD NOT
about sending Certificate/CertificateVerify without CertificateRequest).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Mar 2014 09:14:19 +0100

>  1. Always request a client certificate

FYI, most software has a secondary configuration on this point:
whether to reject the connection if a certificate is not provided.
This makes the request from the server optional to comply with (or
not).

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Mar 2014 09:17:07 +0100

> about sending Certificate/CertificateVerify without CertificateRequest).

I don't know what this does to existing implementations, but I'd
imagine that it would be surprising.  More so if the algorithm or
certificate type wasn't a supported type.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 10 Mar 2014 10:21:40 +0100

> authentication.  For two reasons:

Only if you restrict it to the HTTPS protocol. Otherwise renegotiation
is mainly used to rekey and reset the TLS and DTLS record sequence
numbers.

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Mar 2014 10:51:14 +0100

On 10 March 2014 10:21, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> renegotiation

This is exactly the sort of thing I wanted to flush out.  There are
two questions we need to resolve:

 - whether we can avoid having to define renegotiation for TLS 1.3

 - whether we can avoid having to deal with renegotiation for HTTP
(HTTP/2 primarily)

This effort is primarily focused on addressing the latter, which will
help us unblock some critical HTTP/2 stuff.

For the former, when ekr went through the reasons for having
renegotiation, it was pointed out that a small change could avoid the
sequence number exhaustion/key overuse issues.  If we can work on
progressively identifying important uses and providing
non-renegotiation-based ways to address them, that would be good.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Mar 2014 13:35:13 +0200

> This makes the request from the server optional to comply with (or

Yes, but the user experience is the same whether the server has marked the
client authentication as optional or mandatory - the browser pops us a
certificate selector, and you don't want that on the landing page.

> http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/

I would have preferred a response code (like "4xx client authentication
needed"), but this works as well.

How does the server tell new clients (that support this extension) apart
from older clients, for which you still have to use renegotiation (in TLS
1.2 or course...)? Sending this to old clients would result in breakage.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Mar 2014 13:43:32 +0200

> the server to ask for it?

In TLS the server has to request a certificate before the client can
provide one. There is, however, a UI issue with the server requesting a
certificate: the browser pops up a "certificate picker" asking you to
choose which certificate to show. So if I go to https://www.bigbank.com  or
https://sslvpn.example.com  I don't want to get the picker immediately.
Maybe I just want to read generic information about the bank.

So there will typically be a button or a hyperlink, and when I click that,
the certificate picker pops up. But the only way the server knows that I
clicked this is that it gets a request (like "GET /login_with_certs
HTTP/1.1"). Today when it gets this request, it triggers the TLS layer to
send a HelloRequest, and cause a renegotiation with a certificate request.
Martin's proposal is to signal to the client in the HTTP layer to initiate
a whole new connection, and in this new connection the client signals to
the server that it is OK to request a certificate.

HTH

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Mar 2014 13:32:40 +0100

> 1.2 or course...)? Sending this to old clients would result in breakage.

Good question.  Probably best pursued in httpbis though.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 10 Mar 2014 14:03:36 +0100

On 2014-03-10 12:43, Yoav Nir wrote:
> 
> 
> 
> On Mon, Mar 10, 2014 at 12:54 AM, Watson Ladd <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> In TLS the server has to request a certificate before the client can provide one. There is, however, a UI issue with the server requesting a certificate: the browser pops up a "certificate picker" asking you to choose which certificate to show. So if I go to https://www.bigbank.com  or https://sslvpn.example.com  I don't want to get the picker immediately. Maybe I just want to read generic information about the bank.
> 
> So there will typically be a button or a hyperlink, and when I click that, the certificate picker pops up. But the only way the server knows that I clicked this is that it gets a request (like "GET /login_with_certs HTTP/1.1"). Today when it gets this request, it triggers the TLS layer to send a HelloRequest, and cause a renegotiation with a certificate request. Martin's proposal is to signal to the client in the HTTP layer to initiate a whole new connection, and in this new connection the client signals to the server that it is OK to request a certificate.
> 

If this is addressed, server-initiated logout must be addressed as well,
otherwise application-level client-side PKI login will remain the
best solution.  Google's U2F does this so it can't be that bad.

Personally I think it is too late making HTTPS CCA (Client Certificate
Authentication) generally useful since this would affect every part of
the infrastructure and that takes forever.

Anders

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 10 Mar 2014 10:34:51 -0400

> It seems like the main use case for renegotiation is client authentication.  For two reasons:

I agree.  Does it make sense to therefore define a new "who are you" message that the client can send to the server?

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Mar 2014 15:41:19 +0100

> I agree.  Does it make sense to therefore define a new "who are you" message that the client can send to the server?

Do you mean ClientHello?  Or did you mean server to client?

I've tried to capture that in
http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 10 Mar 2014 10:55:07 -0400

> Do you mean ClientHello?  Or did you mean server to client?

Argh.  I meant server to client.  Thanks.

	/r$

---

From: Geoffrey Keating <[email-masked]>
Date: 10 Mar 2014 12:06:52 -0700

> help us unblock some critical HTTP/2 stuff.

For HTTP, the most common case of renegotiation seems to be requesting
a client certificate.  You could deal with this in TLS 1.3 by allowing
the server (or, either end) to request a certificate validation at any
point, without otherwise renegotiating the connection parameters.

What is signed would need to be a hash of all the handshake messages
to this point, or some other unique identifier of this connection.
TLS 1.3 will need to provide such an identifier anyway, so using it
here makes sense.

I'd suggest making this the only way that signing certificates are
used in the protocol, so instead of the current approach where the
server signs the DH parameters and the cookies, the connection would
start anonymously and the server would authenticate the connection
separately.  This can even happen encrypted, with no extra
round-trips: send the verifier and associated certificates immediately
after the ChangeCipherSpec message.

---

From: Bill Frantz <[email-masked]>
Date: Mon, 10 Mar 2014 12:35:03 -0700

>Argh.  I meant server to client.  Thanks.

This idea seems to be the right direction. We already have a 
encrypted connection. A message from server to client, "who are 
you" either at the TLS layer or at the HTTP layer would allow 
the client to return its certificate.

If we also use the client's private key to sign the master 
secret, or something derived from the master secret, we have a 
second check that there is no MIM.

Cheers - Bill

--------------------------------------------------------------
Bill Frantz        | There are now so many exceptions to the
408-356-8506       | Fourth Amendment that it operates only by
www.pwpconsult.com | accident.  -  William Hugh Murray

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 10 Mar 2014 16:03:03 -0400

Sever sends a challenge, client signs it.  No need to tie the proof of possession to the channel, since we're explicitly NOT renegotiating any of the  channel params.

	/r$

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 10 Mar 2014 16:14:43 -0400

> Sever sends a challenge, client signs it.  No need to tie the proof of possession to the channel, since we're explicitly NOT renegotiating any of the  channel params.

I think this is a bad idea; it doesn't defend against replay attacks at
all, so if you authenticate to https://evilserver.example/, that server
could turn around and impersonate you to https://yourjob.example/, which
would be a Bad Thing.

The certification needs to be bound to the channel, and to be on the
safe side, it shouldn't be over data that either party has full control
over.

	--dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 10 Mar 2014 16:32:03 -0400

> I think this is a bad idea; it doesn't defend against replay attacks at all, so if you authenticate to https://evilserver.example/, that server could turn around and impersonate you to https://yourjob.example/, which would be a Bad Thing.

Hm.  Only if evilserver.gov was able to send you the exact same challenge that yourjob.com would be sending you. I suppose so.  So the challenge could be a nonce hashed with the pre-master secret, which is then signed.  But this is also off the top of my head.  The concept, "who are you" separate from general renegotiation, seems like a good one to me.

	/r$

---

From: Bill Frantz <[email-masked]>
Date: Mon, 10 Mar 2014 14:29:57 -0700

On 3/10/14 at 1:03 PM, [email-masked] (Salz, Rich) wrote:

>Sever sends a challenge, client signs it.  No need to tie the 
>proof of possession to the channel, since we're explicitly NOT 
>renegotiating any of the  channel params.

Given the number of attacks on the CA system*, I was looking for 
a second check that there was no MITM. Including channel binding 
would be cheap and easy. It would also occur in many cases 
before really important secrets were exchanged.

Of course checking for MITM would make deep inspection firewalls 
harder. But that might be a good thing.

Cheers - Bill

* The coding errors revealed in iOS and GNUTLS, The number of 
dead CAs still accepted by major browsers, the susceptibility of 
CAs to legal action, are just some of the vulnerabilities in the 
current system.
-----------------------------------------------------------------------
Bill Frantz        |Security, like correctness, is| Periwinkle
(408)356-8506      |not an add-on feature. - Attr-| 16345 
Englewood Ave
www.pwpconsult.com |ibuted to Andrew Tanenbaum    | Los Gatos, 
CA 95032

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Mar 2014 08:24:38 +0200

On Mon, Mar 10, 2014 at 11:29 PM, Bill Frantz <[email-masked]> wrote:

>  Sever sends a challenge, client signs it.  No need to tie the proof of
>> possession to the channel, since we're explicitly NOT renegotiating any of
>> the  channel params.
>>
>
> Given the number of attacks on the CA system*, I was looking for a second
> check that there was no MITM. Including channel binding would be cheap and
> easy. It would also occur in many cases before really important secrets
> were exchanged.
>
> Of course checking for MITM would make deep inspection firewalls harder.
> But that might be a good thing.
>

Deep inspection firewalls are entirely disabled by client certificates.
This would not be so if client certificate authentication was moved  to the
HTTP layer rather than the TLS layer, but for now, such firewalls can
either allow such connections to pass uninspected or block them.

Yoav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 11 Mar 2014 09:36:05 +0100

On Mon, 2014-03-10 at 16:32 -0400, Salz, Rich wrote:
> > I think this is a bad idea; it doesn't defend against replay attacks
> at all, so if you authenticate to https://evilserver.example/, that
> server could turn around and impersonate you to
> https://yourjob.example/, which would be a Bad Thing.
> 
> Hm.  Only if evilserver.gov was able to send you the exact same
> challenge that yourjob.com would be sending you. I suppose so. 

That is trivial for evilserver to achieve. There is a reason that client
authentication is tied to the channel and part of the key exchange.

regards,
Nikos