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