Ticket History #709: krb4 lifetime

From seph@MIT.EDU Tue Apr 6 12:35:03 1999
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id MAA26091 for <bugs@RT-11.MIT.EDU>; Tue, 6 Apr 1999 12:35:03 -0400
Received: from MARY-KAY-COMMANDOS.MIT.EDU by MIT.EDU with SMTP
id AA05455; Tue, 6 Apr 99 12:35:00 EDT
Received: by mary-kay-commandos (8.8.8+Sun/4.7) id MAA27724; Tue, 6 Apr 1999 12:35:01 -0400 (EDT)
Message-Id: <199904061635.MAA27724@mary-kay-commandos>
Date: Tue, 6 Apr 1999 12:35:01 -0400 (EDT)
From: Joseph Sokol-Margolis <seph@MIT.EDU>
To: krb5-bugs@MIT.EDU
Subject: krb4 lifetime

oops, mailed this to the wrong kerberos-bugs list. you might want to
usurp kerberos-bugs and bug-kerberos

------- Forwarded transaction
Subject: an kinit oddity
To: bugs@MIT.EDU, kerberos-bugs@MIT.EDU
Date: Tue, 06 Apr 1999 02:32:01 EDT
From: Joseph Sokol-Margolis <seph@MIT.EDU>

so, I noticed that when I kinit, for a lengthened ticket (-l1800m) I
get tickets in the future. then I aklog, and I get afs tickets with
the same expiration date.

However, if I kinit with the kinit in the krb5 locker, then use
krb524init (also from the krb5 locker, though I noticed this with the
athena one as well) to get krb4 tickets, then aklog, my afs tokens
expire in 10 hours (as opposed to 20 hours) this seems rather broken.

I don't know enough to track down any more of this bug. I asked about
it on -c sipb last night, and marc said "oh, I know the bug. the
ticket lifetime in the encrypted part of the ticket is wrong."

I wrote a short script to test this, it just runs the various
commands, and dumps klist output somewhere. it and klist output from a
couple of athena platforms is in /mit/seph/Public/krb-aklog.bug/

seph
--[16792]--

------- End forwarded transaction


From: Sam Hartman <hartmans@MIT.EDU>
To: seph@MIT.EDU, krb5-bugs@MIT.EDU
Cc: Subject: krb5-libs/709: lifetime handling
Date: Thu, 15 Apr 1999 18:20:04 -0400 (EDT)

OK, there are multiple problems The basic problem here is that half
the time we use the CMU lifetime algorithm and the rest of the time we
use the MIT algorithm.

In the cnv_tkt_skey.c, if the if we overflow 127*5 minutes, we use the
CMU algorithm to set the lifetime in the ticket.

In both kerberos_v4.c in the KDC and in conv_creds.c, we use the MIT
algorithm of just 255 five-minute blocks. We should settle on one
algorithm and use it everywhere.

State-Changed-From-To: open-analyzed
State-Changed-By: tlyu
State-Changed-When: Wed Feb 7 19:33:35 2001
State-Changed-Why:

long lifetime support on trunk