Distributed Security

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Whenever someone discusses distributed computing, one of the first questions raised is, "Can it be secure?" Computer security frequently consists of two parts: authentication and access control. Authentication involves the verification and identification of a valid user. Access control strives to prevent unwanted tampering with data files and system resources. In an isolated, centralized, single-user system such as a PC, security is accomplished by locking up the room where the computer is stored and locking up the disks. Thus, only the user with the key to the room and disks may access the system resources and files. This accomplishes both authentication and access control. The security is only as good as the keys that lock the computer and the room.

In isolated centralized systems with multiple users, security is a bit more complex. In this scenario, authentication involves the verification and identification of a valid user and is usually managed by some type of password and user identification combination. Control of access to the files, data, and resources to prevent unwanted tampering is generally accomplished through capabilities or access lists and is managed as part of the operating system.

In this chapter, we see that like the previous scenarios, authentication and access control are once again our primary concerns when we connect our system to a network of other systems. While authentication and access control are thought of as tasks to be taken care of by the operating system, distributed access control may be handled by the routers and application software. Furthermore, since we are communicating using an outside shared resource (the network), we also need to secure the content and verify the originator's identity of the information that we are sending across this network by employing cryptography and digital signatures respectively.

While distributed security continues to be a very active research area, there is enough current technology to understand the basis of the security problem and various solutions available to a distributed operating system. In Section 11.1 we examine the various types of cryptography, including their use for digital signatures. Section 11.2 presents two common approaches to authentication, and Section 11.3 presents various methods of access control in distributed systems. The methods discussed in this chapter are used in addition to the necessary authentication and access control techniques usually employed for centralized systems, some of which were presented in Chapter 8.

11.1 Cryptography and Digital Signatures

While computer users may occasionally wish to secure information by means of encryption on isolated computer systems, many users desire and require encryption for communication across networks. Encryption involves encoding data using a key in such a manner that an eavesdropper cannot easily read the data. This encrypted data is referred to as ciphertext while the original data is referred to as plaintext. The process of going from ciphertext to plaintext is referred to as decryption. Figure 11.1 depicts the classic cryptography couple, Alice and Bob, communicating by means of the Caesar Cipher. The Caesar Cipher is a simple cryptosystem that rotates the data; in this case, two letters forward. Obviously, this is not a very secure encryption algorithm and could be decoded with a cereal box decoder ring. The most popular means for measuring the security of a encryption algorithm is that is computationally secure. An encryption algorithm is computationally secure if the system cannot be broken by systematic analysis with available resources. There are two general categories of encryption: private-key and public-key encryption. In addition to encrypting an entire message, both types of encryption can be employed to sign a document digitally. Section 11.1.1 examines symmetric encryption and uses DES as an example. Section 11.1.2 examines asymmetric encryption and uses RSA as an example. Both examples presented are computationally secure when using a significantly long key.

Figure 11.1: Alice and Bob Use Cryptography.

11.1.1 Symmetric Encryption

Symmetric encryption refers to encryption algorithms where the encryption and the decryption algorithm utilize the same key. Specifically:

   E(p,k)=C & D(C,k)=p
   where 
   E = encryption algorithm, 
   D = decryption algorithm,
   p = plaintext (original data),
   k = encryption key and
   C = ciphertext.

Since the same key is utilized to encrypt and decrypt the data, this key must be kept private. This type of encryption is also referred to as secret-key encryption as well as conventional encryption. One of the difficulties in using such a system is, of course, communicating the key! One simple way to overcome the key exchange problem is first to use public-key encryption to exchange keys and then employ private-key encryption. Detail Box 11.4 describes one public-key encryption method for exchanging keys; specifically, the Diffie-Hellman key exchange algorithm. This is also very practical since DESencryption typically operates at approximately 45,000 kbps and public-key cryptography typically operates at 20 kbps. We now examine the most popular private-key encryption algorithm, DES (pronounced DEZ), which was declared the U.S. standard by the National Institute of Standards and Technology (NIST)1 in 1977 [NIST77]. Other private-key encryption algorithms include IDEA [Lai92] and Skipjack (used in the clipper chips) [NIST94a].

Data Encryption Standard

DES was implemented as a standard in 1977 and is reaffirmed every five years, typically in December. All U.S. federal agencies and other organizations that process information on their behalf must utilize DES (for nonclassified documents). Its use is also common among nongovernment corporations. It was based on IBM's LUCIFER system, which employs a 128-bit key. Generally, the larger the key, the more secure the system. DES utilizes a 64-bit key; however, 8 bits are for error detection thereby effectively making DES a 56-bit key system for security purposes. It is referred to as a block cipher since it encrypts data in blocks of 64 bits of binary data. The security of DES is based on the secrecy of the key, not the secrecy of the algorithm. The security is further enhanced by the size of the key since there are seventy quadrillion (70,000,000,000,000,000) possible keys; thus, the chances of deriving the key are low enough to be secure for most distributed environments. Of course, with the power of the average PC continually increasing, the ability to search sequentially for a key and break a code is proportionately increasing as well. There are three phases to the encryption algorithm, which are depicted in Figure 11.2. Decryption is accomplished by performing these three phases in reverse order including using the key blocks described in phase 2 in reverse order (K16 to K1).

