idnits 2.17.1 draft-ietf-curdle-ssh-ext-info-03.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. -- The draft header indicates that this document updates RFC4252, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4253, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4254, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 129 has weird spacing: '... string exte...' == Line 130 has weird spacing: '... string exte...' == Line 187 has weird spacing: '...me-list sign...' == Line 220 has weird spacing: '...me-list com...' == Line 221 has weird spacing: '...me-list com...' (Using the creation date from RFC4252, updated by this document, for RFC5378 checks: 1997-03-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 29, 2017) is 2586 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 (-12) exists of draft-ietf-curdle-rsa-sha2-04 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft D. Bider 3 Updates: 4252, 4253, 4254 (if approved) Bitvise Limited 4 Intended status: Standards Track March 29, 2017 5 Expires: September 29, 2017 7 Extension Negotiation in Secure Shell (SSH) 8 draft-ietf-curdle-ssh-ext-info-03.txt 10 Abstract 12 This memo defines a mechanism for SSH clients and servers to exchange 13 information about supported protocol extensions confidentially after 14 completed key exchange. 16 Status 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Overview and Rationale 53 Secure Shell (SSH) is a common protocol for secure communication on 54 the Internet. The original design of the SSH transport layer [RFC4253] 55 lacks proper extension negotiation. Meanwhile, diverse implementations 56 take steps to ensure that known message types contain no unrecognized 57 information. This makes it difficult for implementations to signal 58 capabilities and negotiate extensions without risking disconnection. 60 This obstacle has been recognized in relationship with [SSH-RSA-SHA2], 61 where the need arises for a client to discover signature algorithms a 62 server accepts, to avoid authentication penalties and trial-and-error. 64 1.1. Requirements Terminology 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 1.2. Wire Encoding Terminology 72 The wire encoding types in this document - "byte", "uint32", "string", 73 "boolean", "name-list" - have meanings as described in [RFC4251]. 75 2. Extension Negotiation Mechanism 77 2.1. Signaling of Extension Negotiation in KEXINIT 79 Applications implementing this mechanism MUST add to the field 80 "kex_algorithms", in their KEXINIT packet sent for the first key 81 exchange, one of the following indicator names: 83 - When acting as server: "ext-info-s" 84 - When acting as client: "ext-info-c" 86 The indicator name is added without quotes, and MAY be added at any 87 position in the name-list, subject to proper separation from other 88 names as per name-list conventions. 90 The names are added to the "kex_algorithms" field because this is one 91 of two name-list fields in KEXINIT that do not have a separate copy 92 for each data direction. 94 The indicator names inserted by the client and server are different to 95 ensure that these names will not produce a match, and will be neutral 96 with respect to key exchange algorithm negotiation. 98 The inclusion of textual indicator names is intended to provide a clue 99 for implementers to discover this mechanism. 101 2.2. Enabling Criteria 103 If a client or server offers "ext-info-c" or "ext-info-s" 104 respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO 105 message from the peer. 107 Thus a server only needs to send "ext-info-s" if it intends to process 108 SSH_MSG_EXT_INFO from the client. 110 If a server receives an "ext-info-c", it MAY send an SSH_MSG_EXT_INFO 111 message, but is not required to do so. 113 If an SSH_MSG_EXT_INFO message is sent, then it MUST be the first 114 message after the initial SSH_MSG_NEWKEYS. 116 Implementations MUST NOT send an incorrect indicator name for their 117 role. Implementations MAY disconnect if the counter-party sends an 118 incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being 119 negotiated as a key exchange method, the parties MUST disconnect. 121 2.3. SSH_MSG_EXT_INFO Message 123 A party that received the "ext-info-c" or "ext-info-s" indicator 124 MAY send the following message: 126 byte SSH_MSG_EXT_INFO (value 7) 127 uint32 nr-extensions 128 repeat the following 2 fields "nr-extensions" times: 129 string extension-name 130 string extension-value 132 This message is sent immediately after SSH_MSG_NEWKEYS, without delay. 133 This allows a client to pipeline an authentication request after its 134 SSH_MSG_SERVICE_REQUEST, even when this needs extension information. 136 2.4. Server's Secondary SSH_MSG_EXT_INFO 138 If the client sent "ext-info-c", the server MAY send zero, one, or two 139 EXT_INFO messages. The first opportunity for the server's EXT_INFO is 140 after the server's NEWKEYS, as above. The second opportunity is just 141 before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The 142 server MAY send EXT_INFO at the second opportunity, whether or not it 143 sent it at the first. A client that sent "ext-info-c" MUST accept a 144 server's EXT_INFO at both opportunities, but MUST NOT require it. 146 This allows a server to reveal support for additional extensions that 147 it was unwilling to reveal to an unauthenticated client. If a server 148 sends a subsequent SSH_MSG_EXT_INFO, this replaces any initial one, 149 and both the client and the server re-evaluate extensions in effect. 150 The server's last EXT_INFO is matched against the client's original. 152 (*) The message MUST be sent at this point for the following reasons: 153 if it was sent earlier, it would not allow the server to withhold 154 information until the client has authenticated; if it was sent later, 155 a client that needs information from the second EXT_INFO immediately 156 after successful authentication would have no way of reliably knowing 157 whether there will be a second EXT_INFO or not. 159 2.5. Interpretation of Extension Names and Values 161 Each extension is identified by its extension-name, and defines the 162 conditions under which the extension is considered to be in effect. 163 Applications MUST ignore unrecognized extension-names. 165 If an extension requires both the client and the server to include it 166 in order for the extension to take effect, the relative position of 167 the extension-name in each EXT_INFO message is irrelevant. 169 Extension-value fields are interpreted as defined by their respective 170 extension. An extension-value field MAY be empty if so permitted by 171 the extension. Applications that do not implement or recognize a 172 particular extension MUST ignore the associated extension-value field, 173 regardless of its size or content. 175 The cumulative size of an SSH_MSG_EXT_INFO message is limited only by 176 the maximum packet length that an implementation may apply in 177 accordance with [RFC4253]. Implementations MUST accept well-formed 178 SSH_MSG_EXT_INFO messages up to the maximum packet length they accept. 180 3. Initially Defined Extensions 182 3.1. "server-sig-algs" 184 This extension is sent with the following extension name and value: 186 string "server-sig-algs" 187 name-list signature-algorithms-accepted 189 Note that the name-list type is a strict subset of the string type, 190 and is thus permissible as an extension-value. See [RFC4251] for 191 more information about this encoding. 193 This extension is sent by the server, and contains a list of signature 194 algorithms that the server is able to process as part of a "publickey" 195 authentication request. 197 If a client sends this extension, the server MAY ignore it, and MAY 198 disconnect. 200 A client that wishes to proceed with public key authentication MAY 201 wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" 202 authentication request with an appropriate signature algorithm, rather 203 than resorting to trial and error. 205 Servers that implement public key authentication SHOULD implement this 206 extension. 208 If a server does not send this extension, a client MUST NOT make any 209 assumptions about the server's signature algorithm support, and MAY 210 proceed with authentication requests using trial and error. Note that 211 implementations are known to exist that apply authentication penalties 212 if the client attempts to use an unexpected signature algorithm. 214 3.2. "delay-compression" 216 This extension MAY be sent by both parties as follows: 218 string "delay-compression" 219 string: 220 name-list compression_algorithms_client_to_server 221 name-list compression_algorithms_server_to_client 223 This extension allows the server and client to renegotiate compression 224 algorithm support without having to conduct a key re-exchange, putting 225 new algorithms into effect immediately upon successful authentication. 227 This extension takes effect only if both parties send it. Name-lists 228 MAY include any compression algorithm that could have been negotiated 229 in SSH_MSG_KEXINIT, except algorithms that define their own delayed 230 compression semantics. This means "zlib,none" is a valid algorithm 231 list in this context; but "zlib@openssh.com" is not. 233 If both parties send this extension, but the name-lists do not contain 234 a common algorithm in either direction, the parties MUST disconnect in 235 the same way as if negotiation failed as part of SSH_MSG_KEXINIT. 237 If this extension takes effect, the renegotiated compression algorithm 238 is activated for the very next SSH message after the trigger message: 240 - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS. 241 - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS. 243 If this extension takes effect, the client MUST send the following 244 message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: 246 byte SSH_MSG_NEWCOMPRESS (value 8) 248 The purpose of NEWCOMPRESS is to avoid a race condition where the 249 server cannot reliably know whether a message sent by the client was 250 sent before or after receiving the server's USERAUTH_SUCCESS. 252 As with all extensions, the server MAY delay including this extension 253 until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS. 254 This allows the server to avoid advertising compression support until 255 the client has been authenticated. 257 If the parties re-negotiate compression using this extension in a 258 session where compression is already enabled; and the re-negotiated 259 algorithm is the same in one or both directions; then the internal 260 compression state MUST be reset for each direction at the time the 261 re-negotiated algorithm takes effect. 263 3.2.1. Awkwardly Timed Key Re-Exchange 265 A party that has signaled, or intends to signal, support for this 266 extension in an SSH session, MUST NOT initiate key re-exchange in that 267 session until either of the following occurs: 269 - This extension was negotiated, and the party that's about to start 270 key re-exchange already sent its trigger message for compression. 272 - The party has sent (if server) or received (if client) the message 273 SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated. 275 If a party violates this rule, the other party MAY disconnect. 277 In general, parties SHOULD NOT start key re-exchange before successful 278 user authentication, but MAY tolerate it if not using this extension. 280 3.2.2. Subsequent Re-Exchange 282 In subsequent key re-exchanges that unambiguously begin after the 283 compression trigger messages, the compression algorithms negotiated in 284 re-exchange override the algorithms negotiated with this extension. 286 3.3. "no-flow-control" 288 This extension is sent with the following extension name and value: 290 string "no-flow-control" 291 string choice of: "p" for preferred | "s" for supported 293 A party SHOULD send "s" if it supports "no-flow-control", but does not 294 prefer to enable it. A party SHOULD send "p" if it prefers to enable 295 the extension if the other party supports it. Parties MAY disconnect 296 if they receive a different extension value. 298 To take effect, this extension MUST be: 300 - Sent by both parties. 301 - At least one party MUST have sent the value "p" (preferred). 303 If this extension takes effect, the "initial window size" fields in 304 SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined 305 in [RFC4254], become meaningless. The values of these fields MUST be 306 ignored, and a channel behaves as if all window sizes are infinite. 307 Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST 308 messages, and if received, such messages MUST be ignored. 310 This extension is intended, but not limited to, use by file transfer 311 applications that are only going to use one channel, and for which the 312 flow control provided by SSH is an impediment, rather than a feature. 314 Implementations MUST refuse to open more than one simultaneous channel 315 when this extension is in effect. Nevertheless, server implementations 316 SHOULD support clients opening more than one non-simultaneous channel. 318 3.4. "elevation" 320 This extension MAY be sent by the client as follows: 322 string "elevation" 323 string choice of: "y" | "n" | "d" 325 A client sends "y" to indicate its preference that the session should 326 be elevated (as used by Windows); "n" to not be elevated; and "d" for 327 the server to use its default behavior. The server MAY disconnect if 328 it receives a different extension value. If a client does not send the 329 "elevation" extension, the server SHOULD act as if "d" was sent. 331 If a client has included this extension, then after authentication, a 332 server that supports this extension SHOULD indicate to the client 333 whether elevation was done by sending the following global request: 335 byte SSH_MSG_GLOBAL_REQUEST 336 string "elevation" 337 boolean want reply = false 338 boolean elevation performed 340 4. IANA Considerations 342 4.1. Additions to existing tables 344 IANA is requested to insert the following entries into the table 345 Message Numbers under Secure Shell (SSH) Protocol Parameters 346 [RFC4250]: 348 Value Message ID Reference 349 7 SSH_MSG_EXT_INFO [this document] 350 8 SSH_MSG_NEWCOMPRESS [this document] 352 IANA is requested to insert the following entries into the table Key 353 Exchange Method Names: 355 Method Name Reference Note 356 ext-info-s [this document] Section 2.2 357 ext-info-c [this document] Section 2.2 359 4.2. New table: Extension Names 361 Also under Secure Shell (SSH) Protocol Parameters, IANA is requested 362 to create a new table, Extension Names, with initial content: 364 Extension Name Reference Note 365 server-sig-algs [this document] Section 3.1 366 delay-compression [this document] Section 3.2 367 no-flow-control [this document] Section 3.3 368 elevation [this document] Section 3.4 370 4.2.1. Future Assignments to Extension Names 372 Names in the Extension Names table MUST follow the Conventions for 373 Names defined in [RFC4250], Section 4.6.1. 375 Requests for assignments of new non-local names in the Extension Names 376 table (i.e. names not including the '@' character) MUST be done 377 through the IETF CONSENSUS method, as described in [RFC5226]. 379 5. References 381 5.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 387 Protocol Assigned Numbers", RFC 4250, January 2006. 389 [RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 390 Protocol Architecture", RFC 4251, January 2006. 392 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 393 Authentication Protocol", RFC 4252, January 2006. 395 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 396 Transport Layer Protocol", RFC 4253, January 2006. 398 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 399 Connection Protocol", RFC 4254, January 2006. 401 [RFC5226] Narten, T. and Alvestrand, H., "Guidelines for Writing an 402 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 403 May 2008. 405 5.2. Informative References 407 [SSH-RSA-SHA2] 408 Bider, D., "Use of RSA Keys with SHA-2 256 and 512 in 409 Secure Shell (SSH)", draft-ietf-curdle-rsa-sha2-04.txt, 410 March 2017, . 413 Author's Address 415 Denis Bider 416 Bitvise Limited 417 Suites 41/42, Victoria House 418 26 Main Street 419 GI 421 Phone: +506 8315 6519 422 EMail: ietf-ssh3@denisbider.com 423 URI: https://www.bitvise.com/ 425 Acknowledgments 427 Thanks to Markus Friedl and Damien Miller for comments and initial 428 implementation. Thanks to Peter Gutmann, Roumen Petrov, and Daniel 429 Migault for review and feedback.