Security considerations over distributed environment using DCE security framework

Most of the businesses today are running over a distributed environment. Security and integrity of the data flowing over the network is, therefore, of utmost importance for the business units. The DCE security framework essentially does the same for such business needs. Most of the present day distributed environment based business services are using the basics of DCE security. Primarily the DCE security service, with additional new services and facilities, is based on the Kerberos system. This article is targeted to understand the basic concepts and implementation of security mechanisms being used in distributed environment and how the whole idea of DCE security is related to Kerberos.

Share:

Avadh N. Pandey (avadhpandey@in.ibm.com), Software Engineer, IBM

Photo of Avadh N. PandeyAvadh N. Pandey works as a Level 3 Support Engineer for IBM DCE and TXSeries since 2008. He graduated from the Indian Institute of Technology, Roorkee in 2007. His areas of interest include UNIX systems and networking.



Jithesh Moothoor (jmoothoo@in.ibm.com), Staff Software Engineer, IBM  

Jithesh Moothoor Jithesh Moothoor works as a Level 3 support engineer for IBM DCE and TXSeries products since 2006. His areas of interest include high-performance computing, cloud computing, and UNIX systems. You can read one of his articles on cloud computing in universities.



15 June 2010

Also available in Chinese

Introduction

Develop skills on this topic

This content is part of a progressive knowledge path for advancing your skills. See AIX security: Learn the basics

The idea of security starts with our own local operating system (OS) environment. An isolated machine which is not connected to the network is more secure than the one connected to the network. In a network, there is no common point of control which regulates or governs the resources (machines or users) of the network. An operating system's protection ends at the network. All one can see is a stream of packets over the network. This makes it very possible for a fake user to imitate as a valid user. If no security measures are in place, fake messages would be indistinguishable from real messages.

One can put the security measures only after establishing the authenticity of the user who is sending the messages. The general approach to security considerations starts with authenticating the user, commonly with username and password. The password is the entity that establishes the authenticity of the user. Username can be known to more than one person but the password is known only to the legitimate authorized person.

Distributed environment security implements an advanced and complex security model as shown in Figure 1. All the security activities are centralized in the security server. The security server does the same task for the network as what is done by the operating system for the local system.


A quick overview of DCE security model

In DCE, the security server is the central point of control which governs the security activities over the network. The security server daemon uses MIT Kerberos to manage authentication. Using this authentication service with DCE, RPC provides data availability and data privacy to users. All the clients/servers trust the security server for authentication and authorization of the messages running over the wires in the network. DCE also provides the way to verify the security server itself.

First of all, a user must log in to DCE to enjoy the services provided by DCE. This login process happens through the security server. The user supplies a secret key (password) to the security server to prove its identity. This secret key is known only to the user and the security server. Once the security server confirms the identity of the user via secret key, the login process of the user into the DCE is completed. This is a one time process and need not be repeated every time until the user itself logs out of the DCE. This process is also known as single login. Thereafter, whenever the user wants to access any DCE service, it asks the security server for a security certificate. This certificate acts as a credential of the user to prove its authenticity to any machine in the network. The user then passes the certificate to the server which is hosting the DCE service required by the user. The server takes the call and examines the certificate and decides whether the user is authorized to enjoy this service. If yes, then call is accepted and processed. Otherwise, the call is rejected.

Figure 1.Basic DCE security model
Illustration of a basic DCE security model

Common terminology used in distributed security

The following are a few of the terms that we will come across frequently in the article:

Authentication: It is the process of establishing the identity of the user. Authentication verifies the claim of a user of its identity. The best example to understand is the login process. Verifying the username and password is an act of authentication.

Authorization: Once the user is authenticated, it is checked for what all resources and services it can enjoy. This is called an authorization.

Integrity: Only an authorized user is permitted to modify the messages/data over the network. Once the message is created by the user, it should not get modified on its way to the destination. This check of message for non-alteration is termed as an integrity check.

Signature: Whenever a user sends a message over the network, it signs the message. This signature is a means of verifying that the legitimate user is the author of this message.

Key: Key is a means of converting a plain-text into cipher-text and vice versa. Mathematically, it is a parameter which determines the functional output of an algorithm.

Cryptography: This is a process of converting a message into a form (cipher-text) that makes it nearly impossible to convert it back to the original message, until we have the key which was used to convert it into cipher-text. It is one of the widely used methods to prohibit unauthorized access to the data over the network.

Cell: A Cell is defined as a group of users, clients or servers which share common DCE services.

Principal: A principal can represent anything from users, clients and servers to cells.

