IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Please review last nits I'm sending to the RFC Editor
Hi Folks,
I'm planning on sending these requests to the RFC Editor. Please let me
know if you'd suggest any changes.
Thanks,
Chris
===
RFC 4250 [SSH-NUMBERS]
1)
Section 4.5.1, first paragraph
- change "a" to "an"
OLD:
a "pty-req" string MUST contain a 'encoded terminal modes' value.
^
NEW:
a "pty-req" string MUST contain an 'encoded terminal modes' value.
^^
2)
Section 4.6.1, first paragraph
- remove extraneous "a"
OLD:
sign ("@"), a comma (","), whitespace, control characters (ASCII
^
NEW:
sign ("@"), comma (","), whitespace, control characters (ASCII
3)
Section 4.8, first paragraph
- Please don't split this paragraph like this across a page break.
It leaves "Names." as the only word from the paragraph on the
next page.
4)
Section 4.9.3, table after first paragraph
- Please don't split this table across a page break.
5)
Section 6, references
- Would you please insert a page break after Section 5 so that
the references start on a new page?
===
RFC 4251 [SSH-ARCH]
1)
Section 4.1, last paragraph
- reverse 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
^^^^^^
2)
Section 4.3, third bullet in the first paragraph
- modify a line
OLD:
depend on the location from where the user is trying to log in.
^^^^^^
NEW:
depend on the location from where the user is trying to gain access.
^^^^^^^^^^^^
3)
Section 6, first bullet in second paragraph
- remove extraneous "a"
OLD:
at-sign ("@"), a comma (","), whitespace, or control characters
^
NEW:
at-sign ("@"), comma (","), whitespace, or control characters
4)
Section 9.3.7, first paragraph
- quote a value
OLD:
and diffie-hellman-group14-sha1) are secure even if private
NEW:
and "diffie-hellman-group14-sha1") are secure even if private
5)
Section 7, Connection protocol table
- Please don't split this two-line table across a page break.
NEW:
Connection protocol:
80 to 89 Connection protocol generic
90 to 127 Channel related messages
6)
Section 10, references
- Would you please insert a page break after Section 9 so that
the references start on a new page?
===
RFC 4252 [SSH-USERAUTH]
1)
Section 5, first paragraph
- remove the following line
The rest of the packet is method-specific.
2)
Section 5.2, second paragraph
- insert a word
OLD:
SSH_MSG_USERAUTH_FAILURE and MAY return it a list of
NEW:
SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of
^^^^
3)
Section 7, packet description after first paragraph
- insert words
OLD:
string service
NEW:
string service name
4)
Section 8, second paragraph
- remove a word
OLD:
added to the database, or compared them (with or without hashing) to
^^^^
NEW:
added to the database, or compared (with or without hashing) to
5)
Section 12, references
- Would you please insert a page break after Section 10 so that
the references start on a new page?
===
RFC 4253 [SSH-TRANS]
1)
Section 4.2, second paragraph
- replace a word; Implementers for Implementors
OLD:
(ASCII 13 and 10, respectively). Implementors who wish to maintain
^^^^^^^^^^^^
NEW:
(ASCII 13 and 10, respectively). Implementers who wish to maintain
^^^^^^^^^^^^
2)
Section 6.1, first paragraph
- insert a word
OLD:
that other party is able to process them. However, implementations
NEW:
that the other party is able to process them. However, implementations
^^^
3)
Section 7.1, last paragraph
- change a word
OLD:
SSH_MSG_KEXINIT messages from the other party.
^^^^^^^^
NEW:
SSH_MSG_KEXINIT message from the other party.
^^^^^^^
4)
Section 5.2, fifth paragraph
- change a word
OLD:
Implementations are expected to have some limit on the ssh transport
^^^
NEW:
Implementations are expected to have some limit on the SSH transport
^^^
5)
Section 8, second paragraph with associated bullets
- replace the paragraph and associated 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 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.
6)
Section 8, table after seventh paragraph
- change words "version" to "identification" in two lines
- change "NL" to "LF" in the same lines
OLD:
string V_C, the client's version string (CR and NL excluded)
string V_S, the server's version string (CR and NL excluded)
NEW:
string V_C, the client's identification string (CR and LF
excluded)
string V_S, the server's identification string (CR and LF
excluded)
7)
Section 15, references
- Would you please insert a page break after Section 14 so that
the references start on a new page?
===
RFC 4254 [SSH-CONNECT]
1)
Section 5.2, fifth paragraph second bullet
- change a word
OLD:
o MUST NOT generate data packets larger that its transport layer is
^^^^
NEW:
o MUST NOT generate data packets larger than its transport layer is
^^^^
2)
Section 6.10, packet description after third paragraph
- remove some words
OLD:
string language tag as defined in [RFC3066]
NEW:
string language tag [RFC3066]
3)
Section 6.10, fourth paragraph
- do not break the hyphen segmented name "sig-name@xyz"
OLD:
Additional 'signal name' values MAY be sent in the format "sig-
name@xyz", where "sig-name" and "xyz" may be anything a particular
NEW:
Additional 'signal name' values MAY be sent in the format
"sig-name@xyz", where "sig-name" and "xyz" may be anything a
particular
===end
Home |
Main Index |
Thread Index |
Old Index