hilary@SNLL-ARPAGW.LLNL.GOV (Hilary Jones) (03/03/91)
I have a concern about one of the premises of Kerberos, and that is that storing a ticket on a workstation is somehow more secure than storing a file containing the user's password. It seems to me that the ticket is nothing more than a glorified password, and that this will become even more apparent if longer-lived passwords become the norm. We have told our users not to put passwords in their files, but now we are saying it's okay as long as the "password" is called a "ticket" and is complicated enough that it's hard to copy. It seems to me that the issue of storing tickets hasn't been dealt with very well in Kerberos as it stands now. I would feel a lot more comfortable about this if the ticket were stored in kernel memory, and if there were a positive assurance that it would would be destroyed when the user's last process exited. I wouldn't want the ticket to be destroyed immediately when the user logged out, since s/he might have several windows open, or be running a batch job that would have to continue to run after s/he logged out. Will tickets be stored in kernel memory in version 5? Or is some other mechanism being planned?
jis@MIT.EDU (Jeffrey I. Schiller) (03/03/91)
Whether or not tickets are stored in the Kernel or in a file is not a function of Kerberos, but of the system platforms that run Kerberos. V5 Kerberos provides a ticket cache abstraction which by default stores tickets in a file (because that is the only "portable" thing we can do). However if your system has the appropriate functions to store tickets in the kernel, it should not be hard to implement a ticket cache abstraction that uses it. From: hilary@snll-arpagw.llnl.gov (Hilary Jones) Subject: Storing tickets safely I have a concern about one of the premises of Kerberos, and that is that storing a ticket on a workstation is somehow more secure than storing a file containing the user's password. It seems to me that the ticket is nothing more than a glorified password, and that this will become even more apparent if longer-lived passwords become the norm. ... It *is* more secure to only store the ticket rather then the password. Tickets have a definite, known lifetime. How long that lifetime should be is a trade-off between security and convenience. If a ticket is compromised, the duration of the compromise is bounded. I will also point out that normal (many hour duration) tickets are *not* valid for *password* change requests. This means that compromised tickets cannot be used to change a user's password. Passwords on the other hand have an infinite or at the very least an indeterminate lifetime. A password is valid until it is changed by explicit action (some systems age passwords, but that is another situation). It is therefore more important to protect them better (ie. not store them on the workstation). From a practical point of view this means that if my tickets are stored on a workstation, tomorrow morning I *know* that my account is "safe" (hanky panky may have already happened, but no future hanky panky can happen). If my password was stored on the workstation, I don't *know* that it wasn't compromised. It may well have been stolen, but the thief may not take advantage of it for days. Of course if I am paranoid I could change it (and people with reason to be paranoid should in general change their password often) but that isn't the point. -Jeff
hilary@SNLL-ARPAGW.LLNL.GOV (Hilary Jones) (03/04/91)
>Whether or not tickets are stored in the Kernel or in a file is not a >function of Kerberos, but of the system platforms that run Kerberos.... >However [...] it should not be hard to implement a ticket cache >abstraction that uses it. I was hoping that the next release of Kerberos would in fact have some form of ticket caching that didn't depend on the file system. Perhaps some sort of shepherd process so that Kernel mods wouldn't have to be made. Without this, I still think the ticket is just a glorified password. I will admit I am being the gadfly here, but this is the one part of Kerberos that I haven't completely bought off on. Besides, if it's easy to implement a ticket cache, it should be trivial to implement a plaintext password cache and do away with Kerberos altogether. (I realize that Kerberos solves other security problems, so I am not being serious, just argumentative :) >It *is* more secure to only store the ticket rather then the password. Yes, but not a whole lot more secure. And if you allow infinitely long lived tickets, then the difference goes away completely. Admittedly my users shouldn't ask for long-lived passwords, and I should enforce that. But then one of the biggest advantages of Kerberos goes away for my users. Namely, they won't be able to run batch jobs that may take many days to run before needing a password. >...point out that normal (many hour duration) tickets are *not* valid for >*password* change requests. Yes, but a ticket thief isn't really likely to change my password. I will notice the problem, so he risks exposure while gaining almost nothing, beyond annoying me. [Come to think of it....] So the issue isn't whether the password is in plaintext or in an encrypted form like a ticket; rather, it's whether a thief can use the information without additional information. Of course all of this is something of a pointless argument; the spy is going to take over my workstation and gather my password as I type it, and I am helpless to prevent that. But I was hoping to make his job as difficult as possible. In particular, I was hoping that the protection would be better than the protection one gives to a file containing a password spelled out in plain text. However, as Kerberos is currently configured, that is not the case.
qjb@ATHENA.MIT.EDU (03/04/91)
Kerberos version V does indeed have support for arbitrary ticket
caching mechanisms. The terminology has been changed to
"credentials cache" since this is really what the ticket file
is. Kerberos V supports arbitrary interface to this cache.
There is a structure of functions (sort of like the way X
toolkit works). You need to implement certain routines
according to specification, and then the library will take care
of the rest. (I'm glossing over the details, of course.) If
you wanted to write a kernel interface for credentials caching,
you could do so without having to otherwise modify any part of
the kerberos code. There is a similar mechanism for srvtabs so
that, for example, you could have servers' keys stored in the
kernel. If necessary, you could get this by requiring that an
operator be present to type passwords at boot time.
Even in Kerberos there is some support for something better than
the filesystem. Shared memory ticket files are implemented and
should work on some systems that support shared memory. I know
that this code works under Ultrix. I know that we have gotten
the code to work on a PS/2 running AIX, but I doubt that we sent
any patches to the kerberos list if patches were necessary.
This still doesn't stop someone from stealing your credentials,
but it makes the job considerably more difficult and provides a
bit of added safety for clients with diskless workstations
(though probably not as much as would be desired.)
I should give the disclaimer that my knowledge of Kerberos V is
based largely on design discussions that took place last summer.
Jay Berkenbilt
Project Athenajtkohl@MIT.EDU (John T Kohl) (03/04/91)
>I was hoping that the next release of Kerberos would in fact have some >form of ticket caching that didn't depend on the file system. If you are willing to code up such a beast when/after the beta-test is ready, we would probably be willing to include it in our distribution. We already have a commitment from elsewhere to do a shared-memory credentials cache implementation, but if you were interested in a different model, we would welcome help with it. >Admittedly my >users shouldn't ask for long-lived passwords, and I should enforce that. >But then one of the biggest advantages of Kerberos goes away for my users. >Namely, they won't be able to run batch jobs that may take many days to >run before needing a password. This is exactly the case that renewable tickets were intended for. The idea is that you get a ticket with both a "local" and a "global" expiration time. Before the "local" time arrives, you send the ticket to the KDC for revalidation, and it sends back a replacement with an adjusted "local" expiration time. If you discover a ticket theft, you can instruct the KDC to refuse to replace that ticket when a renewal is requested. John
hilary@SNLL-ARPAGW.LLNL.GOV (Hilary Jones) (03/05/91)
>We already have a commitment from elsewhere to do a shared-memory >credentials cache implementation, but if you were interested in a >different model, we would welcome help with it. OK, I will see what I can come up with. >If you discover a ticket theft, you can instruct the KDC to refuse to >replace that ticket when a renewal is requested. I gather from this that version 5 of Kerberos is no longer stateless. Is that correct? Otherwise, a renewable ticket isn't really any different that any other kind of ticket.
pato@APOLLO.COM (Joe Pato) (03/05/91)
>Whether or not tickets are stored in the Kernel or in a file is not a >function of Kerberos, but of the system platforms that run Kerberos.... >However [...] it should not be hard to implement a ticket cache >abstraction that uses it. I was hoping that the next release of Kerberos would in fact have some form of ticket caching that didn't depend on the file system. Perhaps some sort of shepherd process so that Kernel mods wouldn't have to be made. Without this, I still think the ticket is just a glorified password. I will admit I am being the gadfly here, but this is the one part of Kerberos that I haven't completely bought off on. The OSF DCE security component (which uses Kerberos V5) includes a kernel ticket cache. The kernel ticket cache is installed with the AFS client file system component of the DCE - a component that already requires kernel modifications. -- Joe Pato Cooperative Computing Division Hewlett-Packard Company pato@apollo.hp.com -------
tytso@ATHENA.MIT.EDU (Theodore Ts'o) (03/05/91)
Date: Sun, 3 Mar 91 16:22:28 -0800 From: hilary@snll-arpagw.llnl.gov (Hilary Jones) I was hoping that the next release of Kerberos would in fact have some form of ticket caching that didn't depend on the file system. Perhaps some sort of shepherd process so that Kernel mods wouldn't have to be made. Without this, I still think the ticket is just a glorified password. I will admit I am being the gadfly here, but this is the one part of Kerberos that I haven't completely bought off on. Well... no. It's not like your password in that 1) you can't use a ticket to change your password, 2) you can't use a ticket file on another workstation without at least some amount of work, and 3) as shipped, Kerberos V4's maximum ticket lifetime is 21 hours. Kerberos V5 will have longer-lived tickets, but it also has provisions for renewable tickets. In Kerberos V4, you still can have batch jobs that may take many days to run --- you just need to modify the programs to Kerberos authenticate with whatever services they need to at the beginning of the batch run. As long as you can maintain some sort of association (i.e., TCP connection) with the server, and you're not afraid that someone will be able to hijack the association, you'll be fine. So there are some ways to make life more convenient, but in the long-run you always have a trade-off between security and convenience. Also note that if a ticket thief has broken root on your workstation, there really isn't that much difference between grabbing the file out of /tmp and grabbing it out of /dev/mem. One's only just a little bit more difficult that the other. Also, as you have yourself pointed out, a ticket thief who has broken root will probably just replace /bin/login with one that logs passwords and then forwards everything else along to the real login program. - Ted