Security Issues in Distributed Computing - Semantic Scholar

6 downloads 0 Views 155KB Size Report
Dr Luke O'Connor has a PhD in cryptogra- phy and is currently employed as a research sci- entist in the Co-operative Research Centre (CRC) for Distributed ...
Security Issues in Distributed Computing Luke O'Connor

Gary Gaskell

CRC for Distributed Systems Technology Information Security Research Centre, QUT foconnor,[email protected]

William J. Caelli School of Data Communications Faculty of Information Technology, QUT Abstract As the computing world progresses towards open systems the potential of Information Systems is expanding rapidly. This and the process of open standardisation makes it imperative that security is built in to the these systems. There has also been substantial publicity concerning the `information superhighway' and the privacy of the information owing on it. It is the purpose of this paper to present the main security issues related to open and distributed systems, which includes authentication, delegation, expression of general access rights, authorization and global credentials. We will give a brief description of each area describing the current status of research.

 The

work reported in this paper has been funded in part by the Cooperative Research Centres program through the Department of the Prime Minister and Cabinet of Australia.

1

Introduction

the fact that a single operating system orchestrated all resource requests and allocations. At the time of logging into the system the user presents their password, which if validated by the system, gives the user access to certain resources on the system. This process is called one-way authentication since the user is proving their identity while the integrity of the system is assumed. Here the user `trusts' the system completely. It is not dicult to envisage that the level of trust inherent in one-way authentication is inadequate for distributed environments consisting of several independent networks, each connecting a number of heterogeneous hosts. Further, authentication is not only required at the user level but also at the peer-to-peer level as processes communicate across the network in accessing resources. For this reason we model the system as consisting of principals , most likely realised by communicating processes, and objects, such as les. It is the task of the system to decide which principal made a given request R, and if this request is to be granted. The main security threats encountered in a distributed environment are:  The impersonation or misuse of a principal's identity  Modifying access control structures which describes a principal's capabilities  Repudiation of a principal participating in an protocol or part thereof  Destruction or modi cation of programs or data  Denial of service to a principal  Leakage of information, including deduction of information  Trac analysis Observe that of these threats, the rst four relate directly to authentication. It is the security policy that will determine which of these threats are to be addressed, the extent to which these threats are to be dealt with, and how this will be implemented. Issues related to security management and policy are discussed by Dorey [7]. It is clear that

One of the most important issues in distributed computing is the security of its resources. This not only means that resources, such as les and databases, are protected from misuse or corruption, but more generally that no action is performed in the system which is contrary to its stated security policy. At the basis of implementing a security policy is the unambiguous determination of a principal's identity, referred to as the problem of authentication . In theory then, a secure and correct authentication mechanism and associated set of permissions with each principal can restrict access to network resources according to a given policy. In this paper we will discuss several aspects of security related to authentication. First we introduce the notion of an authentication server and tickets, which is emerging as the new authentication paradigm (over passwords). The paradigm has been popularised by Kerberos and has been extended in OSF's Distributed Computing Environment (DCE). We next discuss the issue of distributed time and its implications for authentication protocols. The Generic Security Service Application Programming Interface (GSS-API) is introduced which is intended to become standard API for interfacing with general security services, including authentication, in a distributed environment. We then discuss how authentication is performed across security domains using both private and public key technology, leading to a section on certi cate based authentication as in the X.509 standard. Lastly we consider the problem of delegation where rights are transferred from client to one or possibly several servers to act on their behalf.

Authentication We will be interested in the manner in which the distributed system determines the identity of a user, and delegates this information so that the user may access all the resources that they are entitled to. This will be referred to the problem of authentication. While this problem was also present in central time-share systems, it was greatly simpli ed by 2

