[1] {Igor Sachs}\ \bigskip Kerberos Security in a Client-Server \ System Management Application

Igor Sachs


Kerberos Security in a Client-Server
System Management Application

API Application Programming Interface
AS Authentication Server
CIM Common Information Model
CIMOM Common Information Model Object Manager
CORBA Common Object Request Broker Architecture
DES Data Encryption Standard
DMTF Distributed Management Task Force
DTD Document Type Definition
EIM Enterprise Identity Mapping
GSS Generic Security Service
HTTP Hyper Text Transport Protocol
IBM International Business Machines
IDL Interface Definition Language
IP Internet Protocol
ISO International Organization for Standardization
KDC Key Distribution Center
LAN Local Area Network
MAC Message Authentication Code
MIC Message Integrity Check
OSI Open Systems Interconnection
PKI Public Key Infrastructure
RFC Request for Comments
RMI Remote Method Invocation
RPC Remote Procedure Call
SPNEGO Simple and Protected GSS-API Negotiation mechanism
SSL Secure Socket Layer
SSO Single Sign On
SSPI Security Support Provider Interface
TCP Transmission Control Protocol
TGS Ticket Granting Server
TGT Ticket Granting Ticket
UML Unified Modeling Language
WBEM Web Based Enterprise Management
XML Extensible Markup Language
1.15
I would like to thank my supervisor Marek Szermutzky and Robert Kieninger for their constant support during my Internship at IBM Deutschland Entwicklung GmbH. They professionally introduced me into the project and provided me patiently help whenever needed.
I appreciated the many suggestions and helpful hints Prof. Hotop gave me during the work of this report.
Prof. Müller-Wichards I am deeply grateful for his great interest in my work and for the excellent guidance during every phase of this Bachelor Report.
Finally I would like to thank my fellow student Alexej Mühlberg, who gave me a place to stay at the very end of my studies.
Heterogeneity of distributed computing systems has taken root in most companies at the end of the last century. The effort for administration has increased dramatically due to the plurality of different solutions for System Management. The Web Based Enterprise Management initiative establishes an infrastructure for such kind of System Management Applications with a common and standardized interface.
From the security point of view there is a strong need to protect these sensitive management data from unauthorized access. The Authentication Service Kerberos provides a system for authentication within distributed and open networks where the principle of a trusted third party is used.
This Bachelor Report gives an overview how to describe management information using the Common Information Model and how it is embedded into the entire framework of Web Based Enterprise Management. The Authentication Protocol Kerberos is described, which is used to enable a sophisticated and scalable authentication mechanism for this architecture and also provides a Single-Sign-On environment.
The integration of Kerberos into this architecture using the Generic Security Service Application Programming Interface is analyzed and the problems between the Linux and the Windows implementation are discussed.
1.16

Chapter 1
Introduction

1.1  Motivation

The heterogeneity of computing systems within distributed system environments in the end of the 20. century has led to an excess of administration. In former days, System Management was introduced in order to facilitate the administration of these computing systems.
The evolution of distributed Systems Management began in the 1960's, when the systems were centralized and typically housed in one large facility [].
Nowadays data centers are not only concerned with the management of mainframe computers but with the management of thousands of mini data centers and personal computers spread over large geographic areas. Due to the heterogeneity of these systems, one has to struggle with a variety of different proprietary System Management Applications. These applications include an interface to carry out the tasks of System Management.
In November 2004 the Gartner Group1 forecasted that worldwide enterprise systems management software license revenue will grow from $5.6 billion in 2003 to $7.4 billion in 2008.
In practice, these applications are tied to a particular system. Due to the heterogeneous system environments in most companies, there exists a large number of these System Management Applications, each one being responsible for a specific task of management. Furthermore existing management solutions could not be used to support network management []. Each network management application was developed to solve one particular problem on one specific platform.
To handle this situation, consistent and centralized management of distributed systems of different vendors and architectures has to be established. Nowadays there exist entire suits of distributed systems management products, like Tivoli's TME, which is based on the CORBA-framework, or HP OpenView for instance. These applications links together information from various tools and components and create management system platforms. Despite the fact that this integration provides some level of distributed system management, there are still several data models for management which required the vendors to guess the meaning and their relationship of managed components.
Thus there is a need to build an infrastructure for System Management Applications, with a common data model and standardized interfaces between managed objects and management applications, which is able to manage any kind of hardware or software. The Web Based Enterprise Management (WBEM) initiative was introduced by a number of companies in 1996 to standardize the infrastructure of such kind of System Management Applications. To accomplish this the following aspects have to be specified:
Web Based Enterprise Management Applications, as the name implies, send management data via the HTTP-protocol over the network. Management data in general are meta data which are used to describe management objects. These kind of data hold system-specific properties of the managed systems. This could be for instance all processes running on a server or even information about the users of this system.
The security concept of this framework is very crucial. Management data has to be protected from unauthorized access, still retaining the possibility for easy and handy access to these data by the legitimate user. Authentication is necessary to establish the legitimacy of users before allowing access to the requested information. B. Clifford Neumann and Jennifer G. Steiner stated the problem as:
Äuthentication of Unknown Entities
on an Insecure Network of Untrusted Workstations"
To achieve this, the identity of the person who requests management data has to be proven. This can be carried out with an authentication system. The Authentication Service Kerberos provides a mechanism where a third party entity is used, which is trusted by both participants of the authentication process. The task of the so called Key Distribution Center (KDC) is to issue tickets as an optional replacement for a user name and password in order to authenticate users.
When a workstation wants to prove the identity of its user to a server, it contacts Kerberos and asks for a ticket for that specific server. The ticket returned to the workstation is encrypted twice: first with the key of the server and then with the users's key. The user’s password is used to decrypt the ticket which can then be passed to the server to prove the user’s identity [].
Furthermore Kerberos provides the possibility of mutual authentication, where both participants have to prove their identity to each other.
Another benefit of Kerberos compared to other authentication techniques is the ability of Single-Sign-On (SSO), where the users have to type in their passwords only once. This can be accomplished with a hierarchical organization of the trusted third party entities within the given network of a company.
Due to the multifaceted possible fields of application, Kerberos should be the preferred authentication service for this infrastructure for System Management Applications.

1.2  Scenario

Due to the distributed system infrastructure in large companies today, there exist many hosts of different platforms. System Management is indispensable for administrating these computing systems. Despite the fact that there exist already entire management suits, with which it is possible to administrate entire parts of the computer network, the customer (the company) still has to struggle with a large number of these applications.
Web Based Enterprise Management (WBEM) provides the interoperability between different network- and system-management applications. The computer networks of large companies today are divided into several domains, which provide logically separate subnetworks. If interoperability between the different System Management Architectures is established, one could imagine that the domain of responsibility of administrators increases due to the easier management of different systems.
Authentication to this infrastructure has to be secure and reliable. In order to achieve this, an authentication system is needed which should support strong encryption. Compromising this authentication system leads to an unauthorized access to management data of the company's computing environment. From these management data the intruder is able to gain more information about the entire system environment and can possibly do more harm. From this point of view, the importance of protecting system management data from unauthorized access becomes essential.


Authentication should not only be secure but also offer some kind of easy usage. Reentering passwords several times a day for many different systems is annoying and time consuming. The Authentication Protocol Kerberos can be enabled to authenticate across different network-domains (cross-realm authentication) and thus offers a real Single-Sign-On environment if Kerberos is implemented in the corresponding applications.
Compared to other authentication methods, like the Secure Socket Layer (SSL) [] for instance, there are some advantages which will be discussed in this report.

1.3  Objectives

The aim is a concept of an efficient and secure authentication system for such kind of System Management infrastructure. The authentication protocol Kerberos provides an efficient security architecture, which possesses the following properties:

1.4  Structure of the Report

This Bachelor Report gives an overview of the infrastructure for System Management Applications using Web Based Enterprise Management, focusing on the key concepts for authentication. It describes how the Kerberos Authentication Service can be implemented into this framework.


In the second chapter the infrastructure for a System Management Application is introduced, depicting the functionality of the object oriented Common Information Model (CIM) which is used to describe management objects and is the basis of characterizing any piece of Hard- or Software. Furthermore an overview of the Web Based Enterprise Management (WBEM) is given, which standardizes the Information Model as well as its encoding and transport over the network, focusing on the key concepts for authentication.


In the third chapter the authentication protocol Kerberos is described in detail with its management of the credentials and the ticket system, which is used to authenticate users. The Security of this Authentication Protocol is analyzed and possible attacks against this authentication system are discussed.


The fourth chapter deals with the implementation of Kerberos within the architecture of a System Management Application using the Generic Security Service API (GSS-API). Due to the session-oriented nature of the protocol, the client-side as well as the server-side of the Kerberos processing is depicted. With respect to the different APIs, the Kerberos interoperability between Windows and Unix is also investigated.
1.16

Chapter 2
Infrastructure for System Management Applications

This chapter gives an overview of the infrastructure for a System Management Application. After analyzing the need of System Management, the Common Information Model (CIM) will be introduced, which is essential for retrieving management information in the enterprise management environment of computing systems. The Web Based Enterprise Management (WBEM) will be described, focusing on the key concepts for authentication.

2.1  Introduction

The development of multiuser computers and computer networks in the 1960s yielded a heterogenous and distributed system environment. According to Kindberg, a distributed system is a system ïn which components located at networked computers communicate and coordinate by passing messages" []. The challenges resulting from the buildup of distributed systems are the heterogeneity of its components, its openness, security and scalability.
The most important distributed systems today are the Internet, Local Area Networks (LANs) and any kind of mobile and ubiquitous computing networks.
One important motivation for building up distributed systems was the sharing of resources. For the management of these resources, the term "System Management" has been adopted. These resources can be divided into two separate groups: system resources and system services [].
Examples for system resources are:
Within Client-Server environments the services offered by other servers are often more important than the local resources. A so-called Multi-Tiered architecture can be found, where different system layers exist within an entire architecture. For instance a server could be the client of another server.
The most important system services are:
Due to the heterogeneity of distributed systems in large companies today, one can find many servers with different architectures, from several vendors, running different operating systems. There is a need to administrate these computing systems for the following reasons:
These tasks belong to system management and are carried out by the administrators of the computer network. A system management application is a collection of tools wherewith these tasks can be carried out.
System management in general can be applied within data communication networks or within telecommunication networks []. The entities in data communication networks are data terminal equipment (e.g. hosts, servers, workstations, terminals) whereas the entities in telecommunication networks are telephones, private branch exchanges, fax machines or similar devices.

2.2  The OSI Management Framework

In order to establish a manufacturer spanning System Management, standards have to be created and used as well. This has been carried out through the International Standard Organization (ISO) with a norm-packet.
The ISO deals with all norms in the electrical and electronic field. The fast growing area of information processing belongs also to this field.
Within an extensive bunch of norms there exist important specifications for networks which are defined by ISO: The OSI Reference model. OSI is an acronym for Open Systems Interconnection and defines the logical and physical communication within open systems.
The ISO federation is also responsible for classification of management data within this OSI environment []. This has been defined by the Management Framework.

