[jcifs] None
Allen, Michael B (RSCH)
Michael_B_Allen at ml.com
Thu Mar 27 13:22:49 EST 2003
We really should make an HTML page out of this and add a link to it from the site.
> -----Original Message-----
> From: eglass1 at attbi.com [SMTP:eglass1 at attbi.com]
> Sent: Wednesday, March 26, 2003 6:14 AM
> To: miallen at eskimo.com
> Cc: jcifs at samba.org
> Subject: [jcifs] None
>
> I noticed a few inconsistencies with the NTLMSSP stuff from the "innovation"
> document (http://www.innovation.ch/java/ntlm.html) which appear to be causing
> the issues with Win9x clients. I did a whole bunch of research, and here is
> what I came up with. I apologize in advance for the size of this message; it
> will probably have to be "pushed out" to the jCIFS list.
>
> This is based primarily on the OpenGroup documentation available at:
>
> http://www.opengroup.org/comsource/techref2/NCH1222X.HTM
>
> The rest is taken from a patch to the squid proxy server which I more or less
> stumbled upon, but which has been extremely helpful:
>
> http://cvs.sourceforge.net/cgi-
> bin/viewcvs.cgi/squid/squid/src/auth/ntlm/helpers/smbpasswd/Attic/ntlm.h?
> rev=1.1.2.4&only_with_tag=ntlm_smbpasswd&content-type=text/vnd.viewcvs-markup
>
> Attached is a testing program (NTLMRelay.java & NTLMAnalysis.java) which does a
> man-in-the-middle analysis of the NTLM messages between a client and server.
> Assuming you have a web server providing NTLM authentication running on port 80
> on host "foo", you would run:
>
> java NTLMRelay 888 foo 80 log.txt
>
> and connect to http://localhost:888, which will forward requests to port 80 on
> foo. Results for several scenarios are attached in "results.txt".
>
> I will also be sending the patches based on this analysis which fix the
> authentication for Windows 2000, Windows XP, Windows 98 and Windows 95 clients.
>
>
> MESSAGE FORMATS:
>
> There are a few "variants" of each of the message types; what I am calling
> the "conformant" form in the notes below is based on the OpenGroup documented
> format. The "extended" form (which is used by most of the newer clients) is
> taken from the squid stuff and interpretation of results using the attached
> testing program.
>
> The flags mentioned in these messages are described later (as best as I could
> infer their meaning). In addition, the "security buffer" type mentioned is
> defined in the OpenGroup documentation, and consists of:
>
> Length (2 bytes)
> little-endian, 16-bit unsigned value
> Maximum Length (2 bytes)
> little-endian, 16-bit unsigned value
> Offset (4 bytes)
> little-endian, 32-bit unsigned value
>
> This is used as a pointer to a data value (typically a string) within the
> message. The length is the length of the data buffer. The maximum length is
> the amount of space allocated to the data (usually the same as the length).
> The offset is in bytes, from the start of the message.
>
> If the data in the buffer is a string, it is nonterminated and may be either
> Unicode (if negotiated via the NTLMSSP_NEGOTIATE_UNICODE flag described in the
> flags section) or OEM. I'm not sure if that really means in the DOS OEM
> codepage (i.e., Cp437) or the Windows ANSI codepage (i.e., Cp1252) -- I
> understand there is a difference, but for the values being passed (username,
> domain, workstation) it is more or less ASCII. This is one of the issues
> affecting the Win9x clients with jCIFS -- they don't negotiate Unicode, but the
> hardcoded Type 2 flags in the current version of NtlmSsp indicate that only
> Unicode is accepted.
>
> Type 1 message -- conformant form
>
> 0. Signature (8 bytes)
> null-terminated ASCII string ("NTLMSSP", 0x4e544c4d53535000)
> 8. Type (4 bytes)
> little-endian, 32-bit unsigned value (1, 0x01000000)
> 12. Flags (4 bytes)
> little-endian, 32-bit unsigned value
>
> This is the message format described by the OpenGroup documentation.
>
>
> Type 1 message -- extended form
>
> 0. Signature (8 bytes)
> null-terminated ASCII string ("NTLMSSP", 0x4e544c4d53535000)
> 8. Type (4 bytes)
> little-endian, 32-bit unsigned value (1, 0x01000000)
> 12. Flags (4 bytes)
> little-endian, 32-bit unsigned value
> 16. Supplied Domain (8 bytes)
> security buffer (OEM String)
> 24. Supplied Workstation (8 bytes)
> security buffer (OEM String)
> 32. Data Block
>
> This is described in the squid code, and appears to be the form used
> by "modern" clients (Win2k, WinXP).
>
> The supplied domain and workstation (extended form) are only sent
> when "automatic" NTLM authentication is being performed (i.e., single-sign-
> on). Manual NTLM authentication effectively uses conformant form; although
> security buffers are allocated for the supplied domain and workstation, they
> are empty.
>
> Windows 95 clients use conformant form (even during automatic NTLM), in that no
> supplied domain or workstation are sent by these clients. They appear to
> allocate empty security buffers for these fields, however, as well as some
> extraneous information at the end (which appears to be an empty 32-bit value
> and two more empty security buffers). The first two empty buffers may be the
> empty supplied domain and workstations; don't know what the additional stuff is
> for.
>
>
> Type 2 message -- conformant form
>
> 0. Signature (8 bytes)
> null-terminated ASCII string ("NTLMSSP", 0x4e544c4d53535000)
> 8. Type (4 bytes)
> little-endian, 32-bit unsigned value (2, 0x02000000)
> 12. TargetName (8 bytes)
> security buffer (String)
> 20. Flags (4 bytes)
> little-endian, 32-bit unsigned value
> 24. Challenge (8 bytes)
> random challenge
> 32. Data Block
>
> This is the message format described by the OpenGroup documentation. The
> OpenGroup documentation indicates that the TargetName is a string (as opposed
> to a security buffer); this is apparently incorrect. This is the "barebones"
> type 2 message.
>
>
> Type 2 message -- jCIFS form
>
> 0. Signature (8 bytes)
> null-terminated ASCII string ("NTLMSSP", 0x4e544c4d53535000)
> 8. Type (4 bytes)
> little-endian, 32-bit unsigned value (2, 0x02000000)
> 12. TargetName (8 bytes)
> security buffer (String)
> 20. Flags (4 bytes)
> little-endian, 32-bit unsigned value
> 24. Challenge (8 bytes)
> random challenge
> 32. empty (8 bytes)
> empty bytes
> 40. Data Block
>
> This is the form currently used by jCIFS. The 8 empty bytes at the end
> probably represent an empty server context (see below).
>
>
> Type 2 message -- extended form
>
> 0. Signature (8 bytes)
> null-terminated ASCII string ("NTLMSSP", 0x4e544c4d53535000)
> 8. Type (4 bytes)
> little-endian, 32-bit unsigned value (2, 0x02000000)
> 12. TargetName (8 bytes)
> security buffer (String)
> 20. Flags (4 bytes)
> little-endian, 32-bit unsigned value
> 24. Challenge (8 bytes)
> random challenge
> 32. Context (8 bytes)
> context information of some sort?
> 40. ServerInfo (8 bytes)
> security buffer (host information)
> 48. Data Block
>
> This is the form described by the squid code, and used by IIS 5.0. I wasn't
> able to find any documentation on the meaning of the Context field; as
> mentioned previously, jCIFS effectively sends 8 empty bytes. The ServerInfo
> buffer points to a "host information" block. This may be documented somewhere,
> but appears to be a sequence of subblocks, each consisting of:
>
> Type (2 bytes)
> little-endian, 16-bit unsigned value
> 1 = NT server name
> 2 = NT domain
> 3 = fully-qualified DNS host name (host.domain.com)
> 4 = DNS domain (domain.com)
> Length (2 bytes)
> little-endian, 16-bit unsigned value
> String Block (length bytes)
>
> with the sequence being terminated by a type "0" subblock of zero length
> (0x00000000). The string values in the subblocks appear to always be sent as
> Unicode (even to Win9x clients).
>
>
> Type 3 message -- non-conformant form
>
> 0. Signature (8 bytes)
> null-terminated ASCII string ("NTLMSSP", 0x4e544c4d53535000)
> 8. Type (4 bytes)
> little-endian, 32-bit unsigned value (3, 0x03000000)
> 12. LanManager Response (8 bytes)
> security buffer
> 20. NT Response (8 bytes)
> security buffer (empty)
> 28. DomainName (8 bytes)
> security buffer (OEM String)
> 36. UserName (8 bytes)
> security buffer (OEM String)
> 44. Workstation (8 bytes)
> security buffer (OEM String)
> 52. Data Block
>
> This is the form sent by Win9x clients. This is apparently undocumented, but
> is simply the conformant form below with the session key and flags truncated.
> Strings are always in OEM (since there is no flag to specify Unicode, and these
> clients don't support it anyway). Also significant is the absence of an NT
> hash -- only the LanManager response is supplied. This is the other problem
> with the Win9x clients and jCIFS; even after the Unicode issues are resolved,
> SmbSession.logon results in SmbComSessionSetupAndX throwing an exception at
> line 124 due to an unexpected zero-length unicodePassword.
>
>
> Type 3 message -- conformant form
>
> 0. Signature (8 bytes)
> null-terminated ASCII string ("NTLMSSP", 0x4e544c4d53535000)
> 8. Type (4 bytes)
> little-endian, 32-bit unsigned value (3, 0x03000000)
> 12. LanManager Response (8 bytes)
> security buffer
> 20. NT Response (8 bytes)
> security buffer
> 28. DomainName (8 bytes)
> security buffer (String)
> 36. UserName (8 bytes)
> security buffer (String)
> 44. Workstation (8 bytes)
> security buffer (String)
> 52. Session Key (8 bytes)
> security buffer
> 60. Flags (4 bytes)
> little-endian, 32-bit unsigned value
> 64. Data Block
>
> This is the form documented in both the OpenGroup document and the squid code.
> The session key is apparently always empty; according the OpenGroup document,
> this is only used during datagram authentication. It is interesting to note
> that the OpenGroup document also indicates that the flags are unused in the
> Type 3 message. This does not appear to be the case; the Unicode flag, at
> least, appears to be significant. Upon analysis, it appears that IE
> regurgitates the received Type 2 flags with slight modifications for the Type 3
> message.
>
> In both the non-conformant and conformant forms there appear to be trailing
> bytes at the very end of the message, after the security buffer data (24 bytes
> in the non-conformant form, and 48 in the conformant form). I will take a
> blind stab at this and guess that it is either random junk or a signature of
> some sort.
>
> Another interesting phenomenon presents itself when a Windows 2000 box is
> authenticating to IIS locally (i.e., the server and client are the same
> machine). When "automatic" NTLM is used, the Type 2 message has the
> NTLMSSP_NEGOTIATE_LOCAL_CALL flag set. The client responds with a conformant
> Type 3 message that is essentially completely empty. When using manual NTLM,
> the flag is not set, and authentication is performed as though the client was
> external.
>
>
> FLAGS:
>
> NTLMSSP_NEGOTIATE_UNICODE = 0x00000001
> Type 1 message -- indicates that the client can accept unicode strings in the
> body of security buffers.
> Type 2 message -- indicates that the server will send unicode strings in the
> body of security buffers.
>
> NTLMSSP_NEGOTIATE_OEM = 0x00000002
> Type 1 message -- indicates that the client can accept OEM strings in the body
> of security buffers.
> Type 2 message -- indicates that the server will send OEM strings in the body
> of security buffers.
> I'm not sure if this really means DOS OEM codepage (i.e., Cp437) or Windows
> ANSI codepage (i.e., Cp1252); for the fields being sent (domain, workstation,
> username), this information will usually be ASCII-clean anyways.
>
> NTLMSSP_REQUEST_TARGET = 0x00000004
> Type 1 message -- sent by the client to request that the server's
> authentication realm (domain, server, or share?) be included in the Type 2
> message (specifying where the authentication is occurring).
> Although the opengroup document indicates that the authentication can occur at
> the server or at its domain, the squid code includes an additional flag for
> a "share" target type. Also, the opengroup document states that none of the
> clients set this flag; all tested clients, however, did have this flag set.
>
> NTLMSSP_NEGOTIATE_SIGN = 0x00000010
> Specifies that generated messages should contain a digital signature. None of
> the tested clients set this flag.
>
> NTLMSSP_NEGOTIATE_SEAL = 0x00000020
> Specifies that generated messages should be encrypted for transmission. None
> of the tested clients set this flag.
>
> NTLMSSP_NEGOTIATE_DATAGRAM_STYLE = 0x00000040
> This is from the squid code. I'm not sure what this means, although the
> opengroup document states that the session key and flag fields for the Type 3
> message are only used during datagram authentication; it might be possible that
> setting this flag is intended to enable those fields during connection-oriented
> authentication as well. None of the tested clients set this flag.
>
> NTLMSSP_NEGOTIATE_LM_KEY = 0x00000080
> Enables message sequence and replay detection, according to the opengroup
> documentation. None of the tested clients set this flag.
>
> NTLMSSP_NEGOTIATE_NETWARE = 0x00000100
> This is from the squid code. I'm guessing that this indicates authentication
> against Novell NDS rather than a domain, but I have no idea. None of the
> tested clients set this flag.
>
> NTLMSSP_NEGOTIATE_NTLM = 0x00000200
> This specifies that NTLM authentication is being used. This is always set for
> all messages. I'm not sure if the Netware flag is intended to be an
> alternative.
>
> NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED = 0x00001000
> Type 1 message -- This is from the squid code, and is part of the extended Type
> 1 message. The client sends this to indicate that the workstation's domain is
> being supplied for use as a desired authentication target.
>
> NTLMSSP_NEGOTIATE_OEM_WORKSTATION_SUPPLIED = 0x00002000
> Type 1 message -- This is from the squid code, and is part of the extended Type
> 1 message. The client sends this to indicate that the workstation's host name
> is being supplied.
>
> NTLMSSP_NEGOTIATE_LOCAL_CALL = 0x00004000
> Type 2 message -- The server may set this flag if the server and client are on
> the same machine.
>
> NTLMSSP_NEGOTIATE_ALWAYS_SIGN = 0x00008000
> According to the opengroup documentation, the client sets this flag to indicate
> that each message should be signed with a dummy signature. This flag was set
> on all tested clients; additionally, IIS sends this flag as part of the Type 2
> message.
>
> NTLMSSP_TARGET_TYPE_DOMAIN = 0x00010000
> Type 2 message -- The server sets this flag to indicate that the target
> authentication realm is a domain.
>
> NTLMSSP_TARGET_TYPE_SERVER = 0x00020000
> Type 2 message -- The server sets this flag to indicate that the target
> authentication realm is a server (server is not part of a domain?)
>
> NTLMSSP_TARGET_TYPE_SHARE = 0x00040000
> Type 2 message -- The server sets this flag to indicate that the target
> authentication realm is a share. This is from the squid stuff; I'm not sure
> when this would apply.
>
> NTLMSSP_NEGOTIATE_NTLM2 = 0x00080000
> Indicates that the client/server support NTLM version 2. This is from the
> squid code.
>
> NTLMSSP_REQUEST_INIT_RESPONSE = 0x00100000
> This is from the squid code. This flag was not set on any of the tested
> clients.
>
> NTLMSSP_REQUEST_ACCEPT_RESPONSE = 0x00200000
> This is from the squid code. This flag was not set on any of the tested
> clients.
>
> NTLMSSP_REQUEST_NON_NT_SESSION_KEY = 0x00400000
> This is from the squid code. This flag was not set on any of the tested
> clients.
>
> NTLMSSP_NEGOTIATE_TARGET_INFO = 0x00800000
> This is from the squid code. Not sure exactly what this means, although it was
> set on the 2000/XP clients.
>
> NTLMSSP_NEGOTIATE_128 = 0x20000000
> This is from the squid code. Not sure exactly what this means, although it was
> set on the 2000/XP clients.
>
> NTLMSSP_NEGOTIATE_KEY_EXCH = 0x40000000
> This is from the squid code. This flag was not set on any of the tested
> clients.
>
> << File: NTLMRelay.java >> << File: NTLMAnalysis.java >> << File: results.txt >>
More information about the jcifs
mailing list