[jcifs] jCIFS Updates, redux

[Allen, Michael B (RSCH)]

Very nice. I would like to see the "Recursive Composition" technique
pushed all the way up like TypeXMessage.encodeBytes( byte[] dst,
int dstIndex, ...) but considering those messages are just passed to
Base64.encode() the buffering technique is already inverted so I don't 
suppose it really matters. The 'new byte[0]'s in Type1Message.toByteArray()
could probably go away. Then again, I would have to do a lot of cleanup 
of my own code to meet these standards.

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;

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."

Good job,
Mike

> -----Original Message-----
> From:	eglass1 at comcast.net [SMTP:eglass1 at comcast.net]
> Sent:	Wednesday, July 09, 2003 8:24 AM
> To:	Michael_B_Allen at ml.com
> Cc:	jcifs at lists.samba.org
> Subject:	[jcifs] jCIFS Updates, redux
> 
> Mike/all,
> 
> Attached is a bunch of cleaned-up code, including support for LMv2.  I went 
> ahead and removed the NTLMv2 response stuff, since it was commented out 
> anyways; this was where the writeTime function was needed, so it's a moot point 
> for now.  Theoretically, I suppose I could test whether the TZ adjustment is 
> needed by frobbing with my time and timezone settings and see what ends up in 
> the Type 3 messages.  If/when I put the NTLMv2 stuff back in I'll do some 
> experimenting with this -- in the meantime, LMv2 works great.
> 
> The use of LMv2 is controlled via the "jcifs.smb.lmCompatibility" property, 
> which mirrors the corresponding registry setting:
> 
> 0,1 -- Use LM/NTLM (the default)
> 2 -- Use only NTLM
> 3,4,5 -- Use LMv2
> 
> The rest of this message is a description of the issue I was seeing with 
> NTLMv2, and is a boring read -- feel free to skip it. ;)
> 
> Basically, the blob in the NTLMv2 response contains the "target information" 
> structure sent in the Type 2 message (which contains a list of NetBIOS and DNS 
> names).  When dealing with NTLMSSP messages, this works great -- you grab the 
> target information block out of the Type 2 message, and use it directly in the 
> calculation of the NTLMv2 response.  This is the case when "extended security" 
> handshaking takes place; the security blob in the session setup response 
> contains a Type 2 message with the appropriate target information block, and 
> the second setup request contains the Type 3.
> 
> In our case, however (non-extended security), we just have the encryptionKey 
> (server challenge) to work with.  We need to calculate the ansiHash (LMv2 
> response) and unicodeHash (NTLMv2 response).
> 
> For the LMv2 response, this is easy -- you just create a random client nonce 
> and calculate the HMAC of the server challenge + the nonce.
> 
> The NTLMv2 response is a bit trickier, since we create the blob; this contains 
> a bunch of stuff, including the nonce, a timestamp, and the target information 
> block.  Note, however, that we don't *have* the target information block; so we 
> have to create one.  My initial attempt at this was simply to use a big block 
> of random data for the blob.  There is some documentation in Samba-TNG 
> (smbencrypt.c) which indicates that this works.  And it did, *most* of the 
> time.  I ran into errors, however, when attempting to connect to servers that 
> were members of a different domain.
> 
> Apparently, when a user in domain 'A' is connecting to a server which is also a 
> member of 'A', the contents of the blob are not checked at all; the entire blob 
> is essentially treated as a giant client nonce.  When a user in 'A' accesses a 
> server that is a member of 'B', however, I found that authentication would only 
> succeed if the target information block within the blob contained (at a 
> minimum) an entry for domain 'B'.
> 
> Currently, the unicodeHash is created via:
> 
> NtlmPasswordAuthentication.getUnicodeHash(challenge);
> 
> Which just creates the NTLM response from the password and challenge.  To 
> create the NTLMv2 response, we need:
> 
> The user's domain (which we have)
> The username (which we have)
> The server challenge (which we have)
> The client nonce (which we can create)
> The target information block (which we *could* create properly, *if* we had the 
> server's domain)
> 
> To successfully create the NTLMv2 response, we need the domain to which the 
> server belongs.  Technically, I believe we have this information (since it 
> seems to be sent in the "negotiate protocol" response); it might be feasible to 
> change getUnicodeHash to accept this as an additional parameter, if desired.
> 
> However, in the end it doesn't really matter; from a cryptographic standpoint, 
> the LMv2 response is as strong as the NTLMv2 response.  The LMv2 response is 
> accepted by all servers which understand NTLMv2.  There just isn't much point 
> in going to the extra effort to implement NTLMv2.
> 
> 
> Eric
>  << File: update.tgz >>