Subject: [TLS] a TLS server cannot be used in a use-case that requires privilege separation

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 27 Aug 2014 13:59:36 +0200

While trying to implement the privilege separation paradigm in various
TLS servers, I've come to a limitation of the TLS protocol. Unlike SSH,
a TLS server cannot use privilege separation to perform authentication
of the client.

That is if we have:
----------------  -------------
|authentication|  | TLS server|
|  server      |  |           |
----------------  -------------

there is no way for the authentication server to authenticate a user
connecting to the TLS server, without having the authentication server
perform the whole TLS handshake. The latter of course defeats the
purpose of privilege separation.

Why is that? The reason is that unlike ServerKeyExchange the client's
CertificateVerify message is defined as:
      struct {
           digitally-signed struct {
               opaque handshake_messages[handshake_messages_length];
           }
      } CertificateVerify;

meaning that the signature covers all the exchanged messages, and has no
field that can be set by the authentication server directly. Note that
in ServerKeyExchange the authentication server could have set a part or
the whole server_random[] and he could have used that as a proof that
the signature is on the current session. There can be very expensive
work-arounds, but are of significant complexity for the authentication
server, that again defeat the purpose of privilege separation.

I believe it is a nice goal to set for a future revision of TLS, to have
the CertificateVerify message modified to have the same properties as
the ServerKeyExchange message. That is, to have an additional fixed
field that is set by the server.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 27 Aug 2014 18:05:14 +0300

> server, that again defeat the purpose of privilege separation.

I have thought a bit of this (in context of "certificate attach", which
would be one of the two replacements for removed renegotiation, the other
being rekeying).

The basic idea is to derive a subkey from master secret that is then
used to prove certificate verification signatures are fresh[1].

Considering the order TLS 1.3 key exchange runs, the connection master
keys are known by the point either endpoint attempts to send certificates
or certificate verification messages (they have to be, the messages are
supposedly encrypted!).

> field that is set by the server.

It can't be set by the server, since that leads to security holes. It has
to be set by both client and server in collision-resistant manner.

[1] Recomendations to avoid attacks:
- MAC the messages (being inside TLS channel implicitly does so).
- Include public keys (or hashes thereof) into TBS data.
- Include sequence number in TBS data.
- Include endpoint role (client/server) into TBS data.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 29 Aug 2014 10:14:06 +0200

> to be set by both client and server in collision-resistant manner.

I don't really want to get into details because there is not much point
at this moment, but what I say above is an  _additional_ field to the
existing format. The existing format (hash of all previous messages)
already handles (one way or another) the requirements of the protocol
from a digital signature.

regards,
Nikos