Page History

...

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.

...