idnits 2.17.1 draft-ietf-secsh-break-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2], [5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 97: '...length parameter SHOULD be ignored and...' RFC 2119 keyword, line 99: '... driver SHOULD be sent....' RFC 2119 keyword, line 104: '... received, it SHOULD be processed as...' RFC 2119 keyword, line 109: '...a BREAK of 500ms SHOULD be sent since ...' RFC 2119 keyword, line 112: '... is 0, the BREAK SHOULD be sent as 500...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 19, 2003) is 7556 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 162, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 166, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-14 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-16 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-17 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Shell Working Group J. Galbraith 3 Internet-Draft VanDyke Software 4 Expires: February 17, 2004 P. Remaker 5 Cisco Systems, Inc 6 August 19, 2003 8 Session Channel Break Extension 9 draft-ietf-secsh-break-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on February 17, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 The Session Channel Break Extension provides a means to send a BREAK 40 signal [2] over an SSH terminal session [5]. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. The Break Request . . . . . . . . . . . . . . . . . . . . . . . 4 46 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 47 Normative References . . . . . . . . . . . . . . . . . . . . . . 7 48 Informative References . . . . . . . . . . . . . . . . . . . . . 8 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 50 Intellectual Property and Copyright Statements . . . . . . . . . 9 52 1. Introduction 54 The SSH session channel provides a mechanism for the client-user to 55 interactively enter commands and receive output from a remote host 56 while taking advantage of the SSH transport's privacy and integrity 57 features. SSH is increasingly being used to replace telnet for 58 terminal access applications. 60 A common application of the telnet protocol is the "Console Server" 61 [2] whereby a telnet NVT can be connected to a physical RS-232/V.24 62 asynchronous port, making the telnet NVT appear as a locally attached 63 terminal to that port, and making that physical port appear as a 64 network addressable device. A number of major computer equipment 65 vendors provide high level administrative functions through an 66 asynchronous serial port and generally expect the attached terminal 67 to be capable of send a BREAK signal. 69 A BREAK signal is defined as the TxD signal being held in a SPACE 70 ("0") state for a time greater than a whole character time. In 71 practice, a BREAK signal is typically 250 to 500 ms in length. 73 The telnet protocol furnishes a means to send a "BREAK" signal, which 74 RFC0854 defines as a "a signal outside the USASCII set which is 75 currently given local meaning within many systems." [1] Console 76 Server vendors interpret the TELNET BREAK signal as a physical BREAK 77 signal, which can then allow access to the full range of 78 adminisrative functions available on an asynchronous serial console 79 port. 81 The lack of a similar facility in the SSH session channel has forced 82 users to continue the use of telnet for the "Console Server" 83 function. 85 2. The Break Request 87 The following following channel specific request can be sent to 88 request that the remote host perform a BREAK operation. 90 byte SSH_MSG_CHANNEL_REQUEST 91 uint32 recipient channel 92 string "break" 93 boolean want_reply 94 uint32 break-length in milliseconds 96 If the BREAK length cannot be controlled by the application receiving 97 this request, the BREAK length parameter SHOULD be ignored and the 98 default BREAK signal length of the chipset or underlying chipset 99 driver SHOULD be sent. 101 If the application receiving this request can control the 102 BREAK-length, the following suggestions are made regarding BREAK 103 duration. If a BREAK duration request of greater than 3000ms is 104 received, it SHOULD be processed as a 3000ms BREAK, in order to 105 prevent an unreasonably long BREAK request causing the port to become 106 unavailable for as long as 49.7 days while executing the BREAK. 107 Applications that require a longer BREAK may choose to ignore this 108 requirement. If BREAK duration request of less than 500ms, is 109 requested a BREAK of 500ms SHOULD be sent since most devices will 110 recognize a BREAK of that length. In the event that an application 111 needs a shorter BREAK, this suggestion can be ignored. If the 112 BREAK-length parameter is 0, the BREAK SHOULD be sent as 500ms or the 113 default BREAK signal length of the chipset or underlying chipset 114 driver. 116 If the SSH connection does not terminate on a physical serial port, 117 the BREAK indication SHOULD be handled in an implementation-defined 118 manner consistent with the general use of BREAK as an attention/ 119 interrupt signal; for instance, a service processor could use some 120 other out-of-band facility to get the attention of a system it 121 manages. 123 In a case where an SSH connection cascades to another connection, the 124 BREAK SHOULD be passed along the cascaded connection. For example, a 125 telnet session from an SSH shell should carry along an SSH initiated 126 BREAK and an SSH client initited from a telnet connection SHOULD pass 127 a BREAK indication from the telnet connection. 129 If the want_reply boolean is set, the server MUST reply using 130 SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] messages. If 131 a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be 132 sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be 133 sent. 135 This operation SHOULD be supported by any general purpose SSH client. 137 3. Security Considerations 139 Many computer systems treat serial consoles as local and secured, and 140 interpret a BREAK signal as an instruction to halt execution of the 141 operating system or to enter priviliged configuration modes. Because 142 of this, extra care should be taken to ensure that SSH access to 143 BREAK-enabled ports are limited to users with appropriate priviliges 144 to execute such functions. Alternatively, support for the BREAK 145 facility MAY be imlemented configurable or a per port or per server 146 basis. 148 Implementations that literally intepret the BREAK length parameter 149 without imposing the suggested BREAK time limit may cause a denial 150 of service to or unexpected results from attached devices receiving 151 the very long BREAK signal. 153 Normative References 155 [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 156 8, RFC 854, May 1983. 158 Informative References 160 [2] Harris, D., "Greater Scroll of Console Knowledge", April 2003. 162 [3] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH 163 Protocol Architecture", draft-ietf-secsh-architecture-14 (work 164 in progress), July 2003. 166 [4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. 167 Lehtinen, "SSH Transport Layer Protocol", 168 draft-ietf-secsh-transport-16 (work in progress), July 2003. 170 [5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH 171 Connection Protocol", draft-ietf-secsh-connect-17 (work in 172 progress), July 2003. 174 Authors' Addresses 176 Joseph Galbraith 177 VanDyke Software 178 4848 Tramway Ridge Blvd 179 Suite 101 180 Albuquerque, NM 87111 181 US 183 Phone: +1 505 332 5700 184 EMail: galb-list@vandyke.com 186 Phillip Remaker 187 Cisco Systems, Inc 188 170 West Tasman Drive 189 San Jose, CA 95120 190 US 192 EMail: remaker@cisco.com 194 Intellectual Property Statement 196 The IETF takes no position regarding the validity or scope of any 197 intellectual property or other rights that might be claimed to 198 pertain to the implementation or use of the technology described in 199 this document or the extent to which any license under such rights 200 might or might not be available; neither does it represent that it 201 has made any effort to identify any such rights. Information on the 202 IETF's procedures with respect to rights in standards-track and 203 standards-related documentation can be found in BCP-11. Copies of 204 claims of rights made available for publication and any assurances of 205 licenses to be made available, or the result of an attempt made to 206 obtain a general license or permission for the use of such 207 proprietary rights by implementors or users of this specification can 208 be obtained from the IETF Secretariat. 210 The IETF invites any interested party to bring to its attention any 211 copyrights, patents or patent applications, or other proprietary 212 rights which may cover technology that may be required to practice 213 this standard. Please address the information to the IETF Executive 214 Director. 216 Full Copyright Statement 218 Copyright (C) The Internet Society (2003). All Rights Reserved. 220 This document and translations of it may be copied and furnished to 221 others, and derivative works that comment on or otherwise explain it 222 or assist in its implementation may be prepared, copied, published 223 and distributed, in whole or in part, without restriction of any 224 kind, provided that the above copyright notice and this paragraph are 225 included on all such copies and derivative works. However, this 226 document itself may not be modified in any way, such as by removing 227 the copyright notice or references to the Internet Society or other 228 Internet organizations, except as needed for the purpose of 229 developing Internet standards in which case the procedures for 230 copyrights defined in the Internet Standards process must be 231 followed, or as required to translate it into languages other than 232 English. 234 The limited permissions granted above are perpetual and will not be 235 revoked by the Internet Society or its successors or assignees. 237 This document and the information contained herein is provided on an 238 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 239 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 240 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 241 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 242 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 244 Acknowledgement 246 Funding for the RFC Editor function is currently provided by the 247 Internet Society.