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

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

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 <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 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