Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) by krbdev.mit.edu (8.9.3p2) with ESMTP id VAA02692; Wed, 10 Dec 2003 21:45:39 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id hBB2jdEU002138; Wed, 10 Dec 2003 21:45:39 -0500 (EST) To: rt@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #2058] Problems with ticket lifetimes in K4 References: From: Tom Yu Date: Wed, 10 Dec 2003 21:45:39 -0500 In-Reply-To: ("kwc@citi.umich.edu via RT"'s message of "Wed, 10 Dec 2003 17:21:59 -0500 (EST)") Message-Id: Lines: 29 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 1468 >>>>> "kwc" == kwc@citi umich edu via RT writes: kwc> 1) We have many Windows AFS clients which use the default kwc> authentication code found there. This code, unlike all the kwc> other AFS authentication code, uses K4 UDP instead of rx. kwc> The AFS K4 code checks the issue time of the ticket it gets kwc> back and compares it to its local time. If those times are kwc> more than " clock skew" off, it fails with a clock skew error. kwc> The adjustment of the the issue time (kerb_time.tv_sec) causes kwc> the Windows AFS client to fail with a clock skew error. The backwards adjustment of issue time is meant to expire the krb4 ticket at the same time as an equivalent krb4 ticket would expire. I suppose we could round the lifetime down if necessary, though that would cause tickets to expire much sooner than expected if you're in the exponential lifetime region. kwc> 2) The krb_life_to_time() routine returns 0xffffffff when the kwc> requested lifetime is "unlimited" (0xff in the request). So kwc> v4endtime becomes 0xffffffff. When this is used in the min() kwc> functions, -1 is found to be the minimum. Thus a ticket with kwc> an end time of 0xffffffff is returned. This lifetime should kwc> be limited by the life of the TGT and the service's lifetime. Are you mixing krb4 implementations? The version of krb_life_to_time() that is in krb5-1.3.1 does not return 0xffffffff for a requested lifetime of 0xff. ---Tom