Subject: authors 48 hours: RFC 4252 <draft-ietf-secsh-userauth-27.txt> NOW AVAILABLE (fwd)

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

Hi,

===

1)
Section 4, second paragraph
- change a line
OLD:
    always reject this request, unless the client is to be allowed in
                                                           ^^^^^^^^^^
NEW:
    always reject this request, unless the client is to be granted access

2)
Section 5, packet description after the first paragrah
- the packet syntax is not consistent with the format used in RFC 4254.
OLD:
       byte      SSH_MSG_USERAUTH_REQUEST
       string    user name in ISO-10646 UTF-8 encoding [RFC3629]
       string    service name in US-ASCII
       string    method name in US-ASCII

       The rest of the packet is method-specific.
NEW:
       byte      SSH_MSG_USERAUTH_REQUEST
       string    user name in ISO-10646 UTF-8 encoding [RFC3629]
       string    service name in US-ASCII
       string    method name in US-ASCII
       ....      method specific fields follow

3)
Section 5.1, 9th paragraph
- replace the paragraph
OLD:
    A request that results in further exchange of messages will be
    aborted by a second request.  It is not possible to send a second
    request without waiting for a response from the server, if the first
    request will result in a further exchange of messages.  No
    SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method.

NEW:
    A request that requires further messages to be exchanged will be
    aborted by a subsequent request.  A client MUST NOT send a subsequent
    request if it has not recieved a response from the server for a
    previous request.  A SSH_MSG_USERAUTH_FAILURE message MUST NOT be
    sent for an aborted method.

4)
Section 5.2, second paragraph
- replace the paragraph
OLD:
    If no authentication is needed for the user, the server MUST return
    SSH_MSG_USERAUTH_SUCCESS.  Otherwise, the server MUST return
    SSH_MSG_USERAUTH_FAILURE and MAY return it with a list of
    authentication 'method name' values.
NEW:
    If no authentication is needed for the user, the server MUST return
    SSH_MSG_USERAUTH_SUCCESS.  Otherwise, the server MUST return
    SSH_MSG_USERAUTH_FAILURE and MAY return it a list of methods that
    may continue in its 'authentications that can continue' value.

5)
Section 5.4, first paragraph
- repace the paragraph
OLD:
    In some jurisdictions, sending a warning message before
    authentication may be relevant for getting legal protection.  Many
    UNIX machines, for example, normally display text from '/etc/issue',
    use "tcp wrappers", or similar software to display a banner before
    issuing a login prompt.
NEW:
    In some jurisdictions, sending a warning message before
    authentication may be relevant for getting legal protection.  Many
    UNIX machines, for example, normally display text from /etc/issue,
    use tcp wrappers, or similar software to display a banner before
    issuing a login prompt.

6)
Section 5.4, packet description below second paragraph
- remove extra words
OLD:
       string    language tag as defined in [RFC3066]
NEW:
       string    language tag [RFC3066]

7)
Section 6, last paragraph
- change a line (consistent with other range notation)
OLD:
    (60...79) reserved for method-specific messages.  These messages are
NEW:
    (60 to 79) reserved for method-specific messages.  These messages are

8)
Section 7, Second paragraph
- replace the paragraph
OLD:
    With this method, the possession of a private key serves as
    authentication.  This method works by sending a 'signature' created
    with a private key of the user.  The server MUST check that the key
    is a valid authenticator for the user, and MUST check that the
    'signature' is valid.  If both hold, the authentication request MUST
    be accepted; otherwise, it MUST be rejected.  (Note that the server
    MAY require additional authentications after successful
    authentication.)
NEW:
    With this method, the possession of a private key serves as
    authentication.  This method works by sending a signature created
    with a private key of the user.  The server MUST check that the key
    is a valid authenticator for the user, and MUST check that the
    signature is valid.  If both hold, the authentication request MUST
    be accepted; otherwise, it MUST be rejected.  (Note that the server
    MAY require additional authentications after successful
    authentication.)

9)
Section 7, third paragraph
- insert words
OLD:
    authentication using the key would be acceptable.
NEW:
    authentication using the "publickey" method would be acceptable.

10)
Section 8, second paragraph
- remove a comma
OLD:
From an internationalization standpoint, it is desired that, if a
                                                            ^
NEW:
From an internationalization standpoint, it is desired that if a

11)
Section 8, second paragraph
-  change the wording
OLD:
    added to the database, or compare them (with or without hashing) to
                           ^^^^^^^^^^^^
NEW:
    added to the database, or compared (with or without hashing) to

12)
Section 8, packet description after 5th paragraph
- remove words
OLD:
       string    language tag as defined in [RFC3066]
NEW:
       string    language tag [RFC3066]

13)
Section 9, in the fourth paragraph
- add a reference
OLD:
    key' are defined in the transport layer specification.  The 'public
NEW:
    key' are defined in the transport layer specification [RFC4253].  The 
'public

14)
Section 9, the last paragraph
- change a line
OLD:
    It is RECOMMENDED that, whenever possible, the server perform
NEW:
    Whenever possible, it is RECOMMENDED that the server perform

===

---------- Forwarded message ----------
Date: Wed, 26 Oct 2005 16:12:33 -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 4252 <draft-ietf-secsh-userauth-27.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-userauth-27.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/rfc4252.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/rfc4252-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

---

From: Jacob Nevins <[email-masked]>
Date: Sun, 13 Nov 2005 18:58:28 +0000

A couple of miniscule nits.

> Section 5.1, 9th paragraph
  [...]
> NEW:
  [...]
>     request if it has not recieved a response from the server for a

s/recieved/received/

> Section 5.4, first paragraph
  [...]
> NEW:
  [...]
>     use tcp wrappers, or similar software to display a banner before

s/tcp/TCP/