ADV190023 | LDAP channel binding support

[Simo Sorce]

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.
 
> I'd like to send a mail on krbdev, but first I need test and see if it
> is really what it looks like.

Makes sense.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc