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

From: Chris Lonvick <[email-masked]>
Date: Wed, 9 Nov 2005 18:29:44 -0800 (PST)

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 <[email-masked]>
To: [email-masked], [email-masked]
Cc: RFC Editor <[email-masked]>, Russ Housley <[email-masked]>,
     Sam Hartman <[email-masked]>, [email-masked]
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