idnits 2.17.1 draft-ssh-global-requests-ok-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 204 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 122 has weird spacing: '... string exten...' == Line 123 has weird spacing: '... string exten...' == Line 156 has weird spacing: '... string requ...' == Line 157 has weird spacing: '...boolean want-...' (Using the creation date from RFC4254, 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 (December 18, 2018) is 1955 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft D. Bider 3 Updates: 4254 (if approved) Bitvise Limited 4 Intended status: Standards Track December 18, 2018 5 Expires: May 18, 2019 7 Sending and Handling of Global Requests in Secure Shell (SSH) 8 draft-ssh-global-requests-ok-00.txt 10 Abstract 12 This memo updates RFC 4254 to clarify when global requests can be sent 13 or received and provides a mechanism for SSH software to indicate it 14 will accept global requests according to this requirement. 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) 2018 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. [RFC4254] requires both clients and servers to correctly 55 handle messages of type SSH_MSG_GLOBAL_REQUEST received at any time. 56 In practice, several client implementations and some servers mishandle 57 this requirement. This discourages implementations from deploying 58 protocol enhancements including host key synchronization and active 59 keep-alives. Software that uses such enhancements must rely on remote 60 version information to decide if global requests are safe to use. 61 However, this is not accurate as to the remote party's capabilities. 63 This memo updates RFC 4254 to clarify when software may send and must 64 accept global requests. An [RFC8308] extension is defined allowing 65 SSH software to indicate it complies with this requirement. 67 1.1. Requirements Terminology 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 1.2. Wire Encoding Terminology 75 The wire encoding types in this document - "string", "byte" and 76 "boolean" - have meanings as described in [RFC4251]. 78 2. Global Request Sending and Handling 80 The requirement in [RFC4254], which states that both a client and a 81 server must correctly handle global requests at any time, is replaced 82 as defined in this section. 84 A server MAY send a message of type SSH_MSG_GLOBAL_REQUEST at any time 85 after it has sent the message SSH_MSG_USERAUTH_SUCCESS (defined in 86 [RFC4252]), including immediately following that message. A server 87 MUST NOT send SSH_MSG_GLOBAL_REQUEST before it has sent 88 SSH_MSG_USERAUTH_SUCCESS. 90 A client MAY send a message of type SSH_MSG_GLOBAL_REQUEST at any time 91 after it has received SSH_MSG_USERAUTH_SUCCESS from the server. A 92 client MUST NOT send SSH_MSG_GLOBAL_REQUEST before it has received 93 SSH_MSG_USERAUTH_SUCCESS. 95 A server MUST handle correctly - as defined in [RFC4254] - any message 96 of type SSH_MSG_GLOBAL_REQUEST received after the server has sent 97 SSH_MSG_USERAUTH_SUCCESS. A server MAY implement arbitrary behavior 98 for global requests received before this. However, see Section 2.1 99 (Security Consideration). 101 A client MUST handle correctly - as defined in [RFC4254] - any message 102 of type SSH_MSG_GLOBAL_REQUEST received after it has received 103 SSH_MSG_USERAUTH_SUCCESS from the server. A client MAY implement 104 arbitrary behavior for global requests received before this. 106 Implementations MUST correctly handle SSH_MSG_GLOBAL_REQUEST messages 107 received during SSH key re-exchange. When implementations receive 108 global requests during key re-exchange, they MAY defer processing them 109 and responding until key re-exchange has completed. 111 2.1. Security Consideration 113 A server that chooses to handle SSH_MSG_GLOBAL_REQUEST before it has 114 sent SSH_MSG_USERAUTH_SUCCESS MUST apply precautions which take into 115 account that the client has not yet authenticated. 117 3. "global-requests-ok" Extension 119 SSH software that implements [RFC8308] MAY include the following 120 extension when sending an SSH_MSG_EXT_INFO message: 122 string extension-name = "global-requests-ok" 123 string extension-value = "" 125 The sender MUST send an empty extension value. A receiver that does 126 not expect an extension value MUST ignore it. A receiver MUST tolerate 127 and ignore non-printable binary characters in the extension value. 128 Future specifications MAY define meanings for this value. 130 A receiver SHOULD assume, if the remote party includes this extension 131 in its SSH_MSG_EXT_INFO, that the remote will handle global requests 132 as required by this document, regardless of any heuristic knowledge 133 the receiver may have about the remote party's software and version. 134 The receiver SHOULD enable any functionality that relies on global 135 requests if this extension is received. 137 4. Practical Uses of Global Requests 139 The following are some uses of the SSH_MSG_GLOBAL_REQUEST message 140 which are prevented or made difficult by software which incorrectly 141 disconnects when receiving a global request: 143 4.1. Active Keep-Alive 145 Network connections can terminate in ways that prevent SSH software 146 from immediately detecting the disconnection. The TCP stack might not 147 report the disconnection for minutes. Meanwhile resources used by the 148 previous session, such as port numbers for TCP forwarding, may remain 149 in use so that a reconnected client cannot resume its functions. 151 A common strategy to detect if the remote party is still connected is 152 to send a global request which the remote does not have to recognize, 153 only reply to. For example: 155 byte SSH_MSG_GLOBAL_REQUEST 156 string request-name = "keep-alive@implementation.example.com" 157 boolean want-reply = true 159 This requires the remote party to reply with SSH_MSG_REQUEST_FAILURE, 160 which is sufficient to confirm the connection is still active. 162 This strategy cannot be used if the remote party might disconnect on 163 receiving a global request. 165 4.2. Host Key Synchronization 167 A practical deficiency of SSH as standardized and widely used is that 168 it provides no mechanism for host key rollover. A server that wishes 169 to migrate its host key from e.g. DSA to RSA, or from RSA to 170 Curve25519, or from 1024-bit RSA to 3072-bit RSA, has no automated 171 way of informing clients of the intended new host key. Instead, server 172 administrators must contact all clients - which sometimes number in 173 thousands - where host key information must be updated manually. The 174 common result is that servers rarely change host keys until forced. 176 OpenSSH supports and documents an extension ([OPENSSH]) which uses a 177 global request named "hostkeys-00@openssh.com" to synchronize host 178 keys. After successful authentication, the server sends this request 179 to the client, listing all of the server's host keys. The client can 180 respond with a further request for the server to prove possession of 181 those host keys. 183 This mechanism cannot be used if the remote party might disconnect on 184 receiving a global request. 186 5. IANA Considerations 188 IANA is requested to update the "Secure Shell (SSH) Protocol 189 Parameters" registry established with [RFC4250], adding the following 190 entry in the table Extension Names [IANA-EXT]: 192 Extension Name Reference Note 193 global-requests-ok [this document] Section 3 195 6. Security Considerations 197 Security considerations appear where applicable in the document. 199 The security considerations of [RFC4251] also apply to this document. 201 7. References 203 7.1. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, March 1997. 208 [RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 209 Protocol Architecture", RFC 4251, January 2006. 211 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 212 Authentication Protocol", RFC 4252, January 2006. 214 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 215 Connection Protocol", RFC 4254, January 2006. 217 [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell 218 (SSH) Protocol", RFC 8308, March 2018. 220 7.2. Informative References 222 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 223 Protocol Assigned Numbers", RFC 4250, January 2006. 225 [OPENSSH] "OpenSSH deviations and extensions to the published SSH 226 protocol", . 229 [IANA-EXT] "Secure Shell (SSH) Protocol Parameters", 230 . 233 Author's Address 235 Denis Bider 236 Bitvise Limited 237 4105 Lombardy Court 238 Colleyville, Texas 76034 239 United States of America 241 Email: ietf-ssh3@denisbider.com 242 URI: https://www.bitvise.com/