CTES based secure approach for authentication and authorization of ...

International Conference on Computer & Communication Technology (ICCCT)-2011

CTES based Secure approach for Authentication and Authorization of Resource and Service in Clouds

Sanjeev Kumar Pippal

Aruna Kumari

Dharmender Singh Kushwaha

Department of Computer Science and Engineering, MNNIT Allahabad, U.P., India [email protected]

Amar Nath and Shashi Khosla School of Information Technology, IIT, Delhi, India [email protected]

Department of Computer Science and Engineering, MNNIT, Allahabad, U.P., India [email protected]

with some additional functionality using collaborative trust model [10, 11]. We compare the proposed approach with the overhead concerned with various messages used in this model for the above said functions. In the following sections, we start with a brief summary on the previous work in section II. Section III enumerates the proposed modifications to the Kerberos. It provides an overview of the CTES (Collaborative Trust Enhanced Security) model for distributed systems and the messages used in that model. The results and conclusion are covered in section IV and section V, respectively.

Abstract—Cloud services are generally deployed in dedicated machines within Data-center. A cloud using distributed services and voluntary resources to build up its data center, where storage and computational resources of participating individual machines are harnessed non-intrusively, providing security to resources, services and users are primary objectives. Authentication and authorization are keys to any security mechanism. In this paper, we have made an attempt to address the associated concerns through an authentication and authorization model for a cloud computing paradigm. The paper also describes an improvement over traditional Kerberos protocol to authenticate the users and to access the services and resources in cloud, such that offsets certain limitations of Kerberos. Keywords- Cloud, Services, Authentication, Authorization, Kerberos.

I.

INTRODUCTION

Cloud computing is a computing paradigm fig. 1 where services and data reside in common space in scalable data centers, and the services and data are accessible via authentication. When resources and services are distributed geographically and applications and data-center spans over many computing resources, providing security to users, application and resources are of primary concern. Many problems in a cloud, such as data storage, data transfer, automation of information processing, and complex problems solving are entrusted on the protection mechanisms. Several security policies are used to govern these components.

Figure 1. Cloud Computing Architecture

II.

In our scenario the volunteer nodes participate to from an active working set. Since the nodes in the working set are changing with time therefore user authentication and authorization are critical issues and numerous researchers have carried out their work with different authentication protocols like Kerberos, PKI (Public Key Infrastructure), X.509, etc.

A. Kerberos A lot of research work has been performed on Kerberos by several researchers because Kerberos is a time-tested and widely used lightweight protocol based on inexpensive symmetric key cryptography [2-4, 7-9]. It allows a user to be authenticated once and later connect to application servers within the Kerberos realm without authenticating again for a period of time. It is a distributed authentication service that allows a client running on behalf of a user to prove its identity to a verifier (an application server, or just server) without sending data

Another issue is about the basis for authentication and access control? It can be the user identity, the network address the user operates from or the cloud service the user is invoking, i.e., the access operation. In this paper, we focus on Kerberos-style authentication and authorization

978-1-4577-1386-611$26.00©2011 IEEE

PREVIOUS WORK

444


identity with AS. As a result, client gets the encrypted TGT and then requests the TGS for getting a ServiceGranting-Ticket (SGT) before accessing service. This request includes the ID of Server. These tickets are used to establish secure logical communication channels between clients and servers by performing mutual authentication.

across the network that might allow an attacker or the verifier to subsequently impersonate the principal. The predominance of Kerberos involves independent development platform, high-speed communication of authentication, mutual authentication between entities and transferable relationship of trust, and a relatively strong compatibility with heterogeneous domains, which may adopt various trust policies [1, 5]. Kerberos, based on symmetric key algorithm, enables the establishment of mutual trust between the two communication sides through session key and ticket authorization. [1]. Chuang [6] gives a definition to the trusted intermediaries as the systems that authenticate clients and servers such as the Certificate Authorities in public key based systems and KDC (Key Distribution Center) in Kerberos. Trusted intermediaries face a challenge of scalability as the number of users that require authentication increase. If the challenge is not met, users can experience significant delays in authentication, or be forced to accept an increase in risk or fraudulent credentials. Chuang [6] describes a method for fully distributed authentication using public key cryptography within the Kerberos ticket framework; to enhance security and scalability by distributing most of the authentication workload away from the trusted intermediary to the communicating parties. Phillip [2] includes a pre-authentication approach as a Kerberos extension. It states Kerberos as a time-tested protocol and introduces PAS (Pre-authentication Server) in its approach that determines which users can authenticate which principals. It involves two additional messages before making request to Authentication Server, as a mapping of users to Kerberos principals. The authors in [6] have used Kerberos for distributed authentication using public key cryptography. It distributes the authentication workload from the trusted intermediary to the communicating parties. For this, it uses the features of both certificates used in PKI and KDC of Kerberos in the form of Public key based Kerberos for Distributed Authentication (PKDA). It involves at least 3 additional messages for accessing the services.