a security policy must be de ned for a principal to be accused of requesting some service that they are unauthorized to request. A distributed environment is expected to consist of a collection of distinct security domains, each having a well-de ned security policy. The goal of authentication is not to extend these security domains, but rather to de ne access points between trusted domains so that the security of any given domain is not weakened or compromised by participating in the distributed environment. In practice this task often reduces to unambiguously determining the identities of two principals that are attempting to initiate an exchange of data. Two new problems present themselves that were not induced in the time-share environment. First, if a principal Pi logs on at a local host H using password-based authentication, how is the identity of Pi to be propagated to other hosts that do not (and should not) share a password with Pi? The second problem is to determine how two mutually suspicious principals Pi and Pj , from possibly distinct security domains, wll convince each other of their respective identities. It is conceivable that the principal could reauthenticate itself via some elaborate password mechanism for each service that is requested. However, a more ecient and sensible solution would be to issue the principal Pi with some token or ticket TP at the time of logon which is recognized globally as undeniable proof of Pi 's identity. In both cases passwords are insucient since the protocol is asymmetric in its trust. The only option is to introduce a trusted third party that will act on the behalf of a principal in accessing resources and also in interacting securely and authentically with another principal. The authentication server AS is this secure third party. If principal Pi wishes to send a message to principal Pj then AS provides two basic services:

The authentication server will also be able to prove the identity of Pj to Pi so that mutual authentication is possible. At the time of logon, a principal Pi and the authentication server AS carry out a protocol that performs mutual authentication, and leaves Pi with a ticket TP that is used to obtain services from the system. This ticket may contain general permissions or simply an encryption key that can be used to communicate securely with a server. Each principal will share some secret with the authentication server, and possession of a principal's secret is equivalent to being the principal, as with passwords. If this secret is an encryption key, then a principal with demonstrate its identity by its ability to decrypt random challenges constructed by the AS. i

Protocol Type Year Needham-Schroder [18] PK 1978 Needham-Schroder [18] SK 1978 Denning-Sacco [3] SK 1981 Andrew Secure RPC [24] SK 1985 Needham-Schroder [19] SK 1987 CCITT X.509 [1] PK 1987 STS [6] PK 1987 Otway-Rees [20] SK 1987 Kerberos V4 [16] SK 1988 Gong [10] OF 1989 Gong et al. [11] PK/SK 1989 SPX [25] PK 1991 Davis-Swick [2] SK 1990

i

Table 1: Several known authentication protocols. An authentication protocol is a sequence of messages that two principals undertake to perform mutual authentication. The rst signi cant such protocol was due to Needham and Schroeder [18], which gained added notoriety when it was shown to be

awed. Table 1 lists several known authentication protocols [14], where PK, SK and OF refer to public key, private key and one-way functions respectively. There are several implementations of authentication systems available, with Kerberos [16] being the most popular. Kerberos was developed at MIT with DEC during their joint Project Athena,

Con dentiality Principal Pi is certain that the

message sent can only be read by the intended receiver principal Pj ; Authenticity Principal Pj is certain that the received message could have only originated from principal Pi. 3

Distributed Time

and forms the basis of the authentication system in OSF's Distributed Computing Environment (DCE) [23]. There are several versions of Kerberos with V5 release 4 evolving into what is meant by a general reference to Kerberos. Kerberos is freely available in the US and Canada via anonymous FTP, while general export restrictions apply for other countries due to the use of encryption in the authentication protocol. The concept of a ticket was popularized by Kerberos, and all access in Kerberos is controlled by tickets. The basic idea is as follows. Say principal Pi wishes to use a service o ered by principal Pj . Pi contacts the AS and obtains a ticket TP = EP (Pi; t) which consists of an identi er for Pi and some information t all encrypted in the password of Pj . Here t is authentication information including the current time. Pi presents the ticket to Pj , who decrypts it and determines the if the encrypted identity matches the identity of the principal sending the ticket. The ticket is also judged to be `recently generated' by examining the information contained in t. If the identities match and the message is current Pj concludes that Pi just obtained this ticket from AS, as only AS has knowledge of Pj 's password. There are several other implementations of authentication protocols. KryptoKnight [17] was developed in Switzerland at an IBM research laboratory, and is based on protocols distinct from Kerberos. It does not su er from export restrictions as the security of the protocols is based on hash functions (eg. MD5 [21]) rather than encryption. SPX [25] is an authentication system based on public and private key methods and certi cates (explained below). It was originally part of DEC's Distributed System Security Architecture (DSSA), and will probably be incorporated into DEC's future contribution to the security features of DCE. SELANE (SEcure Local Area Network Environment) [9] is another authentication system, based on both private and public key cryptography, developed at the University of Karlsruhe, Germany. i

