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

[Weijun Wang]

I've thought about this over and have the following plan:

Since GSSName::isMN is always true, every gss_name_t must be a MN and I decide the name to be always krb5 style and the type to be always NT_KRB5_NAME. However, somewhere in the JGSS native bridge implementation the name and type are cached on the Java side, therefore the result of gSSMananger.createName("service at host", NT_HOSTBASED_SERVICE) does have toString() being service at host and type being NT_HOSTBASED_SERVICE. When canonicalize() is called, even if the GSS-API canonicalize_name() is not called a new gss_name_t is created and the Java side cache will be recreated, and this time name becomes service/host and type becomes NT_KRB5_NAME.

Is this what you like to see?

As for export(), I can also output a/b at . When the result is imported as a NT_EXPORT_NAME, I'll remember to remove the @ at the end.

The result is:

    GSSManager m = GSSManager.getInstance();
    GSSName n = m.createName("service at host", GSSName.NT_HOSTBASED_SERVICE);
    // n is now (service at host, NT_HOSTBASED_SERVICE)
    n = n.canonicalize(new Oid("1.2.840.113554.1.2.2"));
    // n is now (service/host, NT_KRB5_NAME)
    byte[] x = n.export();
    // 0000: 04 01 00 0B 06 09 2A 86   48 86 F7 12 01 02 02 00  ......*.H.......
    // 0010: 00 00 0D 73 65 72 76 69   63 65 2F 68 6F 73 74 40  ...service/host@
    n = m.createName(x, GSSName.NT_EXPORT_NAME);
    // n is now (service/host, NT_KRB5_NAME)


Thanks
Max

> On Dec 5, 2018, at 11:41 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Java's GSSName::isMN always returns true, therefore to my observation, the GSS-API canonicalize_name() is not called if GSSName::canonicalize is called. It is only called in export(), where the first call to export_name() might return "Name is not MN" (MIT krb5 behavior) and then the bridge automatically call canonicalize_name() and export_name() again.
> 
> And then, the export format is only useful when importing a NT_EXPORT_NAME.
> 
> So, seems like both export_name() and canonicalize_name() are quite useless (at least in the view of the native bridge).
> 
> What's your ideal output? The toString of canonicalize() and import(export) always showing krb5 style and name type being KRB5_NAME?
> 
> --Max
> 
>> On Dec 5, 2018, at 4:34 AM, Nico Williams <Nico.Williams at twosigma.com> wrote:
>> 
>> 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
>> -- 
>