On Tue, Aug 15, 2000 at 04:25:33PM -0400, Jeffrey Altman wrote: > > Anyway, i think it'll be great to have telnet able to forward a later > > credential. That's one more thing I can cross off my "round tuit" > > list. I've been copying newer ccache's across with rsh, which is > > cumbersome, but at least I seldom need it. > > > > A really whizzo function would be the ability not to forward your > > TGT, but to trap accesses to your remote ccache and get your local > > host to do the TGS_REQ when needed and send back the needed cred. > > Some sort of IPC: ccache type could do this without violence to the > > applications. > > Matt Crawford > > > > This is the functionality that Nico has been arguing for as well. I > can do this if we implement some kind of memory or IPC based cache > that could be implemented within the telnetd. That would solve many > of our problems. > > If we did not need to hack /bin/login to manage the credentials cache > could we always use the default os /bin/login? Good question. You'd still need a cache and you'd still need to initialize it, and you'd still need to renew the "indirect TGT". :( IPC shared memory would be great for this. Though not too portable. And I still think that telnetd can cooperate with /bin/login and PAM_KRB5 to initialize the cache securely, and maybe even to update the cache later on. Of course, if telnetd is going to be updating the cache sometime after initializing it then you'd better be prepared to deal with some consequences, such as making sure the cache file is never replaced or never renamed and requiring that the login name be specified in the telnet protocol if Kerberos authentication is being done. I think we can probably agree on standard telnetd/login/PAM_KRB5 behaviours that will allow them to cooperate seamlessly. And we can make sure that cache files are never replaced and only edited in place. As for a new ccache type that uses the indirect TGT system that Matt Crawford and myself suggest, it's a different issue, though worth considering (maybe -- ultimately someone would have to code it). Also, let's not forget reneweable TGTs. If we're talking about telnetd updating ccaches when TGTs expire, we might as well talk about a daemon, much like the one on Solaris 8, that watches for ccached TGT expirations and warns users (or even renews them as needed if possible). Of course, automatic ticket renewal is arguably counter-productive, from a security point of view. No matter how it's achieved. But if that's what users want... > Jeffrey Altman * Sr.Software Designer > The Kermit Project * Columbia University > 612 West 115th St * New York, NY * 10025 * USA > http://www.kermit-project.org/ * kermit-support@kermit-project.org Nico --
