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 3-1 The Secure Environment and the Kerberos V5 Protocol

Figure 3-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 below.

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 1). It is highly recommended that the security server host machine be physically secure (e.g. located in a locked room).

The security server is also referred to as the Key Distribution Center (KDC). The KDC provides Kerberos authentication services by issuing encrypted tickets, which clients and servers share. Throughout the rest of this chapter the term KDC will be used to refer to a generic security server. HP's product that currently fulfills the role of the KDC is the HP DCE Security Server.

Security clients are hosts that run the Secure Internet Services clients and daemons (B and C in Figure 3-1 “The Secure Environment and the Kerberos V5 Protocol”). Security clients communicate with the security server for authentication.There are two types of security clients: application clients and application servers.

Application clients (B in Figure 3-1 “The Secure Environment and the Kerberos V5 Protocol”) are hosts that run one or more of the following Secure Internet Services clients: ftp, rcp, remsh, rlogin, and telnet. The Kerberos utilities kinit, klist, and kdestroy also run on the application client. (See “Related Kerberos Terms and Concepts”.) In some examples, application clients may be referred to as local hosts.

Application servers (C in Figure 3-1 “The Secure Environment and the Kerberos V5 Protocol”) are hosts that run one or more of the following Secure Internet Services daemons: ftpd, remshd, rlogind, and telnetd. In some examples, application servers may be referred to as remote hosts.

A specific security client can be, and usually is, both an application client and application server. However, it makes sense to distinguish between these roles when describing the Kerberos V5 protocol.

A Simplified Description of the Kerberos V5 Protocol

The following steps refer to the arrows indicated in Figure 3-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 Server (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 rather than the kinit 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 typically valid for a login session. It is encrypted in the server's key. 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, or dce_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, it is recommended that the user destroy the credentials 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, the interface to the Secure Internet Services is virtually identical to that of the non-secure versions of the services. Aside from new kerberos-related security options, 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, or dce_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 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 Kerberos Terms and Concepts

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 defined an administrative boundary. It has a unique name. It consists of the KDC and all the security clients (application servers and application clients) registered to that KDC.

When using the HP DCE Security Server as a KDC, the term "cell" is used. A cell is roughly equivalent to a realm.

By convention, Kerberos uses uppercase realm names, which appear as suffixes in principal names (david@MYREALM.COM).

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

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 a DCE 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 Servers, or all the KDCs must be Kerberos V5 KDCs.

Principals

Principals are uniquely named network entities, including users and services. Principals have names that include realm (or cell) information and an associated key. 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 (or cell) name. All users must have one or more user principal names in the KDC's database. An example of a Kerberos user principal name is, susan@MYREALM.COM. An example of an HP DCE user principal name is, /.../my_kdc_cell/susan.
Service Principal Names
A service principal name is a principal name that authorizes a client to use a particular service, including the specific application server machine the service will access and the realm name.
For rcp, remsh, rlogin, and telnet, the service principal name is host. (The actual word is host. It is not meant to be replaced by a host name.)
For ftp, the service principal name is ftp (as a first choice) or host (as an acceptable second choice).
Following is an example of a Kerberos service principal name for telnetd:
host/abc.com@REALM_A.COM.
In this example, the system is abc.com, and the realm is REALM_A.COM.
Following is an example of an HP DCE service principal name for telnetd:
/.../cell_a.com/host/abc.com.
This example uses cell_a.com instead of REALM_A.COM.

Authorization

Authorization is the process in which users verify that they may 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 on the application server machine 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, or dce_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 application server (remote host).
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 may 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 Server, 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 selected 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 must use kinit -f to enable forwarding as the dce_login utility does not have options 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 forwarding of the TGT only happens to 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. Thus, 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.

API (Application Program Interface)

The Secure Internet Services versions of rcp/remshd, remsh/remshd, rlogin/rlogind, and telnet/telnetd use the Kerberos V5 Beta 4 API.

The Secure Internet Services versions of ftp/ftpd use 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 and 1509.

Secure Environment Configurations

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

Figure 3-2 Client Interoperability with HP DCE Security Servers

Figure 3-2 “Client Interoperability with HP DCE Security Servers” illustrates which security clients can interoperate in configurations using HP DCE Security Servers. Though not shown here, there may be multiple HP DCE Security Servers in the configuration.

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

Figure 3-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 may be multiple non-HP Kerberos V5 KDCs in the configuration.

Types of KDC Nodes

The HP DCE Security Server can be configured to run with security clients using the Secure Internet Services and fulfill the role of the KDC. An HP DCE Security Server 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 Server, see Planning and Configuring HP DCE.
The HP DCE Security Server is shown as node A in Figure 3-2 “Client Interoperability with HP DCE 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 E in Figure 3-3 “Client Interoperability with Non-HP Kerberos V5 KDCs”.

Types of Security Client Nodes Using the 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 product, InternetSvcSec, must be installed, enabled and configured on this client.
The Kerberos utilities kinit, klist, and kdestroy are supplied by HP on this client. However, this client generally obtains credentials using thedce_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 3-2 “Client Interoperability with HP DCE Security Servers”.
The HP Kerberos Client is a node with the same client software as the HP DCE client. This node, however, is not configured into a DCE cell. 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 product, InternetSvcSec, must be installed, enabled and configured on this client.
The Kerberos utilities kinit, klist, and kdestroy are supplied by HP. The HP Kerberos client treats the HP DCE Security Server as an ordinary Kerberos KDC. Credentials are obtained with the Kerberos command kinit, not the HP DCE command dce_login. The HP Kerberos client cannot use HP DCE 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.
The HP Kerberos Client is shown as node C in Figure 3-2 “Client Interoperability with HP DCE Security Servers” and Figure 3-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 the following is true:

The Kerberos utilities kinit, klist and kdestroy are based on Kerberos V5 Beta 4.
Secure versions of rcp/remshd, remsh/remshd, rlogin/rlogind and telnet/telnetd are implemented with Kerberos V5 Beta 4 API.
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 Beta 4 API.

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

The Non-HP Kerberos Client is shown as node D in Figure 3-2 “Client Interoperability with HP DCE Security Servers” and Figure 3-3 “Client Interoperability with Non-HP Kerberos V5 KDCs”.

Interoperability

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 either all HP DCE Security Servers or all non-HP Kerberos V5 KDCs (implementing RFC 1510). Multiple KDCs of the same type may exist. In these cases there is effectively one "master" KDC. The additional KDCs contain duplicate, read-only, database information from the master. This can be helpful for load balancing purposes.

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

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

Overview of the Secure Environment and the Kerberos V5 Protocol

Technical documentation

» Table of Contents

Components of the Secure Environment

A Simplified Description of the Kerberos V5 Protocol

Related Kerberos Terms and Concepts

Secure Environment Configurations