Re: Refreshing SSH forwarded/delegated credentials

[Buck Huppmann <buckh@pobox.com>]

On Sat, Jun 04, 2005 at 10:09:16PM +0100, sxw@inf.ed.ac.uk wrote:
> On Sat, 4 Jun 2005, Buck Huppmann wrote:
> 
> > anybody know if somebody's working on the issue of how to refresh cred-
> > entials forwarded/delegated to a an SSH session? 
> 
> I occasionally start thinking about it, but I haven't yet got as far as
> writing any code. There's a lot of dependencies here, and the use of 
> privsep within the OpenSSH code isn't going to make anything any easier.
> Nicolas Williams started the train of thought outlined below...
> 
> This plan will only work with key exchange (as opposed to 
> userauth). Short of designing new protocol pieces, I don't think that 
> there's any easy way of doing this through the userauth layer.
> If you're using GSSAPI seriously you're probably going to want keyexchange 
> anyway.
> 
> The idea is that the client forces a SSH session rekey when it sees the 
> credentials on its system being renewed. This rekeying will cause a new
> GSS context to be created between client and server, allowing the new
> credentials to be delegated to the server. The server then saves these 
> credentials out into the same credentials cache as it originally created 
> for the user.

not to dismiss all the below, but is there any way to get a new
set of credentials without reestablishing a GSS context? (as a
hack, perhaps even by creating a context with oneself?) if such
is the case, you could just have Something on the client open
a new channel to the server, request, say, a gssapi-key-dumper
subsystem session which will exec such a beast with the user's
privs and the KRB5CCNAME, and just send the credentials down the
pipe. (again, potentially carrying out a self-context-establish-
ment with the subsystem server using the older credentials it has
availble to it.) o/t/o/h, if that's beyond the scope of GSSAPI,
then maybe it'd be enough to hook up kf and kfd to an existing
SSH connection (maybe using the new ControlMaster functionality
in OpenSSH 3.9+, if that's what it's for) and, again, just get
enough help from the server to find out what credentials cache to
update (with due care not to clobber the ccache if it now has a
different set of initial credentials than the set you're receiv-
ing--or ones with a later expiration--etc.--etc. as for anything
else PAM may have done, well, that's for the -portable people to
flagellate themselves with, no? more charitably: if you sidestep
the issue of re-authentication, then it seems outside the scope)

thanks for at least validating the notion. maybe the discussion
should continue off this list, since the issue seems to be one
of working the functionality into OpenSSH rather than an issue
of protocol (ab-)use. i, of course, am not qualified to carry
it on

--buck

p.s.--and many thanks for getting the GSSAPI userauth mech into
OpenSSH. has done much around where i work to let us drop all
manner of ``hostbased trust'' and so this functionality is mostly
an offshoot of trying to take that to its logical conclusion

> 
> There are a number of complications:
>  *) You need to navigate your way through the privsep layer
>  *) What happens if the user has used 'kinit' to renew the credentials 
>     early, or to obtain a different set of credentails, but using a cache 
>     of the same name?
>  *) How can you renew any additional credentials that PAM has obtained 
>     for the user (AFS tokens, kx509 credentials &c.)?
>  *) Rekeying a ssh session with gss can be risky. If the rekeying fails
>     for any reason, then the server MUST terminate the session.
>  *) PAGs/keychains and privsep will _really_ complicate the above as the
>     process which receives the user's credentials probably won't be in
>     the same group as the login shell.
> 
> The other, broader issue, is of minimizing the size of the patch to 
> OpenSSH, so its still feasible to apply it each time. If the above could 
> be implemented in a low impact manner, then it would probably be doable...
> 
> Cheers,
> 
> Simon.
> 
>