Current semantics for channel-bindings in GSSAPI

[Isaac Boukris]

On Fri, Feb 28, 2020 at 6:22 PM Stefan Metzmacher <metze at samba.org> wrote:
>
> Am 28.02.20 um 18:00 schrieb Greg Hudson:
> > On 2/27/20 8:27 PM, Isaac Boukris wrote:
> >
> >> 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.

If the connection between the client and intermediate server uses TLS,
the client must also provide the right bindings, so the authdata flag
shouldn't be needed.
If the client connection does not use TLS, I think I can see the value
of the authdata flag to prevent forwarding the token to a real server
which requires TLS and has level=1.

So I'd say a krb5.conf option would make sense for for client
emission.  For acceptor side, Greg pointed out that
gsskrb5_extract_authz_data_from_sec_context() could be used to handle
the authdata flag, once we settle on Heimdal semantics, but I think it
still make sense to take advantage of this assertion implicitly.