rmk at arm.linux.org.uk
Mon Feb 2 12:05:58 EST 2004
On Mon, Feb 02, 2004 at 11:37:26AM -0500, Sam Hartman wrote:
> >>>>> "Russell" == Russell King <rmk at arm.linux.org.uk> writes:
> Russell> Hi, I'm not sure if this is the correct place for this.
> Russell> I'm experimenting with Kerberos 1.3.1 with pam as
> Russell> packaged with Fedora Core 1 from Red Hat. I'm seeing a
> Russell> problem when trying to get renewable principals/tickets
> Russell> working.
> Are they really using stock 1.3? I'm fairly certain we fixed this bug
> late in the 1.3 release cycle before the release.
It appears to be based upon the 1.3.1 release - the gpg signature seems
to be confirm this (RH ship their source packages containing the original
tarball, and separate patch files for each modification they've made):
rmk at flint:[SOURCES]:<1027> gpg --verify krb5-1.3.1.tar.gz.asc krb5-1.3.1.tar.gz
gpg: Signature made Thu Jul 31 19:29:27 2003 BST using RSA key ID F376813D
gpg: Good signature from "Tom Yu <tlyu at MIT.EDU>"
gpg: please do a --check-trustdb
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Fingerprint: 52 E0 3E E9 38 AE 70 58 3F 21 5C C8 5C C4 55 24
Looking at the diffs between the files in this archive and with all the
Red Hat patches applied, I don't see anything which changes the behaviour
of the KDC in do_as_req.c. krb5-1.3.1/src/lib/krb5/krb/get_in_tkt.c
doesn't contain any changes.
> Russell> So:
> Russell> - should the kerberos client library have a hardcoded
> Russell> lifetime of one day?
> It certainly does. There is not a krb5.conf parameter to adjust this
> (nor is there one documented) in the MIT code.
Neither is there one documented in the code I'm looking at.
> Russell> - should the kerberos client libraries allow these
> Russell> requests for renewable tickets with renewlife < lifetime?
> I don't see why not; it is a fairly strange request though.
That's my thinking as well - however, because of the hard-coded lifetime
in the library of 24 hours, and a smaller renewable lifetime in the
configuration, it appears to be a "normal" situation. (Maybe this is
an example of a broken configuration?)
> Russell> - should krb5kdc extend the renewable ticket lifetime if
> Russell> it has shortened the returned ticket lifetime?
> If renewable_ok is set, yes. That's what the spec says.
Ok. However, verify_as_reply() in get_in_tkt() seems buggy:
|| ((request->kdc_options & KDC_OPT_RENEWABLE) &&
(request->rtime != 0) &&
(as_reply->enc_part2->times.renew_till > request->rtime))
|| ((request->kdc_options & KDC_OPT_RENEWABLE_OK) &&
!(request->kdc_options & KDC_OPT_RENEWABLE) &&
(as_reply->enc_part2->flags & KDC_OPT_RENEWABLE) &&
(request->till != 0) &&
(as_reply->enc_part2->times.renew_till > request->till))
If kdc_options had KDC_OPT_RENEWABLE set, and the returned ticket's
renew_till time is later than the requested rtime, then we error out
with KRB5_KDCREP_MODIFIED - and this is exactly what's happening for
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
More information about the krbdev