Refreshing SSH forwarded/delegated credentials

[Buck Huppmann <buckh@pobox.com>]

hello. sorry to cross-post, but i at least left out openssh-unix-dev@
this time around

anybody know if somebody's working on the issue of how to refresh cred-
entials forwarded/delegated to a an SSH session? e.g., if the server
is using RPCSEC_GSS-flavored NFS and your forwarded (krb5) credentials
and those credentials expire, that tends to cripple the remote login
session, no? same sorta thing with AFS, yes? are you just supposed to
use (Heimdal's) kf/kfd facility?

Google produces a few hits that seem to have to do with GSSAPI dele-
gation-refreshing some work of Douglas Engert on the Globus project,
it seems, but they don't seem to lead to any patches or discussion of
implementation. and i guess the IETF Kitten working group hasn't even
standardized a GSSAPI mechanism for adding delegated credentials to a
context, so the question of refreshing those credentials may not even
be on their radar (officially)

please stop reading and point me in the right direction if this is
all leading in the wrong direction

thanks

--buck

still there?

darn

then i guess i'm interested in stimulating implementation^Wdiscussion
about how to do it. lowering the level of abstraction to a meaningful
(for me) instance, for the moment, in the case of forwarded Kerberos
credentials that aren't themselves renewable, one could conceive of
any of the following:

1. a ``subsystem'' to which the connected SSH client could open up
   a session on a separate channel to send asynchronous credential
   updates for it to stick in the credential cache that the ssh-userauth
   exchange set up

2. a. an agent-type function in the SSH server and client so that the
      server end would sit on the writing side of a named pipe and hold
      the credentials in memory, so that krb5 clients could open the pipe
      up like a credentials cache file and the agent function could make
      a call back to the client-end agent if it determined the cache
      was stale; or,

   b. since that's particularly unlikely to work with an implementation
      that's expecting a real file it can read and write to (and might
      be even more improbably on non-UNIX systems), the agent might al-
      ternatively sit around and poll the file cache and take it upon
      itself to make a call back to the client end if the cache is
      ``about to'' expire, and so update the cache asynchronously

in any case, please clue me in. i realize there's a really heady ad-
mixture here of SSH along with Kerberos concerns, but i thought you all
might have the wider view that could maybe be focused on this problem
before i tried to prevail upon the SSH folks to try to figure out how
to implement it, if such be their will, b/c they don't suffer fools as
graciously as you all, i gather

thanks