Figure 2. Messages used in Kerberos

As discussed above, Kerberos performs several functions through a sequence of message exchanges. A brief description of these messages is illustrated in fig. 2 and the syntax listed in table I and the acronyms are explained in table II. TABLE I. a)

Authenticating the identity and obtaining TGT

à AS m1 = Cà = [IDC, IDTGS, TS1] m2= ASà àC = E (KC, [KC,TGS, IDTGS, TS2, lifetime1, TicketTGS]) TicketTGS= E (KTGS, [KC,TGS, IDC, ADC, IDTGS , TS2, lifetime1]) b)

Obtaining Service-granting-ticket

à TGS m3= Cà = [IDS, TicketTGS, AuthC1 ] AuthC1 = E (KC,TGS, [IDC, ADC, TS3]) m4= TGSà àC = E (KC,TGS, [KC,S, IDS, TS4, TicketS]) TicketS = E (KS, [KC,S, IDC, ADC, IDS, TS4, lifetime2])

B. Kerberos Protocol Kerberos is a network authentication protocol and consists of Authentication Server (AS), Ticket-GrantingServer (TGS) as the part of Key Distribution Center (KDC) and Kerberos Authentication Database. The complete Kerberos authentication protocol also covers the client and server. Kerberos authenticates the client identity for which multiple messages are exchanged between different entities of the system. Client makes a request for Ticket-Granting-Ticket (TGT) to AS with its own ID, ID of TGT and a timestamp, and authenticates its TABLE II.

MESSAGES USED IN KERBEROS

c)

Obtaining service

àS m5= Cà = [TicketS, AuthC2] AuthC2 = E (KC,S, [IDC, ADC, IDS, TS5, lifetime2]) m6= Sà àC = E (KC,S, [TS5+1])

NOTATIONS USED IN THE MESSAGES OF KERBEROS

IDC = ID of client.

TS1 = Timestamp

IDTGS = ID of Ticket-granting Server.

KC = Secret key or password of client shared with AS.

KC, TGS = Session key shared by client and TGS.

KTGS = Secret key of TGS shared by TGS and AS.

445


lifetime1 = Informs client of the lifetime of the TicketTGS.

TicketTGS = Encrypted Ticket for TGS – a proof that client has been authenticated.

TS2 = Timestamp

ADC = Network address of client.

IDS = ID of Server S.

TS3 = Informs TGS of time AuthC1 was generated.

AuthC1 = Authenticator generated by client to validate TicketTGS.

KC, S = Session key shared by client and Server

TS4 = Timestamp

TS5 = Timestamp mentioned in AuthC2.

TicketS = Ticket for Server – a permission to provide service to client.

AuthC2 = Authenticator generated by client to validate TicketS.

KS = a secret key of Server shared by Server and TGS.

lifetime2 = lifetime of the TicketS – prevents replay after ticket has expired.

TS5+1 = incremented timestamp – assures that this is not a replay of an old reply.

III.

its interface and access information to the service registry maintained by Agent. The major functions of the various components of the CTES model are enumerated into the following classification: 1. Registration of users with Superhost, 2. Obtaining TGT from AS, 3. Obtaining SGT from TGS, 4. Obtaining server’s reference from Agent, 5. Registration of services with Agent and 6. Accessing service from Server

PROPOSED MODIFICATIONS TO THE KERBEROS

A. Overview to CTES model The CTES model represents a collaborative and synergetic trust approach where all the users are trustworthy and work under the mutual authentication and authorization to users with their dynamic nature of joining and leaving the distributed cloud. The model as shown in fig. 3 is based on hybrid approach that consists of four components: 1. Coordinators (Superhost and Agent) 2. KDC – Key Distribution Center (ASAuthentication Server and TGS- Ticket-Granting Server) 3. Server 4. Client

