summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4250.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4250.txt')
-rw-r--r--doc/rfc/rfc4250.txt1123
1 files changed, 1123 insertions, 0 deletions
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]
+