Above we mentioned that Kerberos tickets contain an authenticator t which is based on a timestamp (the present time) to determine if ticket is current or not. If such a measure was not undertaken, then an attacker could replay the ticket at a later date claiming to be the legitimate owner of the ticket. In a distributed system this would mean that the clocks on the various hosts would have to synchronized to make the use of time meaningful. As perfect synchronization is not possible we will say that two clocks Ci and Cj are synchronized if jCi ? Cj j  , meaning that the times they indicate only di er by at most some xed tolerance . An error in the clock synchronization could lead to issuing tickets which are useful far beyond their intended lifetime. The use of time in an authentication protocols is to prevent replay, but as has been suggested, a similar assurance against replay can be provided by augmenting a protocol with a challenge-and-response step. Here the sender of a ticket is required to encrypt a random challenge (nounce) generated by the receiver, which if correctly decrypted by the sender is taken as evidence that the sender actually posses the key at this moment. The random challenge, such as a 128-bit integer, is drawn from a large space of possible challenges so that challenges are unlikely to repeat. However there are some protocols, such as user datagrams, where the authentication information must be appended to the data, and a challengeand-response step is not possible. On solution is to distribute the time securely using a challenge-andresponse protocol, and then to let other authentications be based on timestamps.

j

The GSS-API There are several initiatives to hide the details of authentication protocols, and in fact security services in general from the application programmer. Essentially all the programmer needs to know is how to incorporate security services into a given application. Additionally, the programming task 4

would be made easier if there was some standard way of accessing security services so that the application would be portable across platforms and architectures. The Generic Security Service Application Programming Interface (GSS-API) is one proposal for an API to access security services [15]. The main goals of the GSS-API are

domains is known as interdomain communication. The basic intradomain authentication protocols can be extended to authenticate interdomain communication if the two ASs of the principals involved, say ASi and ASj , establish some trust relationship. In the case of Kerberos this trust amounts to sharing an encryption key. If there are n such authentication servers then approximately n2 keys will be required to facilitate all possible interdomain communications. Then for 500 domains, over 124,000 keys will be required. One solution to this explosion of interdomain keys is to arrange the domains into a trust hierarchy , such that keys need only be shared by authentication servers that are adjacent in the hierarchy. For example, if we had exactly 63 authentication servers ASi , we could order them as the nodes of a complete binary tree with 5 levels, such that ASi and ASj only share a key if they exist in a parentchild relationship in the tree. In general, if there are n authentication servers, they can be embedded into a complete binary tree on dlog ne levels, requiring approximately n keys to be exchanged. The trust hierarchy where all pairs of authentication servers share a key is called a at hierarchy . On the other hand, in the binary tree trust hierarchy just mentioned, two principals Pi; Pj must follow a chain of trusted links in the tree to establish authentication. Let ASi $ ASj indicate that ASi and ASj share a secret key. Then for Pi and Pj to have authenticated communication there must exist a sequence of d + 2 authentication servers ASi ; ASa1 ; ASa2 ; : : :; ASad ; ASj (1) such that

(1) Mechanism Independence: may be used with public or private key encryption methods. (2) Protocol environment independence: independent of the underlying communicationprotocol used in the distributed system (say RPC). The typical use of the GSS-API will be to add security services to a communication application, say some RPC based communication. The application passes and accepts tokens from the GSSAPI which it sends down the communication channel to be interpreted by another instance of the GSS-API at the receiver. The GSS-API consists of approximately 20 programming calls (headers) for which their are bindings in the C programming language available. The Internet Engineering Task Force Common Authentication Technology Working Group is chartered to standardize the GSS-API speci cations. Initially the GSS-API was intended to provide interoperability between environments based on Kerberos and the DSSA, and more recently, DCE.

