ntlmssp errors against El Capitan's SMB Server

[Simo]

On Wed, 2016-08-31 at 10:20 +0200, Stefan Metzmacher wrote:
> Hi Jeremy,
> 
> > 
> > note the 'ntlmssp_state->new_spnego = true' when timestamp != NULL.
> > 
> > And it looks like the Windows client doesn't check the
> > mechlistMIC in this case, so we might need to losen our
> > check also.
> > 
> > This would also fix the smbclient connecting to the Microsoft
> > Azure server problem - that server also only does NTLM and
> > doesn't send the mechlistMIC in the ACCEPT_COMPLETED reply.
> > 
> > Attached is a possible patch, but I'm *really* unsure
> > if this is safe w.r.t. downgrade attacks.
> > 
> > Metze, can you take a look at this and let me know what you
> > think ?
> 
> The problem I see with this is that client doesn't know
> if the server processed the mechListMIC.
> 
> Which has implications on:
> 
>         if (NT_STATUS_IS_OK(status)) {
>                 bool reset_full = true;
> 
>                 gensec_security->child_security =
> spnego_state->sub_sec_security;
> 
>                 reset_full = !spnego_state->done_mic_check;
> 
>                 status =
> gensec_may_reset_crypto(spnego_state->sub_sec_security,
>                                                  reset_full);
>         }
> 
> @Simo: We discussed that the reset_full parameter might not be
> required,
> but I think
> these "broken/lazy" servers would be the reason to have it there.
> 
> As this problem hopefully only present at the SMB* protocols, which
> have
> their own
> signing/encrytion implementations, I'd propose to add a
> GENSEC_FEATURE_SMB_STYLE
> and allow Jeremy's change only if GENSEC_FEATURE_SMB_STYLE is
> present.
> (We already have GENSEC_FEATURE_DCE_STYLE and
> GENSEC_FEATURE_LDAP_STYLE
> so adding GENSEC_FEATURE_SMB_STYLE would be a similar way to work
> around
> SMB specific
> implementation bugs).
> 
> What do you think?


I think we may want a knob to allow this behavior, it's not ideal but
backward compat is also important. I also agree we may want to relax it
selectively per transport.

I would call it just "SPNEGO_REQUIRE_SERVER_MIC" (instead of SMB_STYLE)
and allow the SMB code paths to set it to No, the default should be to
require it. The name should reflect what the knob actually wants and
not where we actually use it this time, it'd be awkward and confusing
to set "SMB_STYLE" if we figure we need to use it on another protocol.

Simo.