idnits 2.17.1 draft-ssh-ext-info-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 123 has weird spacing: '... string exte...' == Line 124 has weird spacing: '... string exte...' == Line 170 has weird spacing: '...me-list sign...' == Line 221 has weird spacing: '...me-list chan...' == Line 260 has weird spacing: '...me-list com...' == (1 more instance...) -- The document date (December 17, 2015) is 3053 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-03) exists of draft-rsa-dsa-sha2-256-02 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft D. Bider 3 Expires: June 17, 2016 Bitvise Limited 4 December 17, 2015 6 Extension Negotiation in Secure Shell (SSH) 7 draft-ssh-ext-info-05.txt 9 Abstract 11 This memo defines a mechanism for SSH clients and servers to exchange 12 information about supported protocol extensions confidentially after 13 completed key exchange. 15 Status 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Overview and Rationale 52 Secure Shell (SSH) is a common protocol for secure communication on 53 the Internet. The original design of the SSH transport layer [RFC4253] 54 lacks proper extension negotiation. Meanwhile, diverse implementations 55 take steps to ensure that known message types contain no unrecognized 56 information. This makes it difficult for implementations to signal 57 capabilities and negotiate extensions without risking disconnection. 59 This obstacle has been recognized in relationship with [SSH-RSA-SHA2], 60 where the need arises for a client to efficiently discover signature 61 algorithms a server accepts, to avoid round-trips of trial and error. 63 1.1. Requirements Terminology 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 2. Extension Negotiation Mechanism 71 2.1. Signaling of Extension Negotiation in KEXINIT 73 Applications implementing this mechanism MUST add to the field 74 "kex_algorithms", in their KEXINIT packet sent for the first key 75 exchange, one of the following indicator names: 77 - When acting as server: "ext-info-s" 78 - When acting as client: "ext-info-c" 80 The indicator name is added without quotes, and MAY be added at any 81 position in the name-list, subject to proper separation from other 82 names as per name-list conventions. 84 The names are added to the "kex_algorithms" field because this is one 85 of two name-list fields in KEXINIT that do not have a separate copy 86 for each data direction. 88 The indicator names inserted by the client and server are different to 89 ensure that these names will not produce a match, and will be neutral 90 with respect to key exchange algorithm negotiation. 92 The inclusion of textual indicator names is intended to provide a clue 93 for implementers to discover this mechanism. 95 2.2. Enabling Criteria 97 If a client or server offers "ext-info-c" or "ext-info-s" 98 respectively, it must be prepared to accept a SSH_MSG_EXT_INFO message 99 from the peer. 101 Thus a server only needs to send "ext-info-s" if it intends to process 102 SSH_MSG_EXT_INFO from the client. 104 If a server receives an "ext-info-c", it MAY send an SSH_MSG_EXT_INFO 105 message, but is not required to do so. 107 If a SSH_MSG_EXT_INFO message is sent, then it MUST be the first 108 message after the initial SSH_MSG_NEWKEYS. 110 Implementations MUST NOT send an incorrect indicator name for their 111 role. Implementations MAY disconnect if the counter-party sends an 112 incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being 113 negotiated as a key exchange method, the parties MUST disconnect. 115 2.3. SSH_MSG_EXT_INFO Message 117 A party that received the "ext-info-c" or "ext-info-s" indicator 118 can send the the following message: 120 byte SSH_MSG_EXT_INFO (value 7) 121 uint32 nr-extensions 122 repeat "nr-extensions" times: 123 string extension-name 124 string extension-value 126 This message is sent without delay, and immediately after 127 SSH_MSG_NEWKEYS. 129 2.4. Server's Secondary SSH_MSG_EXT_INFO 131 If the client sent "ext-info-c", the server MAY send, but is not 132 obligated to send, an SSH_MSG_EXT_INFO message immediately before 133 SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send 134 this message whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS. 136 This allows a server to reveal support for additional extensions that 137 it was unwilling to reveal to an unauthenticated client. If a server 138 sends a subsequent SSH_MSG_EXT_INFO, this replaces any initial one, 139 and both the client and the server re-evaluate extensions in effect. 140 The server's last EXT_INFO is matched against the client's original. 142 2.5. Interpretation of Extension Names and Values 144 Each extension is identified by its extension-name, and defines the 145 conditions under which the extension is considered to be in effect. 146 Applications MUST ignore unrecognized extension-names. 148 In general, if an extension requires both the client and the server 149 to include it in order for the extension to take effect, the relative 150 position of the extension-name in each EXT_INFO message is irrelevant. 152 Extension-value fields are interpreted as defined by their respective 153 extension. An extension-value field MAY be empty if so permitted by 154 the extension. Applications that do not implement or recognize a 155 particular extension MUST ignore the associated extension-value field, 156 regardless of its size or content. 158 The cumulative size of an SSH_MSG_EXT_INFO message is limited only by 159 the maximum packet length that an implementation may apply in 160 accordance with [RFC4253]. Implementations MUST accept well-formed 161 SSH_MSG_EXT_INFO messages up to the maximum packet length they accept. 163 3. Initially Defined Extensions 165 3.1. "server-sig-algs" 167 This extension is sent with the following extension name and value: 169 string "server-sig-algs" 170 name-list signature-algorithms-accepted 172 Note that the name-list type is a strict subset of the string type, 173 and is thus permissible as an extension-value. 175 This extension is sent by the server only, and contains a list of 176 signature algorithms that the server is able to process as part of a 177 "publickey" request. 179 A client that wishes to proceed with public key authentication MAY 180 wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" 181 authentication request with an appropriate signature algorithm, rather 182 than resorting to trial and error. 184 Servers that implement public key authentication SHOULD implement this 185 extension. 187 If a server does not send this extension, a client SHALL NOT make any 188 assumptions about the server's signature algorithm support, and MAY 189 proceed with authentication request trial and error. 191 3.2. "no-flow-control" 193 This extension is sent with the following extension name and value: 195 string "no-flow-control" 196 string (empty) 198 This extension MUST be sent by both parties in order to take effect. 200 If included by both parties, the effect of this extension is that the 201 "initial window size" fields in the messages SSH_MSG_CHANNEL_OPEN and 202 SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined in [RFC4254], become 203 meaningless. The values of these fields MUST be ignored, and a channel 204 behaves as if the window size in either direction is infinite. Neither 205 side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST messages, 206 and if received, such messages MUST be ignored. 208 This extension is intended, but not limited to, use by file transfer 209 applications that are only going to use one channel, and for which the 210 flow control provided by SSH is an impediment, rather than a feature. 212 Implementations MUST refuse to open more than one simultaneous channel 213 when this extension is in effect. Nevertheless, server implementations 214 SHOULD support clients opening more than one non-simultaneous channel. 216 3.3. "accept-channels" 218 This extension is sent with the following extension name and value: 220 string "accept-channels" 221 name-list channel-types-accepted 223 An implementation MAY use this extension to signal to the other party 224 a list of channel types it might accept. A server that adapts the list 225 of available channel types based on authentication MAY defer sending 226 this extension until a subsequent EXT_INFO, just before sending the 227 message USERAUTH_SUCCESS. 229 An implementation is not obligated to unconditionally accept open 230 requests for channel types advertised in this extension. An open 231 request for a listed channel type MAY still fail for another reason. 233 3.4. "elevation" 235 This extension MAY be sent by the client as follows: 237 string "elevation" 238 string choice of: "y" | "n" | "d" 240 A client sends "y" to indicate its preference that the session should 241 be elevated; "n" to not be elevated; and "d" for the server to use its 242 default behavior. If a client does not send the "elevation" extension, 243 the server SHOULD act as if "d" was sent. 245 If a client has included this extension, then after authentication, a 246 server that supports this extension SHOULD indicate to the client 247 whether elevation was done by sending the following global request: 249 byte SSH_MSG_GLOBAL_REQUEST 250 string "elevation" 251 boolean want reply = false 252 boolean elevation performed 254 3.5. "delay-compression" 256 This extension MAY be sent by both parties as follows: 258 string "delay-compression" 259 string: 260 name-list compression_algorithms_client_to_server 261 name-list compression_algorithms_server_to_client 263 This extension allows the server and client to renegotiate compression 264 algorithm support without having to conduct a key re-exchange, putting 265 new algorithms into effect immediately upon successful authentication. 267 This extension takes effect only if both parties send it. Name-lists 268 MAY include any compression algorithm that could have been negotiated 269 in SSH_MSG_KEXINIT, except algorithms that define their own delayed 270 compression semantics. This means "zlib,none" is a valid algorithm 271 list in this context; but "zlib@openssh.com" is not. 273 If both parties send this extension, but the name-lists do not contain 274 a common algorithm in either direction, the parties MUST disconnect in 275 the same way as if negotiation failed as part of SSH_MSG_KEXINIT. 277 If this extension takes effect, the renegotiated compression algorithm 278 is used as follows: 280 - By the server, starting with the very next SSH message after 281 SSH_MSG_USERAUTH_SUCCESS. 283 - By the client, after sending SSH_MSG_NEWCOMPRESS. If this extension 284 takes effect, the client MUST send the following message immediately 285 after receiving the server's SSH_MSG_USERAUTH_SUCCESS: 287 byte SSH_MSG_NEWCOMPRESS (value 8) 289 The purpose of this message is to avoid a race condition where the 290 server cannot reliably know whether a message sent by the client was 291 sent before or after receiving the server's USERAUTH_SUCCESS. 293 As with all extensions, the server may delay including this extension 294 until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS. 295 This allows the server to avoid advertising compression support until 296 the client has been authenticated. 298 In subsequent key re-exchange, the compression algorithms negotiated 299 in re-exchange override the algorithms negotiated with this extension. 301 4. IANA Considerations 303 4.1. Additions to existing tables 305 IANA is requested to insert the following entries into the table 306 Message Numbers under Secure Shell (SSH) Protocol Parameters 307 [RFC4250]: 309 Value Message ID Reference 310 7 SSH_MSG_EXT_INFO [this document] 311 8 SSH_MSG_NEWCOMPRESS [this document] 313 IANA is requested to insert the following entries into the table Key 314 Exchange Method Names: 316 Method Name Reference Note 317 ext-info-s [this document] Section 2.2 318 ext-info-c [this document] Section 2.2 320 4.2. New table: Extension Names 322 Also under Secure Shell (SSH) Protocol Parameters, IANA is requested 323 to create a new table, Extension Names, with initial content: 325 Extension Name Reference Note 326 server-sig-algs [this document] Section 3.1 327 no-flow-control [this document] Section 3.2 328 accept-channels [this document] Section 3.3 329 elevation [this document] Section 3.4 330 delay-compression [this document] Section 3.5 332 4.2.1. Future Assignments to Extension Names 334 Names in the Extension Names table MUST follow the Conventions for 335 Names defined in [RFC4250], Section 4.6.1. 337 Requests for assignments of new non-local names in the Extension Names 338 table (i.e. names not including the '@' character) MUST be done 339 through the IETF CONSENSUS method, as described in [RFC5226]. 341 6. References 343 6.1. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 349 Protocol Assigned Numbers", RFC 4250, January 2006. 351 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 352 Authentication Protocol", RFC 4252, January 2006. 354 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 355 Transport Layer Protocol", RFC 4253, January 2006. 357 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 358 Connection Protocol", RFC 4254, January 2006. 360 [RFC5226] Narten, T. and Alvestrand, H., "Guidelines for Writing an 361 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 362 May 2008. 364 6.2. Informative References 366 [SSH-RSA-SHA2] 367 Bider, D., "Use of RSA Keys with SHA-2 256 and 512 in 368 Secure Shell (SSH)", draft-rsa-dsa-sha2-256-02, 369 November 2015, 370 . 372 Author's Address 374 Denis Bider 375 Bitvise Limited 376 Suites 41/42, Victoria House 377 26 Main Street 378 GI 380 Phone: +506 8315 6519 381 EMail: ietf-ssh3@denisbider.com 382 URI: https://www.bitvise.com/ 384 Acknowledgments 386 Thanks to Markus Friedl and Damien Miller for comments and initial 387 implementation.