Re: Refreshing SSH forwarded/delegated credentials

["Douglas E. Engert" <deengert@anl.gov>]

Buck Huppmann wrote:

> 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?

Yes AFS has the same problem.
> 
> 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,

There was some work done with Globus, which included the GSSAPI extensions
that added a delegate at any time function. NCSA also did some ssh mods
that I believed used this feature, but not with Kerberos GSS.
Google for    gsi ssh ncsa   which will lead to:
http://grid.ncsa.uiuc.edu/ssh/

Do a google for  gss extensions   to find the Globus gss extensions drafts.

> 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

Its a problem, that nees to be addressed.




> 
> 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
> ________________________________________________
> Kerberos mailing list           Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444