This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state:  Accepted "Under Discussion"

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA:

...

KIP-103 introduced listener names and listener-prefixed configuration options, enabling security options to be configured at individual listener level. But we continue to ignore `ssl.client.auth` configuration for SASL_SSL listeners. This KIP proposes to support TLS client authentication for SASL_SSL listeners for additional protection in security-critical deployments. In organizations where mutual TLS authentication is mandatory on all connections, this feature enables TLS authentication to be combined with SASL-based client identity.

Goals

...

1. Support mutual TLS authentication (mTLS) for SASL_SSL listeners to increase security of SASL_SSL and satisfy mandatory controls in security-critical deployments.
2. Since distribution of TLS certificates with client identity as DN adds significant certificate management overhead, many organizations are unable to use mTLS in external listeners with SSL as the security protocol. Support mTLS in SASL_SSL listeners to enable the use of shared client key stores with SASL-based client identity.
3. Retain current defaults that disable mTLS for both SSL and SASL_SSL unless explicitly configured.
4. Retain current semantics for the broker-wide `ssl.client.auth` configuration for compatibility.
5. Enable mTLS for SASL_SSL if listener-level `ssl.client.auth` configuration option is set to `required` or `requested`, supporting both mandatory and optional TLS client authentication.
6. Retain current KafkaPrincipal based on SASL authentication for SASL_SSL connections even if mTLS is enabled, avoiding any impact on authorization or quotas.

...

1. listener.name.<saslListenerName>.ssl.client.auth

If `ssl.client.auth` is configured without listener prefix and the broker has one or more SASL_SSL listeners, a warning will be logged to indicate that the option is applied only to SSL listeners and that the behaviour may change in future releases. We can consider removing the inconsistency for this configuration option and apply the value to all listeners in a future major release, either 4.0 or later.

Client Identity

SASL_SSL listeners will continue to use the client identity (KafkaPrincipal) established using SASL authentication regardless of whether mTLS is enabled. TLS client authentication is expected to be used for increased security of the connection, but not as a replacement for client identity. Authorization and quotas will continue to use the KafkaPrincipal established using SASL by default. Custom principal builders may use additional information from the SSL session for the KafkaPrincipal associated with SASL_SSL connections. Custom authorizers and custom quota callbacks may use additional information provided by custom principal builders for authorization decisions and quotas.

...

Brokers will start enforcing listener-prefixed  `ssl.client.auth` for SASL_SSL listeners. This is a breaking change for brokers that have been wrongly configured with `listener.name.<saslListenerName>.ssl.client.auth` to required|requested, expecting the configuration value to be ignored. We will document this in upgrade notes to ensure that users can remove the configuration before upgrading.

If broker-wide `ssl.client.auth` is configured in a broker with both SSL and SASL_SSL listeners, a warning will be logged to indicate that the option is applied only to the SSL listeners and that this behaviour may change in future releases. We can consider removing the inconsistency in the semantics of this configuration and apply the value to all listeners in a future major release, either 4.0 or later.

Test Plan

SASL_SSL with mutual TLS  authentication will be tested using unit and integration tests.

...