IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

authors 48 hours: RFC 4251 <draft-ietf-secsh-architecture-22.txt> NOW AVAILABLE (fwd)



Hi,

Again.

Thanks,
Chris

===

1)
There is an inconsistency in the spellings of "implementer" and
"implementor".  Since all other RFCs use "implementer" in their
Intellectual Property section, please change all instances of
"implementor" to "implementer".



2)
Section 4.1, 5th paragraph
- insert a clause in a line
OLD:
   available on the Internet, this option makes the protocol much more
NEW:
   available on the Internet at the time of this writing, this option
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   makes the protocol much more...



3)
Section 4.1, last paragraph
-  restore the previous wording
OLD:
   Thus, providing the option to not check the server host key is
                              ^^^^^^
NEW:
   Thus, providing the option not to check the server host key is
                              ^^^^^^



4)
Section 4.3, third bullet in the first paragraph
- modify a line
OLD:
   depend on the location from which the user is trying to log in.
NEW:
   depend on the location from where the client is trying to gain
   access.



5)
Section 4.4, last paragraph
- modify a line
OLD:
   Specific concessions were made to make widespread fast deployment
NEW:
   Specific concessions were made to make widespread, fast deployment
                                                    ^


6)
Section 4.5, next to last paragraph
- reword the last line
OLD:
   names.  Straight, bit-wise, binary comparison is RECOMMENDED.
                   ^         ^
NEW:
   names.  Straight bit-wise binary comparison is RECOMMENDED.



7)
Section 5.4, third paragraph
- remove a comma
OLD:
  names.  Straight, bit-wise, binary comparison is RECOMMENDED.
                  ^
NEW:
  names.  Straight bit-wise, binary comparison is RECOMMENDED.




8)
Section 6, first bullet in second paragraph
- add a clause
OLD:
      at-sign ("@"), a comma (","), whitespace, or control characters
                                                ^^^
      (ASCII codes 32 or less).  Names are case-sensitive, and MUST NOT
NEW:
      at-sign ("@"), a comma (","), whitespace, control characters
      (ASCII codes 32 or less), or the ASCII code 127 (DEL).  Names are
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      case-sensitive, and MUST NOT



9)
Section 6, second bullet in second paragraph
- replace the bullet/paragraph
OLD:
   o  Anyone can define additional algorithms or methods by using names
      in the format name@domainname, e.g., "ourcipher-cbc%example.com@localhost".
      The format of the part preceding the at-sign is not specified;
      however, these names MUST be printable US-ASCII strings, and MUST
      NOT contain the comma character (","), whitespace, or control
      characters (ASCII codes 32 or less).  The part following the
      at-sign MUST be a valid, fully qualified domain name [RFC1034]
      controlled by the person or organization defining the name.  Names
      are case-sensitive, and MUST NOT be longer than 64 characters.  It
      is up to each domain how it manages its local namespace.  It
      should be noted that these names resemble STD 11 [RFC0822] email
      addresses.  This is purely coincidental and has nothing to do with
      STD 11 [RFC0822].
NEW:
   o  Anyone can define additional algorithms or methods by using names
      in the format name@domainname, e.g., "ourcipher-cbc%example.com@localhost".
      The format of the part preceding the at-sign is not specified;
      however, these names MUST be printable US-ASCII strings, and MUST
      NOT contain the comma character (","), whitespace, control
      characters (ASCII codes 32 or less), or the ASCII code 127 (DEL).
      They MUST have only a single at-sign in them.  The part following
      the at-sign MUST be a valid, fully qualified domain name [RFC1034]
      controlled by the person or organization defining the name.  Names
      are case-sensitive, and MUST NOT be longer than 64 characters.  It
      is up to each domain how it manages its local namespace.  It
      should be noted that these names resemble STD 11 [RFC0822] email
      addresses.  This is purely coincidental and has nothing to do with
      STD 11 [RFC0822].


10)
Section 8, third paragraph
- replace the paragraph
OLD:
   These names MUST be printable US-ASCII strings, and MUST NOT contain
   the characters at-sign ("@"), comma (","), whitespace, or control
   characters (ASCII codes 32 or less).  Names are case-sensitive, and
   MUST NOT be longer than 64 characters.
