[430] in Kerberos
re: should mappings expire?
daemon@TELECOM.MIT.EDU (Mark Lillibridge)
Wed Jul 6 13:33:05 1988
From: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU, athena-ws@ATHENA.MIT.EDU
Reply-To: chariot@ATHENA.MIT.EDU
> I don't feel that it is unreasonable to ask a researcher to login once a
> day in order to gain Kerberos' benefits. Alternatively, if the security
> of the application is not crucial, don't use Kerberos for it. Nobody
> claimed that security is free.
(from Steve)
Security if used for filesystem authentication, is not optional.
If Athena decides that all filesystem accesses must be authenticated
(this is the current policy), then the researcher must keep himself
authenticated in order to read or write any of his files. Very few
applications will work without some form of file storage. Hence,
security becomes mandatory to every application, not just some. The
choice of whether they want the security at the price of having to log
in once a day has been taken out of the hands of the users.
The way I see it (correct me here if I am wrong) is that
workstations of the Athena/Andrew type get used in two distinct ways.
One is as a public workstation being used by a user to read mail, write
a paper, or play a game. Total usage time is normally less than eight
hours, sometimes as much as 30 hours (we are talking about MIT/CMU
here...) but only with extreme rarity more than 30 hours. Very few
people are going to sit at a terminal with no food/drink for 30 hours
straight. For this usage, requiring the user to reauthenticate every n
hours, n>=8, is not too bad as he is physically present and can take any
needed corrective action.
It is still going to be a fairly big surprise to the user the
first time his tickets expire. This will be particularly bad if the
first time he discovers this is the day he is writting his final paper.
(i.e., spending 30 hours on the computer normally happens only just
before a major project of some sort is due) The Vice system solves this
problem for this group of people fairly well by simply upping the default
ticket lifetime to 25 hours, ensuring that very few students will
encounter expiration at all. The few that do probably fall into the
second class.
The second type is the private workstation in someone's office
or in an area of a lab all of whom's reasearchers trust each other. In
this situation, it is reasonable for someone to want to run a data
collection job while he's on vacation. 72 hours or more is perfectly
reasonable for a private workstation. (i.e., batch jobs over the
weekend) However, Vice does not currently provide (to my knowledge
anyways...) any real means of supporting researchers wishing to do this.
Ironically, the current athena setup does support this. Since in the
current athena setup tickets expire but not mappings, so long as no
services needing tickets need to be used (e.g., to read mail), batch
jobs on private workstations can run forever with no problems.
It would seem to me that the ability to create tickets with any
length and using 25-30 hours as the default ticket lifetime for normal
tickets would solve most of the problems abet at a loss of security.
What would be nice (hint, hint, kerberos developers) is a utility that
would allow you to throw away selective tickets from your ticket file.
This would allow me to kinit -lifetime 72, "attach" my home filesystem,
and then destroy all my tickets except my file server tickets. This
would greatly lower the security risk if I did lose my tickets. This is
basically what the current athena system lets you do now.
- Mark Lillibridge
