Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

From: Cas Cremers <[email-masked]>
Date: Mon, 13 Feb 2017 12:32:53 +0000

Thanks everyone, we will try to wrap up the situation and remaining issues.

TL;DR:
The problem that we identified applies to fewer situations in the real
protocol than we thought, because of our previously coarse modelling of the
AEAD. However, the main issue remains: the client never receives an in-band
confirmation that the client authentication has succeeded. From a formal
perspective this means there can be a mismatch between the view of the
client and the server. We suggest this is made explicit in the security
guarantees section.

Furthermore, supposing the client has a way to determine whether
authentication was successful, there still exists the possibility that the
client receives messages whose context is ambiguous. In more detail:

   1. Ordering of messages, which is enforced by the AEAD, means that
   property (A) we discussed is not an issue. The client knows that any
   message sent after the certificate will arrive (be processed) at the
   server after the certificate.
   2. Property (B) is still an open issue for both the initial handshake
   and post-handshake. Application messages sent by the server can easily
   be delayed (by network or adversary) and the client cannot determine
   whether this message was sent before or after the authentication was
   received and therefore under the assumption that the client is an
   authenticated peer or not.
   3. There is a small asymmetry between the initial handshake and
   post-handshake. If the client authenticates in the initial handshake,
   receiving post-handshake messages (such as a NewSessionTicket), must
   come after the client's certificate/finished is processed. This is enforced
   cryptographically since the RMS is computed using the Finished messages. In
   contrast, NST messages can arrive ambiguously before/after a post-handshake
   client authentication.

The main takeaway is that the client never really receives any
acknowledgement of whether the verification provided was successful or
rejected through an in-band mechanism.

The context of the keys does not include the client’s authentication status
(nor the client’s certificate), and is the same in both cases. From a
formal analysis point of view, this results in a mismatch where the client
and server may not agree on the mutual authentication status, which is the
main point we wanted to raise.

Assuming now that the key context will not be changed, we suggest to
explicitly mention in the security guarantees section that the client,
after sending authentication messages, cannot be sure at any point that the
server has received these messages and considers the connection to be
mutually authenticated. If the client wishes to obtain such a guarantee, it
has to be informed by the server’s application.

Best,

Cas Cremers,
Marko Horvat,
Jonathan Hoyland,
Thyla van der Merwe, and
Sam Scott

---

From: David Wong <[email-masked]>
Date: Tue, 14 Feb 2017 15:21:50 +0000

I can see this problem even in the case where the client sends an empty Certificate message during the handshake. If the application does not tell the client what happened, a NewSessionTicket has no way of indicating if it will include client-auth in the next session.

David

---

From: David Benjamin <[email-masked]>
Date: Tue, 14 Feb 2017 15:44:55 +0000

NewSessionTicket always includes in-handshake client auth. The resumption
secret can't even be derived without it.

On Tue, Feb 14, 2017 at 10:21 AM David Wong <[email-masked]>
wrote:

> I can see this problem even in the case where the client sends an empty
> Certificate message during the handshake. If the application does not tell
> the client what happened, a NewSessionTicket has no way of indicating if it
> will include client-auth in the next session.
>
> David
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 14 Feb 2017 18:14:25 +0200

> main point we wanted to raise.

It is not just problem of "context of keys". TLS 1.3 explicitly allows
silently rejecting client authentication. No fatal error, no NAK, no
nothing.

Which impiles that client and server can disagree even about status of
in-handshake authentication. Including in resumption, even if the RMS
supposedly includes client's authentication status in its context.

This problem actually cuts protocol layers, and that's why it is so
hard. And things get even more fun when resumption is involved.

I expect there will be quite a bit of implementations that won't
trigger any errors if EE key can be parsed and the client signature
verified (due to layering rendering that way pretty natural).
 
> has to be informed by the server’s application.

See above why changing "context" won't fix the problem.

And yeah, "if you want to be sure, ask application layer" is
probably about the best that can be done.

-Ilari

---

From: David Wong <[email-masked]>
Date: Tue, 14 Feb 2017 16:18:27 +0000

On Feb 14 2017, at 4:44 pm, David Benjamin <[email-masked]> wrote:

NewSessionTicket always includes in-handshake client auth. The resumption secret can't even be derived without it.

Oups, my bad. What about if the client do send a certificate, but the server decides not to accept it, but goes on with the connection (I think nothing in the spec says that the server needs to terminate the connection if the client cert is not good).

---

From: Andrei Popov <[email-masked]>
Date: Tue, 14 Feb 2017 18:15:36 +0000

Is it important for the client to know, from the TLS stack itself, whether client authentication succeeded or not? My assumption (perhaps incorrect) has been that it is the server that cares about the client's identity (or identities) in order to make an authorization decision.