Access Control List (ACL): An ACL is a data structure that associates to a set of principals a list of permissions for a service. It describes the set of principals that can access and utilize a service and the type of access allowed.

Authenticated RPC: In DCE, an RPC call should succeed only when the identity of the calling client and the called server is confirmed. This surety is verified via Authenticated RPC by adding extra fields to the messages/packets being exchanged between the server and the client.


General distributed security techniques

In this section, we will discuss very briefly two of the most important techniques being used in distributed environment for security.

  1. Secret key cryptography
  2. Public key cryptography

Although DCE is currently based on secret key system, further in the article we will come to know how DCE exploits these techniques and augments them to provide a much more secured environment.

Secret key cryptography

Secret key cryptography is one of the most important technologies in distributed systems security. It involves usage of a secret key which is shared by the server and the client. Same secret key is used to encrypt and decrypt the messages exchanged among them. Because of the usage of same key for encryption/decryption, it is also termed as symmetric cryptography.

Public key cryptography

Public key cryptography, on the other hand, uses a pair of keys: one for encryption and one for decryption. Since a pair of keys is involved, it is also called an asymmetric cryptography. A user has a pair of keys: public key and private key. The public key is known to everyone while the private key is kept secret. Messages intended for the user are encrypted using his/her public key. These messages can only be decrypted by using the corresponding private key. Rivest-Shamir-Adleman (RSA) system is the best known example of this kind.


What is Kerberos?

Historically, Kerberos is an authentication service developed by the Massachusetts Institute of Technology as a part of Project Athena. Kerberos was designed based on secret key cryptography and using trusted third party authentication. All the clients/servers in the network trust a third party called a key distribution center (KDC) for the secure communications. KDC is responsible for key distribution and all the authentication processes which may take place in the network.

Kerberos essentially consists of a complex process called Kerberos authentication protocol (KAP). Whenever two parties want to authenticate each other, they do so by following KAP. This protocol actually contains a series of messages containing secret keys and other information that help clients and servers identify each other securely. The KAP involves three parties: client, server and KDC. Figure 2 below shows the working of KAP in an illustrative manner:

Figure 2. Kerberos authentication protocol (KAP)
Illustration of the Kerberos authentication protocol (KAP)

The description of Figure 2 is as follows:

  1. A client starts with sending a message to KDC to request a new ticket. This specifies the identity of the client as well as the server which client wishes to connect to. KDC creates a ticket by generating a random session key (K.session) which contains the identity of the client and some other useful information.
  2. KDC then encrypts the ticket and sends the result to the client.
  3. Receiving the reply from KDC, client then decrypts the message using its own secret key. The client retains the session key and forward the ticket to the server as it is.
  4. Receiving the ticket from the client, server then decrypts it using its own secret key. This way the server gets the identity of the client and the session key.

The protocol described above is the very basic of KAP and its actual implementation in DCE authentication. The tickets contain all the necessary information for the client/server to trust upon each other.

The session keys generated during this authentication exchange can be used for all the future correspondences among client/server and KDC. It can be used to authenticate the messages, to provide integrity, as well as encryption key to ensure confidentiality of the data. Though the use of a trusted third party, Kerberos, is very effective and manageable, it comes with a trade off. In Kerberos, KDC is the single point of failure for the whole network.


How DCE augments Kerberos

DCE implements three network services effectively. These are:

  1. Authentication service
  2. Privilege service
  3. Registry service

The authentication service is the same as the KDC in Kerberos. The other two services are augmentation or enhancements to Kerberos. Together with these three services in place, DCE enforces a very effective security mechanism in distributed environment. Before we go into the details of each of these services, you should keep in mind that all these services are implemented by a single RPC server, called a security daemon or secd.

Authentication service

The DCE authentication service is the key distribution service in the Kerberos model. It provides ticket and session keys. But authentication service in Kerberos is just a component of key-distribution service. DCE enhanced this terminology with two kinds of ticket service.

  1. Service ticket (STkt)
  2. Ticket-granting ticket (TGT)

A ticket is an encrypted message that carries a session key and some other server/client identifying information.

Service ticket (STkt)

In DCE, the service ticket is a data structure that authentication service uses to pass the client identity and session key to the server. A client must obtain an STkt to authenticate with server. It is called service ticket because it is used by clients to obtain services.

The service ticket, which is authenticating with server, contains two parts illustrated below in Figure 3. The first part is the principal name of the target server. The second part of the ticket is not visible to the client. It is encrypted under the secret key of the target server. The encrypted portion of the STkt contains the name of the client, a session key generated by authentication service that client and server can use, and a lifetime of STkt.

