From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4250.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc4250.txt (limited to 'doc/rfc/rfc4250.txt') diff --git a/doc/rfc/rfc4250.txt b/doc/rfc/rfc4250.txt new file mode 100644 index 0000000..0e04c3d --- /dev/null +++ b/doc/rfc/rfc4250.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group S. Lehtinen +Request for Comments: 4250 SSH Communications Security Corp +Category: Standards Track C. Lonvick, Ed. + Cisco Systems, Inc. + January 2006 + + + The Secure Shell (SSH) Protocol Assigned Numbers + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document defines the instructions to the IANA and the initial + state of the IANA assigned numbers for the Secure Shell (SSH) + protocol. It is intended only for the initialization of the IANA + registries referenced in the set of SSH documents. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Contributors ....................................................3 + 3. Conventions Used in This Document ...............................3 + 3.1. RFC 2119 Keywords ..........................................3 + 3.2. RFC 2434 Keywords ..........................................3 + 3.3. Protocol Fields and Values .................................4 + 4. IANA Considerations .............................................5 + 4.1. Message Numbers ............................................5 + 4.1.1. Conventions .........................................5 + 4.1.2. Initial Assignments .................................6 + 4.1.3. Future Assignments ..................................6 + 4.2. Disconnection Messages Reason Codes and Descriptions .......7 + 4.2.1. Conventions .........................................7 + 4.2.2. Initial Assignments .................................7 + 4.2.3. Future Assignments ..................................8 + 4.3. Channel Connection Failure Reason Codes and Descriptions ...8 + 4.3.1. Conventions .........................................8 + 4.3.2. Initial Assignments .................................8 + + + +Lehtinen & Lonvick Standards Track [Page 1] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + + 4.3.3. Future Assignments ..................................8 + 4.3.4. Notes about the PRIVATE USE Range ...................9 + 4.4. Extended Channel Data Transfer data_type_code and Data .....9 + 4.4.1. Conventions .........................................9 + 4.4.2. Initial Assignments ................................10 + 4.4.3. Future Assignments .................................10 + 4.5. Pseudo-Terminal Encoded Terminal Modes ....................10 + 4.5.1. Conventions ........................................10 + 4.5.2. Initial Assignments ................................10 + 4.5.3. Future Assignments .................................12 + 4.6. Names .....................................................12 + 4.6.1. Conventions for Names ..............................13 + 4.6.2. Future Assignments of Names ........................13 + 4.7. Service Names .............................................13 + 4.8. Authentication Method Names ...............................14 + 4.9. Connection Protocol Assigned Names ........................14 + 4.9.1. Connection Protocol Channel Types ..................14 + 4.9.2. Connection Protocol Global Request Names ...........14 + 4.9.3. Connection Protocol Channel Request Names ..........15 + 4.9.4. Initial Assignment of Signal Names .................15 + 4.9.5. Connection Protocol Subsystem Names ................15 + 4.10. Key Exchange Method Names ................................16 + 4.11. Assigned Algorithm Names .................................16 + 4.11.1. Encryption Algorithm Names ........................16 + 4.11.2. MAC Algorithm Names ...............................17 + 4.11.3. Public Key Algorithm Names ........................17 + 4.11.4. Compression Algorithm Names .......................17 + 5. Security Considerations ........................................17 + 6. References .....................................................18 + 6.1. Normative References ......................................18 + 6.2. Informative References ....................................18 + Authors' Addresses ................................................19 + Trademark Notice ..................................................19 + +1. Introduction + + This document does not define any new protocols. It is intended only + to create the initial state of the IANA databases for the SSH + protocol and also contains instructions for future assignments. + Except for one HISTORIC algorithm generally regarded as obsolete, + this document does not define any new protocols or number ranges not + already defined in: [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], + [SSH-CONNECT]. + + + + + + + + +Lehtinen & Lonvick Standards Track [Page 2] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +2. Contributors + + The major original contributors of this set of documents have been: + Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH + Communications Security Corp), and Markku-Juhani O. Saarinen + (University of Jyvaskyla). Darren Moffat was the original editor of + this set of documents and also made very substantial contributions. + + Many people contributed to the development of this document over the + years. People who should be acknowledged include Mats Andersson, Ben + Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, + Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff + Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph + Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas + Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon + Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and + Tadayoshi Kohno. Listing their names here does not mean that they + endorse this document, but that they have contributed to it. + +3. Conventions Used in This Document + +3.1. RFC 2119 Keywords + + All documents related to the SSH protocols shall use the keywords + "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe + requirements. These keywords are to be interpreted as described in + [RFC2119]. + +3.2. RFC 2434 Keywords + + The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME + FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG + APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in + this document when used to describe namespace allocation are to be + interpreted as described in [RFC2434]. These designations are + repeated in this document for clarity. + + PRIVATE USE - For private or local use only, with the type and + purpose defined by the local site. No attempt is made to prevent + multiple sites from using the same value in different (and + incompatible) ways. There is no need for IANA to review such + assignments and assignments are not generally useful for + interoperability. + + + + + + + +Lehtinen & Lonvick Standards Track [Page 3] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + + HIERARCHICAL ALLOCATION - Delegated managers can assign values + provided they have been given control over that part of the name + space. IANA controls the higher levels of the namespace according to + one of the other policies. + + FIRST COME FIRST SERVED - Anyone can obtain an assigned number, so + long as they provide a point of contact and a brief description of + what the value would be used for. For numbers, the exact value is + generally assigned by the IANA; with names, specific names are + usually requested. + + EXPERT REVIEW - approval by a Designated Expert is required. + + SPECIFICATION REQUIRED - Values and their meaning must be documented + in an RFC or other permanent and readily available reference, in + sufficient detail so that interoperability between independent + implementations is possible. + + IESG APPROVAL - New assignments must be approved by the IESG, but + there is no requirement that the request be documented in an RFC + (though the IESG has discretion to request documents or other + supporting materials on a case-by-case basis). + + IETF CONSENSUS - New values are assigned through the IETF consensus + process. Specifically, new assignments are made via RFCs approved by + the IESG. Typically, the IESG will seek input on prospective + assignments from appropriate persons (e.g., a relevant Working Group + if one exists). + + STANDARDS ACTION - Values are assigned only for Standards Track RFCs + approved by the IESG. + +3.3. Protocol Fields and Values + + Protocol fields and possible values to fill them are defined in this + set of documents. Protocol fields will be defined in the message + definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as + follows. + + byte SSH_MSG_CHANNEL_DATA + uint32 recipient channel + string data + + Throughout these documents, when the fields are referenced, they will + appear within single quotes. When values to fill those fields are + referenced, they will appear within double quotes. Using the above + example, possible values for 'data' are "foo" and "bar". + + + + +Lehtinen & Lonvick Standards Track [Page 4] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +4. IANA Considerations + + This entire document is the IANA considerations for the SSH protocol, + as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], [SSH-CONNECT]. + This section contains conventions used in naming the namespaces, the + initial state of the registry, and instructions for future + assignments. + +4.1. Message Numbers + + The Message Number is a byte value that describes the payload of a + packet. + +4.1.1. Conventions + + Protocol packets have message numbers in the range 1 to 255. These + numbers are allocated as follows: + + Transport layer protocol: + + 1 to 19 Transport layer generic (e.g., disconnect, ignore, + debug, etc.) + 20 to 29 Algorithm negotiation + 30 to 49 Key exchange method specific (numbers can be reused + for different authentication methods) + + User authentication protocol: + + 50 to 59 User authentication generic + 60 to 79 User authentication method specific (numbers can be + reused for different authentication methods) + + Connection protocol: + + 80 to 89 Connection protocol generic + 90 to 127 Channel related messages + + Reserved for client protocols: + + 128 to 191 Reserved + + Local extensions: + + 192 to 255 Local extensions + + + + + + + +Lehtinen & Lonvick Standards Track [Page 5] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +4.1.2. Initial Assignments + + The following table identifies the initial assignments of the Message + ID values. + + Message ID Value Reference + ----------- ----- --------- + SSH_MSG_DISCONNECT 1 [SSH-TRANS] + SSH_MSG_IGNORE 2 [SSH-TRANS] + SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS] + SSH_MSG_DEBUG 4 [SSH-TRANS] + SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS] + SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS] + SSH_MSG_KEXINIT 20 [SSH-TRANS] + SSH_MSG_NEWKEYS 21 [SSH-TRANS] + SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH] + SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH] + SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH] + SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH] + SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT] + SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT] + SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT] + SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT] + SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT] + SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT] + SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT] + SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT] + SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT] + SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT] + SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT] + SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT] + SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT] + SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT] + +4.1.3. Future Assignments + + Requests for assignments of new message numbers in the range of 1 to + 29, 50 to 59, and 80 to 127 MUST be done through the STANDARDS ACTION + method, as described in [RFC2434]. + + The meanings of message numbers in the range of 30 to 49 are specific + to the key exchange method in use, and their meaning will be + specified by the definition of that method. + + + + + + + + +Lehtinen & Lonvick Standards Track [Page 6] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + + The meanings of message numbers in the range of 60 to 79 are specific + to the user authentication method in use, and their meaning will be + specified by the definition of that method. + + Requests for assignments of new message numbers in the range of 128 + to 191 MUST be done through the IETF CONSENSUS method, as described + in [RFC2434]. + + The IANA will not control the message numbers in the range of 192 + through 255. This range will be left for PRIVATE USE. + +4.2. Disconnection Messages Reason Codes and Descriptions + + The Disconnection Message 'reason code' is a uint32 value. The + associated Disconnection Message 'description' is a human-readable + message that describes the disconnect reason. + +4.2.1. Conventions + + Protocol packets containing the SSH_MSG_DISCONNECT message MUST have + Disconnection Message 'reason code' values in the range of 0x00000001 + to 0xFFFFFFFF. These are described in [SSH-TRANS]. + +4.2.2. Initial Assignments + + The following table identifies the initial assignments of the + SSH_MSG_DISCONNECT 'description' and 'reason code' values. + + Symbolic Name reason code + ------------- ----------- + SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 + SSH_DISCONNECT_PROTOCOL_ERROR 2 + SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 + SSH_DISCONNECT_RESERVED 4 + SSH_DISCONNECT_MAC_ERROR 5 + SSH_DISCONNECT_COMPRESSION_ERROR 6 + SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 + SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 + SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 + SSH_DISCONNECT_CONNECTION_LOST 10 + SSH_DISCONNECT_BY_APPLICATION 11 + SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 + SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 + SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 + SSH_DISCONNECT_ILLEGAL_USER_NAME 15 + + + + + + +Lehtinen & Lonvick Standards Track [Page 7] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +4.2.3. Future Assignments + + Disconnection Message 'reason code' values MUST be assigned + sequentially. Requests for assignments of new Disconnection Message + 'reason code' values, and their associated Disconnection Message + 'description' text, in the range of 0x00000010 through 0xFDFFFFFF, + MUST be done through the IETF CONSENSUS method, as described in + [RFC2434]. The IANA will not assign Disconnection Message 'reason + code' values in the range of 0xFE000000 through 0xFFFFFFFF. + Disconnection Message 'reason code' values in that range are left for + PRIVATE USE, as described in [RFC2434]. + +4.3. Channel Connection Failure Reason Codes and Descriptions + + The Channel Connection Failure 'reason code' is a uint32 value. The + associated Channel Connection Failure 'description' text is a human- + readable message that describes the channel connection failure + reason. This is described in [SSH-CONNECT]. + +4.3.1. Conventions + + Protocol packets containing the SSH_MSG_CHANNEL_OPEN_FAILURE message + MUST have Channel Connection Failure 'reason code' values in the + range of 0x00000001 to 0xFFFFFFFF. + +4.3.2. Initial Assignments + + The initial assignments for the 'reason code' values and + 'description' values are given in the table below. Note that the + values for the 'reason code' are given in decimal format for + readability, but they are actually uint32 values. + + Symbolic Name reason code + ------------- ----------- + SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 + SSH_OPEN_CONNECT_FAILED 2 + SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 + SSH_OPEN_RESOURCE_SHORTAGE 4 + +4.3.3. Future Assignments + + Channel Connection Failure 'reason code' values MUST be assigned + sequentially. Requests for assignments of new Channel Connection + Failure 'reason code' values, and their associated Channel Connection + Failure 'description string', in the range of 0x00000005 to + 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as + described in [RFC2434]. The IANA will not assign Channel Connection + + + + +Lehtinen & Lonvick Standards Track [Page 8] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + + Failure 'reason code' values in the range of 0xFE000000 to + 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that + range are left for PRIVATE USE, as described in [RFC2434]. + +4.3.4. Notes about the PRIVATE USE Range + + While it is understood that the IANA will have no control over the + range of 0xFE000000 to 0xFFFFFFFF, this range will be split in two + parts and administered by the following conventions. + + o The range of 0xFE000000 to 0xFEFFFFFF is to be used in conjunction + with locally assigned channels. For example, if a channel is + proposed with a 'channel type' of "example_session@example.com" + but fails, then the server will respond with either a 'reason + code' assigned by the IANA (as listed above and in the range of + 0x00000001 to 0xFDFFFFFF), or with a locally assigned value in the + range of 0xFE000000 to 0xFEFFFFFF. Naturally, if the server does + not understand the proposed 'channel type', even if it is a + locally defined 'channel type', then the 'reason code' MUST be + 0x00000003, as described above. If the server does understand the + 'channel type', but the channel still fails to open, then the + server SHOULD respond with a locally assigned 'reason code' value + that is consistent with the proposed local 'channel type'. It is + assumed that practitioners will first attempt to use the IANA- + assigned 'reason code' values and then document their locally + assigned 'reason code' values. + + o There are no restrictions or suggestions for the range starting + with 0xFF. No interoperability is expected for anything used in + this range. Essentially, it is for experimentation. + +4.4. Extended Channel Data Transfer data_type_code and Data + + The Extended Channel Data Transfer 'data_type_code' is a uint32 + value. The associated Extended Channel Data Transfer 'data' is a + human-readable message that describes the type of data allowed to be + transferred in the channel. + +4.4.1. Conventions + + Protocol packets containing the SSH_MSG_CHANNEL_EXTENDED_DATA message + MUST have Extended Channel Data Transfer 'data_type_code' values in + the range of 0x00000001 to 0xFFFFFFFF. This is described in + [SSH-CONNECT]. + + + + + + + +Lehtinen & Lonvick Standards Track [Page 9] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +4.4.2. Initial Assignments + + The initial assignments for the 'data_type_code' values and 'data' + values are given in the table below. Note that the value for the + 'data_type_code' is given in decimal format for readability, but the + values are actually uint32 values. + + Symbolic name data_type_code + ------------- -------------- + SSH_EXTENDED_DATA_STDERR 1 + +4.4.3. Future Assignments + + Extended Channel Data Transfer 'data_type_code' values MUST be + assigned sequentially. Requests for assignments of new Extended + Channel Data Transfer 'data_type_code' values, and their associated + Extended Channel Data Transfer 'data' strings, in the range of + 0x00000002 to 0xFDFFFFFF, MUST be done through the IETF CONSENSUS + method, as described in [RFC2434]. The IANA will not assign Extended + Channel Data Transfer 'data_type_code' values in the range of + 0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer + 'data_type_code' values in that range are left for PRIVATE USE, as + described in [RFC2434]. + +4.5. Pseudo-Terminal Encoded Terminal Modes + + SSH_MSG_CHANNEL_REQUEST messages with a "pty-req" string MUST contain + 'encoded terminal modes'. The 'encoded terminal modes' value is a + byte stream of opcode-argument pairs. + +4.5.1. Conventions + + Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with + a "pty-req" string MUST contain an 'encoded terminal modes' value. + The opcode values consist of a single byte and are in the range of 1 + to 255. Opcodes 1 to 159 have a uint32 argument. Opcodes 160 to 255 + are not yet defined. + +4.5.2. Initial Assignments + + The following table identifies the initial assignments of the opcode + values that are used in the 'encoded terminal modes' value. + + + + + + + + + +Lehtinen & Lonvick Standards Track [Page 10] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + + opcode mnemonic description + ------ -------- ----------- + 0 TTY_OP_END Indicates end of options. + 1 VINTR Interrupt character; 255 if none. Similarly + for the other characters. Not all of these + characters are supported on all systems. + 2 VQUIT The quit character (sends SIGQUIT signal on + POSIX systems). + 3 VERASE Erase the character to left of the cursor. + 4 VKILL Kill the current input line. + 5 VEOF End-of-file character (sends EOF from the + terminal). + 6 VEOL End-of-line character in addition to + carriage return and/or linefeed. + 7 VEOL2 Additional end-of-line character. + 8 VSTART Continues paused output (normally + control-Q). + 9 VSTOP Pauses output (normally control-S). + 10 VSUSP Suspends the current program. + 11 VDSUSP Another suspend character. + 12 VREPRINT Reprints the current input line. + 13 VWERASE Erases a word left of cursor. + 14 VLNEXT Enter the next character typed literally, + even if it is a special character + 15 VFLUSH Character to flush output. + 16 VSWTCH Switch to a different shell layer. + 17 VSTATUS Prints system status line (load, command, + pid, etc). + 18 VDISCARD Toggles the flushing of terminal output. + 30 IGNPAR The ignore parity flag. The parameter + SHOULD be 0 if this flag is FALSE, + and 1 if it is TRUE. + 31 PARMRK Mark parity and framing errors. + 32 INPCK Enable checking of parity errors. + 33 ISTRIP Strip 8th bit off characters. + 34 INLCR Map NL into CR on input. + 35 IGNCR Ignore CR on input. + 36 ICRNL Map CR to NL on input. + 37 IUCLC Translate uppercase characters to + lowercase. + 38 IXON Enable output flow control. + 39 IXANY Any char will restart after stop. + 40 IXOFF Enable input flow control. + 41 IMAXBEL Ring bell on input queue full. + 50 ISIG Enable signals INTR, QUIT, [D]SUSP. + 51 ICANON Canonicalize input lines. + + + + + +Lehtinen & Lonvick Standards Track [Page 11] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + + 52 XCASE Enable input and output of uppercase + characters by preceding their lowercase + equivalents with "\". + 53 ECHO Enable echoing. + 54 ECHOE Visually erase chars. + 55 ECHOK Kill character discards current line. + 56 ECHONL Echo NL even if ECHO is off. + 57 NOFLSH Don't flush after interrupt. + 58 TOSTOP Stop background jobs from output. + 59 IEXTEN Enable extensions. + 60 ECHOCTL Echo control characters as ^(Char). + 61 ECHOKE Visual erase for line kill. + 62 PENDIN Retype pending input. + 70 OPOST Enable output processing. + 71 OLCUC Convert lowercase to uppercase. + 72 ONLCR Map NL to CR-NL. + 73 OCRNL Translate carriage return to newline + (output). + 74 ONOCR Translate newline to carriage + return-newline (output). + 75 ONLRET Newline performs a carriage return + (output). + 90 CS7 7 bit mode. + 91 CS8 8 bit mode. + 92 PARENB Parity enable. + 93 PARODD Odd parity, else even. + + 128 TTY_OP_ISPEED Specifies the input baud rate in + bits per second. + 129 TTY_OP_OSPEED Specifies the output baud rate in + bits per second. + +4.5.3. Future Assignments + + Requests for assignments of new opcodes and their associated + arguments MUST be done through the IETF CONSENSUS method, as + described in [RFC2434]. + +4.6. Names + + In the following sections, the values for the name spaces are + textual. The conventions and instructions to the IANA for future + assignments are given in this section. The initial assignments are + given in their respective sections. + + + + + + + +Lehtinen & Lonvick Standards Track [Page 12] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +4.6.1. Conventions for Names + + All names registered by the IANA in the following sections MUST be + printable US-ASCII strings, and MUST NOT contain the characters at- + sign ("@"), comma (","), whitespace, control characters (ASCII codes + 32 or less), or the ASCII code 127 (DEL). Names are case-sensitive, + and MUST NOT be longer than 64 characters. + + A provision is made here for locally extensible names. The IANA will + not register, and will not control, names with the at-sign in them. + + Names with the at-sign in them will have the format of + "name@domainname" (without the double quotes) where the part + preceding the at-sign is the name. The format of the part preceding + the at-sign is not specified; however, these names MUST be printable + US-ASCII strings, and MUST NOT contain the comma character (","), + whitespace, control characters (ASCII codes 32 or less), or the ASCII + code 127 (DEL). They MUST have only a single at-sign in them. The + part following the at-sign MUST be a valid, fully qualified internet + domain name [RFC1034] controlled by the person or organization + defining the name. Names are case-sensitive, and MUST NOT be longer + than 64 characters. It is up to each domain how it manages its local + namespace. It has been noted that these names resemble STD 11 + [RFC0822] email addresses. This is purely coincidental and has + nothing to do with STD 11 [RFC0822]. An example of a locally defined + name is "ourcipher-cbc@example.com" (without the double quotes). + +4.6.2. Future Assignments of Names + + Requests for assignments of new names MUST be done through the IETF + CONSENSUS method, as described in [RFC2434]. + +4.7. Service Names + + The 'service name' is used to describe a protocol layer. The + following table lists the initial assignments of the 'service name' + values. + + Service Name Reference + ------------- --------- + ssh-userauth [SSH-USERAUTH] + ssh-connection [SSH-CONNECT] + + + + + + + + + +Lehtinen & Lonvick Standards Track [Page 13] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +4.8. Authentication Method Names + + The Authentication Method Name is used to describe an authentication + method for the "ssh-userauth" service [SSH-USERAUTH]. The following + table identifies the initial assignments of the Authentication Method + Names. + + Method Name Reference + ------------ --------- + publickey [SSH-USERAUTH, Section 7] + password [SSH-USERAUTH, Section 8] + hostbased [SSH-USERAUTH, Section 9] + none [SSH-USERAUTH, Section 5.2] + +4.9. Connection Protocol Assigned Names + + The following table lists the initial assignments to the Connection + Protocol Type and Request names. + +4.9.1. Connection Protocol Channel Types + + The following table lists the initial assignments of the Connection + Protocol Channel Types. + + Channel type Reference + ------------ --------- + session [SSH-CONNECT, Section 6.1] + x11 [SSH-CONNECT, Section 6.3.2] + forwarded-tcpip [SSH-CONNECT, Section 7.2] + direct-tcpip [SSH-CONNECT, Section 7.2] + +4.9.2. Connection Protocol Global Request Names + + The following table lists the initial assignments of the Connection + Protocol Global Request Names. + + Request type Reference + ------------ --------- + tcpip-forward [SSH-CONNECT, Section 7.1] + cancel-tcpip-forward [SSH-CONNECT, Section 7.1] + + + + + + + + + + + +Lehtinen & Lonvick Standards Track [Page 14] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +4.9.3. Connection Protocol Channel Request Names + + The following table lists the initial assignments of the Connection + Protocol Channel Request Names. + + Request type Reference + ------------ --------- + pty-req [SSH-CONNECT, Section 6.2] + x11-req [SSH-CONNECT, Section 6.3.1] + env [SSH-CONNECT, Section 6.4] + shell [SSH-CONNECT, Section 6.5] + exec [SSH-CONNECT, Section 6.5] + subsystem [SSH-CONNECT, Section 6.5] + window-change [SSH-CONNECT, Section 6.7] + xon-xoff [SSH-CONNECT, Section 6.8] + signal [SSH-CONNECT, Section 6.9] + exit-status [SSH-CONNECT, Section 6.10] + exit-signal [SSH-CONNECT, Section 6.10] + +4.9.4. Initial Assignment of Signal Names + + The following table lists the initial assignments of the Signal + Names. + + Signal Reference + ------ --------- + ABRT [SSH-CONNECT] + ALRM [SSH-CONNECT] + FPE [SSH-CONNECT] + HUP [SSH-CONNECT] + ILL [SSH-CONNECT] + INT [SSH-CONNECT] + KILL [SSH-CONNECT] + PIPE [SSH-CONNECT] + QUIT [SSH-CONNECT] + SEGV [SSH-CONNECT] + TERM [SSH-CONNECT] + USR1 [SSH-CONNECT] + USR2 [SSH-CONNECT] + +4.9.5. Connection Protocol Subsystem Names + + There are no initial assignments of the Connection Protocol Subsystem + Names. + + + + + + + +Lehtinen & Lonvick Standards Track [Page 15] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +4.10. Key Exchange Method Names + + The name "diffie-hellman-group1-sha1" is used for a key exchange + method using an Oakley group, as defined in [RFC2409]. SSH maintains + its own group identifier space, which is logically distinct from + Oakley [RFC2412] and IKE; however, for one additional group, the + Working Group adopted the number assigned by [RFC3526], using + "diffie-hellman-group14-sha1" for the name of the second defined + group. Implementations should treat these names as opaque + identifiers and should not assume any relationship between the groups + used by SSH and the groups defined for IKE. + + The following table identifies the initial assignments of the key + exchange methods. + + Method name Reference + ------------ --------- + diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1] + diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2] + +4.11. Assigned Algorithm Names + +4.11.1. Encryption Algorithm Names + + The following table identifies the initial assignment of the + Encryption Algorithm Names. + + Encryption Algorithm Name Reference + ------------------------- --------- + 3des-cbc [SSH-TRANS, Section 6.3] + blowfish-cbc [SSH-TRANS, Section 6.3] + twofish256-cbc [SSH-TRANS, Section 6.3] + twofish-cbc [SSH-TRANS, Section 6.3] + twofish192-cbc [SSH-TRANS, Section 6.3] + twofish128-cbc [SSH-TRANS, Section 6.3] + aes256-cbc [SSH-TRANS, Section 6.3] + aes192-cbc [SSH-TRANS, Section 6.3] + aes128-cbc [SSH-TRANS, Section 6.3] + serpent256-cbc [SSH-TRANS, Section 6.3] + serpent192-cbc [SSH-TRANS, Section 6.3] + serpent128-cbc [SSH-TRANS, Section 6.3] + arcfour [SSH-TRANS, Section 6.3] + idea-cbc [SSH-TRANS, Section 6.3] + cast128-cbc [SSH-TRANS, Section 6.3] + none [SSH-TRANS, Section 6.3] + des-cbc [FIPS-46-3] HISTORIC; See + page 4 of [FIPS-46-3] + + + + +Lehtinen & Lonvick Standards Track [Page 16] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +4.11.2. MAC Algorithm Names + + The following table identifies the initial assignments of the MAC + Algorithm Names. + + MAC Algorithm Name Reference + ------------------ --------- + hmac-sha1 [SSH-TRANS, Section 6.4] + hmac-sha1-96 [SSH-TRANS, Section 6.4] + hmac-md5 [SSH-TRANS, Section 6.4] + hmac-md5-96 [SSH-TRANS, Section 6.4] + none [SSH-TRANS, Section 6.4] + +4.11.3. Public Key Algorithm Names + + The following table identifies the initial assignments of the Public + Key Algorithm names. + + Public Key Algorithm Name Reference + ------------------------- --------- + ssh-dss [SSH-TRANS, Section 6.6] + ssh-rsa [SSH-TRANS, Section 6.6] + pgp-sign-rsa [SSH-TRANS, Section 6.6] + pgp-sign-dss [SSH-TRANS, Section 6.6] + +4.11.4. Compression Algorithm Names + + The following table identifies the initial assignments of the + Compression Algorithm names. + + Compression Algorithm Name Reference + -------------------------- --------- + none [SSH-TRANS, Section 6.2] + zlib [SSH-TRANS, Section 6.2] + +5. Security Considerations + + This protocol provides a secure encrypted channel over an insecure + network. + + Full security considerations for this protocol are provided in + [SSH-ARCH]. + + + + + + + + + +Lehtinen & Lonvick Standards Track [Page 17] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +6. References + +6.1. Normative References + + [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell + (SSH) Protocol Architecture", RFC 4251, January 2006. + + [SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell + (SSH) Transport Layer Protocol", RFC 4253, January + 2006. + + [SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell + (SSH) Authentication Protocol", RFC 4252, January + 2006. + + [SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell + (SSH) Connection Protocol", RFC 4254, January 2006. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + + [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential + (MODP) Diffie-Hellman groups for Internet Key Exchange + (IKE)", RFC 3526, May 2003. + +6.2. Informative References + + [RFC0822] Crocker, D., "Standard for the format of ARPA Internet + text messages", STD 11, RFC 822, August 1982. + + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", + RFC 2412, November 1998. + + [FIPS-46-3] US National Institute of Standards and Technology, + "Data Encryption Standard (DES)", Federal Information + Processing Standards Publication 46-3, October 1999. + + + + + +Lehtinen & Lonvick Standards Track [Page 18] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +Authors' Addresses + + Sami Lehtinen + SSH Communications Security Corp + Valimotie 17 + 00380 Helsinki + Finland + + EMail: sjl@ssh.com + + + Chris Lonvick (editor) + Cisco Systems, Inc. + 12515 Research Blvd. + Austin 78759 + USA + + EMail: clonvick@cisco.com + +Trademark Notice + + "ssh" is a registered trademark in the United States and/or other + countries. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lehtinen & Lonvick Standards Track [Page 19] + +RFC 4250 SSH Protocol Assigned Numbers January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Lehtinen & Lonvick Standards Track [Page 20] + -- cgit v1.2.3