Figure 11.2: The Three Phases of DES.

DES Phase 1: Initial Permutation

The first phase of DES involves a permutation of the 64-bit block that changes the order of the bits within each block. The term permutation is used in the strict mathematical sense; only the order is changed. The exact permutation is specified by a table (see Detail Box 11.1). The 64 bits of data are now broken up into two halves: L0 (left half) and R0 (right half). The zero subscripts indicate the original halves. These subscripts are incremented after each iteration in phase 2 of the DES algorithm.

Detail Box 11.1 The DES Permutation

The exact table used by the DES standard for the initial permutation is depicted in Table 11.1 [NIST77]. Thus, the first bit after the permutations was the 58th bit prior to the permutation. The second bit after the permutation was the 50th bit prior to the permutation. The last bit of the permuted data was originally the 7th data bit of the plaintext.

Table 11.1 DES Initial Permutation [NIST77].

58	50	42	34	26	18	10	2
60	52	44	36	28	20	12	4
62	54	46	38	30	22	14	6
64	56	48	40	32	24	16	8
57	49	41	33	25	17	9	1
59	51	43	35	27	19	11	3
61	53	45	37	29	21	13	5
63	55	47	39	31	23	15	7

DES Phase 2: Shifting (Repeated 16 Times)

The second phase involves a table-dependent algorithm that utilizes the key. This action is generally referred to as shifting the data. The algorithm is repeated 16 times, each time the shifting behaves differently since it utilizes a different subblock of the key. The subblock of the key is determined by another set of tables and its own shifting algorithm. After each iteration, the subindexes of L (left half) and R (right half) are incremented to represent each stage, as represented in Figure 11.2. The result after the 16th iteration is referred to as the pre-output and is passed into phase 3. The exact tables and various algorithms are presented in [NIST77].

DES Phase 3: Inverse Permutation

The final phase of DES involves a permutation of the 64-bit block that changes the order of the bits within each block just like phase 1 but utilizes a different table. The exact permutation is specified by a table (see Detail Box 11.2). The output of this permutation is the ciphertext.

Detail Box 11.2 The DES Inverse Permutation

The exact table used by the DES standard for the final inverse permutation is depicted in Table 11.2 [NIST77]. Thus, the first bit after the permutations was the 40th bit of the preoutput. The second bit after the permutation was the 8th bit prior to the preoutput. Finally, the last bit of the ciphertext was the 25th data bit of the preoutput.

Table 11.2 DES Inverse Permutation [NIST77].

40	8	48	16	56	24	64	32
39	7	47	15	55	23	63	31
38	6	46	14	54	22	62	30
37	5	45	13	53	21	61	29
36	4	44	12	52	20	60	28
35	3	43	11	51	19	59	27
34	2	42	10	50	18	58	26
33	1	41	9	49	17	57	25

TRIPLE DES

One can further enhance the security of DES by utilizing Triple DES. Triple DES utilizes three 64-bit keys. The data is sent through the three phases of DES with the first key to produce C1. C1 is then sent through the three phases of DES with the second key to produce C2. This second ciphertext is then sent through DES a final time with the third key as described here and depicted in Figure 11.3.

   E(p,k1)=C1
   E(C1,k2)=C2
   E(C2,k3)=C3

where E is the DES encryption algorithm,

   ki is the ith key, 
   p is the original plaintext and
   and C3 is the final ciphertext.

Figure 11.3: Triple DES.

Digital Signatures with Symetric Key Encryption

When sending data over a network, there are two basic methods to sign a document digitally. We now examine the first method that utilizes private-key encryption. A digital signature is also referred to as a message digest and employs a secure hash function as described in [NIST93B]. This hash function is referred to as a digest function and is typically 128 bits long. The deterministic digest function is applied to the entire document and produces a value that is dependent on every bit of information in the message. There are two methods for computing the digest utilizing a shared private key. The easiest and quickest method calculates a hash value for the message that is then encrypted by the private key. The message is then sent with the encrypted digest. The recipient may then calculate the message digest, encrypt it, and compare values. If they match, the document contents have not been altered. The second method prepends the private key to the message and then calculates the hash value. The result of this method is as follows.

   Compute D(M,K) where
D is a digest function
M is the message and 
   K is a shared private-key

The document can then be published or distributed. This message digest has the additional benefit of preventing forgery of the digest value itself since third parties do not have knowledge of the private key that is necessary to compute the correct digest value. In both cases, only those with knowledge of the secret key can verify its integrity, and all fraudulent documents are readily detected.

11.1.2 Asymmetric Encryption

Asymmetric encryption involves two keys—a public key and a private key—and is also known as public key encryption. If a piece of information is encrypted with a public key, the corresponding private key can decrypt the information as follows.

   E(p,ku)=C & D(C,kr)=p
   where 
   E = encryption algorithm, 
   D = decryption algorithm,
   p = plaintext (original data),
   ku  = public-key,
   kr  = private-key, and
   C = ciphertext.

If a piece of information is encrypted with a private key, the corresponding public key can decrypt the information as follows.

   E(p,kr)=C & D(C,ku)=p
   where 
   E = encryption algorithm, 
   D = decryption algorithm,
   p = plaintext (original data),
   kr  = private-key,
   ku  = public-key, and
   C = ciphertext.