Figure 3. Structure of a service ticket
Illustration of the structure of a service ticket

Ticket-granting ticket (TGT)

In DCE, The TGT is used for obtaining service ticket (STkt). TGT carries session key for use between the client and authentication service. Basically, TGT contains two parts illustrated below in Figure 4. The first part contains authentication service as the server and the second encrypted portion contains ticket lifetime and TGT session key. TGT session key is the most important part of a TGT. This key is generated by the authentication service and is shared between the client and the authentication service for all future communications.

The TGT also serves a place where the authentication service can store any information it will later need for servicing STkt request from this client.

Figure 4. Structure of ticket-granting ticket
Illustration of the structure of ticket-granting ticket

Authentication service working model - Using TGT and STkt

Here, in Figure 5 below, it is explained how TGT and STkt are used in DCE authentication services.

Get the TGT containing session key for use with the authentication services

Client needs shared session key between itself and the authentication services for the future communication with authentication services. To get the shared session key, client makes a TGT request (Authenticated RPC) to the authentication service. The client request message mainly includes the client principal name, and the desired lifetime of the ticket.

The authentication service creates a TGT. The TGT contains the identity of the client, a randomly generated TGT session key and the lifetime of the TGT. The entire TGT is encrypted with the secret key of authentication service. The authentication service make a response message to the client containing the TGT, a copy of TGT session key and other information. To reach the intended client, this response message is encrypted using the client secret key.

The Client decrypts the message from the authentication service using client secret key. At this point, client has the session key that client can use for authenticating itself to the authentication service.

Figure 5. Authentication service working model
Illustration of an authentication service working model

Get the STkt containing session key for use with the security server

The main objective of STkt request is to get a new session key for the client to use with the security server. Client makes an STkt request via authenticated RPC to authentication service to get a new session key for the client to communicate with any server. This message includes the targeted server name and the TGT. This message's integrity is protected via an encrypted checksum using the session key between the client and authentication service.

The authentication service extracts the TGT from the request and decrypts it using its own secret key and validates/verifies the request. After checking the identity of client request, the authentication service constructs the STkt that would allow client to authenticate with target server. The STkt response message includes first the session key for use between the client and targeted server and then also the identity of the client. The STkt is then encrypted using the target server secret key. So target server can decrypt the STkt request using its secret key. The authentication service then encrypts the STkt and copy of the session key using the TGT session key and sends the message back to the client.

The client already has the TGT session key obtained from the previous TGT request. So the client decrypts the message using this copy of TGT session key. Hence, client gets the shared session key from STkt for it to use with targeted server.

Client communicate to server with session key

The client makes an RPC call to the server, and the STkt containing the session key passed as a part of the RPC protocol. The server RPC runtime verifies and validates the STkt. If it is a valid request from client, it extracts the session key from the STkt using server secret key. Here, client has been authenticated and server knows the shared session key to communicate to this particular client.

Later, the client receives the call result from the server. The client decrypts the result using the shared session key. At this point both client and server have copies of shared session key. Using this session key, client and server can safely communicate with each other.

Privilege service (authorization service)

The whole purpose of the authentication service is to securely exchange the client identity and session key to the server to which the client wants to authenticate. Here, the privilege service of DCE enhances the authentication service by adding the concept of privilege attribute certificates (PAC). DCE security service use PACs that describe a client's security attributes. These security attributes are the principal identity and the group information. In DCE privilege service, the server determines whether a given client is authorized to perform a specific operation with the help of information obtained from PACs. Usually PAC carries the authorization information that is used to make access-control decision.

Components of PAC

  • Authentication flag: This flag shows whether this PAC was authenticated by DCE security.
  • DCE cell UUID: The UUID of cell in whose registry the principal is registered.
  • Principal UUID: The UUID of the principal whose security attributes are described in PAC.
  • Primary group UUID: The UUID of the group to which this principal primarily belongs in the same cell.
  • Secondary group UUIDs: The UUIDs of all the groups to which this principal belongs in the same cell.
  • Foreign group UUIDs: The UUIDs of the groups registered in remote cells to which this principal belongs.

The privilege service uses PTGT and PSTkt for exchanging PACs. In short, PTGT and PSTkt are TGTs and STkts respectively, which carry PACs. Below, Figure 6 describes the PTGT and PSTkt structure. It is evident from the figure that PTGT looks like the TGT while the PSTkt looks like the STkt. However there are two significant differences:

  1. Privilege tickets also contain a client PAC; and,
  2. Privilege tickets specify privilege service as the client in contrast to TGT and STkt which specify the real client.
