Kevin wrote:
> You can change telnet to another port besides 23. (Change
> services.net.sys). I believe you could run 2+ telnet daemons, each
> on a different port.

True, but this isn't much security.  "Port scanning" with something
like satan will quickly reveal your extra "secret" telnet ports.

> If a 3rd party (or HP) would provide a user hook in their telnet
> deamon for security enhancing packet filters (read encryption),
> you could add this feature.

The problem is that telnet on the 3000 is not implemented the way
telnet works on UNIX.  The telnet connection comes in through the
normal mechanism, but at the moment inetd receives it it is passed
directly into the darkest internals of MPE where it appears to be
treated as a special case of a VT session.  So it's not using the
straight forward pty method of UNIX that would make it easy to wrap
the process with SSL, or NCSA Secure Telnet, or something similar.

The idea of HP providing a "hook" to allow 3rd parties to implement
both authentication and encryption has a lot of potential benefits.

It would prevent HP from having to worry about the implementation
and all the legal issues surrounding encryption technology.  It
would give people to choose from among perhaps several 3rd party
or freeware solutions.

You could build other things too.  For example these hooks would let
you build other kinds of security solutions, such as having
a telnet port that, upon connection, automagically logs on as a
specific user and runs a program without requiring any input on the
users part.  This would let you build network services that require
a session context for each connection but without exposing a login
prompt to the user or having to maintain login information in the
client. I already have a customer who wants to do this.

You could have a security package that monitored all the traffic on
a connection, potentially restricting certain commands or watching
for certain keywords.  As a support tool you could monitor a user's
session a la' MIRRORS/PEEKABOO.

G.