RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

[Thomas Maslen]

On Mon, May 25, 2020 at 3:15 AM Michael Osipov <1983-01-06 at gmx.net> wrote:
[...]

> So I read the discussions. RFC 2744 shall not be changed, people
> admitted that the spec of SASL GS2 mechs is wrong and should be changed,
> but this has not happened yet. It remained at UNSPEC all the years.
>
> So we have several issues here:
> * GSS-API C bindings and SASL requests are two distinct RFCs which
> require/mandate differnt things.
> * The change in JGSS in unrelated to this patch because GSS-API knows
> nothing about SASL and its fauly spec.
>
> Since we are doing LDAP over SASL here and RFC 5801 requires to be
> UNSPEC (0) the SASL TlsChannelBinding class must take that into account.
> Unfortunately, JGSS implies with the args of the ChannelBinding the type
> fo the adress. So will change my opinion a bit:
>
> No property for AD/non-AD is necessary, but handling of UNSPEC is
> required. JGSS shall remain at NULLADDR. The subtype
> UnspecEmptyInetAddress should be at least evaluated.
>
> Michael
>

 No.  This isn't just about RFC 5801.  As Alexey Bakhtin observed, this
also applies to channel bindings for HTTP Negotiate Authentication (loosely
aka "SPNEGO"), not only for NTLM (which probably isn't at issue here) but
also for Kerberos -- that's where I first encountered this, working on a
proprietary Java Kerberos implementation.

More generally, if you want channel bindings to interoperate in the GSSAPI
Kerberos Mechanism for any protocol -- SASL GS2, HTTP Negotiate
Authentication, or anything else -- ignore the fact that RFC 2744 specifies
255 for the "no address" case and do what everyone actually does:  use zero.

Here is a test from MIT Kerberos that (implicitly) uses zero:
https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_bindings.c

And here is one from Heimdal:
https://github.com/heimdal/heimdal/blob/5057d04f6a47f05f1ed7c617458722104d4c17dc/lib/gssapi/test_context.c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200525/3e26e948/attachment.htm>