RFR 6722928: Support SSPI as a native GSS-API provider
Nico Williams
Nico.Williams at twosigma.com
Thu Nov 29 16:38:45 UTC 2018
On Thu, Nov 29, 2018 at 10:00:02AM +0800, Weijun Wang wrote:
> > - You're constructing SPNEGO tokens yourself. I'll have to review that
> > very carefully.
>
> I wrapped the outgoing token into NetTokenInit and extracted in incoming
> NegTokenTarg. This might fail if there are multiple rounds, but I think for
> kerberos it's OK.
Kinda. We'd like to add an option for multiple round trips to the
Kerberos mechanism to make it easier to recover from various errors.
You shouldn't assume that Kerberos will always be just one round trip.
Of course, the chances that MSFT will implement our multi-round trip
extension are probably so close to zero that you can get away with it :/
You could still support multiple round trips just fine, of course, but
how to test it?
One thing I've wanted to be able to do is to use concrete mechanisms via
the JGSS JNI native C interface, but SPNEGO being JGSS native Java
coded. That would allow multiple native JNI C providers for different
mechanisms! (I'm sure Martin Rex / SAP would love that. They have a
GSS mechanism provider building toolkit that SAP customers use to build
many many custom mechanisms.) The JGSS mechglue needs additional work
to make that possible, and if I remember correctly I left a few
breadcrumb comments about that in our contribution.
> > It would be better to let Windows provide SPNEGO though...
>
> But it might promote NTLM.
You can make sure it doesn't get used.
> > (I would also urge you to NOT attempt any DNS canonicalization of
> > hostnames. Let's not further spread that mistake.)
>
> I didn't.
I know. I meant that when you get around to parsing generic syntax
names you might get tempted to do that, but if you are tempted, don't do
it :)
> > For user principals it's trickier, and I think you might need some notion of
> > default realm, but a) maybe you can get away with an empty realm here on
> > Windows, b) I'm not sure where you'd a default realm on Windows.
>
> I'm using the environment variable USERDNSDOMAIN now.
Sure, that works for now.
> > What we do to determine the default realm for user names in our
> > patched version of Martin Rex's GSS->SSPI bridge is call
> > AcquireCredentialsHandle() or QueryCredentialsAttributesW() to
> > get/query the default credential and get its name, and from that the
> > realm, and we use that as the default realm.
> >
> > I'll have to look and see how we handle host-based service names
> > (Martin's original code has a domain_realm table in the registry, but
> > we removed all of that and rely on referrals instead.)
> >
> > - If you can get Legal approval for including / distributing a fork of
> > Martin Rex's bridge, you'll get all of the above functionality and
> > also acceptor functionality.
>
> Anyway, one can use his bridge with -Dsun.security.jgss.lib.
Indeed, one can!
That reminds me, we need to publish our changes to it.
A very cut-down (initiator-only) SSPI bridge will probably do for you
for now. I wouldn't insist on acceptor functionality.
But it is important that the bridge work with JAAS. Unfortunately a lot
of projects (many of them Apache ones) have cargo-culted the use of JGSS
w/ JAAS. Indeed, that is the main motivator for our contribution: that
the use of JGSS w/ JAAS meant the native GSS providers couldn't be used
because GSSName is not a Principal and because there was no
GssLoginModule.
I will ask for permission to exfiltrate a handful of test programs we
use for testing basic JGSS w/ JAAS functionality. You should test the
SSPI bridge with our patches and these programs.
Note though that we don't actually test with any policies that would
restrict what credentials the test program can use. In general we find
JAAS to be pretty useless in a world with no applets -- no untrusted
code. All the ServicePermission stuff is very Kerberos-specific and
there is no support for other mechanisms :(
Nico
--
More information about the security-dev
mailing list