[jcifs] Kerberos over HTTP
Christopher R. Hertel
crh at ubiqx.mn.org
Mon Jan 20 05:54:57 EST 2003
I assume folks are aware of this draft:
http://meta.cesnet.cz/software/heimdal/draft-brezak-spnego-http-04.txt
Would be interesting to extend the jCIFS tools to do Kerberos. ;)
Ronald: Some notes on this paragraph from your NTLM over HTTP document:
The host and domain strings are ASCII (or possibly ISO-8859-1), are
uppercased, and are not nul-terminated. The host name is only the
host name, not the FQDN (e.g. just "GOOFY", not "GOOFY.DISNEY.COM").
The offsets refer to the offset of the specific field within the
message, and the lengths are the length of specified field. For
example, in the above message host_off = 32 and dom_off = host_off +
host_len. Note that the lengths are included twice (for some
unfathomable reason).
- The host and domain strings are NetBIOS names. Octet values less than
128 are ASCII, but greater than 127 they may represent any of several
character sets. Before Unicode was adopted, Microsoft used the DOS
OEM Codepages that were original created by IBM (I believe). Even
with Unicode, the NetBIOS names are represented as octet strings, so
they might be Windows-1252 or suchlike.
- Since they are NetBIOS names, they are *probably* the same as the DNS
hostname--but not necessarily.
- The unfathomable reason that the lengths are included twice may be due
to the layers upon layers of protocols and APIs that Microsoft uses to
build the on-the-wire packets. NTLMSSP messages are built in much the
same way as MS-RPC packets (though there are differences, according to
Tridge).
NTLMSSP messages are formatted in NDR (Network Data Representation)
format. NDR is a pre-defined format for transferring data across a
network so that dissimilar systems can unpack it in a sensible fashion.
The code that does the conversion (Marshalling) to NDR probably does a
bit of padding. It probably fills the padding bytes with random garbage
and, in this case, the random garbage just happens to be the length
value. My guess is that one or the other of those bytes could be
replaced with 0x00 and the authentication would still work.
Hope that's useful. I'm sure that there's a lot there that can be expanded
upon (and/or corrected).
Chrids -)-----
--
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh at ubiqx.org
More information about the jcifs
mailing list