B. Messages used in the CTES model In our model, the messages involved for authentication and authorization are developed using the similar functionality as of Kerberos. As described in fig. 4 the complete client authentication process involves 4 messages (m1, m2, m3 and m4). In its first message, client requests AS for authentication where AS using m2 contacts Superhost to verify the client and to obtain password, IP address and trust level of client using m3 and the result of this process is TGT assigned by AS to client by m4. We are using 2 messages (m5 and m6) as shown in fig. 4 to obtain SGT and to authorize the client. Here, client makes a new request to TGS with TGT (obtained in

The coordinators and KDC are the reliable controller systems around which all the activities are scattered. There is a mutual communication between the controller systems. Superhost maintains records of the clients and the servers of the distributed service providers, monitors the life time of the clients and servers and also controls the other controller systems. Agent manages the registry of service provided by servers, monitors client’s behaviour, handles client requests for services and balances the load of servers.

message Figure 4. Messages used in proposed model

m4) and an additional message, known as m4) and an additional message, known as “authenticator”. In our architecture, after obtaining SGT (using message m6), client requests Agent instead of Server to get the list of services for which client is authorized, and the list of servers for a service, using messages m7, m8, m9 and m10. The client uses messages m11 and m12 to access the service from server.

Figure 3. Components of Proposed Model

The KDC is responsible for authenticating and authorizing the client when it requires a service. Client is a registered node of the system that can access the services and resources. The server creates a service and publishes

446


TABLE III. a)

MESSAGES USED IN CTES MODEL

= E (KC,TGS, [KC,A, ADA, TS4, TicketA])

Authenticating the identity and obtaining TGT

TICKETA = E (KA, [KC,A, IDC, ADC, ADA, TS4, LIFETIME2, TLC])

m1 = Cà à AS

c)

= [IDC, TS1]

m7= Cà àA

m2= AS à SH

= [TicketA, AuthC2]

= [IDC]

AuthC2 = E (KC,A, [IDC, ADC, TS5, lifetime2])

m3= SHà à AS

m8= Aà àC

= [PSc, ADC, TLC)

= E (KC,A, [TS6, LSER])

m4= ASà àC

m9= Cà àA

= E (KC, [KC,TGS, ADTGS, TS2, lifetime1, TicketTGS]) TICKETTGS= E (KTGS, [KC,TGS, LIFETIME1, TLC]) b)

Obtaining service

= E (KC,A, [SER, TS7])

IDC, ADC, ADTGS , TS2,

àC m10= Aà

Obtaining Service-granting-ticket

= E (KC,A, [TS8, LSR])

à TGS m5= Cà

m 11= Cà àS

= [TicketTGS, AuthC1 ]

= E (KS, [IDC, SER]) m12= Sà àC

AuthC1 = E (KC,TGS, [IDC, ADC, TS3])

= E (KCC, [RES])

àC m6= TGSà TABLE IV.

NOTATIONS USED IN MESSAGES OF PROPOSED SYSTEM

IDC = ID of client.

TS1 = Timestamp

PSc = Password of Client

TLC = Trust Level of Client

KC = Secret key or password of client shared with AS.

ADC = Network address of client.

ADTGS = Address of Ticket-granting Server.

KTGS = Secret key of TGS shared by TGS and AS.

lifetime1 = Informs client of the lifetime of the TicketTGS.

lifetime2 = lifetime of the TicketS – prevents replay after ticket has expired.

TS2 = Timestamp

KC, TGS = Session key shared by client and TGS.

AuthC1 = Authenticator generated by client to validate TicketTGS.

TS3 = Informs TGS of time AuthC1 was generated.

ADA= Address of Agent.

KC, A = Session key shared by client and Agent.

TicketA = Ticket for Agent – a permission to provide server reference to client.

TicketTGS = Encrypted Ticket for TGS – a proof that client has been authenticated.

TS4 = Timestamp

KA = a secret key of Server shared by Agent and TGS.

AuthC2 = Authenticator generated by client to validate TicketS.

TS5 = Timestamp mentioned in AuthC2.

TS6 = incremented timestamp – assures that this is not a replay of an old reply.

LSER = List of services as per the trust level of client

SER = Information about Selected service

TS7 = timestamp

TS8 = Timestamp

LSR = list of servers for the selected service

