[jcifs] jCIFS Updates, redux

eglass1 at comcast.net eglass1 at comcast.net
Wed Jul 9 22:23:45 EST 2003


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-tar
Size: 17719 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20030709/eb1bb36f/attachment.tar


More information about the jcifs mailing list