Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info-03

Daniel:

> > Implementations MUST NOT send an incorrect indicator name
> > for their role. Implementations MAY disconnect if the
> > counter-party sends an incorrect indicator. If "ext-info-c"
> > or "ext-info-s" ends up being negotiated as a key exchange
> > method, the parties MUST disconnect.
>
> Shouldn't we have "Implementations MUST disconnect" ? At
> least we should maybe state that it MUST ignore the indication.

I try to avoid burdens that aren't strictly required, on the basis that it 
may cause implementers to ignore instructions when it matters.

There's a "MUST NOT send" here that makes the situation clear and 
unambiguous. "MAY disconnect" allows an implementation to police this. I 
didn't put in an "everyone MUST police this rule" because I don't see strong 
added value.

> > uint32     nr-extensions
> > repeat "nr-extensions" times:
> >   string   extension-name
> >   string   extension-value
>
> MGLT: maybe the different terms/parameters could be
> defined. I am assuming that an extenssion-name has
> a single extension-value. In other words,
> extension-name is repeated.

The tuple (extension-name, extension-value) is repeated. The inclusion of 
both fields in repetition is meant to be implied by their indent.

To make this clearer in case the indent is lost, I will be changing the 
instruction to:

  repeat the following 2 fields "nr-extensions" times:

> > 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.
>
> MGLT: Maybe that would be clearer to split the sentence in
> two parts so the "MAY" does not confuse the reader.

OK. I have tried to improve clarity by rewording this paragraph as follows:

"If the client sent "ext-info-c", the server MAY send zero, one, or two 
EXT_INFO messages. The first opportunity for the server's EXT_INFO is after 
the server's NEWKEYS, as above. The second opportunity is just before (*) 
SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send 
EXT_INFO at the second opportunity, whether or not it sent it at the first. 
A client that sent "ext-info-c" MUST accept a server's EXT_INFO at both 
opportunities, but MUST NOT require it."

> -- It is not clear to me why immediately is needed.

OK, I have changed "immediately before" to "just before" above.

The point is that the sequence of messages at the second EXT_INFO 
opportunity is either (USERAUTH_SUCCESS) or (EXT_INFO, USERAUTH_SUCCESS); 
but not e.g. (EXT_INFO, USERAUTH_FAILURE, more activity, USERAUTH_SUCCESS).

> > In general, if an extension requires both the client
> > and the server to include it
>
> MGLT: "In general" can be removed. I think the reader expects
> some additional text that shows cases where the order matters.

OK. Removed "In general".

> > Extension-value fields are interpreted as defined by their
> > respective extension. An extension-value field MAY be empty
> > 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.
>
> MGLT: Is the \0 the delimiter to skip the value ?

An SSH string is encoded as the tuple (word32 n, byte[n] content). Zero 
bytes are valid content.

An empty string would be encoded as \0\0\0\0. So \0\0\0\0 would be an empty 
extension-value.

If \0 appears in the string content of the extension-value, the meaning of 
that is extension-specific.

I think this does not have to be explicitly clarified because an SSH 
implementer would know how an SSH string is encoded; that it can contain 
null bytes; and that these have no special treatment.

> MGLT: Maybe a reference to the types used could be added.

OK. I have added a section like the following to both drafts:

"1.2.  Wire Encoding Terminology

"The wire encoding types in this document - "byte", "uint32", "string", 
"boolean", "name-list" - have meanings as described in [RFC4251]."

I have added a normative reference to RFC 4251 to both documents.

> > 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" request.
>
> MGLT: I think we should also specify the server behavior,
> which MUST ignore the extension and MAY disconnect.

Before addressing this - next comment about the same passage:

> MGLT: I might be wrong but if the client sends the list,
> it may be helpful for the server to narrow down its
> selection. In this case, it may look more as agreement.
> It may also be useful for the server to monitor the
> supported signatures requested by clients which could
> be helpful to understand when to deprecate authentication
> algorithms.

I like this idea.

Unfortunately though, the extension has already been implemented and 
deployed as server-sig-algs". For this suggestion to not be confusing, the 
client would have to send something like "client-sig-algs"; or perhaps, just 
"sig-algs".

Because the extension is already named, I have adopted the first one of the 
above two comments. I have added the following phrasing:

"If a client sends this extension, the server MAY ignore it, and MAY 
disconnect."

> > If a server does not send this extension, a client MUST
> > NOT make any assumptions about the server's signature
> > algorithm support, and MAY proceed with authentication
> > requests using trial and error.
>
> MGLT: Maybe some indication on penalties may be added here.

