Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by krbdev.mit.edu (8.9.3p2) with ESMTP id RAA02592; Wed, 10 Dec 2003 17:21:56 -0500 (EST) Received: from citi.umich.edu (rock.citi.umich.edu [141.211.133.90]) by citi.umich.edu (Postfix) with ESMTP id D8BFE2094A for ; Wed, 10 Dec 2003 17:21:55 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: rt@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #2058] Problems with ticket lifetimes in K4 In-Reply-To: Message from "Sam Hartman via RT" of "Wed, 10 Dec 2003 14:15:05 EST." MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Dec 2003 17:21:53 -0500 From: Kevin Coffman Message-Id: <20031210222156.D8BFE2094A@citi.umich.edu> RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 3814 > Kevin, I find this bug report unreadable. I have no idea what you're > complanaing about, why you think it is wrong, or why you think your > fix is correct. > > If you want a reasonable probability of the problem being fixed, > please step back, explain the issue clearly and explain what's going > on. Then explain what your fix does. > > Thanks. There are two different, but related, problems that I ran into with the the new K4 lifetime code added in 1.3. We've been carrying local mods that do the afs lifetime handling, so I appreciate this code being put into the base MIT release. I'm sorry I didn't have the opportunity to test this earlier. 1) We have many Windows AFS clients which use the default authentication code found there. This code, unlike all the other AFS authentication code, uses K4 UDP instead of rx. The AFS K4 code checks the issue time of the ticket it gets back and compares it to its local time. If those times are more than " clock skew" off, it fails with a clock skew error. The adjustment of the the issue time (kerb_time.tv_sec) causes the Windows AFS client to fail with a clock skew error. 2) The krb_life_to_time() routine returns 0xffffffff when the requested lifetime is "unlimited" (0xff in the request). So v4endtime becomes 0xffffffff. When this is used in the min() functions, -1 is found to be the minimum. Thus a ticket with an end time of 0xffffffff is returned. This lifetime should be limited by the life of the TGT and the service's lifetime. Let me know if I still haven't been clear enough. K.C. Here is a cleaner patch: Index: kerberos_v4.c =================================================================== RCS file: /afs/umich.edu/group/itd/software/packages/k/kerberos-5/cvs/kr b5/src/kdc/kerberos_v4.c,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 kerberos_v4.c --- kerberos_v4.c 21 Jul 2003 20:28:38 -0000 1.1.1.3 +++ kerberos_v4.c 10 Dec 2003 22:16:57 -0000 @@ -743,13 +743,6 @@ v4req_end = min(v4req_end, kerb_time.tv_sec + sk5life); lifetime = krb_time_to_life(kerb_time.tv_sec, v4req_end); v4endtime = krb_life_to_time(kerb_time.tv_sec, lifetime); - /* - * Adjust issue time backwards if necessary, due to - * roundup in krb_time_to_life(). XXX This frobs - * kerb_time, which is potentially problematic. - */ - if (v4endtime > v4req_end) - kerb_time.tv_sec -= v4endtime - v4req_end; #ifdef NOENCRYPTION memset(session_key, 0, sizeof(C_Block)); @@ -932,18 +925,19 @@ /* Bound requested lifetime with service and user */ v4endtime = krb_life_to_time((KRB4_32)ad->time_sec, ad-> life); v4req_end = krb_life_to_time(kerb_time.tv_sec, req_life); - v4req_end = min(v4endtime, v4req_end); + + /* + * Even if they requested unlimited lifetime, + * it is still limited by the end of their TGT + */ + if (v4req_end == 0xffffffff) + v4req_end = v4endtime; + else + v4req_end = min(v4endtime, v4req_end); v4req_end = min(v4req_end, kerb_time.tv_sec + sk5life); lifetime = krb_time_to_life(kerb_time.tv_sec, v4req_end); v4endtime = krb_life_to_time(kerb_time.tv_sec, lifetime); - /* - * Adjust issue time backwards if necessary, due to - * roundup in krb_time_to_life(). XXX This frobs - * kerb_time, which is potentially problematic. - */ - if (v4endtime > v4req_end) - kerb_time.tv_sec -= v4endtime - v4req_end; /* unseal server's key from master key */ memcpy(key, &s_name_data.key_low, 4);