[Curdle] Comments on draft-ietf-curdle-ssh-ext-info-03
Daniel Migault <daniel.migault@ericsson.com> Sat, 25 March 2017 23:25 UTC
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC73128990 for <curdle@ietfa.amsl.com>; Sat, 25 Mar 2017 16:25:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LdJdpav8Y-V for <curdle@ietfa.amsl.com>; Sat, 25 Mar 2017 16:24:58 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BB512894E for <curdle@ietf.org>; Sat, 25 Mar 2017 16:24:58 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id y18so41090156itc.0 for <curdle@ietf.org>; Sat, 25 Mar 2017 16:24:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=tYNC/3ybaG9QzEu8yaa7Kl4b8zE1cRdAMER3IfFUHC8=; b=Zfs0VHusMmnL3wtYSpC5QHQjkfnEDjDVQ4arlNHNtQ9IbiJNcrKo0uvqFsRTVZ+r51 wV/KR5ea0PYO5KSXQOWJCiXq91IqeAHbbvBZbQpqIvl9n4nttzCXjoIZxuqg5GWiLw7O +SE3FNB+0+c2XUGuz21g2F5VUaLBKzaHuregVTeLSHIov4OaMSpm5PpEZU6DpKTIyZti TsSI6/7OwYGk9Kn/leqJpjgGK53BMa65O4r0GWHgodMFA6SBTM89GgERdL1KImyQFQLg y7bgDis540QW37hMuWEMrsDMSeumWN5ck4wYZ5iFkP99p2tuHDADYLwurhdyqPbHafsW QpDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=tYNC/3ybaG9QzEu8yaa7Kl4b8zE1cRdAMER3IfFUHC8=; b=swGeT68s1MjyT/5Un/AAmVqWPuCSdYhK+ZX+MTESp4y1HBcjaruAMohHOT8n7HebRQ CclajX0Zrtt5W8WCiCxI/3TGospB2bKCWckDZodmVPrnjX2LIuC/S2CTIyb3mxirXWa2 d5N/GM5FmF+WkWKY9fyXn/6ekqrkUB2b6AqQKsKknCEPWD7vLJE6czMoUK7bAb34CMj0 qa2h89hpZpiqjSNpaGxJ8TPFeBXqVTYjZpmgdDbulbPTM/PBEJgH6+xONQw6wCGsff7n xOSfnxcLLHsCSCM0h9lGCo9BpjB+FVdNlGGBDxlj5OyJ3FJBBEkz1/JtJ05se2VfJhLE FmKA==
X-Gm-Message-State: AFeK/H0spHxK7qkgcXw02G1Iu4rnjDSuMq1MCzA8XG+E+rDxe27yzin3PdXSvebMJV5+OEZrUmhNNpm0L95bzA==
X-Received: by 10.107.174.27 with SMTP id x27mr14352865ioe.35.1490484297312; Sat, 25 Mar 2017 16:24:57 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.35.213 with HTTP; Sat, 25 Mar 2017 16:24:56 -0700 (PDT)
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Sat, 25 Mar 2017 19:24:56 -0400
X-Google-Sender-Auth: GPQC2WPDCRMNLzmwzfVnZIL2wrw
Message-ID: <CADZyTk=YDNoDpzqA=n-cuq1WGAUa0kVz8gOrgg8B=zyaNXWGMg@mail.gmail.com>
To: curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="001a11449ffc15aff8054b966bbf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/udW4OLbhQ0kAHuw7KHeqKQOXzJU>
Subject: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info-03
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Mar 2017 23:25:03 -0000
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] Comments on draft-ietf-curdle-ssh-ext-in… Daniel Migault
- Re: [Curdle] Comments on draft-ietf-curdle-ssh-ex… denis bider (Bitvise)
- Re: [Curdle] Comments on draft-ietf-curdle-ssh-ex… Daniel Migault