2.2.1  The ISO/OSI-Model

Despite of the variety of hard- and software solutions for networks, it has become quite easy to classify these and to relate them to each other. This was made possible by the ISO when defining the often cited Open Systems Interconnection Model [,P. 71]. Figure shows the seven layers of the ISO/OSI Model.
The Reference Model is a common communication concept. It defines the transmission of data as an entire process, which is carried out through all seven layers. Every layer precisely defines tasks and communicates only with the layer above or below. The actual communication between Client and Server is done by the physical layer.
Figure
Figure 2.1: The 7 layers of the ISO/OSI Reference Model

2.2.2  Regions of Management

A great effort has been done with respect to the classification of management data. ISO/IEC 7498-4 (Management Framework) defines five areas of system management:
Accounting Management
Accounting management allows charges to be established for the use of resources in an OSI environment and for costs to be identified for the use of those resources. Accounting management includes functions to:
Configuration Management
Configuration management identifies, controls, collects data from and provides data to open systems for the purpose of preparing for, initializing, starting and terminating interconnection services.
Configuration management includes functions to:
Fault Management
Fault management contains fault detection, isolation and the correction of abnormal operation of the OSI environment. Faults cause open systems to fail to meet their operational objectives. In general they can be persistent or transient. Faults manifest themselves as particular events (e.g. errors) in the operation of an open system. Error detection provides for the recognition of errors. Fault management includes functions to:
Performance Management
Performance management enables evaluation of the behavior of resources in the OSI environment as well as the capability of communication activities. Performance management includes functions to:
Security Management
The purpose of security management is to support the application of security policies by means of these functions:

2.3  The Common Information Model

Data is the key to management. Without it, any management architecture is of no use. Administrators need management data to effectively carry out management tasks.
In this section, the Common Information Model (CIM) will be briefly described, focusing on the key concepts for its integration into the infrastructure of Web Based Enterprise Management.
CIM is indispensable for describing management information in a common manner for the architecture of different System Management Applications.
After describing the Data Model with its specification and schema, the transport encoding and the transport of the data itself will be depicted.

2.3.1  Introduction to the Data Model

The Common Information Model (CIM) describes management information and offers a framework for managing any piece of hardware or software within a distributed system environment.
It is an object oriented model which allows mapping of so called managed resources onto classes. CIM has evolved from the Simple Network Management Protocol (SNMP) which does not support the object oriented paradigm. The main advantage of CIM is that it is not bound to a particular implementation and thus allows different systems and applications to exchange and interpret management information.
The Distributed Management Task Force (DMTF) 3 is an amalgamation of the leading companies in today's computing industry like Intel, Sun Microsystems, Hewlett Packard and IBM to mention just some of these, which defines the specifications and schemas of CIM.
Due to the fact that CIM is hierarchical and object oriented, the complex relationships that exist in a real world can be described in a schema. Therefore it is easy to track the complex interdependencies and associations between different managed objects.
The CIM schema, being a collection of class definitions, is able to describe a large variety of managed elements, like operating systems, peripherals and applications, as well as network components (switches, routers, network-connections) and even users of a computer system. The schema describes the attributes of managed objects, like for instance the type of printer or storage medium, the capacity of RAM and CPU, or even the status of operating systems [].

2.3.2  Specification and Schema

The CIM specification defines a formal language for describing data. It specifies the language, naming, metaschema and mapping techniques from other management models such as the IETF's Simple Network Management Protocol (SNMP) Management Information Base (MIB) models, and DMTF Management Information Format (MIF) files [].
The CIM Schema contains a description of the resources to be managed. The formal definition of the model is the so called Metaschema. It describes the model with its semantics and usage within the environment. The elements of this metaschema are classes with their methods and properties, describing how the managed resources are mapped onto CIM.
Figure shows the overall structure of the CIM Metaschema using the Unified Modelling Language (UML)4.
Figure
Figure 2.2: Structure of the CIM Metaschema according to []
Meta Classes characterize sets of objects with common properties. Between classes only single inheritance is possible. It is possible that inherited properties or methods can be overridden.
Meta Methods define the operations that can be invoked on objects of a class.
Meta Qualifiers are used to describe additional characteristics of classes or attributes and methods of the classes. Examples are the possible access to properties (READ,WRITE), the tagging of an attribute as a key for instances or the marking of a class as not instantiateable (abstract).
Meta Associations are classes that represent (when being instantiated) relationships between two or more objects.
Meta References are special properties. They depict links to classes.
Meta Indications are a kind of event classes. Instantiation of these classes are concrete event-indications of the corresponding type and are used within Fault and Performance Management.
Meta Schema are groups of elements, which are composed for administrative purposes.


The formal definition of the CIM Schema is phrased in a so called Managed Object File (MOF), which can be either an ASCII file for use in an application or encoded with the Extensible Markup Language (XML) to enable a transport via HTTP.
These Managed Object Files describe the management information in a language based on the Interface Definition Language (IDL) using the Augmented BNF (Backus-Naur Form) notation [].
Because of the fact that the Meta-Model of CIM was specified using UML, there exists the possibility to use UML-based tools to model management objects which are able to create also IDL-interfaces [,P.238]. The Interface Definition Language is a syntax for describing the interfaces of software components, which are written in different languages. The middleware architecture CORBA (Common Object Request Broker Architecture), for instance, specifies this definition language for a central component, which enables objects to offer their functionality to other objects []. This component is the so-called Object Request Broker (ORB) and is responsible for the communication between the objects in a distributed environment. Several System Management Applications, such as Tivoli's TME, are based on CORBA as infrastructure. Thus CIM has the chance to deliver the Management Information Model for such kind of applications. This could be the basis for the integration of the new architecture into the still important old architectures.


In contrast to the CIM Metaschema, which specifies how resources are mapped onto the data model, the CIM schema defines what resources are mapped.
The CIM schema is hierarchically structured into three different layers:
The Core schema is an information model that holds items which are applicable to all areas of management and defines classes of elements in a managed environment. It is the Top-layer which is valid for all managed items and is the basis for the inheritance hierarchy.
The Common schema is an information model that holds items common to specific management areas. Despite of this, it is independent of a particular technology or implementation. The Common schema holds a number of abstract and concrete classes that define the basic characteristics of systems, networks, applications, databases and devices. These are the base classes for an extension into the area of technology-specific schemas, which are described in the Extension schemas.
The Extension schema is a technology-specific extension of the Common schema which are related to specific environments, like different operating systems.
Figure shows typical items of the three layers.
Figure
Figure 2.3: The three layers of the CIM Schema

2.4  Web Based Enterprise Management

The aim of the Distributed Management Task Force (DMTF) is to lead the development of management standards for distributed desktop, network, enterprise and internet environments. The main goal of the DMTF is to "promote interoperability among management solution providers" [].
This goal can be achieved using the Web Based Enterprise Management (WBEM), which was introduced by a number of companies in 1996 in order to make use of Internet technologies for the management of servers, desktop computers and all other Internet-related devices.
Web Based Enterprise Management is a platform and resource independent standard that defines a common model (CIM) as well as a protocol for monitoring and controlling resources from different sources.
This section describes in which way the interoperability, called WBEM, is achieved. WBEM is an acronym for Web Based Enterprise Management. It defines set of management technologies developed to unify the management of enterprise computing environments.
WBEM consists of three main components:
The Common Information Model (CIM), which was described in the last section, provides a common format and language for collecting and describing management data.
The XMLCIM encoding specification defines XML elements, which can be used to describe CIM classes and their instances for transport.
The CIM operations over HTTP specification defines the mapping of CIM operations onto a set of HTTP operations. In other words it defines how a management application acquires the management data and how an agent has to respond to the operations. The three main components building the Web Based Enterprise Management are depicted in Figure .
Figure
Figure 2.4: The components of WBEM
Figure shows the overall structure of a WBEM architecture.
Figure
Figure 2.5: The architecture of WBEM
A centralized Software module has to process all WBEM requests. It functions as a kind of dispatcher, which knows what special class is suitable for a specific managed component. This module is named CIM Object Manager (CIMOM) or, according to CORBA, CIM Object Broker. It brokers CIM objects between an number of sources and destinations. The CIMOM is the implementation of the three main components of WBEM.
Since the CIMOM has to know which associations, classes and qualifiers exist, it has to search in a repository, where all static CIM information is stored. If the CIMOM would directly access the system resources, it would not be very flexible: new resources cannot be added dynamically. For this reason a modular concept is preferred, where a provider is used for the instantiation of one class.
There are several available implementations of the CIMOM, programmed in different languages and supporting a variety of platforms. The two most widely used implementations are the open source projects OpenPegasus5 and SNIA CIMOM6. The first one is programmed in C++, while the latter one uses Java.
The CIMOM has to provide the following functionality:
Figure illustrates an infrastructure of several WBEM components.
Figure
Figure 2.6: Infrastructure of WBEM components

2.4.1  Transport Encoding

The Extensible Markup Language (XML) is a subset of the Standard Generalized Markup Language (SGML) and offers powerful and extensible data modelling possibilities. The advantage of the general-purpose markup language XML is that data can be described in a formal way, allowing programs to modify and validate these documents using its Document Type Definition (DTD), still having a human readable form of this document.
There exists two different models for mapping CIM into XML:
Despite the fact that there are obvious benefits to employing a schema mapping (more validation power, and a slightly more intuitive representation of CIM in XML), the Metaschema mapping was adopted for the following reasons:

2.4.2  CIM Operations over HTTP

To allow WBEM to operate in an open and standardized manner, the DMTF has defined a mapping of CIM operations onto the Hyper Text Transfer Protocol (HTTP).
HTTP is an application-level protocol for distributed information systems. It runs on top of TCP/IP and can be used for many tasks through the extension of its request methods, error codes and headers. By defining a number of HTTP extension headers for CIM, Client and Server applications can be aware that CIM information is being sent.
Potentially there is a large number of ways to represent CIM operations within XML and those operations encapsulated within HTTP messages. For the interest of interoperability among different implementations of CIM, there is an obvious requirement for standardization of both XML representation and HTTP encapsulation. The DMTF uses XML representation to define the HTTP encapsulation.
The following criteria have been applied to the representation of CIM operations over HTTP:
The following criteria have been applied to the HTTP encapsulation of CIM operations:

2.5  Authentication at a Web Based Enterprise Management Application

In this section the authentication at a CIMOM is briefly described. For the CIMOM the OpenPegasus implementation is used.
To build a WBEM enabled system, a client-server architecture was designed as illustrated in Figure . The core component of the WBEM server is the CIMOM. The OpenPegasus implementation includes an interface for communication with a WBEM client (HTTP/xml, RMI) and a number of WBEM providers which build the interface for the managed resources. The communication with the client is carried out with CIMXML over HTTP. On this interface, the authentication system has to be established.
Figure
Figure 2.7: WBEM Client-Server Architecture
The authentication mechanism has to be implemented into the CIMOM as well as into the CIM Client.

2.5.1  Symmetrical and Asymmetrical Cryptographic Systems

