[426] in Kerberos
Re: Misc Kerberos questions
daemon@TELECOM.MIT.EDU (Mike Kazar)
Tue Jul 5 21:37:05 1988
From: Mike Kazar <kazar+@ANDREW.CMU.EDU>
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
In-Reply-To: <8807052151.AA17136@decwrl.dec.com>
The problem with short ticket lifetimes is that our researchers *do* find it
unreasonable to login (more than) once a day to keep their computation running.
And they've told us so. They like to start long batch jobs and walk away,
often for a weekend. Most of them do things like setup cron jobs to
re-authenticate themselves periodically so that they can store their data back
to the file servers.
When they make some mistake in setting up these re-authentication jobs, they do
not blame themselves for their lost efforts, they blame us. And to a certain
extent, they're right. They have physically secure machines and are not really
concerned with a cryptographic attack on their tickets. A ticket expiring in
O(72) hours is exactly the level of security they want.
While I realize that ticket lengths must be minimized to keep encryption costs
down, I think the expiration field was trimmed down just a bit too much in the
original design. An extra byte encrypted in a 60 byte or so ticket shouldn't
really be noticible.