NEW:
   These names MUST be printable US-ASCII strings, and MUST NOT contain
   the characters at-sign ("@"), comma (","), whitespace, control
   characters (ASCII codes 32 or less), or the ASCII code 127 (DEL).
   Names are case-sensitive, and MUST NOT be longer than 64 characters.



11)
Section 8, last paragraph
- replace the paragraph
OLD:
   Message numbers (see Section 7) in the range of 0..191 are allocated
   via IETF CONSENSUS as described in [RFC2434].  Message numbers in the
   192..255 range (the "Local extensions" set) are reserved for PRIVATE
   USE, also as described in [RFC2434].
NEW:
   Message numbers (see Section 7) in the range of 0 to 191 are allocated
   via IETF CONSENSUS, as described in [RFC2434].  Message numbers in the
   192 to 255 range (local extensions) are reserved for PRIVATE USE, also
   as described in [RFC2434].



12)
Section 9, fourth paragraph
- replace the paragraph
OLD:
   The connection protocol [SSH-CONNECT] specifies a mechanism to
   multiplex multiple streams (channels) of data over the confidential
   and authenticated transport.  It also specifies channels for
   accessing an interactive shell, for 'proxy-forwarding' various
   external protocols over the secure transport (including arbitrary
   TCP/IP protocols), and for accessing secure 'subsystems' on the
   server host.
NEW:
   The connection protocol [SSH-CONNECT] specifies a mechanism to
   multiplex multiple streams (channels) of data over the confidential
   and authenticated transport.  It also specifies channels for
   accessing an interactive shell, for proxy-forwarding various
   external protocols over the secure transport (including arbitrary
   TCP/IP protocols), and for accessing secure subsystems on the
   server host.



13)
Section 9.2
- replace a line
OLD:
   When displaying text, such as error or debug messages to the user,
New:
   When displaying text to a user, such as error or debug messages,



14)
Section 9.3.1, third paragraph
- replace a word in a line
OLD:
   considered fully practicable, especially if relatively longer block
                                                          ^^^^^^
NEW:
   considered fully practicable, especially if relatively long block



15)
Section 9.3.1, fourth paragraph
- remove a comma
OLD:
   of the next block that is going to be encrypted.  In CBC mode, that
                                                                ^
NEW:
   of the next block that is going to be encrypted.  In CBC mode that



16)
Section 9.3.1, fifth paragraph
- change a word
OLD:
   from the kernel or buffers.  If there are no unsent packages, then a
                                                       ^^^^^^^^
NEW:
   from the kernel or buffers.  If there are no unsent packets, then a



17)
Section 9.3.1, seventh paragraph, bullet "2"
- replace a word in a line
OLD:
   2. Record 2 is *not* at the beginning of the TCP segment and never
                  ^^^^^
NEW:
   2. Record 2 is not at the beginning of the TCP segment and never



18)
Section 9.3.1, eighth paragraph
- replace the paragraph
OLD:
   As this example indicates, it's totally unsafe to use the existence
   of unflushed data in the TCP buffers proper as a guide to whether you
   need an empty packet, since when you do the second write(), the
   buffers will contain the un-ACKed Record 1.
NEW:
   As this example indicates, it is unsafe to use the existence of
   unflushed data in the TCP buffers proper as a guide to whether an
   empty packet is needed, since when the second write() is performed the
   buffers will contain the un-ACKed Record 1.



19)
Section 9.3.1, ninth paragraph
- replace a word in the first line
OLD:
   On the other hand, it's perfectly safe to have the following
                      ^^^^
NEW:
   On the other hand, it is perfectly safe to have the following



20)
Section 9.3.3, first paragraph
- add a reference
OLD:
   protocol uses this to prevent replay of signatures from previous
NEW:
   protocol ([SSH-USERAUTH]) uses this to prevent replay of signatures
   from previous...



21)
In Section 9.3.3, second paragraph
- remove a word in the second paragraph
OLD:
   more so true when specifying larger hash function outputs and DH
        ^^
NEW:
   more true when specifying larger hash function outputs and DH