Nowadays cryptography is an integral part of authentication. Therefore the two different paradigms of cryptographic systems, which are used today, are briefly described. The example of the famous Bob and Alice, who want to communicate with each other, is used.
If Bob wants to send a message to Alice, where the message is encrypted with a cryptographic system, Alice needs a key e to encrypt and Bob needs the corresponding key d to decrypt the message.
If within a cryptographic system the key e and the key d are always equal, or if at least the key d can be easily deduced from the key e, then this is referred to a symmetric encryption method []. The problem with this method is that Alice and Bob have to exchange their keys e via a secure network connection and have to keep their keys secret because the key d for decryption can be easily deduced from the key e. Generally speaking, the keys for encryption and decryption are equal. An example for a symmetric encryption algorithm is the Data Encryption Standard (DES), which is used by Kerberos.


Within asymmetric encryption methods the keys d and e are unequal and it is very difficult to deduce the key d from the key e with an appropriate effort. If Bob wants to receive encrypted messages, he just publishes his encryption key e and anybody who wants to communicate with Bob encrypts his message with the public key e of Bob. The message can then be decrypted with the private key d of Bob, who keeps this key secret. This is the reason why this method is also referred to as Public-Key-method. A system which uses this approach is called a Public-Key Infrastructure (PKI).
The disadvantage of symmetrical encryption methods is the large number of key exchanges between n participants, in particular:
n*(n−1)
2
But asymmetrical encryption methods have also one drawback: its low performance compared to symmetrical methods, because the computations are very complex. The performance difference has a factor of round about 1000 []. So in practice often both cryptographic systems are used within hybrid systems, which combine both approaches. An example is the Secure Socket Layer (SSL).

2.5.2  Current Authentication Design

At the CIMOM OpenPegasus there are currently two different authentication techniques implemented:
Basic Authentication
Basic authentication, as the name implies, is the simplest authentication mechanism. It is included in the HTTP/1.0 specification and applied within a secure network connection, where client and server use a trusted carrier. It was used for a long time as the common authentication mechanism. Basic authentication as well as Digest authentication are defined in the RFC 2617.
Basic authentication is regarded as insecure, because the credentials (username and password) are sent in plain over the physical network. In fact they are base64 encoded, but this is not an encryption-algorithm as furthermore a method of transforming a string to eliminate ambiguity when decoding the response. Nevertheless Basic Authentication is still used either for local authentication or in conjunction with external secure systems like SSL.
Secure Socket Layer (SSL)
SSL is used to establish secure HTTP connections. The main task of SSL is the authentication of the partners who want to communicate using an asymmetrical encryption technique and the encryption of confidential message exchange, which is accomplished with a symmetric encryption method [,P.589]. This hybrid solution in practice has some limitations. C. Eckert found out that this solution cannot easily cooperate with firewalls, which use application filters. Furthermore a reliable authentication cannot be guaranteed with SSL: Users have to trust that the certificates issued are authentic and trustable.
Kerberos circumvents the problem of the ünknown" authenticity of certificates by introducing a trusted third party.

2.5.3  Requirements for Kerberos Authentication

To implement a strong and secure authentication mechanism into the CIMOM OpenPegasus, Kerberos should be used.
The following requirements for the functions are:

Chapter 3
The Authentication Service Kerberos

The word Kerberos stems from the Greek mythology, where Cerberus, a three headed dog, was the sentinel of the underworld Hades. Today, Kerberos is a sophisticated Authentication Service developed at the Massachusetts Institute of Technology within the project Athena. It is based on the Needham-Schroeder Protocol [] and used within distributed systems.
Kerberos uses the principle of a trusted third party entity which is a centralized authentication server that all systems within a network can trust in. Every authentication server manages the specific information about authentication within a domain of responsibility called realm. In order to achieve a Single-Sign-On environment, the authentication servers can be organized hierarchically to realize Cross-Realm authentication. The benefit of this architecture is that a user has to type in his password only once for using all services (that support Kerberos) within a distributed system environment.

3.1  Introduction and basic concepts

In general, authentication is the process of proving the identity to another person. Kerberos is an Authentication Service for distributed systems. It is based on the Client-Server Model and allows any entity within a network to authenticate against a special service within this network. The term entity in this context can be a client, a user or a server which participates in authentication and is called principal in the Kerberos terminology. For the exchange of information the messages are encrypted. In this connection a symmetrical encryption algorithm is used, that is encryption and decryption are performed with the same key. With the Public-Key-Method (asymmetric) the data is encrypted with a public key which is known to the other participants and decrypted using a private key which is secret. The advantage of a symmetrical encryption algorithm compared to the Public-Key-Method is its high-performance (about 1000 times faster). The problem when using symmetrical encryption is that the keys have to be exchanged between the partners that want to communicate with each other. The number of key exchanges grows quadratically with the number of participants. For n participants we have [n*(n−1)/2] key exchanges.
To circumvent the disadvantage of exchanging large numbers of keys, Kerberos uses a so called Key Distribution Center (KDC) which is trusted by both participants and which administrates the keys within a secure database (trusted third party principle).
Figure shows the trusted relationship between the three main actors Client, Application Server and the KDC. On the Application Server there could run any service where Kerberos is implemented; in the case of a System Management Architecture this would be the CIM-Server.
Figure
Figure 3.1: The Key Distribution Center as trusted third party entity
Kerberos provides two services: the Authentication Service (AS) against whom principals have to authenticate themselves in order to use kerberized services7 and the Ticket Granting Server (TGS) which certifies tickets to principals who want to use a specific service. Tickets are encrypted data structures that are used to process authentication. Both services, AS and TGS, are usually combined within one server: the Key Distribution Center (KDC). The KDC holds a database containing all principals with their corresponding keys. The key is deduced from the password of the principal, which the principal has to declare to the KDC.
Kerberos provides three different levels of protection. Some applications require that the authentication is only done once when establishing a network connection and expect that further messages originate from the authenticated entity.
There may also be applications which require authentication for each message, but do not care if the content of the messages is encrypted or sent in plain over the network.
The highest level of security is needed by applications which have to handle sensitive data, like a System Management Application. In this case each message is not only authenticated but also encrypted. These so called private messages are also used by the Kerberos server itself when sending passwords over the network.

3.2  The Key Distribution Center

The Key Distribution Center (KDC) in which the Authentication Service and the Ticket Granting Service are combined plays an important role in Kerberos. It is the trusted third party entity and consists of three logical components: the Authentication Server, the Ticket Granting Server and an encrypted database of all principals with their corresponding keys. Since Kerberos supports a hierarchical organization of KDC in order to offer cross-realm authentication, the database of each KDC must be kept in synchronization to ensure unified authentication. The Kerberos Protocol does not specify a standard method of synchronization, so the replication of these databases has to be implemented by the different vendors [].
The Authentication Server is used to obtain initial tickets, so called Ticket Granting Tickets (TGTs), to make use of the Ticket Granting Server. In an entirely kerberized environment, for every service a ticket is needed, even for the Ticket Granting Service. With the initial ticket or more precisely with the respective successful decryption of it, the identity of a user can be verified. Once the TGT is decrypted by the client it can be used to request tickets for further individual services. The TGT eliminates the requirement for a user to retype his password for each subsequent request.
With the receipt of the TGT, the client can request for individual services using the Ticket Granting Server (TGS). The client sends a request for a service ticket to the TGS, which includes the principal name of the service he wants to use and the TGT he just obtained from the Authentication Server. The TGS verifies the TGT and sends the service ticket to the client, if the verification was successful.
The initial ticket (TGT) is stored together with the subsequent service tickets in the credentials cache of the clients machine.

3.2.1  Credential Management

The Kerberos authentication system uses two types of credentials: authenticators and tickets. They are both based on symmetrical encryption algorithm, but for the encryption different keys are used. According to Schiller, tickets are used to securely pass the identity of the person to whom the ticket was issued between the authentication server and the end server []. A ticket holds also some information that can be used to make sure that the person using the ticket is the same person to which it was issued. This is accomplished using authenticators. With this method replay attacks can be prevented.

3.2.2  The Ticket System

In a Kerberos system, the use of tickets is the central concept for processing authentication. Generally speaking, a ticket is an encrypted data structure issued by the KDC to establish an authentication process.
The following abbreviations are subsequently used:


c Client
s (Application) Server
addr client's network address
Kx x's secret key
Kx,y session key for x and y
{...}Kx encrypted with x's key
Tx,y x's ticket to use y
Ax Authenticator of x


The Ticket Granting Server (TGS) issues tickets which are in fact only valid for one specific server (or service). Every ticket in general holds the following information:

Tc,s = {s, c, addr, timestamp, lifetime, Kc,s}Ks
s is the name of the application server which is to be accessed, c is the name of the client who requires the service and addr is the Internet address of the client. Furthermore the ticket contains a timestamp, which represents the current date and time, the lifetime of the ticket until it is valid and the random session key Kc,s between client and server. All this information are encrypted using the Master key of the server s for which the ticket is to be issued. As long as the ticket is still valid, it can be reused by the client for subsequent requests to the server. A typical lifetime of a ticket is about 10 hours - the duration of a normal working day. A major difference between tickets and authenticators are that the latter one can only be used once. Every time the client wants to use the service, it has to generate a new authenticator, which includes the following items:

Ac = {c, addr, timestamp}Kc,s
That is the name of the client c and its address addr with a timestamp, all encrypted using the session key Kc,s of both parties.

3.3  Sequence of actions of the Authentication Protocol

When a client requests for a special service, there are several steps of communication between client, server and the KDC. In order to obtain a service ticket, the client has to request an initial ticket at the Authentication Server and can use this ticket to receive further tickets from the Ticket Granting Server. In this section the steps of the message exchange between the three participants of the authentication process is described in detail.

3.3.1  Obtaining an Initial Ticket

The service of the Ticket Granting Server (TGS) is to issue tickets. Because the client needs also a ticket when requesting this service from the TGS, an initial ticket, a so called Ticket Granting Ticket (TGT) is required. After a user has successfully logged in on his/her workstation, a TGT is automatically requested. Every morning the user logs in, a new TGT is obtained which is valid for the whole working day.
Figure shows the process of getting the Initial Ticket from the Authentication Server.
Figure
Figure 3.2: Requesting the Initial Ticket
First the user is prompted for username. After entering, a request is sent to the Authentication Server which contains the username (client's name) c and the name for the service, namely the ticket-granting service TGS.

AS_REQ : c, TGS
The Authentication Server looks into the database of the KDC and verifies that the user/client exist. If this is the case, it generates the Initial Ticket (TGT), denoted by Tc,TGS, which contains the client's name, the name of the ticket-granting server, a timestamp, the lifetime for the ticket, the client's IP-address and a random session key for the client and the ticket-granting server []. It is important to note, that the client did not send the password for requesting the TGT. The Authentication server extracts the password of the client from the database and deduces the key from the password, which will later be used to encrypt the response message in which the TGT is included.
The Authentication Server encrypts the TGT using the secret key of the ticket-granting server: {Tc,TGS}KTGS. It then encrypts again this encrypted TGT, together with the random session key for the client and the ticket-granting server Kc,TGS, using the secret key of the client.

AS_REP : { Kc,TGS , {Tc,TGS}KTGS }Kc
The random session key is later used by the client to communicate with the ticket-granting server. This response message, encrypted using the client's secret key, is sent back to the client.
After the client receives this response, the user is asked for the password. The password is converted to a DES key and only with the correct password, the user is able to decrypt the message just obtained. In this case, the TGT and the session key are stored in the credentials cache of the client's workstation.
After the successful completion of this procedure the workstation stores the information that can be used to prove the identity of the user for the lifetime of the TGT. That is in particular the session-key for the client and the TGS, which is used to encrypt the authenticator of the client and is needed for each subsequent request for a service ticket.

3.3.2  Requesting a Service Ticket

Once the Client has obtained a Ticket Granting Ticket, it can use that initial ticket to request further Service Tickets for specific services. For every service that is to be used, a separate service ticket is needed. For this purpose, the client has to request a service ticket from the Ticket Granting Server as depicted in Figure .
Figure
Figure 3.3: Requesting the Service Ticket
At first, the client has to build an authenticator in order to prove his identity to the server. The authenticator consists basically of the following information:
Ac = c, addr, timestamp
That is the name of the client, the IP-Address of the client and the timestamp he obtained with the Ticket Granting Ticket. With the authenticator the client shows that he is in possession of the session key. The timestamp is used in order to prevent replay attacks.
This authenticator Ac is then encrypted with the common key Kc,TGS and sent together with the name of the server s for the requesting service and the TGT (initial ticket for the TGS) Tc,TGS, still encrypted with the secret key of the TGS, to the Ticket Granting Server.
TGS_REQ : s, {Tc,TGS}KTGS , {Ac}Kc,TGS
After the TGS has received this message, it decrypts the initial ticket Tc,TGS, using its secret key KTGS and extracts from this ticket the session key Kc,TGS. With this session key the TGS is able to decrypt the authenticator of the client {Ac}Kc,TGS. If the authenticator is valid, the TGS generates a new random session key to be used between the client and the application server to be used. It then builds a service ticket containing the client's name, the server name, a timestamp, the client's IP address and the new session key just created []. This service ticket is denoted by Tc,s and is encrypted using the secret key of the server: {Tc,s}Ks. The TGS sends this ticket along with the client's copy of the random session key Kc,s, all encrypted using the session key of the client and the TGS Kc,TGS, back to the requesting client.

TGS_REP : {{Tc,s}Ks , Kc,s}Kc,TGS
Using the session key Kc,TGS, the client decrypts the reply message, extracts the new session key Kc,s and the service ticket {Tc,s}Ks and stores it in the credentials cache of the client's machine.

3.3.3  Requesting a Service

After the client has successfully obtained a service ticket it can be used by the client to request a service.
Figure illustrates the client's request for a Service.
Figure
Figure 3.4: Requesting a Service
The client builds again an authenticator, extracts the session key Kc,s from the credentials cache and encrypts the authenticator, using this session key:
{Ac}Kc,s
The service ticket is also fetched from the credentials cache of the client and sent together with the authenticator to the application server.
Service_REQ : {Tc,s}Ks , {Ac}Kc,s
The Application server is able to decrypt the service ticket using its secret key Ks. It then extracts the session key and decrypts the authenticator of the client with this session key. If the authenticator is valid, the client is successfully authenticated.
In the environment of System Management, the application server represents the CIM-Server. The authenticator is the same as for the service ticket request, except that it is now encrypted with the session key of the client and the application server in order to enable the application server to decrypt the authenticator and prove the identity of the client.
It is important to ensure synchronized clocks between the parties. If the time-difference of the service-ticket request and the service request itself is too large, the authentication process fails. This is implemented in order to prevent so-called replay attacks. A typical upper bound for the clock-skew can be several minutes and are adjustable by the KDC.
There still remains the possibility that someone claims to be the application server, letting the user think that he is connected to the legitimate server, while in fact the user is communicating with an attacker. This is referred to a Man-in-the-Middle attack and will be discussed in more detail in the section Security Considerations.
For this reason there is the possibility of performing Mutual Authentication in Kerberos. That is, also the application server has to prove his identity to the client. This can be done very easily. The application server increments the timestamp he just obtained from the client within his authenticator Ac and encrypts it with the session key (see Figure ).
Figure
Figure 3.5: Mutual Authentication
At the end of this authentication process, the application server can be sure that the client is who he claims to be and in case of Mutual Authentication the client can also trust that the application server is the legitimate server. After authentication the client and the server can communicate securely, encrypting all messages with their session key known only to them and the trusted third-party entity.


Figure summarizes the entire authentication process for requesting a service and table illustrates the contents of the messages that are exchanged.
Figure
Figure 3.6: Entire Authentication process
Step From To Message
1. AS_REQ Client Authentication Server c, TGS
2. AS_REP Authentication Server Client {Kc,TGS, {Tc,TGS}KTGS}Kc
3. TGS_REQ Client TGS s, {Tc,TGS}KTGS, {Ac}Kc,TGS
4. TGS_REP TGS Client {{Tc,s}Ks, Kc,s}Kc,TGS
5. Service_REQ Client Application Server {Tc,s}Ks, {Ac}Kc,s
Table 3.1: Message exchange at the Kerberos Authentication Process
  1. The client sends AS_REQ. This is the request for an initial ticket, containing the name of the client and the name of the TGS.
  2. The AS responds with AS_REP. The Authentication Server sends the TGT encrypted using the key of the TGS and the session key of the client and the TGS to the client.This message is encrypted using the secret key of the client.
  3. The client sends TGS_REQ, requesting for a specific service. The request contains the name of the service the client wants to use, the TGT just obtained and the authenticator of the client encrypted with the session key of the client and the TGS.
  4. The TGS responds with TGS_REP, containing the service ticket encrypted with the key of the application server and the session key of the client and the application sever. This message is encrypted using the session key of the client and the TGS.
  5. The client requests for a service, sending his authenticator and the service ticket to the application server.
In case of mutual authentication the application server increments the timestamp he just obtained from the client by 1 and sends it back to the client, encrypted using their session key.

3.4  Security Considerations

The modern Kerberos protocol, which has been issued in its 5th version, has evolved from the early predecessors. The versions 1 to 3 were only trial versions used internally at MIT. With the version 4 and 5 major improvements have been made concerning usability, extensibility and especially security.
An important feature of the Kerberos Authentication Protocol is that authentication messages are not sent in plaintext over the network, but are encrypted using the DES algorithm or in Kerberos v5 triple-DES. Since the ethernet network is a broadcast medium, where every station connected to the network is continuously listening to all network traffic in that segment, sending authentication data in the plain is an extreme high security risk. But unfortunately strong encryption is not enough to guarantee high security. In this section the different security attacks with which Kerberos can possibly be confronted are analyzed.
Those security attacks can be structured into two groups:

3.4.1  Compromise of the KDC

The nightmare of every authentication protocol based on the principle of a trusted third party is compromise of this entity. If the Kerberos KDC is compromised, reading and modifying any user data becomes possible and thus the entire user group becomes vulnerable. In this case the attacker has full control over the entire Kerberos authentication system. Despite the fact that the Kerberos database is encrypted on the disk using the Kerberos master key, the master key itself is also kept on the disk. Thus, a root-level compromise of a KDC machine hollows out the entire concept of Kerberos security.
To solve this problem, Naomaru Itoi describes in a paper how to integrate the IBM 4758 secure coprocessor into a Kerberos v5 KDC and demonstrates the capabilities of secure hardware []. A secure coprocessor is a "computational device that can be trusted to execute its software correctly, despite physical attack" []. The IBM 4758 is a PCI card with a secure coprocessor on it.
It works on the principle that the host computer on which the Kerberos KDC runs is not trusted any more. The basic design of this approach is to split the KDC between the host and the 4758:
The most important concept of this design is storage of the master key in the battery backed up RAM in the 4758. The master key remains in the RAM and never leaves it.

3.4.2  Brute-Force Attacks

In the original Kerberos protocol version 4, the KDC issues a TGT to any client who requests it, without proving the identity of the requesting principal. The security of the entire system relies on not being able to decrypt this message. An attacker could just request a TGT for any principal which is known to Kerberos and launch a so called offline dictionary attack. Once he has obtained the TGT from the authentication server, he can try out an arbitrary number of different passwords offline, without communicating with Kerberos. The method of using words from a dictionary or commonly used passwords and feeding them into a program which transforms this into a key and tries out to decrypt the TGT would become possible. This becomes feasible due to the fact that the transformation from the users password to the encryption key which is used by Kerberos is well known (String-to-Key Transformation). According to Thomas Wu, compromising the TGT can be done quite easily []:
  1. Convert the password to a DES key: K = STRING-TO-KEY(P)
  2. Decrypt the ticket with the key K and see if it is a valid Kerberos ticket. If it is, then P is the user's password.
The security relies purely only on the chosen password.
The problems of Brute-Force and offline dictionary attacks are explicitly stated in the RFC 1510:

""Password guessing" attacks are not solved by Kerberos. If a user chooses a poor password, it is possible for an attacker to successfully mount an offline dictionary attack by repeatedly attempting to decrypt, with successive entries from a dictionary, messages obtained which are encrypted under a key derived from the user's password."

In order to determine whether a chosen key leads to the successful decryption of the TGT, the attacker can make use of a method called known plaintext attack []. With this method the attacker is in possession of a piece of plaintext and the corresponding ciphertext. The ciphertext is the encrypted TGT he obtained from the authentication server and one part of the plaintext is also known: The ßervice-name" field, which is the second field of the decrypted ticket, is always "krbtgt" for a TGT. This is the only field in the TGT which is known. Table shows the content of a TGT. Since the length of the first field, which is the Session Key, is fixed to 8 bytes, the position of the service name string is known. This implies that only the first two blocks of the TGT have to be decrypted in order to verify the correctness of the chosen password.
Field Content Length in Bytes
1 Session Key 8
2 Service Name = "krbtgt" 6
3 Instance variable String
4 Realm variable String
5 Ticket Lifetime 1
6 Version Number 1
7 Length of Encrypted Ticket Block 1
8 Encrypted Ticket Block 1
9 Timestamp 4
Table 3.2: Format of the TGT according to []
In the Kerberos protocol version 5 new features are implemented to make this form of attack more difficult. On the one hand there is a support for extensible encryption type, which allows the addition of stronger encryption algorithms, on the other hand a new optional security mechanism called preauthentication is built in, which is not currently specified [].
Preauthentication requires that the client who requests an initial ticket proves his identity before the KDC will issue the ticket. When preauthentication is used, the client sends in addition to the request for obtaining an initial ticket a timestamp which is encrypted using the private key of the client Kc as depicted in Figure .
Figure
Figure 3.7: Requesting the Initial Ticket with Preauthentication
The KDC sends back the TGT to the client only if he is able to decrypt the timestamp using the private key of the principal which requested the TGT.
This technique reduces the possibility of Brute-Force Attacks, but does by far not completely eliminate this threat. There is still the possibility given that an attacker contacts the KDC every time he attempts a new password. Furthermore the attacker could make use of a network ßniffing" tool to obtain the responses of the KDC. Such kind of sniffing tools make use of the broadcast property of the ethernet network structure, where all packets are sent to all stations. When gaining a TGT with this method, the attacker is still able to launch an offline dictionary attack with the TGT from a principal he actually does not know yet.

3.4.3  Replay Attacks

Another possible attack Kerberos has to struggle with is known as a Replay Attack. Since the protocol exchanges are simple electronic messages, there is the possibility of intercepting messages when they are broadcasted within an ethernet using sniffing tools as described in the previous section. If an attacker has intercepted a valid service ticket, he is able to make a copy of this message and replay it at a later time as illustrated in Figure .
Figure
Figure 3.8: Kerberos Replay Attack
The ticket is encrypted with the key of the application server and the authenticator is encrypted using the session key of the client and the application server. When the application server receives the replayed message from the attacker, it decrypts the ticket with its own key, receives the session key from the decrypted ticket and uses the session key to decrypt the authenticator.
Kerberos has implemented several protections to prevent Replay Attacks []. These protections are:

3.4.4  Man-in-the-Middle Attacks

Basically every protocol that tries to verify the identity of two connection endpoints is confronted with the so called Man-in-the-Middle Attack. That is, an attacker impersonates the server and lets the users think that they are communicating with the legitimate server, while in fact they are connected with an attacker. The attacker can then pass the messages without modification on to the legitimate server or he can modify or even delete messages between the client and the server []. Since the attacker is part of the conversation between client and server, this scenario is referred to as "Man-in-the-Middle".
Fortunately the Kerberos Protocol has a built in mechanism to defeat this kind of attack. With mutual authentication, the server also has to prove his identity to the client.

Chapter 4
Implementation of Kerberos into Web Based Enterprise Management

This chapter describes how to implement the Authentication Service Kerberos into the CIM Object Manager (CIMOM) of a Web Based Enterprise Management Application. For the CIMOM, the OpenPegasus implementation is used which is written in C++ and thus offers the possibilities and advantages of object oriented programming. The Pegasus CIMOM contains over 200 classes. The CIMClient class is used by management applications to contact the CIMOM over the network and perform CIM operations. This class represents a kind of front-end to the CIM-over-HTTP protocol. The Client module as well as the server module have to be extended in order to support Kerberos Authentication. Due to the encapsulation of the classes, the main functionality of the authentication process resides in one class, the CIMKerberosManager. This class is abstract and the platform-specific implementations of that class are used both by the server module and the client module of the CIMOM.
In order to implement Kerberos security, the Generic Security Service Application Programming Interface (GSS-API) can be used for many different platforms. These are z/OS, major Unix derivatives and most Linux distributions. The different platform-specific implementations of the GSS-API do not differ very much from each other. To implement Kerberos for Windows there exist the Security Service Provider Interface (SSPI), which is similar to the GSS-API, but has some significant differences. These will be discussed as well as the interoperability of applications using these two different APIs.

4.1  Overview

OpenPegasus needs to determine which users are allowed to log into the CIMOM. The clients login using HTTP as the protocol. For this login procedure, the Authentication Protocol Kerberos should be used.
Within a Web Based Enterprise Management Application the Client (manage system) sends a request to the Server (managed system) to do some specific operation. Subsequently the Client is referred to as CIM Client and the Server, which is actually the CIM Object Manager (CIMOM), is referred to as CIM Server. These requests contain the specific CIM Method which should be invoked on the managed system and are encapsulated into HTTP.
Figure illustrates the sequence of actions if a CIM Client requests a CIM Method and Kerberos is used for authentication.
Figure
Figure 4.1: CIM Client requests CIM Method (initial request)
The header of the HTTP-request contains a CIM request (1). The CIM Server responds with the well known HTTP error 401, which means that the client is not authorized (2). Upon this response, the client requests a service ticket from the KDC to use the CIM Server (3). The KDC replies with the service ticket (4). It is assumed that the client has already a valid Ticket-Granting-Ticket (TGT). Then the client generates another request with an authorization string in the header and a token, containing the credentials of the client. These credentials are in particular the service ticket and the authenticator of the client (5). A so called security context is to be established between the client and the server. With his private key, the server decrypts the service-ticket which contains among other things the session key for this security context. With this session key the server is able to decrypt the authenticator of the client and checks if the client is authorized to use this server. In that case the CIM Server processes the requested CIM operation and sends the result back to the client (6).
Let us assume, the CIM Client wants to use the CIM method EnumerateInstances, which is used to enumerate all instances of a CIM Class on the managed system within a specific namespace. The HTTP header of this request would have the following shape:
1.16 POST /cimom HTTP/1.1 HOST:CBGUIBLD.boeblingen.de.ibm.com Content-Type: application/xml; charset=ütf-8" Content-Length: 366 CIMOperation: MethodCall CIMMethod: EnumerateInstances CIMObject: root
The body of the HTTP-request holds the CIM request encoded into XML: 1.16 1.16 <?xml version="1.0" encoding=ütf-8" ?> <CIM CIMVERSION="2.0" DTDVERSION="2.0» <MESSAGE ID="1001" PROTOCOLVERSION="1.0» <SIMPLEREQ> <IMETHODCALL NAME=ËnumerateInstances» <LOCALNAMESPACEPATH> <NAMESPACE NAME="root"/> </LOCALNAMESPACEPATH> <IPARAMVALUE NAME="ClassName» <CLASSNAME NAME="__NameSpace"/> </IPARAMVALUE> </IMETHODCALL> </SIMPLEREQ> </MESSAGE> </CIM>
The response will be: 1.16 HTTP/1.1 401 Unauthorized WWW-Authenticate: Negotiate

4.2  The Generic Security Service API

The Generic Security Service Application Programming Interface (GSS-API) is a standard and is specified in the Request for Comments (RFC). The latest version 2, update 1, is described within the RFC-2743 [].
The GSS-API has to be recognized as a standardized and abstract interface, which provides security services in a generic fashion to application programmers. Generic means in this context that it is not dependent on any particular security mechanism and technology. The benefit of this approach is the portability of the applications using the GSS-API to different environments. The GSS-API can be implemented using private key technology that is using the Kerberos Authentication Service as the underlying security mechanism. This is specified separately within the RFC 1964 [].

4.2.1  Introduction

The GSS-API enables application programmers to write their software in a generic fashion with respect to security. The programmer does not have to take care of tying the security implementation to any particular platform, security mechanism or transport protocol. Due to this fact the applications that take advantage of the GSS-API are highly portable. The GSS-API does not provide security services itself. It just gives a framework to the calling application to use specific security mechanisms and technologies, such as Kerberos for instance. Figure shows the embedding of the GSS-API into the entire system.
Figure
Figure 4.2: The GSS-API Layer according to []
At first the GSS-API has to create a security context, which is a kind of trusted relationship between the two applications who want to communicate with each other. After the security context has been established successfully, the GSS-API applies some type of protection, the security services, to the data to be transmitted.
The functions of the GSS-API are divided into four different groups:
The classification of the functions reflects the general concept of the GSS-API. First both parties have to obtain their credentials. Then the client can initiate a security context and the server (hopefully) accepts it. After the establishment of the security context both peers can communicate securely by sending messages.

4.2.2  Credential Management

A credential is a data structure that provides a proof of the identity. Än Application uses a credential to establish its global identity" []. The GSS-API does not provide credentials, they are created by the underlying security mechanism, which is Kerberos in this case. The Operating System saves the credentials on the local filesystem within an encrypted file (credentials cache).
Before a security context can be established, both the server and the client have to acquire their credentials. Once they have obtained their respective credentials, they can be re-used until they expire.
For the management of the credentials, the GSS-API provides the following functions []:
Function Usage
gss_acquire_cred acquire credentials before use
gss_release_cred release credentials after use
gss_inquire_cred obtain information about credentials
gss_add_cred construct credentials incrementally
gss_inquire_cred_by_mech display per-mechanism credential information
Table 4.1: Functions for credential management

4.2.3  Context-level calls

The GSS-API acts session-oriented. Before the actual data can be exchanged, a security context has to be established. This is the most crucial part of the authentication process. For the security context there can be some requirements, like performing mutual authentication, message confidentiality or integrity, that have to be specified before establishing the context. Before the client can initiate a security context, it needs a valid Ticket Granting Ticket in its credentials cache. The successful establishment of a security context contains the client's request for a service ticket at the Ticket Granting Server (TGS), the TGS reply containing the service ticket and the random session key and finally the request for the service, where the client sends his Authenticator and the service ticket to the application server (compare Step 3 to 5 of Figure 3.6).
For the establishment and management of security contexts between peers, the GSS-API provides the following functions []:
Function Usage
gss_init_sec_context initiate outbound security context
gss_accept_sec_context accept inbound security context
gss_delete_sec_context flush context when no longer needed
gss_process_context_token process received control token on context
gss_context_time indicate validity time remaining on context
gss_inquire_context display information about context
gss_wrap_size_limit determine GSS_Wrap token size limit
gss_export_sec_context transfer context to other process
gss_import_sec_context import transferred context
Table 4.2: GSS-API context-level calls
The gss_init_sec_context() and the gss_accept_sec_context() are the central functions for the establishment of a security context. The initiator calls gss_init_sec_context() and sends the generated context-level token to the acceptor, which passes it to the function gss_accept_sec_context(). This function again generates a token and that token is sent back to the initiator. This loop continues until a security context is established. Figure shows the process of establishing the security context. It is assumed that both peers have already acquired their respective credentials.
Figure
Figure 4.3: Establishment of a security context
If the application requires reply tokens, the gss_init_sec_context() routine returns
GSS_S_CONTINUE_NEEDED
as major status value. The application must call the gss_init_sec_context() routine again when receiving the reply token from the acceptor. The loop continues until both functions return
GSS_S_COMPLETE
If this is the case, the security context has been successfully established and both peers can securely exchanges messages via a so called context handle.
When the security context is no longer needed, one peer (either the server or the client) can delete the context with the function gss_delete_sec_context(). It then deletes the local data structures associated with the security context. When deleting the context, the function generates a token, which has to be passed to the partner application. Upon receipt of this token, the partner application calls the gss_process_context_token() routine to process the token and complete the process of deleting the security context.

4.2.4  Peer-message calls

This group of functions is used to perform the processing of the protection of messages after a security context has been established. The four different functions can be considered as two pairs, each with a function and its opponent: Encryption and decryption of messages on the one hand and applying integrity and validating integrity of messages on the other hand.
Function Usage
gss_wrap sign, optionally encrypt,encapsulate
gss_unwrap decapsulate, decrypt if needed, validate integrity check
gss_get_mic apply integrity check, receive as token separate from message
gss_verify_mic validate integrity check token along with message
Table 4.3: GSS-API peer-message calls
The client generates messages and passes them to the gss_wrap() routine, which performs data origin authentication, data integrity, and optionally confidentiality processing (encryption) on the message and encapsulates the result into the output message [].
Data integrity is carried out using a Message Integrity Check (MIC). There are several algorithms available, like MD5 or the DES MAC (Message Authentication Code). For this purpose the gss_wrap() routine calls the gss_get_mic() routine and returns the MIC together with the wrapped message. The returned MIC is in this context referred to as a cryptographic signature.
The token returned from the gss_wrap() routine is sent to the partner application, which calls the gss_unwrap() routine to extract the original message and verify its authenticity. It has then the optional possibility to produce a signature block for this message using the gss_get_mic() routine. In this case it sends back the signature block to the client, who is able to verify the signature using the gss_verify_mic() procedure. With this procedure it can be ensured that the message has not been modified since the signature was generated.
Figure shows the data transfer after a security context has been established.
Figure
Figure 4.4: Data transfer after establishment of security context

4.2.5  Support calls

The last group of functions provides support calls, useful for GSS-API callers before establishing a security context. They provide some additional information and translate different data structures.
The most important functions are listed in table .
Function Usage
gss_display_status translate status codes to printable form
gss_display_name translate name to printable form
gss_import_name convert printable name to normalized form
gss_release_name free storage of normalized-form name
gss_release_buffer free storage of general GSS-allocated object
Table 4.4: GSS-API support calls
The gss_display_status() function is very useful for inspecting the return codes of the functions. It translates the 32bit error code into a human readable string which contains a short description of the error. The gss_import_name() routine is used to convert a printable name (string) into the GSS-API internal format. The returned gss_name_t object can then be used as input to other GSS-API routines. The counterpart of this routine is the gss_display_name() function, which provides the textual representation of the internal format. It is the responsibility of the application programmer to free the storage of GSS-allocated objects using the routines gss_release_name() and gss_release_buffer().

4.3  Development of a Kerberos Test Program

In order to test the Kerberos Setup and to get acquainted with the GSS-API, test programs have been developed. This section introduces the general concept of both the client-side and the server-side program and gives some results of several test cases that were applied. The listings of the programs can be found on the CD-ROM which is included (see Appendix for more details).

4.3.1  General Concept

Two programs have to be developed to show the Kerberos authentication: a server programm and the corresponding client program. General speaking, the client tries to establish a security context with the server and sends on success an encrypted string. The server decrypts it, computes the Message Integrity Code (MIC) and sends it back to the client.
On client side:
  1. make TCP socket connection to server
  2. acquire credentials
  3. initiate security context with server
  4. wrap a message and send it to server
  5. verify the MIC from server's reply
  6. delete security context
On server side:
  1. bind TCP socket and wait for client's request
  2. acquire credentials
  3. accept security context from client
  4. unwrap the message sent by the client
  5. compute the MIC and send to client
  6. delete security context
The server program waits for client requests while the client program tries to establish a security context with the server and send some messages. In order to establish a TCP communication session between both applications, a socket connection has to be used. For this case the server function int wait_for_client_connection(int port) opens a socket for a TCP stream and binds its port-address, that were passed as argument to the function, to the socket. It then continuously listens to client request on this port.
The client program calls the function int connect_to_host(char *hostname, int port). The port has to be the same as the port on which the server is listening. After successful execution, the TCP socket connection between client and server is established. Whenever one application wants to send data to the other application, it just writes the data to a so called socket file descriptor.
The client has to call the function gss_import_name() to convert the names from human readable Strings of ASCII characters to the GSS internal data format. This has to be done for the service name as well as for the user name. It then has to acquire his credentials using the function gss_acquire_cred(). This routine obtains a GSS-API credential for the specified principal name. The application must have a valid ticket (TGT) in the default credentials cache and the ticket must not expire for at least 10 minutes. Now the critical part comes: the client has to initiate a security context with the server. For this purpose it calls the function gss_init_sec_context() within a do-while loop. The loop will continue to iterate as long as the result of the function will be GSS_S_CONTINUE_NEEDED. The loop will break if either the function returns an error or GSS_S_COMPLETE. In the last case the security context has been successfully established.

4.3.2  Test Cases

After the applications have been developed, it would be useful to see some results in the case of abnormal conditions of program execution.
No KDC available
If there is no Kerberos service running, the application still is able to convert the name to GSS-API internal format and to acquire credentials. But when trying to initiate a security context, the following error will occur:
Cannot create context
initializing context: Cannot contact any KDC for requested realm
initializing context: Miscellaneous failure


Ticket expired
The same holds when the TGT in the credentials cache is expired. The output in this case will be:
Cannot create context
initializing context: Ticket expired
initializing context: Miscellaneous failure

4.4  Design of the authentication mechanism

This section provides an insight into the design of Kerberos authentication within the CIMOM OpenPegasus. In order to allow different authentication mechanisms within the CIMOM OpenPegasus, the SPNEGO protocol can be used.

4.4.1  Overview of Kerberos Authentication within the CIMOM

Figure illustrates which classes are involved for Kerberos Authentication within the CIMOM OpenPegasus.
Figure
Figure 4.5: Kerberos Authentication within the CIMOM Pegasus
At the startup of the CIMServer, the constructor of the instantiated class creates the HTTP AuthenticatorDelegator queue. A constructor is a set of operations that are executed when an object of that class is created. A queue is needed, because there may be several HHTP connections at the same time and each connection is handled separately. A monitor is continuously listening on the socket for incoming HTTP connections.
The HTTPAuthenticatorDelegator constructor creates AuthenticationManager.
AuthenticationManager constructor loads the AuthenticationHandlers.
The main authentication components in the CIMOM OpenPegasus are:
Authentication Manager
Authentication Handlers
Authenticators
As depicted in Figure 4.5, Kerberos authentication is hooked into OpenPegasus similarly to the existing Basic authentication. The CIM Kerberos Authenticator has several classes that encapsulate various components of Kerberos in order to allow platform-specific implementations. Figure shows the classes needed for Kerberos authentication.
Figure
Figure 4.6: Pegasus CIM Kerberos Authenticator
The CIM Kerberos Manager holds the functionality of the Kerberos Authentication process. The CIM Identity Manager is used to map the Kerberos users into the Enterprise Identity Mapping (EIM). The CIMIdentityManager class is a platform independent abstract class used as an interface for dealing with platform-dependent identity mapping implementations. This interface will allow the caller to determine whether identity mapping is enabled in the current environment and to query associations between user identities.

4.4.2  The SPNEGO Protocol

SPNEGO, the Simple and Protected GSS-API Negotiation Mechanism, is defined in the RFC 2478 and allows to negotiate different security mechanisms, different options within a given security mechanism or different options from several security mechanisms [].
Due to the fact that the GSS provides a single API with different authentication mechanisms, the problem of negotiating which mechanism to use arises. This solved by the SPNEGO protocol.


An example of the SPNEGO protocol being used over HTTP is given with the following scenario:
1. The CIM client sends a request to the CIM Server for a particular CIM operation. In this example the client makes an initial request: M-POST / CIMOM HTTP/1.1 ...
2. Since the request does not contain an Authorization header, the CIM Server does not yet have a session with the client. If Kerberos authentication is configured within the CIM Server, the response will be: 1.16 HTTP/1.1 401 Unauthorized WWW-Authenticate: Negotiate
3. Upon receipt of the "WWW-Authenticate: Negotiate" header the client will acquire his credentials and call gss_init_sec_context() to produce a GSS-API token that will then be sent to the CIM Server along with the Authorization header: 1.16 M-POST / CIMOM HTTP/1.1 ... Authorization: NegotiateYIICiAYGKwYBBQUCoIICfDCCAnigDTALBgkqhkiC9x
4. The Pegasus server will pass the GSS-API token to gss_accept_sec_context().
4a. If the token is acceptable, the security context will be successfully established.
4b. If gss_accept_sec_context() returns GSS_S_CONTINUE_NEEDED, the security context is not yet established so the CIM Server will respond with a "401 Unauthorized" status code and a "WWW-Authenticate" header with the GSS-API data: 1.16 HTTP/1.1 401 Unauthorized WWW-Authenticate: Negotiate CYWCCAl0GCSqGSIb3EgECAgEAboICTDCCAkigAwIBBaED
The client decodes the returned GSS-API data, passes it to gss_init_sec_context() and returns the new GSS-API data to the CIM Server: 1.16 M-POST / CIMOM HTTP/1.1 ... Authorization: Negotiate R02iMjAwoAMCAQGhKTAnGwVjaW1vbRseQ0JHVUlCTEQ
This loop will continue until the security context is established (compare Figure 4.3).


Once the security context has been established, the data in the HTTP response can be used by the application.

4.4.3  Client-Side Kerberos Processing

The following pseudo-code shows the overall client-side Kerberos processing, which is involved when authenticating to the CIM Server.
0.5 connect to server
get server's name
gss_import_name()
gss_init_sec_context()
do
send gss_client_token
receive server_token
if Mutual Authentication required
then
gss_init_sec_context()
endif
until Security Context established
do
generate client-message
gss_wrap()
send wrapped client-message
receive server-message
gss_unwrap()
process server message
until no more data
generate terminate-message
receive context-token
gss_process_context_token()
gss_delete_sec_context()

4.4.4  Server-Side Kerberos Processing

The following pseudo-code shows the overall server-side Kerberos processing, which is involved when a CIM Client tries to authenticate against the CIM Server.
0.5 get server's name
gss_import_name() /* converts a printable name to GSS internal format */
gss_acquire_cred() /* get stuff from the keytab file (e.g. secret key!) */
while TRUE
wait for client connection
do
receive client_token
gss_accept_sec_context() /* accept the security context */
send gss_server_token /* only for mutual authentication */
until Security Context established
gss_display_name() /* get the Kerberos client out of the ticket */
use EIM APIs to map Kerberos user to a user ID on this system
do
receive wrapped client message
gss_unwrap()
process client message
if terminate message
then
gss_delete_sec_context()
send context-token to client so he can do gss_process_context_token
gss_release_cred()
else
generate server message
gss_wrap()
send server message
endif
until No Connection
endwhile
gss_release_oid_set()

4.5  Kerberos Interoperability between Windows and Unix

Unfortunately the GSS-API is not available on Microsoft Win32 platforms. To support Kerberos Authentication for Windows, which is implemented since Win2k (Win NT 5.0), Microsoft offers the SSPI-API to application programmers. In this section, the SSPI interface will be briefly introduced and a general mapping between those two APIs will be given.

4.5.1  SSPI

The Security Support Provider Interface (SSPI) model provides a single interface for applications (similar to the GSS), using various security mechanisms running on the Microsoft Windows32 platform.
One important difference between those two APIs is that for SSPI the application programmer has to manage the buffers needed for the tokens on his own, while the GSS takes care of this. The details of the implementation of SSPI will not be discussed here, instead it is referred to the MSDN Library [].

4.5.2  Comparison between GSS-API and SSPI

In general both APIs are quite similar. To most functions of the GSS there exists a mapping to a SSPI function.
The mappings from GSS to SSPI of the most important functions are summarized in table .
GSS-API SSPI (Windows API)
gss_import_name() QueryContextAttributes()
gss_acquire_cred() AcquireCredentialsHandle()
gss_init_sec_context() InitializeSecurityContext()
gss_accept_sec_context() AcceptSecurityContext()
gss_delete_sec_context() DeleteSecurityContext()
gss_release_cred() FreeCredentialsHandle()
gss_release_buffer() Windows applications have to manage their own buffers
gss_wrap() EncryptMessage()
gss_unwrap() DecryptMessage()
Table 4.5: Mapping of the functions form GSS-API to SSPI-API
Figure shows an overview of the Kerberos interoperability between Windows and Linux when using the two different APIs.
Figure
Figure 4.7: Windows - Linux Kerberos Interoperability
The Win32 CIM Client makes an HTTP request containing a CIM method (1). The response from the Linux CIM Server will be a 401 Unauthorized (2). Upon this response the CIM Client calls the SSPI-function InitializeSecurityContext() (3) and receives the context-level token from this function (4). The Client puts the token into the authorization header of the HTTP-request and sends it to the CIM Server (5). The Server passes the token to the gss-function gss_accept_sec_context() (6) and receives the context-level token (7). If security context established, the CIM request is executed and the result will be send along with a HTTP 200 OK to the Client (8).
The steps 3 to 8 are maybe performed several times until the security context is established.
The details of the corresponding function calls of both APIs and the message exchange is illustrated in Figure .
Figure
Figure 4.8: Message exchange between SSPI and GSS
First, both applications have to obtain their credentials. The establishment of the security context can be carried out with the corresponding functions of the two APIs. This loop will continue until the context is established. It could also be possible that the Client is running on a Linux machine and the Server on Windows.

Chapter 5
Conclusion and Outlook

The DMTF's Web Based Enterprise Management initiative establishes an infrastructure for different System Management Applications within a network of distributed and heterogeneous computing systems. To accomplish this in an open and consistent manner, WBEM has to define:
The common data model is realized with the object oriented Common Information Model (CIM) where the complex interdependencies of the real world can be mapped onto this model. The encoding specification for the transport is carried out with the powerful Extensible Markup Language (XML) in which CIM is encapsulated. For the transport protocol HTTP respective HTTPS is used which enables a convenient web based management.
The benefit of this architecture is that it is able to combine, besides Systems Management, all other levels of integrated management which are Network Management, Information Management, Application Management and Service Management.
Due to the interoperability between different solutions for System Management, the domain of responsibility of system and network administrators will probably increase in the near future. Thus there is a need for a secure and scalable authentication system with the possibility of real Single-Sign-On (SSO). This Bachelor Report has introduced the principles of the state-of-the-art Authentication Service Kerberos, where SSO can be realized using a hierarchical structure of the Key Distribution Centers and with the delegation of credentials using forwardable tickets. Furthermore the security considerations of Kerberos were discussed. The outcome was quite favorable: On the one hand the centralized KDC, with the critical and sensitive data, can be secured physically using IBMs secure coprocessor design and on the other hand most protocol-related security issues, like Brute-Force, Replay and Man-in-the-Middle Attacks for instance, have been solved successfully with Kerberos Version 5.
The implementation of Kerberos using the GSS-API, which offers generic and scalable security services, have been analyzed. Due to the session-oriented nature of the protocol, there is very often a counterpart for the corresponding function: initiate a security context - accept a security context, wrap a message - unwrap a message or apply a signature - verify a signature. The most critical and error-prone part of programming is the establishment of the security context itself. Within this section, most errors can occur. The reason for this sensitivity to errors resides in the fact that the applications have to contact the Key Distribution Center for the first time and several steps of the Authentication process are performed. That are in particular the client's request for a service ticket, the reply of the Ticket Granting Server containing the service ticket and the session key and finally the client's service request at the application server. Within these steps many failures could occur. These are for instance an invalid Ticket Granting Ticket, a clock skew between the communicating hosts that is too large or just the absence or a malfunction of the KDC.
Fortunately the GSS-API has an excellent way of providing information on the success or failure of a function using two status codes: one for routine or calling errors, specific to a particular GSS-API language binding and one for the underlying mechanism, that is for instance Kerberos.
For Microsoft Windows operating systems, the GSS-API cannot be used. Instead the SSPI is offered by Microsoft, which implements a similar generic API to application programmers. Unfortunately Microsoft's SSPI does not offer such a convenient way of reporting errors like the GSS-API. Even worse: it sometimes happened, when SSPI functions were called, that they never return. In this case it is a back-breaking work to track and fix errors in the programm. The reasons for this behavior were invalid mechanisms and malformed arguments passed to the functions. After locating and fixing these errors, the functions behaved well and carried out their corresponding tasks.


The Authentication Service Kerberos is not limited to reside within corporate networks, Intranets or any kind of Local Area Networks. G. Di Crescenzo and O. Kornievskaia considered in a paper a practical distributed setting where users within different Intranets (realms) are connected through the Internet and use Kerberos for secure group communication via multicast []. This can be accomplished using an efficient paradigm for crossrealm authentication that decreases the communication over the Internet, makes most operations local and reduces the workload of the involved components.
Another possible application for Kerberos in the near future could be its combination with the use of smart cards for initial authentication. This could solve one of the most problematic issues with Kerberos, namely the dependence on users to chose good passwords. The human brain is not designed for remembering random sequences of characters. But a piece of hardware, like a smart card, solves not only the problem of choosing poor passwords but also enables a storage of the sensitive cryptographic keys outside the host machine.

Appendix A
Glossary of Terms

Authentication Server (AS)
The Kerberos KDC (Key Distribution Center) is composed of two separate services, the Authentication Server and the Ticket Granting Server. They both provide similar services and are typically housed on the same machine. The difference is in the kind of tickets they issue. The Authentication Server gives out ticket granting tickets, which are used to request further tickets from the Ticket Granting Server. The Ticket Granting Server issues tickets used to gain access to a specific service.
Authenticator
Since tickets are visible on the network, they do not prove on their own the identity of a person, who wants to request for a service. The legitimate user and the application server, the user wants to gain access to, can obtain the session key to the corresponding ticket and encrypt information, such as a timestamp, using this session key. The application server is able to decrypt the authenticator and verify the request by comparing the timestamp and other information.
Credentials
In general, credentials are data, which are used to prove the identity of a person (e.g. username and password). In the context of Kerberos, credentials are issued by the KDC to a user in reply to a ticket request. That are in particular the ticket itself and a random session key.
Credentials Cache
When a user receives a reply from the KDC, the credentials (ticket and session key) are stored in a special file called credentials cache.
Delegation
Authorizing someone else to act on your behalf. Kerberos uses delegation by creating a special kind of ticket that identifies both the grantor and the delegate. A common case of delegation is the use of both forwardable and proxy tickets.
Key Distribution Center (KDC)
The Key Distribution Center is the trusted third party entity of a Kerberos environment and is used as the Kerberos ticket server. It is composed of the Authentication Server (AS) and the Ticket Granting Server (TGS). The KDC maintains a database of principals (users and services) and their associated secret keys. It is important to use a secure machine as the KDC. If someone gained access to the KDC, the entire realm could be compromised.
Principal
A uniquely named client or server instance that participates in a network communication.
Realm
In the context of Kerberos, a realm is the set of users and servers for which a given Key Distribution Center (KDC) is the authenticating authority. Realm names are composed of the realm name and its domain name. Each machine has a default realm and ticket requests from that machine will go first to the KDC for that realm. An example of a realm would be EXAMPLE.DOMAIN.COM.
Session Key
A key that is shared only between a user and a server for a given session. The session key is used to encrypt and decrypt the authenticator, as well as any data in the case of an encrypted session.
Ticket
A piece of data (token) that will help to verify the identity of a user to a given service. A ticket is issued by the KDC to the user in response to a ticket request. A ticket is opaque to the user. That is, it is encrypted in a key that the user doesn't have and can be decrypted only by the end server.
Ticket Granting Server (TGS)
The server that handles requests from clients for a ticket for use with a particular network server after principals obtain a ticket granting ticket (TGT).
Ticket Granting Ticket (TGT)
This is a special kind of ticket whose end server is the KDC. This TGT allows the user to access the KDC within the near future (normally 8 hours) to obtain tickets for use in applications without having to enter the password again. On Unix/Linux systems, the program KINIT is used to obtain the TGT. On Windows systems, the TGT is obtained during the login-procedure.

Appendix B
Establishing the Kerberos environment on Linux

B.1  Setup of the KDC

This section describes the configuring procedure to run a Key Distribution Center (KDC) on a Linux machine. As Linux distribution, the Redhat Enterprise Server was used.
At first, the krb5-server, krb5-workstation and krb5-libs packages have to be installed on this machine which will run the KDC. These were:
krb5-server-1.2.7-19.i386.rpm
krb5-workstation-1.2.7-19.i386.rpm
krb5-libs-1.2.7-19.i386.rpm


The file krb5.conf which is located in the /etc directory and the kdc.conf which is located in /var/kerberos/krb5kdc reflects the configuration for the KDC and are used to adjust the settings for the realm and domain-to-realm mappings.
The krb5.conf has the following structure: 1.16 [root@CBGUIBLD sachsigo]# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
[libdefaults] ticket_lifetime = 24000 default_realm = KRBTEST.BOEBLINGEN.DE.IBM.COM dns_lookup_realm = false dns_lookup_kdc = false
[realms] KRBTEST.BOEBLINGEN.DE.IBM.COM = kdc = cbguibld.boeblingen.de.ibm.com:88 admin_server = cbguibld.boeblingen.de.ibm.com:749 default_domain = boeblingen.de.ibm.com
[domain_realm] .boeblingen.de.ibm.com = KRBTEST.BOEBLINGEN.DE.IBM.COM boeblingen.de.ibm.com = KRBTEST.BOEBLINGEN.DE.IBM.COM
[kdc] profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults] pam = debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false
The krb5.conf file specifies the host addresses and ports of the KDC and defines a mapping from the domain to the Kerberos realm. Furthermore the ticket lifetime and the location of the logfiles can be specified.
The kdc.conf is used to define the location of the Access Control List (ACL), which specifies which access right a principal has on the KDC. The Keytab-file is an encrypted file in which the principals with their secret keys are stored. Within the section [realms] all Kerberos realms are listed with their different supported encryption types. A typical configuration for the kdc.conf is as follows: 1.16 [kdcdefaults] acl_file = /var/kerberos/krb5kdc/kadm5.acl dict_file = /usr/share/dict/words admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab v4_mode = nopreauth
[realms] KRBTEST.BOEBLINGEN.DE.IBM.COM =
master_key_type = des-cbc-crc supported_enctypes = des3-cbc-sha1:normal des3-cbc-sha1:norealm des3-cbc-sha1:onlyrealm des-cbc-crc:v4 des-cbc-crc:afs3 des-cbc-crc:normal des-cbc-crc:norealm des-cbc-crc:onlyrealm des-cbc-md4:v4 des-cbc-md4:afs3 des-cbc-md4:normal des-cbc-md4:norealm des-cbc-md4:onlyrealm des-cbc-md5:v4 des-cbc-md5:afs3 des-cbc-md5:normal des-cbc-md5:norealm des-cbc-md5:onlyrealm des-cbc-sha1:v4 des-cbc-sha1:afs3 des-cbc-sha1:normal des-cbc-sha1:norealm des-cbc-sha1:onlyrealm
After the configuration of these two files has been done, a new database has to be created, using the kdb5_util from a shell prompt: /usr/kerberos/sbin/kdb5_util create -s
The create command creates the database that will be used to store keys for the Kerberos realm. The -s switch forces creation of a stash file in which the master server key is stored. If no stash file is present from which to read the key, the Kerberos server (krb5kdc) will prompt the user for the master server password every time it starts.
Whenever there is a need to delete the database, the destroy command can be used: /usr/kerberos/sbin/kdb5_util destroy
The file /var/kerberos/krb5kdc/kadm5.acl is used as the Access Control List (ACL). This file is used by kadmin to determine which principals have administrative access to the Kerberos database and their level of access:
To create the first principal the following command can be used:
/usr/kerberos/sbin/kadmin.local -q äddprinc username/admin"
To view all principals, the listprinc command is to be used: /usr/kerberos/sbin/kadmin.local -q "listprincs"
To start the Kerberos KDC, the kadmin and the Kerberos 5 to 4 translator, the following commands have to be used: /sbin/service krb5kdc start /sbin/service kadmin start /sbin/service krb524 start
The krb5kdc is the process that issues tickets and is used for the Kerberos protocol. The kadmin process is for administrating the Kerberos database over network. This process must be run on the master KDC. The krb524 is just the Kerberos 5-to-4 ticket translator and is actually not needed if Kerberos v5 is installed on all participating hosts. Notice that the krb5kdc process has to be run as root, because it needs access to the keytab-file which should have read- and write-access only for root.
On all Unix derivatives and Linux there exists the programm kinit to obtain an initial ticket: kinit principal
The destroy command can be used to delete the cache and the credentials it contains.
With the command klist the credentials cache can be inspected, that is listing all tickets that are in the cache.

