Kerberos

Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by secret-key cryptography. The key design goal is to create a secure environment for students at workstations, where password sniffing is a major problem. It ensures that passwords are never sent over the network directly. This is done by providing a trusted third party (the Kerberos security server) which holds the user secret password and uses public cryptography as a mean by which constituents of the network (principals) can trust each other. 

The situation with password sniffing was typical for university campuses LANs before switched network implementations and is still typical for WANs. Kerberos originated in MIT(Massachusetts Institute of Technology). MIT provides  free implementation of the protocol. Kerberos is available in many commercial products as well including Windows. Kerberos is distributed under freely BSD license.

The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.

Kerberos is very popular in US military as well as large US universities (University of Michigan is one).  Microsoft has its own implementation of Kerberos (starting with Windows 2000) that has Microsoft-only extensions, but still can interoperate with Unix on the level of base protocol. 

NIS is the standard part of the Unix so it is available on all three major commercial Unixes and linux. Kerberos v.5 also is available for all three Unixes free of charge. The  tandem Kerberos + NIS provides both secure central authentication and local changing of passwords (from any server the user has account on) as well as central user management in a very secure, reliable way with minimal overhead for the base OS.  I think that this solution might be considered as it has both high reliability, multiplatform (Windows can use Kerberos  as well) and can inflict minimal damage because we essentially use parts of the OS that just were not activated.

Installation needs two servers (main and backup) similar to Secure ID. Actually servers can be shared with Secure ID. In this case additional "parasitic" servers are not needed.

When a user logs on to a host running Kerberos, the user is issued a ticket from a Ticket Granting Server (TGS) (a kind of session key). From that point on the ticket must be presented in all transactions. All information sent by Kerberos is encrypted with a user's password, so eavesdropping is not possible. Passwords are never sent over the network directly.

Kerberos authentication is based entirely on knowledge of passwords which are stored on the Kerberos Authentication Server (KAS) for a realm (Kerberos domains are called realms). Unlike Unix and NT passwords which are encrypted with a one-way hash function, Kerberos passwords are encrypted using DES and can be decrypted by the server if needed. This is seen by many as a serious disadvantage of the Kerberos system.

Using Kerberos looks just like using an ordinary host, except that tickets are one-time passwords that expire after a certain period and a user is asked to re-authenticate the login by entering his/her password again. This is to avoid the possibility of someone guessing or determining a user's ticket.

Here is a simplified description (see Gollmann 10.2.1 for a better one) of authentication process. Suppose host A requires a service from host B.

1. A user enters login name and password on host A at the start of a session.
2. The username/ID is sent with a random challenge and the name of the TGS in clear text to the authentication server (KAS).
3. The KAS replies with a session key or one-time-password for talking to the Ticket server which is encrypted using the user's password (stored on the KAS).
4. The user can decrypt if the passwords match. If all goes well, the user is authenticated and is given the key K_tgs as proof.
5. Using the session key K_tgs, the user's workstation then talks to the TGS whenever it needs a service and obtains an encryption key for each session between A and B. The user's password is no longer needed; the ticket is used instead. The ticket server is thus a one-time-password generation server which uses the key K_tgs as proof of identity.

• Every service must be modified to use Kerberos. In Unix this is not a problem as it can be done via PAM. 
• Kerberos has security problems if several users are logged on to the same host(!!) It keeps tickets in the /tmp directory.
• Security is only guaranteed if the Kerberos servers are secure. All passwords on the server are encrypted using a single master key, which is stored on the same host as the passwords.
• Kerberos does not authenticate the system to the user, only the user to the system, so Trojan horses could be used to fool users.

The following is an intuitive description. The client authenticates itself to the Authentication Server and receives a ticket (All tickets are time-stamped.) It then contacts the Ticket Granting Server, and using the ticket it demonstrates its identity and asks for a service. If the client is eligible for the service, then the Ticket Granting Server sends another ticket to client. The client then contacts the Service Server, and using this ticket it proves that it has been approved to receive the service.

A simplified and more detailed description of the protocol follows. The following abbreviations are used:

• AS = Authentication Server
• SS = Service Server
• TGS = Ticket-Granting Server
• TGT = Ticket-Granting Ticket

The client authenticates to the AS once using a long-term shared secret (e.g. a password) and receives a TGT from the AS. Later, when the client wants to contact some SS, it can (re)use this ticket to get additional tickets for SS without resorting to using the shared secret. These tickets can be used to prove authentication to SS.

The phases are detailed below.

User Client-based Logon

1. A user enters a username and password on the client machine.
2. The client performs a one-way function (hash usually) on the entered password, and this becomes the secret key of the client/user.

Client Authentication

1. The client sends a cleartext message of the user ID to the AS requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.) The AS generates the secret key by hashing the password of the user found at the database (e.g. Active Directory in Windows Server).
2. The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:
   • Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
   • Message B: Ticket-Granting Ticket (which includes the client ID, client network address, ticket validity period (time to live), and the client/TGS session key) encrypted using the secret key of the TGS.
3. Once the client receives messages A and B, it decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS's secret key.) At this point, the client has enough information to authenticate itself to the TGS.

Client Service Authorization

1. When requesting services, the client sends the following two messages to the TGS:
   • Message C: Composed of the TGT from message B and the ID of the requested service.
   • Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.
2. Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client:
   • Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service's secret key.
   • Message F: Client/server session key encrypted with the Client/TGS Session Key.

Client Service Request

1. Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages:
   • Message E from the previous step (the client-to-server ticket, encrypted using service's secret key).
   • Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server session key.
2. The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:
   • Message H: the timestamp found in client's Authenticator plus 1, encrypted using the Client/Server Session Key.
3. The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server.
4. The server provides the requested services to the client.

Drawbacks

• Single point of failure: It requires continuous availability of a central server. When the Kerberos server is down, no one can log in. This can be mitigated by using multiple Kerberos servers and fallback authentication mechanisms.
• Kerberos requires the clocks of the involved hosts to be synchronized. The tickets have a time availability period and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail. The default configuration per MIT requires that clock times are no more than five minutes apart. In practice Network Time Protocol daemons are usually used to keep the host clocks synchronized.
• The administration protocol is not standardized and differs between server implementations. Password changes are described in RFC 3244.
• Since all authentication is controlled by a centralized KDC, compromise of this authentication infrastructure will allow an attacker to impersonate any user.

History

Implementing Kerberos in Distributed Systems

Ray Kaplan
Joe Kovara
Glen Zorn

One of the most significant problems in securing distributed systems is authentication. This is, ensuring that the parties to a conversation - possibly separated by a wide area network and traversing untrusted systems and communications paths - are who they claim to be. Kerberos is currently the de facto standard for authentication in large, heterogeneous network environments.

Kerberos has been in production for more than six years in one of the world's most challenging open systems environments - Project Athena at MIT.¹ Kerberos is the backbone of network security for Project Athena, where it protects more than 10,000 users accessing thousands of workstations and hundreds of servers. Kerberos protects thousands of sessions and tens of thousands of mail messages per day. As such, Kerberos is arguably the best-tested, most scrutinized authentication protocol in widespread use today.

---

¹Project Athena is a model of "next-generation distributed computing" in the academic environment. It began in 1983 as an eight-year project with DEC and IBM as its major industrial sponsors. Their pioneering model is based on client-server technology and it includes such innovations as authentication based on Kerberos and X Windows. An excellent reference - George Champine, MIT Project Athena, A Model for Distributed Campus Computing, Digital Press, 1991.

---

HISTORY OF DEVELOPMENT

Many of the ideas for Kerberos originated in a discussion of how to use encryption for authentication in large networks that was published in 1978 by Roger Needham and Michael Schroeder.² Other early ideas can be attributed to continuing work by the security community, such as Dorothy Denning and Giovanni Sacco's work on the use of time stamps in key distribution protocols.³ Kerberos was designed and implemented in the mid-1980s as part of MIT's Project Athena. The original design and implementation of the first four versions of Kerberos were done by MIT Project Athena members Steve Miller (Digital Equipment Corp.) and Clifford Neuman, along with Jerome Salzer (Project Athena technical director) and Jeff Schiller (MIT campus network manager).

---

²Needham, R.M. and Schroeder, M., Using encryption for authentication in large networks of computers, Communications of the ACM 21 (December 1978), pp. 993–999.
³Denning, D.E. and Sacco, G.M., "Timestamps in key distribution protocols, Communications of the ACM 24 (August 1981), pp. 533–536.

---

Kerberos versions 1 through 3 were internal development versions and, since its public release in 1989, version 4 of Kerberos has seen wide use in the Internet community. In 1990, John Kohl (Digital Equipment Corp.) and Clifford Neuman (University of Washington at that time and now with the Information Sciences Institute at the University of Southern California) presented a design for version 5 of the protocol based on input from many of those familiar with the limitations of version 4. Currently, Kerberos versions 4 and 5 are available from several sources, including both freely distributed versions (subject to export restrictions) and fully supported commercial versions.

FUNCTIONAL OVERVIEW

Kerberos is an authentication protocol that has been built into a system that provides networkwide security services. Kerberos can solve many of the security problems of large, heterogeneous networks, including mutual authentication between clients and servers. The basic idea behind Kerberos is that a trusted third party (the Kerberos security server) provides a means by which constituents of the network (principals) can trust each other. These principals may be any hardware or software that communicates across the network. In addition to authentication, Kerberos offers both privacy and integrity for network messages.

There is considerable detail in describing how Kerberos works, and the actual exchanges that take place over the network are a bit complicated. However, the basic idea is quite straightforward and follows this five-step process:

1. On behalf of a user (or surrogate, such as a program), a Kerberos client in the user's workstation asserts the user's identity to the Kerberos server and verifies it locally on the workstation.

2. Kerberos client software on the workstation asks the Kerberos security server for the credentials necessary to use the service that the user requested.

3. The Kerberos security server sends the user's credentials for the requested service to the Kerberos client where they are cached.

4. A client application on the workstation picks up the user's credentials from the workstation's credential cache for that user and presents them to the application server that it wants to use.

5. The application server authenticates the client application to the service that the user requested and the server delivers the requested services.

Exhibit 1 illustrates how this works.

Exhibit 1. Kerberos Authentication Process

SCOPE OF SECURITY SERVICES

In his treatise on distributed systems security, Morrie Gasser⁴ categorizes the security services that a distributed system can provide for its users and applications as: secure channels, authentication, confidentiality, integrity, access control, non-repudiation, and availability.

⁴Gasser, M., Security in distributed systems, in Recent Developments in Telecommunications, North-Holland, Amsterdam, The Netherlands; Elsevier Science Publishers, 1992, pp. 145–228.

Secure Channels

A secure channel provides integrity and confidentiality services to communicating principals. Kerberos offers these services.

Integrity

An integrity service allows principals to determine if the message stream between them has been modified in an unauthorized manner. The Kerberos safe message includes a checksum that is used as an integrity check. Each principal in the Kerberos safe message exchange separately derives this checksum from the message using one of several available algorithms. The algorithms include a one-way message digest hash that has cryptographic strength. The nature of such a checksum is that it cannot be adjusted to conceal a change to the message.

Confidentiality

A confidentiality service is designed to counter passive wire-tapping by restricting the availability of message traffic to an authorized set of principals. The traffic itself and both source and destination addresses of the traffic are of interest. Obviously, the traffic itself can contain confidential information. In particular, Kerberos is specifically designed to minimize the transmission of passwords over the network and encrypt passwords under those few conditions when they are transmitted over the network. Kerberos also provides encryption of an application's message data if the application desires it.

Network addresses and traffic volume may be used to infer information. Consider that an increase in the traffic between two business partners may predict a merger. The Kerberos private message provides protection for message traffic between principals using the bulk data encryption technology such as the Data Encryption Standard (DES). Kerberos does not provide a defense against traffic analysis.

Authentication

An authentication service permits one principal to determine that the identity of another principal is genuine as represented. It is often important for both sides of an exchange to mutually authenticate. Kerberos currently uses a trusted third party (the Kerberos authentication server) to mediate the exchange of shared secrets between principals in order to authenticate principals to one another.

Access Control

An access control service protects information from disclosure or modification in an unauthorized manner by controlling which principals are granted access. Kerberos does not directly offer this service, although the protocol provides for the inclusion and protection of access control information in messages for use by applications and operating systems.

Nonrepudiation

Nonrepudiation services offer proof to the sender that information was delivered and proof to the recipient as to the origin of the information. Typically, such proof is used by an arbitrator to settle a repudiation-based dispute. For instance, in the case of E-mail between two people or electronic funds transfer between two business entities, a court of law would be the arbitrator that adjudicates repudiation-based disputes that arise. Kerberos offers the basic authentication and integrity services from which a nonrepudiation service could be built. Kerberos does not offer the arbitration services that are required for the complete implementation of such a service.

Availability

Availability services provide an expected level of performance and availability such as error-free bandwidth. Perhaps the best example of an availability problem is a denial of service attack. Consider someone simply disconnecting the cable that connects a network segment to its router. Kerberos does not offer any services to deal with this set of problems.

Summing up, Kerberos is an authentication protocol that has been extended to offer privacy and integrity of network messages. It does not offer protection against traffic analysis or availability services. Since it does offer authentication services, it can serve as a platform on which to build access control and non-repudiation.

APPLYING KERBEROS

The best way to think about Kerberos is as a suite of security services. An individual or program that wants to use Kerberos services must make explicit calls in order to obtain those services. A typical scenario is a user sitting at a workstation who wants to use an application that requires the user to first authenticate himself or herself to the application using Kerberos before the application will respond. First, the user runs a Kerberos utility on the workstation called kinit. Kinit obtains the user's Kerberos credentials from the Kerberos Authentication Server (AS) and caches them on the user's workstation. The user's credentials are now available for any application that demands them.

Here is how this looks for version 4 of Kerberos from MIT under UNIX:

     % kinit
     Zippy Corporation (node 1.zippy.com)
     Kerberos initialization
     kerberos name: george
     Password: a-good-password
     %

For a commercial implementation of version 5 of Kerberos under UNIX, this might look like:

     % kinit
     Password for [email protected]: a-good-password
     %

Under VMS, the same operation for version 4 of Kerberos might look like:

     $ KINIT
     Kerberos initialization for "george"
     kerberos name: george
     Password: a-good-password
     $

There are several players in a Kerberos authentication scheme: principals, an AS, and a ticket granting service (TGS). Principals are entities that use Kerberos security services. Principals can be human users or programs - typically users who are logged in at their workstations or the server-based applications that they want to use across the network. The functions of the AS and TGS are usually run on the same machine. This combination of services has come to be called a key distribution center (KDC). (This nomenclature is unfortunate; in cryptographic parlance, a KDC is a center established for the purpose of providing keys to the parties that wish to communicate.) The Kerberos KDC provides a means for authentication between principals.

The details of the Kerberos authentication exchange are simple, robust, and elegant - although not necessarily intuitive. The Kerberos principal asserts its identity by sending a clear text string to the AS. The AS provides Kerberos with credentials for that principal in answer to that request. However, before sending these credentials to the requesting principal, the AS encrypts them with a secret that is shared between the principal and Kerberos. This shared secret is the principal's Kerberos password, which is held in encrypted form in the key distribution center's data base. Once on the principal's workstation, these credentials are decrypted with a password that the user provides to the Kerberos client. If the principal can decrypt these credentials provided by the AS, the principal can use them. If the principal cannot decrypt these credentials provided by the AS, the principal cannot successfully use them. Thus, the initial authentication of a principal happens on the client workstation - not on the Kerberos security server.

This design has two very important features. First, because the principal asserts its identity using a clear test string and the AS encrypts the principal's credentials before it sends them back to the principal, authentication requires that no passwords ever be sent over the network - in clear text or encrypted. A wiretapper looking at the Kerberos initialization transaction would only see two messages, both of which are useless to the attacker:

• A clear text string going from the principal to the KDC, saying "Hello, my name is George."

• An incomprehensible (encrypted) text string from the KDC to the principal.

The ticket that the AS sends in response to the client's assertion of identity does not contain the client's encrypted password, but the ticket itself is encrypted with it. Therefore, the client workstation can decrypt it using the password that the user types. Consequently, the user's password only resides on the workstation for the very short period that it takes to decrypt the initial credentials.

Second, because the Kerberos client uses a password that it obtains from the user on his or her own workstation to decrypt the credentials from the AS, another user at another workstation cannot impersonate the legitimate one. Credentials are useless unless they can be decrypted, and the only way to decrypt them is to know the principal's password.

Kerberos credentials are authenticators called tickets. The authenticator that is exchanged between the principal and the AS in the Kerberos initialization sequence is called a ticket granting ticket (TGT). The TGT is so named because it is used to obtain tickets for various services the principal may wish to access. The TGT simply provides proof in subsequent requests for services without the user having to reauthenticate (e.g., type in the password again). This initial Kerberos exchange is summarized in Exhibit 2.

Exhibit 2. The Initial Kerberos Exchange

At the conclusion of this initial exchange, the client workstation holds a TGT for the client principal. From this point on, these Kerberos credentials are cached on the user's workstation. TGTs are used to obtain additional credentials specifically for each server application that the client principal wants to use. These service-specific credentials are called application service tickets, and they are obtained from the aforementioned Kerberos TGS.

Finally, these application service tickets are used by the client principal to authenticate itself to a server principal when it wants to use the Kerberos-authenticated service that a particular server principal is offering. Once activated, the client program transparently handles all other transactions with Kerberos and the application server.

Client principals authenticate themselves to their servers with service tickets that they obtain from the Kerberos TGS on behalf of their user, based on the TGT that was obtained by the user when they initialized Kerberos. This process is summarized in Exhibit 3.

Exhibit 3. Obtaining an Application Service Ticket from Kerberos

Except for having to run kinit to obtain the initial TGT, enter the Kerberos password, and start the desired application client, Kerberos is transparent from the user's point of view. It is possible to embed the functions of kinit (getting the TGT from Kerberos) in the workstation's login sequence such that everything except the entry of the user's password is transparent. In fact, a smart card or authentication token can be integrated with both Kerberos and the client workstation. In such a scenario, all users have to do is insert their tokens into their workstations. The tight integration of these pieces would allow the authentication sequence and the desired application to be activated automatically. Coupled with good security management of the workstation and the KDC, these basic features provide simple and robust security.

Client principals - be they the client side of applications or such native operating system utilities as UNIX login or telnet - must explicitly call for Kerberos services. In the public domain versions of Kerberos, applications use Kerberos services by calling Kerberos library functions. Some commercial implementations of Kerberos version 5 incorporate the generic security services applications programming interface (GSSAPI) as its standard application programming interface. Digital Equipment Corp. put forth this interface as a standard for security services. The GSSAPI is being considered by the Common Authentication Technology Working Group of the Internet Engineering Task Force as a standard for the Internet community. As outlined in the example of how the Kerberos protocol works, a client would use a sequence of GSSAPI calls to authenticate itself to an application server. Such a sequence of calls using the GSSAPI might look like this:

    gss_acquire_cred

    Obtain Kerberos credentials (i.e., a token, called a ticket).

    gss_init_sec_context

    Initialize the client's security context loop here, wait for success; then pass
    the Kerberos token (ticket) to the named server and start to consume appli
    cation services.

When incorporated into an existing production environment, Kerberos is not transparent. Each client or application server that wants to use Kerberos services must have calls to those services included in its code. As with any other security-related coding, this "kerberization" must be done based on sound applications design and discipline to ensure that it is done properly.

Currently, a few operating system vendors include Kerberos in the software that they ship. Third-party Kerberos suppliers provide Kerberos libraries and modify or rewrite standard operating system utilities to "kerberize" them. The convention in such operating systems as UNIX is that kerberized programs simply replace standard utilities, and users see no difference in the commands that they type. In some implementations for such operating systems as VMS, the standard commands are modified to include instructions that specify Kerberos (e.g., telnet/authorization = Kerberos). In other Kerberos implementations, the standard operating system utilities are actually replaced with appropriately named kerberized counterparts such as ktelnet.

Finally, in such operating system implementations as Kerberos for Microsoft Windows, Macintosh, and Next's NextStep, programs may actually have their own graphical user interfaces, just as would any other program in that environment. In these cases, a user just clicks on the appropriate icon.

For example, in a typical kerberized Windows environment, a user would simply click on the desired application icon to activate it after the user's Kerberos password had been entered. From there on, the application program handles the authentication in cooperation with Kerberos behind the scenes. An environment in which users only need to enter their passwords once has fostered the idea that Kerberos is a single-sign-on system. However, Kerberos can only provide this seemless access to kerberized applications. If workstation users must use many different nonkerberized applications that require them to log on with individual passwords, the addition of Kerberos to their workstation environment alone will not change things. Again, each application must be kerberized.

TECHNICAL ISSUES

The success of a Kerberos implementation depends on how carefully it is designed and how completely it is planned. Lack of these two critical elements is the major reason that the implementation of any security scheme fails. A detailed consideration of the authentication mechanism itself (e.g., what it is, how it works, how to use it, how to apply it, and its weaknesses) is important. A number of details may need to be addressed. These include: the topology of the network; the placement of authentication in the protocol stack; the use and availability of network services (such as time and naming); and the relative security of the basic network infrastructure. Understanding these details is a prerequisite to proper operation, performance, and administration of Kerberos.

Protocol Placement

In Exhibit 4, network segments A (which connects the primary KDC management capability to the KDC), and B (which connects other mission critical applications) may be more critical than network segments D and E (which connect relatively less important applications). Therefore, network segments A and B need to be carefully engineered, perhaps more so than network segments D and E. (As a reminder, Kerberos is an application level protocol. While most Kerberos implementations use TCP/IP, Kerberos itself is an authentication protocol that is independent of the underlying transport protocol.)

Exhibit 4. Network Topology and Authentication Protocol

Using the Kerberos authentication protocol across a security firewall may make the firewall's design, implementation, and operation more complicated. Many such firewalls use filtering or proxy agents that operate at the application layer in the protocol stack. Because the security firewall exists to protect the rest of the network from network segments D and E (including systems C and D, and whatever else they are connected to), the security firewall needs to understand how to deal with Kerberos traffic. Of course, the firewall may also need to deal with application server traffic from system D if its application is in use elsewhere in the network.

Time Services and Network Naming

Although Kerberos was designed to bring authentication to a network that generally lacks security-related services, the degree to which Kerberos can be trusted largely depends on how carefully it is implemented and the robustness of its supporting network services.

Kerberos requires trusted, loosely synchronized clocks in the network. Dorothy Denning and Giovanni Sacco's work on the use of time stamps in key distribution protocols shows that enforcing limited lifetimes for authentication credentials based on time stamps can minimize the threat of replaced credentials. This can only be guaranteed through the use of trusted, or authenticated, network time services.

Kerberos authenticates to the names of its principals. Principals must have a secure way to determine the names of other principals that they are willing to communicate with. However, IP network addresses and network name services (e.g., TCP/IP Domain Name Service, DNS) can be spoofed. There are several ways to ensure that principal names can be trusted. For example, a principal name might be placed in an access control list of an application server. Alternatively, local knowledge of a designated application server might be hard coded into an application client. Finally, use of a name service can provide some measure of assurance, because answers from the name server must be authentic.

Within the limits of the encryption and key exchange protocol technology that Kerberos uses, its authentication is held together by trust. The KDC and principals must trust one another to be who they represent themselves to be. This keystone is held in place by trusted time services and robust means for principals to identify one another. Kerberos provides a mechanism for securely authenticating principals. However, in the real world, it is also necessary to secure the information about which principal one is willing to talk to.

The KDC, Application Servers, and Their Clients

As explained earlier in this chapter, the KDC, kerberized application servers, and their clients must be protected so that their operation cannot be unduly influenced. The KDC must be physically secure and must not allow any non-Kerberos network activity. For example, allowing the KDC to run a network protocol that is a known security risk (e.g., UNIX Trivial File Transfer Protocol (TFTP) or UNIX sendmail mailer) is an invitation to disaster. In general, the only application that should run on the KDC (and its slave servers) is Kerberos.

Both servers and clients must be protected from compromise. Although they are less critical than the KDC and its slaves, if a server or a client is compromised, their roles in the Kerberos authentication process can no longer be trusted. Although it may seem odd that the principals that Kerberos is authenticating need to be protected, consider that all security is built on a foundation of basics such as good control over both physical and logical access to the computing environment. If physical and logical access to Kerberos principals is not properly managed, client and server identities can be spoofed. Additionally, if users do not properly manage their Kerberos passwords (or it is not properly managed for them with a smart card or token device), their identity can be spoofed.

Kerberos Administration

Kerberos administration must be coordinated with other administrative tasks. For example, many organizations maintain their user community controls in a data base that is updated periodically, with changes propagated to individual systems and applications (e.g., individual LA authorization data bases). When an employee leaves the company, among the access privileges needing to be revoked is that user's Kerberos access. It should also be recognized that in preparing for the initial implementation of Kerberos, new passwords must be distributed to a large number of users - not a trivial task.

Kerberos Performance and Network Topology

Kerberos overhead is small, and generally a small amount of additional overhead on signon is considered acceptable. Individual transactions can be authenticated quickly, because Kerberos uses a fast message digest hash for an integrity check and DES for privacy. After the initial Kerberos ticket granting ticket (TGT) is processed, all such operations take place in memory (of both the client and server principals) so there is little additional overhead involved. However, the specific requirements for each implementation should be carefully evaluated.

Special requirements for Kerberos performance and availability can be met by deploying secondary (slave) KDCs to network segments where they can be accessed directly, and where they can be available during periods when the main KDC is unavailable. Updates are made to the main KDC's data base, and the data base is then replicated periodically to the read-only, slave KDCs.

In order to ensure that an organization does not end up with a plethora of different authentication techniques, any new mechanism must be compatible with existing and planned efforts. Compatibility must exist among applications, internal organizational standards, standards in the organization's industry and, of course, international standards in the network and computer industry. Adopting authentication as a part of an overall strategy for security provides a solid foundation. However, the decision should be guided by emerging standards for such services.

The GSSAPI, the emerging standard for Internet security services, is a logical choice as an insulator between the suppliers of security services (such as Kerberos authentication) and security service consumers (such as application programs). Because it is an application program interface, the GSSAPI does not provide interoperability between different security mechanisms in and of itself. Interoperability requires a common mechanism between cooperating players using the mechanism. Widespread interoperability among disparate authentication mechanisms requires that they all communicate with one another. The GSSAPI can hide the complications of this interoperability from the programs that use it to access security services.

What the GSSAPI does provide is insulation from change - it is possible to replace the underlying authentication mechanisms easily and without changes to applications written to use the GSSAPI. A decision to adopt the GSSAPI, with Kerberos as its mechanism, allows weaker, more problematic authentication mechanisms in existing applications to be economically replaced. That is, the initial investment in recoding programs to use the GSSAPI would not be wasted because the underlying authentication mechanism can be changed at will without having to recode the entire application each time security technology advances.

Because current Kerberos implementations support only TCP/IP, shops that run DECnet or SNA may not be able to use Kerberos to authenticate in these environments. In the same vein, Kerberos support for older operating systems may be needed. These environments require special treatment to move Kerberos into them. In the worst case, such environments cannot be changed directly. For example, an older application that is not easily modified to add Kerberos can be frontended with a mechanism that isolates it and provides the desired Kerberos services.

Kerberizing Applications, Their Servers, and Clients

In order to add Kerberos-based authentication to an application, it must be broken down into a client part and a server part (if it is not already so divided). This is done in order to separate the parts of the application that participate in Kerberos authentication - the client part is authenticated to the server part (or possibly mutual authentication is performed). This division is necessary even if the application does not have a true client/server architecture. For those client-server applications, the division usually follows the application's existing client-server structure. The fundamental questions are:

• What client-server structure most accurately represents the components of the application?

• How is the client-server structure to be imposed on the application?

These are very broad questions with implications for an application's utility and security. Implementation of the answers also has a major effect on the cost of kerberizing an application.

Although it may ultimately be desirable to reimplement all applications as kerberized client-server, this is not always feasible. An example is a terminal-based application on a timesharing system. Such applications implicitly assume that the transmission path between the terminal and the host is secure. But this may not hold true when terminals and hosts are separated by a network. The client-server answer to this problem is typically to eliminate the terminal and replace it with a client (running a GUI-based front end), and replace the host application with a back-end server. Kerberizing both client and server parts of the application then make the application's security independent of the intervening network. Suffice it to say that each client/server architecture and each class of network device must be kerberized in a way that takes into consideration its idiosyncrasies.

COST FACTORS

The design, planning, and implementations for widespread authentication is expensive. Planning for authentication may raise basic security-related questions that will also need to be addressed.

Software Costs

The least expensive approach is to use the public domain version of Kerberos. However, this alternative leaves the user with no support and all the idiosyncrasies of this version. (It is possible to purchase support for the public domain version.) It should be noted that many organizations do not allow the widespread deployment of public domain software.

Commercial versions of Kerberos are available with service and support. The vendors can provide trained security professionals and can offer a variety of security services to assist organizations secure their systems.

Cost of Securing the KDC

An additional cost that is often overlooked is the cost of securing the KDC and the slave KDC servers required for redundancy. The KDC requires special treatment, and the network's topology may require more than one slave. Separate machines and physical housings for these KDCs are often required. Fortunately both primary and secondary KDCs can run on small machines. For example, MIT's Project Athena runs 3 DEC station model 2100s as KDCs (one primary and two secondary) for over 1300 workstations and more than 100 servers. These systems are small, easy to operate, and relatively inexpensive. (Each is configured with 12 MB of memory and 332 MB of disk space.)

Personnel Costs

Merely installing the KDCs is not sufficient; people must be properly trained in the administration and operation of these systems. In addition, a complete Kerberos implementation team must be organized and trained.

VULNERABILITIES

As does any authentication scheme, Kerberos has certain weaknesses. The problem for Kerberos implementors is to learn how to deal with these weaknesses.

The Kerberos design assumes that server principals are kept in moderately secure areas, that the key distribution center is in a secure area, and that the key distribution center runs only trusted software. Remember that Kerberos comes out of MIT's Project Athena. At MIT, care is taken to ensure that a minimum amount of trust is placed in client workstations. This includes provisions for trusted booting from trusted servers and no system or applications software on the workstations' local disks. In an ideal environment, local disks are wiped clean between boots to ensure that the after-effects of infected software do not remain to haunt users.

Still, a question remains: Has the workstation been compromised in a way that would allow an attacker to set aside these protections, install a covert channel, and collect a user's Kerberos password as it was typed on the workstation? Although such an attack is not simple, it is possible. Accordingly, workstations in such environments should be kept under the lock and key of controlled physical access and inspected periodically to ensure that they have not been tampered with.

Moving from a closely controlled environment to one in which workstations boot and run from local disks, several new concerns arise. Besides having to carefully control physical access to such workstations, the security of these machines must be managed very carefully to ensure that local software has not been compromised. This is usually done by means of regular technical inspections, backed up by more rigorous periodic assessments.

For instance, in a workstation environment that uses UNIX systems, each workstation might be inspected nightly by automated tools that report their findings to a central security management facility. The hope is that these inspections will detect any security problems so that they can be expediently resolved. Authentication schemes such as Kerberos cannot solve fundamental problems such as dishonest employees, people that pick bad passwords, or lack of adequate network or host security management.

Finally, because the Kerberos key distribution center contains all of the shared secrets as well as provides security services, it must be very carefully protected and managed. Although client workstations may be in relatively public areas and run software that is not entirely trusted, the KDC must be trustworthy. This means that the access to the KDC must be carefully controlled and monitored.

The KDC should support no applications, users, or protocols other than Kerberos. (That is, everything except Kerberos has been removed from this machine.) Ideally, this system will not support remote network access except by means of the Kerberos services it offers. If the KDC itself is to be remotely administered, the necessary operations must be accomplished over a special, secure channel that cannot be compromised. (Of course, kadmin - the Kerberos administrative tool - operates using Kerberos private messages.)

If the KDC is compromised, its shared secrets are at risk and it security services cannot be trusted. However, such an attack is far from easy. Kerberos uses the DES for encryption operations; the entire KDC data base is encrypted using the master key. To successfully attack the KDC, an intruder would need to access the KDC or otherwise obtain a copy of the KDC's data base. For example, a wiretapper could grab a copy of the KDC's data base as it is being propagated to a Kerberos slave KDC server. Because this transfer is done using Kerberos private messages under a randomly generated key that only the KDC and the slave KDC server share expressly for this transaction, such a wiretapper would first have to break that encryption to get at the message traffic that contained the data base being propagated. The intruder would then need to mount a successful cryptanalysis attack against the master key to obtain the data base.

Although contemporary experience with DES shows that successful attacks are possible, they are far too expensive and computationally intensive for anyone but such organizations as the National Security Agency (NSA) to attempt. Perfecting a mechanism to protect Kerberos from such a cryptanalytic attack is impractical for any but the most sophisticated and best funded government intelligence organizations.

The Kerberos protocol does not restrict the type of encryption that is used, and it may include any number of different encryption methods. In fact, design efforts are underway to include public key-based encryption in Kerberos. In any case, a public key-based Kerberos would be subject to the same type of attacks as the current, DES-based implementation.

FUTURE DEVELOPMENTS

As it matures, Kerberos is being incorporated into everything from the most mundane network application software to such specialized network hardware as access control devices for PCs and routers, terminal servers, and modems. It is also coming to be incorporated into some of the most advanced network applications. As operating system functions become distributed, effective authentication and security services have become even more critical. As a consequence of widespread attacks on TCP/IP's highly distributed Network File System, for example, authentication for it has become mandatory (even though it is not widely used). Kerberos has increasing appeal to the implementors and integrators of distributed systems because it is well tested and readily available.

The continuing search for distributed system security solutions has revealed many alternatives to Kerberos, including systems based on RSA Data Security's Public Key Cryptography Standards (PKCS) and those based on the Open System Foundation's (OSF) Distributed Management Environment (DME) and its associated Distributed Computing Environment (DCE). Implementations based on PKCS do not yet offer interoperability between their respective environments, let alone with other authentication schemes. A consortium of European companies (including Bull, ICL, and Seimans Nixdorf) is working on a standard called Secure European System for Applications in a Multivendor Environment (SESAME). SESAME is still in the standards development stage.

The obvious questions that arise when considering a network security system are:

• When will it be widely available?

• What will it cost to implement?

• Will it be interoperable?

• Will it stand the test of time?

While the authors cannot answer these questions for other network security systems, they believe that Kerberos has already answered these questions in the affirmative. There have been no known successful attacks against Kerberos, and production experience shows that the methods for protecting Kerberos described in this chapter are both feasible and effective. In short, Kerberos has become a de facto network standard; it is well understood, well tested, and implementations are available from a variety of sources on a wide range of platforms.

NEWS CONTENTS

• 190313 : Kerberos installation help ( Kerberos installation help, )
• 190313 : Hitmill.com - Kerberos Tutorial ( Hitmill.com - Kerberos Tutorial, )
• 190313 : Hitmill.com - Tutorial About Kerberos by Cheryl Gribble for Hitmill.com ( Hitmill.com - Tutorial About Kerberos, )
• 190313 : What is Kerberos? ( )
• 190313 : Kerberos Terminology ( )
• 190313 : Kerberos in a Nutshell (How it Works) ( )
• 190313 : Some Features and Problems of Kerberos 1 ( )
• 190313 : Kerberos Tutorials, Security Advisories, and Kerberos Help ( )
• 190313 : Mail List and Newsgroup ( )
• 190313 : Kerberos and Mac Computers ( )
• 190313 : Additional Kerberos Related Links ( )
• 190313 : What are some problems with firewalls? ( )

Old News

Kerberos installation help

There's a lot of talk on the Internet about security and the lack of it on UNIX systems. This is, in part, a by-product of the world of the net in which we choose to do business. We can do some things to help counteract the possibility of attack on our systems.

One way to help is with Kerberos. Kerberos is an authentication and encryption scheme that allows a user to become "known" by an authenticating server and then use that authentication to access systems and services on the net. The services can then transpire in an encrypted fashion to further secure transactions occurring over the net. The philosophy behind the creation of Kerberos, and a short summary of how it works is available, but here we assume that you know what Kerberos is, and wish to implement a Kerberos domain on your network. But, we also assume that you are not a hot-shot UNIX programmer, so we intend to lead you by the hand in a step-by-step fashion through the entire process. In other words, this is our version of "Kerberos for Dummies."

Several commercial integrators provide enterprise Kerberos solutions as well as technical support and maintenance. In particular, perhaps the easiest way to install Kerberos V5 is to use Kerbnet from Cygnus solutions. Kerbnet is free and has clients for Win32 machines, Macintoshes and Unix hosts, and has KDC software for Unix and NT as well as host servers for Unix platforms.

Check out the MIT Kerberos Web Site for the latest Kerberos release news. Another good source of information is the Kerberos FAQ compiled by Ken Hornstein.

Hitmill.com - Kerberos Tutorial

[12 Sep 2002] - krb5-1.2.6 Released The krb5-1.2.6 source release is now available.

Hitmill.com - Tutorial About Kerberos by Cheryl Gribble for Hitmill.com

Using Kerberos from Python

Red Hat manual/Kerberos

FreeBSD manual/Kerberos

Kerberos at Stanford

NCSA Kerberos Information

Recommended Links

Softpanorama Recommended

Top articles

Sites

Open Directory - Computers Security Authentication Kerberos

Hitmill.com - Kerberos Tutorial (contains large number of links)

What Is Kerberos Authentication Logon and Authentication

Kerberos and related topics

• Kerberos Reference Page

• Kerberos (http://gost.isi.edu/info/kerberos/)

• MIT Athena System Kerberos Documentation
• Ohio State Kerberos FAQ
• MITVMA & MITVMC Kerberos Client Page

• Kerberos- The Network Authentication Protocol

• What is Kerberos?
• Security Advisories -- exploitable buffer overruns exist in krb4 code
• Kerberos Releases
  • Kerberos V5 Release 1.2
  • Historical releases of MIT krb5
  • Getting Kerberos Sources and Binaries from MIT (US and Canada only)
  • Getting Kerberos Sources from the Crypto Publishing Project
  • The krb5-current Snapshots (for developers; US, Canada only)
• Documentation for the most recent release
• Papers about the Kerberos protocol
• The MIT Kerberos Team
• Commercial Support and Products
• Other Resources
  • Mailing lists
  • comp.protocols.kerberos newsgroup
  • USC/ISI Kerberos Page
  • Oak Ridge National Laboratory's "How to Kerberize your Site"

Reference

rfc1510The Kerberos Network Authentication Service (V5)

This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere [1,2], is presently in production use at MIT's Project Athena, and at other Internet sites.

RFC 1964

FAQs

Frequently Asked Questions about Kerberos

Kerberos Users' Frequently Asked Questions 1.14

Papers

Kerberos An Authentication Service for Computer Networks by B. Clifford Neuman and Theodore Ts'o

When using authentication based on cryptography, an attacker listening to the network gains no information that would enable it to falsely claim another's identity. Kerberos is the most commonly used example of this type of authentication technology.

Modern computer systems provide service to multiple users and require the ability to accurately identify the user making a request. In traditional systems, the user's identity is verified by checking a password typed during login; the system records the identity and uses it to determine what operations may be performed. The process of verifying the user's identity is called authentication. Password based authentication is not suitable for use on computer networks. Passwords sent across the network can be intercepted and subsequently used by eavesdroppers to impersonate the user. While this vulnerability has been long known, it was recently demonstrated on a major scale with the discovery of planted password collecting programs at critical points on the Internet [4].

rs-94-412 The Evolution of the Kerberos authentication system

Kerberos-DCE, the Secure Shell, and Practical Internet Security

Tutorials

The Novice's Guide to Kerberos 5

Developer's Introduction to Kerberos 5

RFC 1510 - Kerberos Network Authentication System

Kerberos Papers and Documentation

Kerberos installation help How to Kerberize your site

There's a lot of talk on the Internet about security and the lack of it on UNIX systems. This is, in part, a by-product of the world of the net in which we choose to do business. We can do some things to help counteract the possibility of attack on our systems.

One way to help is with Kerberos. Kerberos is an authentication and encryption scheme that allows a user to become "known" by an authenticating server and then use that authentication to access systems and services on the net. The services can then transpire in an encrypted fashion to further secure transactions occurring over the net. The philosophy behind the creation of Kerberos, and a short summary of how it works is available, but here we assume that you know what Kerberos is, and wish to implement a Kerberos domain on your network. But, we also assume that you are not a hot-shot UNIX programmer, so we intend to lead you by the hand in a step-by-step fashion through the entire process. In other words, this is our version of "Kerberos for Dummies."

Several commercial integrators provide enterprise Kerberos solutions as well as technical support and maintenance. In particular, perhaps the easiest way to install Kerberos V5 is to use Kerbnet from Cygnus solutions. Kerbnet is free and has clients for Win32 machines, Macintoshes and Unix hosts, and has KDC software for Unix and NT as well as host servers for Unix platforms.

Check out the MIT Kerberos Web Site for the latest Kerberos release news. Another good source of information is the Kerberos FAQ compiled by Ken Hornstein.

Microsoft Implementation

Windows 2000 Security Kerberos Authentication -- very good compilation of resources

Windows 2000 Kerberos Authentication

Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability

Security Briefs Understanding Kerberos Credential Delegation in Windows 2000 Using the TktView Utility -- MSDN Magazine, May 2000

MIT Implementation

• Kerberos- The Network Authentication Protocol

• What is Kerberos?
• Security Advisories -- exploitable buffer overruns exist in krb4 code
• Kerberos Releases
  • Kerberos V5 Release 1.2
  • Historical releases of MIT krb5
  • Getting Kerberos Sources and Binaries from MIT (US and Canada only)
  • Getting Kerberos Sources from the Crypto Publishing Project
  • The krb5-current Snapshots (for developers; US, Canada only)
• Documentation for the most recent release
• Papers about the Kerberos protocol
• The MIT Kerberos Team
• Commercial Support and Products
• Other Resources
  • Mailing lists
  • comp.protocols.kerberos newsgroup
  • USC/ISI Kerberos Page
  • Oak Ridge National Laboratory's "How to Kerberize your Site"

Solaris

Solaris: Kerberos can be used at least since Solaris 2.6. See Solaris Advanced System Administrator's Guide, Second EditionUsing Authentication Services. Solaris 10 provides several new features & improvements over previous releases in the Kerberos area. Enabling Kerberos authentication for clients is an installation option in Solaris 10. Here is what Sun tells us about Kerberos in Solaris 10:

Sun Enterprise Authentication Mechanism software (Sun's implementation of Kerberos), LDAP, and interoperability enhancements allow enterprise-wide, secure, standards-based single sign-on to servers and applications. These enhancements reduce costs by centralizing administration of system access across multiple operating systems while increasing security. New to the Solaris 10 OS are Kerberos-enabled remote applications such as rsh, rcp, telnet, and others that were previously only available via download. An example is Kerberos-enabled NFS file sharing, which provides strong authentication, data privacy, and standards-based file sharing.

• [PDF] SEAM: Sun Enterprise Authentication Mechanism (Kerberos V5 for ...(Kerberos V5 for Solaris and Solaris NFS). Presentation by Mike Eisler. Sun Microsystems. [email protected].

• [PDF] Kerberos Network Security in the Solaris™ Operating Environment
• 6. Post-installation and Customization (Solaris x86 FAQ)
• Kerberos 5 - fully kerberized host - install notes SUN Solaris 2.x ...
• Sybase Help - Eclipse Platform Sun Solaris Kerberos is based on MIT's Kerberos with the following differences:

• The GSS library is /usr/lib/libgss.so instead of libgssapi_krb5.so.
• All other information in the section on Configuring MIT Kerberos applies to the version of Kerberos provided with Sun Solaris.

Links

• Kerberos installation help
• SUMMARY: Kerberos V setup on Solaris 9
• Solaris SSH - Kerberos 5 Hints
• How to Quickly Install the Solaris 10 1-06 OS
• Solaris Advanced System Administrator's Guide, Second EditionUsing Authentication Services
• Configuring Sun Solaris Kerberos

Red Hat

• NIS_Kerberos
• http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/s1-server-nis.html
• http://www.ofb.net/~jheiss/krbldap/howto.html

AIX

AIX. IBM have many years of experience with the technology and strong integration of it into AIX.

pSeries and AIX Information Center

Kerberos is a network authentication service that provides a means of verifying the identities of principals on physically insecure networks. Kerberos provides mutual authentication, data integrity and privacy under the realistic assumption that network traffic is vulnerable to capture, examination, and substitution.

Kerberos tickets are credentials that verify your identity. There are two types of tickets: a ticket-granting ticket and a service ticket. The ticket-granting ticket is for your initial identity request. When logging into a host system, you need something that verifies your identity, such as a password or a token. After you have the ticket-granting ticket, you can then use your ticket-granting ticket to request service tickets for specific services. This two-ticket method is the called the trusted third-party of Kerberos. Your ticket-granting ticket authenticates you to the Kerberos server, and your service ticket is your secure introduction to the service.

The trusted third-party or intermediary in Kerberos is called the Key Distribution Center (KDC). The KDC issues all the Kerberos tickets to the clients.

The Kerberos database keeps a record of every principal; the record contains the name, private key, expiration date of the principal, and some administrative information about each principal. The master KDC contains the master copy of the database and passes it to slave KDCs.

This section contains the following Kerberos information:

• Secure remote commands overview
  The following provides details about secure remote commands.
• Authenticating to AIX using Kerberos
  AIX^® provides both KRB5 and KRB5A Kerberos authentication load modules. Even though both modules do Kerberos authentication, the KRB5 load module performs Kerberos principal management, whereas the KRB5A load module does not.
• KRB5A authentication load module questions and troubleshooting information
  This provides answers to KRB5A authentication load module questions and troubleshooting information.
• Kerberos module
  The Kerberos module is a kernel extension used by the NFS client and server code. It allows the NFS client and server code to process Kerberos message integrity and privacy functions without making calls to the gss daemon.

IBM Cluster information center

Configuring the AIX Kerberos Version 5 clients with a Windows 2000 ...

[PDF] Configuring AIX 5L for Kerberos Based Authentication Using Windows ...

This paper describes the use of Kerberos as an alternative authentication mechanism to AIX using Windows 2000/2003 Server Kerberos Service. Authentication applications on AIX do not require any change to alternatively perform Kerberos authentication as it is woven into the fabric of the AIX security subsystem. By utilizing the loadable identification and authentication framework of AIX, the system directs authentication requests to use Kerberos instead of standard UNIX authentication.

HP-UX

• Authentication module
• Account management module
• Session management module
• Password management module

PAM Kerberos is one of the authentication modules that PAM can invoke based on the authentication method defined in the /etc/pam.conf PAM configuration file. If the shared, dynamically loadable PAM Kerberos library (for example, /usr/lib/security/libpam_krb5.1) is defined for the PAM authentication module, PAM Kerberos is invoked for user authentication.

Following are the PAM Kerberos features on HP-UX:

• PAM Kerberos validation tool � This tool validates the PAM-Kerberos-related entries in the /etc/pam.conf, /etc/pam_user.conf, /etc/krb5.conf, and the /etc/krb5.keytab configuration files. This tool also checks for the presence of the authentication server (Key Distribution Center(KDC)).
• Session Management � The credentials created by PAM Kerberos for the user while logging in are not deleted from the system when the user closes the session. This can result in unnesessary usage of disk space. The session management uses the pam_sm_close_session() function to delete the credentials that are created by the pam_sm_setcred() function.
• Configurable Password prompt � The password for PAM Kerberos can be configured by specifying the krb_prompt flag to the corresponding entry in the /etc/pam.conf PAM configuration file.

Following are the Kerberos-support features on the HP-UX 11i v1 operating system and the Kerberos-client features on the HP-UX 11.0 operating system:

• Appdefault support : The Kerberos client configuration file /etc/krb5.conf supports the [appdefaults] section. In this section, users can use the default flags to be used while obtaining credentials in an application.
• ADS Multidomain Support: If the user's account exists in the Windows 2000 multidomain, the Kerberos client resolves the Windows 2000 domain to which the user belongs. This makes the authentication consistent with nss_ldap, a name service switch module provided by LDAP-UX.

PAM Kerberos v 1.12 on the HP-UX 11.0 operating system has the following features and security fixes:

• If the user profile is not present in the Kerberos database, pam_sm_acct_mgmt() returns PAM_USER_UNKNOWN.
• A user cannot change another user's password even if the user is aware of the other user's password.
• KRB5-Client includes a fix that enables it to properly decode malformed tickets.
• KRB5-Client includes a fix that enables it to parse the auth_to_local_names sub section and auth_to_local tag of Kerberos configuration file correctly.
• KRB5-Client was unable to receive packets properly under certain conditions. This issue has been fixed in PAM Kerberos v 1.12.

PAM Kerberos v 1.24 contains the following changes:

• On the HP-UX 11i v1 operating system, PAM Kerberos v 1.24 delivers the 64-bit /usr/lib/security/pa20_64/libpam_krb5.1 library to provide Kerberos authentication to the 64-bit PAM applications in the HP-UX 11i v1 operating system.
• On the HP-UX 11i v1 and v2 operating systems, PAM Kerberos v 1.24 contains some defect fixes and enhancements. For information on these defect fixes and enhancements, see PAM Kerberos v 1.24 Release Notes at http://www.docs.hp.com.

Table 1 lists and describes the PAM Kerberos versions available on different HP-UX operating systems.

Table 1: PAM Kerberos Versions on HP-UX

SSH Kerberos Authentication

[PDF] hp-ux kerberos server

Using Kerberos with the HP CIFS Client

Government and Universities

• http://www.nrl.navy.mil/code5595/kerberos/INSTALL.krb5.solaris
• http://computing.fnal.gov/cd/unixlinux/unixatfermilab/html/sec_passwords.html
• http://www-mipl.jpl.nasa.gov/mdms/UI/kerTutorial.html
• http://docs.hp.com/en/305/uxint.html

Web authentication

NCSA HTTPd 1.5 Howto Kerberos Authentication

Security

CERT Advisory CA-2000-11 MIT Kerberos Vulnerable to Denial-of-Service Attacks

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created: May 16, 1997; Last modified: March 12, 2019