Interdomain Authentication As indicated, the AS is responsible for administering information relevant to authentication in its domain. The domain is likely to have its own security policy, such as the lifetime of a ticket before it expires, to be enforced by the AS and associated trusted components. The security information for a principal Pi is stored in its home or native domain. A distributed environment is expected to consist of several domains, each with an instance of a distinct and autonomous AS, denoted ASi . Communication between principals with the same native is known as intradomain communication, while communication between principals from distinct native

(1) ASi is the AS for Pi and ASi $ ASa1 , (2) ASak $ ASa(k?1); 2  k  d, (3) ASj is the AS for Pj and ASj $ ASad . We will call a series of authentication servers from eq. (1) that satisfy conditions (1)-(3) an authentication path . Note that d is bound as d  2  dlog ne for the binary hierarchy, while in a at hierarchy d is always zero as ASi $ ASj for all Pi; Pj . Clearly there is tradeo between the number of 5

key pairs required in the system is n for n principals, and if public keys can be retrieved from a directory then no additional keys are required for principals to communicated securely. In the scenario described above there needs to be some repository (possibly central) of public keys that can be accessed by the principals of the system, referred to as a Directory. This concept has been formalised in the development of the X.500 standards, particularly in the X.509 annex [1] which de nes the format of information stored for each principal in the Directory and the protocol used to retrieve it. The information stored in the Directory for each principal is called a certi cate for that principal and has the following general form:

shared keys required against the length of an authentication path. Both Kerberos and DCE use

at trust hierarchies and for this reason do not scale well with respect to key management. Future versions of both these systems are likely to impose some additional structure on the trust hierarchy to reduce the burden of key management.

Certi cates Authentication paths are a means of extending trust between principals beyond the initial trust relations implied by passwords and shared keys. The need for authentication paths is related to the keying method used in the underlying encryption services. Private key systems, such as DES, required the two communicating parties to share a common key. In Kerberos and DCE which are based on DES, the only advantage of a structured hierarchy over a at hierarchy is the number of initial keys required to establish Pj $ Pi. In both systems, if all pairs of principals are to communicate then approximately n2 keys must be established (swapped). Public key systems [5, 4] are a means of having a relatively small number of initial keys and a small number of keys for all principal pairs to communicate. The idea is that each principal Pi has a secret key D(Pi ), the decryption key, and a public key E (PI ), the encryption key, such that D(Pi ) decrypts messages encrypted with E (PI ). The keys have the property that it is computationally infeasible to compute one from the other, and so the public key can be published in a readable directory without threat of compromise to the secret key. For example, in RSA [22], the diculty of recovering the secret key from the public key is based on the the apparent intractability of factoring a given integer into primes. At the moment, general integers of about 120-130 decimal digits can be factored in a reasonable amount of time, but 200 decimal digits integers are considered safe from being factored. If Pj wishes to send a message M encrypted to Pi, Pj recovers E (PI ) from the directory, and uses it as the encryption key for the message M . Pi can then recover M by using the secret key D(Pi ). Note that under this sytem the number of secret/public

Signature Issuer name Validity Principal name Public key of Principal

The certi cate is produced by an issuer for a principal. The issuer uses their secret key to create a signature on the certi cate which can be veri ed by using the issuer's public key. The validity eld typically indicates the length of time for which the certi cate (the public key) is valid, and at that time the certi cate must be reissued (resigned). As might be suspected, it is not practical to assume that there is a single instance of the Directory, but rather a collection of independent directories re ecting di ering security domains. A certi cate authority (CA) is a principal that is responsible for maintaining certi cates for a set of principals, where some of these principals may themselves be CAs. A trust hierarchy is induced by this certi cate relation in that all principals are then subordinate to some signing CA. Principals implicitlytrust their CA and the public key of the CA is assumed to wellknown (say, regularly broadcasted or published in a newsgroup), so that certi cates produced by the CA can be checked (the signature checked). Assume now that Pi wishes to obtain the public key of Pj . If they both trust a common CA then the certi cate for Pj is retrieved from the CA and the signature checked by Pi . On the other hand assume that Pi trusts CAi as a CA and Pj trusts CAj as a 6

