Extension Negotiation in Secure Shell (SSH)
draft-ietf-curdle-ssh-ext-info-12
The information below is for an old version of the document | |||
---|---|---|---|
Document | Type | Active Internet-Draft (curdle WG) | |
Author | denis bider | ||
Last updated | 2017-08-29 (latest revision 2017-08-22) | ||
Replaces | draft-ssh-ext-info | ||
Stream | IETF | ||
Intended RFC status | Proposed Standard | ||
Formats | pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Daniel Migault | ||
Shepherd write-up | Show (last changed 2017-06-01) | ||
IESG | IESG state | IESG Evaluation | |
Consensus Boilerplate | Yes | ||
Telechat date |
Needs a YES. Needs 7 more YES or NO OBJECTION positions to pass. |
||
Responsible AD | Eric Rescorla | ||
Send notices to | Daniel Migault <daniel.migault@ericsson.com> | ||
IANA | IANA review state | IANA OK - Actions Needed |
Internet-Draft D. Bider Updates: 4252, 4253, 4254 (if approved) Bitvise Limited Intended status: Standards Track August 22, 2017 Expires: February 22, 2018 Extension Negotiation in Secure Shell (SSH) draft-ietf-curdle-ssh-ext-info-12.txt Abstract This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. Status This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bider [Page 1] Internet-Draft Extension Negotiation in SSH August 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 public key algorithms a server accepts, to avoid authentication penalties and trial-and-error. This memo updates RFC 4252, RFC 4253, and RFC 4254. 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]. 1.2. Wire Encoding Terminology The wire encoding types in this document - "byte", "uint32", "string", "boolean", "name-list" - have meanings as described in [RFC4251]. 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 these names will not produce a match, and therefore not affect the algorithm chosen in key exchange algorithm negotiation. The inclusion of textual indicator names is intended to provide a clue for implementers to discover this mechanism. Bider [Page 2] Internet-Draft Extension Negotiation in SSH August 2017 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. A server only needs to send "ext-info-s" if it intends to process SSH_MSG_EXT_INFO from the client. A client only needs to send "ext-info-c" if it plans to process SSH_MSG_EXT_INFO from the server.Show full document text