Managing TCPware Security

Introduction

This chapter presents the security features available with TCPware.

TCPware security features can be divided into two parts: independent, free-standing security features, and those inherent within products. The free-standing security features include:

Incoming Access Restrictions

Kerberos Services

Packet Filtering

Outgoing Access Restrictions

IP Security Option (IPSO)

Token Authentication

TCPware products for which security features are available include:

Berkeley R Services

NFS-OpenVMS Server

FTP-OpenVMS

DECwindows

Remote Copy Program (RCP)

TELNET-OpenVMS

Security Tips

Here are some general tips to maintain system security on your TCPware system:

1

Implement an aggressive password strategy for users and especially for privileged accounts. This means long passwords and frequent password changes.

2

Disable all unused accounts, especially privileged ones that are predefined with the operating system (such as field test accounts).

3

If a break-in is in progress, use one of the DEBUG commands in the Network Control Utility (NETCU) to capture the packets. However, be advised that monitoring might be construed as an invasion of privacy.

4

Carefully consider the system announcement or welcome messages. Do not welcome people to the site. Instead, make it clear that the system is for authorized users only, and that all users may be monitored for security reasons.
For details, see a recent book on computer security, such as Cheswick, William R. and Steven M. Bellovin, Firewalls and Internet Security Repelling the Wily Hacker.

5