You cannot decrypt a message with the same key that encrypted it, as depicted in Figure 11.4. Furthermore, it is mathematically difficult to obtain one key from the other. The private key is to be kept a secret by the user and thus its name. Of course, if everyone knew the private key, it wouldn't be so private! The public key is not kept a secret and may be made publicly available through a public listing service, usually implemented using X.509 (which is described in Section 11.2.2). The idea of public-key encryption was first proposed by Diffie and Hellman in 1976 [DH76] in the context of a method for key exchange and is presented in Detail Box 11.4. The most popular form of public-key cryptography is RSA [RSA78], which we now examine in detail.

RSA

RSA is a patent-protected, public-key encryption algorithm developed by Rivest, Shamir, and Adleman in 1978. To utilize RSA, there are three phases. Phase 1 involves the determination of your public and private keys. Phase 2 involves encrypting a message. Finally, Phase 3 involves decrypting a message. The three phases are described next and illustrated in Detail Box 11.3.

RSA Phase 1: Determining your public and private keys.

To determine the public and private keys, each user must do the following six steps.

Choose two large primes, P and Q.
Compute N = P * Q.
Compute F(n) = (P - 1)(Q - 1).

Figure 11.4: Public-Key Cryptography.
Choose e, where 1 <= e <= n-1 and GCD (e, F(n)) = 1.
Compute d, where ed = 1 (mod f(n)) (using the Extended Euclidean Algorithm).
Make d andn public; these values constitute the public key.

RSA Phase 2: Encrypting a message.

To encrypt the message M using RSA, where 1 <= M <= N - 1 you must compute the following.

   C=Me (Mod N) where C is your ciphertext.
   Send C.

RSA Phase 3: Decrypting the ciphertext.

To decrypt the ciphertext C using RSA, you must compute the following.

   Cd (Mod N)=M where M is your original plaintext.

Detail Box 11.3 An Example of the three phases of RSA

Phase1:

Let Alice choose P = 5, Q = 11.
Thus, N = P * Q = 55.
F(N) = (P - 1)(Q - 1) = 40.
Choose e = 7

(verify GCD (40 , 7) = 1 using the Euclidean Algorithm

40 = 5 * 7 + 5

7 = 1 * 5 + 2

5 = 2 * 2 + 1

2 = 2 * 1 + 0 ).
Use the Extended Euclidean Algorithm to determine D expressed as a linear combination of e and f(N).

1 = 5 – 2 * 2

= 5 – 2 (7 – 1 * 5)

= - 2 * 7 + 3 * 5

= - 2 * 7 + 3 * (40 – 5 * 7)

= 3 * 40 – 17 * 7

Hence 1 = - 17 * 7 (Mod 40) = 23 (Mod 40) and

D = 23.

Phase 2.

Send message M = 25 to Alice.

Compute C = Me (Mod N) = 257 (Mod 55) = 20.

Phase 3.

Decrypt ciphertext C = 20 received from Alice, whose public key is (D = 23, N = 55).

Compute Cd (Mod N) = M = 2023 (Mod 55) = 25 = M.

Detail Box 11.4 Diffie-Hellman Key exchange

Alice and Bob would like to exchange keys using this method; they have to follow the next five steps for employing the Diffie-Hellman key exchange. Figure 11.5 depicts Alice and Bob going through this example.

Alice and Bob agree on a prime number that is openly communicated, p and an integer a.
Alice generates a random value x: 2<=x<=p-1.
Alice computes ax (Mod p)=A and sends A to Bob.
Bob generates a random value y: 2<=y<=p-1.

Figure 11.5: Diffie-Hellman Key exchange.
Bob computes ay (Mod p)=B and sends B to Alice.
Bob computes (A)y (Mod p)=(ax)y (Mod p).
Alice computes (B)x (Mod p)=(ay)x (Mod p)= (ax)y (Mod p)!

Thus, (ax)y (Mod p) is their common shared key!

For example.

Alice and Bob agree to let p=11, a=7.
Alice generates x=5 where 2<=5<=11-1.
Alice computes ax (Mod p) or 75 (Mod 11)=10 and sends the 10 to Bob.
Bob generates y=8: 2<=8<=11.
Bob computes ay (Mod p)= 78 (Mod 11)=9 and sends 9 to Alice.
Bob computes (A)y (Mod p)=(75)8 (Mod 11) = 78*5(Mod 11.)
Alice computes (B)x (Mod p)=(78)5 (Mod 11)= 75*8(Mod 11)!

Thus, 75*8(Mod 11) is their common shared key.

Digital Signatures with Public-Key Encryption

The public-key encryption method for digital signatures employs RSA. In this method the originator utilizes its private key to encrypt either the entire data file (expensive) or its signature to the file by using a digest function. The primary benefit over the private-key counterpart is that there are no key distribution problems. This method does assume that you can trust the source that publishes the public key (see Section 11.3.1). A recipient may then utilize the public key to decrypt the signature or file and verify its origin and/or contents. Recall that due to the intricacies of public-key cryptography (Figure 11.4), only the proper public key will decrypt the message or the digest. Finally, if you are sending a message to someone with a known public key, you may encrypt the message or the digest with the recipient's public key so that only the recipient can verify the contents by utilizing their own private-key.

11.2 Authentication

There are several steps necessary in providing authentication in a distributed environment. The first step is authenticating or verifying the identity of a user. There are three basic methods for accomplishing this [Sha77, WL92]. First, one may verify a user by something that is known by the user such as a password, the most popular method although not necessarily the most secure. The second method involves something that is possessed by a user, such as a key. The third method involves something the user is, such as the user's fingerprints or retina patterns, the most secure and expensive method. Observe that up until this point, these methods are all possible to use on a centralized system as well. A distributed operating system must also accommodate the following concerns.

Eavesdropping: How do we prevent someone from eavesdropping on the communication line?
Multiple password management: If we are accessing multiple systems, does every system keep a copy of the user ID and password? Every database storing authentication information is a target for a system security loophole. Furthermore, do we need to present our password everytime we want to accomplish something?
Replay: Someone could copy authentication information while it is transmitted on the network, even if it is encrypted, and replay it at a later time, thus allowing inappropriate access.
Trust: Should authentication be unilateral or should the user be able to verify and have confidence that the service being utilized is legitimate as well. A centralized system trusts itself; a distributed system has to find a way to trust others.

A common solution to these concerns is using one of the certificate management systems. A certificate is a computer-generated, frequently time-valid, authenticated packet of information utilized in distributed systems to allow easy access to the various resources. The time-valid feature helps prevent replay at a later time. This may be accomplished with a timestamp or with a nonce. A nonce is a random value unique for each communication. Thus, no two communications share a nonce and replays are easy to detect. There are two basic approaches to certificate management. The first approach, presented in Section 11.2.1, involves utilizing certificate lists that contain a list of certificates from a trusted certificate authority and is exemplified by X.509. Any service wishing to verify an identity must examine a list to verify the authenticity of the client. The second approach, presented in Section 11.2.2, involves a centralized certificate distribution center where clients obtain a certificate for each service that the user they wish to use. The client then presents this service certificate when utilizing a service.

11.2.1 Certificate Lists

Certificate lists are based on public-key cryptography, as presented in Section 11.1.2. The identifying information of the users is referred to as a certificate and may be contained in a certificate list. The authentication authorities verifying the identities of the users are referred to as certificate authorities and verify the user's public-keys. Figure 11.6 depicts how a service such as RPC may utilize a certificate list.

The certificates are authenticated by the certificate authority's digital signature as described in Section 11.1. There may be several certificate authorities. We now examine how certificate lists function by looking at X.509 as an example.

Figure 11.6: Certificate List Utilized in Secure RPC.

X.509

