[cifs-protocol] Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

[Adam Simpkins]

On Wed, Oct 29, 2008 at 09:37:05AM -0700, Bill Wesse wrote:
> Adam, thank you very much for your persistence.
> 
> I apologize for responding against the two issues with the same
> answer. In order to make sure I don't commit another mix-up, I have
> superseded SRX080803600053 with SRX081029600208.
> 
> I did a careful backtrack on the question/response history, and
> noticed something that surprised and disappointed me: in the below
> partial RESPONSE text, we are essentially claiming that our own XP
> Client is sending an invalid NTLM SSP token.
> 
> I think we confused how gss_ntlmssp.cap was generated (XP <-> 2003)
> with how raw_ntlmssp.cap was generated (which, as you noted, had the
> security blob stripped).

No, you had this part correct.  raw_ntlmssp.cap contains an unmodified
SESSION_SETUP_ANDX request generated by an XP client.  (However, in
order to generate it, I stripped the security blob from the server's
NEGOTIATE response.  If the server includes a security blob in the
NEGOTIATE response, XP clients always use SPNEGO.  With no security
blob, they use raw NTLM SSP without SPNEGO or GSS.  In the past, I
have seen some servers in the field generate NEGOTIATE responses with
no security blob, but I don't recall what OS or version they were
running.)

The gss_ntlmssp.cap traces was taken using a custom client configured
to always generate a GSS InitialContextToken for the very first
security blob exchanged.  This is the behavior one would expect from a
client that performed GSS authentication according to RFC 2743.

-- 
Adam Simpkins
simpkins at cisco.com