[
https://issues.apache.org/jira/browse/KAFKA-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Bentley updated KAFKA-6272:
-------------------------------
Description:
[RFC 5802|https://tools.ietf.org/html/rfc5802] (SASL SCRAM) says:
{quote}
Before sending the username to the server, the client SHOULD
prepare the username using the "SASLprep" profile [RFC4013] of
the "stringprep" algorithm [RFC3454] treating it as a query
string (i.e., unassigned Unicode code points are allowed).
{quote}
ScramSaslClient uses ScramFormatter.normalize(), which just UTF-8 encodes the
bytes.
Likewise [RFC 4616|https://tools.ietf.org/html/rfc4616] (SASL PLAIN) says:
{quote}
The presented authentication identity and password strings, as well
as the database authentication identity and password strings, are to
be prepared before being used in the verification process. The
[SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED
preparation algorithm. The SASLprep preparation algorithm is recommended to
improve the likelihood that comparisons behave in an expected manner. The
SASLprep preparation algorithm is not mandatory so as to allow the server to
employ other preparation algorithms (including none) when appropriate. For
instance, use of a different preparation algorithm may be necessary for the
server to interoperate with an external system.
{quote}
But the comparison is simply on the bare strings.
This doesn't cause problems with the SASL components distributed with Kafka
(because they consistently don't do any string preparation), but it makes it
harder to, for, example, use the Kafka {{SaslClients}} on clients, but
configure a different {{SaslServer}} on brokers.
was:
[RFC 5802|https://tools.ietf.org/html/rfc5802] (SASL SCRAM) says:
{quote}
Before sending the username to the server, the client SHOULD
prepare the username using the "SASLprep" profile [RFC4013] of
the "stringprep" algorithm [RFC3454] treating it as a query
string (i.e., unassigned Unicode code points are allowed).
{quote}
ScramSaslClient uses ScramFormatter.normalize(), which just UTF-8 encodes the
bytes.
Likewise [RFC 4616|https://tools.ietf.org/html/rfc4616] (SASL PLAIN) says:
{quote}
The presented authentication identity and password strings, as well
as the database authentication identity and password strings, are to
be prepared before being used in the verification process. The
[SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED
preparation algorithm. The SASLprep preparation algorithm is recommended to
improve the likelihood that comparisons behave in an expected manner. The
SASLprep preparation algorithm is not mandatory so as to allow the server to
employ other preparation algorithms (including none) when appropriate. For
instance, use of a different preparation algorithm may be necessary for the
server to interoperate with an external system.
{quote}
But the comparison is simply on the bare strings.
This doesn't cause problems with the SASL components distributed with Kafka
(because they consistently don't do any string preparation), but it makes it
harder to, for, example, use the Kafka {{SaslClient}}s on clients, but
configure a different {{SaslServer}} on brokers.
> SASL PLAIN and SCRAM do not apply SASLPrep
> ------------------------------------------
>
> Key: KAFKA-6272
> URL: https://issues.apache.org/jira/browse/KAFKA-6272
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 1.0.0
> Reporter: Tom Bentley
> Assignee: Tom Bentley
> Priority: Minor
>
> [RFC 5802|https://tools.ietf.org/html/rfc5802] (SASL SCRAM) says:
> {quote}
> Before sending the username to the server, the client SHOULD
> prepare the username using the "SASLprep" profile [RFC4013] of
> the "stringprep" algorithm [RFC3454] treating it as a query
> string (i.e., unassigned Unicode code points are allowed).
> {quote}
> ScramSaslClient uses ScramFormatter.normalize(), which just UTF-8 encodes the
> bytes.
> Likewise [RFC 4616|https://tools.ietf.org/html/rfc4616] (SASL PLAIN) says:
> {quote}
> The presented authentication identity and password strings, as well
> as the database authentication identity and password strings, are to
> be prepared before being used in the verification process. The
> [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED
> preparation algorithm. The SASLprep preparation algorithm is recommended to
> improve the likelihood that comparisons behave in an expected manner. The
> SASLprep preparation algorithm is not mandatory so as to allow the server to
> employ other preparation algorithms (including none) when appropriate. For
> instance, use of a different preparation algorithm may be necessary for the
> server to interoperate with an external system.
> {quote}
> But the comparison is simply on the bare strings.
> This doesn't cause problems with the SASL components distributed with Kafka
> (because they consistently don't do any string preparation), but it makes it
> harder to, for, example, use the Kafka {{SaslClients}} on clients, but
> configure a different {{SaslServer}} on brokers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
