sis(5)

NAME

sis — secure internet services with Kerberos authentication and authorization

DESCRIPTION

Secure Internet Services (SIS) provides network authentication when used in conjunction with HP DCE security services, the HP Praesidium/Security Server, or other software products that provide a Kerberos V5 Network Authentication Services environment. The network authentication ensures that a local and remote host will be mutually identified to each other in a secure and trusted manner and that the user is authorized to use the service on the remote host.

Traditional internet services such as telnet, rlogin, or ftp, allow the user to access remote systems by typing a password that is then transmitted to the remote system over the network. The password is transmitted without encryption over the network, permitting an observer to capture the cleartext packets containing the password. This has been a major security hole for traditional internet services.

The optional Secure Internet Services are a replacement for their traditional counterparts and prevent the cleartext transmission of user passwords over the network. However, none of these services will encrypt the session beyond what is necessary to authenticate the service or authorize the user.

This manpage assumes the reader is familiar with Kerberos terminology normally provided with your Kerberos V5 Network Authentication Services environment. The intent here is to describe those aspects of the Kerberos environment specifically used by SIS.

Authentication

For Kerberos authentication to succeed, the user must have successfully logged into a system within the Kerberos realm and obtained a set of credentials. The credentials include a Ticket Granting Ticket (TGT) and a session key. The SIS client will use the TGT to obtain a service ticket to access a SIS daemon on the network. If the credentials are missing or the TGT is invalid, the authentication will fail and connection to the SIS daemon will be denied.

For systems configured into a DCE cell, credentials are obtained through the dce_login command. For systems configured into a Praesidium/Security Server cell, credentials are obtained through the dess_login command. In a non-DCE Kerberos-based secure environment, credentials are obtained through the kinit command.

Authorization

For every user of these services, a user principal must be configured into the Key Distribution Center's database. The user principal allows the user to obtain a service ticket which is sent to the remote service as part of the Kerberos authentication mechanism. If the authentication is successful, the user principal is then used as part of the Kerberos authorization mechanism.

In order for the authorization to succeed, both of the following requirements must be met:

The login name must exist in the remote system's password file, that is, the remote account must exist. Note: The login name is the name specified by the user in response to a login prompt and may be different from the current user name.
One of the following conditions must be true:
1. The remote account's home directory has a .k5login file that contains the user principal. The .k5login file must be owned by that account and only that account can have write permission (that is, the permissions would appear as -rw-r--r--).
2. Note: In the remote system, if the /etc/krb5/ directory exists, Kerberos ignores the .k5login file in the remote account's home directory.
3. The remote system has a .k5login.login_name file or symbolic link in the /etc/krb5/ directory that contains the user principal. If the /etc/krb5/ directory does not exist, Kerberos checks the .k5login file in the remote account's home directory. If the /etc/krb5/ directory exists, Kerberos ignores the .k5login file in the remote account's home directory.
4. The format of the entries in the .k5login.login_name file is similar to the entries in the .k5login file. The .k5login.login_name file (or symbolic link) and /etc/krb5/ directory must be owned by the root user and only the root user must have write permission (that is, -rw-r--r--). To give privileges to a user to handle the .k5login.login_name file, an administrator can create a .k5login.login_name symbolic link to the .k5login file in remote account's home directory.
5. The remote system has an authorization name database file, aname, that contains the user principal. The aname file should contain a mapping of the user principal to an account on the remote system.
6. The user name in the user principal is the same as the user name of the account being accessed, and the local and remote systems are in the same realm.

If authorization succeeds, the user will not see a prompt for a password (when a password is required) and the connection to the remote system will succeed. If the authentication or authorization fails, the user will be notified of the error and will not be allowed to continue.

Bypassing or Enforcing Authentication/Authorization

If the authentication or authorization fails, the service can be rerun with a special command-line option (-P) to request non-Kerberos authentication. However, when a password is required, it will be sent across the network in a readable form. Typically, this special command-line option should only be used to access nonsecure remote systems.

The ftp and telnet daemons have a special command-line option (-A) which can be used to ensure that nonsecure systems are denied access.

To prevent nonsecure access through the rcp, remsh or rlogin commands, the inetd.conf file on the remote system should be edited to comment out the entries for shell and login.

SERVICES

ftp, ftpd: File transfer program
rlogin, rlogind: Remote login
telnet, telnetd: User interface and server for Telnet protocol
rcp, remshd: Remote file copy
remsh, remshd: Execute from a remote shell

TROUBLESHOOTING

For the correct execution of SIS, it is important that the secure environment be properly installed, configured and running. The following is a quick checklist to verify this:

1.