OK. I have added:

"Note that implementations are known to exist that apply authentication 
penalties if the client attempts to use an unexpected signature algorithm."

> > If both parties send this extension, but the name-lists
> > do not contain a common algorithm in either direction,
> > the parties MUST disconnect in the same way as if
> > negotiation failed as part of SSH_MSG_KEXINIT.
>
> MGLT: As this looks like a renegotiation, for which reason
> do we need to disconnect the session and not simply ignore
> the exchange.

Three responses:

- One pre-condition for renegotiation to fail is that at least one party 
fails to offer the "none" compression algorithm. In that case, this behavior 
is consistent with KEXINIT, where we could say "OK, if no compression can be 
agreed on, use none". But we don't, we disconnect.

- Protocol errors result in disconnect because they are an unexpected 
situation that guarantees there's an error somewhere. The "fail early" 
principle applies.

- Outside of this extension, SSH key re-exchange can be initiated with 
changed settings such that the parties no longer agree on algorithms. In 
this case also, there will be a disconnect.

Above policy is consistent with existing behaviors, rather than introducing 
a situation where failed renegotiation would mean disconnect in some cases, 
and "ignore" in others.

> > string  "no-flow-control"
> > string  choice of: "p" for preferred | "s" for supported
>
> MGLT: description of the parameters would be helpful.

OK. Added the following:

"A party SHOULD send "s" if it supports "no-flow-control", but does not 
prefer to enable it. A party SHOULD send "p" if it prefers to enable the 
extension if the other party supports it. Parties MAY disconnect if they 
receive a different extension value."

> > string      "elevation"
> > string      choice of: "y" | "n" | "d"
>
> MGLT: description of the parameters would be helpful.

The next following paragraph defines the values.

Perhaps I misunderstood, and the request is to define "string"? In this 
case, this may be addressed by the new section 1.2, which references RFC 
4251 that defines "string".

This was a number of comments, so if I missed anything, please let me know. 
:-)

denis

----- Original Message -----
From: Daniel Migault
Sent: Saturday, March 25, 2017 17:24
To: curdle
Subject: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info-03

Hi,

Thank you for moving that draft forward. Please see some comments on the 
draft.

Yours,
Daniel

Internet-Draft                                                  D. Bider
Updates: 4252, 4253, 4254 (if approved)                  Bitvise Limited
Intended status: Standards Track                          March 23, 2017
Expires: September 23, 2017

               Extension Negotiation in Secure Shell (SSH)
                  draft-ietf-curdle-ssh-ext-info-03.txt

Abstract

  This memo defines a mechanism for SSH clients and servers to exchange
  information about supported protocol extensions confidentially after
  completed key exchange.

Bider                                                           [Page 1]

Internet-Draft        Extension Negotiation in SSH            March 2017

1.  Overview and Rationale

  Secure Shell (SSH) is a common protocol for secure communication on
  the Internet. The original design of the SSH transport layer [RFC4253]
  lacks proper extension negotiation. Meanwhile, diverse implementations
  take steps to ensure that known message types contain no unrecognized
  information. This makes it difficult for implementations to signal
  capabilities and negotiate extensions without risking disconnection.

  This obstacle has been recognized in relationship with [SSH-RSA-SHA2],
  where the need arises for a client to discover signature algorithms a
  server accepts, to avoid authentication penalties and trial-and-error.

1.1.  Requirements Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].

2.  Extension Negotiation Mechanism

2.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.

2.2.  Enabling Criteria

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

Bider                                                           [Page 2]

Internet-Draft        Extension Negotiation in SSH            March 2017

  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", it MAY send an SSH_MSG_EXT_INFO
  message, but is not required to do so.

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

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

MGLT: Shouldn't we have "Implementations MUST disconnect" ? At least we 
should maybe state that it MUST ignore the indication.

2.3.  SSH_MSG_EXT_INFO Message

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

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

MGLT: maybe the different terms/parameters could be defined. I am assuming 
that an extenssion-name has a single extension-value. In other words, 
extension-name is repeated.

  This message is sent immediately after SSH_MSG_NEWKEYS, without delay.
  This allows a client to pipeline an authentication request after its
  SSH_MSG_SERVICE_REQUEST, even when this needs extension information.

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.

MGLT: Maybe that would be clearer to split the sentence in two parts so the 
"MAY" does not confuse the reader.

OLD:
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].
NEW:
  If the client sent "ext-info-c", the server MAY send, but is not
  obligated to send an SSH_MSG_EXT_INFO. If the server sends 
