Re: Current semantics for channel-bindings in GSSAPI

On Mon, Mar 2, 2020 at 3:02 PM Simo Sorce <[email protected]> wrote:
>
> On Mon, 2020-03-02 at 13:52 +0100, Isaac Boukris wrote:
> > On Sat, Feb 29, 2020 at 12:47 AM Stefan Metzmacher <[email protected]> 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.

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

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

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

> Channel Bindings SHOULD definitely be sent always on HTTPS, but
> conf/integ flags are completely orthogonal to CBs so it is unclear to
> me why you would care.
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev