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