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 ; 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 ; 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 ; 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 To: krb5-bugs@mit.edu Subject: krb5-1.2.2 >Number: 953 >Category: krb5-libs >Synopsis: triple-DES problem on Windows >Confidential: no >Severity: serious >Priority: medium >Responsible: raeburn >State: analyzed >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Fri May 11 19:47:00 EDT 2001 >Last-Modified: Thu Jul 5 20:39:04 EDT 2001 >Originator: Byron Young >Organization: >Release: krb5-1.2.2 >Environment: >Description: 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 >How-To-Repeat: >Fix: >Audit-Trail: 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. >Unformatted: