(Based on Chapter 10 of Tanenbaum, Distributed Operating Systems -- references are to this book.)
OSF's DCE builds a distributed system on top of existing operating systems.
Thus gives users a way of introducing distributed services without discarding their current operating systems.
DCE is a suite of distributed services rather than a distributed operating system.
DCE was developed by the Open Software Foundation (OSF), a consortium of computer manufacturers (HP, DEC, IBM, others) organized to develop standard (corss-platform) computing solutions.
OSF was responsible for developing the OSF/1 operating system, which formed the basis for the Digital Unix OS we are running on our systems.
OSF is now known as The Open Group; their Web site is at
http://www.opengroup.org. There is an overview of DCE at
http://www.opengroup.org/dce/
DCE was originally developed to run on top of Unix, but has now been ported to many different operating systems, including Windows NT.
You can download the entire sources code for DCE from the Open Group Web site. (Current version is 1.2.2) Careful -- it's about 170 MB. However, you probably can't do anything with the source that you download. It needs to be ported to any particular operating system you want to run it on, and to get the runable versions for any particular OS, you have to buy the executables (usually from the OS manufacturer).
Users, machines, and other resources of a DCE system are grouped to form a cell--administrative units.
(Figure 10-1 page 523)
Lowest layer, hardware, and then operating systems. DCE requires a thread implementation to run. If the underlying OS does not support threads, then there is a DCE threads package that can be used. The next layer is an RPC layer, which includes authentication services so that authenticated RPC can be used.
On top of the RPC services are the other services that DCE provides. Similar to Sun RPC using an interface definition language (IDL). Look at Fig. 10-13 and 10-14.
A service to keep the clocks on the different machines "almost synchronized"--difficult to be exact.
Working off a common clock is one of the distinguishing characteristics between tighly-coupled multiprocessors and loosely coupled distributed systems.
At least want to get within a few seconds (distributed make example).
Another use for "alomost synchronization" -- a security / authorization system may give a user access to a resource (file, etc.) to a limited period of time. (If they had access forever, then they might still have access even after you wanted to cancel their access.) So the period of time might be on the order of minutes, and so a timer synchronized to an order of seconds would be useful.
A time clerk synchronizes using the set of time servers on a on its LAN using intersection and averaging as previously discussed.
To keep track of the various resources available on the system -- printers, servers, data, etc. It's possible to interrogate the directory service by describing the service you want (and not just by the exact name of what you're looking for).
There are two levels of directory naming in DCE: cell level and global level. A cell level name begins with the prefix /.: A global name starts with the prefix /... In a global name, next comes a cell name. The next thing (for either a cell or global name) is a resource name.
Both the cell name and the resource name can be in either X.500 (pronounced X-dot-500) format or DNS (Internet) format.
X.500 directory service is a standard directory format Names consist of attribute = value pairs which uniquely identify the cell or resource. So a global name to identify a certain person might be
/.../C=US/O=WPI/OU=CS/TITLE=PROF/OFFICE=FL236/SURNAME=WILLS/
The "C" attribute is for country, the "O" attribute is for organization,
the "OU" attribute is for organizational unit (i.e., department). The
other attributes are pretty obvious. A user (or an application) can just
provide some of the attribute value pairs, and if that's enough to uniquely
identify the resource, then the directory will return location information
for the resource. So a request that just indicated
/C=US/O=WPI/OU=CS/SURNAME=WILLS/ would be enough to identify me.
DNS style naming is just the usual Internet style naming:
/.../cs.wpi.edu/subsys/file
If a cell reference is made, it is handled by the cell's Cell Direcotry Service (CDS). If it's a global reference, it's handled by the cell's Global Directory Service (GDS) via the Global Directory Agent (GDA).
The GDS contacts the appropriate cell's CDS, and resolves the name that way. In this way, an uniform global (really global) naming scheme is provided.
Based on Andrew File System. Same basic idea.
Allows users to be securely identified even in remote parts of the distributed system. The purpose of securely identifying users is to permit (or deny) access to system resources depending on the user's identity. DCE's security service is based on Kerberos, a security system developed at MIT.
Overview: A user logins into to a local client (local to the user's home cell). The local client contacts the cell's Authentication Server (in a secure manner) which issues tickets and Privilege Attribute Certificates (PAC) to the user, which the user uses to establish its identity to other servers in the distributed system. These elements are used so that a client and a server can authenticate their identity to each other to perform a secure RPC.
It is a principle of the DCE security system that passwords or other security information is never passed over the network in unencrypted form. Contrast this with other systems. For example, if you do an rlogin to another system, your password is passed over the network in unencrypted form. Not real secure, huh?
Tickets and PACs are data structures identifying the user, encrypted so that they can be decrypted only by designated servers. A ticket contains a user's username (in text) and the PAC contains a user's uid and gid's (as numbers).
In the security service, only private key encryption is used. In both kinds of encrytion, there are numerical values (called keys) which are parameters to the encryption and decryption algorithms. In general there are two keys, and encryption key Ke and a decryption key Kd. So the encryption and decryption sequence works like this:
encrypt(Ke, plain-text-message) = encrypted-message, and decrypt(Kd, encrypted-message) = plain-text-message.
Private key encryption: In private key encryption, both Ke and Kd are kept secret (and in fact may be equal). So this method can only work when the two parties to the conversation has previously communicated a key.
Public key encryption: In public key encryption, the encryption key Ke is made public, whereas the decryption key Kd is kept private. There some fancy mathematics behind the algorithm that allows you to make the encryption key public without compromising the security of the decryption key. So anyone can encrypt messages using the public encryption ley, but nobody can decrypt it except the intended recipient (assuming that the recipient has been successful in keeping the decryption key private.
In DCE, every server has a key for a private key encryption algorithm. This key is known only to the server and to the authentication server. Each user also has a private key, which is generated for the user by the login process, which takes the password and applies a one-way function to it to obtain the user's secret key. (A one-way function means that it is computationally infeasible to obtain the input of the function from the output.)
A few more concepts necessary to understand the DCE security service.
checksum: a checksum is a numerical value calculated from the contents of a message. The idea is that is the message is changed, the checksum will be changed, too. (Checksums in this form are used for error detection -- a parity bit is one example of this kind of checksum.) A crypto-checksum is one which involves encryption, so that given a message and a checksum, it's not computationally feasible to create a different message that would give the same checksum. So if you receive a message with a crypto- checksum, and then re-calculate the crypto-checksum and it's the same as the crypto- checksum that you received with the message, then you can be assured that you have received the same message as was originally sent. DCE uses the MD-5 (message digest 5) crypto-checksum algorithm.
timestamp: many of the messages used by DCE to exchange keys carry a timestamp or a deadline. This is so that an old key cannot be re-used by someone trying to attack the system. For timestamps to work, of course, there must be "almost-synchronized" clocks. Note that almost synchronized is good enough for this application
Sample message: The explanation of how the DCE security service works, and how secure RPC is implemented, uses many messages of the following form. Here A represents the Authroization Server, and C representes the Client (user), and KA and KC, respectively, are their private keys.
C <- A: {K1, {K1, C}KA}KC
Here's what this means: this describes a message from the Authentication Server to the Client. The overall message is encrypted by the client's private key. The message consists of two parts - K1, and K1, CKA. K1 is just a new key. K1, CKA is another message, encrypted with the Authentication Server's private key. The contents of this sub-message are the new key K1 and C, the identity of the client (the user's text username).
Since the client is receiving this message, the client can decrypt the overall message and obtain the value of K1. It can't do anything with K1, CKA, since the client doesn't know KA. So what does the client do with this message? It sends K1, CKA (without further encryption) to A; A can decrypt it and obtains the value of K1. Now C and A both know the value of K1, and can use it to exchange secure messages, and K1 was securely transmitted over the network. Also, since C was able to decrypt the original message, A is confident about the identity of C -- no one else could have decrypted this message.
Figure 10-27, page 560, gives a complete set of messages to establish authenticated RPC.