Refreshing SSH forwarded/delegated credentials - Kerberos

This is a discussion on Refreshing SSH forwarded/delegated credentials - Kerberos ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Refreshing SSH forwarded/delegated credentials

  1. Refreshing SSH forwarded/delegated credentials

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


  2. Re: Refreshing SSH forwarded/delegated credentials

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

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Refreshing SSH forwarded/delegated credentials



    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
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: Refreshing SSH forwarded/delegated credentials

    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.

    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.

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: Refreshing SSH forwarded/delegated credentials

    Do a kinit -R on the remote system. (You did forward the cred's as
    renewable, right?)

    Appropriate complexities if AFS involved (Heimdal kinit -afslog -R for
    example).

    On Jun 6, 2005, at 8:42 AM, Douglas E. Engert wrote:

    >> anybody know if somebody's working on the issue of how to refresh
    >> cred-
    >> entials forwarded/delegated to a an SSH session?

    ------------------------------------------------------------------------
    ----
    The opinions expressed in this message are mine,
    not those of Caltech, JPL, NASA, or the US Government.
    Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread