Overview of the Secure Environment and the Kerberos V5 Protocol

This section gives an overview of the secure environment in which the Secure Internet Services operate, including a simplified overview of the Kerberos V5 authentication protocol and related Kerberos concepts.

Kerberos, originally developed by MIT, refers to an authentication protocol for open network computing environments. Kerberos V5 is the Kerberos version applicable to the Secure Internet Services. The Kerberos V5 protocol is specified in RFC 1510: ''The Kerberos Network Authentication Service (V5)".

In this chapter ''non-HP Kerberos" refers to Kerberos implementations available directly from MIT, or to commercialized versions of Kerberos based on MIT source code.

Figure 11-1 “The Secure Environment and the Kerberos V5 Protocol” shows the components of the secure environment in which the Secure Internet Services and the Kerberos V5 protocol operate. Each component and arrows 1-6 are explained after the figure.

Figure 11-1 The Secure Environment and the Kerberos V5 Protocol

Components of the Secure Environment

As part of the Kerberos V5 protocol, security clients authenticate themselves (verify their identity) to a trusted host. This trusted host is called the security server (A in Figure 11-1 “The Secure Environment and the Kerberos V5 Protocol”). We strongly recommend that the system where the security server is running be physically secure (for example, located in a locked room).

The security server is also referred to as the Key Distribution Center (KDC). The KDC provides Kerberos authentication services to security clients. Throughout the rest of this chapter the term KDC will be used to refer to a generic security server. Hewlett-Packard currently provides two products that fulfill the role of the KDC: the HP DCE Security Service and the HP Praesidium/Security Service (P/SS).

A security client is one of the following:

Application client (C in Figure 11-1 “The Secure Environment and the Kerberos V5 Protocol”): A Secure Internet Services application (ftp, rcp, remsh, rlogin, or telnet).
Application server (D in Figure 11-1 “The Secure Environment and the Kerberos V5 Protocol”): A Secure Internet Services daemon ( ftpd, remshd, rlogind, or telnetd).
Security client runtime (B in Figure 11-1 “The Secure Environment and the Kerberos V5 Protocol”): A Kerberos command (kinit, klist, or kdestroy).

Security clients communicate with the security server for authentication.

Note that none of the components of the Kerberos environment are restricted to run on a specific type of system. This means that security clients can run on the same node as the KDC, if you wish. For example, the security server (KDC), security client runtime (kinit), the application client (ftp), and application server (ftpd) could all be running on the same physical system.

A Simplified Description of the Kerberos V5 Protocol

The following steps refer to the arrows in Figure 11-1 “The Secure Environment and the Kerberos V5 Protocol”.

Users must first obtain credentials for themselves from a portion of the KDC called the Authentication Service (AS). The AS is the portion of the KDC that verifies the authenticity of a principal. Users must issue the kinit command which then calls the AS. HP DCE users would generally use the dce_login command instead of the kinit command, and HP P/SS users would use the dess_login command.
Once the AS finds an entry for the user principal, it issues encrypted credentials back to the client. The client will need these credentials to successfully run the Secure Internet Services. The credentials consist of a ticket, called the ticket granting ticket (TGT), and a temporary encryption key, often called the session key. The session key is a temporary encryption key used by the server to authenticate the client. It is encrypted in the server's key, and is typically valid for a login session. The user must obtain a TGT before running the Secure Internet Services.
All the user has to do up to this point is issue the kinit, dce_login, or dess_login command. The TGT and session key are automatically kept for the user in a temporary credentials cache file. The user does not need to explicitly do anything with them. However, at the end of the session, or when the credentials are no longer needed, we recommend that the user destroy the credentials by using a Kerberos utility called kdestroy.
When users invoke one of the Secure Internet Services, they enter the usual command along with any desired command options.
From a user's perspective, using the Internet Services with the Secure Internet Services mechanism enabled is virtually identical to using them without the mechanism enabled. The only difference is that the user is not prompted for a password. If the Kerberos V5 authentication and authorization succeed, the command succeeds and the details are transparent to the user.
Although it is not visible to the user, more is going on.
When a user invokes a Secure Internet Service, the client contacts the ticket granting service (TGS) portion of the KDC. The client passes along to the TGS the TGT, the name of the application server (remote host), and an authenticator. The authenticator is a record containing information that can be shown to have been recently generated using the session key known only by the client and the server. The encrypted authenticator is generated from the session key that was sent with the credentials from the AS.
The TGS generates new credentials that both the server and client use to authenticate each other. The TGS sends back to the client a new session key, called the sub-session key, that is encrypted in the old session key. The TGS also sends back to the client a ticket, called a service ticket. The service ticket contains a copy of the sub-session key and is encrypted in the target server's secret key. The secret key is an encryption key shared by a principal and the KDC. These encrypted keys are stored in the KDC's principal database. A secret key has a relatively long lifetime as compared to the relatively short lifetime of a session key.
The same TGT can be used to obtain multiple service tickets.
The client then sends to the application server the service ticket and a new authenticator encrypted using the sub-session key. The application server decrypts the service ticket with its own secret key and extracts the sub-session key. This sub-session key is now a shared secret between the client and the application server.
At the client's request, the application server can also return to the client credentials encrypted in the sub-session key. This implies a mutual authentication between the client and the application server. This optional Kerberos V5 mutual authentication step is performed in each of the Secure Internet Services.

