[security-dev 01605]: Re: Request for comment: spec: NTLM as a SASL mech

[Natalie Li]

Max (Weijun) Wang wrote:
> On Feb 4, 2010, at 4:15 PM, Natalie Li wrote:
>
>   
>>> public final class Client {
>>>    /**
>>>     * Creates an NTLM Client instance.
>>>     * @param version the NTLM version to use, which can be:
>>>     * <ol>
>>>     * <li>1: Original NTLM v1
>>>     * <li>1lm: Original NTLM v1, LM only
>>>     * <li>1ntlm: Original NTLM v1, NTLM only
>>>     * <li>1+: NTLM v1 with Client Challenge
>>>     * <li>2: NTLM v2
>>>     * <li>2lm: NTLM v2, LM only
>>>     * <li>2ntlm: NTLM v2, NTLM only
>>>     * </ol>
>>>     * If null, "1+" will be used.
>>>       
>> I'm not familiar with the Java syntax so could you please elaborate on how you come up with the param version?
>> You can find the following 2 fields in NTLMSSP Type 3 message:
>>
>> LmChallengeResponse
>> NtChallengeResponse
>>
>> So, the Type 3 message could contain the following challenge responses:
>>
>> NTLM
>> LM and NTLM
>> LMv2 and NTLMv2
>>     
>
> I observe that when the client only provides LM, the authentication still goes fine.
Typically, a client provides both LmChallengeResponse and 
NtChallengeResponse to the server, if the provided LmChallengeResponse 
matches the LM, LMv2 challenge responses generated by the server or the 
provided NtChallengeResponse matches the NTLM, or NTLMv2 generated by 
the server, authentication succeeds if LMCompatibiity level is set to 
0.  What challenge responses are accepted by Windows server depends upon 
the LMCompatibilityLevel setting.

Values:
      0 accept all
      1 accept all
      2 accept all
      3 accept all
      4 refuse LM
      5 refuse LM & NTLM



>  The same for v2 messages. This is why I allow the client to choose whatever it want to send.
>   
I'd stick with the following combination. But your choice.

Values:
      0 Send LM & NTLM responses
      1 Send LM & NTLM - use NTLMv2 session security if negotiated
      2 Send NTLM response only
      3 Send NTLMv2 response only
      4 Send NTLMv2 response only
      5 Send NTLMv2 response only



> By "1+", I mean the NTLM2 response described at --
>
>    http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse
>
> Altogether, the client can choose 7 styles.
>
>   
See above.

>>>    public byte[] type3(byte[] type2, byte[] nonce) throws NTLMException;
>>>       
>> I'm missing the context. What's the purpose of the nonce when generating the type 3 message?
>>     
>
> The class does not deal with random bytes generation inside, so the caller needs to provide the nonce.
>
>   
I was not asking why the nonce is passed to the API.  I'm asking the 
usage of the nonce in the function.  Just looking at the function 
signature, it doesn't provide me enough context as to how the nonce is used.

>   
>>> 1. As described by the MSDN article, when LMCompatibilityLevel is set to a
>>>   high value on the server, certain low value request is not supported
>>>       
>> This statement isn't clear (See below).
>>     
>
> Not clear, I'll use your words below on NTLMv2.
>
>   
>>> 2. There's no protocol for the server to tell the client to use a higher
>>>   version, so you must manually setup this config on the client side
>>>       
>> The use of NTLM or NTLMv2 authentication is not negotiated between the client and server.  Hence, authentication might fail if the server mandates NTLMv2 authentication while the client uses NTLM authentication.
>>     
>
> Yes, this is what I say "manually setup this config on the client side".
>
>   
Regards,

Natalie

> Thanks
> Max
>
>   
>> Natalie
>>
>>
>>
>> Max (Weijun) Wang wrote:
>>     
>>> Hi All
>>>
>>> Please take a review on this draft before I send it for CCC:
>>>
>>>   http://cr.openjdk.java.net/~weijun/spec/NTLMSASL.0.1
>>>
>>> The spec includes a raw NTLM API defined in com.sun.* namespace and describes the newly added SASL mech.
>>>
>>> Thanks
>>> Max
>>>
>>>  
>>>       
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20100204/7f5c1018/attachment.htm>