ADV190023 | LDAP channel binding support

[Isaac Boukris]

On Mon, Feb 24, 2020 at 9:37 PM Isaac Boukris <iboukris at gmail.com> wrote:
>
> On Mon, Feb 24, 2020 at 9:28 PM Simo Sorce <simo at redhat.com> wrote:
> >
> > On Mon, 2020-02-24 at 17:41 +0100, Isaac Boukris wrote:
> > > On Mon, Feb 24, 2020 at 2:35 PM Simo Sorce <simo at redhat.com> wrote:
> > > > On Sat, 2020-02-22 at 20:09 +0100, Isaac Boukris wrote:
> > > > > On Tue, Feb 18, 2020 at 5:48 PM Stefan Metzmacher <metze at samba.org> wrote:
> > > > >
> > > > > > I think we need input from dochelp to answer 2 questions:
> > > > > > 1. which kind of channel bindings are expected/used by windows?
> > > > > >    I assume tls-server-end-point. I guess MS-ADTS would be the place
> > > > > >    to define these details for ldaps.
> > > > >
> > > > > I noticed more another reference to channel-bindings in MS-KILE, I
> > > > > think maybe KERB_AP_OPTIONS_CBT ad element is the way to tell the
> > > > > server to require CB when LdapEnforceChannelBinding is set to 1 only,
> > > > > needs testing.
> > > > >
> > > > > 3.2.5.8 AP Exchange
> > > > > If ChannelBinding is set to TRUE, the client sends
> > > > > AD-AUTH-DATA-AP-OPTIONS data in an AD-IF-
> > > > > RELEVANT element ([RFC4120] section 5.2.6.1). The Authorization Data
> > > > > Type AD-AUTH-DATA-AP-
> > > > > OPTIONS has an ad-type of 143 and ad-data of KERB_AP_OPTIONS_CBT
> > > > > (0x4000). The presence of
> > > > > this element indicates that the client expects the applications
> > > > > running on it to include channel binding
> > > > > information ([RFC2743] section 1.1.6 and [RFC2744]) in AP requests
> > > > > whenever Kerberos
> > > > > authentication takes place over an "outer channel" such as TLS.
> > > > > Channel binding is provided using the
> > > > > ChannelBinding variable specified in section 3.2.1.
> > > > >
> > > > > 3.4.5
> > > > > If the ApplicationRequiresCBT parameter (section 3.4.1) is set to
> > > > > TRUE, the server, if so configured,
> > > > > SHOULD<67> return GSS_S_BAD_BINDINGS whenever the AP exchange request
> > > > > message contains
> > > > > an all-zero channel binding value and does not contain the
> > > > > AD-IF-RELEVANT element ([RFC4120]
> > > > > section 5.2.6.1) KERB_AP_OPTIONS_CBT.
> > > >
> > > > Very interesting, we should add support to decode this AD in MIT krb5
> > > > and exposes it via naming attributes or context options, whatever makes
> > > > the most sense.
> > >
> > > Yeah, although I can't really think of something that would work,
> > > given we want to know that before calling accept() on the input token.
> > > On clients supporting CB, maybe we can add this ad-element via a
> > > gss_set_name_attribute() call, not sure.
> >
> > We might even just see there are CBs in gss_init_sec_context() and just
> > do it automatically. The only question is whether this can cause
> > interop issues which requires a more nuanced use of these.
>
> Right, doing it automatically make sense. I think an unknown
> ad-element in ad-if-relevant container shouldn't cause interop issues.

It seems Windows clients send this same list of ad-element, over TLS
or not.  I think "AD-TARGET-PRINCIPAL" is for what they called in the
blog post "bound to SPN", not sure.

authorization-data: 1 item
    AuthorizationData item
        ad-type: AD-IF-RELEVANT (1)
        ad-data: 3081a9938298930…
            AuthorizationData item
                ad-type: AD-TOKEN-RESTRICTIONS (141)
                ad-data: 303330…
            AuthorizationData item
                ad-type: AD-LOCAL (142)
                ad-data: f0bca424242eaf2...
            AuthorizationData item
                ad-type: AD-AP-OPTIONS (143)
                ad-data: 00400000
                    AD-AP-Options: 0x00004000, ChannelBindings
                        .... .... .... .... .1.. .... .... .... =
ChannelBindings: Set
            AuthorizationData item
                ad-type: AD-TARGET-PRINCIPAL (144)
                ad-data: 6c006400602…
                    Target Principal: ldap/sdc.smb.net at SMB.NET