To summarize,

The user obtains a TGT from the AS portion of the KDC when it first issues the kinit, dce_login, or dess_login command to the KDC.
When the user invokes a Secure Internet Service, the client requests a service ticket from the TGS portion of the KDC. It obtains this service ticket by presenting the TGT and other credentials to the TGS portion of the KDC.
The client sends the service ticket and other credentials received from the TGS to the application server. This authenticates the application client to the application server. This authentication replaces the non-secure authentication method of sending a password, in a readable form, to the application server.

Related Terms and Concepts

Some of the terms and concepts you might find helpful in understanding the secure environment are briefly discussed in the paragraphs below.

Kerberos Utilities

The following utilities must exist on all security clients (HP provides these utilities on HP clients):

kinit: This command obtains and caches a TGT for the user. For more information, refer to the kinit(1) man page.
klist: This command displays the list of tickets in the user's credentials cache file. For more information, refer to the klist(1) man page.
kdestroy: This command destroys the user's accumulated credentials. For more information, refer to the kdestroy(1) man page.

Realms/Cells

A realm defines an administrative boundary, and has a unique name. It consists of the KDC and all the security clients (application servers and application clients) registered to that KDC. By convention, Kerberos uses uppercase realm names, which appear as suffixes in principal names ( david@MYREALM.COM).

When using the HP DCE Security Service as a KDC, the term cell is used. A cell is roughly equivalent to a realm. An HP DCE cell name must be lowercase. It appears as a prefix and has a leading "/.../" in a principal name (/.../my_kdc_cell.com/david).

Domains

A P/SS domain defines an administrative structure and is equivalent to a Kerberos realm and an HP DCE cell. Like an HP DCE cell, its name must be lowercase. It appears as a prefix and has a leading "/.../" in a principal name (/.../my_domain/david).

Cross-Realm Authentication

Cross-realm authentication occurs when a client from one realm wishes to access a server from a different realm. Since each KDC administers tickets for a specific realm, cross-realm operation requires using inter-realm keys with the KDC. Cross-realm authentication is also referred to as inter-realm authentication.

Currently it is not possible to set up heterogeneous cross-realm authentication between an HP DCE or P/SS KDC and a Kerberos V5 KDC. Cross-realm authentication is available between realms hosted by KDCs of the same type. In other words, for cross-realm configurations with the Secure Internet Services, all the KDCs must be HP DCE Security Services, all the KDCs must be HP P/SSs, or all the KDCs must be Kerberos V5 KDCs.

Principals

Principals are uniquely named network entities, including users and services. Principal names contain the cell to which they belong, and each principal has a unique key associated with it. All principals that participate in Kerberos V5 authentication and authorization are required to be included in the KDC's database. The KDC database does not distinguish between types of principal names. However, it is useful to describe two kinds of principal names: user principal names and service principal names.

User Principal Names

