comments on section 3.1 of draft-ietf-secsh-architecture-13

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

I object to the text of section 3.1 of
draft-ietf-secsh-architecture-13, in that it claims that there are
only two possible models for verifying host keys.  This is wrong;
there is one ssh server I use regularly which I either log in to
using Kerberos to verify the server identity, or using an OpenPGP host
key to verify the server identity, neither of which is discussed in
the architecture document.

I would like to propose changing this existing text:

   Two different trust models can be used:
   o  The client has a local database that associates each host name (as
      typed by the user) with the corresponding public host key.  This
      method requires no centrally administered infrastructure, and no
      third-party coordination.  The downside is that the database of
      name-to-key associations may become burdensome to maintain.
   o  The host name-to-key association is certified by some trusted
      certification authority.  The client only knows the CA root key,
      and can verify the validity of all host keys certified by accepted
      CAs.

      The second alternative eases the maintenance problem, since
      ideally only a single CA key needs to be securely stored on the
      client.  On the other hand, each host key must be appropriately
      certified by a central authority before authorization is possible.
      Also, a lot of trust is placed on the central infrastructure.

replacing it with this text:

   Several different trust models can be used:
   o  The client has a local database that associates each host name (as
      typed by the user) with the corresponding public host key.  This
      method requires no centrally administered infrastructure, and no
      third-party coordination.  The downside is that the database of
      name-to-key associations may become burdensome to maintain.
   o  The host name-to-key association is certified by some trusted
      certification authority.

      This can be done using X.509, in which case the client only
      knows the CA root key, and can verify the validity of all host
      keys certified by accepted CAs.

      Another option is a symmetric cryptography based system such as
      Kerberos, in which case the client only knows a secret shared
      with the trusted certification authority, and can verify the
      validity of all host keys certified by the kdc.

      Using a trusted certification authority eases the maintenance
      problem, since ideally only a single CA key needs to be securely
      stored on the client.

      On the other hand, each host key must be appropriately certified
      by a central authority before authorization is possible.  Also,
      a lot of trust is placed on the central infrastructure.

      Yet another option is the use of OpenPGP format certificates.
      The model used with OpenPGP is that anyone can be a certifying
      authority.  This has the potential to reduce the amount of
      effort required for an appropriate trusted party to certify a
      host key, as well as greatly reducing the need to trust any
      single central authority.  However, exchanging signatures to
      build the web of trust, and maintaining the database of which
      level of trust is placed in which keys, can be a significant
      amount of effort.

   Implementations SHOULD support as many of these options as
   possible, because different users and different sites have
   different organizational structures, for which different methods of
   verifying the host identity are most convenient.

Also, I'd like to propose a paragraph added at the end:

   The documentation supplied with implementations SHOULD include a
   discussion of the problems of weak or nonexistent host
   verification, strongly encouraging the use of mechanisms that
   provide strong verification of host identity.