idnits 2.17.1 draft-ietf-curdle-ssh-ext-info-11.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 draft header indicates that this document updates RFC4254, but the abstract doesn't seem to directly say this. It does mention RFC4254 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 132 has weird spacing: '... string exte...' == Line 133 has weird spacing: '... string exte...' == Line 198 has weird spacing: '...me-list publ...' == Line 234 has weird spacing: '...me-list com...' == Line 235 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 (July 28, 2017) is 2463 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) == Outdated reference: A later version (-12) exists of draft-ietf-curdle-rsa-sha2-09 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 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 July 28, 2017 5 Expires: December 19, 2017 7 Extension Negotiation in Secure Shell (SSH) 8 draft-ietf-curdle-ssh-ext-info-11.txt 10 Abstract 12 This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a 13 mechanism for SSH clients and servers to exchange information about 14 supported protocol extensions confidentially after SSH 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. 59 This obstacle has been recognized in relationship with [SSH-RSA-SHA2], 60 where the need arises for a client to discover public key algorithms a 61 server accepts, to avoid authentication penalties and trial-and-error. 63 This memo updates RFC 4252, RFC 4253, and RFC 4254. 65 1.1. Requirements Terminology 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 1.2. Wire Encoding Terminology 73 The wire encoding types in this document - "byte", "uint32", "string", 74 "boolean", "name-list" - have meanings as described in [RFC4251]. 76 2. Extension Negotiation Mechanism 78 2.1. Signaling of Extension Negotiation in KEXINIT 80 Applications implementing this mechanism MUST add to the field 81 "kex_algorithms", in their KEXINIT packet sent for the first key 82 exchange, one of the following indicator names: 84 - When acting as server: "ext-info-s" 85 - When acting as client: "ext-info-c" 87 The indicator name is added without quotes, and MAY be added at any 88 position in the name-list, subject to proper separation from other 89 names as per name-list conventions. 91 The names are added to the "kex_algorithms" field because this is one 92 of two name-list fields in KEXINIT that do not have a separate copy 93 for each data direction. 95 The indicator names inserted by the client and server are different to 96 ensure these names will not produce a match, and therefore not affect 97 the algorithm chosen in key exchange algorithm negotiation. 99 The inclusion of textual indicator names is intended to provide a clue 100 for implementers to discover this mechanism. 102 2.2. Enabling Criteria 104 If a client or server offers "ext-info-c" or "ext-info-s" 105 respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO 106 message from the peer. 108 A server only needs to send "ext-info-s" if it intends to process 109 SSH_MSG_EXT_INFO from the client. A client only needs to send 110 "ext-info-c" if it plans to process SSH_MSG_EXT_INFO from the server. 112 If a server receives an "ext-info-c", or a client receives an 113 "ext-info-s", it MAY send an SSH_MSG_EXT_INFO message, but is not 114 required to do so. 116 Neither party needs to wait for the other's KEXINIT in order to decide 117 whether to send the appropriate indicator in its own KEXINIT. 119 Implementations MUST NOT send an incorrect indicator name for their 120 role. Implementations MAY disconnect if the counter-party sends an 121 incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being 122 negotiated as a key exchange method, the parties MUST disconnect. 124 2.3. SSH_MSG_EXT_INFO Message 126 A party that received the "ext-info-c" or "ext-info-s" indicator 127 MAY send the following message: 129 byte SSH_MSG_EXT_INFO (value 7) 130 uint32 nr-extensions 131 repeat the following 2 fields "nr-extensions" times: 132 string extension-name 133 string extension-value (binary) 135 This message is sent immediately after SSH_MSG_NEWKEYS, without delay. 136 This allows a client to pipeline an authentication request after its 137 SSH_MSG_SERVICE_REQUEST, even when this needs extension information. 139 Receivers MUST tolerate any sequence of bytes; including null bytes 140 at any position; in an unknown extension's extension-value. 142 2.4. Server's Secondary SSH_MSG_EXT_INFO 144 If the client sent "ext-info-c", the server MAY send zero, one, or two 145 EXT_INFO messages. The first opportunity for the server's EXT_INFO is 146 after the server's NEWKEYS, as above. The second opportunity is just 147 before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The 148 server MAY send EXT_INFO at the second opportunity, whether or not it 149 sent it at the first. A client that sent "ext-info-c" MUST accept a 150 server's EXT_INFO at both opportunities, but MUST NOT require it. 152 This allows a server to reveal support for additional extensions that 153 it was unwilling to reveal to an unauthenticated client. If a server 154 sends a subsequent SSH_MSG_EXT_INFO, this replaces any initial one, 155 and both the client and the server re-evaluate extensions in effect. 156 The server's last EXT_INFO is matched against the client's original. 158 (*) The message MUST be sent at this point for the following reasons: 159 if it was sent earlier, it would not allow the server to withhold 160 information until the client has authenticated; if it was sent later, 161 a client that needs information from the second EXT_INFO immediately 162 after successful authentication would have no way of reliably knowing 163 whether there will be a second EXT_INFO or not. 165 2.5. Interpretation of Extension Names and Values 167 Each extension is identified by its extension-name, and defines the 168 conditions under which the extension is considered to be in effect. 169 Applications MUST ignore unrecognized extension-names. 171 An extension MAY dictate, where it is specified, that in order to take 172 effect, both parties must include it in their EXT_INFO; or it MAY be 173 sufficient that only one party includes it; or other rules MAY be 174 specified. The relative order in which extensions appear in an 175 EXT_INFO message MUST be ignored by default; but an extension MAY 176 specify that the order matters for that extension, in a specific way. 178 Extension-value fields are interpreted as defined by their respective 179 extension. An extension-value field MAY be empty if so permitted by 180 the extension. Applications that do not implement or recognize a 181 particular extension MUST ignore the associated extension-value field, 182 regardless of its size or content. In particular, applications MUST 183 tolerate any sequence of bytes; including null bytes at any position; 184 in an unknown extension's extension-value. 186 The cumulative size of an SSH_MSG_EXT_INFO message is limited only by 187 the maximum packet length that an implementation may apply in 188 accordance with [RFC4253]. Implementations MUST accept well-formed 189 SSH_MSG_EXT_INFO messages up to the maximum packet length they accept. 191 3. Initially Defined Extensions 193 3.1. "server-sig-algs" 195 This extension is sent with the following extension name and value: 197 string "server-sig-algs" 198 name-list public-key-algorithms-accepted 200 The name-list type is a strict subset of the string type, and is thus 201 permissible as an extension-value. See [RFC4251] for more information. 203 This extension is sent by the server, and contains a list of public 204 key algorithms that the server is able to process as part of a 205 "publickey" authentication request. If a client sends this extension, 206 the server MAY ignore it, and MAY disconnect. 208 In this extension, a server MUST enumerate all public key algorithms 209 it might accept during user authentication. However, there exist early 210 server implementations which do not enumerate all accepted algorithms. 211 For this reason, a client MAY send a user authentication request using 212 a public key algorithm not included in "server-sig-algs". 214 A client that wishes to proceed with public key authentication MAY 215 wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" 216 authentication request with an appropriate public key algorithm, 217 rather than resorting to trial and error. 219 Servers that implement public key authentication SHOULD implement this 220 extension. 222 If a server does not send this extension, a client MUST NOT make any 223 assumptions about the server's public key algorithm support, and MAY 224 proceed with authentication requests using trial and error. Note that 225 implementations are known to exist that apply authentication penalties 226 if the client attempts to use an unexpected public key algorithm. 228 3.2. "delay-compression" 230 This extension MAY be sent by both parties as follows: 232 string "delay-compression" 233 string: 234 name-list compression_algorithms_client_to_server 235 name-list compression_algorithms_server_to_client 237 This extension allows the server and client to renegotiate compression 238 algorithm support without having to conduct a key re-exchange, putting 239 new algorithms into effect immediately upon successful authentication. 241 This extension takes effect only if both parties send it. Name-lists 242 MAY include any compression algorithm that could have been negotiated 243 in SSH_MSG_KEXINIT, except algorithms that define their own delayed 244 compression semantics. This means "zlib,none" is a valid algorithm 245 list in this context; but "zlib@openssh.com" is not. 247 If both parties send this extension, but the name-lists do not contain 248 a common algorithm in either direction, the parties MUST disconnect in 249 the same way as if negotiation failed as part of SSH_MSG_KEXINIT. 251 If this extension takes effect, the renegotiated compression algorithm 252 is activated for the very next SSH message after the trigger message: 254 - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS. 255 - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS. 257 If this extension takes effect, the client MUST send the following 258 message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: 260 byte SSH_MSG_NEWCOMPRESS (value 8) 262 The purpose of NEWCOMPRESS is to avoid a race condition where the 263 server cannot reliably know whether a message sent by the client was 264 sent before or after receiving the server's USERAUTH_SUCCESS. 266 As with all extensions, the server MAY delay including this extension 267 until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS. 268 This allows the server to avoid advertising compression support until 269 the client has been authenticated. 271 If the parties re-negotiate compression using this extension in a 272 session where compression is already enabled; and the re-negotiated 273 algorithm is the same in one or both directions; then the internal 274 compression state MUST be reset for each direction at the time the 275 re-negotiated algorithm takes effect. 277 3.2.1. Awkwardly Timed Key Re-Exchange 279 A party that has signaled, or intends to signal, support for this 280 extension in an SSH session, MUST NOT initiate key re-exchange in that 281 session until either of the following occurs: 283 - This extension was negotiated, and the party that's about to start 284 key re-exchange already sent its trigger message for compression. 286 - The party has sent (if server) or received (if client) the message 287 SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated. 289 If a party violates this rule, the other party MAY disconnect. 291 In general, parties SHOULD NOT start key re-exchange before successful 292 user authentication, but MAY tolerate it if not using this extension. 294 3.2.2. Subsequent Re-Exchange 296 In subsequent key re-exchanges that unambiguously begin after the 297 compression trigger messages, the compression algorithms negotiated in 298 re-exchange override the algorithms negotiated with this extension. 300 3.3. "no-flow-control" 302 This extension is sent with the following extension name and value: 304 string "no-flow-control" 305 string choice of: "p" for preferred | "s" for supported 307 A party SHOULD send "s" if it supports "no-flow-control", but does not 308 prefer to enable it. A party SHOULD send "p" if it prefers to enable 309 the extension if the other party supports it. Parties MAY disconnect 310 if they receive a different extension value. 312 To take effect, this extension MUST be: 314 - Sent by both parties. 315 - At least one party MUST have sent the value "p" (preferred). 317 If this extension takes effect, the "initial window size" fields in 318 SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as defined 319 in [RFC4254], become meaningless. The values of these fields MUST be 320 ignored, and a channel behaves as if all window sizes are infinite. 321 Neither side is required to send any SSH_MSG_CHANNEL_WINDOW_ADJUST 322 messages, and if received, such messages MUST be ignored. 324 This extension is intended, but not limited to, use by file transfer 325 applications that are only going to use one channel, and for which the 326 flow control provided by SSH is an impediment, rather than a feature. 328 Implementations MUST refuse to open more than one simultaneous channel 329 when this extension is in effect. Nevertheless, server implementations 330 SHOULD support clients opening more than one non-simultaneous channel. 332 3.3.1. Implementation Note: Prior "No Flow Control" Practice 334 Before this extension, some applications would simply not implement 335 SSH flow control, sending an initial channel window size of 2^32 - 1. 336 Applications SHOULD NOT do this for the following reasons: 338 - It is entirely within the realm of possibility to transfer more than 339 2^32 bytes over a channel. The channel will then hang if the other 340 party implements SSH flow control according to [RFC4254]. 342 - There exist implementations which cannot handle such large channel 343 window sizes, and will exhibit non-graceful behaviors, including 344 disconnection. 346 3.4. "elevation" 348 This extension MAY be sent by the client as follows: 350 string "elevation" 351 string choice of: "y" | "n" | "d" 353 A client sends "y" to indicate its preference that the session should 354 be elevated; "n" to not be elevated; and "d" for the server to use its 355 default behavior. The server MAY disconnect if it receives a different 356 extension value. If a client does not send the "elevation" extension, 357 the server SHOULD act as if "d" was sent. 359 The terms "elevation" and "elevated" refer to an operating system 360 mechanism where an administrator user's logon session is associated 361 with two security contexts: one limited, and one with administrative 362 rights. To "elevate" such a session is to activate the security 363 context with full administrative rights. For more information about 364 this mechanism on Windows, see also [WINADMIN] and [WINTOKEN]. 366 If a client has included this extension, then after authentication, a 367 server that supports this extension SHOULD indicate to the client 368 whether elevation was done by sending the following global request: 370 byte SSH_MSG_GLOBAL_REQUEST 371 string "elevation" 372 boolean want reply = false 373 boolean elevation performed 375 4. IANA Considerations 377 4.1. Additions to existing tables 379 IANA is requested to insert the following entries into the table 380 Message Numbers [IANA-M] under Secure Shell (SSH) Protocol Parameters 381 [RFC4250]: 383 Value Message ID Reference 384 7 SSH_MSG_EXT_INFO [this document] 385 8 SSH_MSG_NEWCOMPRESS [this document] 387 IANA is requested to insert the following entries into the table Key 388 Exchange Method Names [IANA-KE]: 390 Method Name Reference Note 391 ext-info-s [this document] Section 2.2 392 ext-info-c [this document] Section 2.2 394 4.2. New table: Extension Names 396 Also under Secure Shell (SSH) Protocol Parameters, IANA is requested 397 to create a new table, Extension Names, with initial content: 399 Extension Name Reference Note 400 server-sig-algs [this document] Section 3.1 401 delay-compression [this document] Section 3.2 402 no-flow-control [this document] Section 3.3 403 elevation [this document] Section 3.4 405 4.2.1. Future Assignments to Extension Names 407 Names in the Extension Names table MUST follow the Conventions for 408 Names defined in [RFC4250], Section 4.6.1. 410 Requests for assignments of new non-local names in the Extension Names 411 table (i.e. names not including the '@' character) MUST be done 412 through the IETF CONSENSUS method, as described in [RFC8126]. 414 5. Security Considerations 416 Security considerations are discussed throughout this document. This 417 document updates the SSH protocol as defined in [RFC4251] and related 418 documents. The security considerations of [RFC4251] apply. 420 6. References 422 6.1. Normative References 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 428 Protocol Assigned Numbers", RFC 4250, January 2006. 430 [RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 431 Protocol Architecture", RFC 4251, January 2006. 433 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 434 Authentication Protocol", RFC 4252, January 2006. 436 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 437 Transport Layer Protocol", RFC 4253, January 2006. 439 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 440 Connection Protocol", RFC 4254, January 2006. 442 [RFC8126] Cotton, M., Leiba, B. and Narten, T., "Guidelines for 443 Writing an IANA Considerations Section in RFCs", BCP 26, 444 RFC 8126, June 2017. 446 6.2. Informative References 448 [SSH-RSA-SHA2] 449 Bider, D., "Use of RSA Keys with SHA-2 256 and 512 in 450 Secure Shell (SSH)", draft-ietf-curdle-rsa-sha2-09.txt, 451 June 2017, . 454 [IANA-M] "Secure Shell (SSH) Protocol Parameters", 455 . 458 [IANA-KE] "Secure Shell (SSH) Protocol Parameters", 459 . 462 [WINADMIN] "How to launch a process as a Full Administrator when UAC 463 is enabled?", . 467 [WINTOKEN] "TOKEN_ELEVATION_TYPE enumeration", 468 . 471 Author's Address 473 Denis Bider 474 Bitvise Limited 475 Suites 41/42, Victoria House 476 26 Main Street 477 GI 479 Phone: +506 8315 6519 480 EMail: ietf-ssh3@denisbider.com 481 URI: https://www.bitvise.com/ 483 Acknowledgments 485 Thanks to Markus Friedl and Damien Miller for comments and initial 486 implementation. Thanks to Peter Gutmann, Roumen Petrov, and Daniel 487 Migault for review and feedback.