RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
Alexey Bakhtin
alexey at azul.com
Tue May 26 13:23:24 UTC 2020
Hi Michael, Thomas,
Unfortunately we can not fix address type issue with the UnspecEmptyInetAddress subclass.
We can not create subclass of InetAddress without changing public API.
We can try similar approach but create subclass of ChannelBinding class instead. It is not so elegant like UnspecEmptyInetAddress approach but it could help to distinguish between TLS channel binding and Channel Bindings set by application.
Later we can remove this workaround In case we prove that UNSPEC type should be used in all types of Channel Bindings.
Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/
Regards
Alexey
> On 26 May 2020, at 06:04, Thomas Maslen <thomas.mpp.maslen at gmail.com> wrote:
>
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200526/b36db470/signature.asc>
More information about the security-dev
mailing list