The DCE, Praesidium/Security Server, or Kerberos security system should be running on the Kerberos server. The /etc/services file should contain entries for the Kerberos ports.

2.

The user's user principal must be entered into the Key Distribution Center's database. Use the appropriate tool (for example, kadmin or HP DCE's dcecp) to list the database and to verify that the user has a user principal configured.

3.

The Kerberos configuration directory on the local and remote systems should contain a krb.conf, krb.realms, and a server key table file. Generally, the Kerberos configuration directory will be /krb5 and the server key table file will be named v5srvtab.

4.

The user principal must be specified in the /etc/krb5/.k5login.login_name or ~/.k5login on the local and remote systems. The ~/.k5login lists the principals and realm names which have access permission for the user's account.

Alternatively, the secure system can use an authorization name database, aname, on the local and remote systems. An entry in this file will authorize the user name in a user principal to the specified login name.

Verify that /etc/krb5/.k5login.login_name or ~/.k5login exists, has the correct permissions (that is, -rw-r--r--), and includes the user principal. Or, use the appropriate tool (for example, krb5_anadd on a non-HP DCE system) to verify that the user principal is included in the aname file.

Note: In the remote system, if the /etc/krb5/ directory exists, Kerberos ignores the .k5login file in remote account's home directory.

5.

The server key table file on the remote system should contain a host principal. The root user can verify the contents of the v5srvtab through the command: klist -k. If klist supports the -k option, type this command and verify that a host principal is listed.

Alternatively, if the validation tool, krbval, is available on the system, use the command: krbval -v.

6.

If krbval is available on the local and remote systems, use it to test the Kerberos configuration by invoking it to act as a client application on the local system and a server application on the remote system. See krbval(1M) for details.

7.

The SIS files must be installed. The traditional services will have been saved and the files for the new services will be linked to the original, traditional file names.

DIAGNOSTICS

In addition to Kerberos-specific error messages, SIS has a few security related error messages that are common to several or all of the services. These error messages can be used by scripts to detect whether the invocation of a service has failed.

Error and Warning Messages Reported by the SIS Clients

ERROR! Kerberos authentication failed.

The user has not obtained a valid Ticket Granting Ticket (through kinit, dce_login, or dess_login) or a valid host principal has not been configured in the Key Distribution Center's database for the realm. A more specific error message indicating the possible cause of the failure will accompany this error message.
This error message will also be generated if the user attempts to access a nonsecure remote system. In which case, this message will be preceded by the message: To bypass Kerberos authentication, use the -P option .
This error is reported by ftp, rlogin and telnet.
ERROR! Kerberos-specific options are invalid with the -P option.
The -P command-line option indicates that Kerberos authentication should not be performed. If any Kerberos-specific options are also specified on the command line, then they are in contradiction to this request.
For remsh and rlogin, this means the -P option can not be used in conjunction with the -F, -f, or -k options.
For rcp this means the -P option can not be used in conjunction with the -k option.
For telnet, this means the -P option cannot be used in conjunction with the -a or -l options.
WARNING! Password will be sent in a non-secure manner.
WARNING! Kerberos authentication will be bypassed.
The user has specified the -P option on the command line to access a nonsecure remote system or to bypass a bad configuration in the Kerberos environment.
In the cases where a password is requested, the -P command-line option will cause the password to be sent across the network in a readable form where it could possibly be intercepted or captured.
It is recommended that the user corrects a bad configuration and only uses the -P option if the remote system is nonsecure.
The first warning is reported by ftp, rlogin, and telnet. The second warning is reported by rcp. remsh could report either warning depending upon whether a password is required.

Error Messages Reported in the syslog by the SIS Daemons

ERROR! Access denied. Kerberos authentication must succeed.

The daemon was started with the -A command-line option to ensure that nonsecure access by remote systems will be denied. The user cannot access the remote system unless the local system has been configured for secure access.
This error is logged by ftpd and telnetd.
ERROR! Principal principal (remote_user@remote_host) logging in as local_user has no account.
The local_user does not have a valid password file entry.
This error is logged by all SIS daemons.
ERROR! Principal principal (remote_user@remote_host) logging in as local_user failed krb5_userok.
Authentication succeeded but authorization failed. The user should verify that their user name is listed in /etc/krb5/.k5login.login_name or ~/.k5login or in the aname file on the remote system. The user's ~/.k5login must have the correct permissions and must be owned by the user (that is, -rw-r--r--).
This error is logged by all SIS daemons.
ERROR! Principal principal (remote_user@remote_host) logging in as local_user failed ruserok.
The /etc/hosts.equiv or ~/.rhost files are missing or are not set up properly to authorize local_user (see ruserok(3N)).
This error is logged by rlogind or remshd if they are started with the -R, -r, or -k options.