Good morning Mr. Simpkins. Bill Wesse here from the Protocols Documentation team.
I have taken ownership of the new case (SRX080803600053) I created for your question. I will begin my investigation this morning and update you on my progress before the end of the day. Regards, Bill Wesse MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: 980-776-8200 CELL: 704-661-5438 FAX: 704-665-9606 We're Hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted -----Original Message----- From: Bill Wesse Sent: Sunday, August 03, 2008 2:12 PM To: 'Adam Simpkins'; Interoperability Documentation Help Cc: [EMAIL PROTECTED] Subject: RE: raw NTLMSSP tokens in GSS-API/SPNEGO? Good afternoon Mr. Simpkins. First, I apologize for my late response. I have created a new case for your questions concerning the [MS-NLSP] document. Myself, or one of my team members will taking ownership of the case and contact you soon. Thank you for your forbearance of my mistake in not responding sooner. Regards, Bill Wesse MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: 980-776-8200 CELL: 704-661-5438 FAX: 704-665-9606 We're Hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted -----Original Message----- From: Adam Simpkins [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2008 8:12 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED] Subject: raw NTLMSSP tokens in GSS-API/SPNEGO? I am requesting correction assitance regarding NTLM authentication using SPNEGO: When NTLM authentication is negotiated over SPNEGO, Windows clients do not properly wrap the initial NTLM token inside a GSS-API InitialContextToken (described in RFC 2743 section 3.1). RFC 4178 is somewhat vague on this matter, but a close reading reveals that the first mechToken/responseToken sent by the initiator must be wrapped in a GSS-API InitialContextToken. In particular, RFC 4178 section 3.2 item (c) states: If the initiator's preferred mechanism is accepted, and an optimistic mechanism token was included, this mechanism token MUST be passed to the selected mechanism by invoking GSS_Accept_sec_context(). If a response mechanism token is returned, it MUST be included in the response negotiation token. Otherwise, the target will not generate a response mechanism token in the first reply. Given that the initial inner token is passed to GSS_Accept_sec_context(), it must be a GSS-API InitialContextToken. Windows clients follow this behavior when Kerberos is negotiated, but not when NTLM is negotiated. When NTLM is in use, they send a raw NTLM message, not contained in an InitialContextToken. I can provide SMB traces of this behavior if desired. I haven't been able to find mention of this Microsoft-specific behavior in MS-SPNG or in MS-NLMP. The one thing I did find that could potentially be considered to explain this behavior is in item <8> in Appendix A of MS-SPNG: For backward compatibility and historical reasons, a Windows implementation of SPNEGO has the following behavior: it accepts raw Kerberos messages that are based on [RFC4121] and [RFC4120], and it accepts raw NTLM messages that are not embedded in [RFC4178] SPNEGO messages. This behavior is known as the universal receiver behavior. I find this passage slightly strange--for Kerberos, this seems to be standard behavior, and not a Windows extension. Any conforming GSS-API implementation that supports both SPNEGO and Kerberos should accept InitialContextTokens containing either SPNEGO or Kerberos tokens. Therefore, the Windows behavior could perhaps best be described not by the statement above, but by "the Windows GSS-API implementation accepts as the first token a raw NTLM message that is not embedded in an [RFC2743] InitialContextToken." This wording could also be considered to explain the fact that Windows servers accept the a raw NTLM token in the SPNEGO mechToken. Did I miss something in the documentation, or could it be updated to describe this deviation from the standard? -- Adam Simpkins [EMAIL PROTECTED] _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
