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

[denis bider <ietf-ssh3%denisbider.com@localhost>]

Excellent! I think this will work.

I have updated the draft to reflect this:

https://tools.ietf.org/html/draft-ssh-ext-info-04

I have shortened it much by removing the discussion section, which is now superfluous because it has been discussed.

I have kept the following section. I'm not sure if you currently implement this. I think it's important for the client to tolerate a secondary EXT_INFO just before USERAUTH_SUCCESS, so that servers can advertise additional extensions after the client has been authenticated.


2.4.  Server's Secondary SSH_MSG_EXT_INFO

  If the client sent "ext-info-c", the server MAY send, but is not
  obligated to, send an SSH_MSG_EXT_INFO message immediately before
  SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send
  this message whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS.

  This allows a server to reveal support for additional extensions that
  it was unwilling to reveal to an unauthenticated client. If a server
  sends a subsequent SSH_MSG_EXT_INFO, this replaces any previous ones,
  and both the client and the server re-evaluate extensions in effect.
  The server's last EXT_INFO is matched against the client's original.


I have also renamed "no-handbrake" to "no-flow-control".

What do you think?



----- Original Message -----
From: Markus Friedl 
Sent: Thursday, December 3, 2015 03:32
To: denis bider 
Cc: Damien Miller ; ietf-ssh%netbsd.org@localhost 
Subject: 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.