This thread also seems to consider client authentication a binary state: the client is either authenticated, or not. In practice, the client may assert multiple identities, and the server may grant various levels of access.

Also, why should the client care whether session ticket X includes client identity Y? If a client resumes a TLS session with a session ticket that does not include (or point to) a client authenticator needed to satisfy the client's request, the server can initiate client auth (or deny the request).

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of David Wong
Sent: Tuesday, February 14, 2017 8:18 AM
To: David Benjamin <[email-masked]>
Cc: Cas Cremers <[email-masked]>; [email-masked]
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

On Feb 14 2017, at 4:44 pm, David Benjamin <[email-masked]<mailto:[email-masked]>> wrote:
NewSessionTicket always includes in-handshake client auth. The resumption secret can't even be derived without it.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Feb 2017 10:07:39 +1100

On 15 February 2017 at 03:18, David Wong <[email-masked]> wrote:
> Oups, my bad. What about if the client do send a certificate, but the server
> decides not to accept it, but goes on with the connection (I think nothing
> in the spec says that the server needs to terminate the connection if the
> client cert is not good).

Then it is up to the server to remember this condition.  If it resumes
and later assumes that the client certificate is in place, then it's a
big problem.  Of course, it's easier to NOT remember a client
certificate, so I expect that failure mode to be rare.

---

From: David Wong <[email-masked]>
Date: Wed, 15 Feb 2017 10:07:16 +0000

I think I can agree that this is an application problem, not a TLS problem. But this should be mentioned in the spec nonetheless as Cas pointed.

---

From: [email-masked] (Martin Rex)
Date: Wed, 15 Feb 2017 12:00:29 +0100 (CET)

I think the issue is more about the "principle of least surprise".

The client needs to know whether it offered authentication by client cert
and which client cert it offered.  Whether the server accepted it, and
caches the accepted cert in the session or in a session ticket, is
the business of the server (it may help in troubleshooting to know,
but should not be necessary for application flow control).

Clients asserting multiple identities sounds extremely awkward to me.

We do have clients in posession of multiple client certs, but our application
must specify _before_ each TLS handshake which client identity to use (and
this information is necessary for client-side session caching,
and client-side session lookup.

There is a significant difference between cached sessions where a
specific client cert was used (or at least offered by the client),
and cached sessions where no client cert was offered.

If a client tries to access a resource through a session that is
authenticated with SSL client cert A, and the server-side authorization
decision denies access to client cert A, then this will typically
result in an access failure, _without_ the server asking for a different cert.

When no client cert has been used in a session then access to a resource
that requires a (particular) client cert may result in a request of the
server for a client cert (renegotiation up to TLSv1.2) after seeing the
request--provided that the server supports renegotiation.

-Martin

Andrei Popov wrote:
>
> Is it important for the client to know, from the TLS stack itself,
> whether client authentication succeeded or not? My assumption
> (perhaps incorrect) has been that it is the server that cares about
> the client's identity (or identities) in order to make an
> authorization decision.
> 
> This thread also seems to consider client authentication a binary state:
> the client is either authenticated, or not. In practice, the client may
> assert multiple identities, and the server may grant various levels
> of access.
> 
> Also, why should the client care whether session ticket X includes client
> identity Y? If a client resumes a TLS session with a session ticket that
> does not include (or point to) a client authenticator needed to satisfy
> the client's request, the server can initiate client auth (or deny the
> request).
> 
> Cheers,
> 
> Andrei

---

From: Cas Cremers <[email-masked]>
Date: Wed, 15 Feb 2017 12:02:38 +0000

Hi,

I think the idea that "this is the best we can do" depends on quite a
number of assumptions. In theory, I think it is easy to fix, but of course
in the design space we're in, the trade offs are more complex.

We also have to consider the non-web use cases where one might expect more
symmetric guarantees between client and server.

Indeed, "principle of least surprise": I personally find this lack of
agreement for the client surprising, i.e., the fact that the client it is
not informed by the server on its authentication status, especially since
the server asked for the certificate in the first place. This is even the
case if the server doesn't implement the reject-cert-but-continue option,
for the post-handshake authentication.

I can imagine applications that depend on the assumption that the client
knows that it has been authenticated, to both decide what it should send,
or to correctly interpret what it is receiving.

To me, this means we need to at least document this. We'll draft a PR.

Best,

Cas

---

From: Andrei Popov <[email-masked]>
Date: Wed, 15 Feb 2017 18:27:14 +0000

Yes, I agree that it is useful to mention this in the spec.

From: David Wong [mailto:[email-masked]]
Sent: Wednesday, February 15, 2017 2:07 AM
To: Andrei Popov <[email-masked]>
Cc: David Benjamin <[email-masked]>; Cas Cremers <[email-masked]>; [email-masked]
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

---

