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