22)
Section 9.3.3, third paragraph
- remove an inserted comma
OLD:
the session stays active long enough, however, this sequence number number, will wrap ^
NEW:
the session stays active long enough, however, this sequence number number
   will wrap.



23)
Section 9.3.4, last paragraph
- modify some words
OLD:
   non-security critical environments, and will still provide protection
               ^
NEW:
   non-security-critical environments, and will still provide protection



24)
Section 9.3.5, first paragraph
- remove double quotes
OLD:
   Denial of service attacks of this type ("wire cutter") are almost
                                           ^           ^
NEW:
   Denial of service attacks of this type (wire cutter) are almost



25)
Section 9.3.5, last paragraph
- change wording
OLD:
   of IPs known to have valid users.
      ^^^
NEW:
   of clients known to have valid users.



26)
Section 9.3.7, first paragraph
- remove double quotes
OLD:
   the diffie-hellman methods described in the section "Diffie-Hellman
                                                       ^
   Key Exchange" of [SSH-TRANS] (including diffie-hellman-group1-sha1
               ^
NEW:
   the diffie-hellman methods described in the section Diffie-Hellman
   Key Exchange of [SSH-TRANS] (including "diffie-hellman-group1-sha1"
                                          ^                          ^


27)
Section 9.3.8, first paragraph
- remove double quotes
OLD:
   As stated in the section on "Algorithm Negotiation" of [SSH-TRANS],
                               ^                     ^
NEW:
   As stated in the section on Algorithm Negotiation of [SSH-TRANS],



28)
Section 9.3.9,
- change a word
OLD:
   attempts of traffic analysis.  Other methods may also be found and
            ^^
NEW:
   attempts at traffic analysis.  Other methods may also be found and



29)
Section 9.4, last paragraph
- remove double quotes
OLD:
   The server may go into a "sleep" period after repeated unsuccessful
                            ^     ^
NEW:
   The server may go into a sleep period after repeated unsuccessful



30)
Section 9.4.3, second paragraph
- remove single quotes and add a hyphen
OLD:
   lines of 'anything goes' where there are no restrictions placed upon
            ^        ^    ^
NEW:
   lines of anything-goes where there are no restrictions placed upon



31)
Section 9.4.3, second paragraph
- remove single quotes and add a hyphen
OLD:
   users, or it may be along the lines of 'excessively restrictive', in
                                          ^           ^           ^
NEW:
   users, or it may be along the lines of excessively-restrictive, in



32)
Section 9.4.3, last paragraph
- change wording in a line
OLD:
   this policy to meet their needs.  Alternatively, it may be some
   ^^^^^^^^^^^
NEW:
   the initial default parameters to meet their needs.  Alternatively,
   it may be some...



33)
Section 9.4.3, last paragraph
- change case of MUST
OLD:
   effort to get SSH working.  Whatever choice is made MUST be applied
                                                       ^^^^
NEW:
   effort to get SSH working.  Whatever choice is made must be applied



34)
Section 9.4.4, last paragraph
- change words in the last line
OLD:
   server (see section on password authentication below.)
                          ^        ^
NEW:
   server (see the section on Password Authentication below.)
               ^^^


35)
Section 9.5.1, last two paragraphs
- combine the paragraphs and make some nit changes
OLD:
   If the client end point has been compromised, and the server fails to
   stop the attacker at the authentication protocol, all services
   exposed (either as subsystems or through forwarding) will be
   vulnerable to attack.  Implementors SHOULD provide mechanisms for
   administrators to control which services are exposed to limit the
   vulnerability of other services.

   These controls might include controlling which machines and ports can
   be targeted in 'port-forwarding' operations, which users are allowed
   to use interactive shell facilities, or which users are allowed to
   use exposed subsystems.
NEW:
   If the client has been compromised, and the server fails to stop the
   attacker at the authentication protocol, all services exposed
   (either as subsystems or through forwarding) will be vulnerable to
   attack.  Implementers SHOULD provide mechanisms for administrators
   to control which services are exposed to limit the vulnerability of
   other services.  These controls might include controlling which
   machines and ports can be targeted in port-forwarding operations,
   which users are allowed to use interactive shell facilities, or
   which users are allowed to use exposed subsystems.



