authors 48 hours: RFC 4253 <draft-ietf-secsh-transport-24.txt> NOW AVAILABLE (fwd)

[Chris Lonvick <clonvick%cisco.com@localhost>]

Once more...

===

1)
Section 4, first paragaph
- remove a comma
OLD:
   SSH works over any 8-bit, clean, binary-transparent transport.  The
                           ^
NEW:
   SSH works over any 8-bit clean, binary-transparent transport.  The



2)
Section 5.1, first paragraph
- replace the paragraph
OLD:
   Server implementations MAY support a configurable "compatibility"
   flag that enables compatibility with old versions.  When this flag is
   on, the server SHOULD identify its protocol version as "1.99".
   Clients using protocol 2.0 MUST be able to identify this as identical
   to "2.0".  In this mode, the server SHOULD NOT send the carriage
   return character (ASCII 13) after the version identification string.
NEW:
   Server implementations MAY support a configurable compatibility
   flag that enables compatibility with old versions.  When this flag is
   on, the server SHOULD identify its 'protoversion' as "1.99".
   Clients using protocol 2.0 MUST be able to identify this as identical
   to "2.0".  In this mode, the server SHOULD NOT send the Carriage
   Return character (ASCII 13) after the identification string.



3)
Section 5.1, second paragraph
- replace the paragraph
OLD:
   In the compatibility mode, the server SHOULD NOT send any further
   data after its initialization string until it has received an
   identification string from the client.  The server can then determine
   whether the client is using an old protocol, and can revert to the
   old protocol if required.  In the compatibility mode, the server MUST
   NOT send additional data before the version string.
NEW:
   In the compatibility mode, the server SHOULD NOT send any further
   data after sending its identification string until it has received an
   identification string from the client.  The server can then determine
   whether the client is using an old protocol, and can revert to the
   old protocol if required.  In the compatibility mode, the server MUST
   NOT send additional data before the identification string.



4)
Section 5.2, first paragraph
- reword the second line
OLD:
   identification string (before receiving server's identification), the
NEW:
   identification string (before receiving the server's identification
   string), the



5)
Section 6.1, first paragraph
- revise a line
OLD:
   larger packets MAY be sent if the version string indicates that the
                                     ^^^^^^^
NEW:
   larger packets MAY be sent if the identification string indicates that 
the
                                     ^^^^^^^^^^^^^^


6)
Section 6.1, first paragraph
- revise a line
OLD:
   than uncompressed size.
NEW:
   than the uncompressed length noted above.


7)
Section 6.4, third paragraph
- replace the paragraph
OLD:
   where 'unencrypted_packet' is the entire packet without 'mac' (the
   length fields, 'payload' and 'random padding'), and 'sequence_number'
   is an implicit packet sequence number represented as uint32.  The
   'sequence_number' is initialized to zero for the first packet, and is
   incremented after every packet (regardless of whether encryption or
   MAC is in use).  It is never reset, even if keys/algorithms are
   renegotiated later.  It wraps around to zero after every 2^32
   packets.  The packet 'sequence_number' itself is not included in the
   packet sent over the wire.
NEW:
   where unencrypted_packet is the entire packet without 'mac' (the
   length fields, 'payload' and 'random padding'), and sequence_number
   is an implicit packet sequence number represented as uint32.  The
   sequence_number is initialized to zero for the first packet, and is
   incremented after every packet (regardless of whether encryption or
   MAC is in use).  It is never reset, even if keys/algorithms are
   renegotiated later.  It wraps around to zero after every 2^32
   packets.  The packet sequence_number itself is not included in the
   packet sent over the wire.



8)
Section 6.4, fourth paragraph
- add a sentence
OLD:
   The MAC algorithms for each direction MUST run independently, and
   implementations MUST allow choosing the algorithm independently for
   both directions.
NEW:
   The MAC algorithms for each direction MUST run independently, and
   implementations MUST allow choosing the algorithm independently for
   both directions.  In practice however, it is RECOMMENDED that the
   same algorithm be used in both directions.