X.509 is the authentication portion of the X.500 directory service discussed in Chapter 7. The directory service provides the location for the certificate lists but assumes that a trusted certificate authority exists to create these certificates. The certificates are signed by the issuer (encrypted with the issuer's private key) to bind the certificate holder's name with the issuer's public-key. The following is a list of the elements contained in an X.509 certificate (version 1).

V: Version; the version differentiates among successive versions of X.509. The default is the 1988 version.

SN: Serial number; the serial number is an integer value that is unique within the issuing certificate authority. The serial number is unambiguously associated with a certificate the same way that a Social Security number is unambiguously associated with a U.S. Citizen or immigrant.

AI: Algorithm identifier; the algorithm identifier identifies the algorithm used to sign certificate's by the certificate authority. The certificate authority signs each certificate with its private key.

CA: Issuer or certificate authority; the certificate authority is the one that created this certificate.

T$_{A}$: Period of validity; provides the first and last date it is valid, similar to a credit card's date.

A: Subject; whose identity the certificate verifies.

Ap: Public-key information; provides the public-key and algorithm identifier for the subject identified by the certificate.

Signature: The certificate signature covers all other fields of the certificate. The signature is a hash code of other fields and is encrypted with the certificate authority's private key to ensure the integrity of the information in the entire certificate. If one uses the certificate authority's public key to decrypt the hash code and computes the hash code for the certificate and they do not match, a portion of the certificate has been illegitimately altered.

Any user with the certificate authority's public key can recover and verify the authenticity of each certificate in the certificate list. X.509 provides three procedures for authentication using these certificate lists: one-way authentication, two-way authentication, and three-way authentication.

One-Way Authentication

One-way authentication protects the integrity and originality of a message. This is accomplished when someone signs a timestamp, nonce value, and identity of the destination with the user's signature (private-key). The receiver may then verify the information by "unsigning" the information with the originator's public key as verified in the certificate list. Since only the destination is authenticating, this is referred to as one-way authentication.

Two-Way Authentication

Two-way authentication allows the receiver or destination also to be verified by the originator or sender. In addition to going through one-way authentication, the destination sends a reply to the originator. This reply includes a new timestamp, the original nonce, and a new nonce. This reply is then signed with the originator's public-key. Recall that in public-key cryptography only the corresponding private key, or the originator's private key can decrypt the reply. Furthermore, the nonce must be the original nonce or the message is not authentic.

Three-Way Authentication

Three-way authentication is employed when the destination and originator do not have synchronized clocks or do not wish to trust the clocks. In addition to going through two-way authentication, the originator then sends a reply to the reply of the destination including the new nonce contained in the original reply, as shown in Figure 11.7. Upon verifying the matching nonce values, there is no longer a need to verify timestamps.

Figure 11.7: Three-Way X.509 Authentication.

Revoking Certificates

One potential problem with certificate lists involves revoking a certificate prior to the expiration time of the certificate. This is accomplished by maintaining a revocation list. This list is kept along with the certificate list and must be consulted to ensure that the certificate is still valid. This is similar to the old-fashioned credit card books that maintained a list of credit cards that were invalid prior to their expiration date. The revocation list does contain a message digest that is digitally signed with the certificate authority's private key to maintain and ensure the integrity of this list.

Using Multiple Certificate Authorities in X.509

Another potential problem is the existence of multiple certificate authorities. However, you may verify the identity of someone who uses a different certificate authority if the appropriate certificate authority is listed with your authority. To do this, you must verify the other authority's identity with your authority. Once this is accomplished, you have the other authority's public key and you may verify the identity of anyone listed with the other authority as displayed in Figure 11.8. This is referred to as chaining certificate authorities and may be compared to the mathematical transitive principle. If Alice knows Certificate Authority 1 and Certificate Authority 1 knows Certificate Authority 2 who knows Certificate Authority N, who knows Steven, Alice knows Steven.

Figure 11.8: Chaining Certificate Authorities in X.509.

Classes of Certificates

Finally, X.509 provides for different classes of certificates. Each class has passed a different degree of verification and thus reflects the level of reliability of the authentication information in the certificate lists.

The lowest level is Class 1. For a Class 1 certificate, the identity was verified by the subject providing an Email address and the authority sending a reply to this Email address. At the other end of the spectrum is Class 4, which requires physical presentation of the subject and the certificate authority must perform a background check. X.509 certificates may be employed within the protocol known as secure socket layer (SSL) as described in Detail Box 11.5.

11.2.2 Centralized Certificate Distribution Center

A centralized certificate distribution center relies on one site to manage the distribution of all of the certificates. Thus, the certificate distribution center becomes a critical element in the distributed system. If the certificate distribution center crashes or is compromised, the entire distributed system suffers. This site maintains a copy of the private keys for all valid users and services of the system in the certificate database manager. The certificate distribution center uses these private keys to distribute system and service certificates to the users for each service they wish to utilize. These service certificates must be presented by the client to use a service. There is a unique service certificate for each user and for each service. These service certificates parallel the capability security concept in centralized systems. Thus, a single user may have several service certificates, and these service certificates must be presented to use a service. Service certificates are only valid for a limited time and a particular service. If a user's service certificate has expired, the user must obtain a new service certificate from the certificate distribution center using the user's system certificate. We now examine how a centralized certificate distribution center functions by examining Kerberos version 5.

Detail Box 11.5 Secure Socket Layer

SSL began at Netscape for secure communication through Web pages and is supported by most browsers. Most recently, WinSock now includes SSL. The Internet Engineering Task Force (IETF) formally developed the SSL standard. Its goals are to ensure privacy, integrity, as well as authenticity. Applications may range from the original domain within browsers to developing secure transmissions among corporations collaborating on a project and wishing secure communication. The use of SSL allows two entities to communicate over a public network in a somewhat (depending on the key length) secure manner and without much reworking of code that may already exist. This option is most likely more cost effective and more efficient than purchasing and utilizing a dedicated line connection.

SSL consist of three phases. The first phase is the authentication handshake and accomplishes the following tasks.

It establishes the protocol the two will employ to communicate.
Define the encryption algorithm.
They determine if data compression will be utilized.
They exchange keys.
They may verify the identity of each using X.509 certificates including the ability to chain X.509 certificates.

The second phase the actual communication of the data takes place. This data is transmitted in an encrypted manner, as determined in phase 1. In addition, each block of data is digitally signed generally employing DES. The final phase simply consists of performing an additional handshake to ensure both are aware the connection is closing and, finally, closing the connection. Generally, SSL is employed using a 40-bit key as current U.S. trade restrictions prohibit larger keys for export.

Kerberos v.5

Kerberos was the first distributed authentication protocol in widespread use and influenced many of the later protocols, such as SESAME and KryptoKnight. It is available free from ftp://athena-dis.mit.edu/pub/kerberos and is described in [NeTs94]. Its purpose is to provide a trusted third-party authentication system. By using a third party, every location involved in the distributed system was relieved of keeping a complex database of user ids and passwords. Instead, Kerberos kept a single master database of authentication information referred to as the Kerberos database management system (KDBM). The KDBM was assisted by several possible Kerberos key distribution services, which contained read-only copies of the master database and helped avoid a bottleneck at the KDBM. The Kerberos key distribution services also allowed the system to function if the KDBM was temporarily unreachable. The Kerberos system involves the following four phases, which are further described in Detail Box 11.6.

Phase 0: Registering with Kerberos

Before any user may establish a session, the identify of the user must first be established off-line to the Kerberos key distribution center. Once this is accomplished, user's ID and password are stored in an encrypted manner in the Kerberos database manager. At this point, the user is considered registered and is prepared to utilize the network services through the Kerberos protocol.

Phase 1: Obtaining a System Ticket

Kerberos certificates for authentication are referred to as tickets. Phase 1 involves obtaining a system ticket, which may be used to obtain service tickets from the ticket granting service (TGS) in Phase 2. To obtain a system certificate, one must be registered with Kerberos (Phase 0). The Kerberos system ticket obtained is encrypted with TGS's special private key. This system ticket contains identification information for the client, including the following.

A temporary session key for use between the TGS and client
The client identity
The identity of the TGS
Expiration time of the ticket
The network address of the client

The ticket is encrypted by Kerberos so that only the TGS can verify that the system ticket is valid. An invalid ticket would not be encrypted with TGS's private key, which only Kerberos and the TGS know. The system ticket is sent to the client along with the identity of the TGS, a session key created by Kerberos for the TGS and client to use, and returns the nonce value that the client sent to Kerberos. If the nonce value matches the value sent to Kerberos, the client knows the system ticket is legitimate and new.

Phase 2: Obtaining a Service Ticket

To obtain a service ticket, a client sends a packet to the TGS encrypted with the session key that the client shares with the TGS. This packet includes the client's name, network address, a nonce value, and the name of the service the client wishes to use. In addition, the system ticket is sent unencrypted.

When the TGS decrypts the system ticket with its key, it verifies that the information in the system certificate matches the information in the packet received. If they match, the TGS can be sure that this is a valid request. Given that the request is valid, the TGS prepares a packet for the client. This packet includes a service ticket encrypted with the private-key of the service (thus, only the service can verify the ticket), the name of the service, an expiration time, and the nonce. This packet is encrypted with the client's and the serverice's shared session key. If the nonce values match, the client knows this is the appropriate reply. We now have a key to use a specific service listed with Kerberos.

Detail Box 11.6 Kerberos Authentication Service V.5

Let

IDT = Ticket Granting Service's ID

IDc = Client's ID

IDs = Server's ID

Ni = Nonce value

Kc = Client's private-key

Ks = Application Server's ID

KT = Ticket Granting Server's private-key

K1 = System Ticket

K2 = Service Ticket

Ts = Starting time stamp

Te = Ending time stamp

E(a,K) = Applications of encryption algorithm to a with key K.

Phase 1 is depicted in Figure 11.9, Phase 2 in Figure 11.10, and Phase 3 in Figure 11.11.

Figure 11.9: Kerberos Phase 1 Details.

Figure 11.9: Kerberos Phase 1 Details.

Figure 11.10: Kerberos Phase 2 Details.

Figure 11.11: Kerberos Phase 3 Details.

Phase 3: Employing Mediated Services

Now the client has a service ticket and is ready to use a service. This service ticket allows the service to authenticate or verify the identity of the client. To use a service, a client sends a packet to a service, including the service ticket and the client's identity. Recall that the service ticket is encrypted with the service's private-key and contains the client's identity and timestamp. If the timestamp has not expired and the identity matches, the client is authenticated and free to employ the service.

11.3 Access Control (Firewalls)

While open distributed systems are designed to allow the free flow of information between all the systems attached to the network, a distributed operating system must provide access control so that only the information we intend on sharing is, in fact, shared. Furthermore, the needs of one system may not be the needs of another system. A corporation may follow a security policy stating "anything not explicitly allowed is not allowed" and a university or private site might follow the other extreme. Specifically, "anything not explicitly disallowed is okay." Frequently, while access control is an operating system concept, the distributed operating systems of today must rely on hardware assistance. In either case, access control in current distributed systems is generally accomplished by what is known as a firewall.

A firewall should be immune to security threats and prevent all security threats from passing through the wall and to the system(s) it protects. Firewalls should not prevent activities that conform to the security policy of the organization.

Firewalls generally fit into one of the following two categories.

Packet-filtering gateways
Proxy services

Frequently, a location may employ both types of firewalls to realize the desired access control. We examine each of the two basic categories of firewalls and then examine some of the basic firewall architectures incorporating both types.

11.3.1 Packet Filtering Gateways

A packet-filtering gateway firewall involves a security engineer who must explicitly state what may pass through the wall. This includes what internal information may go out of the firewall as well as what outside locations are allowed through the firewall. Furthermore, the security engineer may configure the firewall to specify what internal computer services may be shared with the outside world.

Packet-filtering gateway firewalls are generally implemented on the router that connects the internal system to the outside world. While general routers can perform packet-filtering functions, firewall routers tend to provide a better user interface and are generally easier to configure for security-based filtering. Just as the postal services around the world require addresses on envelopes, networks require messages to have addresses. It is these addresses that this type of firewall checks against its list before allowing a message to pass through in either direction. Since all messages must pass through the router that functions as a firewall, all messages are checked by the firewall.

The rules of a packet filter gateway might be as depicted in Table 11.3.

Table 11.3 Packet Filter Gateway Rules.

Action	Destination Address	Destination Port	Source Address	Source Port
Deny	us.net		Enemy.net
Allow	us.net		Friend.net

These rules deny anything to us.net coming in from enemy.net on any of our ports or connections to the network. Furthermore, they allow anything to us.net coming from friend.net on any port. The exact syntax varies and depends on the particular router and its manufacturer. Regardless of the manufacturer, the security engineer setting up the system must explicitly state everything that is allowed or disallowed. This is not always easy to decide or specify. Some services, such as the UNIX X11 window manager, are desirable to the internal users; however, if someone internally can use X11, external usage cannot be prohibited. An unauthorized X11 user may conduct screen dumps and record keystrokes of internal users, which is a very serious security threat. Finally, any loopholes left in the firewall may be penetrated and defeat the security and protection of your system.

11.3.2 Proxy Services

A proxy service represents an internal client's service to the outside world. While it is representing this service, it may act a little differently to increase security. There are two basic types of proxy services.

Application-level gateway proxy services, and
Circuit-level gateway proxy services

An application-level gateway firewall provides access control by rewriting all major applications. The new applications reside on centralized hosts that everyone must utilize. These hosts are referred to as bastion hosts, named after highly fortified medieval castles and are considered the critical security points. These hosts are frequently dual-homed hosts or hosts that reside on more than one network. The applications seem to function in the same manner as their original applications except that the security loopholes are removed. Specifically, the new applications involve one small but important added feature: authentication by one of the methods discussed previously in this chapter. Application gateway firewalls are excellent complements to packet filter gateways and could be used to rewrite applications such as X11.

Circuit-level gateways are similar to application-level gateways in that they are designed for an individual application. Unlike application-level gateways, they are transparent to the users. Specifically, an outsider may connect to a network through TCP ports. In circuit-level gateways, the firewall provides the TCP port and relays the bytes back and forth, acting like a wire and thus completing the circuit without ever interpreting the application protocol.

Since they operate at a lower level, circuit-level gateways need to modify the client to obtain the destination address, which is otherwise readily available for application-level gateways. Frequently, the modified clients are used only for external connections. All filtering is conducted based solely on source and destination without additional information on the specific commands.

In addition to relaying the bytes, the modified client and, thus, the circuit-level gateway keeps a log of the number of bytes relayed as well as the TCP destination. If there is a known site that has had a security problem, the system administrator could use this log to notify anyone on the system who has unfortunately connected to the corrupted site.

11.3.3 Firewall Architectures

We now examine three basic firewall architectures incorporating packet-filtering firewalls and proxy-service firewalls.

Bastion Host Architecture

The simplest architecture is that of a bastion host. This design exclusively utilizes a bastion host to provide proxy-services. While the host is capable of routing information from one network to another, this feature of the host is not recommended for it may be abused and ultimately used to circumvent your firewall. All local systems are considered internal systems. All nonlocal systems are considered external systems. The bastion host is a dual-homed host that resides between the internal and external systems. It is not directly on either network but operates as a gateway between the networks. All internal systems can communicate with the bastion host and all external systems can communicate with the same bastion host. The internal and external systems may not communicate directly with each other but communicate by having the host proxy the services on each other's behalf, as depicted in Figure 11.12. If the host receives a packet of information on its external connection with an internal address, that packet must be fraudulent. This architecture exhibits all the weaknesses of proxy-service firewalls, including the limitations of what services they may provide.

Figure 11.12: Bastion Host Firewall Architecture.

Filtering Host Architecture

The filtering host architecture utilizes a bastion host with proxy services and a router acting as a screen and providing packet-filtering capabilities. Unlike the previous architecture, the bastion host resides on the internal network, as depicted in Figure 11.13.

The packet-filtering capabilities on the filtering router route all permissible external traffic with internal destinations to the bastion host. Furthermore, the packet-filter may be configured to allow only the bastion host external access. If internal hosts other than the bastion host are denied access to the packet-filtering router, the internal hosts are forced to use the proxy services of the bastion host to reach external hosts. Thus, a site with strong security requirements would likely disallow internal hosts access to external network directly through the packet-filtering firewall.

Figure 11.13: Filtering Host Firewall Architecture.

Filtering Subnet Architecture

The most secure of the three firewall architectures is the filtering subnet architecture. This architecture involves two packet-filtering firewalls and a proxy-service firewall. The proxy-service firewall or bastion host is connected to its own network situated between the two packet-filtering firewalls. One packet-filtering firewall connects the bastion host's subnet to the external network. The other packet-filtering firewall connects the bastion host's subnet to the internal network, as depicted in Figure 11.14.

The subnet with access to the external network is referred to as a filtering subnet. Since it is possible on most local area networks for any host on the network to 'snoop' or see all traffic on the network, the major benefit of this architecture is the lack of internal-only information on the filtering subnet. Thus, an intruder would have to bypass the external packet-filtering router, compromise the bastion host, and bypass the internal packet-filtering router to compromise the access control.

Figure 11.14: Filtering Subnet Firewall Architecture.

11.4 Summary

This chapter discussed security methods added on to an already secure isolated system when attached to a network. Like centralized systems, distributed security involves both authentication and access control. In addition, distributed systems need to consider the use of encryption and digital signatures. One must always keep in mind the value of what is being protected when determining what methods to employ. Furthermore, one must consider the time frame of the information. For example, MicrosoftTM assumably no longer worries if someone knows they were planning on releasing Windows95TM since it has already been released. However, when this product was first conceived and during its planning and development, this information was obviously important and had to remain very secure. With this in mind, a given system on a network may choose only to employ a packet-filtering gateway while others also choose to utilize a proxy server. Likewise, not all systems maintain information worthy of the complexity and expense to utilize a Class 4 certificate authority. However, a company such as Equifax, which maintains extensive credit databases on U.S. citizens, chooses to utilize isolated networks and considers any risk of connection to outside networks too great despite all available technology in distributed security. In summary, just like standard operating systems on isolated computers, it is possible to achieve a high level of security; however, there are no 100% guarantees.

11.5 References for Further Study

The following references can provide more general information on distributed security: [Bra95, Car95, ChBe94, ChZw95, KPS95, McC98, Pfl97, Pow95, Sta95, and Wil94]. Some appropriate traditional research papers concerning information in this chapter include [ABCLMN98, AbPo86, ADFS98, AGS83, AJP95, And94, BAN90, BBF83, BFMV84, ClHo94, DH76, DESA81, DoMc98, Erick93a, Hel78, Klu94, LABW94, Lai92, Nes83, NeTs94, NIST77, NIST93B, NIST94a, NIST94b, Opp97, Opp98, PaSh98, RSA78, RuGe98, Schn98, Sim92, Sha77, THPSW98, and WoLa92].

The following provide some great starting points for sources on the Internet concerning security issues. An extensive list of security related links can be found at https://www.semper.org/sirene/outsideworld/security.html. This site includes links to standards and protocols, and alert sites among many other resources. By sending Email to rsaref@rsa.com, one can receive information on how to obtain RSAREF. RSAREF is a free (only available to U.S. and Canadian Citizens) educational tool, written in C, which handles RSA encryption and key generation, DES, Diffie-Hellman key agreement, and Triple DES among other features. The Kerberos Request for Comments: 1510 document can be found online at ftp://ftp.isi.edu/in-notes/rfc1510.txt. Information on how to retrieve (the free) Kerberos software can be found at https://web.mit.edu/kerberos/www/krb5-1.0/announce.html. A list of Kerberos Papers and Documentation can be found at https://nii.isi.edu/info/kerberos/ documentation.html. The source code and information about obtaining Sesame, a distributed access control program that builds upon and expands Kerberos, can be found at https://www.esat.kuleuven.ac.be/cosic/sesame/. A free version of SSL along with pointers to references on SSL can be found at https://psych.psy.uq.oz.au/~ftp/Crypto/. A set of links to algorithms and standards for cryptography-related information can be found at https://www.ssh.fi/tech/crypto/.

Exercises

What are some of the additional security concerns presented to a distributed system? Is it possible to provide the same level of security as compared to an isolated centralized system?
Discuss the advantages and disadvantages of symmetric encryption and asymmetric key encryption.
Using the RSA public-key encryption algorithm presented in Section 11.1, let P = 7, Q = 11 and e = 4.

Compute the value of D.

What is the public key?

If the message is M = 17, what is the encrypted message that is sent?

Verify the message by decrypting it using the public key.

Calculate the shared key in Detail Box 11.4.
Write a program that implements the Diffie-Hellman key exchange algorithm described in Detail Box 11.4.

Option 1: Allow both Alice and Bob to use the same terminal and exchange keys. Allow the program to choose your random numbers.

Option 2: Have the user be Alice and the program be Bob. Allow Alice and Bob to exchange numeric messages.

Option 3: Use an IPC mechanism studied in Chapter 4 to allow two users on different computers to exchange keys and numeric messages.

Option 4: Allow the user to select any of the preceding three mode options.
Discuss the relative advantages of one-way, two-way, and three-way authentication in X.509.
Discuss a potential use for each of the following X.509 authentication procedures.

One-way authentication

Two-way authentication

Three-way authentication
Describe one viable algorithm for exchanging messages to accomplish phase 1 of SSL using four keys and allowing each to validate the other's identity (a public key of a given user is counted separately from the private key of the same user).
Discuss the relative advantages and disadvantages of using a certificate list versus a certificate distribution center for distributed authentication.
What are the advantages of having several key distribution services in Kerberos?
In a centralized system, it is common to utilize an access matrix whose rows represent the users (or collection of users) and the columns represent the resources (also defined in varying degrees of granularity). The information within the matrix defines if and to what extent a user has the privilege to utilize a resource. Describe some of the complications that might occur when implementing an access matrix for a distributed system for each of the following options.

Implemented on a single centralized server.

Implemented with multiple copies of the matrix throughout the distributed system (Hint: Think Chapter 7).
Some locations prefer to utilize multiple bastion hosts. Discuss some of the advantages of this approach.
Of the three firewall architectures presented in this chapter, which is the most secure and why?
While it is generally considered OK to utilize multiple exterior routers in the screened subnet firewall architecture, it is considered a serious security risk to utilize several interior routers. Why?
Inherent in the use of cable modems for home access is the cable modem architecture, which involves a single cable going in and out of each home in a neighborhood (much like a pearl necklace) and turning the neighborhood into a virtual LAN.

1 Formerly known as the National Bureau of Standards (NBS).