B.2  Setup of the Client

The krb5-workstation and krb5-libs packages have to be installed on the client.
The client has to be provided with a valid krb5.conf configuration file. Basically this is the same file as used by the KDC.
Using kadmin, host principals for the workstation can be added on the KDC.
addprinc -randkey host/test.example.com
The instance in this case will be the hostname of the workstation. The -randkey option to kadmin's addprinc command can be used to create the principal and assign it a random key. For hosts the random key is quite convenient because it can be ensured it has a good ßtrength".
After creating the principal, one can extract the keys for the workstation by running kadmin on the workstation itself, and using the ktadd command within kadmin
ktadd -k /etc/krb5.keytab host/test.example.com
With the ktadd command the key of the corresponding principal is randomized. Specifying -glob * means that ALL keys are randomized - including the master-key !!! If this happened, first the stash file has to be deleted and then the destroy command is used to delete the database and restore it again. So it is a good idea to make a dump from the database from time to time.

Appendix C
The particular functions of the GSS-API

After introducing the basic concept and functionality of the GSS-API in chapter 4, the most important functions that were used are listed with their input and output parameters and their usage within the Authentication Service Kerberos. The IBM-document "Security Server Network Authentication Service Programming" lists the functions for the z/OS implementation of the GSS-API []. The implementation for Linux does not differ very much, but some minor changes have to be regarded. The functions listed from here on refer to the Linux implementation of the GSS-API.
All GSS-API functions return two types of codes that provide information on the success or failure of the function []:
Major_status codes indicate a generic GSS-API routine error or calling errors specific to a particular GSS-API language binding. These could be the case when giving a routine an invalid mechanism or if an argument cannot be read or written or is just malformed.
Minor_status codes are returned by the underlying mechanism, that is for instance Kerberos. Typical errors result from invalid TGTs or insufficient access to the credentials cache.

