idnits 2.17.1 draft-ietf-secsh-assignednumbers-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 851. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 858. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 864. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 195 has weird spacing: '... string dat...' == Line 471 has weird spacing: '... opcode argum...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 17, 2005) is 7001 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) == Missing Reference: 'Section 7' is mentioned on line 614, but not defined == Missing Reference: 'Section 8' is mentioned on line 615, but not defined == Missing Reference: 'Section 9' is mentioned on line 616, but not defined == Missing Reference: 'FIPS 46-3' is mentioned on line 736, but not defined == Unused Reference: 'FIPS-46-3' is defined on line 828, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-21 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-23 == Outdated reference: A later version (-27) exists of draft-ietf-secsh-userauth-26 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-24 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lonvick, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Expires: August 21, 2005 February 17, 2005 6 SSH Protocol Assigned Numbers 7 draft-ietf-secsh-assignednumbers-11.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 21, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document defines the instructions to the IANA and the initial 43 state of the IANA assigned numbers for the SSH protocol. It is 44 intended only for the initialization of the IANA registries 45 referenced in the documents. 47 Table of Contents 49 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Conventions Used in This Document . . . . . . . . . . . . . 4 52 3.1 RFC2119 Keywords . . . . . . . . . . . . . . . . . . . . . 4 53 3.2 RFC2434 Keywords . . . . . . . . . . . . . . . . . . . . . 4 54 3.3 Protocol Fields and Values . . . . . . . . . . . . . . . . 5 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 56 4.1 Message Numbers . . . . . . . . . . . . . . . . . . . . . 6 57 4.1.1 Conventions . . . . . . . . . . . . . . . . . . . . . 6 58 4.1.2 Initial Assignments . . . . . . . . . . . . . . . . . 7 59 4.1.3 Future Assignments . . . . . . . . . . . . . . . . . . 7 60 4.2 Disconnection Messages Reason Codes and Descriptions . . . 8 61 4.2.1 Conventions . . . . . . . . . . . . . . . . . . . . . 8 62 4.2.2 Initial Assignments . . . . . . . . . . . . . . . . . 8 63 4.2.3 Future Assignments . . . . . . . . . . . . . . . . . . 9 64 4.3 Channel Connection Failure Reason Codes and Descriptions . 9 65 4.3.1 Conventions . . . . . . . . . . . . . . . . . . . . . 9 66 4.3.2 Initial Assignments . . . . . . . . . . . . . . . . . 9 67 4.3.3 Future Assignments . . . . . . . . . . . . . . . . . . 9 68 4.3.4 Notes about the PRIVATE USE Range . . . . . . . . . . 10 69 4.4 Extended Channel Data Transfer data_type_code and Data . . 10 70 4.4.1 Conventions . . . . . . . . . . . . . . . . . . . . . 10 71 4.4.2 Initial Assignments . . . . . . . . . . . . . . . . . 10 72 4.4.3 Future Assignments . . . . . . . . . . . . . . . . . . 11 73 4.5 Pseudo-Terminal Encoded Terminal Modes . . . . . . . . . . 11 74 4.5.1 Conventions . . . . . . . . . . . . . . . . . . . . . 11 75 4.5.2 Initial Assignments . . . . . . . . . . . . . . . . . 11 76 4.5.3 Future Assignments . . . . . . . . . . . . . . . . . . 13 77 4.6 Names . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.6.1 Conventions for Names . . . . . . . . . . . . . . . . 13 79 4.6.2 Future Assignments of Names . . . . . . . . . . . . . 14 80 4.7 Service Names . . . . . . . . . . . . . . . . . . . . . . 14 81 4.8 Authentication Method Names . . . . . . . . . . . . . . . 14 82 4.9 Connection Protocol Assigned Names . . . . . . . . . . . . 14 83 4.9.1 Connection Protocol Channel Types . . . . . . . . . . 15 84 4.9.2 Connection Protocol Global Request Names . . . . . . . 15 85 4.9.3 Connection Protocol Channel Request Names . . . . . . 15 86 4.9.4 Initial Assignment of Signal Names . . . . . . . . . . 16 87 4.9.5 Connection Protocol Subsystem Names . . . . . . . . . 16 88 4.10 Key Exchange Method Names . . . . . . . . . . . . . . . 16 89 4.11 Assigned Algorithm Names . . . . . . . . . . . . . . . . 17 90 4.11.1 Encryption Algorithm Names . . . . . . . . . . . . . 17 91 4.11.2 MAC Algorithm Names . . . . . . . . . . . . . . . . 17 92 4.11.3 Public Key Algorithm Names . . . . . . . . . . . . . 17 93 4.11.4 Compression Algorithm Names . . . . . . . . . . . . 18 94 5. Security Considerations . . . . . . . . . . . . . . . . . . 18 95 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 6.1 Normative References . . . . . . . . . . . . . . . . . . . 18 97 6.2 Informative References . . . . . . . . . . . . . . . . . . 19 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 99 Intellectual Property and Copyright Statements . . . . . . . 20 101 1. Contributors 103 The major original contributors of this set of documents have been: 104 Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH 105 Communications Security Corp), and Markku-Juhani O. Saarinen 106 (University of Jyvaskyla). Darren Moffit was the original editor of 107 this set of documents and also made very substantial contributions. 109 Additional contributors to this document include [need list]. 110 Listing their names here does not mean that they endorse this 111 document, but that they have contributed to it. 113 Comments on this internet draft should be sent to the IETF SECSH 114 working group, details at: 115 http://ietf.org/html.charters/secsh-charter.html Note: This paragraph 116 will be removed before this document progresses to become an RFC. 118 2. Introduction 120 This document does not define any new protocols. It is intended only 121 to create the initial state of the IANA databases for the SSH 122 protocol and also contains instructions for future assignments. 123 Except for one HISTORIC algorithm generally regarded as obsolete, 124 this document does not define any new protocols or any number ranges 125 not already defined in: [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], 126 [SSH-CONNECT]. 128 3. Conventions Used in This Document 130 3.1 RFC2119 Keywords 132 All documents related to the SSH protocols shall use the keywords 133 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 134 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe 135 requirements. These keywords are to be interpreted as described in 136 [RFC2119]. 138 3.2 RFC2434 Keywords 140 The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 141 FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 142 APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 143 this document when used to describe namespace allocation are to be 144 interpreted as described in [RFC2434]. These designations are 145 repeated in this document for clarity. 147 PRIVATE USE - For private or local use only, with the type and 148 purpose defined by the local site. No attempt is made to prevent 149 multiple sites from using the same value in different (and 150 incompatible) ways. There is no need for IANA to review such 151 assignments and assignments are not generally useful for 152 interoperability. 154 HIERARCHICAL ALLOCATION - Delegated managers can assign values 155 provided they have been given control over that part of the name 156 space. IANA controls the higher levels of the namespace according to 157 one of the other policies. 159 FIRST COME FIRST SERVED - Anyone can obtain an assigned number, so 160 long as they provide a point of contact and a brief description of 161 what the value would be used for. For numbers, the exact value is 162 generally assigned by the IANA; with names, specific names are 163 usually requested. 165 EXPERT REVIEW - approval by a Designated Expert is required. 167 SPECIFICATION REQUIRED - Values and their meaning must be documented 168 in an RFC or other permanent and readily available reference, in 169 sufficient detail so that interoperability between independent 170 implementations is possible. 172 IESG APPROVAL - New assignments must be approved by the IESG, but 173 there is no requirement that the request be documented in an RFC 174 (though the IESG has discretion to request documents or other 175 supporting materials on a case-by-case basis). 177 IETF CONSENSUS - New values are assigned through the IETF consensus 178 process. Specifically, new assignments are made via RFCs approved by 179 the IESG. Typically, the IESG will seek input on prospective 180 assignments from appropriate persons (e.g., a relevant Working Group 181 if one exists). 183 STANDARDS ACTION - Values are assigned only for Standards Track RFCs 184 approved by the IESG. 186 3.3 Protocol Fields and Values 188 Protocol fields and possible values to fill them are defined in this 189 set of documents. Protocol fields will be defined in the message 190 definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as 191 follows. 193 byte SSH_MSG_CHANNEL_DATA 194 uint32 recipient channel 195 string data 197 Throughout these documents, when the fields are referenced, they will 198 appear within single quotes. When values to fill those fields are 199 referenced, they will appear within double quotes. Using the above 200 example, possible values for 'data' are "foo" and "bar". 202 4. IANA Considerations 204 This entire document is the IANA considerations for the SSH protocol 205 as is defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], 206 [SSH-CONNECT]. This section contains conventions used in naming the 207 namespaces, the initial state of the registry, and instructions for 208 future assignments. 210 4.1 Message Numbers 212 The Message Number is a byte value, which describes the payload of a 213 packet. 215 4.1.1 Conventions 217 Protocol packets have message numbers in the range 1 to 255. These 218 numbers are allocated as follows: 220 Transport layer protocol: 222 1 to 19 Transport layer generic (e.g., disconnect, ignore, 223 debug, etc.) 224 20 to 29 Algorithm negotiation 225 30 to 49 Key exchange method specific (numbers can be reused 226 for different authentication methods) 228 User authentication protocol: 230 50 to 59 User authentication generic 231 60 to 79 User authentication method specific (numbers can be 232 reused for different authentication methods) 234 Connection protocol: 236 80 to 89 Connection protocol generic 237 90 to 127 Channel related messages 239 Reserved for client protocols: 241 128 to 191 Reserved 243 Local extensions: 245 192 to 255 Local extensions 247 4.1.2 Initial Assignments 249 The following table identifies the initial assignments of the Message 250 ID values. 252 Message ID Value Reference 253 ----------- ----- --------- 254 SSH_MSG_DISCONNECT 1 [SSH-TRANS] 255 SSH_MSG_IGNORE 2 [SSH-TRANS] 256 SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS] 257 SSH_MSG_DEBUG 4 [SSH-TRANS] 258 SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS] 259 SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS] 260 SSH_MSG_KEXINIT 20 [SSH-TRANS] 261 SSH_MSG_NEWKEYS 21 [SSH-TRANS] 262 SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH] 263 SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH] 264 SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH] 265 SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH] 266 SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT] 267 SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT] 268 SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT] 269 SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT] 270 SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT] 271 SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT] 272 SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT] 273 SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT] 274 SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT] 275 SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT] 276 SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT] 277 SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT] 278 SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT] 279 SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT] 281 4.1.3 Future Assignments 283 Requests for assignments of new message numbers in the range of 1 to 284 29, 50 to 59, and 80 to 127 MUST be done through the STANDARDS ACTION 285 method as described in [RFC2434]. 287 The meanings of message numbers in the range of 30 to 49 are specific 288 to the key exchange method in use, and their meaning will be 289 specified by the definition of that method. 291 The meanings of message numbers in the range of 60 to 79 are specific 292 to the user authentication method in use, and their meaning will be 293 specified by the definition of that method. 295 Requests for assignments of new message numbers in the range of 128 296 to 191 MUST be done through the IETF CONSENSUS method as described in 297 [RFC2434]. 299 The IANA will not control the message numbers range of 192 through 300 255. This range will be left for PRIVATE USE. 302 4.2 Disconnection Messages Reason Codes and Descriptions 304 The Disconnection Message 'reason code' is a uint32 value. The 305 associated Disconnection Message 'description' is a human-readable 306 message which describes the disconnect reason. 308 4.2.1 Conventions 310 Protocol packets containing the SSH_MSG_DISCONNECT message MUST have 311 Disconnection Message 'reason code' values in the range of 0x00000001 312 to 0xFFFFFFFF. These are described in [SSH-TRANS]. 314 4.2.2 Initial Assignments 316 The following table identifies the initial assignments of the 317 SSH_MSG_DISCONNECT 'description' and 'reason code' values. 319 Symbolic Name reason code 320 ------------- ----------- 321 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 322 SSH_DISCONNECT_PROTOCOL_ERROR 2 323 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 324 SSH_DISCONNECT_RESERVED 4 325 SSH_DISCONNECT_MAC_ERROR 5 326 SSH_DISCONNECT_COMPRESSION_ERROR 6 327 SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 328 SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 329 SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 330 SSH_DISCONNECT_CONNECTION_LOST 10 331 SSH_DISCONNECT_BY_APPLICATION 11 332 SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 333 SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 334 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 335 SSH_DISCONNECT_ILLEGAL_USER_NAME 15 337 4.2.3 Future Assignments 339 Disconnection Message 'reason code' values MUST be assigned 340 sequentially. Requests for assignments of new Disconnection Message 341 'reason code' values, and their associated Disconnection Message 342 'description' text, in the range of 0x00000010 through 0xFDFFFFFF 343 MUST be done through the IETF CONSENSUS method as described in 344 [RFC2434]. The IANA will not assign Disconnection Message 'reason 345 code' values in the range of 0xFE000000 through 0xFFFFFFFF. 346 Disconnection Message 'reason code' values in that range are left for 347 PRIVATE USE as described in [RFC2434]. 349 4.3 Channel Connection Failure Reason Codes and Descriptions 351 The Channel Connection Failure 'reason code' is a uint32 value. The 352 associated Channel Connection Failure 'description' text is a 353 human-readable message which describes the channel connection failure 354 reason. This is described in [SSH-CONNECT]. 356 4.3.1 Conventions 358 Protocol packets containing the SSH_MSG_CHANNEL_OPEN_FAILURE message 359 MUST have Channel Connection Failure 'reason code' values in the 360 range of 0x00000001 to 0xFFFFFFFF. 362 4.3.2 Initial Assignments 364 The initial assignments for the 'reason code' values and 365 'description' values are given in the table below. Note that the 366 values for the 'reason code' are given in decimal format for 367 readability but that they are actually uint32 values. 369 Symbolic Name reason code 370 ------------- ----------- 371 SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 372 SSH_OPEN_CONNECT_FAILED 2 373 SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 374 SSH_OPEN_RESOURCE_SHORTAGE 4 376 4.3.3 Future Assignments 378 Channel Connection Failure 'reason code' values MUST be assigned 379 sequentially. Requests for assignments of new Channel Connection 380 Failure 'reason code' values, and their associated Channel Connection 381 Failure 'description string', in the range of 0x00000005 to 382 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as 383 described in [RFC2434]. The IANA will not assign Channel Connection 384 Failure 'reason code' values in the range of 0xFE000000 to 385 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that 386 range are left for PRIVATE USE as described in [RFC2434]. 388 4.3.4 Notes about the PRIVATE USE Range 390 While it is understood that the IANA will have no control over the 391 range of 0xFE000000 to 0xFFFFFFFF, this range will be split in two 392 parts and administered by the following conventions. 393 o The range of 0xFE000000 to 0xFEFFFFFF is to be used in conjunction 394 with locally assigned channels. For example: if a channel is 395 proposed with a 'channel type' of "example_session@example.com" 396 but fails, then the server will respond with either a 'reason 397 code' assigned by the IANA (as listed above and in the range of 398 0x00000001 to 0xFDFFFFFF), or with a locally assigned value in the 399 range of 0xFE000000 to 0xFEFFFFFF. Naturally, if the server does 400 not understand the proposed 'channel type', even if it is a 401 locally defined 'channel type', then the 'reason code' MUST be 402 0x00000003 as described above. If the server does understand the 403 'channel type' but the channel still fails to open, then the 404 server SHOULD respond with a locally assigned 'reason code' value 405 consistent with the proposed, local 'channel type'. It is assumed 406 that practitioners will first attempt to use the IANA assigned 407 'reason code' values and then document their locally assigned 408 'reason code' values. 409 o There are no restrictions or suggestions for the range starting 410 with 0xFF. No interoperability is expected for anything used in 411 this range. Essentially it is for experimentation. 413 4.4 Extended Channel Data Transfer data_type_code and Data 415 The Extended Channel Data Transfer 'data_type_code' is an uint23 416 value. The associated Extended Channel Data Transfer 'data' is a 417 human-readable message which describes the type of data allowed to be 418 transferred in the channel. 420 4.4.1 Conventions 422 Protocol packets containing the SSH_MSG_CHANNEL_EXTENDED_DATA message 423 MUST have Extended Channel Data Transfer 'data_type_code' values in 424 the range of 0x00000001 to 0xFFFFFFFF. This is described in 425 [SSH-CONNECT]. 427 4.4.2 Initial Assignments 429 The initial assignments for the 'data_type_code' values and 'data' 430 values are given in the table below. Note that the value for the 431 'data_type_code' is given in decimal format for readability but that 432 the values are actually uint32 values. 434 Symbolic name data_type_code 435 ------------- -------------- 436 SSH_EXTENDED_DATA_STDERR 1 438 4.4.3 Future Assignments 440 Extended Channel Data Transfer 'data_type_code' values MUST be 441 assigned sequentially. Requests for assignments of new Extended 442 Channel Data Transfer 'data_type_code' values, and their associated 443 Extended Channel Data Transfer 'data' strings, in the range of 444 0x00000002 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS 445 method as described in [RFC2434]. The IANA will not assign Extended 446 Channel Data Transfer 'data_type_code' values in the range of 447 0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer 448 'data_type_code' values in that range are left for PRIVATE USE as 449 described in [RFC2434]. 451 4.5 Pseudo-Terminal Encoded Terminal Modes 453 SSH_MSG_CHANNEL_REQUEST messages with a "pty-req" string MUST contain 454 "encoded terminal modes". These "encoded terminal modes" are 455 opcode-argument pairs consisting of an opcode and an argument. 457 4.5.1 Conventions 459 Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with 460 a "pty-req" string MUST contain "encoded terminal modes" with an 461 opcode of 1 byte. The opcode values are in the range of 1 to 255. 462 Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 463 are not yet defined. 465 4.5.2 Initial Assignments 467 The following table identifies the initial assignments of the opcode 468 and argument values which make up the "encoded terminal modes" 469 values. 471 opcode argument description 472 ------ -------- ----------- 473 0 TTY_OP_END Indicates end of options. 474 1 VINTR Interrupt character; 255 if none. Similarly 475 for the other characters. Not all of these 476 characters are supported on all systems. 477 2 VQUIT The quit character (sends SIGQUIT signal on 478 POSIX systems). 480 3 VERASE Erase the character to left of the cursor. 481 4 VKILL Kill the current input line. 482 5 VEOF End-of-file character (sends EOF from the 483 terminal). 484 6 VEOL End-of-line character in addition to 485 carriage return and/or linefeed. 486 7 VEOL2 Additional end-of-line character. 487 8 VSTART Continues paused output (normally 488 control-Q). 489 9 VSTOP Pauses output (normally control-S). 490 10 VSUSP Suspends the current program. 491 11 VDSUSP Another suspend character. 492 12 VREPRINT Reprints the current input line. 493 13 VWERASE Erases a word left of cursor. 494 14 VLNEXT Enter the next character typed literally, 495 even if it is a special character 496 15 VFLUSH Character to flush output. 497 16 VSWTCH Switch to a different shell layer. 498 17 VSTATUS Prints system status line (load, command, 499 pid, etc). 500 18 VDISCARD Toggles the flushing of terminal output. 501 30 IGNPAR The ignore parity flag. The parameter 502 SHOULD be 0 if this flag is FALSE, 503 and 1 if it is TRUE. 504 31 PARMRK Mark parity and framing errors. 505 32 INPCK Enable checking of parity errors. 506 33 ISTRIP Strip 8th bit off characters. 507 34 INLCR Map NL into CR on input. 508 35 IGNCR Ignore CR on input. 509 36 ICRNL Map CR to NL on input. 510 37 IUCLC Translate uppercase characters to 511 lowercase. 512 38 IXON Enable output flow control. 513 39 IXANY Any char will restart after stop. 514 40 IXOFF Enable input flow control. 515 41 IMAXBEL Ring bell on input queue full. 516 50 ISIG Enable signals INTR, QUIT, [D]SUSP. 517 51 ICANON Canonicalize input lines. 518 52 XCASE Enable input and output of uppercase 519 characters by preceding their lowercase 520 equivalents with "\". 521 53 ECHO Enable echoing. 522 54 ECHOE Visually erase chars. 523 55 ECHOK Kill character discards current line. 524 56 ECHONL Echo NL even if ECHO is off. 525 57 NOFLSH Don't flush after interrupt. 526 58 TOSTOP Stop background jobs from output. 527 59 IEXTEN Enable extensions. 529 60 ECHOCTL Echo control characters as ^(Char). 530 61 ECHOKE Visual erase for line kill. 531 62 PENDIN Retype pending input. 532 70 OPOST Enable output processing. 533 71 OLCUC Convert lowercase to uppercase. 534 72 ONLCR Map NL to CR-NL. 535 73 OCRNL Translate carriage return to newline 536 (output). 537 74 ONOCR Translate newline to carriage 538 return-newline (output). 539 75 ONLRET Newline performs a carriage return 540 (output). 541 90 CS7 7 bit mode. 542 91 CS8 8 bit mode. 543 92 PARENB Parity enable. 544 93 PARODD Odd parity, else even. 546 128 TTY_OP_ISPEED Specifies the input baud rate in 547 bits per second. 548 129 TTY_OP_OSPEED Specifies the output baud rate in 549 bits per second. 551 4.5.3 Future Assignments 553 Requests for assignments of new opcodes and their associated 554 arguments MUST be done through the IETF CONSENSUS method as described 555 in [RFC2434]. 557 4.6 Names 559 In the following sections, the values for the name spaces are 560 textual. The conventions and instructions to the IANA for future 561 assignments are given in this section. The initial assignments are 562 given in their respective sections. 564 4.6.1 Conventions for Names 566 All names registered by the IANA in the following sections MUST be 567 printable US-ASCII strings, and MUST NOT contain the characters 568 at-sign ("@"), comma (","), or whitespace or control characters 569 (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be 570 longer than 64 characters. 572 A provision is made here for locally extensible names. The IANA will 573 not register, and will not control names with the at-sign in them. 574 Names with the at-sign in them will have the format of 575 "name@domainname" (without the double quotes) where the part 576 preceeding the at-sign is the name. The format of the part preceding 577 the at-sign is not specified, however these names MUST be printable 578 US-ASCII strings, and MUST NOT contain the comma character (","), or 579 whitespace, or control characters (ASCII codes 32 or less). The part 580 following the at-sign MUST be a valid, fully qualified internet 581 domain name [RFC1034] controlled by the person or organization 582 defining the name. Names are case-sensitive, and MUST NOT be longer 583 than 64 characters. It is up to each domain how it manages its local 584 namespace. It has been noted that these names resemble STD 11 585 [RFC0822] email addresses. This is purely coincidental and actually 586 has nothing to do with STD 11 [RFC0822]. An example of a locally 587 defined name is "ourcipher-cbc@example.com" (without the double 588 quotes). 590 4.6.2 Future Assignments of Names 592 Requests for assignments of new Names MUST be done through the IETF 593 CONSENSUS method as described in [RFC2434]. 595 4.7 Service Names 597 The Service Name is used to describe a protocol layer. The following 598 table lists the initial assignments of the Service Names. 600 Service Name Reference 601 ------------- --------- 602 ssh-userauth [SSH-USERAUTH] 603 ssh-connection [SSH-CONNECT] 605 4.8 Authentication Method Names 607 The Authentication Method Name is used to describe an authentication 608 method for the "ssh-userauth" service [SSH-USERAUTH]. The following 609 table identifies the initial assignments of the Authentication Method 610 Names. 612 Method Name Reference 613 ------------ --------- 614 publickey [SSH-USERAUTH, Section 7] 615 password [SSH-USERAUTH, Section 8] 616 hostbased [SSH-USERAUTH, Section 9] 617 none [SSH-USERAUTH, Section 5.2] 619 4.9 Connection Protocol Assigned Names 621 The following table lists the initial assignments of the Connection 622 Protocol Type and Request names. 624 4.9.1 Connection Protocol Channel Types 626 The following table lists the initial assignments of the Connection 627 Protocol Channel Types. 629 Channel type Reference 630 ------------ --------- 631 session [SSH-CONNECT, Section 6.1] 632 x11 [SSH-CONNECT, Section 6.3.2] 633 forwarded-tcpip [SSH-CONNECT, Section 7.2] 634 direct-tcpip [SSH-CONNECT, Section 7.2] 636 4.9.2 Connection Protocol Global Request Names 638 The following table lists the initial assignments of the Connection 639 Protocol Global Request Names. 641 Request type Reference 642 ------------ --------- 643 tcpip-forward [SSH-CONNECT, Section 7.1] 644 cancel-tcpip-forward [SSH-CONNECT, Section 7.1] 646 4.9.3 Connection Protocol Channel Request Names 648 The following table lists the initial assignments of the Connection 649 Protocol Channel Request Names. 651 Request type Reference 652 ------------ --------- 653 pty-req [SSH-CONNECT, Section 6.2] 654 x11-req [SSH-CONNECT, Section 6.3.1] 655 env [SSH-CONNECT, Section 6.4] 656 shell [SSH-CONNECT, Section 6.5] 657 exec [SSH-CONNECT, Section 6.5] 658 subsystem [SSH-CONNECT, Section 6.5] 659 window-change [SSH-CONNECT, Section 6.7] 660 xon-xoff [SSH-CONNECT, Section 6.8] 661 signal [SSH-CONNECT, Section 6.9] 662 exit-status [SSH-CONNECT, Section 6.10] 663 exit-signal [SSH-CONNECT, Section 6.10] 665 4.9.4 Initial Assignment of Signal Names 667 The following table lists the initial assignments of the Signal 668 Names. 670 Signal Reference 671 ------ --------- 672 ABRT [SSH-CONNECT] 673 ALRM [SSH-CONNECT] 674 FPE [SSH-CONNECT] 675 HUP [SSH-CONNECT] 676 ILL [SSH-CONNECT] 677 INT [SSH-CONNECT] 678 KILL [SSH-CONNECT] 679 PIPE [SSH-CONNECT] 680 QUIT [SSH-CONNECT] 681 SEGV [SSH-CONNECT] 682 TERM [SSH-CONNECT] 683 USR1 [SSH-CONNECT] 684 USR2 [SSH-CONNECT] 686 4.9.5 Connection Protocol Subsystem Names 688 There are no initial assignments of Connection Protocol Subsystem 689 Names. 691 4.10 Key Exchange Method Names 693 The name "diffie-hellman-group1-sha1" is used for a key exchange 694 method using an Oakley group as defined in [RFC2409]. SSH maintains 695 its own group identifier space which is logically distinct from 696 Oakley [RFC2412] and IKE; however, for one additional group, the 697 Working Group adopted the number assigned by [RFC3526], using 698 diffie-hellman-group14-sha1 for the name of the second defined group. 699 Implementations should treat these names as opaque identifiers and 700 should not assume any relationship between the groups used by SSH and 701 the groups defined for IKE. 703 The following table identifies the initial assignments of the 704 key-exchange methods. 706 Method name Reference 707 ------------ --------- 708 diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1] 709 diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2] 711 4.11 Assigned Algorithm Names 713 4.11.1 Encryption Algorithm Names 715 The following table identifies the initial assignment of the 716 Encryption Algorithm Names. 718 Encryption Algorithm Name Reference 719 ------------------------- --------- 720 3des-cbc [SSH-TRANS, Section 6.3] 721 blowfish-cbc [SSH-TRANS, Section 6.3] 722 twofish256-cbc [SSH-TRANS, Section 6.3] 723 twofish-cbc [SSH-TRANS, Section 6.3] 724 twofish192-cbc [SSH-TRANS, Section 6.3] 725 twofish128-cbc [SSH-TRANS, Section 6.3] 726 aes256-cbc [SSH-TRANS, Section 6.3] 727 aes192-cbc [SSH-TRANS, Section 6.3] 728 aes128-cbc [SSH-TRANS, Section 6.3] 729 serpent256-cbc [SSH-TRANS, Section 6.3] 730 serpent192-cbc [SSH-TRANS, Section 6.3] 731 serpent128-cbc [SSH-TRANS, Section 6.3] 732 arcfour [SSH-TRANS, Section 6.3] 733 idea-cbc [SSH-TRANS, Section 6.3] 734 cast128-cbc [SSH-TRANS, Section 6.3] 735 none [SSH-TRANS, Section 6.3] 736 of [FIPS 46-3] 738 4.11.2 MAC Algorithm Names 740 The following table identifies the initial assignments of the MAC 741 Algorithm Names. 743 MAC Algorithm Name Reference 744 ------------------ --------- 745 hmac-sha1 [SSH-TRANS, Section 6.4] 746 hmac-sha1-96 [SSH-TRANS, Section 6.4] 747 hmac-md5 [SSH-TRANS, Section 6.4] 748 hmac-md5-96 [SSH-TRANS, Section 6.4] 749 none [SSH-TRANS, Section 6.4] 751 4.11.3 Public Key Algorithm Names 753 The following table identifies the initial assignments of the Public 754 Key Algorithm names. 756 Public Key Algorithm Name Reference 757 ------------------------- --------- 758 ssh-dss [SSH-TRANS, Section 6.6] 759 ssh-rsa [SSH-TRANS, Section 6.6] 760 spki-sign-rsa [SSH-TRANS, Section 6.6] 761 spki-sign-dss [SSH-TRANS, Section 6.6] 762 pgp-sign-rsa [SSH-TRANS, Section 6.6] 763 pgp-sign-dss [SSH-TRANS, Section 6.6] 765 4.11.4 Compression Algorithm Names 767 The following table identifies the initial assignments of the 768 Compression Algorithm names. 770 Compression Algorithm Name Reference 771 -------------------------- --------- 772 none [SSH-TRANS, Section 6.2] 773 zlib [SSH-TRANS, Section 6.2] 775 5. Security Considerations 777 This protocol provides a secure encrypted channel over an insecure 778 network. 780 Full security considerations for this protocol are provided in 781 [SSH-ARCH]. 783 6. References 785 6.1 Normative References 787 [SSH-ARCH] 788 Lonvick, C., "SSH Protocol Architecture", 789 I-D draft-ietf-secsh-architecture-21.txt, February 2005. 791 [SSH-TRANS] 792 Lonvick, C., "SSH Transport Layer Protocol", 793 I-D draft-ietf-secsh-transport-23.txt, February 2005. 795 [SSH-USERAUTH] 796 Lonvick, C., "SSH Authentication Protocol", 797 I-D draft-ietf-secsh-userauth-26.txt, February 2005. 799 [SSH-CONNECT] 800 Lonvick, C., "SSH Connection Protocol", 801 I-D draft-ietf-secsh-connect-24.txt, February 2005. 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, March 1997. 806 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 807 (IKE)", RFC 2409, November 1998. 809 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 810 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 811 October 1998. 813 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 814 Diffie-Hellman groups for Internet Key Exchange (IKE)", 815 RFC 3526, May 2003. 817 6.2 Informative References 819 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 820 text messages", STD 11, RFC 822, August 1982. 822 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 823 STD 13, RFC 1034, November 1987. 825 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 826 RFC 2412, November 1998. 828 [FIPS-46-3] 829 U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption 830 Standard (DES)", October 1999. 832 Author's Address 834 Chris Lonvick (editor) 835 Cisco Systems, Inc. 836 12515 Research Blvd. 837 Austin 78759 838 USA 840 Email: clonvick@cisco.com 842 Intellectual Property Statement 844 The IETF takes no position regarding the validity or scope of any 845 Intellectual Property Rights or other rights that might be claimed to 846 pertain to the implementation or use of the technology described in 847 this document or the extent to which any license under such rights 848 might or might not be available; nor does it represent that it has 849 made any independent effort to identify any such rights. Information 850 on the procedures with respect to rights in RFC documents can be 851 found in BCP 78 and BCP 79. 853 Copies of IPR disclosures made to the IETF Secretariat and any 854 assurances of licenses to be made available, or the result of an 855 attempt made to obtain a general license or permission for the use of 856 such proprietary rights by implementers or users of this 857 specification can be obtained from the IETF on-line IPR repository at 858 http://www.ietf.org/ipr. 860 The IETF invites any interested party to bring to its attention any 861 copyrights, patents or patent applications, or other proprietary 862 rights that may cover technology that may be required to implement 863 this standard. Please address the information to the IETF at 864 ietf-ipr@ietf.org. 866 The IETF has been notified of intellectual property rights claimed in 867 regard to some or all of the specification contained in this 868 document. For more information consult the online list of claimed 869 rights. 871 Disclaimer of Validity 873 This document and the information contained herein are provided on an 874 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 875 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 876 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 877 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 878 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 879 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 881 Copyright Statement 883 Copyright (C) The Internet Society (2005). This document is subject 884 to the rights, licenses and restrictions contained in BCP 78, and 885 except as set forth therein, the authors retain all their rights. 887 Acknowledgment 889 Funding for the RFC Editor function is currently provided by the 890 Internet Society.