SSH_MSG_EXT_INFO message it MUST be placed immediately before (*)
  SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252].
  -- It is not clear to me why immediately is needed.

  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 initial one,
  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.

  (*) The message MUST be sent at this point for the following reasons:
  if it was sent earlier, it would not allow the server to withhold
  information until the client has authenticated; if it was sent later,
  a client that needs information from the second EXT_INFO immediately
  after successful authentication would have no way of reliably knowing
  whether there will be a second EXT_INFO or not.

Bider                                                           [Page 3]

Internet-Draft        Extension Negotiation in SSH            March 2017

2.5.  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.

  In general, if an extension requires both the client and the server
  to include it in order for the extension to take effect, the relative
  position of the extension-name in each EXT_INFO message is irrelevant.

MGLT: "In general" can be removed. I think the reader expects some 
additional text that shows cases where the order matters.

  Extension-value fields are interpreted as defined by their respective
  extension. An extension-value field MAY be empty 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.

MGLT: Is the \0 the delimiter to skip the value ?

  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.

3. Initially Defined Extensions

3.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.

MGLT: Maybe a reference to the types used could be added.

  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" request.

MGLT: I think we should also specify the server behavior, which MUST ignore 
the extension and MAY disconnect.

MGLT: I might be wrong but if the client sends the list, it may be helpful 
for the server to narrow down its selection. In this case, it may look more 
as agreement. It may also be useful for the server to monitor the supported 
signatures requested by clients which could be helpful to understand when to 
deprecate authentication algorithms.

  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 MUST NOT make any
  assumptions about the server's signature algorithm support, and MAY
  proceed with authentication requests using trial and error.

MGLT: Maybe some indication on penalties may be added here.

Bider                                                           [Page 4]

Internet-Draft        Extension Negotiation in SSH            March 2017

3.2.  "delay-compression"

  This extension MAY be sent by both parties as follows:

    string         "delay-compression"
    string:
      name-list    compression_algorithms_client_to_server
      name-list    compression_algorithms_server_to_client

  This extension allows the server and client to renegotiate compression
  algorithm support without having to conduct a key re-exchange, putting
  new algorithms into effect immediately upon successful authentication.

  This extension takes effect only if both parties send it. Name-lists
  MAY include any compression algorithm that could have been negotiated
  in SSH_MSG_KEXINIT, except algorithms that define their own delayed
  compression semantics. This means "zlib,none" is a valid algorithm
  list in this context; but "zlib@openssh.com" is not.

  If both parties send this extension, but the name-lists do not contain
  a common algorithm in either direction, the parties MUST disconnect in
  the same way as if negotiation failed as part of SSH_MSG_KEXINIT.

MGLT: As this looks like a renegotiation, for which reason do we need to 
disconnect the session and not simply ignore the exchange.

  If this extension takes effect, the renegotiated compression algorithm
  is activated for the very next SSH message after the trigger message:

  - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS.
  - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS.

  If this extension takes effect, the client MUST send the following
  message shortly after receiving SSH_MSG_USERAUTH_SUCCESS:

    byte       SSH_MSG_NEWCOMPRESS (value 8)

  The purpose of this message is to avoid a race condition where the
  server cannot reliably know whether a message sent by the client was
  sent before or after receiving the server's USERAUTH_SUCCESS.

  As with all extensions, the server MAY delay including this extension
  until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS.
  This allows the server to avoid advertising compression support until
  the client has been authenticated.

  If the parties re-negotiate compression using this extension in a
  session where compression is already enabled; and the re-negotiated
  algorithm is the same in one or both directions; then the internal
  compression state MUST be reset for each direction at the time the
  re-negotiated algorithm takes effect.

Bider                                                           [Page 5]

Internet-Draft        Extension Negotiation in SSH            March 2017

3.2.1.  Awkwardly Timed Key Re-Exchange

  A party that has signaled, or intends to signal, support for this
  extension in an SSH session, MUST NOT initiate key re-exchange in that
  session until either of the following occurs:

  - This extension was negotiated, and the party that's about to start
    key re-exchange already sent its trigger message for compression.

  - The party has sent (if server) or received (if client) the message
    SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated.

  If a party violates this rule, the other party MAY disconnect.

  In general, parties SHOULD NOT start key re-exchange before successful
  user authentication, but MAY tolerate it if not using this extension.

3.2.2.  Subsequent Re-Exchange

  In subsequent key re-exchanges that unambiguously begin after the
  compression trigger messages, the compression algorithms negotiated in
  re-exchange override the algorithms negotiated with this extension.

