stoty commented on PR #17901: URL: https://github.com/apache/kafka/pull/17901#issuecomment-2589114017
Yes, this is security issue. Not in the context of the current Kafka code, which does not use QOP at all, but in the context of other components which may use the code either via running in the same JVM as Kafka, or by copying the implementation from Kafka. > You point out, any code using this should "check for QOP correctly". > I assume you mean calling .getNegotiatedProperty(Sasl.QOP). > However these classes return null on that method, which also seems > to be a violation of the [specification](https://github.com/openjdk/jdk23u/blob/master/src/java.security.sasl/share/classes/javax/security/sasl/Sasl.java#L102-L118). The docs should be more explicit, but: 1. The example in the [reference guide](https://docs.oracle.com/en/java/javase/23/security/java-sasl-api-programming-and-deployment-guide1.html#GUID-762BDD49-6EE8-419C-A45E-540462CB192B) explicitly checks for null as a possible result. 2. The non QOP capable mechanisms included in the JVM do not contain any special code to handle the QOP property. (i.e. return null) 3. The main SASL RFC4422 does mention security, but does not define any API for it. The QOP property is only defined in RFC2831 for the Digest mechanism. This all points to QOP being an optional feature, which can be completely ignored by mechanisms that do not support it, and makes it the responsibility of the caller to explicitly check that the desired protection has been negotaited. This change really helps buggy callers, by not letting them silently fall back to plaintext if they forget to check for the negotiated QOP value. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
