On Wed, 9 Feb 2022 11:10:14 GMT, Michael Osipov <d...@openjdk.java.net> wrote:
>>> @martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't >>> everything protocol related a fail-fast issue? E.g., if the socket is up >>> and running, but the LDAP message is rejected can we assume that all >>> subsequent servers for the same resolution will reject the request as well >>> before authentication has happened? >> >> It looks to me that it's not only a fail-fast issue because the state on the >> directory side might be altered by each try, as it happened in the reported >> case. In other words, the client might cause a denial-of-service blocking an >> account by trying multiple times the same incorrect authentication >> credentials on each resolved server. >> >> In regards to the 2nd question, I guess that we cannot assume that. But the >> revert is intended for failed authentication only. >> >> Is there a risk that you foresee by reverting the failed-authentication >> behavior back to pre-JDK-8160768? > >> > @martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't >> > everything protocol related a fail-fast issue? E.g., if the socket is up >> > and running, but the LDAP message is rejected can we assume that all >> > subsequent servers for the same resolution will reject the request as well >> > before authentication has happened? >> >> It looks to me that it's not only a fail-fast issue because the state on the >> directory side might be altered by each try, as it happened in the reported >> case. In other words, the client might cause a denial-of-service blocking an >> account by trying multiple times the same incorrect authentication >> credentials on each resolved server. > > Let me add a few points for consideration from my usecases, since I don't use > any password-based authentication with SASL and Active Directory only: > * `SASL EXTERNAL`: What if the certificate is rejected? Trust store is not > properly populated, CRL misconfigured, etc. Will an exception also thrown > here? > * `SASL GSSAPI/GSS-SPNEGO`: Dir server does not manage creds, but KDC does. I > am thinking whether fail fast is reasonable. SPN not registered, next server > might have. replay/out of sequence, etc. > >> In regards to the 2nd question, I guess that we cannot assume that. But the >> revert is intended for failed authentication only. > > But the auth is part of the LDAP message as well since the auth does not > happen out of band. I would expect that any non-transport issue should fail > fast. > >> Is there a risk that you foresee by reverting the failed-authentication >> behavior back to pre-JDK-8160768? > > Not really, I virtually never had problems, thought might need annotations > when this does not work, see above. Thanks @michael-o for your input. I see the observations that you raised. In my view, we should revert to the previous behavior (as there are users currently affected by the change), and perhaps we can discuss future improvements from there, based on actual cases. @AlekseiEfimov can you please review this change? We need the formal review-approval to move forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/6043
