Current semantics for channel-bindings in GSSAPI

[Isaac Boukris]

On Mon, Mar 2, 2020 at 5:04 PM Simo Sorce <simo at redhat.com> wrote:
>
> On Mon, 2020-03-02 at 15:54 +0100, Isaac Boukris wrote:
> > On Mon, Mar 2, 2020 at 3:02 PM Simo Sorce <simo at redhat.com> wrote:
> > > On Mon, 2020-03-02 at 13:52 +0100, Isaac Boukris wrote:
> > > > On Sat, Feb 29, 2020 at 12:47 AM Stefan Metzmacher <metze at samba.org> wrote:
> > > > > Am 28.02.20 um 21:33 schrieb Greg Hudson:
> > > > > > On 2/28/20 12:22 PM, Stefan Metzmacher wrote:
> > > > > > > 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.
> > > > > >
> > > > > > RFC 4121 (and 1964) communicate bindings in a 128-bit hash.  Ignoring
> > > > > > the vanishingly unlikely scenario where all bits of the hash are zero,
> > > > > > it's possible to distinguish between a client's
> > > > > > GSS_C_NO_CHANNEL_BINDINGS and any valid channel bindings.
> > > > > >
> > > > > > From Isaac's testing and MS-KILE, it sounds like KERB_AP_OPTIONS_CBT is
> > > > > > a lever to force applications to supply TLS channel bindings.  It
> > > > > > enables a weird policy: at server enforcement level 1, client
> > > > > > applications that don't provide bindings will interoperate if and only
> > > > > > if they are running on a sufficiently old versions of Windows.  That's
> > > > > > not a coherent policy in the context of open standards, but it probably
> > > > > > makes sense for a pure Windows ecosystem.
> > > > >
> > > > > For SMB windows sends channel bindings of 16 zeros together with
> > > > > the KERB_AP_OPTIONS_CBT bit set. I would guess the server would reject
> > > > > the request if the md5sum of gss_channel_bindings_struct { 0, } would be
> > > > > provided instead.
> > > > >
> > > > > I guess the bit means that client and server should agree that both
> > > > > sides use 16 zeros. In that case the AP exchange is protected by
> > > > > GSS_C_INTEG_FLAG and GSS_C_MUTUAL_FLAG and cannot be reused without
> > > > > knowing the session key.
> > > >
> > > > Not sure I follow how it relates to INTEG/MUTUAL, but note that LDAP
> > > > not over TLS behaves similar to SMB described above. Also, I noticed
> > > > that Windows HTTP client requests INTEG, both when over TLS and when
> > > > not, although it isn't used afai understand.
> > >
> > > Stephan, Isaac, in SMB CBs should be completely ignored in any case
> > > because there is no outer channel to bind to.
> > > That is why CBs are set to all 0 even when KERB_AP_OPTIONS_CBT is set.
> >
> > Right, that is why I compared it with LDAP when not over TLS.
> >
> > > This AP REQ flag just states: "The client is capable of doing CBs
> > > correctly", but it is only relevant when there is an actual channel to
> > > bind to. In SMB there is no support for running in an outer TLS (or
> > > otherwise) channel, so sending all 0 (or not sending CBs at all) is
> > > simply the correct thing to do and nothing special to SMB.
> >
> > I think the point was made, that Windows client sends
> > KERB_AP_OPTIONS_CBT even when not over TLS.
> >
> > > When it comes to Channel Bindings this is the decision tree:
> > >
> > > 1) Is the GSSAPI exchange going over an outer protection channel ?
> > >    NO -> (2)
> > >    YES -> (3)
> > >
> > > 2) Do not set CB (client) and do not require CB (server), STOP
> > >    [Completely ignore KERB_AP_OPTIONS_CBT]
> >
> > As above, in this case Windows client sends KERB_AP_OPTIONS_CBT.
>
> It doesn't matter, the server should simply not set CBs and ignore the
> whole thing.

I think the client should send KERB_AP_OPTIONS_CBT when so configured
(tbd), even when not over TLS.

> > > ----- From here on we are operating in a protected channel -----
> > > 3) Is CB mandatory ? (In win this means LdapEnforceChannelBindings=2,
> > > or as MS-KILE calls it ApplicationRequiresCBT)
> > >    NO -> (4)
> > >    YES -> (5)
> > >
> > > 4) The client can send CBs or not
> > > The server must be prepared to handle CBs, but can ignore them
> > > Special case:
> > > Did the client sends KERB_AP_OPTIONS_CBT set to 4000?
> > >    NO -> (4.1)
> > >    YES -> (4.2)
> > >
> > > 4.1) Ignore CBs if they are all 0s or NULL
> > > Check CBs otherwise. FAIL if CBs do not match
> >
> > Note, CBs are only checked if LdapEnforceChannelBindings>=1, here if
> > LdapEnforceChannelBindings=0 it works even with wrong CBs.
>
> This is something we should not care for anymore at this point, that
> can simply be handled by passing no CBs in the server (equivalent to
> level =0).
>
> > > 4.2) FAIL is CBs are all 0s and FAIL if CBs do not match
> > > [Ignore CBs only if they are NULL(?) <- Isaac can you test this
> > > scenario?]
> >
> > Not sure how to test this, but note that here too if
> > LdapEnforceChannelBindings=0 Windows would accept even wrong bindings,
> > so it's like passing GSS_C_NO_CHANNEL_BINDINGS in GSS.
>
> This is how to test:
> Use a krb5 GSSAPI based LDAP client, configure server with lvl=1, do
> set KERB_AP_OPTIONS_CBT, omit CBs completely ?

Not sure what 'omit' would mean here, sorry.

> It is not hugely important, but it would be nice to know what to
> expect.
>
> > > ----- From here on Channel Bindings are REQUIRED -----
> > > 5) Client must set valid CBs, Server must require valid CBs
> > >    If CBs do not match (they must be different from all 0s) FAIL
> > >    [Completely ignore KERB_AP_OPTIONS_CBT]
> > >
> > > > Authenticator from win HTTP client over TLS:
> > >
> > > Isaac, note that the SPNEGO spec is exclusively about authentication,
> > > contexts are not retained, and cannot be used for GSSAPI services once
> > > authentication completes. So there really is no much point in
> > > confidentiality or integrity flags.
> >
> > Right, that is why the INTEG request was weird.
>
> I think Integrity here is needed to be able to sign the MicMechList and
> stuff like that. As that is used to prevent tampering with the SPNEGO
> outer layer. And I assume layering within SSPI meant we need the flag
> at the mechanism level (you need it in NTLMSSP or there is no
> negotiation of a session key useful for signing), so it is retained in
> krb5 mechanisms as well.
>
> And in fact if you look at RFC 4178 you'll find this in the
> Introduction:
> """
>    If per-message integrity services [RFC2743] are available on the
>    established mechanism security context, then the negotiation is
>    protected to ensure that the mechanism list has not been modified.
> """

That may explains why Windows HTTP client would ask INTEG indeed. Note
that over TLS Win LDAP client won't request INTEG even in SPNEGO,
while the HTTP does.