draft-ietf-secsh-assignednumbers-10.txt   draft-ietf-secsh-assignednumbers-11.txt 
Network Working Group C. Lonvick, Ed. Network Working Group C. Lonvick, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: June 9, 2005 December 9, 2004 Expires: August 21, 2005 February 17, 2005
SSH Protocol Assigned Numbers SSH Protocol Assigned Numbers
draft-ietf-secsh-assignednumbers-10.txt draft-ietf-secsh-assignednumbers-11.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 9, 2005. This Internet-Draft will expire on August 21, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines the instructions to the IANA and the initial This document defines the instructions to the IANA and the initial
state of the IANA assigned numbers for the SSH protocol. It is state of the IANA assigned numbers for the SSH protocol. It is
intended only for the initialization of the IANA registries intended only for the initialization of the IANA registries
referenced in the documents. referenced in the documents.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 5 3.1 RFC2119 Keywords . . . . . . . . . . . . . . . . . . . . . 4
4.1 Message Numbers . . . . . . . . . . . . . . . . . . . . . 5 3.2 RFC2434 Keywords . . . . . . . . . . . . . . . . . . . . . 4
4.1.1 Conventions . . . . . . . . . . . . . . . . . . . . . 5 3.3 Protocol Fields and Values . . . . . . . . . . . . . . . . 5
4.1.2 Initial Assignments . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
4.1 Message Numbers . . . . . . . . . . . . . . . . . . . . . 6
4.1.1 Conventions . . . . . . . . . . . . . . . . . . . . . 6
4.1.2 Initial Assignments . . . . . . . . . . . . . . . . . 7
4.1.3 Future Assignments . . . . . . . . . . . . . . . . . . 7 4.1.3 Future Assignments . . . . . . . . . . . . . . . . . . 7
4.2 Disconnection Messages Reason Codes and Descriptions . . . 7 4.2 Disconnection Messages Reason Codes and Descriptions . . . 8
4.2.1 Conventions . . . . . . . . . . . . . . . . . . . . . 7 4.2.1 Conventions . . . . . . . . . . . . . . . . . . . . . 8
4.2.2 Initial Assignments . . . . . . . . . . . . . . . . . 8 4.2.2 Initial Assignments . . . . . . . . . . . . . . . . . 8
4.2.3 Future Assignments . . . . . . . . . . . . . . . . . . 8 4.2.3 Future Assignments . . . . . . . . . . . . . . . . . . 9
4.3 Channel Connection Failure Reason Codes and Descriptions . 8 4.3 Channel Connection Failure Reason Codes and Descriptions . 9
4.3.1 Conventions . . . . . . . . . . . . . . . . . . . . . 8 4.3.1 Conventions . . . . . . . . . . . . . . . . . . . . . 9
4.3.2 Initial Assignments . . . . . . . . . . . . . . . . . 9 4.3.2 Initial Assignments . . . . . . . . . . . . . . . . . 9
4.3.3 Future Assignments . . . . . . . . . . . . . . . . . . 9 4.3.3 Future Assignments . . . . . . . . . . . . . . . . . . 9
4.3.4 Notes about the PRIVATE USE Range . . . . . . . . . . 9 4.3.4 Notes about the PRIVATE USE Range . . . . . . . . . . 10
4.4 Extended Channel Data Transfer data_type_code and Data . . 10 4.4 Extended Channel Data Transfer data_type_code and Data . . 10
4.4.1 Conventions . . . . . . . . . . . . . . . . . . . . . 10 4.4.1 Conventions . . . . . . . . . . . . . . . . . . . . . 10
4.4.2 Initial Assignments . . . . . . . . . . . . . . . . . 10 4.4.2 Initial Assignments . . . . . . . . . . . . . . . . . 10
4.4.3 Future Assignments . . . . . . . . . . . . . . . . . . 10 4.4.3 Future Assignments . . . . . . . . . . . . . . . . . . 11
4.5 Pseudo-Terminal Encoded Terminal Modes . . . . . . . . . . 10 4.5 Pseudo-Terminal Encoded Terminal Modes . . . . . . . . . . 11
4.5.1 Conventions . . . . . . . . . . . . . . . . . . . . . 11 4.5.1 Conventions . . . . . . . . . . . . . . . . . . . . . 11
4.5.2 Initial Assignments . . . . . . . . . . . . . . . . . 11 4.5.2 Initial Assignments . . . . . . . . . . . . . . . . . 11
4.5.3 Future Assignments . . . . . . . . . . . . . . . . . . 12 4.5.3 Future Assignments . . . . . . . . . . . . . . . . . . 13
4.6 Names . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6 Names . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6.1 Conventions for Names . . . . . . . . . . . . . . . . 13 4.6.1 Conventions for Names . . . . . . . . . . . . . . . . 13
4.6.2 Future Assignments of Names . . . . . . . . . . . . . 13 4.6.2 Future Assignments of Names . . . . . . . . . . . . . 14
4.7 Service Names . . . . . . . . . . . . . . . . . . . . . . 13 4.7 Service Names . . . . . . . . . . . . . . . . . . . . . . 14
4.8 Authentication Method Names . . . . . . . . . . . . . . . 14 4.8 Authentication Method Names . . . . . . . . . . . . . . . 14
4.9 Connection Protocol Assigned Names . . . . . . . . . . . . 14 4.9 Connection Protocol Assigned Names . . . . . . . . . . . . 14
4.9.1 Connection Protocol Channel Types . . . . . . . . . . 14 4.9.1 Connection Protocol Channel Types . . . . . . . . . . 15
4.9.2 Connection Protocol Global Request Names . . . . . . . 14 4.9.2 Connection Protocol Global Request Names . . . . . . . 15
4.9.3 Connection Protocol Channel Request Names . . . . . . 15 4.9.3 Connection Protocol Channel Request Names . . . . . . 15
4.9.4 Initial Assignment of Signal Names . . . . . . . . . . 15 4.9.4 Initial Assignment of Signal Names . . . . . . . . . . 16
4.10 Key Exchange Method Names . . . . . . . . . . . . . . . 15 4.9.5 Connection Protocol Subsystem Names . . . . . . . . . 16
4.11 Assigned Algorithm Names . . . . . . . . . . . . . . . . 16 4.10 Key Exchange Method Names . . . . . . . . . . . . . . . 16
4.11.1 Encryption Algorithm Names . . . . . . . . . . . . . 16 4.11 Assigned Algorithm Names . . . . . . . . . . . . . . . . 17
4.11.2 MAC Algorithm Names . . . . . . . . . . . . . . . . 16 4.11.1 Encryption Algorithm Names . . . . . . . . . . . . . 17
4.11.2 MAC Algorithm Names . . . . . . . . . . . . . . . . 17
4.11.3 Public Key Algorithm Names . . . . . . . . . . . . . 17 4.11.3 Public Key Algorithm Names . . . . . . . . . . . . . 17
4.11.4 Compression Algorithm Names . . . . . . . . . . . . 17 4.11.4 Compression Algorithm Names . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 6.1 Normative References . . . . . . . . . . . . . . . . . . . 18
6.2 Informative References . . . . . . . . . . . . . . . . . . . 18 6.2 Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 20
1. Contributors 1. Contributors
The major original contributors of this set of documents have been: The major original contributors of this set of documents have been:
Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
Communications Security Corp), and Markku-Juhani O. Saarinen Communications Security Corp), and Markku-Juhani O. Saarinen
(University of Jyvaskyla). Darren Moffit was the original editor of (University of Jyvaskyla). Darren Moffit was the original editor of
this set of documents and also made very substantial contributions. this set of documents and also made very substantial contributions.
skipping to change at page 4, line 34 skipping to change at page 4, line 34
This document does not define any new protocols. It is intended only This document does not define any new protocols. It is intended only
to create the initial state of the IANA databases for the SSH to create the initial state of the IANA databases for the SSH
protocol and also contains instructions for future assignments. protocol and also contains instructions for future assignments.
Except for one HISTORIC algorithm generally regarded as obsolete, Except for one HISTORIC algorithm generally regarded as obsolete,
this document does not define any new protocols or any number ranges this document does not define any new protocols or any number ranges
not already defined in: [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], not already defined in: [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH],
[SSH-CONNECT]. [SSH-CONNECT].
3. Conventions Used in This Document 3. Conventions Used in This Document
3.1 RFC2119 Keywords
All documents related to the SSH protocols shall use the keywords All documents related to the SSH protocols shall use the keywords
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
requirements. These keywords are to be interpreted as described in requirements. These keywords are to be interpreted as described in
[RFC2119]. [RFC2119].
3.2 RFC2434 Keywords
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
this document when used to describe namespace allocation are to be this document when used to describe namespace allocation are to be
interpreted as described in [RFC2434]. These designations are interpreted as described in [RFC2434]. These designations are
repeated in this document for clarity. repeated in this document for clarity.
PRIVATE USE - For private or local use only, with the type and PRIVATE USE - For private or local use only, with the type and
purpose defined by the local site. No attempt is made to prevent purpose defined by the local site. No attempt is made to prevent
multiple sites from using the same value in different (and multiple sites from using the same value in different (and
skipping to change at page 5, line 37 skipping to change at page 5, line 41
IETF CONSENSUS - New values are assigned through the IETF consensus IETF CONSENSUS - New values are assigned through the IETF consensus
process. Specifically, new assignments are made via RFCs approved by process. Specifically, new assignments are made via RFCs approved by
the IESG. Typically, the IESG will seek input on prospective the IESG. Typically, the IESG will seek input on prospective
assignments from appropriate persons (e.g., a relevant Working Group assignments from appropriate persons (e.g., a relevant Working Group
if one exists). if one exists).
STANDARDS ACTION - Values are assigned only for Standards Track RFCs STANDARDS ACTION - Values are assigned only for Standards Track RFCs
approved by the IESG. 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".
4. IANA Considerations 4. IANA Considerations
This entire document is the IANA considerations for the SSH protocol This entire document is the IANA considerations for the SSH protocol
as is defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], as is defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH],
[SSH-CONNECT]. This section contains conventions used in naming the [SSH-CONNECT]. This section contains conventions used in naming the
namespaces, the initial state of the registry, and instructions for namespaces, the initial state of the registry, and instructions for
future assignments. future assignments.
4.1 Message Numbers 4.1 Message Numbers
skipping to change at page 6, line 48 skipping to change at page 7, line 22
Message ID Value Reference Message ID Value Reference
----------- ----- --------- ----------- ----- ---------
SSH_MSG_DISCONNECT 1 [SSH-TRANS] SSH_MSG_DISCONNECT 1 [SSH-TRANS]
SSH_MSG_IGNORE 2 [SSH-TRANS] SSH_MSG_IGNORE 2 [SSH-TRANS]
SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS] SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS]
SSH_MSG_DEBUG 4 [SSH-TRANS] SSH_MSG_DEBUG 4 [SSH-TRANS]
SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS] SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS]
SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS] SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS]
SSH_MSG_KEXINIT 20 [SSH-TRANS] SSH_MSG_KEXINIT 20 [SSH-TRANS]
SSH_MSG_NEWKEYS 21 [SSH-TRANS] SSH_MSG_NEWKEYS 21 [SSH-TRANS]
SSH_MSG_KEXDH_INIT 30 [SSH-TRANS]
SSH_MSG_KEXDH_REPLY 31 [SSH-TRANS]
SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH] SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH]
SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH] SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH]
SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH] SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH]
SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH] SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH]
SSH_MSG_USERAUTH_PK_OK 60 [SSH-USERAUTH]
SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT] SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT]
SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT] SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT]
SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT] SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT]
SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT] SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT]
SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT] SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT]
SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT] SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT]
SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT] SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT]
SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT] SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT]
SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT] SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT]
SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT] SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT]
SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT] SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT]
4.1.3 Future Assignments 4.1.3 Future Assignments
Requests for assignments of new message numbers in the range of 1 to Requests for assignments of new message numbers in the range of 1 to
127 MUST be done through the STANDARDS ACTION method as described in 29, 50 to 59, and 80 to 127 MUST be done through the STANDARDS ACTION
[RFC2434]. 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.
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 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 to 191 MUST be done through the IETF CONSENSUS method as described in
[RFC2434]. [RFC2434].
The IANA will not control the message numbers range of 192 through The IANA will not control the message numbers range of 192 through
255. This range will be left for PRIVATE USE. 255. This range will be left for PRIVATE USE.
4.2 Disconnection Messages Reason Codes and Descriptions 4.2 Disconnection Messages Reason Codes and Descriptions
skipping to change at page 8, line 10 skipping to change at page 8, line 33
Protocol packets containing the SSH_MSG_DISCONNECT message MUST have Protocol packets containing the SSH_MSG_DISCONNECT message MUST have
Disconnection Message 'reason code' values in the range of 0x00000001 Disconnection Message 'reason code' values in the range of 0x00000001
to 0xFFFFFFFF. These are described in [SSH-TRANS]. to 0xFFFFFFFF. These are described in [SSH-TRANS].
4.2.2 Initial Assignments 4.2.2 Initial Assignments
The following table identifies the initial assignments of the The following table identifies the initial assignments of the
SSH_MSG_DISCONNECT 'description' and 'reason code' values. SSH_MSG_DISCONNECT 'description' and 'reason code' values.
description reason code Symbolic Name reason code
----------- ----------- ------------- -----------
SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1
SSH_DISCONNECT_PROTOCOL_ERROR 2 SSH_DISCONNECT_PROTOCOL_ERROR 2
SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3
SSH_DISCONNECT_RESERVED 4 SSH_DISCONNECT_RESERVED 4
SSH_DISCONNECT_MAC_ERROR 5 SSH_DISCONNECT_MAC_ERROR 5
SSH_DISCONNECT_COMPRESSION_ERROR 6 SSH_DISCONNECT_COMPRESSION_ERROR 6
SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7
SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8
SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9
SSH_DISCONNECT_CONNECTION_LOST 10 SSH_DISCONNECT_CONNECTION_LOST 10
skipping to change at page 9, line 10 skipping to change at page 9, line 35
Protocol packets containing the SSH_MSG_CHANNEL_OPEN_FAILURE message Protocol packets containing the SSH_MSG_CHANNEL_OPEN_FAILURE message
MUST have Channel Connection Failure 'reason code' values in the MUST have Channel Connection Failure 'reason code' values in the
range of 0x00000001 to 0xFFFFFFFF. range of 0x00000001 to 0xFFFFFFFF.
4.3.2 Initial Assignments 4.3.2 Initial Assignments
The initial assignments for the 'reason code' values and The initial assignments for the 'reason code' values and
'description' values are given in the table below. Note that the 'description' values are given in the table below. Note that the
values for the 'reason code' are given in decimal format for values for the 'reason code' are given in decimal format for
readability but that they are actually uinit32 values. readability but that they are actually uint32 values.
description reason code Symbolic Name reason code
----------- ----------- ------------- -----------
SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
SSH_OPEN_CONNECT_FAILED 2 SSH_OPEN_CONNECT_FAILED 2
SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3
SSH_OPEN_RESOURCE_SHORTAGE 4 SSH_OPEN_RESOURCE_SHORTAGE 4
4.3.3 Future Assignments 4.3.3 Future Assignments
Channel Connection Failure 'reason code' values MUST be assigned Channel Connection Failure 'reason code' values MUST be assigned
sequentially. Requests for assignments of new Channel Connection sequentially. Requests for assignments of new Channel Connection
Failure 'reason code' values, and their associated Channel Connection Failure 'reason code' values, and their associated Channel Connection
skipping to change at page 10, line 28 skipping to change at page 11, line 4
Protocol packets containing the SSH_MSG_CHANNEL_EXTENDED_DATA message Protocol packets containing the SSH_MSG_CHANNEL_EXTENDED_DATA message
MUST have Extended Channel Data Transfer 'data_type_code' values in MUST have Extended Channel Data Transfer 'data_type_code' values in
the range of 0x00000001 to 0xFFFFFFFF. This is described in the range of 0x00000001 to 0xFFFFFFFF. This is described in
[SSH-CONNECT]. [SSH-CONNECT].
4.4.2 Initial Assignments 4.4.2 Initial Assignments
The initial assignments for the 'data_type_code' values and 'data' The initial assignments for the 'data_type_code' values and 'data'
values are given in the table below. Note that the value for the values are given in the table below. Note that the value for the
'data_type_code' is given in decimal format for readability but that 'data_type_code' is given in decimal format for readability but that
the values are actually uinit32 values. the values are actually uint32 values.
data data_type_code Symbolic name data_type_code
---- -------------- ------------- --------------
SSH_EXTENDED_DATA_STDERR 1 SSH_EXTENDED_DATA_STDERR 1
4.4.3 Future Assignments 4.4.3 Future Assignments
Extended Channel Data Transfer 'data_type_code' values MUST be Extended Channel Data Transfer 'data_type_code' values MUST be
assigned sequentially. Requests for assignments of new Extended assigned sequentially. Requests for assignments of new Extended
Channel Data Transfer 'data_type_code' values, and their associated Channel Data Transfer 'data_type_code' values, and their associated
Extended Channel Data Transfer 'data' strings, in the range of Extended Channel Data Transfer 'data' strings, in the range of
0x00000002 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS 0x00000002 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS
method as described in [RFC2434]. The IANA will not assign Extended method as described in [RFC2434]. The IANA will not assign Extended
skipping to change at page 15, line 45 skipping to change at page 16, line 26
ILL [SSH-CONNECT] ILL [SSH-CONNECT]
INT [SSH-CONNECT] INT [SSH-CONNECT]
KILL [SSH-CONNECT] KILL [SSH-CONNECT]
PIPE [SSH-CONNECT] PIPE [SSH-CONNECT]
QUIT [SSH-CONNECT] QUIT [SSH-CONNECT]
SEGV [SSH-CONNECT] SEGV [SSH-CONNECT]
TERM [SSH-CONNECT] TERM [SSH-CONNECT]
USR1 [SSH-CONNECT] USR1 [SSH-CONNECT]
USR2 [SSH-CONNECT] USR2 [SSH-CONNECT]
4.9.5 Connection Protocol Subsystem Names
There are no initial assignments of Connection Protocol Subsystem
Names.
4.10 Key Exchange Method Names 4.10 Key Exchange Method Names
The Key Exchange Method Name describes a key-exchange method for the The name "diffie-hellman-group1-sha1" is used for a key exchange
protocol [SSH-TRANS]. Note that for historical reasons, the name method using an Oakley group as defined in [RFC2409]. SSH maintains
"diffie-hellman-group1-sha1" is used for a key exchange method using its own group identifier space which is logically distinct from
an Oakley group as defined in [RFC2412]. Subsequently, the Working Oakley [RFC2412] and IKE; however, for one additional group, the
Group attempted to follow the numbering scheme of group numbers from Working Group adopted the number assigned by [RFC3526], using
[RFC3526] with diffie-hellman-group14-sha1 for the name of the second diffie-hellman-group14-sha1 for the name of the second defined group.
defined name. This is considered an aberration and should not be Implementations should treat these names as opaque identifiers and
repeated. Any future specifications of Diffie-Hellman key exchange should not assume any relationship between the groups used by SSH and
using Oakley groups defined in [RFC2412] or its successors should be the groups defined for IKE.
performed with care and a bit of research.
The following table identifies the initial assignments of the The following table identifies the initial assignments of the
key-exchange methods. key-exchange methods.
Method name Reference Method name Reference
------------ --------- ------------ ---------
diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1] diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1]
diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2] diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2]
4.11 Assigned Algorithm Names 4.11 Assigned Algorithm Names
skipping to change at page 18, line 10 skipping to change at page 18, line 37
network. network.
Full security considerations for this protocol are provided in Full security considerations for this protocol are provided in
[SSH-ARCH]. [SSH-ARCH].
6. References 6. References
6.1 Normative References 6.1 Normative References
[SSH-ARCH] [SSH-ARCH]
Lonvick, C., "SSH Protocol Architecture", I-D Lonvick, C., "SSH Protocol Architecture",
draft-ietf-secsh-architecture-20.txt, December 2004. I-D draft-ietf-secsh-architecture-21.txt, February 2005.
[SSH-TRANS] [SSH-TRANS]
Lonvick, C., "SSH Transport Layer Protocol", I-D Lonvick, C., "SSH Transport Layer Protocol",
draft-ietf-secsh-transport-22.txt, December 2004. I-D draft-ietf-secsh-transport-23.txt, February 2005.
[SSH-USERAUTH] [SSH-USERAUTH]
Lonvick, C., "SSH Authentication Protocol", I-D Lonvick, C., "SSH Authentication Protocol",
draft-ietf-secsh-userauth-25.txt, December 2004. I-D draft-ietf-secsh-userauth-26.txt, February 2005.
[SSH-CONNECT] [SSH-CONNECT]
Lonvick, C., "SSH Connection Protocol", I-D Lonvick, C., "SSH Connection Protocol",
draft-ietf-secsh-connect-23.txt, December 2004. I-D draft-ietf-secsh-connect-24.txt, February 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
2412, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, May 2003.
6.2 Informative References 6.2 Informative References
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. text messages", STD 11, RFC 822, August 1982.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[FIPS-46-3] [FIPS-46-3]
U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption
Standard (DES)", October 1999. Standard (DES)", October 1999.
Author's Address Author's Address
Chris Lonvick (editor) Chris Lonvick (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
12515 Research Blvd. 12515 Research Blvd.
Austin 78759 Austin 78759
USA USA
EMail: clonvick@cisco.com Email: clonvick@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 20, line 46 skipping to change at page 20, line 46
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/