draft-ietf-secsh-connect-21.txt   draft-ietf-secsh-connect-22.txt 
Network Working Group C. Lonvick, Ed. Network Working Group C. Lonvick, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: May 19, 2005 November 18, 2004 Expires: May 30, 2005 November 29, 2004
SSH Connection Protocol SSH Connection Protocol
draft-ietf-secsh-connect-21.txt draft-ietf-secsh-connect-22.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 34 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 May 19, 2005. This Internet-Draft will expire on May 30, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
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.
skipping to change at page 3, line 7 skipping to change at page 3, line 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 21
12.2 Informative References . . . . . . . . . . . . . . . . . . . 21 12.2 Informative References . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 23
1. Contributors 1. Contributors
The major original contributors of this document were: Tatu Ylonen, The major original contributors of this set of documents have been:
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 document and also made very substantial contributions. this set of documents and also made very substantial contributions.
Additional contributors to this document include [need list]. Additional contributors to this document include [need list].
Listing their names here does not mean that they endorse this Listing their names here does not mean that they endorse this
document, but that they have contributed to it. document, but that they have contributed to it.
Comments on this internet draft should be sent to the IETF SECSH Comments on this internet draft should be sent to the IETF SECSH
working group, details at: working group, details at:
http://ietf.org/html.charters/secsh-charter.html Note: This paragraph http://ietf.org/html.charters/secsh-charter.html Note: This paragraph
will be removed before this document progresses to become an RFC. will be removed before this document progresses to become an RFC.
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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 [SSH-ARCH] and The 'channel type' is a name as described in [SSH-ARCH] and
[SSH-NUMBERS], with similar extension mechanisms. The 'sender [SSH-NUMBERS], with similar extension mechanisms. The 'sender
channel' is a local identifier for the channel used by the sender of channel' is a local identifier for the channel used by the sender of
this message. The 'initial window size' specifies how many bytes of this message. The 'initial window size' specifies how many bytes of
channel data can be sent to the sender of this message without channel data can be sent to the sender of this message without
adjusting the window. The 'maximum packet size' specifies the adjusting the window. The 'maximum packet size' specifies the
maximum size of an individual data packet that can be sent to the maximum size of an individual data packet that can be sent to the
sender. For example, one might want to use smaller packets for sender. For example: one might want to use smaller packets for
interactive connections to get better interactive response on slow interactive connections to get better interactive response on slow
links. links.
The remote side then decides whether it can open the channel, and The remote side then decides whether it can open the channel, and
responds with either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or responds with either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or
SSH_MSG_CHANNEL_OPEN_FAILURE. SSH_MSG_CHANNEL_OPEN_FAILURE.
byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32 recipient channel uint32 recipient channel
uint32 sender channel uint32 sender channel
skipping to change at page 6, line 24 skipping to change at page 6, line 24
description reason code description 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
Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code' Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code'
values (and associated 'description' text) in the range of 0x00000005 values (and associated 'description' text) in the range of 0x00000005
to 0x0xFDFFFFFF MUST be done through the IETF CONSENSUS method as to 0xFDFFFFFF 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 0xFF000000 to Failure 'reason code' values in the range of 0xFE000000 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].
While it is understood that the IANA will have no control over the 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 range of 0xFE000000 to 0xFFFFFFFF, this range will be split in two
parts and administered by the following conventions. parts and administered by the following conventions.
o The range of 0xFF000000 to 0xFEFFFFFF is to be used in conjunction o The range of 0xFE000000 to 0xFEFFFFFF is to be used in conjunction
with locally assigned channels. For example, if a channel is with locally assigned channels. For example: if a channel is
proposed with a 'channel type' of "example_session@example.com" proposed with a 'channel type' of "example_session@example.com"
but fails, then the response will contain either a 'reason code' but fails, then the response will contain either a 'reason code'
assigned by the IANA (as listed above and in the range of assigned by the IANA (as listed above and in the range of
0x00000001 to 0x0xFDFFFFFF), or with a locally assigned value in 0x00000001 to 0xFDFFFFFF), or with a locally assigned value in the
the range of 0xFF000000 to 0xFEFFFFFF. Naturally, if the server range of 0xFE000000 to 0xFEFFFFFF. Naturally, if the server does
does not understand the proposed 'channel type', even if it is a not understand the proposed 'channel type', even if it is a
locally defined 'channel type', then the 'reason code' MUST be locally defined 'channel type', then the 'reason code' MUST be
0x00000003 as described above, if the 'reason code' is sent. If 0x00000003 as described above, if the 'reason code' is sent. If
the server does understand the 'channel type' but the channel the server does understand the 'channel type' but the channel
still fails to open, then the server SHOULD respond with a locally still fails to open, then the server SHOULD respond with a locally
assigned 'reason code' value consistent with the proposed, local assigned 'reason code' value consistent with the proposed, local
'channel type'. It is assumed that practitioners will first 'channel type'. It is assumed that practitioners will first
attempt to use the IANA assigned 'reason code' values and then attempt to use the IANA assigned 'reason code' values and then
document their locally assigned 'reason code' values. document their locally assigned 'reason code' values.
o There are no restrictions or suggestions for the range starting o There are no restrictions or suggestions for the range starting
with 0xFF. No interoperability is expected for anything used in with 0xFF. No interoperability is expected for anything used in
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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
Channel Data Transfer 'data_type_code' values in the range of Channel Data Transfer 'data_type_code' values in the range of
0xFE000000 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]. As is noted, the actual instructions to the described in [RFC2434]. As is noted, the actual instructions to the
IANA is in [SSH-NUMBERS]. IANA are in [SSH-NUMBERS].
5.3 Closing a Channel 5.3 Closing a Channel
When a party will no longer send more data to a channel, it SHOULD When a party will no longer send more data to a channel, it SHOULD
send SSH_MSG_CHANNEL_EOF. send SSH_MSG_CHANNEL_EOF.
byte SSH_MSG_CHANNEL_EOF byte SSH_MSG_CHANNEL_EOF
uint32 recipient_channel uint32 recipient_channel
No explicit response is sent to this message. However, the No explicit response is sent to this message. However, the
skipping to change at page 11, line 17 skipping to change at page 11, line 17
X11 connection forwarding should stop when the session channel is X11 connection forwarding should stop when the session channel is
closed. However, already opened forwardings should not be closed. However, already opened forwardings should not be
automatically closed when the session channel is closed. automatically closed when the session channel is closed.
If 'single connection' is TRUE, only a single connection should be If 'single connection' is TRUE, only a single connection should be
forwarded. No more connections will be forwarded after the first, or forwarded. No more connections will be forwarded after the first, or
after the session channel has been closed. after the session channel has been closed.
The 'x11 authentication protocol' is the name of the X11 The 'x11 authentication protocol' is the name of the X11
authentication method used, e.g. "MIT-MAGIC-COOKIE-1". authentication method used, e.g., "MIT-MAGIC-COOKIE-1".
The 'x11 authentication cookie' MUST be hexadecimal encoded. The 'x11 authentication cookie' MUST be hexadecimal encoded.
The X Protocol is documented in [SCHEIFLER]. The X Protocol is documented in [SCHEIFLER].
6.3.2 X11 Channels 6.3.2 X11 Channels
X11 channels are opened with a channel open request. The resulting X11 channels are opened with a channel open request. The resulting
channels are independent of the session, and closing the session channels are independent of the session, and closing the session
channel does not close the forwarded X11 channels. channel does not close the forwarded X11 channels.
byte SSH_MSG_CHANNEL_OPEN byte SSH_MSG_CHANNEL_OPEN
string "x11" string "x11"
uint32 sender channel uint32 sender channel
uint32 initial window size uint32 initial window size
uint32 maximum packet size uint32 maximum packet size
string originator address (e.g. "192.168.7.38") string originator address (e.g., "192.168.7.38")
uint32 originator port uint32 originator port
The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION
or SSH_MSG_CHANNEL_OPEN_FAILURE. or SSH_MSG_CHANNEL_OPEN_FAILURE.
Implementations MUST reject any X11 channel open requests if they Implementations MUST reject any X11 channel open requests if they
have not requested X11 forwarding. have not requested X11 forwarding.
6.4 Environment Variable Passing 6.4 Environment Variable Passing
skipping to change at page 16, line 5 skipping to change at page 16, line 5
7.1 Requesting Port Forwarding 7.1 Requesting Port Forwarding
A party need not explicitly request forwardings from its own end to A party need not explicitly request forwardings from its own end to
the other direction. However, if it wishes that connections to a the other direction. However, if it wishes that connections to a
port on the other side be forwarded to the local side, it must port on the other side be forwarded to the local side, it must
explicitly request this. explicitly request this.
byte SSH_MSG_GLOBAL_REQUEST byte SSH_MSG_GLOBAL_REQUEST
string "tcpip-forward" string "tcpip-forward"
boolean want reply boolean want reply
string address to bind (e.g. "0.0.0.0") string address to bind (e.g., "0.0.0.0")
uint32 port number to bind uint32 port number to bind
The 'address to bind' and 'port number to bind' specify the IP The 'address to bind' and 'port number to bind' specify the IP
address and port to which the socket to be listened is bound. The address and port to which the socket to be listened is bound. The
address should be "0.0.0.0" if connections are allowed from anywhere. address should be "0.0.0.0" if connections are allowed from anywhere.
(Note that the client can still filter connections based on (Note that the client can still filter connections based on
information passed in the open request.) information passed in the open request.)
Implementations should only allow forwarding privileged ports if the Implementations should only allow forwarding privileged ports if the
user has been authenticated as a privileged user. user has been authenticated as a privileged user.
skipping to change at page 16, line 35 skipping to change at page 16, line 35
byte SSH_MSG_REQUEST_SUCCESS byte SSH_MSG_REQUEST_SUCCESS
uint32 port that was bound on the server uint32 port that was bound on the server
A port forwarding can be canceled 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
normally only sent by the client. normally only sent by the client.
7.2 TCP/IP Forwarding Channels 7.2 TCP/IP Forwarding Channels
When a connection comes to a port for which remote forwarding has When a connection comes to a port for which remote forwarding has
been requested, a channel is opened to forward the port to the other been requested, a channel is opened to forward the port to the other
side. side.
skipping to change at page 18, line 21 skipping to change at page 18, line 21
The client SHOULD put in the stream any modes it knows about, and the The client SHOULD put in the stream any modes it knows about, and the
server MAY ignore any modes it does not know about. This allows some server MAY ignore any modes it does not know about. This allows some
degree of machine-independence, at least between systems that use a degree of machine-independence, at least between systems that use a
POSIX-like tty interface. The protocol can support other systems as POSIX-like tty interface. The protocol can support other systems as
well, but the client may need to fill reasonable values for a number well, but the client may need to fill reasonable values for a number
of parameters so the server pty gets set to a reasonable mode (the of parameters so the server pty gets set to a reasonable mode (the
server leaves all unspecified mode bits in their default values, and server leaves all unspecified mode bits in their default values, and
only some combinations make sense). only some combinations make sense).
The naming of 'opcode' values mostly follows the POSIX terminal mode The naming of opcode values mostly follows the POSIX terminal mode
flags. The following 'opcode' values have been defined. Note that flags. The following opcode values have been defined. Note that the
the values given below are in decimal format for readability but that values given below are in decimal format for readability but that
they are actually byte values. they are actually byte values.
opcode argument description opcode argument description
------ -------- ----------- ------ -------- -----------
0 TTY_OP_END Indicates end of options. 0 TTY_OP_END Indicates end of options.
1 VINTR Interrupt character; 255 if none. Similarly 1 VINTR Interrupt character; 255 if none. Similarly
for the other characters. Not all of these for the other characters. Not all of these
characters are supported on all systems. characters are supported on all systems.
2 VQUIT The quit character (sends SIGQUIT signal on 2 VQUIT The quit character (sends SIGQUIT signal on
POSIX systems). POSIX systems).
skipping to change at page 20, line 42 skipping to change at page 20, line 42
this document, are detailed in [SSH-NUMBERS]. this document, are detailed in [SSH-NUMBERS].
11. Security Considerations 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.
Full security considerations for this protocol are provided in Full security considerations for this protocol are provided in
[SSH-ARCH]. Specific to this document, it is RECOMMENDED that [SSH-ARCH]. Specific to this document, it is RECOMMENDED that
implementations disable all the potentially dangerous features (e.g. implementations disable all the potentially dangerous features (e.g.,
agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host
key has changed without notice or explanation. key has changed without notice or explanation.
12. References 12. References
12.1 Normative References 12.1 Normative References
[SSH-ARCH] [SSH-ARCH]
Lonvick, C., "SSH Protocol Architecture", I-D Lonvick, C., "SSH Protocol Architecture", I-D
draft-ietf-architecture-18.txt, October 2004. draft-ietf-architecture-19.txt, November 2004.
[SSH-TRANS] [SSH-TRANS]
Lonvick, C., "SSH Transport Layer Protocol", I-D Lonvick, C., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-20.txt, October 2004. draft-ietf-transport-21.txt, November 2004.
[SSH-USERAUTH] [SSH-USERAUTH]
Lonvick, C., "SSH Authentication Protocol", I-D Lonvick, C., "SSH Authentication Protocol", I-D
draft-ietf-userauth-23.txt, October 2004. draft-ietf-userauth-24.txt, November 2004.
[SSH-NUMBERS] [SSH-NUMBERS]
Lonvick, C., "SSH Protocol Assigned Numbers", I-D Lonvick, C., "SSH Protocol Assigned Numbers", I-D
draft-ietf-assignednumbers-08.txt, October 2004. draft-ietf-assignednumbers-09.txt, November 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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
12.2 Informative References 12.2 Informative References
[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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 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, February 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.
 End of changes. 

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