A user principal name is associated with a specific user of the Secure Internet Services. User principal names consist of a user ID and a realm, cell, or domain name. All users must have one or more user principal names in the KDC's database. Some examples of user principal names are the following:

Kerberos: susan@MYREALM.COM
HP DCE: /.../my_kdc_cell/susan
HP P/SS: /.../my_domain/susan

Service Principal Names

A service principal name is a principal name that authorizes an application server to use a particular service.

For ftp, the service principal name is ftp (as a first choice) or host (as an acceptable second choice. Note that the actual name is host; it is not meant to be replaced by a host name.)

For rcp, remsh, rlogin, and telnet, the service principal name is host.

Some examples of service principal names for telnetd are the following:

Kerberos: host/abc.com@REALM_A.COM.
In this example, the system is abc.com, and the realm is REALM_A.COM.
HP DCE: /.../cell_a.com/host/abc.com
This example uses cell_a.com instead of REALM_A.COM (as used in the first example).
HP P/SS: /.../domain_a.com/host/abc.com
This example uses domain_a.com instead of REALM_A.COM (as used in the first example).

Authorization

Authorization is the process in which users verify that they can access a remote account on a specified server. Authorization depends on successful user principal validation through the Kerberos V5 authentication protocol described earlier in this section.

For authorization to succeed, a mapping must exist at the application server authorizing the user principal to operate as the login user. The term "login user" refers to the user whose account is being accessed on the remote host. This is not necessarily the same user who originally issued the kinit, dce_login, or dess_login command.

Assume david has already issued the kinit command. In this example, david enters the following:

$ ftp hostA
$ Connected to hostA
$ Name:(hostA:david): susan

In this example, susan is the login user.

Both of the following requirements must be met for authorization to succeed:

The login user must have an entry in the /etc/passwd file on the host where the application server is running.
One of the following three conditions must be met:
- A $HOME/.k5login file must exist in the login user's home directory on the application server and contain an entry for the authenticated user principal. This file must be owned by the login user and only the login user can have write permission.
- An authorization name database file called /krb5/aname must exist on the application server and contain a mapping of the user principal to the login user.
- The user name in the user principal must be the same as the login user name, and the client and server systems must be in the same realm.

Forwarded/Forwardable Tickets

When a user obtains service ticket credentials, they are for a remote system. However, the user might want to use a secure service to access a remote system and then run a secure service from that remote system to a second remote system. This would require possession of a valid TGT for the first remote system. However, running kinit on the first remote system to obtain a TGT would cause the user's password to be transmitted in a readable form over the network.

To avoid this problem, Kerberos provides the option to create TGTs with special attributes allowing them to be forwarded to remote systems within the realm.

The Secure Internet Services clients which offer TGT forwarding options (-f, -F) are remsh, rlogin, and telnet. However, before these options can be recognized, two prerequisite flags must be enabled.

First, the KDC's forwardable ticket option must be enabled. For Kerberos V5 KDCs, use the kadmin command. For the HP DCE Security Service and the HP P/SS, use the dcecp command to set the forwardabletkt account attribute.

Second, kinit must be invoked with the forwardable flag set (-f). If the -f option is specified when kinit is run, the TGT for the local system can be forwarded to the remote system. Then clients do not need to re-authenticate themselves from the remote system to the KDC.

HP DCE clients can use dce_login -f to enable forwarding. However, HP P/SS clients must use kinit -f to enable forwarding because the dess_login utility does not have an option for ticket attributes.

Provided these two flags are enabled, the forwarding options of rlogin, remsh, and telnet can take effect. For the remsh, rlogin, or telnet client that invokes the -f option, the TGT is forwarded to only one remote system (one free hop). For the remsh, rlogin, or telnet client that invokes the -F option, it is possible to keep forwarding the TGT (potentially n free hops).

Multiple free hops are possible because using the -F option leaves the forwardable attribute enabled in the forwarded TGT ticket, whereas using the -f option does not. So, the client can forward the TGT to an unlimited number of remote systems if the -F option is used every time. Once the -f option is used, the forwarding chain stops at the next node.

