Current semantics for channel-bindings in GSSAPI

[Stefan Metzmacher]

Am 28.02.20 um 18:00 schrieb Greg Hudson:
> 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?)

As far as I can tell the server enforces them when the client provides
them. That means there's a way in the protocol to distinguish between
GSS_C_NO_CHANNEL_BINDINGS and struct gss_channel_bindings_struct { 0, }.

E.g. for SMB Windows uses 0 zero bytes a valid channel bindings.

While KERB_AP_OPTIONS_CBT is needed for that for kerberos.

> * 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.

I think using excplicit acceptor_creds and flag the requested behavior
there, it's similar to the ignore transited problem.

It would be good to make some generic progress here, as we'll likely
need more of these application driven options.

> * 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.

The problem is kerberos or NTLMSSP without GSS_C_CONF_FLAG and without
GSS_C_INTEG_FLAG. If this is used within TLS the server receiving the
AP-REQ could just replay that to another server. A client knowning about
the correct channel bindings can prevent such attacks, but the server
needs level=1 (or higher) to detect that.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20200228/580829ba/attachment-0001.bin