From: David Wong <[email-masked]>
Date: Wed, 15 Feb 2017 19:48:59 +0000

On Feb 15 2017, at 7:27 pm, Andrei Popov <[email-masked]> wrote:

It would be nice is to have two different PRs solving this issue. One mentioning this as a potential issue that the application must be aware of. I've seen things like that for example in rfc 5746: https://tools.ietf.org/html/rfc5746#section-5

>  While this extension mitigates the man-in-the-middle attack described
in the overview, it does not resolve all possible problems an
application may face if it is unaware of renegotiation. For example,
during renegotiation, either the client or the server can present a
different certificate than was used earlier. This may come as a
surprise to application developers (who might have expected, for
example, that a "getPeerCertificates()" API call returns the same
value if called twice), and might be handled in an insecure way.

A second PR could try to tackle this by adding a new message, for example an "AcknowledgeClientAuthentication" message that the server would send to confirm (or not) the validation of the client certificate. I think this would add a bit of complexity for less "surprise". I'm not too keen on this, and I think this could be added as an extension instead, but I think it would be nice to have to see if it integrates nicely in the current draft.

David

---

From: David Benjamin <[email-masked]>
Date: Wed, 15 Feb 2017 19:52:26 +0000

On Wed, Feb 15, 2017 at 2:49 PM David Wong <[email-masked]>
wrote:

> It would be nice is to have two different PRs solving this issue. One
> mentioning this as a potential issue that the application must be aware of.
> I've seen things like that for example in rfc 5746:
> https://tools.ietf.org/html/rfc5746#section-5
>
> in the overview, it does not resolve all possible problems an application
> may face if it is unaware of renegotiation. For example, during
> renegotiation, either the client or the server can present a different
> certificate than was used earlier. This may come as a surprise to
> application developers (who might have expected, for example, that a
> "getPeerCertificates()" API call returns the same value if called twice),
> and might be handled in an insecure way.
>
> A second PR could try to tackle this by adding a new message, for example
> an "AcknowledgeClientAuthentication" message that the server would send to
> confirm (or not) the validation of the client certificate. I think this
> would add a bit of complexity for less "surprise". I'm not too keen on
> this, and I think this could be added as an extension instead, but I think
> it would be nice to have to see if it integrates nicely in the current
> draft.
>

Post-handshake auth exists basically entirely to service HTTP/1.1 reactive
client certificate which was previously hacked on via renegotiation. I
think we should not make this feature any more complicated than absolutely
necessary to support this mode, and we should not add more bells and
whistles to it to encourage further use.

For the HTTP/1.1 use case, this is not necessary because it's reasonable
for client/server to agree that the server will not send any more data for
that request until it has processed the client's authentication messages.

David

---

From: Andrei Popov <[email-masked]>
Date: Wed, 15 Feb 2017 20:01:17 +0000

I agree with David: a different client auth mechanism is in the works for HTTP/2.

Cheers,

Andrei

From: David Benjamin [mailto:[email-masked]]
Sent: Wednesday, February 15, 2017 11:52 AM
To: David Wong <[email-masked]>; Andrei Popov <[email-masked]>
Cc: Cas Cremers <[email-masked]>; [email-masked]
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

On Wed, Feb 15, 2017 at 2:49 PM David Wong <[email-masked]<mailto:[email-masked]>> wrote:
On Feb 15 2017, at 7:27 pm, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

>  While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation. For example, during renegotiation, either the client or the server can present a different certificate than was used earlier. This may come as a surprise to application developers (who might have expected, for example, that a "getPeerCertificates()" API call returns the same value if called twice), and might be handled in an insecure way.

Post-handshake auth exists basically entirely to service HTTP/1.1 reactive client certificate which was previously hacked on via renegotiation. I think we should not make this feature any more complicated than absolutely necessary to support this mode, and we should not add more bells and whistles to it to encourage further use.

For the HTTP/1.1 use case, this is not necessary because it's reasonable for client/server to agree that the server will not send any more data for that request until it has processed the client's authentication messages.

David

---

From: [email-masked] (Martin Rex)
Date: Thu, 16 Feb 2017 12:54:09 +0100 (CET)

> that request until it has processed the client's authentication messages.

Well, the funny thing here is how HTTP/1.1 POST works when the server
asks for a certificate through renegotiation.  The client-side data,
which may be a multi-megabyte upload, will be performed entirely before
the renegotiation, and any renegotiation requested by the server might
be sitting in the incoming network buffer and ignored by the
client.  Depending on how much data the server expects, and the bandwith
available to the client upstream, the server might not even want to start
the renegotiation handshake before the client has completed transmission,
because this might result in a connection termination (when the client
needs more than 2*MSL for the upload and doesn't perform any recv() / SSL_Read
on the socket while uploading.

-Martin