All GSS-API functions can be separated into four different categories:
  1. Credential management
  2. Context-level calls
  3. Peer-message calls
  4. Support calls

C.1  Credential management

gss_acquire_cred
This function allows an application to obtain GSS-API credentials. The application can then either initiate or accept a security context. 1.16 OM_uint32 gss_acquire_cred ( OM_uint32 * minor_status, gss_name_t desired_name, OM_uint32 time_req, gss_OID_set desired_mechs, gss_cred_usage_t cred_usage, gss_cred_id_t * output_cred_handle, gss_OID_set * actual_mechs, OM_uint32 * time_rec )
Input Parameters
desired_name
specifies the principal name to be used for the credential.
time_req
Specifies the number of seconds that the credential remains valid. If zero is specified the default lifetime is 2 hours.
desired_mechs
Specifies the desired security mechanisms for use with the credential, for instance Kerberos.
cred_usage
Specifies if the credential can be used only to initiate security contexts or only to accept security contexts or both .


Output Parameters
output_cred_handle
Returns the handle for the GSS-API credential.
actual_mechs
Returns the set of mechanism identifiers for which the credential is valid.
time_rec
Returns the number of seconds the credential remains valid.
gss_inquire_cred
This function returns information about a GSS-API credential to the calling application. 1.16 OM_uint32 gss_inquire_cred ( OM_uint32 * minor_status, gss_cred_id_t cred_handle, gss_name_t * name, OM_uint32 * lifetime, gss_cred_usage_t * cred_usage, gss_OID_set * mechanisms )
Input Parameters
cred_handle
Specifies the handle for the GSS-API credential.


