[jcifs] jCIFS Updates, redux

[eglass1 at comcast.net]

> Q: Did you change SmbComSessionSetupAndX.java or
> SmbComTreeConnectAndX.java since patches.zip? Similarly, are you certain 
> your change to SmbComSessionSetupAndX.java will not break Win95/98/ME
> clients that expect a password length of 0 in some cases?: 
> 
> 62,64c62,64
> <                 passwordLength = unicodePasswordLength = 24;
> <                 // fix for win9x clients 
> <                 if (unicodePassword.length == 0) unicodePasswordLength = 0;
> ---
> >                 // fix for NTLMv2 or empty NTLM/LM 

> >                 passwordLength = accountPassword.length;
> >                 unicodePasswordLength = unicodePassword.length;
> 

The changes I had made to those were just to allow any length for the
ansiHash/unicodeHash fields.  This was needed for NTLMv2 (since the unicodeHash
can be an arbitrary length).  LMv2 has the same "footprint" as LM
(24-byte ansiHash).  I basically just took out all the hardcoding of the
password lengths altogether and used the actual lengths of the fields instead;
this works with NTLMv2 responses (which can be bigger than 24 bytes) as well
as Win9x clients' LM responses (which are 0 bytes).  The LMv2 stuff will work
using either the "stock" 0.7.10 code or with the change above.

> Finally, please approve the new jcifs.smb.lmCompatability property
> description for the API Overview page:
> 
> "This client can perform NTLM and LMv2 authentication. The default 
> behavior is to negotiate a mechanism however this can be specified
> explicitly using this property with an integer that specifies the "level" 
> of security:
> 
>     * 0,1 - Use LM/NTLM (the default)
>     * 2 - Use only NTLM
>     * 3,4,5 - Use LMv2
> 
> These values mirror those used with the Windows registry key
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa used for the 
> same purpose. See the page entitled <The NTLM Authentication Protocol>
> for a technical description of these authentication mechanisms."
> 

Looks pretty good; it doesn't negotiate a mechanism, however.  The default is
Level 0, which sends the LM and NTLM responses in the ansiHash and unicodeHash
fields, respectively (which is what we currently do).  Level 1 is the same.
Level 2 will send the NTLM response in *both* the ansiHash and unicodeHash
fields (removing the weak LM response).  Levels 3, 4, and 5 send the LMv2
response in the ansiHash field with an empty unicodeHash field.

I would maybe change the first part to something like:

This client can perform NTLM and LMv2 authentication.  The default behavior is
to use NTLM version 1.  This can be changed by using this property with an
integer that specifies the "level" of security:

0,1 -- Sends LM and NTLM responses.  This is the default behavior.

2 -- Sends only the NTLM response.  This is more secure than Levels 0 and 1,
because it eliminates the cryptographically-weak LM response.

3,4,5 -- Sends only the LMv2 response.  This offers a higher level of security.


Eric