Re: new C-S draft

[Alex Bochannek <[e-mail]>]

> Given the number of changes in the draft, I'm appending a copy of
> it before sending it to CNRI for posting.  Please send comments...
> 
> thanks,
> henry

A few comments.

>    LOGIN-CMD    ::=  LOGIN <username> <auth-type>
>    USERNAME     ::=  " <ASCII-STRING> "
>    AUTH-TYPE    ::=  "none" | " <ASCII-STRING> "
>    CHAL-CMD     ::=  CHAL " <ASCII-STRING> "
>    AUTH-CMD     ::=  AUTH " <ASCII-STRING> "
> 
> 
>    The authentication types supported by each server  will  vary.   It's
>    recommended  that  standard  strings  such as "kerberos", "password",
>    "securid", "skey", and "tacacs" be used for maximum  interoperability
>    among clients and servers.

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

>    An example of a invalid username:
> 
> 
>    >LOGIN "mule" "skey"
>    <112 "Username unknown"
> 
> 
>    or
> 
> 
>    >LOGIN "mule" "skey"
>    <CHAL "78 lo39065"
>    >AUTH "COW DOG FRED LOG COLD WAR"
>    <110 "Login invalid"

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

>    Note that upon reception of an EXIT command, the server  must  always
>    close  the  connection,  even if it would be appropriate to return an
>    ERROR return code.

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.

That's it from me.

--
Alex Bochannek                                Phone : [phone]
Network Analyst - ECS                         Fax   : [phone]
Cisco Systems, Inc.                           Pager : [phone]
170 West Tasman Drive, Bldg E                 Email : [e-mail]
San Jose, CA 95134-1706, USA