Output Parameters
name
Returns the principal name associated with the credential.
lifetime
Returns the number of seconds the credential remains valid.
cred_usage
Returns one of these values describing how the application can use the credential:
mechanisms
Returns the set of security mechanisms supported by the credential.

C.2  Context-level calls

gss_init_sec_context
This function initiates a security context for use by two different applications. 1.16 OM_uint32 gss_init_sec_context ( OM_uint32 * minor_status, gss_cred_id_t cred_handle, gss_ctx_id_t * context handle, gss_name_t * target_name, gss_OID mech_type, OM_uint32 req_flags, OM_uint32 time_req, gss_channel_bindings_t input_chan_bindings, gss_buffer_t input_token, gss_OID * actual_mech_type, gss_buffer_t output_token, OM_uint32 ret_flags, OM_uint32 * time_rec )
Input Parameters
cred_handle
Specifies the handle for the GSS-API credential used to initiate the security context.
target_name
Specifies the name of the context acceptor.
mech_type
Specifies the desired security mechanism. For instance gss_mech_krb5 for Kerberos v5 mechanism.
req_flags
Specifies a bitmask containing independent flags representing requested GSS services.
time_req
Specifies the desired number of seconds that the security context remains valid. Specifying zero results in a default lifetime of 2 hours.
input_chan_bindings
Specifies the bindings describing the communications channel to be used between the communicating applications.
input_token
Specifies the token received from the context acceptor.