If the Kerberos V5 credentials are forwarded to a DCE client, they will be promoted to DCE credentials. This will allow the user to run DCE applications on the remote host. The k5dcelogin utility, which is invoked by rlogind/remshd and telnetd on the remote host, converts the Kerberos V5 credentials to DCE credentials without prompting for a password. See the man page for k5dcelogin(8sec) for syntax information.

API (Application Program Interface)

The Secure Internet Services mechanism for rcp/remshd, remsh/remshd, rlogin/rlogind, and telnet/telnetd uses the Kerberos V5 Release 1.0 API.

The Secure Internet Services mechanism for ftp/ftpd uses the GSS-API (Generic Security Service Application Program Interface) Version 1. The GSS-API separates application logic from a given security mechanism.

For more information on GSS-API Version 1, refer to RFCs 1508, 1509, and 1964.

Secure Environment Configurations

Configurations consist of KDCs and client nodes. The figures below illustrate possible KDC/client configurations. The paragraphs following the figures describe the nodes in more detail and also discuss interoperability among the nodes.

Figure 11-2 Client Interoperability with HP DCE and P/SS Security Servers

Figure 11-2 “Client Interoperability with HP DCE and P/SS Security Servers” illustrates which security clients can interoperate in configurations using HP DCE Security Services. Though not shown here, there might be multiple HP DCE Security Services in the configuration.

Figure 11-3 Client Interoperability with Non-HP Kerberos V5 KDCs

Figure 11-3 “Client Interoperability with Non-HP Kerberos V5 KDCs” illustrates which security clients can interoperate in configurations using non-HP Kerberos V5 KDCs. Though not shown here, there might be multiple non-HP Kerberos V5 KDCs in the configuration.

Types of KDC Nodes

The HP DCE Security Service can be configured to run with security clients using the Secure Internet Services and fulfill the role of the KDC. An HP DCE Security Service node runs the HP DCE security daemon secd. This node can be configured as the only member of a single-node DCE cell, or as a member of a multi-node cell with HP DCE clients.
For more information on how to configure an HP DCE Security Service, see Planning and Configuring HP DCE.
The HP DCE Security Service is shown as node A in Figure 11-2 “Client Interoperability with HP DCE and P/SS Security Servers”.
The HP P/SS can be configured to run with security clients using the Secure Internet Services and fulfill the role of the KDC. An HP P/SS security server node runs the HP P/SS security daemon secd. This node can be configured as the only member of a single-node P/SS domain, or as a member of a multi-node domain with HP P/SS clients.
For more information on how to configure an HP P/SS, see Planning and Configuring Praesidium/Security Service.
The HP P/SS security server is shown as node F in Figure 11-2 “Client Interoperability with HP DCE and P/SS Security Servers”.
The Non-HP Kerberos V5 KDC can be configured to run with security clients using the Secure Internet Services. A non-HP Kerberos V5 KDC is any non-HP KDC that implements the Kerberos V5 protocol (described in RFC 1510).
For more information, refer to your KDC provider's documentation.
The Non-HP Kerberos V5 KDC is shown as node G in Figure 11-3 “Client Interoperability with Non-HP Kerberos V5 KDCs”.

Types of Security Clients Using Secure Internet Services

