Re: Core draft last call update.

[Derek Fawcus <dfawcus%cisco.com@localhost>]

On Wed, Mar 06, 2002 at 03:35:21PM -0500, Bill Sommerfeld wrote:
> 
> Issues raised so far:

Well there is also the issue I raised on 4th Feb in
Message-ID: <20020204234611.A21942%edinburgh.cisco.com@localhost>

Pasted again below:

I've got a slightly different issue with the userauth spec,  section 3 states:
  
   Message numbers of 80 and higher are reserved for protocols running
   after this authentication protocol, so receiving one of them before
   authentication is complete is an error, to which the server MUST
   respond by disconnecting (preferably with a proper disconnect message
   sent first to ease troubleshooting).
  
Maybe I'm missing something,  but I can't see the need to disconnect in this
case,  as opposed to simply discarding these messages.  At the moment an
extra RTT is required to wait for the SSH_MSG_USERAUTH_SUCCESS,  assuming
that the log in method succeeds.  Given that I happen to frequently log
into machines over long slow (long RTT) links,  it gets painful.
  
Unless there is a valid security reason for disconnecting,  I'd suggest
a change to:
 
   Message numbers of 80 and higher are reserved for protocols running
   after this authentication protocol, so any of these messages received
   before authentication has completed cannot be processed;  if this
   situation occurs the server MUST silently discard those messages.
 
An alternative would be to generate some sort of error response to the
messages.  However silent discard serves the purpose of allowing one to
pipeline the initial connection protocol messages after a USERAUTH_REQUEST
on the assumption that it will succeed,  and still automatically deal
with the request failing.  The failure response indicating that the
subsequent higher level protocol messages have been discarded.

DF