Current semantics for channel-bindings in GSSAPI

Greg Hudson ghudson at mit.edu
Fri Feb 28 12:00:28 EST 2020


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.

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.


More information about the krbdev mailing list