9)
Section 7, 5th paragraph
- replace the paragraph
OLD:
   A key exchange method uses "explicit server authentication" if the
   key exchange messages include a signature or other proof of the
   server's authenticity.  A key exchange method uses "implicit server
   authentication" if, in order to prove its authenticity, the server
   also has to prove that it knows the shared secret, K, by sending a
   message and a corresponding MAC that the client can verify.
NEW:
   A key exchange method uses explicit server authentication if the
   key exchange messages include a signature or other proof of the
   server's authenticity.  A key exchange method uses implicit server
   authentication if, in order to prove its authenticity, the server
   also has to prove that it knows the shared secret, K, by sending a
   message and a corresponding MAC that the client can verify.



10)
Section 7.1, packet description
- please do not split this over a page boundary



11)
Section 7.1, fourth paragraph (not including bulleted items)
- add keywords
OLD:
   After the KEXINIT packet exchange, the key exchange algorithm is run.
NEW:
   After the SSH_MSG_KEXINIT message exchange, the key exchange
   algorithm is run. ...



12)
Section 7.1, fifth paragraph and bulleted items
- replace the paragraph an bullet
OLD:
   Once a party has sent a KEXINIT message for key exchange or re-
   exchange, until it has sent a NEWKEYS message (Section 7.3), it MUST
   NOT send any messages other than:

   o  Transport layer generic messages (1 to 19) (but SERVICE_REQUEST
      and SERVICE_ACCEPT MUST NOT be sent);

   o  Algorithm negotiation messages (20 to 29) (but further KEXINITs
      MUST NOT be sent);

   o  Specific key exchange method messages (30 to 49).
NEW:
   Once a party has sent a SSH_MSG_KEXINIT message for key exchange or
   re-exchange, until it has sent a SSH_MSG_NEWKEYS message (Section
   7.3), it MUST NOT send any messages other than:

   o  Transport layer generic messages (1 to 19) (but
      SSH_MSG_SERVICE_REQUEST and SSH_MSG_SERVICE_ACCEPT MUST NOT be
      sent);

   o  Algorithm negotiation messages (20 to 29) (but further
      SSH_MSG_KEXINIT messages MUST NOT be sent);

   o  Specific key exchange method messages (30 to 49).



13)
Section 7.1, seventh paragraph
- replace the paragraph
OLD:
   Note, however, that during a key re-exchange, after sending a KEXINIT
   message, each party MUST be prepared to process an arbitrary number
   of messages that may be in-flight before receiving a KEXINIT from the
   other party.
NEW:
   Note, however, that during a key re-exchange, after sending a
   SSH_MSG_KEXINIT message, each party MUST be prepared to process an
   arbitrary number of messages that may be in-flight before receiving a
   SSH_MSG_KEXINIT messages from the other party.



14)
Section 7.2, first paragraph
- insert an additional space after a period
OLD:
   exchange hash H. Encryption and authentication keys are derived from
                   ^
NEW:
   exchange hash H.  Encryption and authentication keys are derived from



15)
Section 8, second paragraph with bullets
- replace the paragraph with bullets
- do not break the bulleted sections across page boundaries
OLD:
   The following steps are used to exchange a key.  In this, C is the
   client; S is the server; p is a large safe prime; g is a generator
   for a subgroup of GF(p); q is the order of the subgroup; V_S is S's
   version string; V_C is C's version string; K_S is S's public host
   key; I_C is C's KEXINIT message and I_S is S's KEXINIT message that
   have been exchanged before this part begins.

   1. C generates a random number x (1 < x < q) and computes e = g^x mod
      p.  C sends "e" to S.

   2. S generates a random number y (0 < y < q) and computes f = g^y mod
      p.  S receives "e".  It computes K = e^y mod p, H = hash(V_C ||
      V_S || I_C || I_S || K_S || e || f || K) (these elements are
      encoded according to their types; see below), and signature s on H
      with its private host key.  S sends "K_S || f || s" to C. The
      signing operation may involve a second hashing operation.

   3. C verifies that K_S really is the host key for S (e.g., using
      certificates or a local database).  C is also allowed to accept
      the key without verification; however, doing so will render the
      protocol insecure against active attacks (but may be desirable for
      practical reasons in the short term in many environments).  C then
      computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S
      || e || f || K), and verifies the signature s on H.
