Re: Feedback on draft-ssh-ext-info-00

Here is what I've implemented for OpenSSH:


3.  Extension Negotiation Mechanism

3.1.  Signaling of Extension Negotiation in KEXINIT

  Applications implementing this mechanism MUST add to the field
  "kex_algorithms", in their KEXINIT packet sent for the first key
  exchange, one of the following indicator names:

  - When acting as server: "ext-info-s"
  - When acting as client: "ext-info-c"

  The indicator name is added without quotes, and MAY be added at any
  position in the name-list, subject to proper separation from other
  names as per name-list conventions.

  The names are added to the "kex_algorithms" field because this is one
  of two name-list fields in KEXINIT that do not have a separate copy
  for each data direction.

  The indicator names inserted by the client and server are different to
  ensure that these names will not produce a match, and will be neutral
  with respect to key exchange algorithm negotiation.

  The inclusion of textual indicator names is intended to provide a clue
  for implementers to discover this mechanism.

3.2.  Mechanism Enabling Criteria

  If a client or server offers "ext-info-c" or "ext-info-s"
  respectively, then it must be prepared to accept a SSH_MSG_EXT_INFO
  message from the peer.

  Thus a server only needs to send "ext-info-s" if it intends to
  process SSH_MSG_EXT_INFO from the client.

  If a server receives an "ext-info-c", then it can send a
  SSH_MSG_EXT_INFO message, but it's not required to do so.

  If a SSH_MSG_EXT_INFO message is sent, then it MUST be the first
  message after the initial SSH_MSG_NEWKEYS.

  This way a server will send the SSH_MSG_EXT_INFO before sending
  a possible SERVICE_ACCEPT message.

  Implementations MUST NOT send an incorrect indicator name for their
  role. Implementations MAY disconnect if the counter-party does so.
  If an indicator name ("ext-info-c" or "ext-info-s") ends up being
  negotiated as a key exchange method, the parties MUST disconnect.

3.3.  Indicating Extensions

  A party that received the "ext-info-c" or "ext-info-s" indicator
  can send the the following message:

    byte       SSH_MSG_EXT_INFO (value 7)
    uint32     nr-extensions
    repeat "nr-extensions" times:
      string   extension-name
      string   extension-value

  This message is sent without delay, and immediately after
  SSH_MSG_NEWKEYS.

3.4.  Interpretation of Extension Names and Values

  Each extension is identified by its extension-name, and defines the
  conditions under which the extension is considered to be in effect.
  Applications MUST ignore unrecognized extension-names.

  Extension-value fields are interpreted as defined by their respective
  extension. An extension-value field MAY be an empty string if so
  permitted by the extension. Applications that do not implement
  or recognize a particular extension MUST ignore the associated
  extension-value field, regardless of its size or content.

  The cumulative size of an SSH_MSG_EXT_INFO message is limited only by
  the maximum packet length that an implementation may apply in
  accordance with [RFC4253]. Implementations MUST accept well-formed
  SSH_MSG_EXT_INFO messages up to the maximum packet length they accept.

4. Initially Defined Extensions

4.1. "server-sig-algs"

  This extension is sent with the following extension name and value:

    string      "server-sig-algs"
    name-list   signature-algorithms-accepted

  Note that the name-list type is a strict subset of the string type,
  and is thus permissible as an extension-value.

  This extension is sent by the server only, and contains a list of
  signature algorithms that the server is able to process as part of a
  "publickey" authentication request.

  A client that wishes to proceed with public key authentication MAY
  wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey"
  authentication request with an appropriate signature algorithm, rather
  than resorting to trial and error.

  Servers that implement public key authentication SHOULD implement this
  extension.

  If a server does not send this extension, a client SHALL NOT make any
  assumptions about the server's signature algorithm support, and MAY
  proceed with authentication request trial and error.