Current semantics for channel-bindings in GSSAPI

[Isaac Boukris]

On Mon, Mar 2, 2020 at 6:30 PM Simo Sorce <simo at redhat.com> wrote:
>
> On Mon, 2020-03-02 at 15:12 +0100, Isaac Boukris wrote:
> > On Fri, Feb 28, 2020 at 6:00 PM Greg Hudson <ghudson at mit.edu> wrote:
> > > On 2/27/20 8:27 PM, Isaac Boukris wrote:
> > > > Following the discussion on  IRC, there is currently a difference in
> > > > between Heimdal and MIT, when the client does not send bindings, and
> > > > the server does pass bindings to accept(), in MIT it fails, in Heimdal
> > > > it succeeds.
> > >
> > > There are a few reasons why I think Heimdal's behavior is better:
> >
> > Taking a closer look at MIT accept() code, it looks like there is a
> > case where no checksum is provided at all, where MIT would skip
> > channel-bindings even if the server provided ones. It sounds like
> > Windows also supports this.
> >
> > https://github.com/krb5/krb5/blob/2b1acc07a267782a7f4c9644da78587cc29b6f56/src/lib/gssapi/krb5/accept_sec_context.c#L659
>
> Given this case it sounds like relaxing MITs code to accept when
> clients do not send Channel Bindings to allow the context to be
> established brings consistency not only across implementations but also
> within the MIT code by simplifying away that condition.
>
>
> Here I am going to try to summarize how I and Isaac think we should
> change the semantics so that we can interoperate better.
>
> Premise: Isaac was investigating on how to handle connecting to Windows
> servers that implement a configuration flag called
> LdapEnforceChannelBinding
>
> This flag can be configured with 3 levels:
>
> Level 0: CBs are completely disabled
> Level 1: CBs are optional. Specifically clients that do not send
> KERB_AP_OPTIONS_CBT can still connect with or withouth CBs, while
> clients that send KERB_AP_OPTIONS_CBT are required to send matching
> Channel Bindings.
> Level 2: All clients must send Channel Bindings, without exceptions.
>
> This applies only to the LDAP service as far as we know, but requires
> us to try to allow these configurations in servers that are used to
> emulate Windows AD (eg Samba).
>
> With current MIT code we can only really implement
> LdapEnforceChannelBinding levels 0 and 2. Level 0 when setting no CBs
> in the acceptor, and level 2 when passing CBs, however as stated
> multiple times over the years in previous conversations, this MIT krb5
> behavior makes it hard to perform gradual conversions of the clients.
>
> With current Heimdal, in contrast, it looks like we can only implement
> LdapEnforceChannelBinding levels 0 and 1. Level 0 when setting no CBs
> in the acceptor, and level 1 when passing CBs, this means we do not
> have a way to enforce CBs at all.
>
> We'd like to propose that both MIT and Heimdal code converge in
> behavior and agree in implementing the following behavior:
>
> [ACCEPTOR SIDE]
>
> 1) When passing GSS_C_NO_CHANNEL_BINDINGS to gss_accept_sec_context()
> then Channel Bindings are ignored (equivalent to level = 0)
> 2) When passing actual Channel Bindings to gss_accept_sec_context()
> then Channel Bindings are checked only if the client sends non zero
> CBs. (allows us to implement level = 1)
> 3) If the client sent CBs and we verified them set a new flag in
> ret_flags that signify CBs were received and checked (this will allow
> us to implement level = 2 behavior by failing the connection if the
> flag is missing).
>
> Optionally[A] support the presence of the KERB_AP_OPTIONS_CBT. If we do
> this then the above point (2) above is split in two sub options:
>
> 2) When passing actual Channel Bindings to gss_accept_sec_context()
> then:
> 2.1) Channel Bindings are checked only if the client sends non zero CBs
> and KERB_AP_OPTIONS_CBT is not present.
> 2.2) Channel Bindings are enforced if the client provides the
> KERB_AP_OPTIONS_CBT.
>
> NOTE in 2.2 we propose that context establishment fails if CBs are not
> provided, we do not rely on the application to check ret_flags in this
> case.
>
> Optionally[B] we add a krb5.conf flag like "require channel bindings"
> that causes the gss_accept_sec_context() function to fail if CBs are
> passed into it and the client does not send CBs (ie we do not rely on
> the applications to check ret_flags, the context establishment fails
> just like MIT code currently does).

Hmm, if we provide a krb5.conf for this, then I think it might make
more sense to use set_cred/context_option over ret flag. So the logic
would be lib-defaults is false (not fail), can be overridden by
krb5.conf, and again by application code.

> Option B allows operators relying on current MIT behavior to retain it
> by simply adding this option in krb5.conf and not having to worry to
> change pre-existing applications in order to enforce CBs.
>
>
> [INITIATOR SIDE]
>
> Optionally [C] we add a krb5.conf flag like "require channel bindings"
> that causes gss_init_sec_context() to emit the KERB_AP_OPTIONS_CBT.
> The flag should always be emitted and will cause clients that have not
> been updated to send CBs to fail against servers that have support for
> interpreting KERB_AP_OPTIONS_CBT. This is useful for deployers to check
> that all their client software has been properly updated before
> switching the same flag on on the servers.
>
>
> In closing,
>
> Although Options B and C could use different config options we suggest
> the exact same option to be used for both initiator and acceptor for
> consistency of behavior and to reduce the number of knobs to dial for
> admins. Applications that need special exceptions can always be
> configured to point to a different custom krb5.conf file.

Not sure about making it the same option, it has side impacts.

> NOTE: "require channel bindings" defaults to False in our proposal.

Thanks for summing it up.