[3208] in Kerberos-V5-bugs
pending/953: krb5-1.2.2
daemon@ATHENA.MIT.EDU (Byron Young)
Fri May 11 19:47:10 2001
Resent-From: gnats@rt-11.mit.edu (GNATS Management)
Resent-To: gnats-admin@rt-11.mit.edu
Resent-Reply-To: krb5-bugs@MIT.EDU, Byron Young <bkyoung@cwnet.com>
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
>Number: 953
>Category: pending
>Synopsis: krb5-1.2.2
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri May 11 19:47:00 EDT 2001
>Last-Modified:
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted:
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