Subscribe to CERT (Computer Emergency Response Team) announcements by e-mail. If you believe that your system was compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by e-mail, we strongly advise that the E-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available through anonymous FTP on info.cert.org), or PEM (contact CERT staff for details).
Here are the contacts at CERT:
Internet E-mail: cert@cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 AM5:00 PM EST (GMT-5) or EDT (GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 Postal address:CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA

The following documents are also available on the Web using the following URLs:
ftp://info.cert.org/pub/tech_tips/security_info ftp://info.cert.org/pub/tech_tips/anonymous_ftp_abuses ftp://info.cert.org/pub/tech_tips/packet_filtering

CERT posts advisories and bulletins on the comp.security.announce USENET newsgroup. If you wish to have future advisories and bulletins mailed to you or to a mail exploder at your site, send mail to cert-advisory-request@cert.org.
Past advisories, CERT bulletins, information about FIRST representatives, and other information related to computer security are available by anonymous FTP from info.cert.org. (CERT is a service mark of Carnegie Mellon University.)

Independent Security Features

This section describes the security features that you can use with more than one TCPware product. These include incoming and outgoing access restrictions, packet filtering, Kerberos Services, IP Security Option, and Token Authentication.

Incoming Access Restrictions

With incoming access restrictions, the system imposes restrictions on the remote hosts having access to local services.

Manage incoming access restrictions using the following NETCU commands:

ADD ACCESS_LIST

REMOVE ACCESS_LIST

MODIFY SERVICE

ADD SERVICE

SHOW ACCESS_LISTS

To manage incoming access restrictions, see Chapter 19, Access Restrictions.

Outgoing Access Restrictions

With outgoing access restrictions, you restrict access to outside services such as FTP or TELNET for local users. You can base restrictions on a user's ID (UIC or rights identifiers), or the destination address or port (service). Since the system checks only outgoing access restrictions with active open connections and not on each and every datagram, it involves relatively low system overhead.

Manage outgoing access restrictions using two commands in the TCPware Network Control Utility (NETCU):

SET OUTGOING_ACCESS_RESTRICTIONS
SHOW OUTGOING_ACCESS_RESTRICTIONS

To manage outgoing access restrictions, see Chapter 35, Access Restrictions.

Packet Filtering

Packet filtering restricts the datagrams that may be received on a network interface. The system drops all datagrams it denies entry. This software-based filtering allows you to filter datagrams by:

Protocol (IP, TCP, UDP, or ICMP)
Source or destination address
Destination port (TCP or UDP) or ICMP message type

Packet filtering prevents a site from receiving datagrams from certain networks or hosts. For example, a site might wish to restrict incoming access from the rest of the Internet, but allow local users to have full access to Internet resources.

Use packet filtering only when absolutely necessary since the system must scan the packet filter for each datagram. If there is a question whether to use packet filtering or access restrictions on incoming datagrams, packet filtering is more complete, since it covers all connections. However, packet filtering requires more overhead than incoming access restrictions.

Manage packet filtering using the following NETCU commands:

SET FILTER or SET NOFILTER
SHOW FILTER

To manage packet filtering, see Chapter 20, Packet Filtering.

Kerberos Services

TCPware provides the following Kerberos Services:

Kerberos Server

Kerberos for RCP

Kerberos Administration Server

Kerberos User Commands

Kerberos for RLOGIN

Kerberos for TELNET

Kerberos Management Commands

Kerberos for RSH

Some Terms

Some of the terms commonly associated with Kerberos include:

Term Description

Principal

Kerberos refers to clients and servers as principals. Kerberos assigns each principal a name, in the general format:
name.instance@realm

-name, for clients, is the user's login name; for servers, is the name of the service provided, usually rcmd.
-instance, for clients, is usually omitted and is not necessary; for Kerberos administrators, the value is admin; for servers, instance identifies the machine name of the application server that has Kerberos authentication support. For example, if the rlogin server on merlin has Kerberos authentication support, the principal would have the following format:
rcmd.merlin@your_realm

-realm is associated with all principals in a Kerberos database and is the name of a group of machines, such as those on a LAN; realm identifies the Kerberos domain.
You can omit the last two components from some principals. For example, a possible principal could be jones (for user Jones in the local domain) or jones@daisy.com for user Jones in the daisy.com domain. A possible principal could also be rcmd.merlin (for the rlogin server in the local domain) or rcmd.merlin@daisy.com (for the rlogin server on merlin in the domain daisy.com).

Ticket-granting ticket

Contains an encrypted form of the user's Kerberos password. Use it to obtain application service tickets from the Kerberos Server. You cannot use Kerberos authentication without first having this ticket-granting ticket.
The ticket-granting ticket has an associated lifetime that the Kerberos Server specifies. This lifetime is generally eight hours. You can use the same ticket over and over again, until you no longer need the ticket or it expires.

Application service ticket

The Kerberos protocol application uses service tickets to verify a client's identity to an application server. The Kerberos Server encrypts the service ticket with the application server's private key. Only that application server can decrypt the service ticket.

Authenticator

The Kerberos protocol uses authenticators to prevent eavesdroppers from stealing a ticket. The client sends a new authenticator with each service request. An authenticator consists of the client's name, client's IP address, and a timestamp showing the current time.
The server uses the information in the authenticator to confirm that the rightful owner presents the accompanying ticket. For this to be true, the client and server must synchronize their clocks. One way is through the Network Time Protocol (NTP).

Note that a service ticket and authenticator only accompany the request for a service; you do not use them for data exchange once you initiate the service.

Kerberos Process

There are three main steps in the Kerberos process. The user:

Gets a ticket-granting ticket from the Kerberos Server.
Employs this ticket-granting ticket to get the application service ticket.
Requests service by presenting the service ticket and an authenticator to the application server.

The Kerberos process uses tickets, authenticators, and messages. These elements provide specific encrypted information about clients and servers. Kerberos uses keys to encrypt and decrypt tickets, authenticators, and messages.

Some things to remember about tickets and authenticators:

A client must have service tickets for access to any application server.
The client cannot read service tickets since the Kerberos Server encrypts them with the private key of the application server. Every ticket has a session key.
Kerberos requires a new authenticator from the client each time the client starts a new connection with a server.
The encrypted service ticket and authenticator contain the client's network address.
The service ticket and authenticator have a short lifetime (generally five minutes).

Command Users

Regular users and Kerberos administrators use the Kerberos commands in TCPware's Network Control Utility (NETCU). Regular users and Kerberos administrators can also use parts of the KADMIN Server.

Regular users can:
- Get tickets.
- Manage (show and remove) their tickets.
- Change their Kerberos passwords.
Kerberos administrators can:
- Create the Kerberos database (KDB).
- Manage the KDB.
- Control remote access to the KDB.
- Add Kerberos users remotely.
- Show Kerberos users remotely.
- Change a Kerberos user's password remotely.

Typical Session

The following list and Figure 18-1 present a typical implementation of the Kerberos process:

1

The client submits a request to the Kerberos Server to obtain a ticket-granting ticket (TGT). The Kerberos Server consults the Kerberos database (KDB) to get the user's Kerberos password, and encrypts it.

2

The Kerberos Server sends back the encrypted password in the TGT. When the client receives the TGT, it asks the the user for his Kerberos password, encrypts the password, and compares it with the password in the TGT. This is how the user authenticates himself to the Kerberos Server.

3

The client uses the TGT to apply for service tickets so that it can use specific applications. Each service ticket proves the client's identity to an application server.

4

The client presents the service ticket to the application server for authentication. The application server decrypts part of this ticket to check its authenticity.

5

If the application server deems the service ticket to be authentic, it applies the access control it previously defined for that client. If the server cannot decrypt the service ticket, or the service ticket expired or is not authentic, it does not authenticate the client.

Figure 18-1 Typical Kerberos Session Sequence

Kerberos Server

Kerberos is an authentication system for networks designed as part of Project Athena at the Massachusetts Institute of Technology. Kerberos provides network security by regulating user access to networking services. Kerberos uses a set of keys and encrypted tickets to authenticate users.

In a Kerberos environment, at least one system runs the Kerberos Server. Keep this system secure. This trusted server provides authentication services to prove that the requesting user is genuine. Another name for the Kerberos Server is the Key Distribution Center (KDC).

The system manager assumes that other servers on the network and all clients are untrustworthy. For the Kerberos protocol to work, all systems relying on Kerberos must trust only the Kerberos system itself.

The Kerberos Server maintains a secure database, the Kerberos database (KDB), listing the names and private keys of all clients and servers allowed to use the Kerberos Server. Kerberos assumes that all users keep their passwords secure.

User Commands

TCPware provides commands for users to get a ticket-granting ticket, show the ticket-granting ticket and any service tickets, and remove all Kerberos user tickets. Kerberos tickets allow use of Kerberos applications.

TCPware implements the following user commands through NETCU:

GET TGT

SET KERBEROS_PASSWORD

REMOVE TICKETS

SHOW TICKETS

For details on the Kerberos user commands, see Chapter 4, Kerberos User Commands, in the User's Guide.

Management Commands

TCPware provides the system manager with an interface to the Kerberos database (KDB) using the following commands:

ADD KACL

MODIFY KDB

MODIFY KERBEROS USER

ADD KDB

REMOVE KACL

SET MASTER_PASSWORD

CREATE KDB

REMOVE KDB

SHOW KERBEROS USER

CREATE SRVTAB

SHOW KACL

STASH MASTER_PASSWORD

DUMP KDB

SHOW KDB

ADD KERBEROS USER

LOAD KDB

Kerberos Server management also includes setting certain configuration logicals.

For details on the Kerberos management functions, see Chapter 38, Managing Kerberos.

Administration Server

The Kerberos Administration Server allows remote administration of the Kerberos primary server database. It also allows Kerberos users to change their Kerberos passwords.

Authentication for RCP

You can configure the RSH server, which also handles Remote Copy Program (RCP) requests, to require Kerberos authentication requests, to allow both Kerberos authentication and standard authentication requests, or to disallow any Kerberos authentication requests. RCP users must authenticate themselves to the Kerberos Server before using Kerberos authentication for RCP.

Authentication for RLOGIN

You can configure the RLOGIN server to require Kerberos authentication requests, to allow both Kerberos authentication and standard authentication requests, or to disallow any Kerberos authentication requests. RLOGIN users must authenticate themselves to the Kerberos Server before using Kerberos authentication for RLOGIN.

Authentication for RSH

You can configure the remote shell (RSH) server to require Kerberos authentication requests, to allow both Kerberos authentication and standard authentication requests, or to disallow any Kerberos authentication requests. RSH users must authenticate themselves to the Kerberos Server before using Kerberos authentication for RSH.

Authentication for TELNET

You can configure the TELNET server to require Kerberos authentication requests, to allow both Kerberos authentication and standard authentication requests, or to disallow any Kerberos authentication requests. TELNET users must authenticate themselves to the Kerberos Server before using Kerberos authentication for TELNET.

IP Security Option

The IP Security Option (IPSO) is a standard for preventing a system from receiving or transmitting unauthorized datagrams. It was developed for the U.S. Department of Defense and conforms to RFC 1108, U.S. Department of Defense Security Options for the Internet Protocol. IPSO incorporates both a Basic Security Option and an Extended Security Option. TCPware supports both of these options.

To manage IPSO, see Chapter 23, IP Security Option (IPSO).

Token Authentication

Token Authentication allows you to set additional security restrictions on your FTP, TELNET, RLOGIN, and SET HOST logins. You can set up Token Authentication through TCPware's Access Control Encryption Client (ACE/Client) on the OpenVMS host, which communicates with Security Dynamics' ACE/Server on a UNIX or Windows NT host. The authentication takes place through a physical SecurID^[ token "smart card" that you use to provide the ACE/Server with the necessary login information.

To manage Token Authentication, see Chapter 21, Managing Token Authentication.

Component Security

This section describes the TCPware security features available with particular TCPware products.

Berkeley R Commands

The Berkeley R Commands implement security at TCPware configuration and later through Service Access Lists and host equivalence files. The R Services use standard TCPware and OpenVMS security facilities to ensure that only authorized hosts and users have access to the TCPware host.

TCPware implements Berkeley R Command security through:

Configuration

During TCPware configuration, you first select whether you want to enable the login, shell, and exec services. For login service, you also specify whether you want NORMAL or SECURE login authorization (the default is SECURE). The login service is used for RLOGIN, while shell or exec is used for RCP, RMT, and RSH (exec if you specify a username and password).

Service Access Lists

If desired, create a Service Access List to control which hosts, group of hosts, or network can have access to the service.

Host equivalence files

Host equivalence files allow a set of remote hosts access to the server. They contain single-line entries for each authorization. The system manager can set up a TCPWARE:HOSTS.EQUIV file on the system level. Each individual client user can also set up a SYS$LOGIN:.RHOSTS file. This allows equivalent access beyond that specified in the TCPWARE:HOSTS.EQUIV file. The format for SYS$LOGIN:.RHOSTS and TCPWARE:HOSTS.EQUIV file entries is identical.

See Chapter 15, Managing R Commands, for details on host equivalence files.

The typical Berkeley R Commands server security steps are that the server:

1

Checks that the Service Access List (if any) is configured to protect the desired service.

2

Checks that the client's port number is in a reserved range.

3

Checks the password file for an entry for the supplied username.

4

Searches the /etc/hosts.equiv (on UNIX systems) or TCPWARE:HOSTS.EQUIV (on OpenVMS systems) file for the hostname and username.

5

Searches the .rhosts (on UNIX systems) or .RHOSTS (on OpenVMS systems) file in the user's home directory for the hostname and username. Note that if Kerberos authentication is used, the server searches the .klogin (on UNIX systems) or .KLOGIN (on OpenVMS systems) file in the user's home directory for the user's Kerberos principal name.

6

Prompts for a password if SECURE login is specified (for RLOGIN) and there is a match-up in the .RHOSTS or HOSTS.EQUIV file, or a username and password if NORMAL login is specified (for RLOGIN) without a match-up in the .RHOSTS or HOSTS.EQUIV file.
If the user is prompted for the password, and the TCPware ACE/Client is enabled and the user designated for Token Authentication, the user is also prompted for the PASSCODE.

7

Grants or rejects access depending on the server configuration and authorization results:

Grants access for shell, exec, or NORMAL login service without a login prompt if there is a match-up in the .RHOSTS or HOSTS.EQUIV. file, or for SECURE login service if the password entered is authorized.
Rejects access if the server is configured for shell, exec, or SECURE login service and there is no matchup in the .RHOSTS or HOSTS.EQUIV files, or for NORMAL login service if the password entered fails authorization.

Additional password protection is available using Kerberos authentication. This feature is available for the RCP, RLOGIN, and RSH Berkeley R Commands.

For details on Service Access Lists, see the ADD ACCESS_LIST in the NETCU Command Reference.

DECwindows

TCPware provides the following security for the DECwindows Transport Interface:

Target display host configuration

Configure the target display host to allow incoming X Window System applications from the OpenVMS system host.

Displaying on the local host

Bring up the Security option under the Session Manager's Options menu.

Displaying on the remote host

Configure "security" on the remote host to allow incoming connections on the currently active session.

To manage DECwindows security, see Chapter 44, DECwindows Transport Interface.

FTP-OpenVMS

FTP-OpenVMS Server provides the following security functions and options:

Table 18-1 Security Functions and Options

Functions and Options Description

Passwords

Similar to DECnet, you cannot use FTP to log in to multiple-passworded accounts.
If the TCPware ACE/Client is enabled and the user is designated for Token Authentication, the user must provide the PASSCODE at the password prompt.

Directory access restrictions

Server-FTP lets you define the TCPWARE_FTP_ROOT logical for directory access restrictions on a system-wide basis, the TCPWARE_FTP_ANONYMOUS_ROOT logical for ANONYMOUS user directory access restrictions, and the TCPWARE_FTP_username_ROOT logical for directory access restrictions for specific user accounts.

Log file

The FTPSERVER_DTP.LOG file contains information about files transferred during the FTP session. Examining this file helps to isolate security problems.

Idle timeout

If the control connection (other than during a data transfer) is idle for more than 10 minutes, the system aborts the connection.

SYLOGIN.COM

This procedure and user account login command procedures can contain commands that cause the login to fail.

FTP ANONYMOUS Accounts

FTP-OpenVMS supports ANONYMOUS accounts whereby the user can log in using the ANONYMOUS login and the GUEST password. You set up ANONYMOUS accounts using the AUTHORIZE utility.
ANONYMOUS users only have read-only access unless you define the TCPWARE_FTP_ANONYMOUS_RIGHTS logical to allow write, rename, and delete access rights. In addition, the TCPWARE_FTP_ANONYMOUS_ROOT logical allows you to restrict ANONYMOUS users to files in the root directory and its subdirectories.

TCPWARE_FTP_LOGFILE

Define this system logical name to specify the log file name if you suspect break-in attempts through the server.

TCPWARE_FTP_421_REPLY

This logical defines a message to send when a user you want to prevent from logging in connects to the server. After sending the message, the connection closes.

To manage FTP-OpenVMS Server security, see Chapter 20, Managing FTP-OpenVMS.

NFS-OpenVMS Server

The NFS-OpenVMS Server provides several features that maintain the integrity of the OpenVMS file system:

PROXY database

The Server requires that the local system must register any user attempting access to OpenVMS files. You do this through the PROXY database when you configure the Server, and through later modifications as needed.

EXPORT database

You must export an OpenVMS directory for an NFS user to have access to it. The Server does this through the EXPORT database when you configure the Server, and through later modifications as needed.

You can take the following additional system security measures:

Assign an NFS rights identifier to further restrict file access
Require all RPC requests to originate from privileged ports
Restrict all remote mounts to the NFS superuser only
Restrict mounts only to explicit directories and not their subdirectories
Require the PROXY database to define the mount requester's identification

See Chapter 13, Managing NFS-OpenVMS Server.

Remote Copy Program

Passwords can be a problem in RCP since the /PASSWORD qualifier requires entry of plain text that someone on the network can intercept.

You can prevent users from having to specify the /USER, /PASSWORD, or /TRUNCATE qualifier with the RCP command. Check that remote hosts include your hostname entry in their host equivalence files (such as the /etc/hosts.equiv file in UNIX systems). On OpenVMS hosts, the TCPWARE:HOSTS.EQUIV or SYS$LOGIN:.RHOSTS file serves as the host equivalence file to permit remote hosts to log in.

Kerberos password protection is also available for the RCP service.

To manage RCP security, see Chapter 15, Managing R Commands. To manage Kerberos authentication for RCP, see Chapter 22, Managing Kerberos.

TELNET-OpenVMS

The TELNET-OpenVMS Server provides the TCPWARE_TELNETD_INTRO_MSG option. With this logical, you can define a special message that appears whenever a user attempts access to the host through TELNET. You can use this logical to issue warnings such as "Authorized Use Only" for remote logins.

If the TCPware ACE/Client is enabled and the user is designated for Token Authentication, the user is also prompted for the PASSCODE in addition to the username and password.

Kerberos password protection is also available for the TELNET service.

To manage TELNET-OpenVMS security, see Chapter 17, Managing TELNET-OpenVMS Server. To manage Kerberos authentication for TELNET, see Chapter 22, Managing Kerberos.

Berkeley R Services	NFS-OpenVMS Server	FTP-OpenVMS
DECwindows	Remote Copy Program (RCP)	TELNET-OpenVMS

1	Implement an aggressive password strategy for users and especially for privileged accounts. This means long passwords and frequent password changes.
2	Disable all unused accounts, especially privileged ones that are predefined with the operating system (such as field test accounts).
3	If a break-in is in progress, use one of the DEBUG commands in the Network Control Utility (NETCU) to capture the packets. However, be advised that monitoring might be construed as an invasion of privacy.
4	Carefully consider the system announcement or welcome messages. Do not welcome people to the site. Instead, make it clear that the system is for authorized users only, and that all users may be monitored for security reasons. For details, see a recent book on computer security, such as Cheswick, William R. and Steven M. Bellovin, Firewalls and Internet Security Repelling the Wily Hacker.
5	Subscribe to CERT (Computer Emergency Response Team) announcements by e-mail. If you believe that your system was compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by e-mail, we strongly advise that the E-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available through anonymous FTP on info.cert.org), or PEM (contact CERT staff for details). Here are the contacts at CERT: Internet E-mail: cert@cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 AM5:00 PM EST (GMT-5) or EDT (GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 Postal address:CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA The following documents are also available on the Web using the following URLs: ftp://info.cert.org/pub/tech_tips/security_info ftp://info.cert.org/pub/tech_tips/anonymous_ftp_abuses ftp://info.cert.org/pub/tech_tips/packet_filtering CERT posts advisories and bulletins on the comp.security.announce USENET newsgroup. If you wish to have future advisories and bulletins mailed to you or to a mail exploder at your site, send mail to cert-advisory-request@cert.org. Past advisories, CERT bulletins, information about FIRST representatives, and other information related to computer security are available by anonymous FTP from info.cert.org. (CERT is a service mark of Carnegie Mellon University.)

ADD ACCESS_LIST	REMOVE ACCESS_LIST	MODIFY SERVICE
ADD SERVICE	SHOW ACCESS_LISTS

Kerberos Server	Kerberos for RCP	Kerberos Administration Server
Kerberos User Commands	Kerberos for RLOGIN	Kerberos for TELNET
Kerberos Management Commands	Kerberos for RSH

Term	Description
Principal	Kerberos refers to clients and servers as principals. Kerberos assigns each principal a name, in the general format: name.instance@realm -name, for clients, is the user's login name; for servers, is the name of the service provided, usually rcmd. -instance, for clients, is usually omitted and is not necessary; for Kerberos administrators, the value is admin; for servers, instance identifies the machine name of the application server that has Kerberos authentication support. For example, if the rlogin server on merlin has Kerberos authentication support, the principal would have the following format: rcmd.merlin@your_realm -realm is associated with all principals in a Kerberos database and is the name of a group of machines, such as those on a LAN; realm identifies the Kerberos domain. You can omit the last two components from some principals. For example, a possible principal could be jones (for user Jones in the local domain) or jones@daisy.com for user Jones in the daisy.com domain. A possible principal could also be rcmd.merlin (for the rlogin server in the local domain) or rcmd.merlin@daisy.com (for the rlogin server on merlin in the domain daisy.com).
Ticket-granting ticket	Contains an encrypted form of the user's Kerberos password. Use it to obtain application service tickets from the Kerberos Server. You cannot use Kerberos authentication without first having this ticket-granting ticket. The ticket-granting ticket has an associated lifetime that the Kerberos Server specifies. This lifetime is generally eight hours. You can use the same ticket over and over again, until you no longer need the ticket or it expires.
Application service ticket	The Kerberos protocol application uses service tickets to verify a client's identity to an application server. The Kerberos Server encrypts the service ticket with the application server's private key. Only that application server can decrypt the service ticket.
Authenticator	The Kerberos protocol uses authenticators to prevent eavesdroppers from stealing a ticket. The client sends a new authenticator with each service request. An authenticator consists of the client's name, client's IP address, and a timestamp showing the current time. The server uses the information in the authenticator to confirm that the rightful owner presents the accompanying ticket. For this to be true, the client and server must synchronize their clocks. One way is through the Network Time Protocol (NTP).

1	The client submits a request to the Kerberos Server to obtain a ticket-granting ticket (TGT). The Kerberos Server consults the Kerberos database (KDB) to get the user's Kerberos password, and encrypts it.
2	The Kerberos Server sends back the encrypted password in the TGT. When the client receives the TGT, it asks the the user for his Kerberos password, encrypts the password, and compares it with the password in the TGT. This is how the user authenticates himself to the Kerberos Server.
3	The client uses the TGT to apply for service tickets so that it can use specific applications. Each service ticket proves the client's identity to an application server.
4	The client presents the service ticket to the application server for authentication. The application server decrypts part of this ticket to check its authenticity.
5	If the application server deems the service ticket to be authentic, it applies the access control it previously defined for that client. If the server cannot decrypt the service ticket, or the service ticket expired or is not authentic, it does not authenticate the client.

ADD KACL	MODIFY KDB	MODIFY KERBEROS USER
ADD KDB	REMOVE KACL	SET MASTER_PASSWORD
CREATE KDB	REMOVE KDB	SHOW KERBEROS USER
CREATE SRVTAB	SHOW KACL	STASH MASTER_PASSWORD
DUMP KDB	SHOW KDB	ADD KERBEROS USER
LOAD KDB

Configuration	During TCPware configuration, you first select whether you want to enable the login, shell, and exec services. For login service, you also specify whether you want NORMAL or SECURE login authorization (the default is SECURE). The login service is used for RLOGIN, while shell or exec is used for RCP, RMT, and RSH (exec if you specify a username and password).
Service Access Lists	If desired, create a Service Access List to control which hosts, group of hosts, or network can have access to the service.
Host equivalence files	Host equivalence files allow a set of remote hosts access to the server. They contain single-line entries for each authorization. The system manager can set up a TCPWARE:HOSTS.EQUIV file on the system level. Each individual client user can also set up a SYS$LOGIN:.RHOSTS file. This allows equivalent access beyond that specified in the TCPWARE:HOSTS.EQUIV file. The format for SYS$LOGIN:.RHOSTS and TCPWARE:HOSTS.EQUIV file entries is identical.

1	Checks that the Service Access List (if any) is configured to protect the desired service.
2	Checks that the client's port number is in a reserved range.
3	Checks the password file for an entry for the supplied username.
4	Searches the /etc/hosts.equiv (on UNIX systems) or TCPWARE:HOSTS.EQUIV (on OpenVMS systems) file for the hostname and username.
5	Searches the .rhosts (on UNIX systems) or .RHOSTS (on OpenVMS systems) file in the user's home directory for the hostname and username. Note that if Kerberos authentication is used, the server searches the .klogin (on UNIX systems) or .KLOGIN (on OpenVMS systems) file in the user's home directory for the user's Kerberos principal name.
6	Prompts for a password if SECURE login is specified (for RLOGIN) and there is a match-up in the .RHOSTS or HOSTS.EQUIV file, or a username and password if NORMAL login is specified (for RLOGIN) without a match-up in the .RHOSTS or HOSTS.EQUIV file. If the user is prompted for the password, and the TCPware ACE/Client is enabled and the user designated for Token Authentication, the user is also prompted for the PASSCODE.
7	Grants or rejects access depending on the server configuration and authorization results: Grants access for shell, exec, or NORMAL login service without a login prompt if there is a match-up in the .RHOSTS or HOSTS.EQUIV. file, or for SECURE login service if the password entered is authorized. Rejects access if the server is configured for shell, exec, or SECURE login service and there is no matchup in the .RHOSTS or HOSTS.EQUIV files, or for NORMAL login service if the password entered fails authorization.

Target display host configuration	Configure the target display host to allow incoming X Window System applications from the OpenVMS system host.
Displaying on the local host	Bring up the Security option under the Session Manager's Options menu.
Displaying on the remote host	Configure "security" on the remote host to allow incoming connections on the currently active session.

Functions and Options	Description
Passwords	Similar to DECnet, you cannot use FTP to log in to multiple-passworded accounts. If the TCPware ACE/Client is enabled and the user is designated for Token Authentication, the user must provide the PASSCODE at the password prompt.
Directory access restrictions	Server-FTP lets you define the TCPWARE_FTP_ROOT logical for directory access restrictions on a system-wide basis, the TCPWARE_FTP_ANONYMOUS_ROOT logical for ANONYMOUS user directory access restrictions, and the TCPWARE_FTP_username_ROOT logical for directory access restrictions for specific user accounts.
Log file	The FTPSERVER_DTP.LOG file contains information about files transferred during the FTP session. Examining this file helps to isolate security problems.
Idle timeout	If the control connection (other than during a data transfer) is idle for more than 10 minutes, the system aborts the connection.
SYLOGIN.COM	This procedure and user account login command procedures can contain commands that cause the login to fail.
FTP ANONYMOUS Accounts	FTP-OpenVMS supports ANONYMOUS accounts whereby the user can log in using the ANONYMOUS login and the GUEST password. You set up ANONYMOUS accounts using the AUTHORIZE utility. ANONYMOUS users only have read-only access unless you define the TCPWARE_FTP_ANONYMOUS_RIGHTS logical to allow write, rename, and delete access rights. In addition, the TCPWARE_FTP_ANONYMOUS_ROOT logical allows you to restrict ANONYMOUS users to files in the root directory and its subdirectories.
TCPWARE_FTP_LOGFILE	Define this system logical name to specify the log file name if you suspect break-in attempts through the server.
TCPWARE_FTP_421_REPLY	This logical defines a message to send when a user you want to prevent from logging in connects to the server. After sending the message, the connection closes.

PROXY database	The Server requires that the local system must register any user attempting access to OpenVMS files. You do this through the PROXY database when you configure the Server, and through later modifications as needed.
EXPORT database	You must export an OpenVMS directory for an NFS user to have access to it. The Server does this through the EXPORT database when you configure the Server, and through later modifications as needed.