Re: new C-S draft

Henry Clark <hclark@nic.near.net> Tue, 11 April 1995 13:39 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01683; 11 Apr 95 9:39 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01677; 11 Apr 95 9:39 EDT
Received: from wugate.wustl.edu by CNRI.Reston.VA.US id aa05687; 11 Apr 95 9:39 EDT
Received: from host (localhost.wustl.edu [127.0.0.1]) by wugate.wustl.edu (8.6.11/8.6.11) with SMTP id IAA02605; Tue, 11 Apr 1995 08:39:33 -0500
Received: from nic.near.net (curry.near.net [198.114.157.153]) by wugate.wustl.edu (8.6.11/8.6.11) with SMTP id IAA02573 for <oswg-l@wugate.wustl.edu>; Tue, 11 Apr 1995 08:39:20 -0500
Message-Id: <9504111339.aa10762@nic.near.net>
Date: Tue, 11 Apr 1995 09:39:06 -0400
Reply-To: oswg-l@wugate.wustl.edu
X-Orig-Sender: owner-oswg-l@wugate.wustl.edu
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Henry Clark <hclark@nic.near.net>
To: oswg-l@wugate.wustl.edu
Subject: Re: new C-S draft
In-Reply-To: <199504110645.XAA25938@hubbub.cisco.com> from "Alex Bochannek" at Apr 10, 95 11:45:04 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: ELM [version 2.4 PL23]
X-Listprocessor-Version: 7.1 -- ListProcessor by CREN

> The authentication type names specified in RFC1409 could be used here.

This doesn't seem like it's buying us anything.  I guess the basic 
question here is do we need a "standard" list of authentication types
specified in this document?  Not every server or client need support
all of the types...

> For security reasons, I'd always challenge even if the username is
> unknown. This way it is harder to find valid usernames by trial and
> error. (I guess I am also suggesting to get rid of error code 112
> then).

changed!

> It might be helpful to spell out what happens if the underlying
> reliable transport protocol closes the connection. I'd assume for the
> server this is equivalent to receiving an EXIT command and the server
> can release all data structures and TAG's that were associated with
> the session.

done...

If the data connection to the client closes for any reason while the server 
is in the PROCESS state, the server must immediately close its connection and
do any associated internal cleanup and return to the LOGIN state.

thanks,
henry