idnits 2.17.1 draft-ietf-secsh-assignednumbers-08.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 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 780. ** 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 424 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 18, 2004) is 7091 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 4' is mentioned on line 563, but not defined == Missing Reference: 'Section 5' is mentioned on line 564, but not defined == Missing Reference: 'Section 6' is mentioned on line 565, but not defined == Missing Reference: 'FIPS 46-3' is mentioned on line 662, but not defined == Unused Reference: 'FIPS-46-3' is defined on line 744, 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 19, 2005 November 18, 2004 5 SSH Protocol Assigned Numbers 6 draft-ietf-secsh-assignednumbers-08.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 19, 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. Editor's Note . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 8 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 . . 9 66 4.4.1 Conventions . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 10 71 4.5.2 Initial Assignments . . . . . . . . . . . . . . . . . 10 72 4.5.3 Future Assignments . . . . . . . . . . . . . . . . . . 12 73 4.6 Names . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.6.1 Conventions for Names . . . . . . . . . . . . . . . . 12 75 4.6.2 Future Assignments of Names . . . . . . . . . . . . . 13 76 4.7 Service Names . . . . . . . . . . . . . . . . . . . . . . 13 77 4.8 Authentication Method Names . . . . . . . . . . . . . . . 13 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 . . . . . . 14 82 4.9.4 Initial Assignment of Signal Names . . . . . . . . . . 14 83 4.10 Key Exchange Method Names . . . . . . . . . . . . . . . 15 84 4.11 Assigned Algorithm Names . . . . . . . . . . . . . . . . 15 85 4.11.1 Encryption Algorithm Names . . . . . . . . . . . . . 15 86 4.11.2 MAC Algorithm Names . . . . . . . . . . . . . . . . 16 87 4.11.3 Public Key Algorithm Names . . . . . . . . . . . . . 16 88 4.11.4 Compression Algorithm Names . . . . . . . . . . . . 16 89 5. Security Considerations . . . . . . . . . . . . . . . . . . 16 90 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 92 6.2 Informative References . . . . . . . . . . . . . . . . . . . 17 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 94 Intellectual Property and Copyright Statements . . . . . . . 19 96 1. Editor's Note 98 The references in this document are statically defined. However, the 99 locations of the referenced materials are dynamic and are changing 100 with the whims of the Working Group. Please do not comment to the 101 editor or the Working Group about inaccuracies along those lines in 102 this document at this time. (This paragraph will be removed before 103 this document is submitted to the RFC Editor.) 105 2. Introduction 107 This document does not define any new protocols. It is intended only 108 to create the initial state of the IANA databases for the SSH 109 protocol and also contains instructions for future assignments. 110 Except for one HISTORIC algorithm generally regarded as obsolete, 111 this document does not define any new protocols or any number ranges 112 not already defined in: [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], 113 [SSH-CONNECT]. 115 3. Conventions Used in This Document 117 All documents related to the SSH protocols shall use the keywords 118 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 119 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe 120 requirements. These keywords are to be interpreted as described in 121 [RFC2119]. 123 The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 124 FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 125 APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 126 this document when used to describe namespace allocation are to be 127 interpreted as described in [RFC2434]. These designations are 128 repeated in this document for clarity. 130 PRIVATE USE - For private or local use only, with the type and 131 purpose defined by the local site. No attempt is made to prevent 132 multiple sites from using the same value in different (and 133 incompatible) ways. There is no need for IANA to review such 134 assignments and assignments are not generally useful for 135 interoperability. 137 HIERARCHICAL ALLOCATION - Delegated managers can assign values 138 provided they have been given control over that part of the name 139 space. IANA controls the higher levels of the namespace according to 140 one of the other policies. 142 FIRST COME FIRST SERVED - Anyone can obtain an assigned number, so 143 long as they provide a point of contact and a brief description of 144 what the value would be used for. For numbers, the exact value is 145 generally assigned by the IANA; with names, specific names are 146 usually requested. 148 EXPERT REVIEW - approval by a Designated Expert is required. 150 SPECIFICATION REQUIRED - Values and their meaning must be documented 151 in an RFC or other permanent and readily available reference, in 152 sufficient detail so that interoperability between independent 153 implementations is possible. 155 IESG APPROVAL - New assignments must be approved by the IESG, but 156 there is no requirement that the request be documented in an RFC 157 (though the IESG has discretion to request documents or other 158 supporting materials on a case-by-case basis). 160 IETF CONSENSUS - New values are assigned through the IETF consensus 161 process. Specifically, new assignments are made via RFCs approved by 162 the IESG. Typically, the IESG will seek input on prospective 163 assignments from appropriate persons (e.g., a relevant Working Group 164 if one exists). 166 STANDARDS ACTION - Values are assigned only for Standards Track RFCs 167 approved by the IESG. 169 4. IANA Considerations 171 This entire document is the IANA considerations for the SSH protocol 172 as is defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], 173 [SSH-CONNECT]. This section contains conventions used in naming the 174 namespaces, the initial state of the registry, and instructions for 175 future assignments. 177 4.1 Message Numbers 179 The Message Number is an 8-bit value, which describes the payload of 180 a packet. 182 4.1.1 Conventions 184 Protocol packets have message numbers in the range 1 to 255. These 185 numbers are allocated as follows: 187 Transport layer protocol: 189 1 to 19 Transport layer generic (e.g. disconnect, ignore, 190 debug, etc.) 192 20 to 29 Algorithm negotiation 193 30 to 49 Key exchange method specific (numbers can be reused 194 for different authentication methods) 196 User authentication protocol: 198 50 to 59 User authentication generic 199 60 to 79 User authentication method specific (numbers can be 200 reused for different authentication methods) 202 Connection protocol: 204 80 to 89 Connection protocol generic 205 90 to 127 Channel related messages 207 Reserved for client protocols: 209 128 to 191 Reserved 211 Local extensions: 213 192 to 255 Local extensions 215 4.1.2 Initial Assignments 217 Message ID Value Reference 218 ----------- ----- --------- 219 SSH_MSG_DISCONNECT 1 [SSH-TRANS] 220 SSH_MSG_IGNORE 2 [SSH-TRANS] 221 SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS] 222 SSH_MSG_DEBUG 4 [SSH-TRANS] 223 SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS] 224 SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS] 225 SSH_MSG_KEXINIT 20 [SSH-TRANS] 226 SSH_MSG_NEWKEYS 21 [SSH-TRANS] 227 SSH_MSG_KEXDH_INIT 30 [SSH-TRANS] 228 SSH_MSG_KEXDH_REPLY 31 [SSH-TRANS] 229 SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH] 230 SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH] 231 SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH] 232 SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH] 233 SSH_MSG_USERAUTH_PK_OK 60 [SSH-USERAUTH] 234 SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT] 235 SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT] 236 SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT] 237 SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT] 238 SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT] 239 SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT] 240 SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT] 241 SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT] 242 SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT] 243 SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT] 244 SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT] 245 SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT] 246 SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT] 247 SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT] 249 4.1.3 Future Assignments 251 Requests for assignments of new message numbers in the range of 1 to 252 127 MUST be done through the STANDARDS ACTION method as described in 253 [RFC2434]. 255 Requests for assigments of new message numbers in the range of 128 to 256 191 MUST be done through the IETF CONSENSUS method as described in 257 [RFC2434]. 259 The IANA will not control the message numbers range of 192 through 260 255. This range will be left for PRIVATE USE. 262 4.2 Disconnection Messages Reason Codes and Descriptions 264 The Disconnection Message 'reason code' is a uint32 value. The 265 associated Disconnection Message 'description string' is a 266 human-readable message which describes the disconnect reason. 268 4.2.1 Conventions 270 Protocol packets containing the SSH_MSG_DISCONNECT message MUST have 271 Disconnection Message 'reason code' values in the range of 0x00000001 272 to 0xFFFFFFFF. These are described in [SSH-TRANS]. 274 4.2.2 Initial Assignments 276 description string reason code 277 ------------------ ----------- 278 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 279 SSH_DISCONNECT_PROTOCOL_ERROR 2 280 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 281 SSH_DISCONNECT_RESERVED 4 282 SSH_DISCONNECT_MAC_ERROR 5 283 SSH_DISCONNECT_COMPRESSION_ERROR 6 284 SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 285 SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 286 SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 287 SSH_DISCONNECT_CONNECTION_LOST 10 288 SSH_DISCONNECT_BY_APPLICATION 11 289 SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 290 SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 291 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 292 SSH_DISCONNECT_ILLEGAL_USER_NAME 15 294 4.2.3 Future Assignments 296 Disconnection Message 'reason code' values MUST be assigned 297 sequentially. Requests for assignments of new Disconnection Message 298 'reason code' values, and their associated Disconnection Message 299 'description string', in the range of 0x00000010 through 0xFDFFFFFF 300 MUST be done through the IETF CONSENSUS method as described in 301 [RFC2434]. The IANA will not assign Disconnection Message 'reason 302 code' values in the range of 0xFE000000 through 0xFFFFFFFF. 303 Disconnection Message 'reason code' values in that range are left for 304 PRIVATE USE as described in [RFC2434]. 306 4.3 Channel Connection Failure Reason Codes and Descriptions 308 The Channel Connection Failure 'reason code' is a uint32 value. The 309 associated Channel Connection Failure 'description string' is a 310 human-readable message which describes the channel connection failure 311 reason. This is described in [SSH-CONNECT]. 313 4.3.1 Conventions 315 Protocol packets containing the SSH_MSG_CHANNEL_OPEN_FAILURE message 316 MUST have Channel Connection Failure 'reason code' values in the 317 range of 0x00000001 to 0xFFFFFFFF. 319 4.3.2 Initial Assignments 321 The initial assignments for the 'reason code' values and 'description 322 string' values are given below. Note that the values for the 'reason 323 code' are given in decimal format for readability but that they are 324 actually uinit32 values. 326 description string reason code 327 ------------------ ----------- 328 SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 329 SSH_OPEN_CONNECT_FAILED 2 330 SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 331 SSH_OPEN_RESOURCE_SHORTAGE 4 333 4.3.3 Future Assignments 335 Channel Connection Failure 'reason code' values MUST be assigned 336 sequentially. Requests for assignments of new Channel Connection 337 Failure 'reason code' values, and their associated Channel Connection 338 Failure 'description string', in the range of 0x00000005 to 339 0x0xFDFFFFFF MUST be done through the IETF CONSENSUS method as 340 described in [RFC2434]. The IANA will not assign Channel Connection 341 Failure 'reason code' values in the range of 0xFF000000 to 342 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that 343 range are left for PRIVATE USE as described in [RFC2434]. 345 4.3.4 Notes about the PRIVATE USE Range 347 While it is understood that the IANA will have no control over the 348 range of 0xFF000000 to 0xFFFFFFFF, this range will be split in two 349 parts and administered by the following conventions. 350 o The range of 0xFF000000 to 0xFEFFFFFF is to be used in conjunction 351 with locally assigned channels. For example, if a channel is 352 proposed with a 'channel type' of "example_session@example.com" 353 but fails, then the server will respond with either a 'reason 354 code' assigned by the IANA (as listed above and in the range of 355 0x00000001 to 0x0xFDFFFFFF), or with a locally assigned value in 356 the range of 0xFF000000 to 0xFEFFFFFF. Naturally, if the server 357 does not understand the proposed 'channel type', even if it is a 358 locally defined 'channel type', then the 'reason code' MUST be 359 0x00000003 as described above. If the server does understand the 360 'channel type' but the channel still fails to open, then the 361 server SHOULD respond with a locally assigned 'reason code' value 362 consistent with the proposed, local 'channel type'. It is assumed 363 that practitioners will first attempt to use the IANA assigned 364 'reason code' values and then document their locally assigned 365 'reason code' values. 366 o There are no restrictions or suggestions for the range starting 367 with 0xFF. No interoperability is expected for anything used in 368 this range. Essentially it is for experimentation. 370 4.4 Extended Channel Data Transfer data_type_code and Data 372 The Extended Channel Data Transfer 'data_type_code' is an uint23 373 value. The associated Extended Channel Data Transfer 'data' is a 374 human-readable message which describes the type of data allowed to be 375 transferred in the channel. 377 4.4.1 Conventions 379 Protocol packets containing the SSH_MSG_CHANNEL_EXTENDED_DATA message 380 MUST have Extended Channel Data Transfer 'data_type_code' values in 381 the range of 0x00000001 to 0xFFFFFFFF. This is described in 382 [SSH-CONNECT]. 384 4.4.2 Initial Assignments 386 The initial assignments for the 'data_type_code' values and 'data' 387 values are given below. Note that the value for the 'data_type_code' 388 is given in decimal format for readability but that the values are 389 actually uinit32 values. 391 data data_type_code 392 ---- -------------- 393 SSH_EXTENDED_DATA_STDERR 1 395 4.4.3 Future Assignments 397 Extended Channel Data Transfer 'data_type_code' values MUST be 398 assigned sequentially. Requests for assignments of new Extended 399 Channel Data Transfer 'data_type_code' values, and their associated 400 Extended Channel Data Transfer 'data' strings, in the range of 401 0x00000002 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS 402 method as described in [RFC2434]. The IANA will not assign Extended 403 Channel Data Transfer 'data_type_code' values in the range of 404 0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer 405 'data_type_code' values in that range are left for PRIVATE USE as 406 described in [RFC2434]. 408 4.5 Pseudo-Terminal Encoded Terminal Modes 410 SSH_MSG_CHANNEL_REQUEST messages with a "pty-req" string MUST contain 411 "encoded terminal modes". These "encoded terminal modes" are 412 opcode-argument pairs consisting of an opcode and an argument. 414 4.5.1 Conventions 416 Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with 417 a "pty-req" string MUST contain "encoded terminal modes" with an 418 opcode of 1 byte. The opcode values are in the range of 1 to 255. 419 Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 420 are not yet defined. 422 4.5.2 Initial Assignments 424 opcode argument description 425 ------ -------- ----------- 426 0 TTY_OP_END Indicates end of options. 427 1 VINTR Interrupt character; 255 if none. Similarly 428 for the other characters. Not all of these 429 characters are supported on all systems. 430 2 VQUIT The quit character (sends SIGQUIT signal on 431 POSIX systems). 432 3 VERASE Erase the character to left of the cursor. 433 4 VKILL Kill the current input line. 434 5 VEOF End-of-file character (sends EOF from the 435 terminal). 436 6 VEOL End-of-line character in addition to 437 carriage return and/or linefeed. 438 7 VEOL2 Additional end-of-line character. 439 8 VSTART Continues paused output (normally 440 control-Q). 441 9 VSTOP Pauses output (normally control-S). 442 10 VSUSP Suspends the current program. 443 11 VDSUSP Another suspend character. 444 12 VREPRINT Reprints the current input line. 445 13 VWERASE Erases a word left of cursor. 446 14 VLNEXT Enter the next character typed literally, 447 even if it is a special character 448 15 VFLUSH Character to flush output. 449 16 VSWTCH Switch to a different shell layer. 450 17 VSTATUS Prints system status line (load, command, 451 pid, etc). 452 18 VDISCARD Toggles the flushing of terminal output. 453 30 IGNPAR The ignore parity flag. The parameter 454 SHOULD be 0 if this flag is FALSE set, 455 and 1 if it is TRUE. 456 31 PARMRK Mark parity and framing errors. 457 32 INPCK Enable checking of parity errors. 458 33 ISTRIP Strip 8th bit off characters. 459 34 INLCR Map NL into CR on input. 460 35 IGNCR Ignore CR on input. 461 36 ICRNL Map CR to NL on input. 462 37 IUCLC Translate uppercase characters to 463 lowercase. 464 38 IXON Enable output flow control. 465 39 IXANY Any char will restart after stop. 466 40 IXOFF Enable input flow control. 467 41 IMAXBEL Ring bell on input queue full. 468 50 ISIG Enable signals INTR, QUIT, [D]SUSP. 469 51 ICANON Canonicalize input lines. 470 52 XCASE Enable input and output of uppercase 471 characters by preceding their lowercase 472 equivalents with "\". 473 53 ECHO Enable echoing. 474 54 ECHOE Visually erase chars. 475 55 ECHOK Kill character discards current line. 477 56 ECHONL Echo NL even if ECHO is off. 478 57 NOFLSH Don't flush after interrupt. 479 58 TOSTOP Stop background jobs from output. 480 59 IEXTEN Enable extensions. 481 60 ECHOCTL Echo control characters as ^(Char). 482 61 ECHOKE Visual erase for line kill. 483 62 PENDIN Retype pending input. 484 70 OPOST Enable output processing. 485 71 OLCUC Convert lowercase to uppercase. 486 72 ONLCR Map NL to CR-NL. 487 73 OCRNL Translate carriage return to newline 488 (output). 489 74 ONOCR Translate newline to carriage 490 return-newline (output). 491 75 ONLRET Newline performs a carriage return 492 (output). 493 90 CS7 7 bit mode. 494 91 CS8 8 bit mode. 495 92 PARENB Parity enable. 496 93 PARODD Odd parity, else even. 498 128 TTY_OP_ISPEED Specifies the input baud rate in 499 bits per second. 500 129 TTY_OP_OSPEED Specifies the output baud rate in 501 bits per second. 503 4.5.3 Future Assignments 505 Requests for assignments of new opcodes and their associated 506 arguments MUST be done through the IETF CONSENSUS method as described 507 in [RFC2434]. 509 4.6 Names 511 In the following sections, the values for the name spaces are 512 textual. The conventions and instructions to the IANA for future 513 assignments are given in this section. The initial assignments are 514 given in their respective sections. 516 4.6.1 Conventions for Names 518 All names registered by the IANA in the following sections MUST be 519 printable US-ASCII strings, and MUST NOT contain the characters 520 at-sign ("@"), comma (","), or whitespace or control characters 521 (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be 522 longer than 64 characters. 524 A provision is made here for locally extensible names. The IANA will 525 not register, and will not control names with the at-sign ("@") in 526 them. Names with the at-sign in them will have the format of 527 "name@domainname" (without the double quotes) where the part 528 preceeding the at-sign is the name. The format of the part preceding 529 the at sign is not specified, however these names MUST be printable 530 US-ASCII strings, and MUST NOT contain the comma character (","), or 531 whitespace, or control characters (ASCII codes 32 or less). The part 532 following the at-sign MUST be a valid, fully qualified internet 533 domain name [RFC1034] controlled by the person or organization 534 defining the name. Names are case-sensitive, and MUST NOT be longer 535 than 64 characters. It is up to each domain how it manages its local 536 namespace. It has been noted that these names resemble STD 11 537 [RFC0822] email addresses. This is purely coincidental and actually 538 has nothing to do with STD 11 [RFC0822]. An example of a locally 539 defined name is "ourcipher-cbc@example.com" (without the double 540 quotes). 542 4.6.2 Future Assignments of Names 544 Requests for assignments of new Names MUST be done through the IETF 545 CONSENSUS method as described in [RFC2434]. 547 4.7 Service Names 549 The Service Name is used to describe a protocol layer. 551 Service name Reference 552 ------------- --------- 553 ssh-userauth [SSH-USERAUTH] 554 ssh-connection [SSH-CONNECT] 556 4.8 Authentication Method Names 558 The Authentication Method Name is used to describe an authentication 559 method for the "ssh-userauth" service [SSH-USERAUTH]. 561 Method name Reference 562 ------------ --------- 563 publickey [SSH-USERAUTH, Section 4] 564 password [SSH-USERAUTH, Section 5] 565 hostbased [SSH-USERAUTH, Section 6] 566 none [SSH-USERAUTH, Section 2.3] 568 4.9 Connection Protocol Assigned Names 570 The following are the Connection Protocol Type and Request names. 572 4.9.1 Connection Protocol Channel Types 574 Channel type Reference 575 ------------ --------- 576 session [SSH-CONNECT, Section 4.1] 577 x11 [SSH-CONNECT, Section 4.3.2] 578 forwarded-tcpip [SSH-CONNECT, Section 5.2] 579 direct-tcpip [SSH-CONNECT, Section 5.2] 581 4.9.2 Connection Protocol Global Request Names 583 Request type Reference 584 ------------ --------- 585 tcpip-forward [SSH-CONNECT, Section 5.1] 586 cancel-tcpip-forward [SSH-CONNECT, Section 5.1] 588 4.9.3 Connection Protocol Channel Request Names 590 Request type Reference 591 ------------ --------- 592 pty-req [SSH-CONNECT, Section 4.2] 593 x11-req [SSH-CONNECT, Section 4.3.1] 594 env [SSH-CONNECT, Section 4.4] 595 shell [SSH-CONNECT, Section 4.5] 596 exec [SSH-CONNECT, Section 4.5] 597 subsystem [SSH-CONNECT, Section 4.5] 598 window-change [SSH-CONNECT, Section 4.7] 599 xon-xoff [SSH-CONNECT, Section 4.8] 600 signal [SSH-CONNECT, Section 4.9] 601 exit-status [SSH-CONNECT, Section 4.10] 602 exit-signal [SSH-CONNECT, Section 4.10] 604 4.9.4 Initial Assignment of Signal Names 606 Signal Reference 607 ------ --------- 608 ABRT [SSH-CONNECT] 609 ALRM [SSH-CONNECT] 610 FPE [SSH-CONNECT] 611 HUP [SSH-CONNECT] 612 ILL [SSH-CONNECT] 613 INT [SSH-CONNECT] 614 KILL [SSH-CONNECT] 615 PIPE [SSH-CONNECT] 616 QUIT [SSH-CONNECT] 617 SEGV [SSH-CONNECT] 618 TERM [SSH-CONNECT] 619 USR1 [SSH-CONNECT] 620 USR2 [SSH-CONNECT] 622 4.10 Key Exchange Method Names 624 The Key Exchange Method Name describes a key-exchange method for the 625 protocol [SSH-TRANS]. Note that, for historical reasons, the name 626 "diffie-hellman-group1-sha1" is used for a key exchange method using 627 Oakley Group 2. This is considered an aberration and should not be 628 repeated. Any future specifications of Diffie Hellman key exchange 629 using Oakley groups defined in [RFC2412] or its successors should be 630 named using the group numbers assigned by IANA, and names of the form 631 "diffie-hellman-groupN-sha1" should be reserved for this purpose. 633 Method name Reference 634 ------------ --------- 635 diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1] 636 diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2] 638 4.11 Assigned Algorithm Names 640 The following names identify the Encryption Algorithm Names. 642 4.11.1 Encryption Algorithm Names 644 Cipher name Reference 645 ------------ --------- 646 3des-cbc [SSH-TRANS, Section 4.3] 647 blowfish-cbc [SSH-TRANS, Section 4.3] 648 twofish256-cbc [SSH-TRANS, Section 4.3] 649 twofish-cbc [SSH-TRANS, Section 4.3] 650 twofish192-cbc [SSH-TRANS, Section 4.3] 651 twofish128-cbc [SSH-TRANS, Section 4.3] 652 aes256-cbc [SSH-TRANS, Section 4.3] 653 aes192-cbc [SSH-TRANS, Section 4.3] 654 aes128-cbc [SSH-TRANS, Section 4.3] 655 serpent256-cbc [SSH-TRANS, Section 4.3] 656 serpent192-cbc [SSH-TRANS, Section 4.3] 657 serpent128-cbc [SSH-TRANS, Section 4.3] 658 arcfour [SSH-TRANS, Section 4.3] 659 idea-cbc [SSH-TRANS, Section 4.3] 660 cast128-cbc [SSH-TRANS, Section 4.3] 661 none [SSH-TRANS, Section 4.3] 662 of [FIPS 46-3] 664 4.11.2 MAC Algorithm Names 666 The following names identify the MAC Algorithm Names. 668 MAC name Reference 669 --------- --------- 670 hmac-sha1 [SSH-TRANS, Section 4.4] 671 hmac-sha1-96 [SSH-TRANS, Section 4.4] 672 hmac-md5 [SSH-TRANS, Section 4.4] 673 hmac-md5-96 [SSH-TRANS, Section 4.4] 674 none [SSH-TRANS, Section 4.4] 676 4.11.3 Public Key Algorithm Names 678 This table identifies the Public Key Algorithm names. 680 Algorithm name Reference 681 --------------- --------- 682 ssh-dss [SSH-TRANS, Section 4.6] 683 ssh-rsa [SSH-TRANS, Section 4.6] 684 spki-sign-rsa [SSH-TRANS, Section 4.6] 685 spki-sign-dss [SSH-TRANS, Section 4.6] 686 pgp-sign-rsa [SSH-TRANS, Section 4.6] 687 pgp-sign-dss [SSH-TRANS, Section 4.6] 689 4.11.4 Compression Algorithm Names 691 The following names identify the Compression Algorithm names. 693 Algorithm name Reference 694 --------------- --------- 695 none [SSH-TRANS, Section 4.2] 696 zlib [SSH-TRANS, Section 4.2] 698 5. Security Considerations 700 This protocol provides a secure encrypted channel over an insecure 701 network. 703 Full security considerations for this protocol are provided in 704 [SSH-ARCH]. 706 6. References 708 6.1 Normative References 710 [SSH-ARCH] 711 Lonvick, C., "SSH Protocol Architecture", I-D 712 draft-ietf-architecture-18.txt, October 2004. 714 [SSH-TRANS] 715 Lonvick, C., "SSH Transport Layer Protocol", I-D 716 draft-ietf-transport-20.txt, October 2004. 718 [SSH-USERAUTH] 719 Lonvick, C., "SSH Authentication Protocol", I-D 720 draft-ietf-userauth-23.txt, October 2004. 722 [SSH-CONNECT] 723 Lonvick, C., "SSH Connection Protocol", I-D 724 draft-ietf-connect-21.txt, October 2004. 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, March 1997. 729 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 730 2412, November 1998. 732 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 733 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 734 October 1998. 736 6.2 Informative References 738 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 739 text messages", STD 11, RFC 822, August 1982. 741 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 742 STD 13, RFC 1034, November 1987. 744 [FIPS-46-3] 745 U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption 746 Standard (DES)", October 1999. 748 Author's Address 750 Chris Lonvick (editor) 751 Cisco Systems, Inc. 752 12515 Research Blvd. 753 Austin 78759 754 USA 756 EMail: clonvick@cisco.com 758 Intellectual Property Statement 760 The IETF takes no position regarding the validity or scope of any 761 Intellectual Property Rights or other rights that might be claimed to 762 pertain to the implementation or use of the technology described in 763 this document or the extent to which any license under such rights 764 might or might not be available; nor does it represent that it has 765 made any independent effort to identify any such rights. Information 766 on the procedures with respect to rights in RFC documents can be 767 found in BCP 78 and BCP 79. 769 Copies of IPR disclosures made to the IETF Secretariat and any 770 assurances of licenses to be made available, or the result of an 771 attempt made to obtain a general license or permission for the use of 772 such proprietary rights by implementers or users of this 773 specification can be obtained from the IETF on-line IPR repository at 774 http://www.ietf.org/ipr. 776 The IETF invites any interested party to bring to its attention any 777 copyrights, patents or patent applications, or other proprietary 778 rights that may cover technology that may be required to implement 779 this standard. Please address the information to the IETF at 780 ietf-ipr@ietf.org. 782 The IETF has been notified of intellectual property rights claimed in 783 regard to some or all of the specification contained in this 784 document. For more information consult the online list of claimed 785 rights. 787 Disclaimer of Validity 789 This document and the information contained herein are provided on an 790 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 791 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 792 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 793 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 794 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 795 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 797 Copyright Statement 799 Copyright (C) The Internet Society (2004). This document is subject 800 to the rights, licenses and restrictions contained in BCP 78, and 801 except as set forth therein, the authors retain all their rights. 803 Acknowledgment 805 Funding for the RFC Editor function is currently provided by the 806 Internet Society.