Ticket History #953: triple-DES problem on Windows

From bkyoung@cwnet.com Fri May 11 19:46:48 2001
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id TAA26823
for <bugs@RT-11.mit.edu>; Fri, 11 May 2001 19:46:47 -0400 (EDT)
Received: from april.cwnet.com (april.cwnet.com [209.21.20.250])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA18454
for <krb5-bugs@mit.edu>; Fri, 11 May 2001 19:46:46 -0400 (EDT)
Received: from cwnet.com (hiper1-d235.stk.cwnet.com [209.142.56.235])
by april.cwnet.com (8.9.0/8.9.3) with ESMTP id QAA02911
for <krb5-bugs@mit.edu>; Fri, 11 May 2001 16:41:17 -0700 (PDT)
Message-Id: <3AFC79E1.C5A0EB80@cwnet.com>
Date: Fri, 11 May 2001 16:46:41 -0700
From: Byron Young <bkyoung@cwnet.com>
To: krb5-bugs@mit.edu
Subject: krb5-1.2.2

Possible bug report:
Source krb5-1.2.2.tar.gz

Binaries built: (krb5-1.2.2 for windows)
krb5_32.dll, comerr32.dll, gssapi32.dll, xpprof32.dll
krb5.exe, telnet.exe, kinit.exe, klist.exe, kpasswd.exe
wconfig.exe
Procedure followed:
untarred dist on LINUX (Redhat 5.2, updated to glibc 2) 2.2.16
created kerbsrc.zip as per instructions
transferred kerbsrc.zip to windows 98 machine
altered win-pre.in by changing ZI to Zi for MSVC5.0
(SRV PACK 3) computability
added KRB_INSTALL_DIR= to win-pre.in
altered various Makefile.in files to remove krb4, gss-sample stuff
(not needed, I hope)
ran wconfig in each subdirectory to create new Makefile files.
nmake clean
nmake
nmake install

Configured binaries using krb5.ini, as follows:

BEGIN KRB5.INI
[libdefaults]
default_realm = BKYOUNG.COM
default_tgs_enctypes = des-cbc-crc
default_tkt_enctypes = des-cbc-crc

[realms]
BKYOUNG.COM = {
kdc = WAITER.BKYOUNG.COM:88
admin_server = WAITER.BKYOUNG.COM
default_domain = BKYOUNG.COM
}

[domain_realm]
.bkyoung.com = BKYOUNG.COM
bkyoung.com = BKYOUNG.COM
[logging]
default = FILE:d:\dev\myprojects\krb5-1.2.2\dbg\bin\krb5lib.log
END KRB5.INI

Indication of success:
The created applications, telnet.exe, krb5.exe, kinit.exe, klist.exe,
kpasswd.exe, wconfig.exe seem to function as expected with the above
config file. The dll used by the binaries also appear to work as
expected.

SUSPECTED PROBLEM:
the windows version of kinit seems to only function using des-cbc-crc
encryption. When des3-hmac-sha1 type encryption is used, kinit.exe
fails.
The kdc issues the ticket-granting-ticket, but kinit cannot decrypt it
from the supplied password. The ticket-granting-ticket is placed in
the cache. When the kdc is set to des3-hmac-sha1 encryption, the LINUX
version of kinit properly authenticates to the kdc. More puzzling, is
the fact that stepping thru both the LINUX kinit and WINDOWS kinit.exe
client simultaneously shows that each one executes the same
instructions,
but the WINDOWS kinit.exe fails at the checksum check. During this time,
the
if (krb5_enctypes_list[i].etype == key->enctype)
in krb5_c_decrypt
matched on i=6. According to etypes.c that is des3-cbc-sha1, and alias
for des3-hmac-sha1l. But, the match happed on the LINUX client just
the same (which eventually succeeded).


config files used to create "problem":
ON KDC
kdc.conf
master_key_type = des3-hmac-sha1
supported_enctypes = des3-hmac-sha1:normal
kdc_supported_enctypes = des3-hmac-sha1:normal

krb5.conf
default_tgs_enctypes = des3-hmac-sha1:normal
default_tkt_enctypes = des3-hmac-sha1:normal

ON WINDOWS CLIENT
krb5.ini
default_tgs_enctypes = des3-hmac-sha1
default_tkt_enctypes = des3-hmac-sha1

If there are no other reports of this "problem" then perhaps I
removed too much information from the various makefiles, and
broke the des3-hmac-sha1 encryption routines. In this case,
I would erase all the sources on my win98 machine, and
start from scratch, this time removing fewer items from the
various makefiles. But, before I do that (what fun!!) I'd
like to check with the experts. IF it is a bug, perhaps
it is a data alignment problem. I am not sure of all the differences
between the GNU compiler on LINUX and MSVC5.0 cl, but in the past
when I have experienced a similar type of problem, I was able
to solve it with #pragma pack (micro$oft specific) preprocessor
directive.

Thanks,
Byron Young
bkyoung@cwnet.com

Responsible-Changed-From-To: gnats-admin->krb5-unassigned
Responsible-Changed-By: raeburn
Responsible-Changed-When: Sat Jun 23 00:58:30 2001
Responsible-Changed-Why:

Responsible-Changed-From-To: krb5-unassigned->raeburn
Responsible-Changed-By: raeburn
Responsible-Changed-When: Thu Jul 5 20:36:38 2001
Responsible-Changed-Why:
I'll take 3des stuff.

State-Changed-From-To: open-analyzed
State-Changed-By: raeburn
State-Changed-When: Thu Jul 5 20:36:56 2001
State-Changed-Why:

I think we've found the problem, finally. In lib/crypto/sha1/shs.h,
there's a typedef for "LONG" that isn't used on Windows. Apparently,
the system header files somewhere provide a definition for it already
(though our Windows guy didn't tell me where), and it's not the same
as we're using, and it causes the sha1 code to be built incorrectly.

Our fix was to change LONG to SHS_LONG in shs.h, shs.c, and t_shs.c.
Please try making that change and see if it works for you.