idnits 2.17.1 draft-ietf-secsh-break-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 244. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 108 has weird spacing: '...boolean want...' -- 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 (July 15, 2005) is 6861 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: '4' is defined on line 187, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 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: January 16, 2006 P. Remaker 5 Cisco Systems, Inc 6 July 15, 2005 8 Secure Shell (SSH) Session Channel Break Extension 9 draft-ietf-secsh-break-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 16, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The Session Channel Break Extension provides a means to send a BREAK 43 signal over a Secure Shell (SSH) terminal session. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 49 3. The Break Request . . . . . . . . . . . . . . . . . . . . . . 5 50 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 51 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 52 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 53 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 54 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 56 Intellectual Property and Copyright Statements . . . . . . . . 11 58 1. Introduction 60 The Secure Shell (SSH) session channel provides a mechanism for the 61 client-user to interactively enter commands and receive output from a 62 remote host while taking advantage of the SSH transport's privacy and 63 integrity features. SSH is increasingly being used to replace Telnet 64 for terminal access applications. 66 A common application of the Telnet protocol is the "Console Server" 67 [7] whereby a Telnet Network Virtual Terminal (NVT) can be connected 68 to a physical RS-232/V.24 asynchronous port, making the Telnet NVT 69 appear as a locally attached terminal to that port, and making that 70 physical port appear as a network addressable device. A number of 71 major computer equipment vendors provide high level administrative 72 functions through an asynchronous serial port and generally expect 73 the attached terminal to be capable of sending a BREAK signal. 75 A BREAK signal is defined as the TxD signal being held in a SPACE 76 ("0") state for a time greater than a whole character time. In 77 practice, a BREAK signal is typically 250 to 500 ms in length. 79 The Telnet protocol furnishes a means to send a "BREAK" signal, which 80 RFC0854 [1] defines as a "a signal outside the USASCII set which is 81 currently given local meaning within many systems." [1] Console 82 Server vendors interpret the TELNET BREAK signal as a physical BREAK 83 signal, which can then allow access to the full range of 84 administrative functions available on an asynchronous serial console 85 port. 87 The lack of a similar facility in the SSH session channel has forced 88 users to continue the use of Telnet for the "Console Server" 89 function. 91 2. Conventions Used in this Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [2]. 97 The "byte", "boolean", "uint32", and "string" data types are defined 98 in [3]. 100 3. The Break Request 102 The following channel specific request can be sent over a session 103 channel to request that the remote host perform a BREAK operation. 105 byte SSH_MSG_CHANNEL_REQUEST 106 uint32 recipient channel 107 string "break" 108 boolean want_reply 109 uint32 break-length in milliseconds 111 If the BREAK length cannot be controlled by the application receiving 112 this request, the BREAK length parameter SHOULD be ignored and the 113 default BREAK signal length of the chipset or underlying chipset 114 driver SHOULD be sent. If no default exists, 500ms can be used as 115 the BREAK length. 117 If the application receiving this request can control the BREAK- 118 length, the following suggestions are made regarding BREAK duration. 119 If a BREAK duration request of greater than 3000ms is received, it 120 SHOULD be intepreted as a request for a 3000ms BREAK. This safeguard 121 prevents an unreasonably long BREAK request from causing a port to 122 become unavailable for as long as 49.7 days while executing the 123 BREAK. Applications that require a longer BREAK may choose to ignore 124 this suggestion. If BREAK duration request of less than 500ms is 125 received, it SHOULD be interpreted as a 500ms BREAK since most 126 devices will recognize a BREAK of that length. Applications that 127 require a shorter BREAK may choose to ignore this suggestion. If the 128 BREAK-length parameter is 0 or not present, the BREAK SHOULD be 129 interpreted as the default BREAK signal length of the chipset or 130 underlying chipset driver. If no default exists, 500ms can be used 131 as the BREAK length. 133 If the SSH connection does not terminate on a physical serial port, 134 the BREAK indication SHOULD be handled in a manner consistent with 135 the general use of BREAK as an attention/interrupt signal; for 136 instance, a service processor which requires an out-of-band facility 137 to get the attention of a system it manages. 139 In a case where an SSH connection cascades to another connection, the 140 BREAK SHOULD be passed along the cascaded connection. For example, a 141 Telnet session from an SSH shell should carry along an SSH initiated 142 BREAK and an SSH client initiated from a Telnet connection SHOULD 143 pass a BREAK indication from the Telnet connection. 145 If the 'want_reply' boolean is set, the server MUST reply using an 146 SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] message. If a 147 BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be 148 sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be 149 sent. 151 This operation SHOULD be supported by any general purpose SSH client. 153 4. Security Considerations 155 Many computer systems treat serial consoles as local and secured, and 156 interpret a BREAK signal as an instruction to halt execution of the 157 operating system or to enter privileged configuration modes. Because 158 of this, extra care should be taken to ensure that SSH access to 159 BREAK-enabled ports are limited to users with appropriate privileges 160 to execute such functions. Alternatively, support for the BREAK 161 facility MAY be implemented as configurable on a per-port or per- 162 server basis. 164 Implementations that literally interpret the BREAK length parameter 165 without imposing the suggested BREAK time limit may cause a denial of 166 service to or unexpected results from attached devices receiving the 167 very long BREAK signal. 169 5. IANA Considerations 171 IANA is requested to assign the Connection Protocol Channel Request 172 Name "break" in accordance with [6]. 174 6. References 176 6.1 Normative References 178 [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", 179 STD 8, RFC 854, May 1983. 181 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 182 Levels", BCP 14, RFC 2119, March 1997. 184 [3] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 185 draft-ietf-secsh-architecture-22 (work in progress), March 2005. 187 [4] Lonvick, C., "SSH Transport Layer Protocol", 188 draft-ietf-secsh-transport-24 (work in progress), March 2005. 190 [5] Lonvick, C. and T. Ylonen, "SSH Connection Protocol", 191 draft-ietf-secsh-connect-25 (work in progress), March 2005. 193 [6] Lehtinen, S. and C. Lonvick, "SSH Protocol Assigned Numbers", 194 draft-ietf-secsh-assignednumbers-12 (work in progress), 195 March 2005. 197 6.2 Informative References 199 [7] Harris, D., "Greater Scroll of Console Knowledge", March 2004, 200 . 202 Authors' Addresses 204 Joseph Galbraith 205 VanDyke Software 206 4848 Tramway Ridge Blvd 207 Suite 101 208 Albuquerque, NM 87111 209 US 211 Phone: +1 505 332 5700 212 Email: galb-list@vandyke.com 213 Phillip Remaker 214 Cisco Systems, Inc 215 170 West Tasman Drive 216 San Jose, CA 95120 217 US 219 Phone: +1 408 526 8614 220 Email: remaker@cisco.com 222 Intellectual Property Statement 224 The IETF takes no position regarding the validity or scope of any 225 Intellectual Property Rights or other rights that might be claimed to 226 pertain to the implementation or use of the technology described in 227 this document or the extent to which any license under such rights 228 might or might not be available; nor does it represent that it has 229 made any independent effort to identify any such rights. Information 230 on the procedures with respect to rights in RFC documents can be 231 found in BCP 78 and BCP 79. 233 Copies of IPR disclosures made to the IETF Secretariat and any 234 assurances of licenses to be made available, or the result of an 235 attempt made to obtain a general license or permission for the use of 236 such proprietary rights by implementers or users of this 237 specification can be obtained from the IETF on-line IPR repository at 238 http://www.ietf.org/ipr. 240 The IETF invites any interested party to bring to its attention any 241 copyrights, patents or patent applications, or other proprietary 242 rights that may cover technology that may be required to implement 243 this standard. Please address the information to the IETF at 244 ietf-ipr@ietf.org. 246 Disclaimer of Validity 248 This document and the information contained herein are provided on an 249 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 250 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 251 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 252 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 253 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 254 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 256 Copyright Statement 258 Copyright (C) The Internet Society (2005). This document is subject 259 to the rights, licenses and restrictions contained in BCP 78, and 260 except as set forth therein, the authors retain all their rights. 262 Acknowledgment 264 Funding for the RFC Editor function is currently provided by the 265 Internet Society.