CA. In this case the public key for Pj must be retrieved from CAj in a manner that Pi trusts. This problem is solved by a certi cation path , which is similar to the notion of an authentication paths. Let CAi ! CAj indicate that CAi has issued a public key for CAj . Then an certi cation path is de ned as

CAi; CAa1; CAa2; : : :; CAad; CAj such that

identify the identity of a principal Pi . Often authentication is used as the rst step in determining if a principal may be granted access to a service that they are requesting. The second step, after authentication, is authorization , which is the actual process of deciding if a principal is given access, and uses the information made available from the authentication step. In DCE for example, the authentication step may yield the name of the principal requesting a service, and in addition, the (administrative) groups that they belong to. For example, a principal Pi who belongs to the teacher group may be given access to the service of updating class marks. This scenario is the basic exchange in the clientserver model. More generally however, to ful ll a client request a server may have to contact several other servers. For example, a client may request that a certain le be printed, requiring a call to the File server and possibly an additional call to a Print server by the File server on behalf of the client. If there are permissions associated with the use of the Print server and the File server is acting on behalf of the client, then the File sever must temporarily take on the access rights of the client to ful ll the service. This process is known as delegation , when one principal (the File server) is acting as a proxy for another (the client). In this example the chain of delegation was short, but it is conceivable that several servers may be involved in ful lling a request, each depending on the access rights of the client, which must be passed to these servers. There are several papers that discuss protocols for delegation (see for example [8, 26]). Apparently there is no simple or elegant solution to delegating rights, even when considering the use of public keys. The main diculties are

(2)

(1) CAi is the CA for Pi and CAi ! CAa1 , (2) CAa(k?1) ! CAak ; 2  k  d, (3) CAj is the CA for Pj and CAad ! CAj . The certi cation path establishes a chain of public keys beginning with the trusted CA CAi and ending with CAj , thus establishing a collection a certi cates which authenticates the public key of CAj . With an authentic copy of CAj 's public key, Pi can accept the signed certi cate from CAj for Pj 's public key. So public keys are retrieved by following trusted links in the trust hierarchy, similar to authentication paths for private keys. In general to nd such a path for authentication or certi cation between two principals, a path is followed to their least common ancestor in the trust hierarchy. However this presupposes that there is some direct method for determining this common ancestor. To facilitate this, certi cate based systems such as Privacy Enhanced Mail (PEM) [12] embed the trust hierarchy in the naming hierarchy so that certi cation paths are easily determined. However there are reasons for not subordinating the trust hierarchy to the naming hierarchy, mainly that trust is not naturally implied by the ordering imposed by naming. The problems of this approach were recently highlighted in the PASSWORD project [13].

(1) How are partial rights associated with a principal to be delegated? (2) Once rights are delegated, how are we to guarantee that these rights will only be used for the service that is requested?

Delegation

(3) How are delegated rights withdrawn or revoked from a principal?

The function of authentication is to unambiguously 7