Figure 6. Structure of PTGT and PSTkt
Diagram of the structure of a PTGT
Diagram of the structure of a PSTkt

The following section describes the working of the privilege service in DCE with the help of the figure 7.

Getting the PTGT

The client starts with sending a TGT to the authentication service which in turn provides the client with an STkt and a session key. The STkt and the session key are used by the client to talk to the privilege service. Client sends a PTGT request to the privilege service containing the STkt and the session key.

The privilege service decrypts the request and gets a copy of the session key and confirms the identity of the client. The privilege service then generates a new session key, PTGT session key. Meanwhile, PAC is also generated by the privilege service after getting all the information for this client from the registry service. Now the privilege service copies this information into a TGT and encrypts it using the authentication service's secret key. This TGT is a PTGT as it contains privileged information. The privilege service now sends back the response to the client. This response message is encrypted under the session key passed by the client to the privilege service.

The client gets the response message, decrypts it, and obtains the PTGT and PTGT session key.

Getting the PSTkt

The client now has everything it needs to get PSTkt from the authentication service, PTGT and PTGT session key. The client sends a PSTkt request to the authentication service. This request message contains the name of the server (from which the client wants to get service) and a copy of the client's PTGT.

The authentication service gets the PSTkt request and decrypts it using its secret key. After confirming the associated fields in the PSTkt request, the authentication service proceeds to generate an STkt. It copies the PAC from the PTGT into STkt, sets the client as privilege service and generates a new session key. This session key will be used by the target server to confirm the identity of the client. As this STkt is containing PAC, it becomes PSTkt. Moreover this PSTkt is encrypted using the target server's secret key. The authentication service constructs the response message containing the PSTkt and a copy of the new session key. The whole message is encrypted using the PTGT session key and is sent back to the client.

The client receives the response, decrypts it and obtains the PSTkt and the session key to be used with the target server.

Figure 7. Privilege service working model - Using PTGT and PSTkt
Diagram of a privilege service working model using PTGT and PSTkt

Using the PSTkt

Client now makes an RPC call to the target server sending it the PSTkt containing session key and the PAC. The target server receives the PSTkt and decrypts it using its own secret key. To be assured that the PAC was really issued by the privilege service, the target server checks and confirms that the client specified in the PSTkt is indeed the privilege service. Finally the server then goes ahead and executes the RPC call and returns the results back to the client.

Registry service

The registry service is the third network service being offered by DCE security. Registry service maintains a database of all the principal, group and account information for a cell. This information is used by the first two services (authentication service and privilege service) and the DCE APIs. It primarily consists of the following information:

  • Cell information: This includes cell name, cell UUID, version of the registry service running and the bounds on the UNIX® IDs that the registry can assign to principals. It also stores the information about the cell as a whole, such as cell-wide security policy, ticket lifetimes, etc.
  • Principal, group and organization information: This includes a list of all the principals, groups and organizations (PGO) for the cell. For each PGO entry, corresponding UUID, name and UNIX ID are stored.
  • Account Information: DCE accounts are just like any other local account on the OS. A user must log in to the DCE account to enjoy the services provided by DCE. Each account represents a principal and a list of the groups to which the principal belongs. The account information consists of two parts: network and local system. Network part contains the information required to acquire tickets and other services (e.g. it includes the principals secret key). Local part contains the information such as the home directory and the shell to run. It is also responsible to support network-wide single login, which means that logging into DCE account automatically logs the user into all the associated local accounts too.

How DCE security differs from Kerberos

As seen from the previous details, the authentication service being implemented by the DCE is very similar to the process followed in Kerberos protocol. This similarity is a result of the fact that DCE authentication service was built upon the source code for Kerberos V5. Though DCE Security is a superset of Kerberos V5, it differs from Kerberos in lot many ways. The most noted one being the privilege service and registry service, which are provided only by DCE. In addition, some of the DCE facilities, like authenticated RPC and DCE, ACLs are not provided by Kerberos. Moreover, the DCE authentication service uses DCE RPC, in addition to UDP/IP, for communications over the network. This is in contrast to the fact that Kerberos uses only UDP protocol for communications.


Conclusion

This article is primarily targeted to understand the background of distributed systems security. We started with a note on the importance of security in a distributed environment and an overview of DCE security model. It then covered the general techniques being used in field of distributed security followed by details on Kerberos. Finally, this article explained in detail about the working and implementation of DCE security and a small note on how it differs from Kerberos. This article can be taken as an initial approach towards a deeper understanding of distributed security using DCE.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=495369
ArticleTitle=Security considerations over distributed environment using DCE security framework
publish-date=06152010