On Thursday, March 31, 2005 06:42:57 PM -0500 Bill Sommerfeld <sommerfeld%sun.com@localhost> wrote:
On Thu, 2005-03-31 at 14:51, Jeffrey Hutzelman wrote:I'm adding the following text to the next version of the draft:<t>Therefore, when a new key for an already-known host is received via the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue strong warnings or abort the connection, provided the GSSAPI-based key exchange succeeds.</t>I think we need to provide additional guidance about hostkey update acceptance..
I don't think we do. I think that section 4.1 of the architecture document provides all the guidance we need in this area, which is mostly a matter for policy and configuration. Our existing security considerations RECOMMEND that clients issue a warning when the offered host key does not match that cached by the client, on the assumption that such a mismatch is an indication of a MitM attack. But that recommendation is based on the fact that in the base protocol, the host key offered by a server is completely unauthenticated. The purpose of the new text is to point out that host keys offered during GSSAPI-based key exchange are _not_ unauthenticated, and a strong warning is not indicated. It is still up to the implementation and local policy to determine the relative reliability of different sources of keys.
BTW, it is worth noting that most implementations do not have any mechanism for recording the source or confidence level of a cached key, nor do we require such a mechanism (or even that clients store keys).
-- Jeff