36)
Section 10.2
- modify the reference to FIPS-180-2
OLD:
   [FIPS-180-2]       National Institute of Standards and Technology,
NEW:
   [FIPS-180-2]       US National Institute of Standards and Technology,



37)
Section 10.2
- modify the reference to FIPS-186-2
OLD:
   [FIPS-186-2]       National Institute of Standards and Technology,
NEW:
   [FIPS-186-2]       US National Institute of Standards and Technology,



38)
Section 10.2
- properly indent the reference for FIPS-197 and modify
OLD:
                      [FIPS-197]         National Institute of Standards
NEW:
   [FIPS-197]         US National Institute of Standards and Technology,

===

---------- Forwarded message ----------
Date: Wed, 26 Oct 2005 16:11:01 -0700
From: RFC Editor <rfc-editor%rfc-editor.org@localhost>
To: ylo%ssh.com@localhost, clonvick%cisco.com@localhost
Cc: RFC Editor <rfc-editor%rfc-editor.org@localhost>, Russ Housley <housley%vigilsec.com@localhost>,
    Sam Hartman <hartmans-ietf%mit.edu@localhost>, sommerfeld%sun.com@localhost
Subject: authors 48 hours: RFC 4251 <draft-ietf-secsh-architecture-22.txt> NOW
    AVAILABLE

****IMPORTANT*****

Updated 2005/10/26

RFC AUTHOR(S):
--------------

This is your LAST CHANCE to make changes to your RFC to be:
draft-ietf-secsh-architecture-22.txt, once the document is published
as an RFC we *WILL NOT* make any changes.

Please check your document at

   ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251.txt

ATTENTION: The editing process occasionally introduces errors that
were not in the Internet Draft.  Although the RFC Editor tries very
hard to catch all errors, proofreading the text at least twice, typos
can slip through.  You, as an author of the RFC, are taking
responsibility for the correctness of the final product when you OK
publication.  You should therefore proofread the entire RFC carefully
and without assumptions.  Errors in RFCs last forever.

NOTE: We have run a diff tool that compares the approved internet-draft
against our edited RFC version of the document.  Please review this
file at:

   ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251-diff.html

The document will NOT BE PUBLISHED until ALL of the authors listed in
the RFC have affirmed that the document is ready to be
published, as ALL of the authors are equally responsible for verifying
the documents readiness for publication.

** Please send us a list of suitable keywords for this document, over
and above those which appear in the title.

	Frequently INCORRECT information includes

	- Contact Information
	- References (are they up to date)
	- Section Numbers
	  (especially if you originally put the copyright somewhere
	  other than the VERY end of the document, or if you numbered
	  the "Status of the Memo" field)

Please send us the changes, *DO NOT* send a new document with the
changes made.  (If we think that the changes might be more than
editorial we will contact the AD or the IESG to confirm that the
changes do not require review.)

Send us the changes in THIS format.

	1)*** SECTION #'s***  [i.e. Section 5, 2nd paragraph]
	2) the text you want changed,
	3) the new correct text and
	4) if the changes are spacing or indentation than please note
	   that.

FOR EXAMPLE:

	Section 5.6, 3rd paragraph

 	OLD:
		The quick brown fox jumped over the lazy dog.

	NEW:
		The quick brown dog jumps over the lazy fox.
				^^^     ^               ^^^

If you have a whole paragraph to replace you do not need to use
the arrow to point out the differences

	INTRODUCTION, 2nd paragraph

	Replace OLD:

		alsdfja;sldjf;lajsd;fljas;dlfj;

	With NEW:

		nv;alkjd;lsf;aoisj;ltjka;sldkjf


Spacing or indentation problems...

	Section 10, 1st paragraph (remove spaces between bit
	and of, add space after butter)

	OLD:

	Better botter bought a bit
		of bitter butterMary mary quite contrary

	NEW:

	Better botter bought a bit of bitter butter

	Mary mary quite contrary


This document will NOT be published until we receive agreement, from
ALL listed authors, that the document is ready for publication.

Thanks for your cooperation,


-RFC Editor



Home | Main Index | Thread Index | Old Index