Re: rekeying, host key verification, and gssapi

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

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

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

Re-authenticating the server is not as important as re-authenticating
the user.  Normally rekeying does not re-authenticate the user, but that
is what happens with GSS-API rekeying, and I think it's a fine thing
too, though it would be obnoxious to re-run normal userauth as part of
each rekeying event.

But I see the point about unsigned rekeying being potentially useful.

Cheers,

Nico

On Fri, May 16, 2003 at 07:08:43PM -0400, Joel N. Weber II wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> The current design of the ssh protocol makes the host key verification
> (whether by public key or by gssapi) and the DH exchange a single
> step.  That seems fine for the initial key exchange.
> 
> However, it can be a little bit unfortunate for rekeying, especially
> if the mechanism used for initial host key verification might not work
> at the time of rekeying.  It also makes rekeying more expensive, and
> some of the mail seems to suggest that some people have some concern
> about the cost of rekeying.
> 
> http://www.sxw.org.uk/computing/patches/openssh.html says ``Note that
> if you're using OpenSSH with GSSAPI support and your clients will only
> be performing GSSAPI authenticated connections and you can ensure that
> clients will have valid credentials when rekeying occurs, then you no
> longer need a host key for the version 2 protocol.''
> 
> If it is possible to do rekeying after GSSAPI credentials expire, that
> is something that many will find desireable.  (There might be some who
> would prefer to see their connections terminate as soon as their
> credentials expire, and that is also an appropriate option to offer.)
> The current status quo that expired credentials don't terminate
> connections unless you happen to need rekeying seems poorly thought
> out, however.
> 
> None of the justifications for rekeying I've seen (such as in the
> archives of this list in March and April of this year) mention any
> need to verify the identity of the server again, and furthurmore, if
> there were some need to do so, I would expect that the server would
> need to authenticate the client again, and the protocol does not
> appear to have any support for verifying the client again at the time
> of rekeying.
> 
> My understanding is that the key exchange is protected by the symmetric
> cipher during rekeying.
> 
> I think it would be appropriate to support the use of ``none'' as the
> public key algorithm during rekeying, using key exchange methods that
> normally do get used with public keys.  The way this would be defined
> is that rather than sending a signature, a zero-length block of data
> would be sent by the protocol.  Clients which do not have any desire
> to recheck the server's host key, whether because of concerns about
> expired GSSAPI credentials, or in order to reduce the overhead of
> rekeying, could prefer the use of the ``none'' host key algorithm, and
> the use of a non-GSSAPI key exchange method.  (This would define
> ``none'' somewhat differently from how
> http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-06.txt
> defines it.)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.0 (NetBSD)
> 
> iD8DBQE+xW90NIJPyVx4GhgRAgbrAKCJVTgoAlAa8Vi7/TFf1GwnUsHPzACguiTX
> wKsOB9PzKI5ojybjP/j5ILs=
> =ERvB
> -----END PGP SIGNATURE-----
>