Subject: rekeying, host key verification, and gssapi

From: "Joel N. Weber II" <[email-masked]>
Date: Fri, 16 May 2003 19:08:43 -0400

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

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 17 May 2003 09:27:22 -0700

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
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.0 (NetBSD)
> 
> iD8DBQE+xW90NIJPyVx4GhgRAgbrAKCJVTgoAlAa8Vi7/TFf1GwnUsHPzACguiTX
> wKsOB9PzKI5ojybjP/j5ILs=
> =ERvB
> -----END PGP SIGNATURE-----
>

---

From: "Joel N. Weber II" <[email-masked]>
Date: Sat, 17 May 2003 18:43:05 -0400

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

> you re-kinit at your console and the let rekeying re-forward your

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.

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

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 17 May 2003 21:04:58 -0700

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

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

> result of trying to use credentials that are changing while the keyex

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

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

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