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