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

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 01 Apr 2005 15:30:47 -0500

On Thursday, March 31, 2005 06:42:57 PM -0500 Bill Sommerfeld 
<[email-masked]> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 11 Apr 2005 14:47:14 -0400

> I'm adding the following text to the next version of the draft:

Well, there's been some discussion on this issue, and I can't add any text 
without a consensus.  Bill?

-- Jeff

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 11 Apr 2005 20:49:08 -0400

> without a consensus.  Bill?

i'm not sure we have consensus but don't let that stop you from
resurrecting the draft.  wg last call is when consensus really matters
and I may be the outlyer here.

we have a conflict between:
 1) the true paranoids who exchange server keys or key hashes out of
band.
vs
 2) the average guy who "just says yes".

(and complicating #1 is the interaction with the SSH DNS fingerprint
document, because that *is* a way of securely exchanging the
fingerprints out of band, at least if dnssec is turned on...)

						- Bill

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Apr 2005 10:38:31 -0400

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

    Bill> (and complicating #1 is the interaction with the SSH DNS
    Bill> fingerprint document, because that *is* a way of securely
    Bill> exchanging the fingerprints out of band, at least if dnssec
    Bill> is turned on...)

I'd argue that gss-authenticated keys are out-of-band in the same
sense that the dns document is.  The signed key is exchanged by a
mechanism that does not depend on that key being a trust anchor for
the security of the exchange.  I.E. in one case my trust anchor is
some DNS related key, in another case it is a Kerberos key or some
other GSS credential.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 12 Apr 2005 23:12:53 -0400

On Tue, 2005-04-12 at 10:38, Sam Hartman wrote:
> other GSS credential

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

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

						- Bill

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Apr 2005 15:21:25 -0400

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> 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.