ntlmssp errors against El Capitan's SMB Server

[Jeremy Allison]

On Tue, Aug 30, 2016 at 01:13:57PM -0700, Jeremy Allison wrote:
> On Tue, Aug 30, 2016 at 03:54:33PM -0400, Simo wrote:
> > 
> > This is not how spnego is supposed to work, once a mechListMIC is
> > returned by one of the parties and it checks out then you do not add
> > another one on the way back.
> > 
> > Whether the client or the server send a mechListMIC depends on the
> > mechanism selected and how many round trips it implies.
> > 
> > Going by memory but IIRC:
> > If kerberos is used usually it's the server that send the mechlistMIC
> > as the last leg is done at the server. In case of NTLM the client needs
> > to send back one more token so it is the client that generates the
> > mechlistMIC.
> > 
> > I may be wrong on some minor detail or the directions :-)
> 
> https://www.rfc-editor.org/rfc/rfc4178.txt
> 
> does imply that mechListMIC's are exchanged.

Yeah, doesn't this part:

"   In cases where an attacker could have materially influenced the
   negotiation, peers exchange message integrity code (MIC) tokens to
   confirm that the mechanism list has not been modified. "

mean that both sides must exchange a mechlistMIC ?

However, in the .pcap between smbclient and the Apple
server there's only one mechType, which the server selects,
so I'm guessing that in this case no attacker "could have materially influenced the
negotiation" so the mechlistMIC becomes optional...