-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hmmm.... The cascading credentials code sounds interesting, but raises the practical question of how does one deal with derived credentials. For example some sites configure the pam_session code to use delegated krb5 credentials to acquire additional credentials such as afs tokens, or x509 certificates. Since there would be no new session created, these derived credentials would not get refreshed. I think you'd need some way to hook site specific actions into the refresh activity, and of course that raises the hairy problem whether this refresh activity occurs in the same process, or one of it's descendants where the pam_session was established.
In any case I'm interested in the feature, but am trying to think of what other features are needed to take full advantage of it in a number of common environments. - -Matt Andrews Nicolas Williams wrote: | On Fri, Sep 28, 2007 at 04:26:14PM -0500, Douglas E. Engert wrote: |> Sounds interesting. And yes, I would be interested in |> the cascading credentials delegation code. Does the |> delegation code depend on the key exchange code? | | Protocol-wise, yes, it does. | | There's two ways to use the GSS-API in SSHv2: | | - userauth only, but this happens once at the start of the session, so | you can't delegate credentials after that | | - key exchange (and optionally userauth), which can be done again and | again over the lifetime of the session | | Nico -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHyMVcpLF3UzlwZVgRAutsAKD7a33FKqROnIzPzXP5hbO6CqXkzgCfezdH G+Fzx1/0z8OwPEgU2WNY+gc= =gfd7 -----END PGP SIGNATURE----- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