KCC = Secret key generated using client ID and IP address, and shared by Client and Server.

KS = Secret key generated using Server ID and IP address, and shared by Server and Client.

Res = Response from Server in terms of service

IV.

III (acronyms are explained in table IV), although Kerberos uses 2 messages each for authenticating the identity of client and obtaining TGT; for obtaining SGT; and for accessing service whereas our architecture uses 4 messages for authenticating the identity of client and obtaining TGT, 2 messages for obtaining SGT, 4 for obtaining reference of server from Agent and 2 for accessing service from server. The Superhost is involved

RESULT

A. Merits of the propose model over Kerberos Although, we use similar concept of authentication and ticket generation process of Kerberos but with few changes, Kerberos requires 6 messages whereas the proposed system works on 12 messages but provides new dimension of services. As illustrated in table I and in table

447


to authenticate the client for verifying the existence of client and to provide the required details of client (client password, trust level, stored IP address at Superhost) to AS. It reduces the overhead of keeping track of all the clients of distributed system in Kerberos Authentication Database (part of Kerberos). By using four additional messages for accessing service, we focus on the availability of services and servers of the distributed system that is not touched by any of the message of Kerberos. Here, Agent is involved for providing the reference of server to the client on the basis of the requested service. Before transferring message m8 to client, Agent analyzes the behaviour of client in the system along with sending intimation to Superhost to update the trust level of client. These additional features help in making our architecture efficient than Kerberos even when the number of messages increases. Almost messages are exchanged in encrypted form for the above said operations. It has been assumed that the communication channel between Controllers and KDC is secured. So, no need to encrypt messages exchanged between them. A relative discussion about the said issue proves that the proposed approach is efficient than Kerberos. 1) In the proposed system, initially the ID of TGS (in message m1) and ID of Server (in message m5) are not available with the client and it has been assumed that client (especially new client) is unknown to the system. If the system involves more than one KDC, client can face problem in selecting a TGS. Most of the times, the new clients are unaware about these trusted intermediaries so it becomes a limitation. In the proposed system, to maintain the initial privacy and to hide these intermediaries, these references will be provided to client whenever required, like Authentication Server provides the reference of TGS only when client authenticates its identity, in message m4, so that client can request TGS for SGT with TGT and authenticator. 2) In the proposed system, Kerberos authentication database at KDC is not required to maintain the user ID and password of all the users of the distributed system. Superhost accomplishes this task. Superhost maintains the record of all clients who may access services and thus required to authenticate. Instead of a big database for Kerberos authentication, a file is used to keep the secret keys for trusted intermediaries. It is easy to secure and makes the proposed system efficient. 3) In the proposed system, instead of providing the ID and IP address of Server system to access a particular service, TGS provides the reference of Agent system to client, as in message m6. Here, Servers are transparent to TGS. Agent works as another trusted intermediary that registers the services of servers. Client has to contact Agent before making any request to Server. 4) We are considering dual encryption at client and server side to maintain data confidentiality, briefly

described using messages m11 and m12. Client sends a request and payment (on server’s demand) to server for some service, as cipher messages encrypted using key generated with Server-ID and Server-IP. Server decrypts these messages and sends service to client in encrypted form using the key generated with Client-ID and Client IP. It ensures a trustworthy user and a trustworthy platform. A malicious user may alter the network address of a system to redirect the messages but due to both ID and IP address, messages cannot be decrypted. B. Offsetting Kerberos Limitations 1) Password Guessing Attack: Kerberos has limitation of password guessing attack. Since no authentication is required to request a ticket in Kerberos and unencrypted password is send to Authentication Server, the attacker can guess password and request many tickets. In CTES model this problem is resolved with the help of Superhost. Here, client does not transfer his/her password and its location to Authentication Server. AS takes this information from Superhost that verifies the client in the distributed network. Along with this, AS compares the extracted client IP address and the IP address stored at Superhost to authenticate the client. Hence, CTES model works against password guessing attack. 2) Service Registries: Service registries are the unique identifiers for services running on servers. In Kerberos authentication, every service must have a service registry so that clients can identify the service on the network. If a service registry is not set for a service, it is difficult to locate that service. Kerberos authentication is not possible if these services registries are not managed properly. In our collaborative approach, Agent has given the responsibility to manage and control these service registries keeping the knowledge of active and underloaded servers of the distributed network. 3) Platform dependence: Kerberos authentication relies on client functionality that is built in to the Windows Server 2003 Operating System, the Microsoft Windows XP Operating System and the Windows 2000 Operating System. It makes the use of Kerberos rigid. Our CTES model is implemented in JAVA RMI and Java has feature of platform independency that makes CTES model to work on multiple types of platforms. 4) Access Authorization: Kerberos gives the benefits only in terms of authentication rather than access authorization. This additional feature is handled in proposed CTES model using different controller entities. Kerberos (version 4 and version 5) and CTES model are briefly enumerated in table V. TABLE V.

