RFR 6722928: Support SSPI as a native GSS-API provider

[Bernd Eckenfels]

Just to add another aspect to the discussion, there are at least 3 DLLs out there which implement this functionality (Microsoft’s JDBC driver, jTDS driver and Waffle) + commercial solutions as we have heared. All of them are used to allow authenticating the current user against services (mostly TDS (SQL Server), SMB and http.

So having a GSS provider, even when it is not used by default would hugely benefit a lot of projects (especially if it does not require JAAS wrapping and will support Windows 10 with Credential Guard for NTLM and Kerberos)

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: security-dev <security-dev-bounces at openjdk.java.net> im Auftrag von Nico Williams <nico.williams at twosigma.com>
Gesendet: Montag, März 25, 2019 6:38 PM
An: Weijun Wang
Cc: security-dev at openjdk.java.net
Betreff: Re: RFR 6722928: Support SSPI as a native GSS-API provider

On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang wrote:
> > On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> >>> There's a few reasons:
> >>>
> >>> - NTLM doesn't have an OID, at least as I remember
> >>>
> >>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/
> >>> regards to the ServicePermission stuff
> >>
> >> Yes, it needs to check a permission if the token is SPNEGO and
> >> internally it's Kerberos. I also believe the HTTP Negotiate code
> >> there is probably not good at dealing with a Negotiate dialog with
> >> 2 rounds. The first problem should be easy to fix, I'll see if the
> >> 2nd is complicated.

I expect lots of implementations of HTTP/Negotiate to not support more
than one round trip. However, if a client and server lack credentials
for a common mechanism, authentication will fail or not even start, and
if they do have credentials for a common mechanism but one or both
cannot handle more than one round trip, they'll fail. Either way they
fail, so what's the problem? Ignoring for a moment NTLM's weakness,
adding support for it adds ways to win, not ways to fail.

> It works. Java's (old) HTTPConnection sends an NTLM token to IIS and
> after 4 messages I see 200 OK.
>
> But 1) Java GSS acceptor does not accept it and I don't want to break
> interop inside Java.

That's not breaking interop. A Windows initiator and non-Windows
acceptor (and vice-versa) will still interop provided both have Kerberos
credentials.

> 2) No more permission check.

I don't understand (2).

> Not going to do it this time. Later I might ask networking how
> transparent NTLM works and if they needs any permission checking or
> other settings I can probably follow.

Of course it needs permission checking, except that in a world without
applets that's a bit pointless.

Nico
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190325/3d7c9c0a/attachment.htm>