Re: draft-ietf-secsh-gss-keyex and null host keys

[Sam Hartman <hartmans-ietf-ietf%mit.edu@localhost>]

>>>>> "Bill" == Bill Sommerfeld <sommerfeld%sun.com@localhost> writes:

    Bill> if there are multiple potential sources for a given host's
    Bill> key, they could disagree.

    Bill> at the very least we need to provide a clue to implementors
    Bill> for what to do in the event of a disagreement between
    Bill> allegedly-authoritative sources of information on the
    Bill> host-to-host-key binding.

I actually think this may be the best approach.  Describe the
tradeoffs and give one or two reasonable example implementation
strategies.



For example point out that if a key was actually verified by a user
from a trusted source like a printout then automatic replacement would
probably decrease security.  However it is desirable to allow
mechanisms like GSS to facilitate rekeying of machines especially
since that is very difficult in the base protocol.

One suggestion might be to have a warning noting that the key had
changed but had been verified by GSS.  The warning could suggest that
unless the user had knowledge otherwise, accepting the new key would
be reasonable.  The warning might be disabled for users whose key
management strategy never involved particularly trusted sources.  Or
perhaps the warning defaults to off and can be enabled.  Most of the
options in this space seem like reasonable implementation decisions.

I think the things I'm fairly sure you want are the ability to disable
GSS-based key replacement, the ability to do it automatically and the
ability to get a warning.  Beyond suggesting these alternatives and
explaining the tradeoffs I don't think we can do much.