draft-ietf-secsh-assignednumbers-07.txt   draft-ietf-secsh-assignednumbers-08.txt 
Network Working Group C. Lonvick, Ed. Network Working Group C. Lonvick, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc.
Expires: April 24, 2005 October 24, 2004 Expires: May 19, 2005 November 18, 2004
SSH Protocol Assigned Numbers SSH Protocol Assigned Numbers
draft-ietf-secsh-assignednumbers-07.txt draft-ietf-secsh-assignednumbers-08.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.
skipping to change at page 1, line 35 skipping to change at page 1, line 34
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 April 24, 2005. This Internet-Draft will expire on May 19, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
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. Editor's Note . . . . . . . . . . . . . . . . . . . . . . . 3 1. Editor's Note . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 5
4.1 Message Numbers . . . . . . . . . . . . . . . . . . . . . 4 4.1 Message Numbers . . . . . . . . . . . . . . . . . . . . . 5
4.1.1 Conventions . . . . . . . . . . . . . . . . . . . . . 4 4.1.1 Conventions . . . . . . . . . . . . . . . . . . . . . 5
4.1.2 Initial Assignments . . . . . . . . . . . . . . . . . 5 4.1.2 Initial Assignments . . . . . . . . . . . . . . . . . 6
4.1.3 Future Assignments . . . . . . . . . . . . . . . . . . 6 4.1.3 Future Assignments . . . . . . . . . . . . . . . . . . 7
4.2 Disconnection Messages Reason Codes and Descriptions . . . 6 4.2 Disconnection Messages Reason Codes and Descriptions . . . 7
4.2.1 Conventions . . . . . . . . . . . . . . . . . . . . . 6 4.2.1 Conventions . . . . . . . . . . . . . . . . . . . . . 7
4.2.2 Initial Assignments . . . . . . . . . . . . . . . . . 6 4.2.2 Initial Assignments . . . . . . . . . . . . . . . . . 7
4.2.3 Future Assignments . . . . . . . . . . . . . . . . . . 7 4.2.3 Future Assignments . . . . . . . . . . . . . . . . . . 8
4.3 Channel Connection Failure Reason Codes and Descriptions . 7 4.3 Channel Connection Failure Reason Codes and Descriptions . 8
4.3.1 Conventions . . . . . . . . . . . . . . . . . . . . . 7 4.3.1 Conventions . . . . . . . . . . . . . . . . . . . . . 8
4.3.2 Initial Assignments . . . . . . . . . . . . . . . . . 7 4.3.2 Initial Assignments . . . . . . . . . . . . . . . . . 8
4.3.3 Future Assignments . . . . . . . . . . . . . . . . . . 7 4.3.3 Future Assignments . . . . . . . . . . . . . . . . . . 9
4.4 Extended Channel Data Transfer data_type_code and Data . . 8 4.3.4 Notes about the PRIVATE USE Range . . . . . . . . . . 9
4.4.1 Conventions . . . . . . . . . . . . . . . . . . . . . 8 4.4 Extended Channel Data Transfer data_type_code and Data . . 9
4.4.2 Initial Assignments . . . . . . . . . . . . . . . . . 8 4.4.1 Conventions . . . . . . . . . . . . . . . . . . . . . 9
4.4.3 Future Assignments . . . . . . . . . . . . . . . . . . 8 4.4.2 Initial Assignments . . . . . . . . . . . . . . . . . 10
4.5 Pseudo-Terminal Encoded Terminal Modes . . . . . . . . . . 8 4.4.3 Future Assignments . . . . . . . . . . . . . . . . . . 10
4.5.1 Conventions . . . . . . . . . . . . . . . . . . . . . 9 4.5 Pseudo-Terminal Encoded Terminal Modes . . . . . . . . . . 10
4.5.2 Initial Assignments . . . . . . . . . . . . . . . . . 9 4.5.1 Conventions . . . . . . . . . . . . . . . . . . . . . 10
4.5.3 Future Assignments . . . . . . . . . . . . . . . . . . 10 4.5.2 Initial Assignments . . . . . . . . . . . . . . . . . 10
4.6 Names . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5.3 Future Assignments . . . . . . . . . . . . . . . . . . 12
4.6.1 Conventions for Names . . . . . . . . . . . . . . . . 11 4.6 Names . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6.2 Future Assignments of Names . . . . . . . . . . . . . 11 4.6.1 Conventions for Names . . . . . . . . . . . . . . . . 12
4.7 Service Names . . . . . . . . . . . . . . . . . . . . . . 11 4.6.2 Future Assignments of Names . . . . . . . . . . . . . 13
4.8 Authentication Method Names . . . . . . . . . . . . . . . 12 4.7 Service Names . . . . . . . . . . . . . . . . . . . . . . 13
4.9 Connection Protocol Assigned Names . . . . . . . . . . . . 12 4.8 Authentication Method Names . . . . . . . . . . . . . . . 13
4.9.1 Connection Protocol Channel Types . . . . . . . . . . 12 4.9 Connection Protocol Assigned Names . . . . . . . . . . . . 14
4.9.2 Connection Protocol Global Request Names . . . . . . . 12 4.9.1 Connection Protocol Channel Types . . . . . . . . . . 14
4.9.3 Connection Protocol Channel Request Names . . . . . . 12 4.9.2 Connection Protocol Global Request Names . . . . . . . 14
4.9.4 Initial Assignment of Signal Names . . . . . . . . . . 13 4.9.3 Connection Protocol Channel Request Names . . . . . . 14
4.10 Key Exchange Method Names . . . . . . . . . . . . . . . 13 4.9.4 Initial Assignment of Signal Names . . . . . . . . . . 14
4.11 Assigned Algorithm Names . . . . . . . . . . . . . . . . 13 4.10 Key Exchange Method Names . . . . . . . . . . . . . . . 15
4.11.1 Encryption Algorithm Names . . . . . . . . . . . . . 14 4.11 Assigned Algorithm Names . . . . . . . . . . . . . . . . 15
4.11.2 MAC Algorithm Names . . . . . . . . . . . . . . . . 14 4.11.1 Encryption Algorithm Names . . . . . . . . . . . . . 15
4.11.3 Public Key Algorithm Names . . . . . . . . . . . . . 14 4.11.2 MAC Algorithm Names . . . . . . . . . . . . . . . . 16
4.11.4 Compression Algorithm Names . . . . . . . . . . . . 15 4.11.3 Public Key Algorithm Names . . . . . . . . . . . . . 16
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.11.4 Compression Algorithm Names . . . . . . . . . . . . 16
5.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . 16
5.2 Informative References . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . 17 6.2 Informative References . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . 19
1. Editor's Note 1. Editor's Note
The references in this document are statically defined. However, the The references in this document are statically defined. However, the
locations of the referenced materials are dynamic and are changing locations of the referenced materials are dynamic and are changing
with the whims of the Working Group. Please do not comment to the with the whims of the Working Group. Please do not comment to the
editor or the Working Group about inaccuracies along those lines in editor or the Working Group about inaccuracies along those lines in
this document at this time. (This paragraph will be removed before this document at this time. (This paragraph will be removed before
this document is submitted to the RFC Editor.) this document is submitted to the RFC Editor.)
skipping to change at page 3, line 26 skipping to change at page 4, line 26
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
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", All documents related to the SSH protocols shall use the keywords
and "MAY" that appear in this document are to be interpreted as "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
described in [RFC2119]. "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
requirements. These keywords are to be interpreted as described in
[RFC2119].
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
skipping to change at page 6, line 36 skipping to change at page 7, line 38
4.2 Disconnection Messages Reason Codes and Descriptions 4.2 Disconnection Messages Reason Codes and Descriptions
The Disconnection Message 'reason code' is a uint32 value. The The Disconnection Message 'reason code' is a uint32 value. The
associated Disconnection Message 'description string' is a associated Disconnection Message 'description string' is a
human-readable message which describes the disconnect reason. human-readable message which describes the disconnect reason.
4.2.1 Conventions 4.2.1 Conventions
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. to 0xFFFFFFFF. These are described in [SSH-TRANS].
4.2.2 Initial Assignments 4.2.2 Initial Assignments
description string reason Reference description string reason code
code ------------------ -----------
------------------ ----- --------- SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1
SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 [SSH-TRANS] SSH_DISCONNECT_PROTOCOL_ERROR 2
SSH_DISCONNECT_PROTOCOL_ERROR 2 [SSH-TRANS] SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3
SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 [SSH-TRANS] SSH_DISCONNECT_RESERVED 4
SSH_DISCONNECT_RESERVED 4 [SSH-TRANS] SSH_DISCONNECT_MAC_ERROR 5
SSH_DISCONNECT_MAC_ERROR 5 [SSH-TRANS] SSH_DISCONNECT_COMPRESSION_ERROR 6
SSH_DISCONNECT_COMPRESSION_ERROR 6 [SSH-TRANS] SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7
SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 [SSH-TRANS] SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8
SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 [SSH-TRANS] SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9
SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 [SSH-TRANS] SSH_DISCONNECT_CONNECTION_LOST 10
SSH_DISCONNECT_CONNECTION_LOST 10 [SSH-TRANS] SSH_DISCONNECT_BY_APPLICATION 11
SSH_DISCONNECT_BY_APPLICATION 11 [SSH-TRANS] SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12
SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 [SSH-TRANS] SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13
SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 [SSH-TRANS] SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14
SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 [SSH-TRANS] SSH_DISCONNECT_ILLEGAL_USER_NAME 15
SSH_DISCONNECT_ILLEGAL_USER_NAME 15 [SSH-TRANS]
4.2.3 Future Assignments 4.2.3 Future Assignments
Disconnection Message 'reason code' values MUST be assigned Disconnection Message 'reason code' values MUST be assigned
sequentially. Requests for assignments of new Disconnection Message sequentially. Requests for assignments of new Disconnection Message
'reason codes', and their associated Disconnection Message 'reason code' values, and their associated Disconnection Message
'description string', in the range of 0x00000010 through 0xFFFFFFE9 'description string', in the range of 0x00000010 through 0xFDFFFFFF
MUST be done through the IETF CONSENSUS method as described in MUST be done through the IETF CONSENSUS method as described in
[RFC2434]. The IANA will not assign Disconnection Message 'reason [RFC2434]. The IANA will not assign Disconnection Message 'reason
codes' in the range of 0xFFFFFFF0 through 0xFFFFFFFF. Disconnection code' values in the range of 0xFE000000 through 0xFFFFFFFF.
Message 'reason code' values in that range are left for PRIVATE USE Disconnection Message 'reason code' values in that range are left for
as described in [RFC2434]. PRIVATE USE as described in [RFC2434].
4.3 Channel Connection Failure Reason Codes and Descriptions 4.3 Channel Connection Failure Reason Codes and Descriptions
The Channel Connection Failure 'reason code' is a uint32 value. The The Channel Connection Failure 'reason code' is a uint32 value. The
associated Channel Connection Failure 'description string' is a associated Channel Connection Failure 'description string' is a
human-readable message which describes the channel connection failure human-readable message which describes the channel connection failure
reason. reason. This is described in [SSH-CONNECT].
4.3.1 Conventions 4.3.1 Conventions
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
description string reason Reference The initial assignments for the 'reason code' values and 'description
code string' values are given below. Note that the values for the 'reason
------------------ ----- --------- code' are given in decimal format for readability but that they are
SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 [SSH-CONNECT] actually uinit32 values.
SSH_OPEN_CONNECT_FAILED 2 [SSH-CONNECT]
SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 [SSH-CONNECT] description string reason code
SSH_OPEN_RESOURCE_SHORTAGE 4 [SSH-CONNECT] ------------------ -----------
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 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
Failure 'description string', in the range of 0x00000005 to Failure 'description string', in the range of 0x00000005 to
0xFFFFFFE9 MUST be done through the IETF CONSENSUS method as 0x0xFDFFFFFF MUST be done through the IETF CONSENSUS method as
described in [RFC2434]. The IANA will not assign Channel Connection described in [RFC2434]. The IANA will not assign Channel Connection
Failure 'reason code' values in the range of 0xFFFFFFF0 to Failure 'reason code' values in the range of 0xFF000000 to
0xFFFFFFFF. Channel Connection Failure 'reason code' values in that 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that
range are left for PRIVATE USE as described in [RFC2434]. 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 0xFF000000 to 0xFFFFFFFF, this range will be split in two
parts and administered by the following conventions.
o The range of 0xFF000000 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 0x0xFDFFFFFF), or with a locally assigned value in
the range of 0xFF000000 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
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 4.4 Extended Channel Data Transfer data_type_code and Data
The Extended Channel Data Transfer 'data_type_code' is an uint23 The Extended Channel Data Transfer 'data_type_code' is an uint23
value. The associated Extended Channel Data Transfer 'data' is a value. The associated Extended Channel Data Transfer 'data' is a
human-readable message which describes the type of data allowed to be human-readable message which describes the type of data allowed to be
transferred in the channel. transferred in the channel.
4.4.1 Conventions 4.4.1 Conventions
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. the range of 0x00000001 to 0xFFFFFFFF. This is described in
[SSH-CONNECT].
4.4.2 Initial Assignments 4.4.2 Initial Assignments
data data_type_code Reference The initial assignments for the 'data_type_code' values and 'data'
---- -------------- --------- values are given below. Note that the value for the 'data_type_code'
SSH_EXTENDED_DATA_STDERR 1 [SSH-CONNECT] is given in decimal format for readability but that the values are
actually uinit32 values.
data data_type_code
---- --------------
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 0xFFFFFFE9 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
Channel Data Transfer 'data_type_code' values in the range of Channel Data Transfer 'data_type_code' values in the range of
0xFFFFFFF0 to 0xFFFFFFFF. Extended Channel Data Transfer 0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer
'data_type_code' values in that range are left for PRIVATE USE as 'data_type_code' values in that range are left for PRIVATE USE as
described in [RFC2434]. described in [RFC2434].
4.5 Pseudo-Terminal Encoded Terminal Modes 4.5 Pseudo-Terminal Encoded Terminal Modes
SSH_MSG_CHANNEL_REQUEST messages with a "pty-req" string MUST contain SSH_MSG_CHANNEL_REQUEST messages with a "pty-req" string MUST contain
"encoded terminal modes". These "encoded terminal modes" are "encoded terminal modes". These "encoded terminal modes" are
opcode-argument pairs consisting of an opcode and an argument. opcode-argument pairs consisting of an opcode and an argument.
4.5.1 Conventions 4.5.1 Conventions
skipping to change at page 11, line 32 skipping to change at page 13, line 17
them. Names with the at-sign in them will have the format of them. Names with the at-sign in them will have the format of
"name@domainname" (without the double quotes) where the part "name@domainname" (without the double quotes) where the part
preceeding the at-sign is the name. The format of the part preceding preceeding the at-sign is the name. The format of the part preceding
the at sign is not specified, however these names MUST be printable the at sign is not specified, however these names MUST be printable
US-ASCII strings, and MUST NOT contain the comma character (","), or US-ASCII strings, and MUST NOT contain the comma character (","), or
whitespace, or control characters (ASCII codes 32 or less). The part whitespace, or control characters (ASCII codes 32 or less). The part
following the at-sign MUST be a valid, fully qualified internet following the at-sign MUST be a valid, fully qualified internet
domain name [RFC1034] controlled by the person or organization domain name [RFC1034] controlled by the person or organization
defining the name. Names are case-sensitive, and MUST NOT be longer 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 than 64 characters. It is up to each domain how it manages its local
namespace. It has been noted that these names resemble [RFC0822] namespace. It has been noted that these names resemble STD 11
email addresses. This is purely coincidental and actually has [RFC0822] email addresses. This is purely coincidental and actually
nothing to do with [RFC0822]. An example of a locally defined name has nothing to do with STD 11 [RFC0822]. An example of a locally
is "ourcipher-cbc@example.com" (without the double quotes). defined name is "ourcipher-cbc@example.com" (without the double
quotes).
4.6.2 Future Assignments of Names 4.6.2 Future Assignments of Names
Requests for assignments of new Names MUST be done through the IETF Requests for assignments of new Names MUST be done through the IETF
CONSENSUS method as described in [RFC2434]. CONSENSUS method as described in [RFC2434].
4.7 Service Names 4.7 Service Names
The Service Name is used to describe a protocol layer. The Service Name is used to describe a protocol layer.
skipping to change at page 13, line 36 skipping to change at page 15, line 24
The Key Exchange Method Name describes a key-exchange method for the The Key Exchange Method Name describes a key-exchange method for the
protocol [SSH-TRANS]. Note that, for historical reasons, the name protocol [SSH-TRANS]. Note that, for historical reasons, the name
"diffie-hellman-group1-sha1" is used for a key exchange method using "diffie-hellman-group1-sha1" is used for a key exchange method using
Oakley Group 2. This is considered an aberration and should not be Oakley Group 2. This is considered an aberration and should not be
repeated. Any future specifications of Diffie Hellman key exchange repeated. Any future specifications of Diffie Hellman key exchange
using Oakley groups defined in [RFC2412] or its successors should be using Oakley groups defined in [RFC2412] or its successors should be
named using the group numbers assigned by IANA, and names of the form named using the group numbers assigned by IANA, and names of the form
"diffie-hellman-groupN-sha1" should be reserved for this purpose. "diffie-hellman-groupN-sha1" should be reserved for this purpose.
Editor's Note: diffie-hellman-group14-sha1 is controversial at the
moment. It is being discussed on the mailing list.
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
The following names identify the Encryption Algorithm Names. The following names identify the Encryption Algorithm Names.
4.11.1 Encryption Algorithm Names 4.11.1 Encryption Algorithm Names
skipping to change at page 14, line 47 skipping to change at page 16, line 29
none [SSH-TRANS, Section 4.4] none [SSH-TRANS, Section 4.4]
4.11.3 Public Key Algorithm Names 4.11.3 Public Key Algorithm Names
This table identifies the Public Key Algorithm names. This table identifies the Public Key Algorithm names.
Algorithm name Reference Algorithm name Reference
--------------- --------- --------------- ---------
ssh-dss [SSH-TRANS, Section 4.6] ssh-dss [SSH-TRANS, Section 4.6]
ssh-rsa [SSH-TRANS, Section 4.6] ssh-rsa [SSH-TRANS, Section 4.6]
x509v3-sign-rsa [SSH-TRANS, Section 4.6]
x509v3-sign-dss [SSH-TRANS, Section 4.6]
spki-sign-rsa [SSH-TRANS, Section 4.6] spki-sign-rsa [SSH-TRANS, Section 4.6]
spki-sign-dss [SSH-TRANS, Section 4.6] spki-sign-dss [SSH-TRANS, Section 4.6]
pgp-sign-rsa [SSH-TRANS, Section 4.6] pgp-sign-rsa [SSH-TRANS, Section 4.6]
pgp-sign-dss [SSH-TRANS, Section 4.6] pgp-sign-dss [SSH-TRANS, Section 4.6]
4.11.4 Compression Algorithm Names 4.11.4 Compression Algorithm Names
The following names identify the Compression Algorithm names. The following names identify the Compression Algorithm names.
Algorithm name Reference Algorithm name Reference
--------------- --------- --------------- ---------
none [SSH-TRANS, Section 4.2] none [SSH-TRANS, Section 4.2]
zlib [SSH-TRANS, Section 4.2] zlib [SSH-TRANS, Section 4.2]
5. References 5. Security Considerations
5.1 Normative References This protocol provides a secure encrypted channel over an insecure
network.
Full security considerations for this protocol are provided in
[SSH-ARCH].
6. References
6.1 Normative References
[SSH-ARCH] [SSH-ARCH]
Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", Lonvick, C., "SSH Protocol Architecture", I-D
I-D draft-ietf-architecture-17.txt, October 2004. draft-ietf-architecture-18.txt, October 2004.
[SSH-TRANS] [SSH-TRANS]
Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", Lonvick, C., "SSH Transport Layer Protocol", I-D
I-D draft-ietf-transport-19.txt, October 2004. draft-ietf-transport-20.txt, October 2004.
[SSH-USERAUTH] [SSH-USERAUTH]
Ylonen, T. and C. Lonvick, "SSH Authentication Protocol", Lonvick, C., "SSH Authentication Protocol", I-D
I-D draft-ietf-userauth-22.txt, October 2004. draft-ietf-userauth-23.txt, October 2004.
[SSH-CONNECT] [SSH-CONNECT]
Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D Lonvick, C., "SSH Connection Protocol", I-D
draft-ietf-connect-20.txt, October 2004. draft-ietf-connect-21.txt, October 2004.
[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 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998. 2412, 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.
5.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.
[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
 End of changes. 

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