RFR 6722928: Support SSPI as a native GSS-API provider
Nico Williams
Nico.Williams at twosigma.com
Tue Dec 4 20:34:36 UTC 2018
On Tue, Dec 04, 2018 at 10:55:49AM +0800, Weijun Wang wrote:
> > On Nov 29, 2018, at 10:00 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> >> - gss_canonicalize_name() is not fully implemented. This will be noticeable
> >> to callers of GSSNameElement's getKrbName(). In particular, permissions
> >> checks will fail (e.g., in GSSCredElement's doServicePermCheck(); similarly
> >> in NativeGSSContext).
> >>
> >> At minimum you absolutely must parse generic GSS name type names into
> >> Kerberos-style names (e.g., service at hostname -> service/hostname@).
> >
> > OK.
>
> I'm playing with the Java native bridge to MIT krb5 and noticed that whatever
> GSSName I created (user, user at REALM, service at host) the toString() of the
> original GSSName and its canonicalize(KRB5_OID) are always the same (and the
That, in principle, is a bug. That should be evidence that little code out
there cares.
But gss_display_name() on a generic-syntax imported name should be the same as
the original input, while gss_display_name() on an MN is mechanism-specific,
and for Kerberos should be a Kerberos-style name string.
Looking at the JGSS code, it looks like this buglet is in MIT. I'll confirm
later.
> same as the original input). On the other hand, the export() forms of them
> are also the same and show Kerberos-style names.
Yes, code would definitely break if export() didn't do that...
> From the debug output, I can see the first export() call notices it's not MN
> and canonicalize automatically.
>
> In my library, since there is only one mechanism, the name is created as MN
> at the beginning. So in import_name() you can see service at host is already
> changed into service/host, canonicalize_name() does nothing, and
> export_name() adds the realm. Is this also OK?
In principle no. See above.
> Summary:
>
> Input MIT name export MIT mn export my name export my mn export
> ----- -------- ------ ------ ------ ------- ------ ----- ------
> a a a at R a a at R a a at R a a at R
> s at h s at h s/h@ s at h s/h@ s/h s/h at R s/h s/h at R
Speaking of @<empty-realm>, I should read up on how to implement
referrals on the client side using SSPI...
Nico
--
More information about the security-dev
mailing list