Input/Output Parameters
context_handle
Specifies the context handle for the context.


Output Parameters
actual_mech_type
Returns the security mechanism to be used with this context.
output_token
Returns a token to be sent to the context acceptor.
ret_flags
Returns a bitmask containing independent flags indicating which GSS services are available for the context.
time_rec
Returns the number of seconds the context remains valid.




gss_accept_sec_context
This function accepts a security context created by the context initiator. 1.16 OM_uint32 gss_accept_sec_context ( OM_uint32 * minor_status, gss_ctx_id_t * context handle, gss_cred_id_t * acceptor_cred_handle, gss_buffer_t input_token, gss_channel_bindings_t input_chan_bindings, gss_name_t * src_name, gss_OID * mech_type, gss_buffer_t output_token, OM_uint32 ret_flags, OM_uint32 * time_rec, gss_cred_id_t * delegated_cred_handle )
Input Parameters
acceptor_cred_handle
Specifies the GSS-API credential for the identity claimed by the context acceptor. The credential must be either an ACCEPT type credential or BOTH type credential.
input_token
Specifies the token received from the context initiator.
input_chan_bindings
Specifies the bindings describing the communications channel to be used between the communicating applications.


Input/Output Parameters
context_handle
Specifies the context handle for the context.


Output Parameters
src_name
Returns the authenticated name of the context initiator.
mech_type
Returns the security mechanism that the context was established with.
output_token
Returns a token to be returned to the context initiator.
ret_flags
Returns a bitmask containing independent flags indicating which GSS services are available for the context.
time_rec
Returns the number of seconds the context remains valid.
delegated_cred_handle
Returns the credential handle for the delegated credentials received from the context initiator.

C.3  Peer-message calls

gss_wrap
This function cryptographically signs and optional encrypts a message. 1.16 OM_uint32 gss_wrap ( OM_uint32 * minor_status, gss_ctx_id_t context handle, int conf_req_flag, gss_qop_t qop_req, gss_buffer_t input_message, int * conf_state, gss_buffer_t output_message, )
Input Parameters
context_handle
Specifies the context to be associated with the message when it is sent to the partner application.
conf_req_flag
Specifies the requested level of confidentiality and integrity services.
qop_req
Specifies the requested quality of protection for the message.
input_message
Specifies the message to be wrapped.


Output Parameters
conf_state
Returns the level of confidentiality that was applied to the message.
output_message
Returns the wrapped message.

C.4  Support calls

gss_import_name
This function converts a printable name to the internal GSS-API format. 1.16 OM_uint32 gss_wrap ( OM_uint32 * minor_status, gss_buffer_t input_name_buffer, gss_OID input_name_type, gss_name_t output_name, )
Input Parameters
input_name_buffer
Specifies the buffer containing the name to convert. The value field contains the address of the name and the length field contains the length of the name.
input_name_type
Specifies the object identifier for the type of printable name.


Output Parameters
output_name
Returns the name in the GSS-API internal format.

Appendix D
The CD-ROM

This Bachelor Report includes a CD-ROM. The following directories can be found:
/krb_gss Sample Kerberos Client- and Server-Program using the GSS-API
The programs are written in the programming language C
and are designed to run on a Unix/Linux system
/krb_sspi Sample Kerberos Client- and Server-Program using SSPI
The programs are written in the programming language C
and are designed to run on a Windows32 system
/sequence Sequence Diagrams of the Kerberos Authentication Process
at the CIMOM OpenPegasus 2.3
/tex The Tex-files of this Report, including all graphics and a PDF-File
1.44
Declaration
I declare within the meaning of section 25(4) of the Examination and Study Regulations of the International Degree Course Information Engineering that: this Bachelor Report has been completed by myself independently without outside help and only the defined sources and study aids were used. Sections that reflect the thoughts or works of others are made known through the definition of sources.
All hyperlinks that are mentioned in this Bachelor Report have been verified on June, 3rd 2005.


Hamburg, 8th of June 2005




--------------
Igor Sachs

Footnotes:

1http://www.gartner.com
2It is assumed that Kerberos security is implemented in all applications that are used
3http://www.dmtf.org
4http://www.rational.com/uml/documentation.html
5http://www.openpegasus.org
6http://www.opengroup.org/snia-cimom
7The term kerberized service is used to indicate that the Kerberos security has been implemented within this service.

File translated from TEX by TTH, version 3.70.
On 05 Nov 2005, 10:57.