[424] in Kerberos
Re: Misc Kerberos questions
daemon@TELECOM.MIT.EDU (Steve Miller)
Tue Jul 5 18:01:30 1988
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
File Server Mappings-
This is a very deep question, way beyond Kerberos per se. It is really
a question of what is the access control model. Most systems (Unix, VMS, etc.)
check access when a file is first opened, but once the file is opened, changing
the protection on the file has no effect on existing clients. Some systems
may check access on EVERY ACCESS.
Kerberos should be consistent with whatever access control model is in use.
For example, if the VICE model is that access is checked on every file open,
then if your Kerberos ticket expires, subsequent open requests should treat
it as just as if the access controls on the file had changed -- the client
can no longer authenticate as a user granted access. But just as in the local
case without Kerberos, once the file has been opened, access may continue.
Now, of course, one can change the existing model to cutoff access to open
files. But then one should logically cutoff access to open files if the
protection on the file is changed while the file is open, such that the
existing client would be excluded from the current access mode.
Short Tickets-
----------------
In the Kerberos design maximum ticket lifetimes were intentionally kept short
to be consistent with the Athena workstation environment and common security
practices. The main concern is that in an open workstation environment like
Athena, the tickets may be exposed on the workstations after the user has
left, either due to forgetting to clean up, or system idiosyncracies. Also
recall that the workstations have no hardware protection for keys or tickets.
So the longer the lifetime, the more exposed the system is for misuse. And,
designed as part of a security system, this is precisely what we were trying
to prevent. There is a second tier of arguments centered around crypto-attacks,
where the general principle is to restrict the amount of data encrypted with
any single key; Kerberos uses the same session key between parties for the
entire lifetime of the ticket. The crypto threat is less important in the
university environment.
Also note that Kerberos does not support any notion of revocating tickets.
Once issued, they are valid until they expire, unless the recipient makes
a conscious decision to reject a particular ticket based on some knowledge
learned from an external channel.
So, while you could extend the maximum lifetime allowed in the ticket, to
do so would weaken the protection environment Kerberos offers, and weaken
the damage control enforced by ticket lifetimes.
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.
(p.s. the size of encrypted fields within the ticket must be minimized to
minimize the performance cost of encryption.)
Steve
