1、WebDAVA: An Administrator-Free Approach To Web File-SharingAlexander Levine Vassilis PrevelakisAlexander.Levinedrexel.edu vpdrexel.eduDrexel University Drexel UniversityJohn Ioannidis Sotiris Ioannidis Angelos D. K sotirisdsl.cis.upenn.edu angeloscs.columbia.eduAT that is, checking whether a propose
2、d action con-forms to policy. Actions are specified as a set of name-valuepairs, called the action attribute set. Policies are writtenin the KeyNote assertion language and either accept or re-ject action attribute sets presented to the policy engine (non-binary results are also possible, but we do n
3、ot consider themhere). Policies can be broken up and distributed as creden-tials, which are signed assertions that can be sent over anetwork and to which a local policy can refer when mak-ing a decision. The credential mechanism allows for arbi-trarily complex graphs of trust, in which credentials s
4、ignedby several entities are considered when authorizing actions.Group-based access is handled by issuing the appropriatecredentials to all the group members. Furthermore, sub-groups can be created at any level in the hierarchy.Authorizer: ADMINISTRATORS_PUBLIC_KEYLicensees: ALICES_PUBLIC_KEYConditi
5、ons: (AppDomain = “WebServer“) Comment: Owner (Alice) can do anything!UID:666240signature: SIGNED_BY_ADMINS_PRIVATE_KEYFigure 1. Credential by the administrator giv-ing Alice access to a file. Public keys and sig-natures are replaced with symbolic names.Figures 1 and 2 show two credentials forming p
6、art of adelegation chain in our system. User Alice is granted accessto a particular file through a credential issued by the ad-ministrator. User Bob is then granted read-only access (by2Authorizer: ALICES_PUBLIC_KEYLicensees: BOBS_PUBLIC_KEYConditions: (AppDomain = “WebServer“) Comment: UID:666240Si
7、gnature: SIGNED_BY_ALICES_PRIVATE_KEYFigure 2. Credential from Alice delegatingread-only access to a file to Bob, for oneday. Again, public keys and signatures arereplaced with symbolic names.Alice) to access the same file during November 15, 2002.KeyNote will allow this delegation because the autho
8、ritygranted to Bob is a subset of the authority granted to Alice.Notice that users are identified only by their public keys.The advantage of using this system is that we no longerneed to have a priori knowledge of the user base. Thus,the system does not need to store information about everyperson or
9、 entity that may need to retrieve a file. We alsoprovide our users with the ability to propagate access to thefiles by passing on (delegating) their rights to other users.In this way, users pass credentials rather than passwords,thus allowing the system to associate access requests withkeys and also
10、 to be able to reconstruct the authorization pathfrom the administrator to the user making the request (andthus grant access). The system may not know that Bob istrying to get at a file, but it can log that key B (Bobs key)was used and that key A (Alices key) authorized the oper-ation. Logging such
11、information creates a clear audit trailfor any access request, which can be used by the adminis-trator to validate that the appropriate usage policy is beingfollowed. Note that a user can at most pass on the privilegesshe holds (there is no rights amplification); furthermore, theuser can delegate on
12、ly a subset of her privileges (e.g., accessto only a specific file in the users directory).2.2 Saving FilesThe HTTP PUT method is used to upload a file to theserver. When a client needs to upload a file to the server,a PUT request must be sent. The PUT header includes thelength of the file, the URI
13、of the file, and the users publickey. If the URI refers to a file that is already on the server,then the server requests a valid credential from the user thatincludes proper access rights (this situation is discussed inSection 2.4). If all of the information in the PUT request isvalid, then the serv
14、er returns a 100 Continue response.Upon receiving this message, the client can upload the fileto the server. If the information is invalid, then the serverreturns a401 Unauthorizedresponse to the client, andthe client must either try again or abort the transfer.Figure 3. Uploading a file to the serv
15、er.After a file has been successfully uploaded to the server,the server creates a KeyNote credential granting full-accessprivileges for that file to the client. A unique identifier(UID) for that file is associated with the file; this UID is alsoincluded in the credential. The server then returns a 2
16、01Created message to the client. This response includesthe credential in the ETag portion of the message. Whilethe ETag header is generally a caching-related header, it isused here as it is the only way to send back informationabout a resource in the response header. The receipt of the201 Created re
17、sponse completes the transaction. Thesoftware on the client must then extract the credential andstore it. This credential will be required for future access tothe file. Figures 3 and 4 show successful and unsuccessfulfile upload exchanges between a browser and a server.Figure 4. Failed attempt to up
18、load a file.2.3 The Challenge-Response SchemeThe system employs a challenge-response scheme toprotect against replay attacks. When a user attempts to ac-cess a secure file on the WebDAVA server, the server sendsback a 401 Unauthorized response containing a chal-lenge. Included in the WWW-Authenticat
19、e header is thename of the authentication method being used, a nonce, andthe servers public key:WWW-Authenticate: Keynote nonce= server_key=rnThe client then prepares a response that includes thenonce from the challenge message. The client first creates a3new nonce credential delegating trust to the
20、 server key forthe desired action (GET, PUT, etc.). The nonce credential issigned with the users private key. The Authorization headerof the response includes the users public key, the originalfile credential, and the newly created nonce credential:Authorization: client_key= credential=nn rnWhen the
21、 server receives the message, it verifies thatall the necessary information is included. If not, a 401Unauthorized message is sent. If all the necessaryinformation is there, the server passes all supplied cre-dentials to the KeyNote policy engine, along with theaction name/value pairs of (AppDomain,
22、 “WebServer”),(method, “ a0 method a1 ”), (file, “ a0 File UID a1 ”), and (nonce,“ a0 nonce a1 ”), as well as the servers local policy, and theusers public key as the action authorizer. a0 File UID a1refers to the UID of the requested file and a0 method a1 tothe HTTP method being called (GET, PUT, D
23、ELETE). IfKeyNote approves the request, the file is sent to the client.Otherwise, a 403 Forbidden message is returned. Fig-ures 5 and 6 show successful and unsuccessful challenge-response message exchanges for a GET request.Figure 5. Message exchange in a successfulGET request.2.4 Downloading, Editi
24、ng, and Deleting FilesDownloading a file from the web server is done via theHTTP GET method. Files on the server are identified viathe UID assigned when they are first uploaded to the server.First, the client sends a GET request for the file using theUID as the file URI. The server then attempts to
25、validate theusers request via the challenge-response scheme mentionedpreviously. If the credential verification is successful, a200OK response is generated and the file is transmitted.Modifying a stored file is done by overwriting it usingthe HTTP PUT method, as described previously in Sec-tion 2.2.
26、 Deleting a file is done by saving an empty file;the server notices that the file is empty and removes it. Ifthe user really wants an empty file, she must create one.Figure 6. Message exchange in a failed GETrequest.3 PrototypeOur prototype implementation of WebDAVA allowsusers to create the delegat
27、ion credentials and send themto other users. Moreover, the software allows users to ac-cept and integrate within their workspace credentials sentto them by other users. The server, written in C+, im-plements the initial uploading of files and their subsequentdownloading, based on receipt of proper c
28、redentials.The server puts all uploaded files in a directory called“storage”. When the server receives a file, it creates a UIDto represent it using the uuid generate API that is part ofthe Linux E2fsprogs ext2 filesystem library. The file is thenstored on the server using this UID. A client trying
29、to re-trieve a file must sends a special file access block (FAB)that contains the file UID along with additional information(note that the FAB in Figure 7 is that of the file owner, as itdoes not contain any delegation credentials).Figure 7. FAB with a single credential.For portability, the client w
30、as implemented as a signedJava applet. Clients can upload a file to the server, for whichthey will receive a file access credential in return (containedinside the file access block). They can then use this cre-dential to retrieve the file from the server, or they can passit, along with a delegation
31、credential they create, to anotheruser with a valid set of keys. When Alice wants to downloada file from the server, she sends the credential representingthe file. If the credential is valid, the server then sends thefile to the client. The applet can search for the appropriatecredential using the U
32、ID as a key in its credential database.When Alice wants to allow another user, Charlie, to ac-4cess a file stored on the WebDAVA server, she needs to re-trieve Charlies public key, construct the credential delegat-ing access to Charlies key, and then send this credentialalong with her own access cre
33、dentials to Charlie. Charliemust import these credentials and use them to access thefile. While Alice may use any mechanism to get Charlieskey, we provide a key-server that stores the keys of the var-ious users to simplify credential management.To transfer a credential to Charlie, Alice simply selec
34、tsthe credential and enters Charlies email address. Whenusers run the Java applet for the first time, their email ad-dresses and public keys are passed to the key-server. Thekey-server stores a mapping of email address/public keypairs. If Charlie is not registered, Alice must obtain hiskey through o
35、ther means. If Charlie is registered with thekey-server, Alice creates a credential transferring authorityto Charlies key and appends it to a copy of the creden-tials she already has for that file. The client then creates anemail message using these credentials and sends it to Char-lie. Charlie can
36、use these credentials to download the filefrom the server. Figure 8 shows Charlies FAB.Figure 8. FAB with the file access credentialand one delegation credential.4 EvaluationPerformance Analysis The prototype implementationwas used to determine the costs of the initial message ex-change and credenti
37、al verification. We used a Pentium 866Mhz machine running Red Hat Linux 7.2 (server) and anIBM X.21 laptop running Windows 2000 (client). We mea-sured the average elapsed time for repeatedly processing aGET request for the same file. We performed this operationwith the access-control mechanism disab
38、led, using only theoriginal credential delegated from the server to the clientwho had initially uploaded the file, and with an increasingnumber of delegation credentials. Figures 9 and 10 show theresults of using a local (on the same machine as the server)and a remote (over the network) client respe
39、ctively.The time was measured in system-clock ticks, with a res-ClockticksNo SecurityOriginal CertificateDelegate 1 TimeDelegate 2 Times Delegate 3 Times Delegate 4 Times Delegate 5 Times010203040506070133.35 34.85 39.340.5 45.748.15Figure 9. Time to handle a GET request, clientand server on the sam
40、e host.ClockticksNo SecurityOriginal CertificateDelegate 1 TimeDelegate 2 Times Delegate 3 Times Delegate 4 Times Delegate 5 Times0102030405060700.934.3 3841.4551.157.4 60.95Figure 10. Time to handle a GET request,client connecting over the network.olution of a0a2a1a4a3a6a5 seconds. Increasing the n
41、umber of delega-tions slightly increases request-processing time. Additionaltests showed that the policy evaluation itself required be-tween 1 and 2 clock ticks, even after 5 delegations. Thecost of retrieving the file from disk is minimal since, af-ter the first request, it resides entirely in the
42、operating sys-tems cache. Thus, the increase in latency can be directlyattributed to the overhead of the security mechanism andthe network-stack (present even in the local-access case).Security Analysis As the performance analysis indicates,the challenge-response phase incurs a significant perfor-ma
43、nce penalty. This cost, however, must be weighedagainst the benefits gained from a security perspective.The design primarily addresses replay attacks, whereby aneavesdropper records an interaction between a user and theserver, and sends the same packets at a later time. The exis-tence of the nonce i
44、n the servers challenge ensures that eachexchange is unique (assuming a good source of entropy).Revocation One of the major problems in capability-based systems is revocation. In our system, each file has5an associated file that stores information about revoked cre-dentials. Before the KeyNote compl
45、iance checker is con-sulted, the file-access credential is checked against the cor-responding revocation file to make sure it is still valid. Ifit is found in the revocation file, the compliance checkerdoes not consider it in the policy evaluation. In this way,the revocation file acts as a Certifica
46、te Revocation List. Thefact that the file is located in one server makes this simpleapproach acceptable. The only remaining problem, of howrevoked credentials are added to the file, is solved by havingthe issuer of the credential to be revoked attempt to uploadthe credential in the revocation file (
47、using the PUT method),using our protocol to authenticate. The server intercepts thePUT method, verifies that the key used to authenticate therequest is the same as the key that signed the credential, andadds the hash of the credential to the revocation file.Other Services Web servers are increasingl
48、y used asfront-ends to databases and other services. Clients issueparameterized POST requests that are passed to programsspawned by the web server in response (e.g., CGI scripts).This model has proved very successful, and various stan-dardization efforts use it for remote method invocation andas an
49、inter-process communication mechanism. Authenti-cation using simple public key certificates does not allowfor fine-grain access control at the parameter level. SinceKeyNote allows for arbitrarily complex conditions to be ex-pressed as part of the policy, we can pass the inputs froma POST request to the policy engine, as part of the access-control decision-making process. Access to services canthen be arbitrarily fine-grained using the WebDAVA model.5 Related WorkAlthough network file systems such as NFS 6 andAFS 4 are th
