Re: rekeying, host key verification, and gssapi

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> One very nice side effect of rekeying with GSS-API keyex is that it
> allows your client to automatically re-delegate new GSS-API credentials.

You're right, and I hadn't realized that, but being able to redelegate
credentials is certainly a feature the protocol ought to support.

Perhaps the correct semantic is for rekeying to redo GSSAPI keyex iff
the credentials currently available are unexpired, don't expire for at
least 10 minutes (to allow enough time for clock skew and for keyex to
take whatever real time it actually takes, since if GSSAPI keyex fails
I believe your session immediately dies), and are different from the
credentials that were used last time GSSAPI keyex happened, and
otherwise do rekeying that does not do any verification.

I do wonder if that leaves a race condition where if I run kinit at
the exact same time ssh recieves an update of the clock in the status
line from my emacs running on a remote system, causing automatic
rekeying to happen, if it's possible for a gssapi call to fail as a
result of trying to use credentials that are changing while the keyex
is happening.

> With Kerberos this means that when you tickets are close to expiration,
> you re-kinit at your console and the let rekeying re-forward your
> tickets.

Or, the way I tend to use kerberos tickets for AFS access, it would
mean that after my tickets expire, I notice that my remote logins to
machines that use AFS no longer have access to my homedir, and I
rekinit on the console and manually force rekeying to push the tickets.

> I do think that there should be an option to force GSS-API rekeying
> after GSS-API context expiration.

Can this be done in such a way that the session gets stuck in the
rekeying state where all data is queued until rekeying is successful?
(Otherwise, I'm not sure that it would be meaningfully different from
an option to just close the connection if the gssapi credentials ever
are allowed to expire without being renewed.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (NetBSD)

iD8DBQE+xrqvNIJPyVx4GhgRAr7zAJ9FgMHH41IpHIyzoH7m52AcD/3JXACdGBuL
goaYfw+VC9467rRiwkAjujo=
=jwFs
-----END PGP SIGNATURE-----