GSSAPI Key Exchange Patch for OpenSSH 4.7p1

[Matthew Andrews]

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