[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