The HP DCE client is a node configured into a DCE cell using the dce_config utility. The HP DCE file set DCE-Core.DCE-CORE-RUN, which is automatically installed, must be configured on this client. The HP Secure Internet Services mechanism must be enabled on this client.
The Kerberos utilities kinit, klist, and kdestroy are supplied by HP on this client. However, this client generally obtains credentials using the dce_login command, rather than the Kerberos kinit command. This client can use dcecp and other administrative tools for Kerberos-related management tasks.
For more information, see Using HP DCE 9000 Security with Kerberos Applications, available in postscript and ASCII form in the directory /opt/dce/newconfig/RelNotes/ in the files krbWhitePaper.ps and krbWhitePaper.text.
The HP DCE client is shown as node B in Figure 11-2 “Client Interoperability with HP DCE and P/SS Security Servers”.
The HP P/SS client is a node configured into a P/SS domain using the dess_config utility. The HP P/SS file set DESS-Core.DESS-CORE-RUN, which is automatically installed, must be configured on this client. The HP Secure Internet Services mechanism must be enabled on this client.
The Kerberos utilities kinit, klist, and kdestroy are supplied by HP on this client. However, this client generally obtains credentials using the dess_login command, instead of the Kerberos kinit command. This client can use dcecp and other administrative tools for Kerberos-related management tasks.
For more information, see Appendix C ("Using Praesidium/Security Service with Kerberos Applications") in Planning and Configuring Praesidium/Security Service.
The HP P/SS client is shown as node C in Figure 11-2 “Client Interoperability with HP DCE and P/SS Security Servers”.
The HP Kerberos client is a node with the same client software as the HP DCE or P/SS client. This node, however, is not configured into a DCE cell or a P/SS domain. The HP DCE file set DCE-Core.DCE-CORE-RUN, which includes the Kerberos utilities kinit, klist, and kdestroy, is automatically installed on this client. The HP Secure Internet Services mechanism must be enabled on this client.
The Kerberos utilities kinit, klist, and kdestroy are supplied by HP. The HP Kerberos client treats the HP DCE Security Service or the HP P/SS as an ordinary Kerberos KDC. Credentials are obtained with the Kerberos command kinit, not the HP DCE command dce_login or the P/SS command dess_login. The HP Kerberos client cannot use HP DCE or P/SS administration tools for Kerberos-related management tasks. The creation and update of Kerberos-related files must be done manually.
For more information, see Using HP DCE 9000 Security with Kerberos Applications, available in postscript and ASCII form in the directory /opt/dce/newconfig/RelNotes/ in the files krbWhitePaper.ps and krbWhitePaper.text. For more information about P/SS, see Appendix C ("Using Praesidium/Security Service with Kerberos Applications") in Planning and Configuring Praesidium/Security Service.
The HP Kerberos client is shown as node D in Figure 11-2 “Client Interoperability with HP DCE and P/SS Security Servers” and Figure 11-3 “Client Interoperability with Non-HP Kerberos V5 KDCs”.

Allowable Non-HP Security Client Nodes

The non-HP Kerberos client is a node running non-HP security client software. This includes non-HP versions of the Kerberos utilities kinit, klist, and kdestroy, and non-HP secure versions of internet services.

Generally, configurations that contain non-HP security clients will interoperate securely with configurations that include the HP Secure Internet Services, provided all of the following things are true:

The Kerberos utilities kinit, klist, and kdestroy are based on Kerberos V5.
Secure versions of rcp/remshd, remsh/remshd, rlogin/rlogind, and telnet/telnetd either are implemented with Kerberos V5 Release 1.0 API or interoperate with it.
Secure versions of ftp/ftpd are implemented according to the FTP security extension standard and use the GSS-API Version 1 based on the Kerberos V5 Release 1.0 API.

For information on the non-HP Kerberos client, refer to your provider's documentation.

The non-HP Kerberos client is shown as node E in Figure 11-2 “Client Interoperability with HP DCE and P/SS Security Servers” and Figure 11-3 “Client Interoperability with Non-HP Kerberos V5 KDCs”.

Interoperability within a Realm

Within a given realm, all KDCs must be of the same type. In other words, for configurations that include the Secure Internet Services, KDCs must be all HP DCE Security Services, all HP P/SSs, or all non-HP Kerberos V5 KDCs (implementing RFC 1510). Multiple KDCs of the same type can exist. In these cases there is effectively one "master" KDC. The additional KDCs contain duplicate, read-only, database information from the master. This is done for availability purposes: if the master goes down, a "slave" (one of the KDCs with the duplicate information) takes over for the master.

Currently it is not possible to set up heterogeneous cross-realm authentication between an HP DCE or P/SS KDC and a Kerberos V5 KDC. So, even in cross-realm configurations, all KDCs must be of the same type. In other words, they must be either all HP DCE Security Services, HP P/SSs, or all non-HP Kerberos V5 KDCs (implementing RFC 1510).

For more specific interoperability information with non-HP Kerberos clients (node E in Figure 11-2 “Client Interoperability with HP DCE and P/SS Security Servers” and Figure 11-3 “Client Interoperability with Non-HP Kerberos V5 KDCs”), contact your HP support representative.