Subject: WG Chair nits for draft-ietf-secsh-break-00.txt

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 09 Apr 2003 19:20:57 -0400

So, I'd like to do a last-call on this but there are the following
nits which will require a re-spin to resolve:

 1) security considerations section is missing.

s-c fodder: 

 Because "break" is typically used to enter low-level administrative
 or debugging functions, implementors of this extension SHOULD provide
 a mechanism to control whether this extension is accepted, and
 administrators should use care when deciding whether to enable this
 feature.

 2) typos:

> This operation SHOULD be support by most general purpose SSH clients.

"supported"?

>  The telnet protocolprovides a means to send a "BREAK" signal, which

missing space --------^

 3) no mention of what to do when the thing on the other end isn't
    (directly) connected to a traditional serial line.  I'm in favor of
    saying "MAY implement functionally similar implementation-defined
    behavior".   

    examples:
	- a ssh-to-telnet gateway could convert into the equivalent 
	telnet option.
	- a service processor providing remote console access may use some 
	other out-of-band signal to the system it manages rather than
	the traditional BREAK.. 

 4) usual normative/informative reference section gorp: these all look
    normative, so just "s/References/Normative References/"

					- Bill

---

From: "Phillip Remaker" <[email-masked]>
Date: Fri, 11 Apr 2003 10:33:16 -0700

>  1) security considerations section is missing.

I would think that the main security considerations are:

- Denial of service based on a long duration break.  Should be addressed on
the server side
- Unauthorized parties sending break.  Should be addressed by SSH security
freamework.
- There is no means in the protocol to make certain users able to view, but
not send break.  This is optionally addressed on the server side, based on
authentication credentials.  The protocol need not be concerned.
Unauthorized break requests should be treated as if the server does not
support break.

Anything else?  Should we fold all that in?

> other out-of-band signal to the system it manages rather than

OK, excellent.  I like those examples.