security: missing support for GSS encryption (not authentication)

[knz]

GSSAPI defines security primitives at multiple levels. It is really a competing stack to TLS.

In PostgreSQL, both GSSAPI client authentication and transport encryption are supported separately.

The "best practice" for deployment in a GSS environment is to use them hand-in-hand.

In CockroachDB, we only support GSSAPI client authentication, but not GSSAPI transport encryption.

Here's the combination of features:

Transport encryption	Endpoint authentication	Supported by pg	Supported by crdb
TLS	TLS	yes (recommended)	yes (recommended)
GSS	GSS	yes (recommended)	no
TLS	TLS+GSS	yes (not recommended)	yes
GSS	TLS	not supported	N/A

Why this matters:

• transport encryption is important to protect the connection against sniffing attacks.
• however this protection is only active under under the guarantee there was no MITM attack, i.e. it's only valid after authentication phase, when both sides of the connection have verified the identity of the other side.
• therefore, encryption only "works" if the client can verify the server's identity
• most client drivers don't know how to verify the server identity using GSSAPI unless GSSAPI transport encryption is enabled
• therefore, TLS encryption requires validation of the TLS server certificate in any case
• therefore, GSS authn over TLS enc requires a setup to both provides GSS tokens and TLS server certs to client apps, which is more work and more complex to operate than a pure-GSS, real single-sign-on infrastructure (what PostgreSQL supports).

So it's likely that CockroachDB would be better off supporting GSSAPI transport encryption (and the hostgssenc directives in the HBA config) in addition to TLS, to ease deployments with kerberos infrastructures.

Jira issue: CRDB-3975

[knz]

@thtruo @aaron-crl @dbist - could you review this and provide feedback about how much customer ask there is for this, and/or how much product value we would create by investing into it.

[dbist]

@BramGruneir any context from your customerbase you can add?

[dbist]

In PCI compliant environments this would be critical though having this capability with TLS makes it hard to justify one over the other. I think consolidating on TLS or GSS for both authN and transport encryption is a welcome addition but whether it is a high priority ask I won't know until customers ask for it.

[aaron-crl]

I'm not sure how much of a concern: "most client drivers don't know how to verify the server identity using GSSAPI unless GSSAPI transport encryption is enabled" is in practice. Let's see how much of a customer demand there is for this before delving too deep here.

There are other ways to solve the problem in a PCI environment that do not require application support for GSS. Depending on configuration, other transport level security mechanics are possible including things like IPSec at the OS level where the tunnel is negotiated using GSS primitives.

[dbist]

I evaluated #3 by connecting to a kerberized cluster with root user using cert and a kerberos principal as well. Both showed connection hostssl based on the behavior in the following doc. So given we support it but not necessary feel it is seamless, what should the next step be? So far I have not heard of any customer asking for GSS encryption in the same conversation with Cockroach but I know of one potential prospect that may care?

I200817 19:06:12.898466 2878 sql/pgwire/conn.go:226  [n1,client=172.28.1.7:56844,hostssl,user=sqlalchemy] 14 session terminated; duration: 240.3243ms

sqlalchemy is a kerberos principal.

[bdarnell]

When a user attempts to use GSS encryption, the server just logs an inscrutable message: unknown protocol version 80877104. We should add a better error message in this switch and get telemetry on attempted usage.

[knz]

adding telemetry for this in https://github.com/cockroachdb/cockroach/pull/63734

[data-matt]

@knz, I know this is the "cold storage", but I would like to check.

1. Would this cover GSS transport encryption for the client?
2. With both of authN and encryption, at that point we could kerberos authN cockroach cli in GSS based environments?

Thanks

[knz]

crdb CLI already can use kerberos authentication (albeit over TLS). We even test it in CI.