448

KERBEROS AND CTES MODEL


Particulars Single Sign on

Kerberos V4 Yes

Kerberos V5 Yes

CTES Model Yes

Password guessing

Yes

Yes

No

Requirement of database for storing keys Adequate service registry maintenance Use of symmetric keys

Yes

Yes

No

No

No

Yes

Yes

Yes

Yes

Operating system dependency Mutual authentication between entities Access authorization

Yes

Yes

No

No

Yes

Yes

No

No

yes

V.

[4]

Wen Tei-hua, Gu Shi-wem, “An improved method of enhancing Kerberos protocol security”, Journal of China Institute of Communications, Vol 25 No. 6. June 2004, pp. 76-79. [5] Fred B. Schneider, Steven M. Bellovin and Alan S. Inouye, “Building trustworthy systems: Lessons from the PTN and Internet”, IEEE Internet Computing, November- December 1999. [6] Marvin A. Sirbu and John Chung-I Chuang, “Distributed authentication in Kerberos using public key cryptography”, in SNDSS, pp.134, 1997 Symposium on Network and Distributed System Security, 1997. [7] C. Neuman, T. Yu, S. Hartman, and K. Raeburn., “RFC 4120: The Kerberos Network Authentication Service (V5)”, Jul 2005. [8] Wen Tei-hua, Gu Shi-wem, “An improved method of enhancing Kerberos protocol security”, Journal of China Institute of Communications, Vol 25 No. 6. June 2004, pp. 76-79. [9] B. Clifford Neuman and Theodore Tso, “Kerberos: an authentication service for computer networks”, in IEEE Communications Magazine, volume 32, issue 9, pages 33-38, 1994. [10] Aruna Kumari, Shakti Mishra, D.S. Kushwaha, “A new collaborative trust enhanced security model for distributed systems”, published in International Journal of Computer Applications, (Iinternational Conference on Futuristic Computer Applications - ACM) vol. 1(26), pg 127 - 134, February 2010, Published by Foundation of Computer Science. [11] Aruna Kumari, Shakti Mishra, D.S. Kushwaha, “A collaborative trust enhanced security model for distributed systems services”, in International Conference on Advances in Communication, Network and Computing- CNC 2010, IEEE Computer Society, page 260-264, 2010.

CONCLUSION

The CTES model is briefly explained in this paper along with the messages involved in the process of user authentication and authorization for distributed cloud services. A Kerberos-style authentication and authorization has been proposed through a collaborative approach. The proposed model has been able to establish that the CTES model is more efficient than Kerberos despite of increase number of messages. A 3-level trust hierarchy is established for securing resource and services that reduces the Kerberos authentication database, storing the details of all the users of distributed cloud services and their respective secret keys with comparable message exchange. Apart from this, the overhead associated with Kerberos in keeping track of active users of the network has also been reduced. For all this, coordinator systems are introduced in the proposed model to make the approach more effective than Kerberos. It has also been ascertained that the various messages and the functionality used in CTES model overcomes the drawbacks of Kerberos like password guessing attack, platform dependency, etc. REFERENCES [1]

[2]

[3]

Ping Liu, Rui Zong and Sizuo Liu, “A new model for Authentication and Authorization across Heterogeneous TrustDomain”, in International Conference on Computer Science and Software Engineering, Volume 03, IEEE Computer Society, pages 789-792, 2008. Phillip L. Hellewell, Timothy W. van der Horst and Kent E. Seamons, “Extensible Preauthentication in Kerberos”, in 23rd Annual Computer Security Applications Conference, pages 201 210, 2007. Ching Lin and Vijay Varadharajan, “Trust based risk management for distributed system security- a new approach”, in Proceedings of the IEEE First International Conference on Availability, Reliability and Security, 2006.

449