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

Re: Last Call: 'Generic Message Exchange Authentication For SSH' to Proposed Standard



On Wed, Sep 17, 2003 at 01:38:28PM -0400, The IESG wrote:
> The IESG has received a request from the Secure Shell WG to consider the 
> following document:
> 
> - 'Generic Message Exchange Authentication For SSH '
>    <draft-ietf-secsh-auth-kbdinteract-05.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-01.
>                                                                                        
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-05.txt
> 

typographical/grammatical changes only (from my nroff source):

$ rcsdiff -r1.5 -r1.7 -u pwplus.n
===================================================================
RCS file: RCS/pwplus.n,v
retrieving revision 1.5
retrieving revision 1.7
diff -u -r1.5 -r1.7
--- pwplus.n    2003/04/29 06:03:05     1.5
+++ pwplus.n    2003/08/06 09:36:47     1.7
@@ -83,7 +83,7 @@
 1. Introduction

 The SSH authentication protocol \%[SSH-USERAUTH] is a general-purpose user
-authentication protocol. It is intended to be run over the SSH transport
+authentication protocol.  It is intended to be run over the SSH transport
 layer protocol \%[SSH-TRANS].  The authentication protocol assumes that
 the underlying protocols provide integrity and confidentiality protection.

@@ -178,7 +178,7 @@
 does not support the requested language is implementation-dependent.

 The submethods field is included so the user can give a hint of which
-actual methods he wants to use.  It is a a comma-separated list of
+actual methods he wants to use.  It is a comma-separated list of
 authentication submethods (software or hardware) which the user prefers.
 If the client has knowledge of the submethods preferred by the user,
 presumably through a configuration setting, it MAY use the submethods
@@ -186,7 +186,7 @@
 the empty string.

 The actual names of the submethods is something which the user and the
-server needs to agree upon.
+server need to agree upon.

 Server interpretation of the submethods field is implementation-dependent.

@@ -221,7 +221,7 @@
 The server may send as many requests as are necessary to authenticate the
 client; the client MUST be prepared to handle multiple exchanges.  However
 the server MUST NOT ever have more than one SSH_MSG_USERAUTH_INFO_REQUEST
-message outstanding. That is, it may not send another request before
+message outstanding.  That is, it may not send another request before
 the client has answered.

 .KS
@@ -293,7 +293,7 @@
 the name and prompts.  If the server presents names or prompts longer
 than 30 characters, the client MAY truncate these fields to the length
 it can display.  If the client does truncate any fields, there MUST be
-an obvious indication that such truncation has occured.  The instruction
+an obvious indication that such truncation has occurred.  The instruction
 field SHOULD NOT be truncated.

 Clients SHOULD use control character filtering as discussed in \%[SSH-ARCH]
@@ -363,7 +363,7 @@
 If the server intends to respond with a failure message, it MAY delay
 for an implementation-dependent time before sending to the client.
 It is suspected that implementations are likely to make the time delay
-a configurable, a suggested default is 2 seconds.
+configurable; a suggested default is 2 seconds.

 .ti 0
 4. Authentication Examples
@@ -485,7 +485,7 @@
 .ti 0
 6. Security Considerations

-The authentication protocol, and this authentication method, depends
+The authentication protocol, and this authentication method, depend
 on the security of the underlying SSH transport layer.  Without the
 confidentiality provided therein, any authentication data passed with
 this method is subject to interception.
@@ -494,8 +494,8 @@
 authentication using this method may be variable.  It is possible that an
 observer may gain valuable information simply by counting that number.
 For example, an observer may guess that a user's password has expired,
-and with further observation may be able to determine the frequency of
-a site's password expiration policy.
+and with further observation may be able to determine the password lifetime
+imposed by a site's password expiration policy.

 .KS
 .ti 0
@@ -561,7 +561,7 @@
 .in 3
 .KS
 .ti 0
-8. Author's Addresses
+8. Authors' Addresses

 .nf
 .ne 5