Package: libkrb53
Version: 1.6.dfsg.1-6
Severity: important

This is a confusing one (for me, anyway):

I have a GSSAPI-capable client (curl, using the --negotiate flag).  It
is linked against the MIT krb5 libraries.  It is connecting to service
"X".  My credentials cache already has a (non-expired) ticket for X
(in addition to having a TGT).

My understanding of the krb5 protocol is that there is no need to
contact the KDC until ticket expiry.  In my test environment, the KDC
is inaccessible after having granted the tickets.

However, with the lenny version of libkrb53, not only does my client
attempt to contact the KDC (both primary and secondary, repeatedly,
for ~45 seconds); if neither KDC responds, the GSSAPI authentication
fails.

Trying the same experiment on a debian etch system with the same
credentials cache shows the same repeated attempts to contact the
KDCs, but then the GSSAPI authentication succeeds.

Further debugging:
------------------

To narrow the scope of the misbehavior, i transferred selected
libkrb53 libraries from a lenny system to an etch system and placed
them in LD_LIBRARY_PATH.  To trigger the failure, i only needed to
place the following libraries in LD_LIBRARY_PATH:

  libkrb5.so.3.3 (and symlinked libkrb5.so.3)
  libkrb5support.so.0.1 (and symlinked libkrb5support.so.0)
  libkeyutils.so.1


Outstanding questions:
----------------------

 0) i don't understand why the libraries try to contact the KDC at
    all.  Am i misunderstanding the krb5 protocol?

 1) Why is there a change in behavior between the etch and lenny
    versions of the krb5 libraries given a failure to contact the KDC
    in this case?

My larger concern is that i think this same failure is causing me
trouble in iceweasel (firefox) as well, but there are way too many
dependencies in firefox for me to debug it at this level.  It also
seems to be causing trouble for me with libneon (which is used by
svn).

FWIW, the server i'm attempting to authenticate against is apache2
with mod_auth_kerb (both from sarge), and the (non-responding) KDC is
also a sarge installation.

If i can be of any help in debugging this or providing more
information, please let me know.

Thanks for keeping krb5 in debian.

Regards,

        --dkg

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libkrb53 depends on:
ii  libc6    2.6-2                           GNU C Library: Shared libraries
ii  libcomer 1.39+1.40-WIP-2006.11.14+dfsg-2 common error description library
ii  libkeyut 1.2-3                           Linux Key Management Utilities (li

libkrb53 recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to