[3] D. E. R. Denning and G. M. Sacco. Timestamps in key distribution protocols. Communications of the ACM, 24(8):533{536, 81. [4] W. Die. The rst ten years of public key cryptography. proceedings of the IEEE, 76(5):560{577, 1988. [5] W. Die and M. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, 22(6):472{492, 1976. [6] W. Die, P. C. van Oorschot, and M. J. Weiner. Authentication and authenticated key exchanges. Designs, Codes and Cryptography, 2(2):107{125, 1992. [7] P. Dorey. Security management and policy. In W. Caelli, D. Longley, and M. Shain, editors, Information Security Handbook, pages 27{74, 1991. [8] M. Gasser and E. McDermott. An architecture for practical delegation in a distributed system. IEEE Symposium on Security and Privacy, pages 20{30, 1990. [9] D. Gollmann, T. Beth, and F. Damm. Authentication services in distributed systems. Computers and Security, 12:753{764, 1993. [10] L. Gong. Using one-way functions for authentication. ACM Computer Communication Review, 19(5):8{11, 1989. [11] L. Gong, M. A. Lomas, R. M. Needham, and J. H. Saltzer. Protecting poorly chosen keys from guessing attacks. IEEE Journal on Selected Areas in Communication, 11(5):648{ 656, 1993. [12] S. Kent. Internet privacy enhanced mail. Communications of the ACM, 36(8):48{60, 1993. [13] P. Kirstein and P. Williams. Piloting authentication and security services in the PASSWORD project. Computer Commincations, 17(7):519{531, 1994. [14] A. Liebl. Authentication in distributed systems: a bibliography. ACM Operating Systems Review, 27(6):31{41, 1993.

Conclusion In this paper we have discussed several of the main issues related to security in distributed computing, each stemming from the basic problem of authentication. We have taken this approach as many security problems can be solved if a secure protocol is given for authenticating principals. It is likely that Kerberos will become the industry standard authentication scheme, either as a stand-alone piece of software, or incorporated in more general secure environments such as DCE or the GSS-API.

Author Pro les

Dr Luke O'Connor has a PhD in cryptography and is currently employed as a research scientist in the Co-operative Research Centre (CRC) for Distributed Systems Technology (DSTC). His speci c interests include cryptography, security architectures and security in distributed systems. Mr Gary Gaskell is a research associate with the Co-operative Research Centre (CRC) for Distributed Systems Technology (DSTC). He has a computer science and engineering background with interests in computer security and cryptography. Professor William Caelli, FACS & FTICA, is currently the head of the school of Data Communications, Faculty of InformationTechnology, Queensland University of Technology. Prof. Caelli was previously the head of the Information Security Research Centre at the QUT. He has had over twenty years experience in computer security.

References

[1] CCITT draft recommendation X.509. The directory service, version 7, 1987. [2] D. Davis and Swick. R. Network security via private-key certi cates. ACM Operating Systems Review, 24(4):64{67, 1990. 8

[15] J. Linn. Generic interface to security services. Computer Commincations, 17(7):483{ 491, 1994. [16] S. P. Miller, C. Neuman, J. I. Schiller, and J. H. Saltzer. Kerberos authentication and authorization system. In Project Athena Technical Plan, page section E.2.1, 1987. [17] R. Molva, G. Tsudik, E. Van Herreweghen, and S. Zatti. Kryptonight authentication and key distribution. In proceedings of ESORICS '92, 1992. [18] R. M. Needham and M. Schroeder. Using encryption for authentication in large computer networks. Communications of the ACM, 12(21):993{999, 1978. [19] R. M. Needham and M. Schroeder. Authentication revisited. Operating Systems review, 21(7), 1987. [20] D. Otway and O. Rees. Ecient and timely mutual authentication. ACM Operating Systems Review, 21(1):8{10, 1987. [21] R. L. Rivest. The MD5 message digest algorithm. RFC 1321, Internet Activities Board, Internet Privacy Task Force, April 1992. [22] R. L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public key cryptosystems. Communications of the ACM, 21(2):120{126, 1978. [23] W. Rosenberry, D. Kenny, and G. Fisher. Understanding DCE. O'Reilly and Associates, Inc., 1992. [24] M. Satyanarayanan. Integrating security in a large distributed system. ACM Tranactions on Computer Systems, 7(3):247{280, 1989. [25] J. J. Tardo and K. Alagappan. SPX: Global authentication using public key certi cates. Journal of Computer Security, 1(1):295{316, 1992. [26] V. Varaharajan. An analysis of the proxy problem in distributed systems. IEEE Symposium on Security and Privacy, pages 255{275, 1991. 9