A web service is a set-of-.programmable functions that could be invoked protocols, and consumed through some internet The design of Web services has been plagued with security flaws. Web services invocations could be executed on the fly with the invokers remain anonymous

Khoo, Vincent

Ling, Elvis,Ing Seng

English

Repository@USM

NON.REPUDIATION IN WEB SERVICES INTERACTIONS.Elvis Ling \tg Seng, Vincent Khoo Kay TeongInformation Systems Engineering Researtn GroupSchool of Computer SciencesUniversitiSains Mataysia, 11900 USM, pulau pinang, Malaysia.Email: elviscss@yahoo.com, vkhoo@cs.usm-.myABSTRACTA web seruice is a set-of-.prcgrammabte functions that oould be invoked and consumed through llrlme lntemetprotocols, The design of Web serwbes has been plagued with security flaws. Web seruices invocations coutd beexecuted on he fly with the invokers remain anonymous. The Web seruices creators tend to overlook the need tosecurely identify the identity of the Web seryrbes'consumers and the confidentiatity "ia int grity of the interactedentities and processes among the web seryrces. This papir aftempts to modet the potentiat threats andvulnerabilities that plague the interactions among Web seruices.' The proposed model is presented as a set of IJMLs:cluglcP diagrams that show the criticat points-where Web services intenctions couH pose a severe threat to boththe web servtbes consumers and creators. A! thg ena oitnii iaper, the need for identifying the entities andprocesses involved in a Web seruice interaction is hightighted'through the recoimenaaiioior possibte ioirepudiation capabilities in Web seryrbes.Keymords: web semice interaction, srRtDE, threab modelling, non-repudiation.1.0 INTRODUCTIONThe widespread use of the world wide web has created a common ground for many business organizations to tradeamong themselves regardless of their geographical locations. T|.rE woao W6e Web has inJeed "r"tlJ,invsuccessful stories for the business-entrepreneurs who trade on the new borderless "yueopa"". However, while theWorld Wide web is making significant tonfiibutions to tris progfus", tn"r" remain many challenges to its furtherdevelopment into a safe environment where business trading ""i rt"pp"n more securely. One area that needs anurgent attention is in Web services interactions.For the Web Services to-achieve its full potentials. in.improving business productivity, at least three key securityrequirements must be fulfilled namely, cohfidentiality, i{dgrity, "anJ avairaoitity I1l pt:' connoentiaritv proteGln6identity of users involved in .requesting and consuming wju services. However, confidentiality does not mean theanonymity of users as.it is happening in the cunent irueb services interactions. lntegrity or iveo servi;";; ;ltlimited to the preservation of messagl authenticity, which indicates that the message returned by a Web serviceprovider was not modified when itwas being transmitted to the consumer. Availability-or weo services will ensure itscontinuity in providing services to its service-consumerc.This paper focuses on preserving the users and transactions confidentiality with some aocounting mechanisms, andhighlighting the issue of anonymbus users in Web services interactions and how the capabilities of non-repudiationmay resolve the problem.2.0 WEB SERVICES INTERACTIONSA Web Service can be easilylocated by making a request to a Web service registry [3], which acts as the centralizedsystem to connect web service consumers witn web service prouia"ts. Initi;lly,'is;rvice provioer wilt regi;ter itsWeb services at the Universal Description Discolery Integration (Uooi) registry. 'UDDI will process the Web servicesand publish the services into a searchable registry system-.Whel a request to discover and describe a Web service is made by a user, UDDI will locate the named seMce in itsdatabase' lf the service is found, UDDI will post a list of avaihbb s6rvice providers who may safisry the user request.i!.!!U .n9i$ 9f the request, the return message to the user js wrapped in a web servile Description Language(WSDL) to hetp the user to tocate the required s6rvice provider tq iStl-'The user will continue the interaction worlcflow by making a simple object Access protocol (soAp) call to request theservice provider to process the data contained in_tne-missage talso rho*n as Web service invocation). The serviceprovider is designed to response to this request l3l I4l upon i"cLiuing iiano will proceed to piocess it and then retumthe result to the user, thus ending the Web'service-int6r:action. The iiteraction model is shown in Fig. 1.365Sgrdcsprovltbtpt€aatdn$!tlgtdrd,rnrdm$rFig. 1: A Web service interaction model3.0 THREATS IN WEB SERVICES INTERACTIONSAs shown in the previous section, a web service provider has no knowledge of the service consumer. Fig. 2 showsthe web service interaction model in Fig. 1 translated into a sequence diagram. From the diagram, one simpleunoersianoing that could be derived is that a web service is invoked and consumed without the knowledge o! the;;rG frwiJer. By the n"t*" or itr design, the service provider's main concem in a web service interaction is toprocess the service request regardless of the request origin'Ihruoft!-rendo{snlc.) !Fodd{ccrvtr)---frDe-be Sgn lce-nedCntIII--{IIIFig. 2: Th! return message indicates one-way communication by service providerAs a result, the communication model between a service oonsumer and a service provider is a one-waycommunication, as inoiciieo uv tn" red dotted anow in Fig. 2, where the Web service interaction ends at that point.The absence of a service a"rno*t"og"rent from the useri made it impossible for the service provider to identify theuser identity.366According to the STRlDE.threat molel t6l, six categories of threat can be identified in a web service interactionnamely: spoofing, Tampering, Repudiatioh, Informatioin oisclosure, Dlnial of service and Elevation of privilege (henceth9..9cr9nYT STRIDE). These threats are identified at eacn flini oi " w"o service interaction, and they invotve ail theentities in the interaction.Referring to Fig' 3, the jdentities of service1egistry and service provider can be spoofed (number 1), where fraudservices provided could lead to stolen data. Daia iniegrity 9gn oe ffiardized while in transit (numb er 2),Iorexamplewhen a service provider's valid services are tamperJd ivr'ire ueihg lent to the service registry. Repudiation threat(number 3), which this paper attempts to mitigate, is identified whEn the user denied that"the service provider hasindeed processed the request and returned thi results. tn tnis case, ine service provider is on the losing side as thereis no mechanism to record the proof that the services have indeed been provided to the user.As web services travelthe network in XML text, its content is exposed while being exchanged between the entities ina web service interaction (number 4). The denial-of-service lnulnuer s; and elevation of privilege (number 6) are thethreats more commonly found at ine weo seryers that host fire weo services, which could render servicesunavailabili$ or permanent damages on the web seryers, Arfirough it is agreeable that all these threats are presentin a web service interaction, this p?per focuses onry on tne tnreattr repudiation.oH Ssvica Provil* Sav*te fu*Wti)r\-/ |,___ __YYItmpt(o-rarvica(saryhs) ;AtoProvkl{sorvicalFig. 3: Threats identified in a web r"ri"i interaction based on srRrDE threat moder Iil3J"05*""':"$:J1""1fl:::j:tj_l-: y:?^l"yiTllleraction because-rhere is no mechanism for acknowledsins rhatln:,^":l:Tg?:,:l:jj,i:flTq9g,t" service to.e. service codfi;;i4: rhe absence or " ,""nJn"ii#il?"#1il!H:?,::TlTi,i:fg:1,:lti 1111",::I?9::_o.U:,I;""t.-Aril;;;l i#;"i;6iliJfi"i'ilj'[!'lijlil''ii,'L?Hffif;interactions.11,"":=9"-ML sisnarure r8t, the ,"" o'r t'i. r";i";;i.-w$';ffi,;#il!;;iffiffffi"Hffi?'irT:'Hil11#ilTffi,!|tfitJfl 'n ttt' there are other threats and challenges that are bound in rhe context of web service security,Message security between Web service intermediariesUnauthorized a@essParameter injectionMessage eavesdropping and replayFrrewails evasionPlatform immaturitya.b.c.d.e.f.367@-lISer,rhe Prot/der 1 SgMcs PIQtyl(b 2Redmct(d-s€Mce, nry*addt€E*)lnmke-ssttics(candcalProride-seMce{rrvil)P!6r6.-crdce{€aillac)1lllFig. 4: Threat entry points in Web services InteractionsThe threat analysis on a Web service interaction shows several threat entry points as^shown in Fig' 4' Firs-tly, theattackers involved in a Web service interaction will perform Domain Name System (DNS).cache poisoning on ServiceFrouioe,. 1 so that att weu services deliveries witt ue redirected to the aftacker. This aftack is based on thevulnerability exists in a DNS system that may allow the aftacker to send invalid packets of data to be cached into theDNS server that belongs Service Provider 1.When a user makes a service request to a valid service provider, the request may be forwarded to another serviceprovider for further processing. A spoofing threat point can be identified here where the request made by the usermay be forwarded to a rane iJrvice provide-r, which can be an attacker itself. The attacker could have crafted a returnr"3""g" that may intenly damage ihe systems located at the user end. This is identified as a tampering threat'Back to the previous scenario, when Service Provider 1 delivers a service back to the user, the delivery path isLoireaec to the attacker, thus creating a repudiation attack whereby service Provider 1 claims the service deliverywhen it actually n"u"r" ,L""h"s the use-r. The interactions with threai of repudiation as depicted in Fig. 4 shows thatthe attack can 'be alleviated with a mandatory proof of delivery and proof of receipt'4.0 NON.REPUDIATIONNon-repudiation is the term used in describing the nature of a system where participation and non-participation in anelectronic event is oe"meo unoeniable [10]. iwo main capabilities of non-repudiation are-to provide proof of deliveryiiii "il proof of r"""ipilut. rnerefbre the goal of non+epudiation is to provide a fair exchange in electronictransactions whereby ttie iource that initiated itransaction can be protected from a fraudulent allege made by itsdestination and vice versa [13] [14]'4.1 Non Repudiation in Web Servicesln practice, every computer that communicates via a network system should be accounted for the oourse of actionstaken along tne neturoir patn. since the wild nature of world wide web attracts malicious computer users to !119chaos into the cyberspab, it is therefore acceptable that the presence of some accounting mechanisms in WebServices should reOucd the risk of consuming Web Services anonymously'The use of an accounting system in the Web services interactions could prevent the consumption of Web servicesanonymousty as snown l"n iig. s. in" differences of this interaction are the service rcknowledgement made by theservice consumet and the recording of user request at the initial stage of service invocation'368Prudd.(ryl,ic.lAch'ou'b6.rrEntIIRrdqryyb.Jrrovtdcd)IRscor{Ecktoi'ffigrrxt)Web SaMce AccqrntinoReconftE*e-q.uyllllFig. 5:A Web service interaction with non-rLpudiation capabilities4.2 Accounting Mechanisms and Service AcknowledgementsThe accounting mechanism in Web services interactions should comprise of a log archival [1fl and other non-repudiation capabilities which include receipt acknowledgement and ielivery notif[ation. Rs itrown in iig.-s,whenever the users make up a service query to the seilice n"gi"iry, the {uery is recorded into a web serviceaccounting fYstgm repository. lf the query produces results, tne seirice Registry will retum a list of service providers,while recording this into the accounting syiiem repository.Jlt91' tne user proceeds with the interaction by invoking a service from the service provider. As the user is theinitiator of this interaction, every action taken s1ri1! ue r"6ro"o a" part of the repudiati6n tnreat mitigation, providingan evidence base for future references for both the user and the service provider. When the service provider hasprocessed the data as contained in the use/s request, the action is recorded in the accounting system as a proof ofdelivery.However, the interaction flow does not end there as shown in Fig. 5, where the service provider waits for a serviceacknowledgement from the user once the data has.been comptelely processed. The acknowledgement sent by theuser is in fact a proof of receipt that will _be keptby the servicefr*ilri. The accounting system will also have a copyof th.is acknowledgement in con.esponding td th6 proof or oeiivery-tnat was previousiy iecorded when the serviceprovider delivered the service to the user.5.0 CONCLUSIONAND FUTURE WORKldentiffing threats is crucial in de.veloping secure web services interactions. With the growing number oforganizations leveraging the capabilities of Web services, it has been noted that the use of transaction logs is notenough in-securing the online business transactions. More robust accounting mechanisms should be implemented insecuring Web services interactions. Moreover, the capabilities of non-repuJiation should be incorporated into everysystem on the Web.More intensive research work needs to be done to establish the requirements of a new vercion of accountingmechanism that surpasses the outdated audit log that has become a miinstream for any system that needs rc r"eitrack of electronic transaction interchange. one immediate research problem is how [he'entities involved in webservices interactions record their activities and how these records could be secured and managed. Therefore, it ishoped.that the design and implementiation of a robust and trustworthy accounting mechanism coutd thwart theattempts to repudiate the services provided by service providers.llJlelII Servta Pruvider ItliI servic" n"oirrru III369REFERENCES111I2lB., Roberta, CISSP Security Management and Practices, QUE Publishing, December 2002'R., J., Boncella, Web Services and Web Service Security, Proceedings of the Americas Conference inInformation Systems, NY, August 2004'l3l 8., David, H., Hugo, M. C., Francis, N. Eric, C., Michael, F., Chris, and O., David, Web Service Architecture'W3C Working Group Note, February 2004.I4l S., Vinoski, Web Services Interaction Models, Part 1: Current Practice, IEEE Intemet Computing 6(3)' May2002, pp.89-91.t51 S., Vinoski, pufting the',Web" into Web Services: Interaction Models, PartZ IEEE Internet Computing 6(4)'May 2002, PP. 90-92.161 L., Desmet, 8., Jacobs, F., Piessens,_and W., Joossen, Threat Modelling for W9b Services Based WebApptications, eighth iFtp rc-o rc-t t Conference on Communications and Multimedia Security (cMS 2004)'September 2004, UK.I4 J., Onieva, J., Zhou and J., Lopez, Non-repudiation protocols for multiple entities, Computer Communications,27(1 6):pP. 1 60&161 6, October 2004.tgl J., Rosenberg and D., Remy, Securing Web Servic99.1vr!n WS-security - Demygtlfying WS-Security' WS-poticy, SAML;XML Signature and XMLEncryption, SAMS Publishing, Indianapolis, 2004.tgl J., Holgersson and E., Soderstrom, W_eb Service Security - Vulnerabilities and Threats within the Gontext ofWS-Se-curity, fn" +6bonf"r"n"" on Standardization and Innovation in Information Technology, pp- 138-146'September 2005.l10l J., Zhou and D., Gollmann, Evidence- and Non-repudiation, Joumal of Network and Computer Applications'Academic Press Ltd., 1997' pp. 267-281.t11l M., Wichert, D., Ingham, and S., Caughey. Non+epr]_diation Evidence Generation for CORBA using XML,Proc. IEEE Annual corp. security Applications conf., Phoenix, usA, 1999.1121 T., Coffey, p., saidha, Non-repudiation with mandatory proof of receipt, computer communication Review,26(1), PP6-18. 1996.t13l J., Zhou and D., Gollman, A fair non+epudiation protocol, Proc. 1996 Symp. on Research in Security andPrivacy, pp.5$61, Oakland, CA' USA' 1996.l14l J., Cederquist, R., Corin and M., Torabi Dashti, On the Quest for lmpartiality: Design and Analysis of a FairNon-repudiation irotocol, Lecture Notes in Computer Science 3783, Proceedings of 2005 lnternationalConference on Information and Communications Security, pp.27-39, Beijing, China, December 2005.l15l M., H., Shao, A Study on Chain of Evidence Supporting Disputes Resolution in Electronic Commerce, PhDThesis, National Chiao Tung University, Taiwan' 2005'BIOGRAPHYElvis Ling Ing Seng graduated with a Bachelo/s Degree in Computer Science from Universiti Sains Malaysia in Mayzooo. Cu'ire,itry, njii r"gi"t"r"o as a part-time reseirch student in the Master of computer science programme whileworking in Iniel. His iesearch interests include security mechanisms and countermeasures for Web-basedapplications.370

Non-Repudiation In Web Services.

http://eprints.usm.my/9495/1/NON-REPUDIATION_IN_WEB_SERVICES_INTERACTIONS.pdf

Non-Repudiation In Web Services.

Abstract

Similar works

Full text

Available Versions

Repository@USM