draft-ietf-secsh-connect-18.txt   draft-ietf-secsh-connect-19.txt 
Network Working Group T. Ylonen Network Working Group T. Ylonen
Internet-Draft SSH Communications Security Corp Internet-Draft SSH Communications Security Corp
Expires: March 31, 2004 D. Moffat, Editor, Ed. Expires: December 1, 2004 C. Lonvick, Ed.
Sun Microsystems, Inc Cisco Systems, Inc
Oct 2003 June 2, 2004
SSH Connection Protocol SSH Connection Protocol
draft-ietf-secsh-connect-18.txt draft-ietf-secsh-connect-19.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 http:// The list of current Internet-Drafts can be accessed at
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 March 31, 2004. This Internet-Draft will expire on December 1, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
SSH is a protocol for secure remote login and other secure network SSH is a protocol for secure remote login and other secure network
services over an insecure network. services over an insecure network.
This document describes the SSH Connection Protocol. It provides This document describes the SSH Connection Protocol. It provides
interactive login sessions, remote execution of commands, forwarded interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections. All of these TCP/IP connections, and forwarded X11 connections. All of these
channels are multiplexed into a single encrypted tunnel. channels are multiplexed into a single encrypted tunnel.
The SSH Connection Protocol has been designed to run on top of the The SSH Connection Protocol has been designed to run on top of the
SSH transport layer and user authentication protocols. SSH transport layer and user authentication protocols.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 3
4. Global Requests . . . . . . . . . . . . . . . . . . . . . . 3 4. Global Requests . . . . . . . . . . . . . . . . . . . . . . . 3
5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . 4 5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . . 4
5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . . 4 5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . 4
5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 5 5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . 6
5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6 5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . 6
5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . . 7 5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . 7
6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . 8 6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . . 8
6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . . 8 6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . 8
6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 8 6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . 8
6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 9 6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . 9
6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 9 6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . 9
6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . 10
6.4 Environment Variable Passing . . . . . . . . . . . . . . . . 10 6.4 Environment Variable Passing . . . . . . . . . . . . . . . 10
6.5 Starting a Shell or a Command . . . . . . . . . . . . . . . 10 6.5 Starting a Shell or a Command . . . . . . . . . . . . . . 10
6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . . 11 6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . 11
6.7 Window Dimension Change Message . . . . . . . . . . . . . . 12 6.7 Window Dimension Change Message . . . . . . . . . . . . . 12
6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . . 12 6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . 12
6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . . 13 6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . 13
7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 14 7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . . 14
7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . . 14 7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . 14
7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 15 7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . 15
8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . 16 8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . . 16
9. Summary of Message Numbers . . . . . . . . . . . . . . . . . 18 9. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
11. iana cONSiderations . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . 18
12. Intellectual Property . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . . 19 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
Informative References . . . . . . . . . . . . . . . . . . . 20 12.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 21
1. Contributors 1. Contributors
The major original contributors of this document were: Tatu Ylonen, The major original contributors of this document were: Tatu Ylonen,
Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
Security Corp), and Markku-Juhani O. Saarinen (University of Communications Security Corp), and Markku-Juhani O. Saarinen
Jyvaskyla) (University of Jyvaskyla). Darren Moffit was the original editor of
this document and also made very substantial contributions.
The document editor is: Darren.Moffat@Sun.COM. Comments on this Additional contributors to this document include [need list].
internet draft should be sent to the IETF SECSH working group, Listing their names here does not mean that they endorse this
details at: http://ietf.org/html.charters/secsh-charter.html document, but that they have contributed to it.
Comments on this internet draft should be sent to the IETF SECSH
working group, details at:
http://ietf.org/html.charters/secsh-charter.html Note: This paragraph
will be removed before this document progresses to become an RFC.
2. Introduction 2. Introduction
The SSH Connection Protocol has been designed to run on top of the The SSH Connection Protocol has been designed to run on top of the
SSH transport layer and user authentication protocols. It provides SSH transport layer and user authentication protocols. It provides
interactive login sessions, remote execution of commands, forwarded interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections. The service name TCP/IP connections, and forwarded X11 connections. The service name
for this protocol is "ssh-connection". for this protocol is "ssh-connection".
This document should be read only after reading the SSH architecture This document should be read only after reading the SSH architecture
skipping to change at page 3, line 49 skipping to change at page 4, line 6
conventions that MUST be used with the SSH protocols. conventions that MUST be used with the SSH protocols.
4. Global Requests 4. Global Requests
There are several kinds of requests that affect the state of the There are several kinds of requests that affect the state of the
remote end "globally", independent of any channels. An example is a remote end "globally", independent of any channels. An example is a
request to start TCP/IP forwarding for a specific port. All such request to start TCP/IP forwarding for a specific port. All such
requests use the following format. requests use the following format.
byte SSH_MSG_GLOBAL_REQUEST byte SSH_MSG_GLOBAL_REQUEST
string request name (restricted to US-ASCII) string request name in US-ASCII only
boolean want reply boolean want reply
... request-specific data follows ... request-specific data follows
Request names follow the DNS extensibility naming convention outlined Request names follow the DNS extensibility naming convention outlined
in [SSH-ARCH]. in [SSH-ARCH].
The recipient will respond to this message with The recipient will respond to this message with
SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if `want reply' is SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if `want reply' is
TRUE. TRUE.
byte SSH_MSG_REQUEST_SUCCESS byte SSH_MSG_REQUEST_SUCCESS
..... response specific data ..... response specific data
skipping to change at page 4, line 44 skipping to change at page 4, line 50
a message is received to indicate that window space is available. a message is received to indicate that window space is available.
5.1 Opening a Channel 5.1 Opening a Channel
When either side wishes to open a new channel, it allocates a local When either side wishes to open a new channel, it allocates a local
number for the channel. It then sends the following message to the number for the channel. It then sends the following message to the
other side, and includes the local channel number and initial window other side, and includes the local channel number and initial window
size in the message. size in the message.
byte SSH_MSG_CHANNEL_OPEN byte SSH_MSG_CHANNEL_OPEN
string channel type (restricted to US-ASCII) string channel type in US-ASCII only
uint32 sender channel uint32 sender channel
uint32 initial window size uint32 initial window size
uint32 maximum packet size uint32 maximum packet size
... channel type specific data follows ... channel type specific data follows
The channel type is a name as described in the SSH architecture The channel type is a name as described in the SSH architecture
document, with similar extension mechanisms. `sender channel' is a document, with similar extension mechanisms. `sender channel' is a
local identifier for the channel used by the sender of this message. local identifier for the channel used by the sender of this message.
`initial window size' specifies how many bytes of channel data can be `initial window size' specifies how many bytes of channel data can be
sent to the sender of this message without adjusting the window. sent to the sender of this message without adjusting the window.
skipping to change at page 5, line 26 skipping to change at page 5, line 30
byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32 recipient channel uint32 recipient channel
uint32 sender channel uint32 sender channel
uint32 initial window size uint32 initial window size
uint32 maximum packet size uint32 maximum packet size
... channel type specific data follows ... channel type specific data follows
where `recipient channel' is the channel number given in the original where `recipient channel' is the channel number given in the original
open request, and `sender channel' is the channel number allocated by open request, and `sender channel' is the channel number allocated by
the other side, or the other side, or
byte SSH_MSG_CHANNEL_OPEN_FAILURE byte SSH_MSG_CHANNEL_OPEN_FAILURE
uint32 recipient channel uint32 recipient channel
uint32 reason code uint32 reason code
string additional textual information (ISO-10646 UTF-8 [RFC2279]) string additional textual information in ISO-10646 UTF-8
string language tag (as defined in [RFC3066]) encoding [RFC2279]
string language tag as defined in [RFC3066]
If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support
the specified channel type, it simply responds with the specified channel type, it simply responds with
SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the additional SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the additional
information to the user. If this is done, the client software should information to the user. If this is done, the client software should
take the precautions discussed in [SSH-ARCH]. take the precautions discussed in [SSH-ARCH].
The following reason codes are defined: The following reason codes are defined:
#define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 #define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
skipping to change at page 7, line 36 skipping to change at page 7, line 43
5.4 Channel-Specific Requests 5.4 Channel-Specific Requests
Many channel types have extensions that are specific to that Many channel types have extensions that are specific to that
particular channel type. An example is requesting a pty (pseudo particular channel type. An example is requesting a pty (pseudo
terminal) for an interactive session. terminal) for an interactive session.
All channel-specific requests use the following format. All channel-specific requests use the following format.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string request type (restricted to US-ASCII) string request type in US-ASCII characters only
boolean want reply boolean want reply
... type-specific data ... type-specific data
If want reply is FALSE, no response will be sent to the request. If want reply is FALSE, no response will be sent to the request.
Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS
or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation
messages. If the request is not recognized or is not supported for messages. If the request is not recognized or is not supported for
the channel, SSH_MSG_CHANNEL_FAILURE is returned. the channel, SSH_MSG_CHANNEL_FAILURE is returned.
This message does not consume window space and can be sent even if no This message does not consume window space and can be sent even if no
skipping to change at page 11, line 35 skipping to change at page 11, line 41
these will include a general file transfer mechanism, and possibly these will include a general file transfer mechanism, and possibly
other features. Implementations may also allow configuring more such other features. Implementations may also allow configuring more such
mechanisms. As the user's shell is usually used to execute the mechanisms. As the user's shell is usually used to execute the
subsystem, it is advisable for the subsystem protocol to have a subsystem, it is advisable for the subsystem protocol to have a
"magic cookie" at the beginning of the protocol transaction to "magic cookie" at the beginning of the protocol transaction to
distinguish it from arbitrary output generated by shell distinguish it from arbitrary output generated by shell
initialization scripts etc. This spurious output from the shell may initialization scripts etc. This spurious output from the shell may
be filtered out either at the server or at the client. be filtered out either at the server or at the client.
The server SHOULD not halt the execution of the protocol stack when The server SHOULD not halt the execution of the protocol stack when
starting a shell or a program. All input and output from these SHOULD starting a shell or a program. All input and output from these
be redirected to the channel or to the encrypted tunnel. SHOULD be redirected to the channel or to the encrypted tunnel.
It is RECOMMENDED to request and check the reply for these messages. It is RECOMMENDED to request and check the reply for these messages.
The client SHOULD ignore these messages. The client SHOULD ignore these messages.
Subsystem names follow the DNS extensibility naming convention Subsystem names follow the DNS extensibility naming convention
outlined in [SSH-ARCH]. outlined in [SSH-ARCH].
6.6 Session Data Transfer 6.6 Session Data Transfer
Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and
skipping to change at page 13, line 29 skipping to change at page 13, line 33
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient_channel uint32 recipient_channel
string "exit-status" string "exit-status"
boolean FALSE boolean FALSE
uint32 exit_status uint32 exit_status
The remote command may also terminate violently due to a signal. The remote command may also terminate violently due to a signal.
Such a condition can be indicated by the following message. A zero Such a condition can be indicated by the following message. A zero
exit_status usually means that the command terminated successfully. exit_status usually means that the command terminated successfully.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "exit-signal" string "exit-signal"
boolean FALSE boolean FALSE
string signal name without the "SIG" prefix. string signal name without the "SIG" prefix.
boolean core dumped boolean core dumped
string error message (ISO-10646 UTF-8) string error message in ISO-10646 UTF-8 encoding
string language tag (as defined in [RFC3066]) string language tag as defined in [RFC3066]
The signal name is one of the following (these are from [POSIX]) The signal name is one of the following (these are from [POSIX])
ABRT ABRT
ALRM ALRM
FPE FPE
HUP HUP
ILL ILL
INT INT
KILL KILL
skipping to change at page 15, line 9 skipping to change at page 15, line 11
normally only sent by the client. normally only sent by the client.
If a client passes 0 as port number to bind and has want reply TRUE If a client passes 0 as port number to bind and has want reply TRUE
then the server allocates the next available unprivileged port number then the server allocates the next available unprivileged port number
and replies with the following message, otherwise there is no and replies with the following message, otherwise there is no
response specific data. response specific data.
byte SSH_MSG_GLOBAL_REQUEST_SUCCESS byte SSH_MSG_GLOBAL_REQUEST_SUCCESS
uint32 port that was bound on the server uint32 port that was bound on the server
A port forwarding can be cancelled with the following message. Note A port forwarding can be canceled with the following message. Note
that channel open requests may be received until a reply to this that channel open requests may be received until a reply to this
message is received. message is received.
byte SSH_MSG_GLOBAL_REQUEST byte SSH_MSG_GLOBAL_REQUEST
string "cancel-tcpip-forward" string "cancel-tcpip-forward"
boolean want reply boolean want reply
string address_to_bind (e.g. "127.0.0.1") string address_to_bind (e.g. "127.0.0.1")
uint32 port number to bind uint32 port number to bind
Client implementations SHOULD reject these messages; they are Client implementations SHOULD reject these messages; they are
skipping to change at page 18, line 38 skipping to change at page 18, line 40
#define SSH_MSG_CHANNEL_OPEN_FAILURE 92 #define SSH_MSG_CHANNEL_OPEN_FAILURE 92
#define SSH_MSG_CHANNEL_WINDOW_ADJUST 93 #define SSH_MSG_CHANNEL_WINDOW_ADJUST 93
#define SSH_MSG_CHANNEL_DATA 94 #define SSH_MSG_CHANNEL_DATA 94
#define SSH_MSG_CHANNEL_EXTENDED_DATA 95 #define SSH_MSG_CHANNEL_EXTENDED_DATA 95
#define SSH_MSG_CHANNEL_EOF 96 #define SSH_MSG_CHANNEL_EOF 96
#define SSH_MSG_CHANNEL_CLOSE 97 #define SSH_MSG_CHANNEL_CLOSE 97
#define SSH_MSG_CHANNEL_REQUEST 98 #define SSH_MSG_CHANNEL_REQUEST 98
#define SSH_MSG_CHANNEL_SUCCESS 99 #define SSH_MSG_CHANNEL_SUCCESS 99
#define SSH_MSG_CHANNEL_FAILURE 100 #define SSH_MSG_CHANNEL_FAILURE 100
10. Security Considerations 10. IANA Considerations
This document is part of a set. The IANA considerations for the SSH
protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], and
this document, are detailed in [SSH-NUMBERS].
11. Security Considerations
This protocol is assumed to run on top of a secure, authenticated This protocol is assumed to run on top of a secure, authenticated
transport. User authentication and protection against network-level transport. User authentication and protection against network-level
attacks are assumed to be provided by the underlying protocols. attacks are assumed to be provided by the underlying protocols.
It is RECOMMENDED that implementations disable all the potentially
dangerous features (e.g. agent forwarding, X11 forwarding, and TCP/IP
forwarding) if the host key has changed.
Full security considerations for this protocol are provided in Full security considerations for this protocol are provided in
Section 8 of [SSH-ARCH] [SSH-ARCH]. Specific to this document, it is RECOMMENDED that
implementations disable all the potentially dangerous features (e.g.
11. iana cONSiderations agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host
key has changed without notice or explanation.
This document is part of a set, the IANA considerations for the SSH
protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH],
[SSH-CONNECT] are detailed in [SSH-NUMBERS].
12. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
The IETF has been notified of intellectual property rights claimed in 12. References
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Normative References 12.1 Normative References
[SSH-ARCH] [SSH-ARCH]
Ylonen, T., "SSH Protocol Architecture", I-D Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
draft-ietf-architecture-15.txt, Oct 2003. I-D draft-ietf-architecture-16.txt, May 2004.
[SSH-TRANS] [SSH-TRANS]
Ylonen, T., "SSH Transport Layer Protocol", I-D Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol",
draft-ietf-transport-17.txt, Oct 2003. I-D draft-ietf-transport-18.txt, May 2004.
[SSH-USERAUTH] [SSH-USERAUTH]
Ylonen, T., "SSH Authentication Protocol", I-D Ylonen, T. and C. Lonvick, "SSH Authentication Protocol",
draft-ietf-userauth-18.txt, Oct 2003. I-D draft-ietf-userauth-21.txt, May 2004.
[SSH-CONNECT]
Ylonen, T., "SSH Connection Protocol", I-D
draft-ietf-connect-18.txt, Oct 2003.
[SSH-NUMBERS] [SSH-NUMBERS]
Lehtinen, S. and D. Moffat, "SSH Protocol Assigned Ylonen, T. and C. Lonvick, "SSH Protocol Assigned
Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct Numbers", I-D draft-ietf-assignednumbers-06.txt, May 2004.
2003.
[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.
Informative References 12.2 Informative References
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 1884, December 1995. Architecture", RFC 1884, December 1995.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998. 10646", RFC 2279, January 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[SCHEIFLER] [SCHEIFLER]
Scheifler, R., "X Window System : The Complete Reference Scheifler, R., "X Window System : The Complete Reference
to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital
Press ISBN 1555580882, Feburary 1992. Press ISBN 1555580882, February 1992.
[POSIX] ISO/IEC, 9945-1., "Information technology -- Portable [POSIX] ISO/IEC, 9945-1., "Information technology -- Portable
Operating System Interface (POSIX)-Part 1: System Operating System Interface (POSIX)-Part 1: System
Application Program Interface (API) C Language", ANSI/IEE Application Program Interface (API) C Language", ANSI/IEE
Std 1003.1, July 1996. Std 1003.1, July 1996.
Authors' Addresses Authors' Addresses
Tatu Ylonen Tatu Ylonen
SSH Communications Security Corp SSH Communications Security Corp
Fredrikinkatu 42 Fredrikinkatu 42
HELSINKI FIN-00100 HELSINKI FIN-00100
Finland Finland
EMail: ylo@ssh.com EMail: ylo@ssh.com
Darren J. Moffat (editor) Chris Lonvick (editor)
Sun Microsystems, Inc Cisco Systems, Inc
17 Network Circle 12515 Research Blvd.
Menlo Park CA 94025 Austin 78759
USA USA
EMail: Darren.Moffat@Sun.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 or other rights that might be claimed to intellectual property 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; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 21, line 34 skipping to change at page 21, line 34
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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