idnits 2.17.1 draft-ietf-curdle-ssh-ext-info-02.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 8) being 59 lines 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 124 has weird spacing: '... string exte...' == Line 125 has weird spacing: '... string exte...' == Line 171 has weird spacing: '...me-list sign...' == Line 207 has weird spacing: '...me-list com...' == Line 208 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 (February 27, 2017) is 2615 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) == Unused Reference: 'RFC4254' is defined on line 301, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-12) exists of draft-ietf-curdle-rsa-sha2-03 Summary: 2 errors (**), 0 flaws (~~), 9 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 February 27, 2017 5 Expires: August 27, 2017 7 Extension Negotiation in Secure Shell (SSH) 8 draft-ietf-curdle-ssh-ext-info-02.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 2. Extension Negotiation Mechanism 72 2.1. Signaling of Extension Negotiation in KEXINIT 74 Applications implementing this mechanism MUST add to the field 75 "kex_algorithms", in their KEXINIT packet sent for the first key 76 exchange, one of the following indicator names: 78 - When acting as server: "ext-info-s" 79 - When acting as client: "ext-info-c" 81 The indicator name is added without quotes, and MAY be added at any 82 position in the name-list, subject to proper separation from other 83 names as per name-list conventions. 85 The names are added to the "kex_algorithms" field because this is one 86 of two name-list fields in KEXINIT that do not have a separate copy 87 for each data direction. 89 The indicator names inserted by the client and server are different to 90 ensure that these names will not produce a match, and will be neutral 91 with respect to key exchange algorithm negotiation. 93 The inclusion of textual indicator names is intended to provide a clue 94 for implementers to discover this mechanism. 96 2.2. Enabling Criteria 98 If a client or server offers "ext-info-c" or "ext-info-s" 99 respectively, it must be prepared to accept an SSH_MSG_EXT_INFO 100 message from the peer. 102 Thus a server only needs to send "ext-info-s" if it intends to process 103 SSH_MSG_EXT_INFO from the client. 105 If a server receives an "ext-info-c", it MAY send an SSH_MSG_EXT_INFO 106 message, but is not required to do so. 108 If an SSH_MSG_EXT_INFO message is sent, then it MUST be the first 109 message after the initial SSH_MSG_NEWKEYS. 111 Implementations MUST NOT send an incorrect indicator name for their 112 role. Implementations MAY disconnect if the counter-party sends an 113 incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being 114 negotiated as a key exchange method, the parties MUST disconnect. 116 2.3. SSH_MSG_EXT_INFO Message 118 A party that received the "ext-info-c" or "ext-info-s" indicator 119 MAY send the following message: 121 byte SSH_MSG_EXT_INFO (value 7) 122 uint32 nr-extensions 123 repeat "nr-extensions" times: 124 string extension-name 125 string extension-value 127 This message is sent without delay, and immediately after 128 SSH_MSG_NEWKEYS. 130 2.4. Server's Secondary SSH_MSG_EXT_INFO 132 If the client sent "ext-info-c", the server MAY send, but is not 133 obligated to send, an SSH_MSG_EXT_INFO message immediately before 134 SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The server MAY send 135 this message whether or not it sent EXT_INFO after SSH_MSG_NEWKEYS. 137 This allows a server to reveal support for additional extensions that 138 it was unwilling to reveal to an unauthenticated client. If a server 139 sends a subsequent SSH_MSG_EXT_INFO, this replaces any initial one, 140 and both the client and the server re-evaluate extensions in effect. 141 The server's last EXT_INFO is matched against the client's original. 143 2.5. Interpretation of Extension Names and Values 145 Each extension is identified by its extension-name, and defines the 146 conditions under which the extension is considered to be in effect. 147 Applications MUST ignore unrecognized extension-names. 149 In general, if an extension requires both the client and the server 150 to include it in order for the extension to take effect, the relative 151 position of the extension-name in each EXT_INFO message is irrelevant. 153 Extension-value fields are interpreted as defined by their respective 154 extension. An extension-value field MAY be empty if so permitted by 155 the extension. Applications that do not implement or recognize a 156 particular extension MUST ignore the associated extension-value field, 157 regardless of its size or content. 159 The cumulative size of an SSH_MSG_EXT_INFO message is limited only by 160 the maximum packet length that an implementation may apply in 161 accordance with [RFC4253]. Implementations MUST accept well-formed 162 SSH_MSG_EXT_INFO messages up to the maximum packet length they accept. 164 3. Initially Defined Extensions 166 3.1. "server-sig-algs" 168 This extension is sent with the following extension name and value: 170 string "server-sig-algs" 171 name-list signature-algorithms-accepted 173 Note that the name-list type is a strict subset of the string type, 174 and is thus permissible as an extension-value. 176 This extension is sent by the server only, and contains a list of 177 signature algorithms that the server is able to process as part of a 178 "publickey" request. 180 A client that wishes to proceed with public key authentication MAY 181 wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" 182 authentication request with an appropriate signature algorithm, rather 183 than resorting to trial and error. 185 Servers that implement public key authentication SHOULD implement this 186 extension. 188 If a server does not send this extension, a client SHALL NOT make any 189 assumptions about the server's signature algorithm support, and MAY 190 proceed with authentication request trial and error. 192 3.2. "no-flow-control", "accept-channels", "elevation" 194 Former versions of this document defined extensions with names 195 enumerated in this heading. These proposals are removed due to current 196 lack of implementation. Any attempt to define extensions that reuse 197 these names MUST define them in a way that is compatible with their 198 specifications in earlier draft versions of this document. Definitions 199 of similar extensions with different details MUST use different names. 201 3.3. "delay-compression" 203 This extension MAY be sent by both parties as follows: 205 string "delay-compression" 206 string: 207 name-list compression_algorithms_client_to_server 208 name-list compression_algorithms_server_to_client 210 This extension allows the server and client to renegotiate compression 211 algorithm support without having to conduct a key re-exchange, putting 212 new algorithms into effect immediately upon successful authentication. 214 This extension takes effect only if both parties send it. Name-lists 215 MAY include any compression algorithm that could have been negotiated 216 in SSH_MSG_KEXINIT, except algorithms that define their own delayed 217 compression semantics. This means "zlib,none" is a valid algorithm 218 list in this context; but "zlib@openssh.com" is not. 220 If both parties send this extension, but the name-lists do not contain 221 a common algorithm in either direction, the parties MUST disconnect in 222 the same way as if negotiation failed as part of SSH_MSG_KEXINIT. 224 If this extension takes effect, the renegotiated compression algorithm 225 is used as follows: 227 - By the server, starting with the very next SSH message after 228 SSH_MSG_USERAUTH_SUCCESS. 230 - By the client, after sending SSH_MSG_NEWCOMPRESS. If this extension 231 takes effect, the client MUST send the following message immediately 232 after receiving the server's SSH_MSG_USERAUTH_SUCCESS: 234 byte SSH_MSG_NEWCOMPRESS (value 8) 236 The purpose of this message is to avoid a race condition where the 237 server cannot reliably know whether a message sent by the client was 238 sent before or after receiving the server's USERAUTH_SUCCESS. 240 As with all extensions, the server may delay including this extension 241 until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS. 242 This allows the server to avoid advertising compression support until 243 the client has been authenticated. 245 In subsequent key re-exchange, the compression algorithms negotiated 246 in re-exchange override the algorithms negotiated with this extension. 248 4. IANA Considerations 250 4.1. Additions to existing tables 252 IANA is requested to insert the following entries into the table 253 Message Numbers under Secure Shell (SSH) Protocol Parameters 254 [RFC4250]: 256 Value Message ID Reference 257 7 SSH_MSG_EXT_INFO [this document] 258 8 SSH_MSG_NEWCOMPRESS [this document] 260 IANA is requested to insert the following entries into the table Key 261 Exchange Method Names: 263 Method Name Reference Note 264 ext-info-s [this document] Section 2.2 265 ext-info-c [this document] Section 2.2 267 4.2. New table: Extension Names 269 Also under Secure Shell (SSH) Protocol Parameters, IANA is requested 270 to create a new table, Extension Names, with initial content: 272 Extension Name Reference Note 273 server-sig-algs [this document] Section 3.1 274 delay-compression [this document] Section 3.3 276 4.2.1. Future Assignments to Extension Names 278 Names in the Extension Names table MUST follow the Conventions for 279 Names defined in [RFC4250], Section 4.6.1. 281 Requests for assignments of new non-local names in the Extension Names 282 table (i.e. names not including the '@' character) MUST be done 283 through the IETF CONSENSUS method, as described in [RFC5226]. 285 6. References 287 6.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 293 Protocol Assigned Numbers", RFC 4250, January 2006. 295 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 296 Authentication Protocol", RFC 4252, January 2006. 298 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 299 Transport Layer Protocol", RFC 4253, January 2006. 301 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 302 Connection Protocol", RFC 4254, January 2006. 304 [RFC5226] Narten, T. and Alvestrand, H., "Guidelines for Writing an 305 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 306 May 2008. 308 6.2. Informative References 310 [SSH-RSA-SHA2] 311 Bider, D., "Use of RSA Keys with SHA-2 256 and 512 in 312 Secure Shell (SSH)", draft-ietf-curdle-rsa-sha2-03.txt, 313 February 2017, . 316 Author's Address 318 Denis Bider 319 Bitvise Limited 320 Suites 41/42, Victoria House 321 26 Main Street 322 GI 324 Phone: +506 8315 6519 325 EMail: ietf-ssh3@denisbider.com 326 URI: https://www.bitvise.com/ 328 Acknowledgments 330 Thanks to Markus Friedl and Damien Miller for comments and initial 331 implementation.