rekeying, host key verification, and gssapi

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

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