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:

...

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.

...