Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt)

[Tomi Salo <ttsalo%ssh.com@localhost>]

Jeffrey Hutzelman writes:
 > Hm; this is an interesting problem.  I think the current theory is that
 > the host sends you its key along with all the signatures.  But if it has
 > to select which key to send you on the basis of what CA's you'll accept,
 > then it won't work.  There's also an identity problem here, in that a
 > host may need to decide which key and certs to send you based on what
 > identity you think it has.  TLS has this problem today...

   It's an interesting problem, and a real one. There may not be many
   reasons for a host to have multiple plain DSA or RSA keys, but with
   certificates (X.509), there is a real need for one server to have 
   multiple certificates. For example, the server might be used by
   several groups of clients, each group trusting its' own CA. Right
   now, the server can't advertise multiple host keys of the same type
   and the client can't select among multiple host keys (of the same 
   type), even if it retried the connection after having the key
   exchange fail because of receiving a 'wrong' hostkey.

   Of Joel's ideas for fixing this...:

   Putting the hostkeys into the hostkey algorithm list as
   algorithm@name pairs might be a partial solution. The client would
   at least be able to iterate through the list of keys, even if it
   did have to start a new connection for each try. 

   Negotiating the CA by having the client send a list of trusted
   CAs and the server the list of available CAs could also work,
   but different host key algorithms might have completely different
   lists, so each party would have to send a separate list for each
   host key algorithm. 

-- 
Tomi T. Salo <ttsalo%ssh.com@localhost>, SSH Communications Security Corp