3.3.  "no-flow-control"

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

    string      "no-flow-control"
    string      choice of: "p" for preferred | "s" for supported

MGLT: description of the parameters would be helpful.

  To take effect, this extension MUST be:

  - Sent by both parties.
  - At least one party MUST have sent the value "p" (preferred).

  If this extension takes effect, the "initial window size" fields in
  SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined
  in [RFC4254], become meaningless. The values of these fields MUST be
  ignored, and a channel behaves as if all window sizes are infinite.
  Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST
  messages, and if received, such messages MUST be ignored.

  This extension is intended, but not limited to, use by file transfer
  applications that are only going to use one channel, and for which the
  flow control provided by SSH is an impediment, rather than a feature.

  Implementations MUST refuse to open more than one simultaneous channel
  when this extension is in effect. Nevertheless, server implementations
  SHOULD support clients opening more than one non-simultaneous channel.

Bider                                                           [Page 6]

Internet-Draft        Extension Negotiation in SSH            March 2017

3.4.  "elevation"

  This extension MAY be sent by the client as follows:

    string      "elevation"
    string      choice of: "y" | "n" | "d"

MGLT: description of the parameters would be helpful.

  A client sends "y" to indicate its preference that the session should
  be elevated (as used by Windows); "n" to not be elevated; and "d" for
  the server to use its default behavior. If a client does not send the
  "elevation" extension, the server SHOULD act as if "d" was sent.

  If a client has included this extension, then after authentication, a
  server that supports this extension SHOULD indicate to the client
  whether elevation was done by sending the following global request:

    byte        SSH_MSG_GLOBAL_REQUEST
    string      "elevation"
    boolean     want reply = false
    boolean     elevation performed

4.  IANA Considerations

4.1.  Additions to existing tables

  IANA is requested to insert the following entries into the table
  Message Numbers under Secure Shell (SSH) Protocol Parameters
  [RFC4250]:

    Value    Message ID             Reference
    7        SSH_MSG_EXT_INFO       [this document]
    8        SSH_MSG_NEWCOMPRESS    [this document]

  IANA is requested to insert the following entries into the table Key
  Exchange Method Names:

    Method Name     Reference          Note
    ext-info-s      [this document]    Section 2.2
    ext-info-c      [this document]    Section 2.2

4.2.  New table: Extension Names

  Also under Secure Shell (SSH) Protocol Parameters, IANA is requested
  to create a new table, Extension Names, with initial content:

    Extension Name       Reference          Note
    server-sig-algs      [this document]    Section 3.1
    delay-compression    [this document]    Section 3.2
    no-flow-control      [this document]    Section 3.3
    elevation            [this document]    Section 3.4

Bider                                                           [Page 7]

Internet-Draft        Extension Negotiation in SSH            March 2017

4.2.1.  Future Assignments to Extension Names

  Names in the Extension Names table MUST follow the Conventions for
  Names defined in [RFC4250], Section 4.6.1.

  Requests for assignments of new non-local names in the Extension Names
  table (i.e. names not including the '@' character) MUST be done
  through the IETF CONSENSUS method, as described in [RFC5226].

5.  References

5.1.  Normative References

  [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

  [RFC4250]   Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Assigned Numbers", RFC 4250, January 2006.

  [RFC4252]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, January 2006.

  [RFC4253]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006.

  [RFC4254]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Connection Protocol", RFC 4254, January 2006.

  [RFC5226]   Narten, T. and Alvestrand, H., "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

5.2.  Informative References

  [SSH-RSA-SHA2]
              Bider, D., "Use of RSA Keys with SHA-2 256 and 512 in
              Secure Shell (SSH)", draft-ietf-curdle-rsa-sha2-03.txt,
              February 2017, <https://tools.ietf.org/html/
              draft-ietf-curdle-rsa-sha2-03>.

Bider                                                           [Page 8]

Internet-Draft        Extension Negotiation in SSH            March 2017

Author's Address

  Denis Bider
  Bitvise Limited
  Suites 41/42, Victoria House
  26 Main Street
  GI

  Phone: +506 8315 6519
  EMail: ietf-ssh3@denisbider.com
  URI:   https://www.bitvise.com/

Acknowledgments

  Thanks to Markus Friedl and Damien Miller for comments and initial
  implementation. Thanks to Peter Gutmann and Roumen Petrov for review
  and feedback.

Bider                                                           [Page 9]

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle 