Re: rekeying, host key verification, and gssapi

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Sat, May 17, 2003 at 06:43:05PM -0400, Joel N. Weber II wrote:
> -----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.

Keep in mind that with the GSS-API (v2, update 1) re-delegating creds
always requires establishing a new context.

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

The client can always force rekeying with GSS-API to forward creds if
and when it wants to.  The client could easily check on its credentials
around and after the time of their expiration and rekey as soon as fresh
creds appear to be available.

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

Depends on the implementation.  But I think implementors generally know
about locking :)

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

Dunno - 'twould be a nice feature though (should the server stop your
processes too?)

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

It sure is different; some implementations might cache users' longterm
keys and keep refreshing their creds as long as the user is logged in on
the console, say (I believe on implementation of Kerberos does this), so
that the user effectively always has creds as long as she stays logged
in on console somewhere and is not terminated or locked out.

Cheers,

Nico
--