[Curdle] Spencer Dawkins' Yes on draft-ietf-curdle-ssh-ext-info-12: (with COMMENT)
Spencer Dawkins <spencerdawkins.ietf@gmail.com> Tue, 12 September 2017 18:37 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: curdle@ietf.org
Delivered-To: curdle@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77522126B6D; Tue, 12 Sep 2017 11:37:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-curdle-ssh-ext-info@ietf.org, Daniel Migault <daniel.migault@ericsson.com>, curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.61.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150524144548.17894.106479337730195058.idtracker@ietfa.amsl.com>
Date: Tue, 12 Sep 2017 11:37:25 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/m6QffUR0t9oyXN2GwklhqFWEgcI>
Subject: [Curdle] Spencer Dawkins' Yes on draft-ietf-curdle-ssh-ext-info-12: (with COMMENT)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 12 Sep 2017 18:37:25 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-curdle-ssh-ext-info-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a readable document. It was a pleasure to review. I have a few comments, but "Spencer doesn't know much about SSH" might be a fine response for most of them ;-) In this text, 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. why would a party that doen't support this extention disconnect? I ask, because this looks like a MUST requirement that might apply to an implementation that doesn't support this extension. If that's normal SSH behavior, that's all I need to know :-) In this text, 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 NEWCOMPRESS 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. I THINK the point is that the client's SSH_MSG_NEWCOMPRESS is sent after SSH_MSG_USERAUTH_SUCCESS, before the client sends its first SSH message that's compressed using the newly negotiated compression algorithm, but "MUST send ... shortly after receiving SSH_MSG_USERAUTH_SUCCESS" doesn't help me figure that out - I'm mostly guessing, based on "the renegotiated compression algorithm is activated for the very next SSH message after the trigger message". But (1) if I got that wrong, it's at least unclear for TSV ADs, and (2) if I got that right, I'm not understanding what "shortly after receiving" the trigger message is saying - for example, I wondered if there's a timer involved, so that if a client doesn't have messages to send, it should still send SSH_MSG_NEWCOMPRESS, or the server will think something's wrong. In this text, This extension MAY be sent by the client as follows: string "elevation" string choice of: "y" | "n" | "d" A client sends "y" to indicate its preference that the session should be elevated; "n" to not be elevated; and "d" for the server to use its default behavior. The server MAY disconnect if it receives a different extension value. If a client does not send the "elevation" extension, the server SHOULD act as if "d" was sent. The terms "elevation" and "elevated" refer to an operating system mechanism where an administrator user's logon session is associated with two security contexts: one limited, and one with administrative rights. To "elevate" such a session is to activate the security context with full administrative rights. For more information about this mechanism on Windows, see also [WINADMIN] and [WINTOKEN]. 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 I would find this easier to understand, if the paragraph defining the terms was the first paragraph in the section, and then the description of the extension (which uses the term "elevation") followed. It's not bad, the way it is, but the reader has to read past the description to find out what the definition means. The security considerations are brief and refer to overarching security considerations, which I understand because this is an extension, but Security considerations are discussed throughout this document. This document updates the SSH protocol as defined in [RFC4251] and related documents. The security considerations of [RFC4251] apply. doesn't say anything about new security considerations to think about, when you add support for elevation, which seems like it would be a new attack surface, but I could imagine that adding elevation is the first step toward fewer SSH server implementations that always run with administrative rights just in case they ever need to use them, so the attack surface is getting smaller? ... And now I see that Mirja also asked about elevation, and your answer to her was pretty much what I had guessed. Maybe it's worth summarizing your answer in section 3.4.
- [Curdle] Spencer Dawkins' Yes on draft-ietf-curdl… Spencer Dawkins
- Re: [Curdle] Spencer Dawkins' Yes on draft-ietf-c… denis bider
- Re: [Curdle] Spencer Dawkins' Yes on draft-ietf-c… Spencer Dawkins at IETF