draft-ietf-secsh-break-02.txt   draft-ietf-secsh-break-03.txt 
Secure Shell Working Group J. Galbraith Secure Shell Working Group J. Galbraith
Internet-Draft VanDyke Software Internet-Draft VanDyke Software
Expires: October 18, 2004 P. Remaker Expires: November 24, 2005 P. Remaker
Cisco Systems, Inc Cisco Systems, Inc
April 19, 2004 May 23, 2005
Session Channel Break Extension Secure Shell (SSH) Session Channel Break Extension
draft-ietf-secsh-break-02.txt draft-ietf-secsh-break-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC2026. 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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 October 18, 2004. This Internet-Draft will expire on November 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
The Session Channel Break Extension provides a means to send a BREAK The Session Channel Break Extension provides a means to send a BREAK
signal [2] over an SSH terminal session [5]. signal over a Secure Shell (SSH) terminal session.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Break Request . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in this Document . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 3. The Break Request . . . . . . . . . . . . . . . . . . . . . . 5
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.2 Informative References . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 8 6.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 11
1. Introduction 1. Introduction
The SSH session channel provides a mechanism for the client-user to The Secure Shell (SSH) session channel provides a mechanism for the
interactively enter commands and receive output from a remote host client-user to interactively enter commands and receive output from a
while taking advantage of the SSH transport's privacy and integrity remote host while taking advantage of the SSH transport's privacy and
features. SSH is increasingly being used to replace telnet for integrity features. SSH is increasingly being used to replace Telnet
terminal access applications. for terminal access applications.
A common application of the telnet protocol is the "Console Server" A common application of the Telnet protocol is the "Console Server"
[2] whereby a telnet NVT can be connected to a physical RS-232/V.24 [7] whereby a Telnet Network Virtual Terminal (NVT) can be connected
asynchronous port, making the telnet NVT appear as a locally attached to a physical RS-232/V.24 asynchronous port, making the Telnet NVT
terminal to that port, and making that physical port appear as a appear as a locally attached terminal to that port, and making that
network addressable device. A number of major computer equipment physical port appear as a network addressable device. A number of
vendors provide high level administrative functions through an major computer equipment vendors provide high level administrative
asynchronous serial port and generally expect the attached terminal functions through an asynchronous serial port and generally expect
to be capable of send a BREAK signal. the attached terminal to be capable of send a BREAK signal.
A BREAK signal is defined as the TxD signal being held in a SPACE A BREAK signal is defined as the TxD signal being held in a SPACE
("0") state for a time greater than a whole character time. In ("0") state for a time greater than a whole character time. In
practice, a BREAK signal is typically 250 to 500 ms in length. practice, a BREAK signal is typically 250 to 500 ms in length.
The telnet protocol furnishes a means to send a "BREAK" signal, which The Telnet protocol furnishes a means to send a "BREAK" signal, which
RFC0854 defines as a "a signal outside the USASCII set which is RFC0854 [1] defines as a "a signal outside the USASCII set which is
currently given local meaning within many systems." [1] Console currently given local meaning within many systems." [1] Console
Server vendors interpret the TELNET BREAK signal as a physical BREAK Server vendors interpret the TELNET BREAK signal as a physical BREAK
signal, which can then allow access to the full range of signal, which can then allow access to the full range of
adminisrative functions available on an asynchronous serial console administrative functions available on an asynchronous serial console
port. port.
The lack of a similar facility in the SSH session channel has forced The lack of a similar facility in the SSH session channel has forced
users to continue the use of telnet for the "Console Server" users to continue the use of Telnet for the "Console Server"
function. function.
2. The Break Request 2. Conventions Used in this Document
The following following channel specific request can be sent to The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
request that the remote host perform a BREAK operation. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2].
The "byte", "boolean", "uint32", and "string" data types are defined
in [3].
3. The Break Request
The following channel specific request can be sent over a session
channel to request that the remote host perform a BREAK operation.
byte SSH_MSG_CHANNEL_REQUEST byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel uint32 recipient channel
string "break" string "break"
boolean want_reply boolean want_reply
uint32 break-length in milliseconds uint32 break-length in milliseconds
If the BREAK length cannot be controlled by the application receiving If the BREAK length cannot be controlled by the application receiving
this request, the BREAK length parameter SHOULD be ignored and the this request, the BREAK length parameter SHOULD be ignored and the
default BREAK signal length of the chipset or underlying chipset default BREAK signal length of the chipset or underlying chipset
driver SHOULD be sent. driver SHOULD be sent.
If the application receiving this request can control the If the application receiving this request can control the BREAK-
BREAK-length, the following suggestions are made regarding BREAK length, the following suggestions are made regarding BREAK duration.
duration. If a BREAK duration request of greater than 3000ms is If a BREAK duration request of greater than 3000ms is received, it
received, it SHOULD be processed as a 3000ms BREAK, in order to SHOULD be processed as a 3000ms BREAK, in order to prevent an
prevent an unreasonably long BREAK request causing the port to become unreasonably long BREAK request causing the port to become
unavailable for as long as 49.7 days while executing the BREAK. unavailable for as long as 49.7 days while executing the BREAK.
Applications that require a longer BREAK may choose to ignore this Applications that require a longer BREAK may choose to ignore this
requirement. If BREAK duration request of less than 500ms, is requirement. If BREAK duration request of less than 500ms, is
requested a BREAK of 500ms SHOULD be sent since most devices will requested a BREAK of 500ms SHOULD be sent since most devices will
recognize a BREAK of that length. In the event that an application recognize a BREAK of that length. In the event that an application
needs a shorter BREAK, this suggestion can be ignored. If the needs a shorter BREAK, this suggestion can be ignored. If the BREAK-
BREAK-length parameter is 0, the BREAK SHOULD be sent as 500ms or the length parameter is 0, the BREAK SHOULD be sent as 500ms or the
default BREAK signal length of the chipset or underlying chipset default BREAK signal length of the chipset or underlying chipset
driver. driver.
If the SSH connection does not terminate on a physical serial port, If the SSH connection does not terminate on a physical serial port,
the BREAK indication SHOULD be handled in an implementation-defined the BREAK indication SHOULD be handled in a manner consistent with
manner consistent with the general use of BREAK as an attention/ the general use of BREAK as an attention/interrupt signal; for
interrupt signal; for instance, a service processor could use some instance, a service processor could use some other out-of-band
other out-of-band facility to get the attention of a system it facility to get the attention of a system it manages.
manages.
In a case where an SSH connection cascades to another connection, the In a case where an SSH connection cascades to another connection, the
BREAK SHOULD be passed along the cascaded connection. For example, a BREAK SHOULD be passed along the cascaded connection. For example, a
telnet session from an SSH shell should carry along an SSH initiated Telnet session from an SSH shell should carry along an SSH initiated
BREAK and an SSH client initited from a telnet connection SHOULD pass BREAK and an SSH client initiated from a Telnet connection SHOULD
a BREAK indication from the telnet connection. pass a BREAK indication from the Telnet connection.
If the want_reply boolean is set, the server MUST reply using If the 'want_reply' boolean is set, the server MUST reply using an
SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] messages. If SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] message. If a
a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be
sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be
sent. sent.
This operation SHOULD be supported by any general purpose SSH client. This operation SHOULD be supported by any general purpose SSH client.
3. Security Considerations 4. Security Considerations
Many computer systems treat serial consoles as local and secured, and Many computer systems treat serial consoles as local and secured, and
interpret a BREAK signal as an instruction to halt execution of the interpret a BREAK signal as an instruction to halt execution of the
operating system or to enter priviliged configuration modes. Because operating system or to enter privileged configuration modes. Because
of this, extra care should be taken to ensure that SSH access to of this, extra care should be taken to ensure that SSH access to
BREAK-enabled ports are limited to users with appropriate priviliges BREAK-enabled ports are limited to users with appropriate privileges
to execute such functions. Alternatively, support for the BREAK to execute such functions. Alternatively, support for the BREAK
facility MAY be imlemented configurable or a per port or per server facility MAY be implemented configurable or a per port or per server
basis. basis.
Implementations that literally intepret the BREAK length parameter Implementations that literally interpret the BREAK length parameter
without imposing the suggested BREAK time limit may cause a denial without imposing the suggested BREAK time limit may cause a denial of
of service to or unexpected results from attached devices receiving service to or unexpected results from attached devices receiving the
the very long BREAK signal. very long BREAK signal.
4. References 5. IANA Considerations
4.1 Normative References IANA is requested to assign the Connection Protocol Channel Request
Name "break" in accordance with [6].
[1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 6. References
8, RFC 854, May 1983.
4.2 Informative References 6.1 Normative References
[2] Harris, D., "Greater Scroll of Console Knowledge", March 2004. [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification",
STD 8, RFC 854, May 1983.
[3] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Protocol Architecture", draft-ietf-secsh-architecture-15 (work Levels", BCP 14, RFC 2119, March 1997.
in progress), October 2003.
[4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. [3] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
Lehtinen, "SSH Transport Layer Protocol", draft-ietf-secsh-architecture-22 (work in progress), March 2005.
draft-ietf-secsh-transport-17 (work in progress), October 2003.
[5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH [4] Lonvick, C., "SSH Transport Layer Protocol",
Connection Protocol", draft-ietf-secsh-connect-18 (work in draft-ietf-secsh-transport-24 (work in progress), March 2005.
progress), October 2003.
[5] Lonvick, C. and T. Ylonen, "SSH Connection Protocol",
draft-ietf-secsh-connect-25 (work in progress), March 2005.
[6] Lehtinen, S. and C. Lonvick, "SSH Protocol Assigned Numbers",
draft-ietf-secsh-assignednumbers-12 (work in progress),
March 2005.
6.2 Informative References
[7] Harris, D., "Greater Scroll of Console Knowledge", March 2004,
<http://www.conserver.com/consoles/>.
Authors' Addresses Authors' Addresses
Joseph Galbraith Joseph Galbraith
VanDyke Software VanDyke Software
4848 Tramway Ridge Blvd 4848 Tramway Ridge Blvd
Suite 101 Suite 101
Albuquerque, NM 87111 Albuquerque, NM 87111
US US
Phone: +1 505 332 5700 Phone: +1 505 332 5700
EMail: galb-list@vandyke.com Email: galb-list@vandyke.com
Phillip Remaker Phillip Remaker
Cisco Systems, Inc Cisco Systems, Inc
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95120 San Jose, CA 95120
US US
Phone: +1 408 526 8614 Phone: +1 408 526 8614
EMail: remaker@cisco.com Email: remaker@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 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; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2005). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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/