NEW:
   The following steps are used to exchange a key.  In this, C is the
   client; S is the server; p is a large safe prime; g is a generator
   for a subgroup of GF(p); q is the order of the subgroup; V_S is S's
   identification string; V_C is C's identification string; K_S is S's
   public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's
   SSH_MSG_KEXINIT message that have been exchanged before this part
   begins.

   1. C generates a random number x (1 < x < q) and computes
      'e' = g^x mod p.  C sends 'e' to S.

   2. S generates a random number y (0 < y < q) and computes
      'f' = g^y mod p.  S receives 'e'.  It computes K = e^y mod p,
      H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)
      (these elements are encoded according to their types; see below),
      and s ('signature of H') with its private host key.  S sends
      "K_S || f || s" to C. The signing operation may involve a
      second hashing operation.

   3. C verifies that K_S really is the host key for S (e.g., using
      certificates or a local database).  C is also allowed to accept
      the key without verification; however, doing so will render the
      protocol insecure against active attacks (but may be desirable for
      practical reasons in the short term in many environments).  C then
      computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S
      || e || f || K), and verifies the 'signature of H' (s).


16)
Section 8, third paragraph
- replace the paragraph
OLD:
   Either side MUST NOT send or accept 'e' or 'f' values that are not in
   the range [1, p-1].  If this condition is violated, the key exchange
   fails.
NEW:
   Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be
   sent or accepted by either side.  If this condition is violated, the
   key exchange fails.



17)
Section 8, fourth paragraph
- modify a word in a line
OLD:
   the KEXINIT messages.
NEW:
   the SSH_MSG_KEXINIT messages.



18)
Section 11.1, packet description
- add description in a line
OLD:
      string    description [RFC3629]
NEW:
      string    description in ISO-10646 UTF-8 encoding [RFC3629]



19)
Section 11.2, first paragraph
- change a word
OLD:
   time (after receiving the protocol version).  No implementation is
                             ^^^^^^^^^^^^^^^^
NEW:
   time (after receiving the identification string).  No implementation is
                             ^^^^^^^^^^^^^^^^^^^^^


20)
Section 11.3, message description
- add description to a line
OLD:
      string    message [RFC3629]
NEW:
      string    message in ISO-10646 UTF-8 encoding [RFC3629]



21)
Section 12, table
- remove the following lines
REMOVE:
         SSH_MSG_KEXDH_INIT             30
         SSH_MSG_KEXDH_REPLY            31



22)
Section 15.1, all FIPS references
- Add "US" before "National..."
OLD:
   [FIPS-180-2]   National Institute of Standards and Technology,
NEW:
   [FIPS-180-2]   US National Institute of Standards and Technology,



23)
Section 15.1, all FIPS references
- Add "US" before "National..."
OLD:
   [FIPS-186-2]   National Institute of Standards and Technology,
NEW:
   [FIPS-186-2]   US National Institute of Standards and Technology,



24)
Section 15.1, all FIPS references
-  Add "US" before "National..."
OLD:
   [FIPS-197]     National Institute of Standards and Technology,
NEW:
   [FIPS-197]     US National Institute of Standards and Technology,



25)
Section 15.1, all FIPS references
-  Add "US" before "National..."
OLD:
   [FIPS-46-3]    National Institute of Standards and Technology, "Data
NEW:
   [FIPS-46-3]    US National Institute of Standards and Technology,
                  "Data...
===


---------- Forwarded message ----------
Date: Wed, 26 Oct 2005 16:13:50 -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 4253 <draft-ietf-secsh-transport-24.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-transport-24.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/rfc4253.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/rfc4253-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