[security-dev 01603]: Re: Request for comment: spec: NTLM as a SASL mech
Natalie Li
Natalie.Li at Sun.COM
Thu Feb 4 08:39:36 UTC 2010
> Security Blob: 605506062B0601050502A04B3049A00E300C060A2B060104...
> GSS-API Generic Security Service Application Program Interface
> OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
> SPNEGO
> negTokenInit
> mechTypes: 1 item
> Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP -
> Microsoft NTLM Security Support Provider)
> mechToken:
> 4E544C4D535350000100000097B208E2060006002F000000...
> NTLMSSP
> NTLMSSP identifier: NTLMSSP
> NTLM Message Type: NTLMSSP_NEGOTIATE
> (0x00000001)
> Flags: 0xe208b297
> Calling workstation domain: NLW2K8
> Calling workstation name: PHANTOM
In CIFS, Windows clients typically send raw NTLMSSP messages in non AD
environment while domain clients send NTLMSSP w/ SPNEGO. I don't really
know whether my observation apply here when NTLM is used as a SASL mech.
Natalie
Max (Weijun) Wang wrote:
> How are these 2 forms used (by MS and others)? I've never seen an NTLM token embedded inside the SPNEGO initial context token.
>
> Thanks
> Max
>
> On Feb 4, 2010, at 1:14 AM, Nicolas Williams wrote:
>
>
>> On Wed, Feb 03, 2010 at 08:54:03AM -0800, Natalie Li wrote:
>>
>>> Nicolas Williams wrote:
>>>
>>>> On Wed, Feb 03, 2010 at 08:34:13AM -0800, Natalie Li wrote:
>>>>
>>>>
>>>>> Max (Weijun) Wang wrote:
>>>>>
>>>>>
>>>>>> Hi Nico
>>>>>>
>>>>>> Is there a separate OID for NTLM as a GSS-API mech?
>>>>>>
>>>>>>
>>>>> Yes, OID for NTLM is "1.3.6.1.4.1.331.2.2.10"
>>>>> And the encoded OID octet string is:
>>>>>
>>>>> 102 #define GSS_MECH_NTLMSSP_OID
>>>>> "\053\006\001\004\001\202\067\002\002\012"
>>>>>
>>>>>
>>>> But it doesn't go on the wire in the initial context token, right?
>>>>
>>> No, if you're interested in implementing raw NTLMSSP (i.e. without the
>>> SPENGO wrapper).
>>> Yes, if the NTLM mech token is embedded in the SPNEGO initial context token.
>>>
>> What a wrinkle! :) Thanks for the info.
>>
>
>
More information about the security-dev
mailing list