Re: Current semantics for channel-bindings in GSSAPI

On Fri, Feb 28, 2020 at 6:00 PM Greg Hudson <[email protected]> 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:
>
> * It's symmetric with the initiator.
>
> * It's symmetric with other mechanisms like Moonshot.  (More research
> may be required here; in particular, does NTLM enforce channel bindings
> when one party doesn't pass them?)
>
> * GSS generally does not fail a security context if it can't fulfill a
> requested option; instead, the caller can find out which options
> succeeded.  For instance, if you ask for confidentiality and the mech
> can't provide that, you get a security context without the
> confidentiality flag set.
>
> * gss_accept_sec_context() has output flags but not input flags.  So
> it's easy to add a channel-bound flag indicating that channel bindings
> were used; it's significantly harder to add an input flag to indicate
> whether channel bindings should be enforced.
>
> * Even without any other changes, Heimdal's behavior allows channel
> bindings to be introduced into an application protocol gradually,
> whereas MIT's behavior requires upgrading all of the clients before any
> of the servers.  Neither party polices the other, but when both parties
> supply channel bindings the negotiation will fail if an attacker replays
> it within a different channel.

I find more value in being able to enforce it at least on one side,
and to my understanding that is the main feature in MS implementation,
and level 2 is intended to be the default at some point.
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8563
https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry

While I agree we also need level 1, and we could also use better
signaling with the client, I don't think it is a reason to regress on
the main feature, technically people may be using it, although
unlikely. Also, I was hoping to provide server support for current MIT
releases.

> For historical context, there is a lot of conversation about
> draft-ietf-kitten-channel-bound-flag in the kitten archives, although
> this specific point is only touched on at the end (after Sam's review).
>
> > To follow up on the KERB_AP_OPTIONS_CBT ad-element, (partly)
> > documented in MS-KILE, 3.2.5.8 AP Exchange, and 3.4.5.
> > I was able to confirm that Windows would enforce channel-bindings (not
> > allow all zeroes)
>
> I am a little confused about the need for this flag.  The GSS client
> code knows whether the application supplied channel bindings, so it
> seems like it can fail locally if channel bindings are expected.  I
> guess it doesn't know whether the server is level 0 or level >=1, but
> I'm still not sure what security guarantees level 1 is trying to provide.
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev