<%BANNER%>

Ubiquitous file system protocol

University of Florida Institutional Repository

PAGE 1

UBIQUITOUS FILE SYSTEM PROTOCOL By PRASAD K. P. MENON A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2003

PAGE 2

Copyright 2003 by Prasad K. P. Menon

PAGE 3

To Mom, Dad and Sis

PAGE 4

ACKNOWLEDGMENTS Many people deserve special acknowledgements for making this thesis possible. I must first and foremost express my deepest appreciation to my committee chair, Dr. Joseph Wilson, for presenting me with the opportunity to work on such a fantastic idea. Joes continuous guidance played a significant role in bringing this project to fruition. I would also like to thank my other committee members, Dr. Richard Newman and Dr. Janise McNair, for their meticulous review of this thesis. I would also like to express my gratitude to all my friends at CISE for their encouragement and for being a constant source of motivation. They have provided input into my research and have also extended their support towards helping me correct errors in this document. I owe a great deal of thanks to my roommates, all of them contributing significantly with their constructive criticisms. Finally, I owe endless debt to my father and mother. They instilled the confidence in me to make all of this possible. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iv LIST OF FIGURES.........................................................................................................viii ABSTRACT.........................................................................................................................x CHAPTER 1 INTRODUCTION............................................................................................................1 1.1 Motivation...............................................................................................................1 1.2 Approach.................................................................................................................2 1.3 Organization...........................................................................................................3 2 FILE SYSTEM PROTOCOL ARCHITECTURE............................................................5 2.1 Authentication Protocols........................................................................................6 2.1.1 Data Encryption Standard.............................................................................6 2.1.2 Public Key Encryption.................................................................................7 2.1.3 Secure Socket Layer.....................................................................................7 2.1.4 Kerberos Authentication Protocol................................................................7 2.2 Protocol Phases.......................................................................................................8 2.2.1 Negotiation Phase.........................................................................................9 2.2.2 Authentication Phase....................................................................................9 2.2.3 Data Transfer................................................................................................9 2.3 Negotiation Phase...................................................................................................9 3 CLIENT AUTHENTICATION METHODS A COMPARISON................................12 3.1 Authentication based on Secure Socket Layer.....................................................13 3.2 With DES at Client-side and Proxy with SSL Support........................................14 3.2.1 Mechanism.................................................................................................19 3.2.2 Conventions................................................................................................19 3.2.3 Difficulties.................................................................................................20 3.3 Authentication based on DES SSL and Data Transfer using DES....................22 3.4 Authentication with Kerberos using DES.............................................................28 3.5 Authentication with Charon..................................................................................35 3.6 Authentication with Kerberos using Public Key Encryption...............................37 3.7 Data Transfer Phase..............................................................................................39 v

PAGE 6

4 FILE SHARING PROTOCOL.......................................................................................40 4.1 File Handle............................................................................................................41 4.2 File System Operations.........................................................................................41 4.2.1 Procedure 1: NULL No Operation..........................................................41 4.2.2 Procedure 2: CHGGRP Change group association.................................42 4.2.3 Procedure 3: CLOSE Close the file.........................................................42 4.2.4 Procedure 4: COMMIT Commit cached data.........................................42 4.2.5 Procedure 5: CREATE Create a file object.............................................42 4.2.6 Procedure 6: DELEGPURGE Purge all delegations for a client.............43 4.2.7 Procedure 7: DELEGRETURN Return Delegation................................43 4.2.8 Procedure 8: GETATTR Get File Attributes...........................................43 4.2.9 Procedure 9: GETFH Return current file handle.....................................44 4.2.10 Procedure 10: LOCK Create a lock.......................................................44 4.2.11 Procedure 11: LOCKT Test for a lock..................................................44 4.2.12 Procedure 12: LOCKU Unlock the object.............................................44 4.2.13 Procedure 13: LOOKUP Lookup filename...........................................44 4.2.14 Procedure 14: PUTFH Set Current File Handle....................................45 4.2.15 Procedure 15: READ Read from a file..................................................45 4.2.16 Procedure 16: READDIR Read contents of a directory........................45 4.2.17 Procedure 17: READLINK Read a symbolic link................................45 4.2.18 Procedure 18: REMOVE Remove a filesystem object..........................45 4.2.19 Procedure 19: RENAME Rename a filesystem object..........................46 4.2.20 Procedure 20: RENEW Renew a lease..................................................46 4.2.21 Procedure 21: RESTOREFH Restore a saved filehandle......................46 4.2.22 Procedure 22: SAVEFH Save current filehandle..................................46 4.2.23 Procedure 23: SETATTR Set attributes................................................46 4.2.24 Procedure 24: WRITE Write to a file....................................................47 4.2.25 Procedure 25: RELEASELOCK Release lock associated with a file...47 4.3 Caching.................................................................................................................47 4.3.1 Client-side Caching....................................................................................48 4.3.2 Caching of File Data...................................................................................49 4.3.3 Caching Operations....................................................................................49 4.3.4 Organizing Cached Data............................................................................50 4.3.5 Delegation and Callbacks...........................................................................50 4.3.5.1 Delegation...............................................................................................50 4.3.5.2 Callbacks.................................................................................................51 4.3.6 Caching Conclusion.................................................................................52 4.4 File Locking..........................................................................................................52 4.4.1 Lock Request..............................................................................................54 4.4.1.1 Indefinite Wait........................................................................................55 4.4.1.2 No Wait...................................................................................................56 4.4.1.3 Finite Wait...............................................................................................57 4.4.2 Lock Release..............................................................................................59 4.4.3 Crash Recovery..........................................................................................60 4.4.3.1 Client.......................................................................................................60 4.4.3.2 Server......................................................................................................60 vi

PAGE 7

4.5 Group Permissions................................................................................................61 5 CONCLUSIONS AND FUTURE WORK.....................................................................62 5.1 Conclusions...........................................................................................................62 5.2 Future Work..........................................................................................................63 APPENDIX FILE SYSTEM OPERATIONS....................................................................65 Operations with Arguments........................................................................................65 Procedure 1: NULL No Operation...................................................................65 Procedure 2: CHGGRP Change Group Association........................................65 Procedure 3: CLOSE Close the File.................................................................65 Procedure 4: COMMIT Commit Cached Data.................................................65 Procedure 5: CREATE Create a File Object....................................................65 Procedure 6: DELEGPURGE Purge All Delegations for a Client...................65 Procedure 7: DELEGRETURN Return Delegation.........................................66 Procedure 8: GETATTR Get File Attributes....................................................66 Procedure 9: GETFH Return Current File Handle...........................................66 Procedure 10: LOCK Create a Lock................................................................66 Procedure 11: LOCKT Test for a Lock............................................................66 Procedure 12: LOCKU Unlock the Object.......................................................66 Procedure 13: LOOKUP Lookup Filename.....................................................66 Procedure 14: PUTFH Set Current File Handle...............................................66 Procedure 15: READ Read from a File............................................................66 Procedure 16: READDIR Read Contents of a Directory.................................66 Procedure 17: READLINK Read a Symbolic Link.........................................67 Procedure 18: RELEASELOCK Release Lock Associated with a File............67 Procedure 19: REMOVE Remove a Filesystem Object...................................67 Procedure 20: RENAME Rename a Filesystem Object...................................67 Procedure 21: RENEW Renew a Lease...........................................................67 Procedure 22: RESTOREFH Restore a Saved Filehandle...............................67 Procedure 23: SAVEFH Save Current Filehandle...........................................67 Procedure 24: SETATTR Set Attributes..........................................................67 Procedure 25: WRITE Write to a File..............................................................67 LIST OF REFERENCES...................................................................................................68 BIOGRAPHICAL SKETCH.............................................................................................71 vii

PAGE 8

LIST OF FIGURES Figure page 2-1. Scenario illustrating ubiquitous file system mounted by three different clients and accessing files from the server...................................................................................5 2-2. Phases involved in the protocol....................................................................................8 2-3. Negotiation phase when proxy is used. 1. Request from the Client for SSL based authentication. 2. The Server transfers all requests to the Proxy. 3. All future authentication transactions are done between the Client and the Proxy..................10 3-1. The PDA device can connect to the server using SSL...............................................13 3-2. State diagram for SSL mode of client authentication.................................................15 3-3. Components involved in DES-SSL mode of authentication......................................17 3-4. State diagram for the SSL mode of client authentication when viewed at from the proxy side.................................................................................................................18 3-5. Transaction flow diagram among the three entities involved in the authentication scheme......................................................................................................................20 3-6. Components involved in DES-SSL mode of authentication with proxy removed after authentication...........................................................................................................23 3-7. State diagram for the SSL-DES mode of client authentication when viewed at from the proxy side...........................................................................................................25 3-8. State diagram involved in the SSL-DES mode of client authentication when viewed at from the server side..............................................................................................26 3-9. Transaction flow diagram for DES SSL (initial phase) and DES only (final phase) among all the three components...............................................................................27 3-10. The figure illustrates the various stages involved in Kerberos authentication for a PDA client................................................................................................................30 3-11. State diagram for the first stage i.e. the client communicating with the Kerbeross Key Distribution Center...........................................................................................31 viii

PAGE 9

3-12. State diagram for the second stage i.e. the client communicating with the Ticket Granting Server........................................................................................................32 3-13. State diagram for the third stage i.e. the client communicating with the File System Server.......................................................................................................................33 3-14. Transaction flow in Charon......................................................................................36 3-15. Transaction flow between among the entities involved in Kerberos-public key encryption.................................................................................................................38 4-1. Scenario where the client has to wait indefinitely until another client releases the lock Indefinite wait................................................................................................56 4-2. Scenario where the client either receives a lock or has to try again later No wait..57 4-3. Scenario where the clients request is added to a queue of finite size and has to wait until another client releases the lock and its request reached the top of the queue Finite wait.................................................................................................................58 ix

PAGE 10

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Master of Science UBIQUITOUS FILE SYSTEM PROTOCOL By Prasad K. P. Menon August 2003 Chair: Joseph N. Wilson Major Department: Computer and Information Science and Engineering The past decade has witnessed a phenomenal growth in wireless technology, which has led to widespread use of wireless devices in all spheres of human activities. Most of these devices store data and individuals are becoming increasingly dependent on these devices for accessing information from any location. These mobile devices now require data access from other machines that can store and process vast amounts of information. This thesis proposes a file system protocol that runs on wireless networks as well as wired networks and can be used by either mobile or fixed devices to exchange data with another device. Both server and client can be stationary computers or mobile devices. Mobile devices pose hardware and software constraints and computationally intensive operations may need to be offloaded to another machine. The negotiation phase decides the type of communication that can be established between the client and the server. The authentication phase supports a number of client authentication protocols using Secure Socket Layer protocol, Data Encryption Standard, or the Kerberos protocol. Initially a client must connect to a server and authenticate itself by using any of the aforementioned x

PAGE 11

authentication protocols. Once the client is authenticated, it can mount a file system and perform any necessary file operations. This file system protocol supports client-side caching, which is essential while communicating over a wireless network as the strength of the connection varies as the user travels. This can lead to disruptions in the connection between a client and server, so it is essential that such a file system protocol provide support for disconnected operation. xi

PAGE 12

CHAPTER 1 INTRODUCTION During the past decade, the world has become increasingly dependent on mobile devices. As a result, traditional ways of networking have proven inadequate to meet all the challenges posed by wireless networks. If users must be connected to a network by physical cables, their movement is dramatically reduced. Wireless connectivity, however, poses no such restriction and allows a great deal more free movement on the part of the network user. On the flip-side wireless network applications are complex to develop and to maintain. Security and authentication on wireless networks is extremely difficult owing to the additional risks posed by wireless media. Our idea is to provide a ubiquitous file system protocol meant for devices that are either on wired networks or wireless networks to share files on other mobile devices or from a server. Moreover mobile devices pose hardware and software constraints that are leading to the pervasive use of application-level proxies to mediate between client and servers. 1.1 Motivation The increased use of mobile devices by individuals has led to widespread research on wireless applications and on mechanisms to share information between these devices. Mobility has placed many demands on the existing networks and on the applications available. A study conducted in August 2002 by Oracle and Telephia [1] has defined the primary constraints faced by mobile users. Some of the difficulties faced with mobile devices [2] are the low computing power and memory associated with these devices, the kind of network connectivity associated with wireless devices i.e. the time required to get 1

PAGE 13

2 an application to function and the low battery power associated with mobile devices. In spite of these challenges it is essential that mobile users be allowed access to information on demand and from any location. These problems were initially addressed during the last decade at Carnegie Melon University [3] and subsequently enormous amount of literature has been published in this field. Later on file systems such as Coda [4, 5] and Odyssey [6] were implemented to solve the problems of wireless network access. In order to address the security concerns of today, the file system protocol discussed in this thesis attempts to improve upon the authentication systems provided in earlier file systems for mobile devices. Another primary goal of this protocol has been to address caching issues while communicating over a wireless link [7]. As power and memory are limited in a mobile device, the file system protocol proposed also attempts to provide only the minimal needed functionality for file handling operations and this can decrease the overhead on the client system. The file system protocol has been made as generic as possible. It can be used on wired or wireless networks and can provide file-sharing facilities to computers with a broad range of computing power. 1.2 Approach This file system protocol is an attempt to create a generic protocol that can be used both on low power mobile devices and with high power wired devices. Since wireless devices pose most of the constraints, this protocol addresses these issues. One of the major constraints is the low computing power associated with these devices, and this protocol attempts to transfer most of the computing to either proxy machines or to the server. This drawback is considerably felt during the authentication phase where

PAGE 14

3 authentication protocols such as SSL can take a considerable amount of time on these devices. This protocol addresses this issue by providing a number of authentication protocols to choose from and the client can choose one depending on its computing power. Some of them are allowed to offload computation to a proxy and the proxy continues with the client authentication. An advantage of this approach, is the lower memory needed by the client to perform the authentication. Another constraint is the strength of network connectivity associated with these wireless devices. Sometimes the connection is weak or at times it is even non-existent. This file system protocol addresses this issue by providing client-side caching, depending on the strength of the connection. Every attempt has been made to decrease the complexity of the file system protocol both in terms of implementation and in design without compromising on any of the file handling operations. File system features such as Access Control Lists have not been included in this design and it is the responsibility of the server to provide the correct file access for a client. 1.3 Organization The thesis is organized as follows: Chapter 2 provides an overview of the Ubiquitous File System Protocol architecture and discusses the major phases involved. Chapter 3 provides an in-depth discussion of the different client authentication protocols supported by the system and also explains the architecture involved in each of the authentication strategies. State diagrams [8] are used to explain the design involved for each of the authentication protocols. Chapter 4 discusses the file sharing protocol, with the various file operations and file locking strategies. Some concepts such as the readers / writers problem are discussed

PAGE 15

4 here. This chapter discusses caching, client-side caching and its use depending on the strength of the connection. It also discusses the file handling operations that are supported by the file system. Later on this chapter focuses on locking and how the protocol proposed handles file locking. The last section of this chapter discusses group access permissions and illustrates the novel approach used to solve the group access problem in this file system.

PAGE 16

CHAPTER 2 FILE SYSTEM PROTOCOL ARCHITECTURE This chapter provides an overview of the protocol and the various phases involved in this protocol. A file system provides an interface to support creation, manipulation, storage and retrieval of data on a permanent storage medium such as a disk. The two fundamental concepts of a file system are files and directories. A file is the primary functionality that every file system must provide to store a named piece of data and to later retrieve the data using the name given to it. A file is where a program stores data permanently. The size of data stored may range from only a few bytes to the entire capacity of a volume. A file system must provide a way to name and organize multiple files, and a directory is used for this purpose. Figure 2-1. Scenario illustrating ubiquitous file system mounted by three different clients and accessing files from the server. Dotted lines represent a wireless connection while the black line represents a wired connection. The ubiquitous file system protocol is a generic protocol designed for both wired and wireless devices. Figure 2-1 illustrates three different clients mounting the file 5

PAGE 17

6 system from the server. Clients are allowed to mount the server-side file system and perform necessary operations on the file objects. This protocol can be broadly classified into two stages. The first stage is the authentication layer, where a client is made to authenticate and prove its identity to the server. When the authentication is successful, then the client is allowed to mount the servers file system and perform the required file operations. 2.1 Authentication Protocols Authentication is the process of verifying identity so that one entity can be sure that another entity is who it claims to be. It is essential to authenticate the devices involved in communication before any file-sharing protocol can be used. In the case of our file system, communication can occur between two mobile devices or between a mobile handset and a server. In a mobile computing context, the processing and communications resources required to perform encryptions and decryptions and to transmit large messages may result in unacceptable performance characteristics and extended user authentication response times. This protocol supports a number of client authentication protocols using Secure Socket Layer protocol, Data Encryption Standard, or the Kerberos protocol. A brief explanation of each of these protocols is mentioned below. 2.1.1 Data Encryption Standard Data Encryption Standard (DES) [9] is a block cipher algorithm; it encrypts data in 64 bit blocks. A 64-bit plain text goes in one end of the algorithm, and a 64-bit block of ciphertext comes out the other end. Both encryption and decryption use the same

PAGE 18

7 algorithm. The key length can be any 56 bit number and can be changed at any time. All security rests within the key. 2.1.2 Public Key Encryption Public key encryption [10] is a technique that uses a pair of asymmetric keys for encryption and decryption. Each pair of keys consists of a public key and a private key. The public key is made public by distributing it widely. The private key is never distributed; it is always kept secret. Data that is encrypted with the public key can be decrypted only with the private key. Conversely, data encrypted with the private key can be decrypted only with the public key. This asymmetry is the property that makes public key cryptography so useful. 2.1.3 Secure Socket Layer Secure Socket Layer (SSL) technology was developed by Netscape Communications Corporation [11] for protecting web based communications. The SSL security protocol provides data encryption, server authentication and message integrity. SSL comes in two strengths, 40-bit and 128-bit, which refer to the length of the "session key" generated by every encrypted transaction. The longer the key, the more difficult it is to break the encryption code. 2.1.4 Kerberos Authentication Protocol Kerberos is a trusted third-party authentication protocol [12, 13]. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. A Kerberos service, sitting on the network acts as a trusted arbitrator. Kerberos provides secure network authentication allowing a person to access different machines on the network. Kerberos is based on symmetric cryptography, and it shares a

PAGE 19

8 different key with every entity on the network. Knowledge of the secret key is used as proof of identity. 2.2 Protocol Phases The authentication stage is further complex. The protocol has to consider two particular cases to handle during the authentication stage, if on the destination side we have a server, then it can handle any kind of SSL or Kerberos authentication mechanism whereas, if the destination is a PDA device then we will once again need to have a proxy at the destination end and every SSL request to the PDA-device should be re-routed to the proxy on the destination side. This is because the PDA device lacks the computing power and the memory necessary to encrypt or decrypt SSL packets. This implies that one would need to know the kind of device that is used at the destination end. In order to ascertain the kind of device that is being used on the destination side, we have divided the communication between the client/proxy and the server can into three phases. Figure 2-2. Phases involved in the protocol.

PAGE 20

9 2.2.1 Negotiation Phase This is the first phase of communication between the client and the device at the destination end. During this phase we check if the server can respond to SSL encrypted messages or not, as in the case of a PDA device. If a PDA device is used as the server, then the IP address of the proxy is retrieved in this phase. The rest of the communication occurs with the proxy acting as an intermediary for the PDA device at the destination. 2.2.2 Authentication Phase During this phase, both the parties authenticate each other through Secure Socket Layer, Data Encryption Standard or Kerberos authentication mechanisms. A significant amount of processing power and free memory is needed during this stage owing to the encryption and decryption of the client and server certificates. The next chapter discusses ways to offload computation to other computers and this decreases the load on each client. 2.2.3 Data Transfer Once authentication is complete, the client and the server can communicate over the network using DES, SSL or Kerberos mechanisms. The client mounts the file system on the server and the rest of data transfer is handled by the file transfer protocol. As part of our study we compare the client authentication mechanisms that are possible, between the client and the server. The rest of this chapter discusses the negotiation phase, and the other two phases are discussed in the later chapters. 2.3 Negotiation Phase This phase is the first stage of communication between the mobile client and the server. The client device could be either a PDA device or even a mobile notebook. Also, the server can either be a mobile device or a computing device placed at a fixed location.

PAGE 21

10 In an attempt to provide for a generic file system protocol, it is necessary to consider the case where, the server is a mobile PDA device with low memory and low computing power. Most authentication protocols require a large degree of computing power and a significant amount of free memory, on both the server and the client machines and in some cases the server might not be able to handle such a load. In such cases, the client and the server will require a considerable amount of time to authenticate using Secure Socket Layer. The negotiation phase is useful in such situations. During this phase, the client sends a request to the server inquiring if the server-computing device can handle the required authentication protocol. For example, the client sends a request to the server to verify if the server can handle SSL requests. In most cases, the server will be able to handle such requests and will respond with an acknowledgement message and this concludes the Negotiation phase. Figure 2-3. Negotiation phase when proxy is used. 1. Request from the Client for SSL based authentication. 2. The Server transfers all requests to the Proxy. 3. All future authentication transactions are done between the Client and the Proxy. If the server is unable to handle the SSL requests, for example the server might be another mobile device and in such cases a proxy can be used to and the server will transfer the SSL computations to the proxy. This assumes that the proxy is a partially

PAGE 22

11 trusted device and the proxy later interacts with the client in the next phase. This concludes the Negotiation phase in this case. The advantage of using the negotiation phase is that the file system can provide support for a number of authentication protocols, as the computing power of a device will cease to be a constraint. Moreover the advantage of off loading the computation from the mobile device to a proxy is a great benefit and can speed up the authentication phase considerably. A similar scenario occurs when a mobile client with low computation power and memory needs to authenticate its identity to a server device. The mobile client can then use a partially trusted proxy to offload some or most of its computation. Since the client is a mobile device and the proxy may be a fixed device, issues such as handover of client etc., need to be considered. These issues are dealt with in Chapter 3.

PAGE 23

CHAPTER 3 CLIENT AUTHENTICATION METHODS A COMPARISON This chapter provides a detailed discussion of the various authentication protocols that can be used for identifying the client and the server devices connected using either wired or wireless networks. The initial three protocols are authentication protocols based on Data Encryption Standard (DES) [9] and Secure Socket Layer (SSL) [11, 12, 14] whereas the last three protocols are based on the Kerberos [12, 13] standard. These three protocols cover a broad spectrum of authentication protocols available today. Data Encryption Standard is a symmetric key algorithm and is popular because of the faster response times that can be achieved when this algorithm is used. SSL is one among the most widely used authentication mechanisms on the Internet and does provide an adequate level of security for most client-server applications. Kerberos has been found useful as an authentication mechanism in distributed systems, where a client needs to communicate with a number of servers. Kerberos can be used with either DES or with public key cryptography and both of these authentication mechanisms are discussed in this chapter. Hardware based cryptographic algorithms such as Fortezza [15] have not been covered in this chapter, as these algorithms are machine-specific and an attempt has been made to use generic authentication algorithms which are not machine dependent. The SSL security protocol provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. SSL is a layered protocol. At each layer, messages may include fields for length, description, and content. SSL takes messages to be transmitted, fragments the data into manageable blocks, 12

PAGE 24

13 optionally compresses the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, and reassembled, then delivered to higher-level applications. SSL [11, 14] comes in two strengths, 40-bit and 128-bit, which refer to the length of the "session key" generated by every encrypted transaction. The session key is a unique key generated by the client and encrypted with the servers public key. This encrypted message is then sent across to the server, which can decrypt and retrieve the session key using its private key. The client uses this key to encrypt all communication with the server. The longer the key, the more difficult it is to break the encryption code but more time-consuming for encryption and decryption. So a balance needs to be maintained between the power and memory associated with the computing device and the length of the session key. Among the protocols discussed, SSL is one of the easiest to implement owing to the number of third-party tools available. It is also extremely popular and is supported by most server systems. 3.1 Authentication based on Secure Socket Layer The first authentication mechanism that we consider is based on the Secure Socket Layer. Both the client and the server side communicate using Secure Socket Layer to Figure 3-1. The PDA device can connect to the server using SSL. authenticate each other. SSL uses public key encryption [16, 17] and even with 40-bit encryption, this is computation intensive and also requires a large amount of free memory

PAGE 25

14 to perform all computations. This places a considerable overhead on a PDA device and the time taken to encrypt and decrypt packets can be significant. As shown in the Figure 3-1, the connection is straightforward; the client directly connects to the server using the protocol SSL. Since the protocol involves only two components, it is simple in design and Figure 3-2, illustrates the states involved in authentication and file transfer. The dotted lines represent a change of phase for example; the first series of dotted lines in Figure 3-2 represent the negotiation phase. In this phase both the client and the server communicate with each other and verify if SSL can be used for authentication. If yes, then the client and the server authenticate each other based on their public and private keys. A failure in authentication causes the system to exit whereas a successful authentication leads to the server allowing the client to mount the file system. 3.2 With DES at Client-side and Proxy with SSL Support A basis for this design is that programming portable devices is hard! It is hard ranging for many reasons, ranging from simplicity of the device architecture to simplicity of the programming tools. Moreover memory constraints and low computation power [18] associated with these devices, pose major restrictions on the programmer. In the previous authentication mechanism, the encryption and decryption of keys can be prohibitively expensive in terms of computation power and when used on small devices.

PAGE 26

15 Figure 3-2. State diagram for SSL mode of client authentication.

PAGE 27

16 Using this protocol on portable devices would consume a lot of battery power and pose a considerable overhead on its resources. The strategy of inserting a proxy between the end-systems allows more efficient use of computational resources, reduces complexity of the implementation, and increases security. The previous chapter provided a brief overview of using a proxy device to offload computations from the server. In this section, the issues regarding the use of proxy have been discussed in finer detail. DES (Data encryption Standard) [19, 20] is a symmetric crypto algorithm unlike SSL and is thus less computationally intensive. This protocol is particularly advantageous when portable devices are used. The algorithm specifies both enciphering and deciphering operations, which are based on a binary number called a key. A key consists of 64 binary digits ("0"s or "1"s) of which 56 bits are randomly generated and used directly by the algorithm. The other 8 bits, which are not used by the algorithm, are used for error detection. The 8 error detecting bits are set to make the parity of each 8-bit byte of the key odd, i.e., there is an odd number of "1"s in each 8-bit byte. Authorized users of encrypted computer data must have the key that was used to encipher the data in order to decrypt it. The unique key chosen for use in a particular application makes the results of encrypting data using the algorithm unique. Selection of a different key causes the cipher that is produced for any given set of inputs to be different. The cryptographic security of the data depends on the security provided for the key used to encipher and decipher the data. The key is usually a 64-bit number but the encryption uses only 56 bits. A proxy meant for SSL encryption and decryption is brought into the system. The PDA-client and the proxy authenticate each other using DES and later the proxy handles

PAGE 28

17 all communication for the client using Secure Socket Layer. The proxy is assumed to have much greater computing power and a larger amount of free memory than a PDA device, so the user can achieve faster response times. This protocol is suitable if the server side supports only SSL encryption and the client is constrained in terms of computational power, free memory available and battery resources. A third entity is brought into the system, one that acts as an interpreter between DES and SSL protocols. Figure 3-3. Components involved in DES-SSL mode of authentication. Data transfer between a client and a server can be divided into two stages. The first stage involves using DES based authentication between the client and proxy. Both the client and proxy agree on a shared secret key K and use a symmetric key algorithm. The reason is that client has less computing resources and DES requires less computing power compared to SSL. Figure 3-4 explores the various states involved in the first stage of communication i.e. between the client and the proxy. The dotted lines represent the change of phase and initially the algorithm verifies if the proxy supports DES or not.

PAGE 29

18 Figure 3-4. State diagram for the SSL mode of client authentication when viewed at from the proxy side. The second stage is the communication between the proxy and the server via an SSL based proxy. The proxy is assumed to be a partially trusted entity and can act as an intermediary between the client and the server. Once client authentication is performed with the proxy then the client transfers its certificates to the server encrypted using DES.

PAGE 30

19 The proxy continues the authentication with the server using these certificates. The state diagram for this stage is shown in Figure 3-2, the server does not differentiate between the client and the proxy. 3.2.1 Mechanism The algorithm can be summarized as shown below: Client and proxy agree on using DES. Client and proxy agree on a key. Authentication of proxy is necessary at this stage. Message is sent across by client E DES (msg), let us say and a corresponding response by the proxy,P E DES (result-msg). Authentication of client is necessary at this stage. Message is sent across by client E DES (msg). Let us say and a corresponding response by the proxy, P E DES (result-msg). Client to proxy: E DES (Service (port and host ip)) Proxy: Locate service with the requested port and host IP address. 3.2.2 Conventions E DES (msg): The message msg is encrypted using Data Encryption Standard. P E DES (result-msg): The message result-msg is encrypted by the Proxy using an encryption algorithm based on Data Encryption Standard. The following assumptions are made in this protocol. Proxy is located in a secure area and only authorized personnel can access this machine. Client can store the key in a secure manner. A chance of key retrieval by an unauthorized person is very low.

PAGE 31

20 Figure 3-5. Transaction flow diagram among the three entities involved in the authentication scheme. 3.2.3 Difficulties One of the major constraints posed by this authentication scheme is that the proxy is assumed to be a trusted source. The client is a wired or a wireless device with minimal computing resources whereas the proxy is probably wired and fixed to a specific location.

PAGE 32

21 So as the client moves, it may be necessary to transfer to another proxy. There are several reasons this can happen: 1. Proxy is tied to a wireless access point. So it may go out of range, and cause a break in communication. 2. The hop count may become too large, if the client travels a large area, for example when the client travels from US to Europe. If the client switches its wireless access point, then the proxy that the client is connected to will change. A handover of the clients identity needs to be performed between the client and the proxy. Ideally, there are three ways to accomplish this. Client handles handover without any intervention Proxy handles the clients handover. A new entity handles the handover. Of all these, the proxy handling the handover seems the most suitable for our purpose. The first proxy will search and find another suitable proxy that can continue with data transfer. The proxy presently communicating will need to be requested by the PDA client for a change in proxy. The client will need to confirm its identity to the second proxy and the data transfer can continue among the three entities. A prototype for this protocol has been developed at University of California, Berkeley and found to be faster than the previously discussed SSL protocol. Hill, Perrin, Ross and Singh have discussed this protocol in their paper [21] where they have discussed the client-server connection latency when this protocol is used.

PAGE 33

22 Another possible solution for the client is to store all information once the connection is weak and later perform all needed operations. This is the basis of caching and this idea is further dealt with in the next chapter. 3.3 Authentication based on DES SSL and Data Transfer using DES. The previous mechanism that we discussed had a major drawback that the proxy had to handle all the communication between the PDA-client and the server. This requires the proxy to be an extremely trusted source. The proxy also had to initiate handover and this is another source of overhead on the proxy machine. It has been noticed that in most cases of data communication, it is the authentication stage that should have maximum security. The initial authentication stage involves communicating the credentials of each entity present in the network. So as the identities are to be established, the security should be highest during the transfer of credentials. No malicious user should be able to access these credentials. These credentials form the basic framework of security and should never be compromised. The later stages of communication will tend to have lesser security requirements. This is because in the later stages of information transfer, credentials are not transferred. Based on this assumption, we can simplify the previous mechanism so that DES is used as the cryptography algorithm between PDA-client and server once authentication is completed using SSL. The assumptions made in this protocol are The proxy is assumed to be a partially trusted source as it handles all client certificates. The server can handle both DES mode of authentication and SSL mode. So once again, communication is divided into three stages, between the client, proxy and the server.

PAGE 34

23 1. The PDA-Client authenticates itself to the Proxy and they communicate using DES. Once this authentication is complete the client transfers its certificates to the proxy, so that the proxy can authenticate the client to the server based on these certificates. 2. The Proxy and the Server authenticate each other using an SSL based authentication protocol. The proxy uses the certificates that were sent across by the client after the first authentication stage. Since the proxy is a partially trusted source, trusted by the client, the client can safely transfer the certificates to the proxy. 3. Now the Proxy can be removed from the picture and the PDA-Client will communicate with the Server using DES. This is possible only if the server supports a DES based encryption and decryption protocol. All data transfer between the client and the server are encrypted and decrypted using DES. Figure 3-6. Components involved in DES-SSL mode of authentication with proxy removed after authentication. The advantage that this protocol provides is that, once the proxy completes its authentication with the server using SSL, then communication can continue without using a proxy. This also eliminates the problem of handover between the proxy systems and implementing the system will be much easier. Figure 3-7 depicts the various states involved in the communication between the client and the proxy. Once again, the connection is verified and the client is authenticated, the client then transfers its certificates for SSL based communication between the proxy and the server. If the authentication between the proxy and the server

PAGE 35

24 does not succeed the client is informed of this and the proxy exits. If the authentication between the proxy and the server is successful, the proxy hands over the client credentials needed for decrypting DES messages to the server and exits. The next stage involves the authentication based on Secure Socket Layer between the proxy and the server. At the end of the first stage the proxy receives the certificates of the client and can authenticate the client to the server based on these credentials. The proxy is transparent to the server and it assumes that the authentication is from a client. The server authenticates the client based on the certificates received. If successful, it retrieves the DES details such as shared key used for encryption and decryption from the proxy. These details are received encrypted using the SSL message exchange so cannot be decrypted by any eavesdropper. The next figure, Figure 3-8, depicts the various states involved for the server to authenticate the client and for subsequent data transfer. Note that, towards the end of the authentication phase, the server needs to retrieve the DES key details of the client from the proxy. In this manner, the server can continue communicating with the client using DES encryption. A transaction flow diagram is a flow chart depicting the various requests and responses that occur among the entities of the system. The diagram illustrates the successive steps involved during authentication between the client, proxy and the server. Figure 3-9, provides a transaction flow diagram for the whole system. Note that unlike in the previous authentication protocol, the server receives all DES details from the proxy machine and continues to communicate with the client and the proxy can be removed from the existing system.

PAGE 36

25 Figure 3-7. State diagram for the SSL-DES mode of client authentication when viewed at from the proxy side.

PAGE 37

26 Figure 3-8. State diagram involved in the SSL-DES mode of client authentication when viewed at from the server side.

PAGE 38

27 Figure 3-9. Transaction flow diagram for DES SSL (initial phase) and DES only (final phase) among all the three components. The table shown is a comparison of the three protocols based on a number of parameters such as the difficulty associated with design and implementation of the protocol, the level of security provided and so on. The client-side response times and memory constraints comparisons are based on a study conducted at University of

PAGE 39

28 Berkeley comparing SSL and DES client server connection latency times [21]. The comparison was based on a test run on a Palm Pilot device. Table 3-1. Table comparing DES and SSL based authentication protocols. Implementation complexity Computation complexity (Client side) Possible security breach Memory Constraints Client side response time SSL Only RSA Comparatively easy Maximum Lowest High (> 200K) Slow (> 20 secs) SSL, DES with Proxy Difficult Low Proxy needs to be partially trusted. Low (104 K) Fast (6.4 secs) SSL, DES without Proxy Difficult Low Proxy needs to be partially trusted. Low (104 K) Fast (6.4 secs) 3.4 Authentication with Kerberos using DES Authenticating mobile computing users can use significant amounts of processing and communications resources-particularly when protocols based on public key encryption are invoked. These resource requirements can sometimes result in unacceptable response times for the user. Kerberos [12, 13, 19] is a trusted third-party authentication protocol designed for TCP/ IP networks. A Kerberos service, sitting on the network, acts as a trusted arbitrator. Kerberos provides secure network authentication, allowing a person to access different machines on the network. Kerberos is based on symmetric key cryptography and the advantage Kerberos provides is; it shares a different secret key with every entity of the network and the knowledge of that secret key equals proof of identity. Kerberos provides both user authentication and encryption key management to guard networks from all forms of attacks on data in transmission including, interruption, interception, modification, and fabrication.

PAGE 40

29 There are two types of credentials used in Kerberos: tickets and authenticators. A ticket is used to pass securely the identity of the client for whom the ticket was issued to the server. It also contains information that the server can use to ensure that the client using the ticket is the same as the client to whom the ticket was issued. An authenticator is an additional credential, presented with the ticket. In the Kerberos model, there are entities-clients and servers-sitting on the network. Kerberos keeps a database of clients and their secret keys. Network services that require authentication, as well as clients who wish to use these services, register their secret key with Kerberos. Because Kerberos knows everyones secret key, it can create messages that convince one entity of another entitys identity. Kerberos also creates temporary secret keys, called session keys, which are given to a client and a server. A session key is used to encrypt messages between the two parties, after which it is destroyed. Figure 3-10, illustrates the Kerberos authentication protocol. The PDA-client requests for a Ticket-Granting Service (TGS Ticket) from the Kerberos service. The ticket is sent to the client, encrypted using the clients secret key. To use a particular service, the client requests a ticket for that service from the Ticket-Granting Server (TGS). Assuming everything is in order, the TGS sends the ticket back to the client. The client then presents the ticket to the server along with an authenticator. Again if theres nothing wrong with the clients credentials, the server lets the client have access to the service. Figure 3.11, represents the states associated in the first phase of Kerberos authentication protocol where the client tries to get a ticket to communicate with the Ticket Granting Server. The Key Distribution Center (KDC) looks up the client in the

PAGE 41

30 database. If the client is found, then Kerberos generates a session key to be used between the client and the TGS. This is called the Ticket Granting Ticket or a TGT. Figure 3-10. The figure illustrates the various stages involved in Kerberos authentication for a PDA client. The Ticket Granting Server encrypts that session key with the clients secret key. Then it creates a TGT for the client to authenticate itself to the TGS and encrypts that in the TGSs secret key. The authentication server sends both of these encrypted messages to the client. Unlike in the other protocols, the Kerberos authentication process involves more entities when compares to the previous protocols that we had discussed and data transfer occurs in the very last stage. The client now decrypts the first message and retrieves the session key. The secret key is a one-way hash of the users password, so a legitimate user will have no trouble in retrieving password. In the second stage of Kerberos authentication protocol, the client authenticates with the TGS and tries to get a ticket to communicate with the Server. The TGS grants tickets for individual servers, so the client needs to send a request to the TGS.

PAGE 42

31 Figure 3-11. State diagram for the first stage i.e. the client communicating with the Kerbeross Key Distribution Center.

PAGE 43

32 Figure 3-12. State diagram for the second stage i.e. the client communicating with the Ticket Granting Server.

PAGE 44

33 Figure 3-13. State diagram for the third stage i.e. the client communicating with the File System Server.

PAGE 45

34 Figure 3-12 explains the states involved in creating a ticket for a service. First, the client needs an authenticator. The authenticator consists of the clients name, clients address and a time stamp, encrypted with the session key generated by the Kerberos authentication server also known as KDC. The request consists of the name of the server, the TGT received from Kerberos (already encrypted with the TGSs secret key), and the encrypted authenticator. The TGS upon receiving the request decrypts the TGT with his secret key. Then he uses the session key included in the TGT to decrypt the authenticator. Finally, he compares the information in the authenticator with the information in the ticket, the network address of the client with the address the request was sent from, and the timestamp with the current time. If everything matches, he allows the request to proceed. The TGS responds to a valid request by returning a valid ticket for the client to present to the server. The ticket contains the name of the client, the network address of the client, a timestamp, an expiration time for the ticket, and the session key it just created, all encrypted with the servers secret key, and the name of the server. The TGS also creates a new session key for the client and the server, encrypted with the session key shared by the client and the TGS. The client receives both a valid ticket for use with the server and a new session key for the client and the server from the TGS. The client once again creates an authenticator, consisting of the clients name, the clients network address and a timestamp, encrypted with the session key for the client and the server that was generated by the TGS. Figure 3-13 shows the states involved in the last stage of the authentication protocol where the server decrypts the clients request. The server verifies the client address and the

PAGE 46

35 timestamp and if everything is found fine, it allows the client to connect and mount the file system. Later the client is allowed file access and all requested file operations are performed by the server. 3.5 Authentication with Charon Though Kerberos is a viable protocol for mobile PDA devices, it is difficult to implement this protocol on a PDA device, particularly for preserving credentials and for security guarantees. Moreover Kerberos is particularly problematic to port, besides its size and complexity, it relies heavily on Unix idioms and libraries, use of Unix I/O and memory services, and knowledge of hardware semantics such as byte ordering and word-size of the host architecture. None of this functionality is easy to implement or mimic in PDA systems. The lack of free memory is one of the major constraints in implementing Kerberos for PDA clients. The next protocol that we look at is an implementation of Kerberos and a proxy, which in fact does most of Kerberos computations. Charon [22] uses Kerberos to establish a trust relationship between the user and the proxy. The mechanism for establishing this trust is similar to the method of establishing trust between the user and the target application server. As a result, there are several more interactions required in Charon than in the standard Kerberos protocol, where there is no proxy involved. Charon uses the same algorithm i.e. DES on the PDA as standard Kerberos. In Charon, proxies play two important roles: they provide application-level adaptation for impoverished clients and can optionally function as a protocol gateway and logical channel multiplexor for non-TCP/IP clients. When a client running Charon attempts to connect to the proxy, the proxy-side Charon protocol module receives the request and attempts to authenticate the client.

PAGE 47

36 Figure 3-14. Transaction flow in Charon. Charon interaction consists of two distinct phases: the handshake phase, in which the client authenticates itself to the proxy via Kerberos, and establishes a secure channel with it, and the service access phase, in which the proxy accesses Kerberized services on the clients behalf. Handshaking is accomplished by treating the proxy as a Kerberized service. The handshake consists of two steps. During the first step, the client uses the proxy as an intelligent router to obtain a TGT, which will then be managed by the proxy. During the second step, the client obtains a proxy service ticket from the TGS; during this step the

PAGE 48

37 proxy functions not only as a router but also as a Kerberized service, for which the TGS can create a session key to be securely disclosed via the Kerberos messages. After this two-step handshake phase has succeeded, the session key can be used to secure the channel between the client and the proxy, and therefore all logical connections multiplexed onto it. The client, now in the service access phase can then request indirect access to other Kerberized services. An important property of Charon is that the proxy-side Charon module never gains possession of enough information necessary to independently negotiate for services on behalf of the client. 3.6 Authentication with Kerberos using Public Key Encryption Network authentication protocols regularly employ public key cryptography to securely identify clients to servers and establish trust relationships. In a mobile computing context, the processing and communications resources required to perform public key operations and transmit large messages may result in unacceptable performance characteristics and extended user authentication times. The authentication mechanisms that we have discussed before compensated for the resource limitations of mobile computing platforms by off-loading processing to a proxy server. On the flip side, proxies pose an additional layer of complexity, network delay and opportunity for security breach. With the rapid increases in computing capacity on PDAs, it might be possible to run public-key algorithms on these devices in the near future. This section analyzes a public-key based variant of the Kerberos authentication protocol [23]. The advantages provided by public key cryptography include simplified key management and the ability to leverage existing and developing public key certification infrastructures.

PAGE 49

38 Figure 3-15. Transaction flow between among the entities involved in Kerberos-public key encryption. A transaction using public-key encryption can be divided into the following stages: 1. The mobile client sends an initial Ticket Granting Request (TGT) to the Kerberos server. The session key is generated by the client, which is encrypted using the Kerberos servers public key and later signed by the mobile clients private key just as in Public Key Encryption. 2. The mobile client then requests for a session key for communicating with the application server. 3. The client and server authenticate each other using the standard Kerberos key exchange.

PAGE 50

39 The transaction flow is very similar to the one with Kerberos using DES and the difference is that here instead of symmetric key encryption we are using public key encryption. 3.7 Data Transfer Phase Towards the end of the authentication phase, the clients identity is known and verified. The server then assigns the client to a group based on this identity. The client can access all the files that are accessible by members of this group. This method is used to avoid Access Control Lists and Group Permissions that will be discussed in the next chapter. Once all the devices involved in data transfer are authenticated, the stage is set for transfer of data between the entities involved in communication over the wireless network. This stage might also be in an encrypted form depending on the sensitivity of the data being transferred. In most cases the data involved can be encrypted and decrypted using the simple DES algorithm. Most PDA devices do have the computing power necessary for encrypting and decrypting DES messages. So in such situations the client and the server can communicate directly without the use of the proxy device. In some cases, SSL or public key encryption might be needed again depending on the sensitivity of the data being transferred. In such situations, the proxy might continue to be used until the end of data transfer stage.

PAGE 51

CHAPTER 4 FILE SHARING PROTOCOL The file sharing protocol for the Ubiquitous File System is a stateful protocol. This protocol is meant to suit clients running on either wired or wireless networks. It features a simple design for easy recovery, is independent of transport protocols, operating systems and the underlying filesystem. This file system has been developed with low power portable computation devices in mind, without compromising on file sharing functionality issues so that the file system can also be used with high power computation devices. Some of the features unique to this file system protocol are its dual mode of caching, locking only for writer processes and that it provides for cross-platform interoperability. The protocol features a filesystem model that provides a useful, common set of features that does not unduly favor one filesystem or operating system over another. An attempt has been made to understand the commercially successful file systems of today, such as NFS [24, 25, 26] and CIFS [27] and create a file system that has the better features of these proven file systems. NFS is used prominently on UNIX based machines while CIFS is based on Windows based machines. The motivation to design the ubiquitous file system protocol from NFS and CIFS is that, collectively these file systems represent a broad spectrum of file system users. The remainder of this chapter is a discussion on file handles and the issues that must be considered while developing this file system. File system operations and features such as caching and locking are explained in the subsequent sections. 40

PAGE 52

41 4.1 File Handle The file handle in this protocol is a per server-unique identifier for a file system object. It contains all the information that is required by the server to distinguish an individual file from all other files. The client does not need to understand the contents of the file handle and the file handle is opaque to the client. Therefore, it is essential that the server translate the file handle to an internal representation of the file system object. The client might store the file handle for a later request to the server but there is no need for the client to discover the contents of the file handle. The client can also compare two file handles from the server for equality by using a byte-to-byte comparison. The client needs a file handle to initiate communication with the server. The MOUNT protocol can be used to translate a string based file system path name to a file handle, which can then be used by the client. Thus, the client gets its first file handle by mounting a file system residing on the server. 4.2 File System Operations This section provides a detailed description of all the operations that are supported by this file system protocol. The operations are motivated by NFS [25] and CIFS [27]. 4.2.1 Procedure 1: NULL No Operation This operation performs the standard NULL procedure. It does not take any arguments and has no functionality associated with it. It is sometimes, used to measure the overhead of processing a service request. The server must ensure that no unnecessary work is done in servicing this procedure.

PAGE 53

42 4.2.2 Procedure 2: CHGGRP Change group association This operation permits the user to change her present group association. Members of a group are allowed access to certain file objects on the server. The server decides this and the user is then allowed to change her group. Once this command is executed, this requires the user to re-authenticate her credentials, and she can change her group if the authentication succeeds. 4.2.3 Procedure 3: CLOSE Close the file This operation closes the file and the client should return any locks held by the file back to the server. The server may either force all locks to be removed or it may not allow close unless all locks are returned to the system. The server must return an error if any of the following conditions are found: File object locks are open after the file is closed. File handle for file to be closed is inconsistent or bad. File has been moved and cannot be retrieved. 4.2.4 Procedure 4: COMMIT Commit cached data This operation commits the cached data to a stable storage medium for the file specified by the current file handle. The server notifies the client if a successful commit has occurred or if a failure takes place. 4.2.5 Procedure 5: CREATE Create a file object This operation creates a regular file or a directory or a symbolic link, depending on the argument passed. The create operation requires the location i.e. the path name and the name of the file to create a new object. It returns the file handle if the operation is successful, else it returns an error.

PAGE 54

43 4.2.6 Procedure 6: DELEGPURGE Purge all delegations for a client Delegation allows a client to locally service operations on files. The server then delegates certain responsibilities to the client. This feature is very useful in weakly connected networks. This concept is dealt with in the succeeding sections. DELEGPURGE operation purges all of the delegations awaiting recovery for a given client. This is useful for clients, which do not commit delegation information to stable storage. This is also used to indicate that the server need not delay conflicting requests from other clients while it is awaiting recovery of delegation information. 4.2.7 Procedure 7: DELEGRETURN Return Delegation Returns the delegation back to the server for the given client id and file handle. Delegations may be returned either on a recall by the server or voluntarily by the client when it has completed modifying the delegated object. 4.2.8 Procedure 8: GETATTR Get File Attributes The following file attributes are supported by this file system protocol. Type: The type of the file object whether file, directory, symlink etc. Change: A value created by the server that the client can use to determine if file data,directory contents or attributes of the object have been modified. Size: The size of the object on bytes. Fsid: Unique filesystem identifier for the filesystem holding this object. Lease_time: Duration of the leases at server in seconds. Filehandle: The file handle of this object for various file operations. The GETATTR operation will obtain attributes for the filesystem object specified by the current filehandle. The client sets a bit in the bitmap argument for each attribute value that it would like the server to return. The server returns an attribute bitmap that

PAGE 55

44 indicates the attribute values for which it was able to return, followed by the attribute values ordered lowest attribute number first. The server must return a value for each attribute that the client requests if the attribute is supported by the server. If the server does not support an attribute or cannot approximate a useful value then it must not return the attribute value and must not set the attribute bit in the result bitmap. The server must return an error if it supports an attribute but cannot obtain its value. In that case no attribute values will be returned. 4.2.9 Procedure 9: GETFH Return current file handle This procedure returns the current file handle for the required object. 4.2.10 Procedure 10: LOCK Create a lock This procedure can be used to create a write LOCK on a file object if the server-side file system supports this feature. If a lock cannot be created then an error message is returned. A LOCK request can be placed on a file or on a directory but not on a symlink. 4.2.11 Procedure 11: LOCKT Test for a lock This operation checks if an object is attached to a lock. Appropriate messages are returned based on the result of the operation. 4.2.12 Procedure 12: LOCKU Unlock the object This operation unlocks the lock specified on an object. The file is specified as in a LOCK operation. Appropriate messages are returned based on the result of the operation. 4.2.13 Procedure 13: LOOKUP Lookup filename This operation looks up or finds a filesystem object (either a directory, a file or a symlink) using the directory specified by the current filehandle. On return this operations returns the filehandle of the object that it searched. If the search is unsuccessful, an

PAGE 56

45 appropriate error message is returned. The pathname can be specified in the lookup, depending on the file system, the field separator can be set up 4.2.14 Procedure 14: PUTFH Set Current File Handle This operation replaces the current filehandle with the filehandle provided as an argument. 4.2.15 Procedure 15: READ Read from a file The READ operation reads data from the regular file identified by the current filehandle. The client provides an offset of where the READ is to start and a count of how many bytes are to be read. An offset of 0 (zero) means to read data starting at the beginning of the file. If offset is greater than or equal to the size of the file then an error message is displayed. 4.2.16 Procedure 16: READDIR Read contents of a directory The READDIR operation retrieves a variable number of entries from a filesystem directory and returns client requested attributes for each entry 4.2.17 Procedure 17: READLINK Read a symbolic link READLINK reads the data associated with a symbolic link. 4.2.18 Procedure 18: REMOVE Remove a filesystem object The REMOVE operation removes (deletes) a directory entry named by filename from the directory corresponding to the current filehandle. If the entry in the directory was the last reference to the corresponding filesystem object, the object may be destroyed.

PAGE 57

46 4.2.19 Procedure 19: RENAME Rename a filesystem object The RENAME operation renames the object identified by oldname in the source directory corresponding to the saved filehandle, as set by the SAVEFH operation, to newname in the target directory corresponding to the current filehandle. The operation is required to be atomic to the client. Source and target directories must reside on the same filesystem on the server. On success, the current filehandle will continue to be the target directory. 4.2.20 Procedure 20: RENEW Renew a lease The RENEW operation is used by the client to renew leases that it currently holds at a server. In processing the RENEW request, the server renews all leases associated with the client. 4.2.21 Procedure 21: RESTOREFH Restore a saved filehandle This operation is used to set the value of the current filehandle to the value in the saved filehandle. If there is no such filehandle an appropriate error message is displayed. 4.2.22 Procedure 22: SAVEFH Save current filehandle This operation is used to save the current filehandle. It overwrites the previous value of saved filehandle. The SAVEFH operation is used along with the RENAME operation. 4.2.23 Procedure 23: SETATTR Set attributes The SETATTR operation changes one or more of the attributes of a filesystem object. The new attributes are specified with a bitmap and the attributes that follow the bitmap in bit order.

PAGE 58

47 4.2.24 Procedure 24: WRITE Write to a file This operation writes data to a regular file. The current file handle points to the target file. The write operation begins from the offset field that is passed along with this operation. 4.2.25 Procedure 25: RELEASELOCK Release lock associated with a file This operation is used to notify the server that the lock owner is no longer in use by the client. This allows the server to release cached state related to the specified lock owner. If file locks, associated with the lock owner, are held at the server, appropriate error messages are returned. 4.3 Caching Caching [28, 29, 30] involves keeping frequently used data close to where it is needed, or preloading data in anticipation of future operations. In our file protocol, caching refers to storing data from a file on the client and the data can be read from the local memory instead of the remote server. In some cases, the client will not be able to load the complete file owing to lack of memory, then the client can cache the required portion of the file in its local memory. The advantage that this provides is that the client can load and update large files even if it lacks the necessary memory. The client can be connected to the server using either a weak connection (one that has a low data transfer speed and is not stable) or a strong connection (one that supports fast data transfers and is rarely disconnected). Depending on the type of connection present between the client and the server, the server can decide whether or not caching is necessary. Consider a scenario, in which the client needs to update a file on the server frequently. If the connection is weak, the client can spend a considerable amount of time

PAGE 59

48 in transferring data over the network, for every modification made to the file. Under such circumstances it is essential that the client cache the file locally and make all the changes to the local copy. Once all modifications are completed or if the server sends a call back request, the existing copy of the file on the server is updated by the clients copy and the local copy on the client is destroyed. If the connection is stable and supports a high data transfer rate, then the server may not allow the client to make a local copy or to cache a file. In this case, the client must make all the necessary modifications directly to the file present on the server. 4.3.1 Client-side Caching Client-side caching [28] works by keeping a copy of the file object in local storage. Client-side caching of data, of file attributes, and of file names is essential to providing good performance because of weak connectivity and low computing power associated with the client. Most file system protocols require the client to repeat their file data cache validation requests at the time the file is opened. This behavior can have serious performance drawbacks. A common case is one in which a file is accessed only by a single client. Therefore, sharing of this file is infrequent. In this case, repeated reference to the server to find that no conflicts exist is expensive. A better option with regards to performance is to allow a client that repeatedly opens a file to do so without reference to the server. This is performed until potentially conflicting operations from another client actually occur. A similar situation arises in connection with file locking. Sending file lock and unlock requests to the server as well as the read and write requests necessary to make data caching consistent with the locking semantics can severely limit performance. When

PAGE 60

49 locking is used to provide protection against infrequent conflicts, a large penalty is incurred. This penalty may discourage the use of file locking by applications. Thus to improve performance, the file system protocol introduces a delegation [25] mechanism which allows many decisions normally made by the server to be made locally by clients. This mechanism provides efficient support of the common cases where sharing is infrequent or where sharing is read-only. The next section provides a detailed discussion of the delegation mechanism. 4.3.2 Caching of File Data For file data, the client checks its cache validity when the file is opened. A query is sent to the server to determine if the file has been changed. Based on this information, the client determines if the data cache for the file should kept or released. Also, when the file is closed, any modified data is written to the server. When applications share access to a set of files, they need to be implemented so as to take account of the possibility of conflicting access by another application. This is true whether the applications in question execute on different clients or reside on the same client. File locking, which is discussed in the next section, is a facility available in this protocol that allows applications to coordinate access by providing mutual exclusion facilities. The protocol's data caching must be implemented such that it does not invalidate the assumptions that those using these facilities depend upon. 4.3.3 Caching Operations The operations involved in caching of data are described below: First, cached data present on a client must be revalidated after doing an OPEN. Revalidating means that the client fetches the change attribute from the server, compares

PAGE 61

50 it with the cached change attribute, and if different, declares the cached data (as well as the cached attributes) as invalid. This is to ensure that the data for the OPENed file is still correctly reflected in the client's cache. Second, modified data must be flushed to the server before closing a file OPENed for write. If the data is not flushed at CLOSE, the revalidation done after client OPENs as file is unable to achieve its purpose. The other aspect to flushing the data before close is that the data must be committed to stable storage, at the server, before the CLOSE operation is requested by the client. In the case of a server reboot or restart and a CLOSEd file, it may not be possible to retransmit the data to be written to the file. 4.3.4 Organizing Cached Data When clients cache data, the file data needs to be organized according to the filesystem object to which the data belongs. For this file system, for the purpose of caching a distinct filehandle represents a distinct filesystem object. So for every object cached, there will exist a filehandle for that object. The client then has the choice to organize and maintain the data cache on this basis. 4.3.5 Delegation and Callbacks It is possible for the server to delegate certain responsibilities to the client. The essence of a delegation is that it allows the client to locally service operations such as OPEN, CLOSE, LOCK, READ, and WRITE without immediate interaction with the server. 4.3.5.1 Delegation When the server grants a delegation for a file to a client, the client is guaranteed certain semantics with respect to the sharing of that file with other clients. At OPEN, the server may provide the client either a read or write delegation for the file. If the client is

PAGE 62

51 granted a read delegation, it is assured that no other client has the ability to write to the file for the duration of the delegation. If the client is granted a write delegation, the client is assured that no other client has read or write access to the file. Because the granting of a delegation is always conditional upon the absence of conflicting access, clients must not assume that a delegation will be granted and they must always be prepared for OPENs to be processed without any delegations being granted. Once granted, a delegation behaves in most ways like a lock. There is an associated lease that is subject to renewal together with all of the other leases held by that client. Unlike locks, an operation by a second client to a delegated file will cause the server to recall a delegation through a callback. 4.3.5.2 Callbacks Only the server can recall delegations. If another client requests access to the file in such a way that the access conflicts with the granted delegation, the server is able to notify the initial client and recall the delegation. With the use of a callback, from server to client, a server recalls delegated responsibilities when another client engages in sharing of a delegated file. On recall, the client holding the delegation must flush modified state (such as modified data) to the server and return the delegation. The conflicting request will not receive a response until the recall is complete. The recall is considered complete when the client returns the delegation or the server times out on the recall and revokes the delegation as a result of the timeout. Following the resolution of the recall, the server has the information necessary to grant or deny the second client's request.

PAGE 63

52 At the time the client receives a delegation recall, it may have substantial state that needs to be flushed to the server. A client failure or a network partition can result in failure to respond to a recall callback. In this case, the server will revoke the delegation, which in turn will render useless any modified state still on the client. 4.3.6 Caching Conclusion Some of the other operations such as READDIR or LOOKUP can also be cached, depending on the amount of memory available on the client. Though caching improves on data access time, a compromise should be found between data cached and the amount of memory available on the client. 4.4 File Locking File locking [31, 32] is the act of ensuring that when a user accesses a file, usually via a software application, no other user can change the file until the previous user has completed examining it. So if a file has to be modified, then file locking ensures that no one else can examine or modify the file until the lock has been released. File locking allows one process to gain exclusive access to a file or part of a file and forces other processes requiring access to the file to wait for the lock to be released. Locking can be implemented in either of the two ways proposed here. Locking can pose to be a significant overhead and depending on the file system usage, it can either be avoided or implemented. In file systems such as Network File System [26], NFS v3, locking is almost non-existent. Multiple readers are allowed to read a file and when multiple writers write into a file, the last writer is the one that succeeds. The rest of the writers are allowed to write but the modifications made by them are not visible on the file. This might seem like a very risky situation, but in most non-critical cases of file

PAGE 64

53 system use, this method succeeds. The advantage of this method is that it poses lesser design implications and is much easier to implement than locking as implemented in CIFS. In the Common Internet File System (CIFS) [27], locking is necessary for any unsafe operation. A safe operation is defined as only one client is writing to a file or many clients are accessing a file as long as all are just reading. If many clients are writing a file simultaneously, then none are safe, and all file operations have to go to the server. The protocol notifies all clients accessing a file of changes in the number and access mode of clients accessing the file, so that they can use the most optimized safe access method. The implementation in CIFS causes a lot more delays and waits but all users can be assured that all their modifications or updates are made to the file. In Ubiquitous File System Protocol, multiple readers are allowed to read from a file so long as no writer has access to the file. If a writer requests file access, then there should be no other conflicting writes on this file object. If another writer is holding a lock then this writer request will need to be queued, as explained further on in this section. If multiple reads are taking place and if a writer requests a lock, then this is allowed to proceed and the writer is given a lock. This implies that the readers could be left with an old copy of the file object and the user must take necessary steps to ensure consistency of the file object being accessed. To summarize, this file system protocol has only a write lock and does not have a read lock associated with a file object. Integrating file locking into this protocol causes the protocol to be stateful. Stateful services are those that require the server to maintain client information from one

PAGE 65

54 transaction to the next i.e. maintain the state. As the protocol is stateful, care must be taken to handle the following conditions. Appropriate division of state management responsibilities between the client and server. Mechanism should be provided for detecting an inconsistency in state between the client and the server. In case of either a client or a server crash, appropriate recovery mechanisms should be provided. There are two specific state-related problems involved in providing the locking in a network context. If the client has crashed, the lock can be held forever by the server. If the server has crashed, it loses its state (including all its lock information) when it recovers. File locking involves a request from the client for a lock on a file and later on both the client and the server need to communicate between themselves, detecting if any inconsistencies arise. So the communication phase can be divided into two different types. 4.4.1 Lock Request For each LOCK request, the client must identify itself to the server. This is done in such a way so as to allow for correct lock identification and crash recovery. Establishment of identification by a new incarnation of the client also has the effect of immediately breaking any leased state that a previous incarnation of the client might have had on the server, as opposed to forcing the new client incarnation to wait for the leases to expire. The client request will need two fields, the verifier and a field to identify the client. The verifier is a random value reset by the client every time it reboots. A suggested value for the verifier is appending the date and time of reboot with the IP address of the client. The client on every initialization changes the verifier, the server can compare a new

PAGE 66

55 verifier to the verifier associated with the currently held locks and determine that they do not match. So if the server has previously recorded the client and if the value in verifier has changed, then all previously recorded states can be removed. The identification string has to be unique and specific for each client. A possible identifier is the home address field used in Mobile IP [33]. Since we assume that our file system runs on devices having Mobile IP addresses, the home address can be set as the unique identification string. Since the care-of address used in Mobile IP changes as the device changes its access point it is not possible to use the care-of address field. Another possible identification string can be based on the serial number available on the device. It is possible to perform a one-way function on this serial number and the string generated can be used as the identification string. An advantage of using the one-way function is that the serial number will be protected from public access and privacy is maintained. A request for a lock on a file object can be handled in three different ways. This section provides an overview of possible locking mechanisms with state diagrams for each model. 4.4.1.1 Indefinite Wait Figure 4-1 illustrates the scenario where a client has to wait indefinitely to receive a lock for a file object. The client sends a request to the server for lock on a file object. The server then verifies if a lock can be provided or not. If a lock is not available, the client is made to wait until the lock is free. Once the lock is free, the server provides the client with the lock. The advantage of this approach is that the client can be sure of receiving a lock once it requests for a lock to a file object. On the flip side the client is made to wait for an indefinite duration of time.

PAGE 67

56 Figure 4-1. Scenario where the client has to wait indefinitely until another client releases the lock Indefinite wait. 4.4.1.2 No Wait Figure 4-2 depicts the scenario where a client makes a request for a lock on a file object, and the server verifies if the lock can be given or not. If the lock is free, then it is provided to the client. Unlike in the previous case, if the lock is not free and is being used by another client, then the client is informed that that lock is not free. The client will need to try again. An advantage of this approach is that it is easy to implement this design and

PAGE 68

57 the client has to wait for the least amount of time. On the flip side, the client will need to make the request at a later stage as the server does not continue holding on to the request. Figure 4-2. Scenario where the client either receives a lock or has to try again later No wait. 4.4.1.3 Finite Wait Figure 4-3 depicts the scenario where the client makes a request for a lock on a file object. If a lock is free then it is given to the client immediately. If another client is using the lock, then the clients lock request is added to a queue. The queue size is fixed, so if the queue is full, then the client is informed of the failure to receive a lock.

PAGE 69

58 Figure 4-3. Scenario where the clients request is added to a queue of finite size and has to wait until another client releases the lock and its request reached the top of the queue Finite wait. In the other case, the clients request is added to the queue. All client requests are given equal priority and as the queue is a First In First Out (FIFO) object, the client

PAGE 70

59 requests are processed in the same manner as they were added to the queue. This method has a number of advantages, the primary one being that in the worst case the client has to wait for a finite amount of time. Moreover the queue size is specified to be large enough to accommodate a number of client requests, so most client requests terminate only after receiving the lock. On the flip side this is comparatively difficult to implement as the queue has to maintained. In this file system, the aforementioned Finite Wait method of locking is used, the client can request either a read / write access to a file. A read access proceeds without a lock if the file does not have a write lock associated with it. If the client requests a write access to the file, and if the file does not have a write lock associated with it, the client is given the lock. If the client requests a write access to a file object, and if another client is holding the lock for this file, then this request is added to a lock queue which is processed in FIFO manner. 4.4.2 Lock Release The lock associated with an object can be released either based on a client request or by the server if it discovers an inactive client. The client can request for the release of lock associated with the file. The server then releases the lock after verifying the identity of the client. The server might also need to periodically check for the activity of the client and if inactive will need to release the lock. A request is sent to the client mentioning that the lock will soon be released. The server then waits for a response from the client for a previously specified duration of time. If the client does not respond then the lock is released. When the lock is released, then the lock queue is scanned. If any other client has placed a request for this file object then it is given the lock to this file object. Once again

PAGE 71

60 as the implementation is based on a queue, the first request is given priority and is processed before the other requests. 4.4.3 Crash Recovery The important requirement in crash recovery is that both the client and the server know when the other has failed. Additionally, it is required that a client sees a consistent view of data across server restarts or reboots. All READ and WRITE operations that may have been queued within the client or network buffers must wait until the client has successfully recovered the locks protecting the READ and WRITE operations. 4.4.3.1 Client If the client crashes, then on reboot and initialization, the value in the verifier field is modified. A request is made to the server for a lock. The server then compares the old verifier value with the new one for the particular client id and determines that the client has crashed and restarted. The old lock is then released and a new one is provided to the client once again. The lock queue is also scanned and any lock requests stored with the previous verifier is removed. The client will need to place new requests for any of the file objects it needs to write. 4.4.3.2 Server If the server loses locking state (usually as a result of a restart or reboot), it must allow clients time to discover this fact and reestablish the lost locking state. The client must be able to reestablish the locking state without having the server deny valid requests because the server has granted conflicting access to another client. Likewise, if there is the possibility that clients have not yet reestablished their locking state for a file, the server must disallow read and write operations for that file.

PAGE 72

61 4.5 Group Permissions In this protocol the client is authenticated by the server before the data transfer phase begins. As was explained in the last chapter, once the identity of the client is known the server assigns the client to a predefined group. This group is given access to some or all files on the server. The client is thus allowed to read / write to all the files in this region. Sometimes the client might need to change the group that it is presently associated with. This can be performed by the operation CHGGRP, as defined in the File Operations section. This allows the user to change her group association. The user can be assigned to only one group at a time and will need to change the group if it needs access to files other than those accessible to this group. The advantage of this approach is that one can do away with Access Control Lists [34] (ACLs). This allows a larger degree of freedom in implementation and does not pose to be a major constraint in file access because the user can still change a group or file associations. Moreover as transfer occurs over wireless networks and as computational power is limited on the mobile clients, from a data transfer point of view, one can do with minimal file or directory access restrictions.

PAGE 73

CHAPTER 5 CONCLUSIONS AND FUTURE WORK 5.1 Conclusions This thesis presents a new file system protocol that can be used by the entire gamut of connected computing devices for file sharing, be it wired or wireless. This protocol features support for low power portable computation devices without any compromise on file sharing functionality issues. Needless to say, it also supports high power computation devices. On wireless networks, security has always been a matter of major concern. Owing to this the trade-off between security and computation complexity has become the issue, which requires much deliberation. The authentication stage of this protocol is the result of an in-depth analysis into the various other protocols available and their associated complexities. The implementation of the authentication stage using a partially trusted proxy enables the low power computation devices to use any of the best suitable authentication protocols. The file sharing protocol presented in Chapter 4 is an amalgam of features taken from various commercially successful file systems. This file system has been optimized for low power computation devices without any compromise on file sharing functionality issues. Some of the file system features such as caching and locking break new grounds. The server allows for client-side caching of a file object depending on a weak connection or a strong connection. The file system also allows multiple clients to read from a file, whereas only one writer can perform writing to a file object. Once authentication is 62

PAGE 74

63 successful, each client is provided certain access permissions depending on the group affinity. Unlike in the traditional file system group policies, where a client can change a group affinity and thus have a different set of file access permissions, in the ubiquitous file system, access permissions are decided by the server during authentication. The client can change its access permissions by requesting the server for a change of group affinity. 5.2 Future Work With the advent of wireless networks, the requirements of information security have undergone a sea change. The file system that is discussed in this thesis has attempted to provide adequate security for most day-to-day applications. Hardware cryptographic mechanisms such as Fortezza Crypto Card, formerly called Tessera [15] can be interfaced with the existing file system design and these algorithms may provide better user response times with possibly an improved level of security. Some of the algorithms mentioned require a partially trusted proxy; this can pose as a weak link in the system. The details stored in the proxy need to be deleted after every transaction, and mechanisms can be found to improve upon this system. The design of a file system is a complex affair especially with distributed file systems that allow weakly connected operations. The features that can be added to such a file system are immense and most file systems are tailored to suit the operation environment. The next stage is to provide an implementation of this file system design. In an attempt to reduce the burden on low power computational devices, just the required file system operations have been added to this protocol. Features such as group permissions and access control lists can also be added to this file system protocol. Compound file operations can be created which can perform a pre-defined set of operations as requested by the client. Moreover in an attempt to create a generic file

PAGE 75

64 system protocol, file locking for write operations has been added as a feature to this protocol. Depending on the file system usage, one can do away with write locks and this would vastly improve file system performance. Journaling [35] is a useful feature that can be added to this file system and would provide a lot more stability to this file system. Again techniques, which exploit and adapt to the communication opportunities at hand are needed. Such techniques may include compressed network transmission, partial file transfer and caching at intermediate intervals.

PAGE 76

APPENDIX A FILE SYSTEM OPERATIONS This appendix lists the various possible file operations that are discussed in this file system protocol. All the operations mentioned must be present in an implementation of this file system. A detailed discussion of these operations can be found in Chapter 4. Operations with Arguments Procedure 1: NULL No Operation This operation does not take any arguments. Procedure 2: CHGGRP Change Group Association This operation takes the client identifier as its argument. Procedure 3: CLOSE Close the File This operation takes the file handle as its argument. Procedure 4: COMMIT Commit Cached Data This operation requires the offset as the argument passed. The offset specifies the position within the file where the flush is to begin. An offset value of 0 (zero) means to flush data starting at the beginning of the file. The count specifies the number of bytes of data to flush. If count is 0 (zero), a flush from offset to the end of the file is done. Procedure 5: CREATE Create a File Object This operation takes three arguments, file object type, file object name and attributes of the file object. Procedure 6: DELEGPURGE Purge All Delegations for a Client This operation requires the client identification as its argument. 65

PAGE 77

66 Procedure 7: DELEGRETURN Return Delegation This operation takes as argument the file handle. Procedure 8: GETATTR Get File Attributes This operation does not require any arguments. Procedure 9: GETFH Return Current File Handle This operation does not require any arguments. Procedure 10: LOCK Create a Lock This operation requires two arguments, the client identification and the lock object requested. Procedure 11: LOCKT Test for a Lock This operation requires the name of the file object. Procedure 12: LOCKU Unlock the Object This operation requires two arguments, the client identification and the locked object. Procedure 13: LOOKUP Lookup Filename This operation requires the file object name as its argument. Procedure 14: PUTFH Set Current File Handle This operation requires the name of the object as its argument. Procedure 15: READ Read from a File This operation can take either the file handle of the object or the offset to read from as part of its arguments. Procedure 16: READDIR Read Contents of a Directory This operation requires the name of the directory as its argument.

PAGE 78

67 Procedure 17: READLINK Read a Symbolic Link This operation requires the name of the symbolic link as its argument. Procedure 18: RELEASELOCK Release Lock Associated with a File This operation requires the client identification and the locked object. Procedure 19: REMOVE Remove a Filesystem Object This operation requires the file handle of the object being removed. Procedure 20: RENAME Rename a Filesystem Object This operation requires the file handle of the object to be renamed. Procedure 21: RENEW Renew a Lease This operation requires the time duration for renew, the client identification and the name of the object to be renewed as its arguments. Procedure 22: RESTOREFH Restore a Saved Filehandle This operation requires the file object name as its argument. Procedure 23: SAVEFH Save Current Filehandle This operation requires the file object name as its argument. Procedure 24: SETATTR Set Attributes This operation requires the attribute set as its arguments. The attributes include type of the object, change, size, fs identifier, lease duration and file handle. Procedure 25: WRITE Write to a File This operation can take either the file handle of the object or the offset to write from as part of its arguments.

PAGE 79

LIST OF REFERENCES 1. Oracle and Telephia, US Wireless Networks are ready for Business, August 2002, http://www.oracle.com/ip/deploy/ias/mobile/US_Networks_R_Ready_FINAL.pdf accessed: 03/24/2003. 2. Satyanarayanan M, Hot Topics: Mobile Computing, IEEE Computer Sep. 1993, Vol. 26, No. 9. 3. Satyanarayanan M, Mobile Information Access, IEEE Personal Communications, Vol. 3, No. 1, February 1996. 4. Satyanarayanan M, Coda: A Highly Available File System for a Distributed Workstation Environment, Proceedings of the Second IEEE Workshop on Workstation Operating Systems, Sep 1989, Pacific Grove, CA. 5. J. Kistler and M. Satyanarayanan. Disconnected operation in Coda le system. In ACM Symposium on Operating systems and Principles, 1992. 6. Noble, B.D. and Satyanarayanan, M., Experience with adaptive mobile applications in Odyssey, Mobile Networks and Applications, Vol 4, 1999. 7. Mummert, L.B., Ebling, M.R., Satyanarayanan, M., Exploiting Weak Connectivity for Mobile File Access, Proceedings of the 15th ACM Symposium on Operating Systems Principles. 8. Martin Fowler, Kendall Scott, UML Distilled: A Brief Guide to the Standard Object Modeling Language, Reading, Massachusetts, Addison-Wesley Pub Co; 2 nd edition, 1999. 9. Data Encryption Standard (DES), http://www.itl.nist.gov/fipspubs/fip46-2.htm accessed: 12/20/2002. 10. Public Key Cryptography, http://grouper.ieee.org/groups/1363/, accessed: 12/20/2002 11. Netscape Communication Corporation, Secure Sockets Layer, http://wp.netscape.com/security/techbriefs/ssl.html accessed: 12/20/2002. 12. Tung B, Hur M, Medvinsky A and Wray J, Public Key Cryptography for Initial Authentication in Kerberos, 2001, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-12.txt accessed 01/15/2003. 68

PAGE 80

69 13. Massachusetts Institute of Technology, Kerberos: The Network Authentication Protocol, 1998, http://web.mit.edu/kerberos/www/ accessed: 01/10/2003. 14. Netscape Communications, Secure Socket Layer, Version 3.0, 1996 http://wp.netscape.com/eng/ssl3/draft302.txt accessed: 12/20/2002. 15. Fortezza PC Cards, http://www.rsasecurity.com/rsalabs/faq/6-2-6.html accessed: 03/24/03. 16. W.Diffie and M.E.Hellman, "New directions in cryptography," IEEE Trans. Inform. Theory, IT-22, 6, 1976, pp.644-654. 17. Rivest, R, L., Shamir, A., Adleman, L, A, A method for obtaining digital signatures and public-key cryptosystems, communications of the ACM, Vol 21, Nr 2, 1978. 18. I. Chlamtac et al., "Energy conservation in access protocols for mobile computing and communications," Microprocessors and Microsystems Journal, vol. 1, pp. 20--32, March 1998. 19. Schneier B, Applied Cryptography, 2 nd Edition, New York, N.Y., John Wiley, 1996. 20. Stallings W, Cryptography and Network Security--Principles and Practice, 2 nd Edition, Upper Saddle River, New Jersey, Prentice Hall Inc, 1999. 21. Hill J, Perrin T, Ross S, Singh A, Public Key Authentication on Mobile Devices, 1998, University of California, Berkeley. 22. Fox A and Gribble S D, Security on the Move: Indirect Authentication using Kerberos, in MOBICOM 96, 1996, Rye, New York. 23. Harbitter A, Menasce D, The Performance of Public-Key Enabled Kerberos Authentication in Mobile Computing Applications, IEEE Symposium on Security and Privacy, 2001, Oakland, California. 24. Stern H, Eisler M and Labiaga R, Managing NFS and NIS, 2 nd Edition, Sebastopol, California, O Reilly & Associates Inc, 2001. 25. Shepler. S, Beame. C, and others, http://www.potaroo.net/ietf/ids/draft-ietf-nfsv4-rfc3010bis-05.txt Sun Microsystems, Network File System. Version 4, November 2002. 26. NFS: Network File System--Version 3 Protocol Specification, Mountain View, CA, Sun Microsystems, February 1994. 27. Common Internet File System Technical Reference, Colorado Springs, Colorado, Storage Network Industry Association, Revision 1.0, 2002.

PAGE 81

70 28. R. Macklem. Not quite NFS, soft cache consistency for NFS. In USENIX Association Conference Proceedings, pages 261 278, January 1994. 29. Allison, C., Bramley, M., Serrano J. (1998) "The World Wide Wait: Where Does the Time Go?", Proceedings Euromicro 98 Conference "Engineering Systems and Software for the Next Decade, pp 932-940, August, IEEE Press, Vasteras, Sweden. 30. Silberschatz. A, Galvin. P, Operating System Concepts, 5 th edition, Singapore, John Wiley & Sons, Inc, 1999. 31. Chow. R, Johnson. T, Distributed Operating Systems and Algorithms, Reading, Massachusetts, Addison Wesley Longman Inc, 1997. 32. Marshall K. McKusick, William N. Joy, Samuel J. Leffler, and Robert S. Fabry, "A Fast File System for UNIX", ACM Transactions on Computer Systems 2, 3 (August 1984), 181-197. 33. Mobile Internet Protocol, http://www.computer.org/internet/v2n1/perkins.htm accessed: 03/10/2003. 34. Giampaolo. D., Practical File system Design with the Be File System, San Francisco, California, Morgan Kaufman, January 1999. 35. IBM Developer Works. and Best, S., How the Journaled File System Performs Logging, Proceedings of the 4th Annual Linux Showcase and Conference, Atlanta, GA, October 2000, 163-168.

PAGE 82

BIOGRAPHICAL SKETCH Prasad K P Menon was born in Thrissur, Kerala, India, on April 24th, 1978, and did most of his schooling in South India. He attended Government Engineering College, which is affiliated to Calicut University and located in Thrissur, Kerala, where he received a Bachelor of Technology in computer science and engineering in June 1999. After graduation he worked at Verifone India, a division of Hewlett Packard, at Bangalore as a Software Engineer. In August 2001, Prasad entered the graduate program in the CISE department at the University of Florida where he worked as a teaching assistant and attended school full time while completing the requirements for a Master of Science in computer science engineering. His research interests include network security, file systems and wireless networks. 71


Permanent Link: http://ufdc.ufl.edu/UFE0000867/00001

Material Information

Title: Ubiquitous file system protocol
Physical Description: xi, 71 p.
Language: English
Creator: Menon, Prasad ( Dissertant )
Wilson, Joseph N. ( Thesis advisor )
Newman, Richard ( Reviewer )
McNair, Janise ( Reviewer )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2003
Copyright Date: 2003

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, M.S   ( local )
Mobile computing   ( lcsh )
Personal communication service systems   ( lcsh )
Computer network protocols -- Design   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering   ( local )

Notes

Abstract: The past decade has witnessed a phenomenal growth in wireless technology, which has led to widespread use of wireless devices in all spheres of human activities. Most of these devices store data and individuals are becoming increasingly dependent on these devices for accessing information from any location. These mobile devices now require data access from other machines that can store and process vast amounts of information. This thesis proposes a file system protocol that runs on wireless networks as well as wired networks and can be used by either mobile or fixed devices to exchange data with another device. Both server and client can be stationary computers or mobile devices. Mobile devices pose hardware and software constraints and computationally intensive operations may need to be offloaded to another machine. The negotiation phase decides the type of communication that can be established between the client and the server. The authentication phase supports a number of client authentication protocols using Secure Socket Layer protocol, Data Encryption Standard, or the Kerberos protocol. Initially a client must connect to a server and authenticate itself by using any of the aforementioned authentication protocols. Once the client is authenticated, it can mount a file system and perform any necessary file operations. This file system protocol supports client-side caching, which is essential while communicating over a wireless network as the strength of the connection varies as the user travels. This can lead to disruptions in the connection between a client and server, so it is essential that such a file system protocol provide support for disconnected operation.
Subject: devices, file, mobile, system, ubiquitous, wireless
General Note: Title from title page of source document.
General Note: Includes vita.
Thesis: Thesis (M.S.)--University of Florida, 2003.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000867:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000867/00001

Material Information

Title: Ubiquitous file system protocol
Physical Description: xi, 71 p.
Language: English
Creator: Menon, Prasad ( Dissertant )
Wilson, Joseph N. ( Thesis advisor )
Newman, Richard ( Reviewer )
McNair, Janise ( Reviewer )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2003
Copyright Date: 2003

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, M.S   ( local )
Mobile computing   ( lcsh )
Personal communication service systems   ( lcsh )
Computer network protocols -- Design   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering   ( local )

Notes

Abstract: The past decade has witnessed a phenomenal growth in wireless technology, which has led to widespread use of wireless devices in all spheres of human activities. Most of these devices store data and individuals are becoming increasingly dependent on these devices for accessing information from any location. These mobile devices now require data access from other machines that can store and process vast amounts of information. This thesis proposes a file system protocol that runs on wireless networks as well as wired networks and can be used by either mobile or fixed devices to exchange data with another device. Both server and client can be stationary computers or mobile devices. Mobile devices pose hardware and software constraints and computationally intensive operations may need to be offloaded to another machine. The negotiation phase decides the type of communication that can be established between the client and the server. The authentication phase supports a number of client authentication protocols using Secure Socket Layer protocol, Data Encryption Standard, or the Kerberos protocol. Initially a client must connect to a server and authenticate itself by using any of the aforementioned authentication protocols. Once the client is authenticated, it can mount a file system and perform any necessary file operations. This file system protocol supports client-side caching, which is essential while communicating over a wireless network as the strength of the connection varies as the user travels. This can lead to disruptions in the connection between a client and server, so it is essential that such a file system protocol provide support for disconnected operation.
Subject: devices, file, mobile, system, ubiquitous, wireless
General Note: Title from title page of source document.
General Note: Includes vita.
Thesis: Thesis (M.S.)--University of Florida, 2003.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000867:00001


This item has the following downloads:


Full Text












UBIQUITOUS FILE SYSTEM PROTOCOL


By

PRASAD K. P. MENON
















A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2003



























Copyright 2003

by

Prasad K. P. Menon




















To Mom, Dad and Sis















ACKNOWLEDGMENTS

Many people deserve special acknowledgements for making this thesis possible. I

must first and foremost express my deepest appreciation to my committee chair,

Dr. Joseph Wilson, for presenting me with the opportunity to work on such a fantastic

idea. Joe's continuous guidance played a significant role in bringing this project to

fruition. I would also like to thank my other committee members, Dr. Richard Newman

and Dr. Janise McNair, for their meticulous review of this thesis.

I would also like to express my gratitude to all my friends at CISE for their

encouragement and for being a constant source of motivation. They have provided input

into my research and have also extended their support towards helping me correct errors

in this document. I owe a great deal of thanks to my roommates, all of them contributing

significantly with their constructive criticisms.

Finally, I owe endless debt to my father and mother. They instilled the confidence

in me to make all of this possible.
















TABLE OF CONTENTS
page
A C K N O W L E D G M E N T S ....................................................................... .................... iv

LIST OF FIGURES .......................................... ............. ............. viii

A B ST R A C T ................. .......................................................................................... x

CHAPTER

1 IN TR OD U CTION ....................................... ...... .. ........ .... .............. .

1.1 M otiv action ............................................. 1
1.2 A approach ............................................... 2
1.3 O organization ................................................................. 3

2 FILE SYSTEM PROTOCOL ARCHITECTURE............................ ...............5

2.1 A uthentication Protocols ....................................................... 6
2.1.1 D ata Encryption Standard............................................... 6
2.1.2 Public K ey E ncryption .......................................................... .............. 7
2.1.3 Secure Socket L ayer ............................................................................... .... 7
2.1.4 K erberos A uthentication Protocol ........................................ ............... 7
2 .2 P rotocol P hases................................................. 8
2 .2 .1 N negotiation P hase ........................................................................... .............. 9
2.2.2 Authentication Phase ............................................................. ...............
2.2.3 D ata Transfer .................................................................... ...... 9
2.3 N negotiation Phase ......................................... ................... .... ...........

3 CLIENT AUTHENTICATION METHODS A COMPARISON .............................12

3.1 Authentication based on Secure Socket Layer .............................. ....................13
3.2 With DES at Client-side and Proxy with SSL Support ......................................14
3 .2 .1 M e ch a n ism ......................................................................................19
3.2.2 C conventions .... .................................................................. ........ ....... 19
3.2 .3 D difficulties ........................................ ........ ........................... 20
3.3 Authentication based on DES SSL and Data Transfer using DES ...................... 22
3.4 Authentication with Kerberos using DES..................................... .....................28
3.5 Authentication with Charon........................................................... ..........35
3.6 Authentication with Kerberos using Public Key Encryption ............................. 37
3.7 D ata Transfer Phase .................. .................................................... .. ... 39









4 FILE SH ARIN G PRO TOCOL ............................................... ............................ 40

4 .1 F ile H a n d le ...................................................................................................... 4 1
4.2 File System O perations................................................ ................ ............... 4 1
4.2.1 Procedure 1: NULL No Operation ..................................... ...............41
4.2.2 Procedure 2: CHGGRP Change group association ..............................42
4.2.3 Procedure 3: CLOSE Close the file.............................. ............... 42
4.2.4 Procedure 4: COMMIT Commit cached data ......................................42
4.2.5 Procedure 5: CREATE- Create a file object....................................... 42
4.2.6 Procedure 6: DELEGPURGE Purge all delegations for a client.............43
4.2.7 Procedure 7: DELEGRETURN Return Delegation .............................43
4.2.8 Procedure 8: GETATTR- Get File Attributes..............................43
4.2.9 Procedure 9: GETFH -Return current file handle.................................44
4.2.10 Procedure 10: LOCK Create a lock..................... ............... ............... 44
4.2.11 Procedure 11: LOCKT Test for a lock .............. ................................. 44
4.2.12 Procedure 12: LOCKU Unlock the object ........................................44
4.2.13 Procedure 13: LOOKUP Lookup filename .......................................44
4.2.14 Procedure 14: PUTFH Set Current File Handle..............................45
4.2.15 Procedure 15: READ -Read from a file.................... ............... 45
4.2.16 Procedure 16: READDIR- Read contents of a directory .....................45
4.2.17 Procedure 17: READLINK Read a symbolic link ................................45
4.2.18 Procedure 18: REMOVE Remove a filesystem object.......................45
4.2.19 Procedure 19: RENAME Rename a filesystem object........................46
4.2.20 Procedure 20: RENEW Renew a lease ...................... ............... 46
4.2.21 Procedure 21: RESTOREFH Restore a saved filehandle....................46
4.2.22 Procedure 22: SAVEFH- Save current filehandle ................................46
4.2.23 Procedure 23: SETATTR Set attributes .........................................46
4.2.24 Procedure 24: W RITE -W rite to a file................................................ 47
4.2.25 Procedure 25: RELEASELOCK Release lock associated with a file ...47
4.3 Caching ......... .... .... ....................... ...........................................47
4.3.1 Client-side Caching ............................................................................. 48
4.3.2 Caching of File Data ................. ............................. 49
4.3.3 Caching O operations ............................................................................. 49
4.3.4 Organizing Cached Data....... .. ........................ ....... .. ............... 50
4.3.5 D delegation and Callbacks ....... .. ................................. ................. 50
4.3.5.1 Delegation ................ .... ......... .. .... .........50
4 .3 .5 .2 C a llb a c k s ........................................................................................... 5 1
4.3.6 C aching C onclusion........................................... .......................... 52
4.4 File Locking ..... ............. ......... ...................52
4.4.1 Lock Request ........... .. .... ........... .............. .............. 54
4.4.1.1 Indefinite W ait ........................................... ................ ............. 55
4.4.1.2 N o W ait ............... .. ............. ................ ................ ............56
4.4.1.3 Finite W ait ............... .. ............. ......................... ... ............ 57
4.4.2 L ock R release ...................................... .............................59
4.4.3 Crash R recovery .................................... ................. ......... 60
4.4.3.1 Client ..... ............... ......... ...... ........60
4.4.3.2 Server ......................................................................... .......................... 60









4.5 Group Permissions .................. ...................................... .... ......... 61

5 CONCLUSIONS AND FUTURE WORK ............................................................62

5 .1 C o n c lu sio n s ..................................................................................................... 6 2
5 .2 F u tu re W o rk .................................................................................................... 6 3

APPENDIX FILE SYSTEM OPERATIONS ..................... .............. 65

O operations w ith A rgum ents ............................................................. .....................65
Procedure 1: NULL No Operation .............................................. ...............65
Procedure 2: CHGGRP Change Group Association .......................................65
Procedure 3: CLOSE Close the File..............................................65
Procedure 4: COMMIT Commit Cached Data...........................................65
Procedure 5: CREATE Create a File Object.................................................65
Procedure 6: DELEGPURGE Purge All Delegations for a Client...................65
Procedure 7: DELEGRETURN Return Delegation .............. ..................66
Procedure 8: GETATTR Get File Attributes........................................66
Procedure 9: GETFH Return Current File Handle............ .................66
Procedure 10: LOCK Create a Lock ..................................... .................66
Procedure 11: LOCKT Test for a Lock...................................... ................... 66
Procedure 12: LOCKU- Unlock the Object................................. ............66
Procedure 13: LOOKUP Lookup Filename ............................................. 66
Procedure 14: PUTFH Set Current File Handle.....................................66
Procedure 15: READ Read from a File................................ ..................66
Procedure 16: READDIR- Read Contents of a Directory ..............................66
Procedure 17: READLINK Read a Symbolic Link .......................................67
Procedure 18: RELEASELOCK Release Lock Associated with a File............67
Procedure 19: REMOVE Remove a Filesystem Object.............................67
Procedure 20: RENAME Rename a Filesystem Object..............................67
Procedure 21: RENEW Renew a Lease ................................... ... ..................67
Procedure 22: RESTOREFH- Restore a Saved Filehandle ............................67
Procedure 23: SAVEFH- Save Current Filehandle .......................................67
Procedure 24: SETATTR Set Attributes .................................. ............... 67
Procedure 25: WRITE Write to a File..... ..............................67

LIST OF REFERENCES ......... ........................................ ........................ 68

B IO G R A PH IC A L SK E T C H ..................................................................... ..................71
















LIST OF FIGURES


Figure pge

2-1. Scenario illustrating ubiquitous file system mounted by three different clients and
accessing files from the server. ............................................................................5

2-2. Phases involved in the protocol. ...... ...................................................................... 8

2-3. Negotiation phase when proxy is used. 1. Request from the Client for SSL based
authentication. 2. The Server transfers all requests to the Proxy. 3. All future
authentication transactions are done between the Client and the Proxy ................10

3-1. The PDA device can connect to the server using SSL. ...........................................13

3-2. State diagram for SSL mode of client authentication..............................................15

3-3. Components involved in DES-SSL mode of authentication ......................................17

3-4. State diagram for the SSL mode of client authentication when viewed at from the
proxy side. .......................................................................... 18

3-5. Transaction flow diagram among the three entities involved in the authentication
sc h e m e ........................................................................... 2 0

3-6. Components involved in DES-SSL mode of authentication with proxy removed after
authentication. ........................................................................23

3-7. State diagram for the SSL-DES mode of client authentication when viewed at from
the proxy side. ........................................................................25

3-8. State diagram involved in the SSL-DES mode of client authentication when viewed
at from the server side. ....................................... ............. .... ..... .. 26

3-9. Transaction flow diagram for DES -SSL (initial phase) and DES only (final phase)
among all the three components .............. ...................... ............... 27

3-10. The figure illustrates the various stages involved in Kerberos authentication for a
PD A client. ............................................................................30

3-11. State diagram for the first stage i.e. the client communicating with the Kerberos's
K ey D distribution Center. ........................................ ................................ 31









3-12. State diagram for the second stage i.e. the client communicating with the Ticket
G ranting Server. .................................................... ................. 32

3-13. State diagram for the third stage i.e. the client communicating with the File System
S erv er. ..............................................................................33

3-14. Transaction flow in Charon. ...... ........................... ......................................36

3-15. Transaction flow between among the entities involved in Kerberos-public key
encryption......................................................................... ... ....... ....... 38

4-1. Scenario where the client has to wait indefinitely until another client releases the
lock Indefinite w ait .................. ............................. ...... .. .......... .... 56

4-2. Scenario where the client either receives a lock or has to try again later No wait..57

4-3. Scenario where the client's request is added to a queue of finite size and has to wait
until another client releases the lock and it's request reached the top of the queue -
Finite w ait. ......... ........................................ ................................ 58















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Master of Science

UBIQUITOUS FILE SYSTEM PROTOCOL

By

Prasad K. P. Menon

August 2003

Chair: Joseph N. Wilson
Major Department: Computer and Information Science and Engineering

The past decade has witnessed a phenomenal growth in wireless technology, which

has led to widespread use of wireless devices in all spheres of human activities. Most of

these devices store data and individuals are becoming increasingly dependent on these

devices for accessing information from any location. These mobile devices now require

data access from other machines that can store and process vast amounts of information.

This thesis proposes a file system protocol that runs on wireless networks as well as

wired networks and can be used by either mobile or fixed devices to exchange data with

another device. Both server and client can be stationary computers or mobile devices.

Mobile devices pose hardware and software constraints and computationally intensive

operations may need to be offloaded to another machine. The negotiation phase decides

the type of communication that can be established between the client and the server. The

authentication phase supports a number of client authentication protocols using Secure

Socket Layer protocol, Data Encryption Standard, or the Kerberos protocol. Initially a

client must connect to a server and authenticate itself by using any of the aforementioned









authentication protocols. Once the client is authenticated, it can mount a file system and

perform any necessary file operations.

This file system protocol supports client-side caching, which is essential while

communicating over a wireless network as the strength of the connection varies as the

user travels. This can lead to disruptions in the connection between a client and server, so

it is essential that such a file system protocol provide support for disconnected operation.














CHAPTER 1
INTRODUCTION

During the past decade, the world has become increasingly dependent on mobile

devices. As a result, traditional ways of networking have proven inadequate to meet all

the challenges posed by wireless networks. If users must be connected to a network by

physical cables, their movement is dramatically reduced. Wireless connectivity, however,

poses no such restriction and allows a great deal more free movement on the part of the

network user. On the flip-side wireless network applications are complex to develop and

to maintain. Security and authentication on wireless networks is extremely difficult

owing to the additional risks posed by wireless media. Our idea is to provide a ubiquitous

file system protocol meant for devices that are either on wired networks or wireless

networks to share files on other mobile devices or from a server. Moreover mobile

devices pose hardware and software constraints that are leading to the pervasive use of

application-level proxies to mediate between client and servers.

1.1 Motivation

The increased use of mobile devices by individuals has led to widespread research

on wireless applications and on mechanisms to share information between these devices.

Mobility has placed many demands on the existing networks and on the applications

available. A study conducted in August 2002 by Oracle and Telephia [1] has defined the

primary constraints faced by mobile users. Some of the difficulties faced with mobile

devices [2] are the low computing power and memory associated with these devices, the

kind of network connectivity associated with wireless devices i.e. the time required to get









an application to function and the low battery power associated with mobile devices. In

spite of these challenges it is essential that mobile users be allowed access to information

on demand and from any location.

These problems were initially addressed during the last decade at Carnegie Melon

University [3] and subsequently enormous amount of literature has been published in this

field. Later on file systems such as Coda [4, 5] and Odyssey [6] were implemented to

solve the problems of wireless network access. In order to address the security concerns

of today, the file system protocol discussed in this thesis attempts to improve upon the

authentication systems provided in earlier file systems for mobile devices. Another

primary goal of this protocol has been to address caching issues while communicating

over a wireless link [7].

As power and memory are limited in a mobile device, the file system protocol

proposed also attempts to provide only the minimal needed functionality for file handling

operations and this can decrease the overhead on the client system.

The file system protocol has been made as generic as possible. It can be used on

wired or wireless networks and can provide file-sharing facilities to computers with a

broad range of computing power.

1.2 Approach

This file system protocol is an attempt to create a generic protocol that can be used

both on low power mobile devices and with high power wired devices. Since wireless

devices pose most of the constraints, this protocol addresses these issues. One of the

major constraints is the low computing power associated with these devices, and this

protocol attempts to transfer most of the computing to either proxy machines or to the

server. This drawback is considerably felt during the authentication phase where









authentication protocols such as SSL can take a considerable amount of time on these

devices. This protocol addresses this issue by providing a number of authentication

protocols to choose from and the client can choose one depending on it's computing

power. Some of them are allowed to offload computation to a proxy and the proxy

continues with the client authentication. An advantage of this approach, is the lower

memory needed by the client to perform the authentication.

Another constraint is the strength of network connectivity associated with these

wireless devices. Sometimes the connection is weak or at times it is even non-existent.

This file system protocol addresses this issue by providing client-side caching, depending

on the strength of the connection. Every attempt has been made to decrease the

complexity of the file system protocol both in terms of implementation and in design

without compromising on any of the file handling operations. File system features such as

Access Control Lists have not been included in this design and it is the responsibility of

the server to provide the correct file access for a client.

1.3 Organization

The thesis is organized as follows:

Chapter 2 provides an overview of the Ubiquitous File System Protocol

architecture and discusses the major phases involved.

Chapter 3 provides an in-depth discussion of the different client authentication

protocols supported by the system and also explains the architecture involved in each of

the authentication strategies. State diagrams [8] are used to explain the design involved

for each of the authentication protocols.

Chapter 4 discusses the file sharing protocol, with the various file operations and

file locking strategies. Some concepts such as the readers / writers problem are discussed






4


here. This chapter discusses caching, client-side caching and it's use depending on the

strength of the connection. It also discusses the file handling operations that are supported

by the file system. Later on this chapter focuses on locking and how the protocol

proposed handles file locking. The last section of this chapter discusses group access

permissions and illustrates the novel approach used to solve the group access problem in

this file system.














CHAPTER 2
FILE SYSTEM PROTOCOL ARCHITECTURE

This chapter provides an overview of the protocol and the various phases involved

in this protocol. A file system provides an interface to support creation, manipulation,

storage and retrieval of data on a permanent storage medium such as a disk. The two

fundamental concepts of a file system are files and directories. A file is the primary

functionality that every file system must provide to store a named piece of data and to

later retrieve the data using the name given to it. A file is where a program stores data

permanently. The size of data stored may range from only a few bytes to the entire

capacity of a volume. A file system must provide a way to name and organize multiple

files, and a directory is used for this purpose.





----------2-
Laptop omTputer



Hand held computer
Fixed poinL computer


Figure 2-1. Scenario illustrating ubiquitous file system mounted by three different clients
and accessing files from the server. Dotted lines represent a wireless
connection while the black line represents a wired connection.

The ubiquitous file system protocol is a generic protocol designed for both wired

and wireless devices. Figure 2-1 illustrates three different clients mounting the file









system from the server. Clients are allowed to mount the server-side file system and

perform necessary operations on the file objects.

This protocol can be broadly classified into two stages. The first stage is the

authentication layer, where a client is made to authenticate and prove its identity to the

server. When the authentication is successful, then the client is allowed to mount the

server's file system and perform the required file operations.

2.1 Authentication Protocols

Authentication is the process of verifying identity so that one entity can be sure that

another entity is who it claims to be. It is essential to authenticate the devices involved in

communication before any file-sharing protocol can be used. In the case of our file

system, communication can occur between two mobile devices or between a mobile

handset and a server.

In a mobile computing context, the processing and communications resources

required to perform encryptions and decryptions and to transmit large messages may

result in unacceptable performance characteristics and extended user authentication

response times.

This protocol supports a number of client authentication protocols using Secure

Socket Layer protocol, Data Encryption Standard, or the Kerberos protocol. A brief

explanation of each of these protocols is mentioned below.

2.1.1 Data Encryption Standard

Data Encryption Standard (DES) [9] is a block cipher algorithm; it encrypts data in

64 bit blocks. A 64-bit plain text goes in one end of the algorithm, and a 64-bit block of

ciphertext comes out the other end. Both encryption and decryption use the same









algorithm. The key length can be any 56 bit number and can be changed at any time. All

security rests within the key.

2.1.2 Public Key Encryption

Public key encryption [10] is a technique that uses a pair of asymmetric keys for

encryption and decryption. Each pair of keys consists of a public key and a private key.

The public key is made public by distributing it widely. The private key is never

distributed; it is always kept secret.

Data that is encrypted with the public key can be decrypted only with the private

key. Conversely, data encrypted with the private key can be decrypted only with the

public key. This asymmetry is the property that makes public key cryptography so useful.

2.1.3 Secure Socket Layer

Secure Socket Layer (SSL) technology was developed by Netscape

Communications Corporation [11] for protecting web based communications. The SSL

security protocol provides data encryption, server authentication and message integrity.

SSL comes in two strengths, 40-bit and 128-bit, which refer to the length of the "session

key" generated by every encrypted transaction. The longer the key, the more difficult it is

to break the encryption code.

2.1.4 Kerberos Authentication Protocol

Kerberos is a trusted third-party authentication protocol [12, 13]. It is designed to

provide strong authentication for client/server applications by using secret-key

cryptography. A Kerberos service, sitting on the network acts as a trusted arbitrator.

Kerberos provides secure network authentication allowing a person to access different

machines on the network. Kerberos is based on symmetric cryptography, and it shares a









different key with every entity on the network. Knowledge of the secret key is used as

proof of identity.

2.2 Protocol Phases

The authentication stage is further complex. The protocol has to consider two

particular cases to handle during the authentication stage, if on the destination side we

have a server, then it can handle any kind of SSL or Kerberos authentication mechanism

whereas, if the destination is a PDA device then we will once again need to have a proxy

at the destination end and every SSL request to the PDA-device should be re-routed to

the proxy on the destination side. This is because the PDA device lacks the computing

power and the memory necessary to encrypt or decrypt SSL packets. This implies that

one would need to know the kind of device that is used at the destination end. In order to

ascertain the kind of device that is being used on the destination side, we have divided the

communication between the client/proxy and the server can into three phases.


Figure 2-2. Phases involved in the protocol.









2.2.1 Negotiation Phase

This is the first phase of communication between the client and the device at the

destination end. During this phase we check if the server can respond to SSL encrypted

messages or not, as in the case of a PDA device. If a PDA device is used as the server,

then the IP address of the proxy is retrieved in this phase. The rest of the communication

occurs with the proxy acting as an intermediary for the PDA device at the destination.

2.2.2 Authentication Phase

During this phase, both the parties authenticate each other through Secure Socket

Layer, Data Encryption Standard or Kerberos authentication mechanisms. A significant

amount of processing power and free memory is needed during this stage owing to the

encryption and decryption of the client and server certificates. The next chapter discusses

ways to offload computation to other computers and this decreases the load on each

client.

2.2.3 Data Transfer

Once authentication is complete, the client and the server can communicate over

the network using DES, SSL or Kerberos mechanisms. The client mounts the file system

on the server and the rest of data transfer is handled by the file transfer protocol.

As part of our study we compare the client authentication mechanisms that are

possible, between the client and the server. The rest of this chapter discusses the

negotiation phase, and the other two phases are discussed in the later chapters.

2.3 Negotiation Phase

This phase is the first stage of communication between the mobile client and the

server. The client device could be either a PDA device or even a mobile notebook. Also,

the server can either be a mobile device or a computing device placed at a fixed location.










In an attempt to provide for a generic file system protocol, it is necessary to consider the

case where, the server is a mobile PDA device with low memory and low computing

power. Most authentication protocols require a large degree of computing power and a

significant amount of free memory, on both the server and the client machines and in

some cases the server might not be able to handle such a load. In such cases, the client

and the server will require a considerable amount of time to authenticate using Secure

Socket Layer.

The negotiation phase is useful in such situations. During this phase, the client

sends a request to the server inquiring if the server-computing device can handle the

required authentication protocol. For example, the client sends a request to the server to

verify if the server can handle SSL requests. In most cases, the server will be able to

handle such requests and will respond with an acknowledgement message and this

concludes the Negotiation phase.




/ Client
S/ Server
unable to
handle
SSL
3 2 requests.
SSL Proxy
for Server



Figure 2-3. Negotiation phase when proxy is used. 1. Request from the Client for SSL
based authentication. 2. The Server transfers all requests to the Proxy. 3. All
future authentication transactions are done between the Client and the Proxy.

If the server is unable to handle the SSL requests, for example the server might be

another mobile device and in such cases a proxy can be used to and the server will

transfer the SSL computations to the proxy. This assumes that the proxy is a partially









trusted device and the proxy later interacts with the client in the next phase. This

concludes the Negotiation phase in this case.

The advantage of using the negotiation phase is that the file system can provide

support for a number of authentication protocols, as the computing power of a device will

cease to be a constraint. Moreover the advantage of off loading the computation from the

mobile device to a proxy is a great benefit and can speed up the authentication phase

considerably.

A similar scenario occurs when a mobile client with low computation power and

memory needs to authenticate its identity to a server device. The mobile client can then

use a partially trusted proxy to offload some or most of its computation. Since the client

is a mobile device and the proxy may be a fixed device, issues such as handover of client

etc., need to be considered. These issues are dealt with in Chapter 3.














CHAPTER 3
CLIENT AUTHENTICATION METHODS A COMPARISON

This chapter provides a detailed discussion of the various authentication protocols

that can be used for identifying the client and the server devices connected using either

wired or wireless networks. The initial three protocols are authentication protocols based

on Data Encryption Standard (DES) [9] and Secure Socket Layer (SSL) [11, 12, 14]

whereas the last three protocols are based on the Kerberos [12, 13] standard. These three

protocols cover a broad spectrum of authentication protocols available today.

Data Encryption Standard is a symmetric key algorithm and is popular because of

the faster response times that can be achieved when this algorithm is used. SSL is one

among the most widely used authentication mechanisms on the Internet and does provide

an adequate level of security for most client-server applications. Kerberos has been found

useful as an authentication mechanism in distributed systems, where a client needs to

communicate with a number of servers. Kerberos can be used with either DES or with

public key cryptography and both of these authentication mechanisms are discussed in

this chapter. Hardware based cryptographic algorithms such as Fortezza [15] have not

been covered in this chapter, as these algorithms are machine-specific and an attempt has

been made to use generic authentication algorithms which are not machine dependent.

The SSL security protocol provides data encryption, server authentication, message

integrity, and optional client authentication for a TCP/IP connection. SSL is a layered

protocol. At each layer, messages may include fields for length, description, and content.

SSL takes messages to be transmitted, fragments the data into manageable blocks,









optionally compresses the data, applies a MAC, encrypts, and transmits the result.

Received data is decrypted, verified, decompressed, and reassembled, then delivered to

higher-level applications. SSL [11, 14] comes in two strengths, 40-bit and 128-bit, which

refer to the length of the "session key" generated by every encrypted transaction. The

session key is a unique key generated by the client and encrypted with the server's public

key. This encrypted message is then sent across to the server, which can decrypt and

retrieve the session key using it's private key. The client uses this key to encrypt all

communication with the server. The longer the key, the more difficult it is to break the

encryption code but more time-consuming for encryption and decryption. So a balance

needs to be maintained between the power and memory associated with the computing

device and the length of the session key. Among the protocols discussed, SSL is one of

the easiest to implement owing to the number of third-party tools available. It is also

extremely popular and is supported by most server systems.

3.1 Authentication based on Secure Socket Layer

The first authentication mechanism that we consider is based on the Secure Socket

Layer. Both the client and the server side communicate using Secure Socket Layer to

PDA -Client Server


SSL --SSL-
S Services
requests
from Client



Figure 3-1. The PDA device can connect to the server using SSL.

authenticate each other. SSL uses public key encryption [16, 17] and even with 40-bit

encryption, this is computation intensive and also requires a large amount of free memory









to perform all computations. This places a considerable overhead on a PDA device and

the time taken to encrypt and decrypt packets can be significant.

As shown in the Figure 3-1, the connection is straightforward; the client directly

connects to the server using the protocol SSL. Since the protocol involves only two

components, it is simple in design and Figure 3-2, illustrates the states involved in

authentication and file transfer. The dotted lines represent a change of phase for example;

the first series of dotted lines in Figure 3-2 represent the negotiation phase. In this phase

both the client and the server communicate with each other and verify if SSL can be used

for authentication. If yes, then the client and the server authenticate each other based on

their public and private keys. A failure in authentication causes the system to exit

whereas a successful authentication leads to the server allowing the client to mount the

file system.

3.2 With DES at Client-side and Proxy with SSL Support

A basis for this design is that programming portable devices is hard! It is hard

ranging for many reasons, ranging from simplicity of the device architecture to simplicity

of the programming tools. Moreover memory constraints and low computation power

[18] associated with these devices, pose major restrictions on the programmer. In the

previous authentication mechanism, the encryption and decryption of keys can be

prohibitively expensive in terms of computation power and when used on small devices.















I N- tlatlon Phas
I Negotlatlan Phase

I - -


I-------
Auiltentication Phase
begins
------------


I Data Transfer
Phlase begins
I______


Figure 3-2. State diagram for SSL mode of client authentication.









Using this protocol on portable devices would consume a lot of battery power and pose a

considerable overhead on its resources. The strategy of inserting a proxy between the

end-systems allows more efficient use of computational resources, reduces complexity of

the implementation, and increases security. The previous chapter provided a brief

overview of using a proxy device to offload computations from the server. In this section,

the issues regarding the use of proxy have been discussed in finer detail.

DES (Data encryption Standard) [19, 20] is a symmetric crypto algorithm unlike

SSL and is thus less computationally intensive. This protocol is particularly advantageous

when portable devices are used. The algorithm specifies both enciphering and

deciphering operations, which are based on a binary number called a key.

A key consists of 64 binary digits ("O"s or "l"s) of which 56 bits are randomly

generated and used directly by the algorithm. The other 8 bits, which are not used by the

algorithm, are used for error detection. The 8 error detecting bits are set to make the

parity of each 8-bit byte of the key odd, i.e., there is an odd number of 1"s in each 8-bit

byte. Authorized users of encrypted computer data must have the key that was used to

encipher the data in order to decrypt it. The unique key chosen for use in a particular

application makes the results of encrypting data using the algorithm unique. Selection of

a different key causes the cipher that is produced for any given set of inputs to be

different. The cryptographic security of the data depends on the security provided for the

key used to encipher and decipher the data. The key is usually a 64-bit number but the

encryption uses only 56 bits.

A proxy meant for SSL encryption and decryption is brought into the system. The

PDA-client and the proxy authenticate each other using DES and later the proxy handles










all communication for the client using Secure Socket Layer. The proxy is assumed to

have much greater computing power and a larger amount of free memory than a PDA

device, so the user can achieve faster response times.

This protocol is suitable if the server side supports only SSL encryption and the

client is constrained in terms of computational power, free memory available and battery

resources. A third entity is brought into the system, one that acts as an interpreter

between DES and SSL protocols.


PDA- Client Server

DES

Proxy nSSLt /
Services
S/ requests
S from Client
DES

SSL



Figure 3-3. Components involved in DES-SSL mode of authentication.

Data transfer between a client and a server can be divided into two stages. The first

stage involves using DES based authentication between the client and proxy. Both the

client and proxy agree on a shared secret key K and use a symmetric key algorithm. The

reason is that client has less computing resources and DES requires less computing power

compared to SSL.

Figure 3-4 explores the various states involved in the first stage of communication

i.e. between the client and the proxy. The dotted lines represent the change of phase and

initially the algorithm verifies if the proxy supports DES or not.















Pro~y and Client
authenticate each other
based on the shared secret
and key.
Request auth, EDES mag



Proxy EDES (result-mSg)


Certifcate for SSL (private key)


Signajure privatee key)


Ilefl ':DES (3etfCe, (pgart.ip atrjll



Proxy and Server
authenlicate each other as ter .-er s car req'i-. leiil
first part f SSL. tartlricate3


orerL. aa4r


Acklnowledgerlrten (suocessb[ai )


AppliCation Data is asc ar-r-v
encrypted by P..n" and
senL tL Client. /
1[_ ... Auth (sulcces4fail)
Auth (s uce.s/fail)



Figure 3-4. State diagram for the SSL mode of client authentication when viewed at from
the proxy side.

The second stage is the communication between the proxy and the server via an

SSL based proxy. The proxy is assumed to be a partially trusted entity and can act as an

intermediary between the client and the server. Once client authentication is performed

with the proxy then the client transfers it's certificates to the server encrypted using DES.









The proxy continues the authentication with the server using these certificates. The state

diagram for this stage is shown in Figure 3-2, the server does not differentiate between

the client and the proxy.

3.2.1 Mechanism

The algorithm can be summarized as shown below:

* Client and proxy agree on using DES.

* Client and proxy agree on a key.

* Authentication of proxy is necessary at this stage. Message is sent across by client
E DES (msg), let us say and a corresponding response by the proxy,P E DES (result-
msg).

* Authentication of client is necessary at this stage. Message is sent across by client
E DES (msg). Let us say and a corresponding response by the proxy, P E DES (result-
msg).

* Client to proxy: E DES (Service (port and host ip))

* Proxy: Locate service with the requested port and host IP address.

3.2.2 Conventions

* E DES (msg): The message "msg" is encrypted using Data Encryption Standard.

* P E DES (result-msg): The message "result-msg" is encrypted by the Proxy using an
encryption algorithm based on Data Encryption Standard.

The following assumptions are made in this protocol.

* Proxy is located in a secure area and only authorized personnel can access this
machine.

* Client can store the key in a secure manner. A chance of key retrieval by an
unauthorized person is very low.















PrFtiy and Client
authenticate each other
based on the shared secret
and key.
Request auth, EDES msg



Proxy EDES (resuIt-rms)


Certificate for SSL (private key)


Signalure privatee key)




lIJE; f.eetACM kPolg
Inltlale SSL Handshake

Proxy and Server
authenticate each other as r carl. ri e.qs lei l
first part of SSL. certificates


f-orenar aq 'neyL. OLr.er


Acklnowledgerent (suocess~f2a[i)


Application Data is-- sec and ke
encrypted by Proxy and
sent to Client.

DES Acknovledgement (s&ccesttaIl)




Figure 3-5. Transaction flow diagram among the three entities involved in the
authentication scheme.

3.2.3 Difficulties

One of the major constraints posed by this authentication scheme is that the proxy

is assumed to be a trusted source. The client is a wired or a wireless device with minimal


computing resources whereas the proxy is probably wired and fixed to a specific location.









So as the client moves, it may be necessary to transfer to another proxy. There are several

reasons this can happen:

1. Proxy is tied to a wireless access point. So it may go out of range, and cause a
break in communication.
2. The hop count may become too large, if the client travels a large area, for example
when the client travels from US to Europe.


If the client switches its wireless access point, then the proxy that the client is

connected to will change. A handover of the client's identity needs to be performed

between the client and the proxy. Ideally, there are three ways to accomplish this.

* Client handles handover without any intervention

* Proxy handles the client's handover.

* A new entity handles the handover.

Of all these, the proxy handling the handover seems the most suitable for our

purpose. The first proxy will search and find another suitable proxy that can continue

with data transfer. The proxy presently communicating will need to be requested by the

PDA client for a change in proxy.

The client will need to confirm its identity to the second proxy and the data transfer

can continue among the three entities.

A prototype for this protocol has been developed at University of California,

Berkeley and found to be faster than the previously discussed SSL protocol. Hill, Perrin,

Ross and Singh have discussed this protocol in their paper [21] where they have

discussed the client-server connection latency when this protocol is used.









Another possible solution for the client is to store all information once the

connection is weak and later perform all needed operations. This is the basis of caching

and this idea is further dealt with in the next chapter.

3.3 Authentication based on DES SSL and Data Transfer using DES.

The previous mechanism that we discussed had a major drawback that the proxy

had to handle all the communication between the PDA-client and the server. This

requires the proxy to be an extremely trusted source. The proxy also had to initiate

handover and this is another source of overhead on the proxy machine.

It has been noticed that in most cases of data communication, it is the

authentication stage that should have maximum security. The initial authentication stage

involves communicating the credentials of each entity present in the network. So as the

identities are to be established, the security should be highest during the transfer of

credentials. No malicious user should be able to access these credentials. These

credentials form the basic framework of security and should never be compromised. The

later stages of communication will tend to have lesser security requirements. This is

because in the later stages of information transfer, credentials are not transferred.

Based on this assumption, we can simplify the previous mechanism so that DES is

used as the cryptography algorithm between PDA-client and server once authentication is

completed using SSL. The assumptions made in this protocol are

* The proxy is assumed to be a partially trusted source as it handles all client
certificates.

* The server can handle both DES mode of authentication and SSL mode.

So once again, communication is divided into three stages, between the client,

proxy and the server.









1. The PDA-Client authenticates itself to the Proxy and they communicate using DES.
Once this authentication is complete the client transfers it's certificates to the
proxy, so that the proxy can authenticate the client to the server based on these
certificates.

2. The Proxy and the Server authenticate each other using an SSL based
authentication protocol. The proxy uses the certificates that were sent across by the
client after the first authentication stage. Since the proxy is a partially trusted
source, trusted by the client, the client can safely transfer the certificates to the
proxy.

3. Now the Proxy can be removed from the picture and the PDA-Client will
communicate with the Server using DES. This is possible only if the server
supports a DES based encryption and decryption protocol. All data transfer
between the client and the server are encrypted and decrypted using DES.




PDA-Client Proxy Server
DES S

SSL / Services
DES requests
from Client

DES



Figure 3-6. Components involved in DES-SSL mode of authentication with proxy
removed after authentication.

The advantage that this protocol provides is that, once the proxy completes it's

authentication with the server using SSL, then communication can continue without using

a proxy. This also eliminates the problem of handover between the proxy systems and

implementing the system will be much easier.

Figure 3-7 depicts the various states involved in the communication between the

client and the proxy. Once again, the connection is verified and the client is

authenticated, the client then transfers its certificates for SSL based communication

between the proxy and the server. If the authentication between the proxy and the server









does not succeed the client is informed of this and the proxy exits. If the authentication

between the proxy and the server is successful, the proxy hands over the client credentials

needed for decrypting DES messages to the server and exits.

The next stage involves the authentication based on Secure Socket Layer between

the proxy and the server. At the end of the first stage the proxy receives the certificates of

the client and can authenticate the client to the server based on these credentials. The

proxy is transparent to the server and it assumes that the authentication is from a client.

The server authenticates the client based on the certificates received. If successful, it

retrieves the DES details such as shared key used for encryption and decryption from the

proxy. These details are received encrypted using the SSL message exchange so cannot

be decrypted by any eavesdropper. The next figure, Figure 3-8, depicts the various states

involved for the server to authenticate the client and for subsequent data transfer. Note

that, towards the end of the authentication phase, the server needs to retrieve the DES key

details of the client from the proxy. In this manner, the server can continue

communicating with the client using DES encryption.

A transaction flow diagram is a flow chart depicting the various requests and

responses that occur among the entities of the system. The diagram illustrates the

successive steps involved during authentication between the client, proxy and the server.

Figure 3-9, provides a transaction flow diagram for the whole system. Note that unlike in

the previous authentication protocol, the server receives all DES details from the proxy

machine and continues to communicate with the client and the proxy can be removed

from the existing system.















Sstablishd I Negoltiaion Phase






I-I
Authentication Pase
S h betic gins




























I
gredingr -
Iverify



,'
-ft




Auth
ALUTRE
TRY




J SUCCE

EXIT




Receive
Client I- _ _- _- _-
Carts
IFiu Afuthentication wih Server



SRe
Server
Auth





Client ranCen
credentials
CEI -to Server







LOGOUT




Figure 3-7. State diagram for the SSL-DES mode of client authentication when viewed at
from the proxy side.












I--I----
SConnectAuthencation Phase
EstaMishied cones








Server greeting,
Check certificate




C'





AUTH R
ETRY










Retrieve DES Data encoded and decoded I
detailsfron usingDES
I -----------






Accept File I Data Transfer
Handle as Client Phase begins
mounts File I
System





Perform File
Operations








LOGOUT





Figure 3-8. State diagram involved in the SSL-DES mode of client authentication when
viewed at from the server side.
















Prot and Client
authenticate each other
based on the shared secret
and key.
Request auth, EDES msag


Proxy EDES (result-Mg)


Certiicate for SSL (private key)


Signaljur privatee key)





Inltliale SS Handshake
Proxy and Server
authenlicate each other as %-.- r -eIls car req'& I leill
first part ofSSL. (rtificate3


orerL. aa4 rr


Aclnowledgermen (success5f[ai)


AppliCation Data is sc-U! and re d
encrypted by P..n and
senL tL Client.

.... DES Acknowledgement (s&icce~stall)




Figure 3-9. Transaction flow diagram for DES -SSL (initial phase) and DES only (final
phase) among all the three components.

The table shown is a comparison of the three protocols based on a number of

parameters such as the difficulty associated with design and implementation of the

protocol, the level of security provided and so on. The client-side response times and

memory constraints comparisons are based on a study conducted at University of









Berkeley comparing SSL and DES client server connection latency times [21]. The

comparison was based on a test run on a Palm Pilot device.

Table 3-1. Table comparing DES and SSL based authentication protocols.
Implementation Computation Possible Memory Client side
complexity complexity security Constraints response
(Client side) breach time
SSL Only Comparatively Maximum Lowest High Slow
RSA easy (> 200K) (> 20 secs)
SSL, DES Difficult Low Proxy Low Fast
with Proxy needs to be (104 K) (6.4 secs)
partially
trusted.
SSL, DES Difficult Low Proxy Low Fast
without needs to be (104 K) (6.4 secs)
Proxy partially
trusted.

3.4 Authentication with Kerberos using DES

Authenticating mobile computing users can use significant amounts of processing

and communications resources-particularly when protocols based on public key

encryption are invoked. These resource requirements can sometimes result in

unacceptable response times for the user.

Kerberos [12, 13, 19] is a trusted third-party authentication protocol designed for

TCP/ IP networks. A Kerberos service, sitting on the network, acts as a trusted arbitrator.

Kerberos provides secure network authentication, allowing a person to access different

machines on the network. Kerberos is based on symmetric key cryptography and the

advantage Kerberos provides is; it shares a different secret key with every entity of the

network and the knowledge of that secret key equals proof of identity. Kerberos provides

both user authentication and encryption key management to guard networks from all

forms of attacks on data in transmission including, interruption, interception,

modification, and fabrication.









There are two types of credentials used in Kerberos: tickets and authenticators. A

ticket is used to pass securely the identity of the client for whom the ticket was issued to

the server. It also contains information that the server can use to ensure that the client

using the ticket is the same as the client to whom the ticket was issued. An authenticator

is an additional credential, presented with the ticket. In the Kerberos model, there are

entities-clients and servers-sitting on the network. Kerberos keeps a database of clients

and their secret keys. Network services that require authentication, as well as clients who

wish to use these services, register their secret key with Kerberos. Because Kerberos

knows everyone's secret key, it can create messages that convince one entity of another

entity's identity. Kerberos also creates temporary secret keys, called session keys, which

are given to a client and a server. A session key is used to encrypt messages between the

two parties, after which it is destroyed.

Figure 3-10, illustrates the Kerberos authentication protocol. The PDA-client

requests for a Ticket-Granting Service (TGS Ticket) from the Kerberos service. The

ticket is sent to the client, encrypted using the client's secret key. To use a particular

service, the client requests a ticket for that service from the Ticket-Granting Server

(TGS). Assuming everything is in order, the TGS sends the ticket back to the client. The

client then presents the ticket to the server along with an authenticator. Again if there's

nothing wrong with the client's credentials, the server lets the client have access to the

service.

Figure 3.11, represents the states associated in the first phase of Kerberos

authentication protocol where the client tries to get a ticket to communicate with the

Ticket Granting Server. The Key Distribution Center (KDC) looks up the client in the









database. If the client is found, then Kerberos generates a session key to be used between

the client and the TGS. This is called the Ticket Granting Ticket or a TGT.



SKerberos TGS ]







3 PA Client 5, Request for Service Server




Figure 3-10. The figure illustrates the various stages involved in Kerberos authentication
for a PDA client.

The Ticket Granting Server encrypts that session key with the client's secret key.

Then it creates a TGT for the client to authenticate itself to the TGS and encrypts that in

the TGS's secret key. The authentication server sends both of these encrypted messages

to the client.

Unlike in the other protocols, the Kerberos authentication process involves more

entities when compares to the previous protocols that we had discussed and data transfer

occurs in the very last stage.

The client now decrypts the first message and retrieves the session key. The secret

key is a one-way hash of the user's password, so a legitimate user will have no trouble in

retrieving password. In the second stage of Kerberos authentication protocol, the client

authenticates with the TGS and tries to get a ticket to communicate with the Server. The

TGS grants tickets for individual servers, so the client needs to send a request to the TGS.













I-I
Nagotlatlon Phase

I I





jAuthenctition Phase I
begins I
- - I


Figure 3-11. State diagram for the first stage i.e. the client communicating with the
Kerberos's Key Distribution Center.



















I- I
Authentication Phase I
begins I
I I


Figure 3-12. State diagram for the second stage i.e. the client communicating with the
Ticket Granting Server.















Kerbemo Authenticatl,, -
Sarver Side


-- --- -- -- I
Authentlcatlon Phase I
Decrpt TGT, begins
check
authentication






7.








~ FAIL AUTH
SUCCESS






EXIT





AoceptFile I _
Handle as Client I
mount Fila I
System I/ Data Transfer
S Piase begins








Allow FIle
OperaUtons









LOGOUT






Figure 3-13. State diagram for the third stage i.e. the client communicating with the File
System Server.









Figure 3-12 explains the states involved in creating a ticket for a service. First, the

client needs an authenticator. The authenticator consists of the client's name, client's

address and a time stamp, encrypted with the session key generated by the Kerberos

authentication server also known as KDC. The request consists of the name of the server,

the TGT received from Kerberos (already encrypted with the TGS's secret key), and the

encrypted authenticator.

The TGS upon receiving the request decrypts the TGT with his secret key. Then he

uses the session key included in the TGT to decrypt the authenticator. Finally, he

compares the information in the authenticator with the information in the ticket, the

network address of the client with the address the request was sent from, and the

timestamp with the current time. If everything matches, he allows the request to proceed.

The TGS responds to a valid request by returning a valid ticket for the client to

present to the server. The ticket contains the name of the client, the network address of

the client, a timestamp, an expiration time for the ticket, and the session key it just

created, all encrypted with the server's secret key, and the name of the server. The TGS

also creates a new session key for the client and the server, encrypted with the session

key shared by the client and the TGS.

The client receives both a valid ticket for use with the server and a new session key

for the client and the server from the TGS. The client once again creates an authenticator,

consisting of the client's name, the client's network address and a timestamp, encrypted

with the session key for the client and the server that was generated by the TGS. Figure

3-13 shows the states involved in the last stage of the authentication protocol where the

server decrypts the client's request. The server verifies the client address and the









timestamp and if everything is found fine, it allows the client to connect and mount the

file system. Later the client is allowed file access and all requested file operations are

performed by the server.

3.5 Authentication with Charon

Though Kerberos is a viable protocol for mobile PDA devices, it is difficult to

implement this protocol on a PDA device, particularly for preserving credentials and for

security guarantees. Moreover Kerberos is particularly problematic to port, besides it's

size and complexity, it relies heavily on Unix idioms and libraries, use of Unix I/O and

memory services, and knowledge of hardware semantics such as byte ordering and word-

size of the host architecture. None of this functionality is easy to implement or mimic in

PDA systems. The lack of free memory is one of the major constraints in implementing

Kerberos for PDA clients. The next protocol that we look at is an implementation of

Kerberos and a proxy, which in fact does most of Kerberos computations.

Charon [22] uses Kerberos to establish a trust relationship between the user and the

proxy. The mechanism for establishing this trust is similar to the method of establishing

trust between the user and the target application server. As a result, there are several more

interactions required in Charon than in the standard Kerberos protocol, where there is no

proxy involved. Charon uses the same algorithm i.e. DES on the PDA as standard

Kerberos.

In Charon, proxies play two important roles: they provide application-level

adaptation for impoverished clients and can optionally function as a protocol gateway and

logical channel multiplexor for non-TCP/IP clients. When a client running Charon

attempts to connect to the proxy, the proxy-side Charon protocol module receives the

request and attempts to authenticate the client.
















Clieat
Plica


Alice uses the Charon
proprietary protoco to
obtaln a TGT from the KDC;
the proxy uses standard
Kerberos v4 to obtain the
TGT and pass it back to
Alice. The proxy cannot
uses the TGT.



Alice obtains a ticket and
session key for use with the
proxy in estatlising a trust
relatllsEIlp and potentially
a secure link.





The client requests a ticket
for an application server
through the proxy








The client authenticates to
the application server.


Proxy


Ch-AS-REQ


Chl. AS-REP



Ch TGS-REQ


Ch: TGS-REP



Ch. KRB-CRED



Ch: TGS-REQ



TGS-REP


KL'c


AS-REQ


S AS-REP



TGS-REQ


TGS-REP







TGS-REQ



TGS-REP


Ch: AP-REQ AP-REQ
_______________, /


AP-REP


Figure 3-14. Transaction flow in Charon.


Charon interaction consists of two distinct phases: the handshake phase, in which


the client authenticates itself to the proxy via Kerberos, and establishes a secure channel


with it, and the service access phase, in which the proxy accesses Kerberized services on


the client's behalf.


Handshaking is accomplished by treating the proxy as a Kerberized service. The


handshake consists of two steps. During the first step, the client uses the proxy as an


intelligent router to obtain a TGT, which will then be managed by the proxy. During the


second step, the client obtains a proxy service ticket from the TGS; during this step the


Snrver
Bob









proxy functions not only as a router but also as a Kerberized service, for which the TGS

can create a session key to be securely disclosed via the Kerberos messages. After this

two-step handshake phase has succeeded, the session key can be used to secure the

channel between the client and the proxy, and therefore all logical connections

multiplexed onto it. The client, now in the service access phase can then request indirect

access to other Kerberized services.

An important property of Charon is that the proxy-side Charon module never gains

possession of enough information necessary to independently negotiate for services on

behalf of the client.

3.6 Authentication with Kerberos using Public Key Encryption

Network authentication protocols regularly employ public key cryptography to

securely identify clients to servers and establish trust relationships. In a mobile

computing context, the processing and communications resources required to perform

public key operations and transmit large messages may result in unacceptable

performance characteristics and extended user authentication times. The authentication

mechanisms that we have discussed before compensated for the resource limitations of

mobile computing platforms by off-loading processing to a proxy server. On the flip

side, proxies pose an additional layer of complexity, network delay and opportunity for

security breach. With the rapid increases in computing capacity on PDA's, it might be

possible to run public-key algorithms on these devices in the near future. This section

analyzes a public-key based variant of the Kerberos authentication protocol [23].

The advantages provided by public key cryptography include simplified key

management and the ability to leverage existing and developing public key certification

infrastructures.

















Initial TGT request to KDCG
Alice generates a session AS-REQ
key, encrypts it with KDC's
public key, and signs It wlth
her public key.
AS-REP



TGS-REQ
Server ticket request: Alice
can now trust the KDC, so
5he requests a ticket to the
application using smret key TGS-REP
encryption.




AP- EQ


The client authaentcates to
the application server. AP- EP





Figure 3-15. Transaction flow between among the entities involved in Kerberos-public
key encryption.

A transaction using public-key encryption can be divided into the following stages:

1. The mobile client sends an initial Ticket Granting Request (TGT) to the Kerberos
server. The session key is generated by the client, which is encrypted using the
Kerberos server's public key and later signed by the mobile client's private key just
as in Public Key Encryption.

2. The mobile client then requests for a session key for communicating with the
application server.

3. The client and server authenticate each other using the standard Kerberos key
exchange.









The transaction flow is very similar to the one with Kerberos using DES and the

difference is that here instead of symmetric key encryption we are using public key

encryption.

3.7 Data Transfer Phase

Towards the end of the authentication phase, the client's identity is known and

verified. The server then assigns the client to a group based on this identity. The client

can access all the files that are accessible by members of this group. This method is used

to avoid Access Control Lists and Group Permissions that will be discussed in the next

chapter.

Once all the devices involved in data transfer are authenticated, the stage is set for

transfer of data between the entities involved in communication over the wireless

network. This stage might also be in an encrypted form depending on the sensitivity of

the data being transferred. In most cases the data involved can be encrypted and

decrypted using the simple DES algorithm. Most PDA devices do have the computing

power necessary for encrypting and decrypting DES messages. So in such situations the

client and the server can communicate directly without the use of the proxy device.

In some cases, SSL or public key encryption might be needed again depending on

the sensitivity of the data being transferred. In such situations, the proxy might continue

to be used until the end of data transfer stage.














CHAPTER 4
FILE SHARING PROTOCOL

The file sharing protocol for the Ubiquitous File System is a stateful protocol. This

protocol is meant to suit clients running on either wired or wireless networks. It features a

simple design for easy recovery, is independent of transport protocols, operating systems

and the underlying filesystem. This file system has been developed with low power

portable computation devices in mind, without compromising on file sharing

functionality issues so that the file system can also be used with high power computation

devices.

Some of the features unique to this file system protocol are its dual mode of

caching, locking only for writer processes and that it provides for cross-platform

interoperability. The protocol features a filesystem model that provides a useful, common

set of features that does not unduly favor one filesystem or operating system over

another. An attempt has been made to understand the commercially successful file

systems of today, such as NFS [24, 25, 26] and CIFS [27] and create a file system that

has the better features of these proven file systems. NFS is used prominently on UNIX

based machines while CIFS is based on Windows based machines. The motivation to

design the ubiquitous file system protocol from NFS and CIFS is that, collectively these

file systems represent a broad spectrum of file system users.

The remainder of this chapter is a discussion on file handles and the issues that

must be considered while developing this file system. File system operations and features

such as caching and locking are explained in the subsequent sections.









4.1 File Handle

The file handle in this protocol is a per server-unique identifier for a file system

object. It contains all the information that is required by the server to distinguish an

individual file from all other files.

The client does not need to understand the contents of the file handle and the file

handle is opaque to the client. Therefore, it is essential that the server translate the file

handle to an internal representation of the file system object. The client might store the

file handle for a later request to the server but there is no need for the client to discover

the contents of the file handle. The client can also compare two file handles from the

server for equality by using a byte-to-byte comparison.

The client needs a file handle to initiate communication with the server. The

MOUNT protocol can be used to translate a string based file system path name to a file

handle, which can then be used by the client. Thus, the client gets its first file handle by

mounting a file system residing on the server.

4.2 File System Operations

This section provides a detailed description of all the operations that are supported

by this file system protocol. The operations are motivated by NFS [25] and CIFS [27].

4.2.1 Procedure 1: NULL No Operation

This operation performs the standard NULL procedure. It does not take any

arguments and has no functionality associated with it. It is sometimes, used to measure

the overhead of processing a service request. The server must ensure that no unnecessary

work is done in servicing this procedure.









4.2.2 Procedure 2: CHGGRP Change group association

This operation permits the user to change her present group association. Members

of a group are allowed access to certain file objects on the server. The server decides this

and the user is then allowed to change her group. Once this command is executed, this

requires the user to re-authenticate her credentials, and she can change her group if the

authentication succeeds.

4.2.3 Procedure 3: CLOSE Close the file

This operation closes the file and the client should return any locks held by the file

back to the server. The server may either force all locks to be removed or it may not

allow close unless all locks are returned to the system. The server must return an error if

any of the following conditions are found:

* File object locks are open after the file is closed.
* File handle for file to be closed is inconsistent or bad.
* File has been moved and cannot be retrieved.

4.2.4 Procedure 4: COMMIT Commit cached data

This operation commits the cached data to a stable storage medium for the file

specified by the current file handle. The server notifies the client if a successful commit

has occurred or if a failure takes place.

4.2.5 Procedure 5: CREATE Create a file object

This operation creates a regular file or a directory or a symbolic link, depending on

the argument passed. The create operation requires the location i.e. the path name and the

name of the file to create a new object. It returns the file handle if the operation is

successful, else it returns an error.









4.2.6 Procedure 6: DELEGPURGE Purge all delegations for a client

Delegation allows a client to locally service operations on files. The server then

delegates certain responsibilities to the client. This feature is very useful in weakly

connected networks. This concept is dealt with in the succeeding sections.

DELEGPURGE operation purges all of the delegations awaiting recovery for a given

client. This is useful for clients, which do not commit delegation information to stable

storage. This is also used to indicate that the server need not delay conflicting requests

from other clients while it is awaiting recovery of delegation information.

4.2.7 Procedure 7: DELEGRETURN Return Delegation

Returns the delegation back to the server for the given client id and file handle.

Delegations may be returned either on a recall by the server or voluntarily by the client

when it has completed modifying the delegated object.

4.2.8 Procedure 8: GETATTR Get File Attributes

The following file attributes are supported by this file system protocol.

* Type: The type of the file object whether file, directory, symlink etc.

* Change: A value created by the server that the client can use to determine if file
data,directory contents or attributes of the object have been modified.

* Size: The size of the object on bytes.

* Fsid: Unique filesystem identifier for the filesystem holding this object.

* Lease time: Duration of the leases at server in seconds.

* Filehandle: The file handle of this object for various file operations.

The GETATTR operation will obtain attributes for the filesystem object specified

by the current filehandle. The client sets a bit in the bitmap argument for each attribute

value that it would like the server to return. The server returns an attribute bitmap that









indicates the attribute values for which it was able to return, followed by the attribute

values ordered lowest attribute number first.

The server must return a value for each attribute that the client requests if the

attribute is supported by the server. If the server does not support an attribute or cannot

approximate a useful value then it must not return the attribute value and must not set the

attribute bit in the result bitmap. The server must return an error if it supports an attribute

but cannot obtain its value. In that case no attribute values will be returned.

4.2.9 Procedure 9: GETFH Return current file handle

This procedure returns the current file handle for the required object.

4.2.10 Procedure 10: LOCK- Create a lock

This procedure can be used to create a write LOCK on a file object if the server-

side file system supports this feature. If a lock cannot be created then an error message is

returned. A LOCK request can be placed on a file or on a directory but not on a symlink.

4.2.11 Procedure 11: LOCKT Test for a lock

This operation checks if an object is attached to a lock. Appropriate messages are

returned based on the result of the operation.

4.2.12 Procedure 12: LOCKU Unlock the object

This operation unlocks the lock specified on an object. The file is specified as in a

LOCK operation. Appropriate messages are returned based on the result of the operation.

4.2.13 Procedure 13: LOOKUP Lookup filename

This operation looks up or finds a filesystem object (either a directory, a file or a

symlink) using the directory specified by the current filehandle. On return this operations

returns the filehandle of the object that it searched. If the search is unsuccessful, an









appropriate error message is returned. The pathname can be specified in the lookup,

depending on the file system, the field separator can be set up

4.2.14 Procedure 14: PUTFH Set Current File Handle

This operation replaces the current filehandle with the filehandle provided as an

argument.

4.2.15 Procedure 15: READ Read from a file

The READ operation reads data from the regular file identified by the current

filehandle.

The client provides an offset of where the READ is to start and a count of how

many bytes are to be read. An offset of 0 (zero) means to read data starting at the

beginning of the file. If offset is greater than or equal to the size of the file then an error

message is displayed.

4.2.16 Procedure 16: READDIR Read contents of a directory

The READDIR operation retrieves a variable number of entries from a filesystem

directory and returns client requested attributes for each entry

4.2.17 Procedure 17: READLINK Read a symbolic link

READLINK reads the data associated with a symbolic link.

4.2.18 Procedure 18: REMOVE Remove a filesystem object

The REMOVE operation removes (deletes) a directory entry named by filename

from the directory corresponding to the current filehandle. If the entry in the directory

was the last reference to the corresponding filesystem object, the object may be

destroyed.









4.2.19 Procedure 19: RENAME Rename a filesystem object

The RENAME operation renames the object identified by oldname in the source

directory corresponding to the saved filehandle, as set by the SAVEFH operation, to

newname in the target directory corresponding to the current filehandle. The operation is

required to be atomic to the client. Source and target directories must reside on the same

filesystem on the server. On success, the current filehandle will continue to be the target

directory.

4.2.20 Procedure 20: RENEW Renew a lease

The RENEW operation is used by the client to renew leases that it currently holds

at a server. In processing the RENEW request, the server renews all leases associated

with the client.

4.2.21 Procedure 21: RESTOREFH Restore a saved filehandle

This operation is used to set the value of the current filehandle to the value in the

saved filehandle. If there is no such filehandle an appropriate error message is displayed.

4.2.22 Procedure 22: SAVEFH Save current filehandle

This operation is used to save the current filehandle. It overwrites the previous

value of saved filehandle. The SAVEFH operation is used along with the RENAME

operation.

4.2.23 Procedure 23: SETATTR- Set attributes

The SETATTR operation changes one or more of the attributes of a filesystem

object. The new attributes are specified with a bitmap and the attributes that follow the

bitmap in bit order.









4.2.24 Procedure 24: WRITE Write to a file

This operation writes data to a regular file. The current file handle points to the

target file. The write operation begins from the offset field that is passed along with this

operation.

4.2.25 Procedure 25: RELEASELOCK Release lock associated with a file

This operation is used to notify the server that the lock owner is no longer in use by

the client. This allows the server to release cached state related to the specified lock

owner. If file locks, associated with the lock owner, are held at the server, appropriate

error messages are returned.

4.3 Caching

Caching [28, 29, 30] involves keeping frequently used data "close" to where it is

needed, or preloading data in anticipation of future operations. In our file protocol,

caching refers to storing data from a file on the client and the data can be read from the

local memory instead of the remote server. In some cases, the client will not be able to

load the complete file owing to lack of memory, then the client can cache the required

portion of the file in its local memory. The advantage that this provides is that the client

can load and update large files even if it lacks the necessary memory.

The client can be connected to the server using either a weak connection (one that

has a low data transfer speed and is not stable) or a strong connection (one that supports

fast data transfers and is rarely disconnected). Depending on the type of connection

present between the client and the server, the server can decide whether or not caching is

necessary.

Consider a scenario, in which the client needs to update a file on the server

frequently. If the connection is weak, the client can spend a considerable amount of time









in transferring data over the network, for every modification made to the file. Under such

circumstances it is essential that the client cache the file locally and make all the changes

to the local copy. Once all modifications are completed or if the server sends a call back

request, the existing copy of the file on the server is updated by the client's copy and the

local copy on the client is destroyed.

If the connection is stable and supports a high data transfer rate, then the server

may not allow the client to make a local copy or to cache a file. In this case, the client

must make all the necessary modifications directly to the file present on the server.

4.3.1 Client-side Caching

Client-side caching [28] works by keeping a copy of the file object in local storage.

Client-side caching of data, of file attributes, and of file names is essential to providing

good performance because of weak connectivity and low computing power associated

with the client.

Most file system protocols require the client to repeat their file data cache

validation requests at the time the file is opened. This behavior can have serious

performance drawbacks. A common case is one in which a file is accessed only by a

single client. Therefore, sharing of this file is infrequent.

In this case, repeated reference to the server to find that no conflicts exist is

expensive. A better option with regards to performance is to allow a client that repeatedly

opens a file to do so without reference to the server. This is performed until potentially

conflicting operations from another client actually occur.

A similar situation arises in connection with file locking. Sending file lock and

unlock requests to the server as well as the read and write requests necessary to make

data caching consistent with the locking semantics can severely limit performance. When









locking is used to provide protection against infrequent conflicts, a large penalty is

incurred. This penalty may discourage the use of file locking by applications.

Thus to improve performance, the file system protocol introduces a delegation [25]

mechanism which allows many decisions normally made by the server to be made locally

by clients. This mechanism provides efficient support of the common cases where

sharing is infrequent or where sharing is read-only. The next section provides a detailed

discussion of the delegation mechanism.

4.3.2 Caching of File Data

For file data, the client checks its cache validity when the file is opened. A query is

sent to the server to determine if the file has been changed. Based on this information,

the client determines if the data cache for the file should kept or released. Also, when the

file is closed, any modified data is written to the server.

When applications share access to a set of files, they need to be implemented so as

to take account of the possibility of conflicting access by another application. This is true

whether the applications in question execute on different clients or reside on the same

client.

File locking, which is discussed in the next section, is a facility available in this

protocol that allows applications to coordinate access by providing mutual exclusion

facilities. The protocol's data caching must be implemented such that it does not

invalidate the assumptions that those using these facilities depend upon.

4.3.3 Caching Operations

The operations involved in caching of data are described below:

First, cached data present on a client must be revalidated after doing an OPEN.

Revalidating means that the client fetches the change attribute from the server, compares









it with the cached change attribute, and if different, declares the cached data (as well as

the cached attributes) as invalid. This is to ensure that the data for the OPENed file is still

correctly reflected in the client's cache.

Second, modified data must be flushed to the server before closing a file OPENed

for write. If the data is not flushed at CLOSE, the revalidation done after client OPENs as

file is unable to achieve its purpose. The other aspect to flushing the data before close is

that the data must be committed to stable storage, at the server, before the CLOSE

operation is requested by the client. In the case of a server reboot or restart and a

CLOSEd file, it may not be possible to retransmit the data to be written to the file.

4.3.4 Organizing Cached Data

When clients cache data, the file data needs to be organized according to the

filesystem object to which the data belongs. For this file system, for the purpose of

caching a distinct filehandle represents a distinct filesystem object. So for every object

cached, there will exist a filehandle for that object. The client then has the choice to

organize and maintain the data cache on this basis.

4.3.5 Delegation and Callbacks

It is possible for the server to delegate certain responsibilities to the client. The

essence of a delegation is that it allows the client to locally service operations such as

OPEN, CLOSE, LOCK, READ, and WRITE without immediate interaction with the

server.

4.3.5.1 Delegation

When the server grants a delegation for a file to a client, the client is guaranteed

certain semantics with respect to the sharing of that file with other clients. At OPEN, the

server may provide the client either a read or write delegation for the file. If the client is









granted a read delegation, it is assured that no other client has the ability to write to the

file for the duration of the delegation. If the client is granted a write delegation, the client

is assured that no other client has read or write access to the file.

Because the granting of a delegation is always conditional upon the absence of

conflicting access, clients must not assume that a delegation will be granted and they

must always be prepared for OPENs to be processed without any delegations being

granted.

Once granted, a delegation behaves in most ways like a lock. There is an associated

lease that is subject to renewal together with all of the other leases held by that client.

Unlike locks, an operation by a second client to a delegated file will cause the

server to recall a delegation through a callback.

4.3.5.2 Callbacks

Only the server can recall delegations. If another client requests access to the file in

such a way that the access conflicts with the granted delegation, the server is able to

notify the initial client and recall the delegation. With the use of a callback, from server

to client, a server recalls delegated responsibilities when another client engages in sharing

of a delegated file.

On recall, the client holding the delegation must flush modified state (such as

modified data) to the server and return the delegation. The conflicting request will not

receive a response until the recall is complete. The recall is considered complete when

the client returns the delegation or the server times out on the recall and revokes the

delegation as a result of the timeout. Following the resolution of the recall, the server has

the information necessary to grant or deny the second client's request.









At the time the client receives a delegation recall, it may have substantial state that

needs to be flushed to the server.

A client failure or a network partition can result in failure to respond to a recall

callback. In this case, the server will revoke the delegation, which in turn will render

useless any modified state still on the client.

4.3.6 Caching Conclusion

Some of the other operations such as READDIR or LOOKUP can also be cached,

depending on the amount of memory available on the client. Though caching improves

on data access time, a compromise should be found between data cached and the amount

of memory available on the client.

4.4 File Locking

File locking [31, 32] is the act of ensuring that when a user accesses a file, usually

via a software application, no other user can change the file until the previous user has

completed examining it. So if a file has to be modified, then file locking ensures that no

one else can examine or modify the file until the lock has been released. File locking

allows one process to gain exclusive access to a file or part of a file and forces other

processes requiring access to the file to wait for the lock to be released.

Locking can be implemented in either of the two ways proposed here. Locking can

pose to be a significant overhead and depending on the file system usage, it can either be

avoided or implemented. In file systems such as Network File System [26], NFS v3,

locking is almost non-existent. Multiple readers are allowed to read a file and when

multiple writers write into a file, the last writer is the one that succeeds. The rest of the

writers are allowed to write but the modifications made by them are not visible on the

file. This might seem like a very risky situation, but in most non-critical cases of file









system use, this method succeeds. The advantage of this method is that it poses lesser

design implications and is much easier to implement than locking as implemented in

CIFS.

In the Common Internet File System (CIFS) [27], locking is necessary for any

unsafe operation. A safe operation is defined as only one client is writing to a file or

many clients are accessing a file as long as all are just reading. If many clients are writing

a file simultaneously, then none are safe, and all file operations have to go to the server.

The protocol notifies all clients accessing a file of changes in the number and access

mode of clients accessing the file, so that they can use the most optimized safe access

method. The implementation in CIFS causes a lot more delays and waits but all users can

be assured that all their modifications or updates are made to the file.

In Ubiquitous File System Protocol, multiple readers are allowed to read from a file

so long as no writer has access to the file. If a writer requests file access, then there

should be no other conflicting writes on this file object. If another writer is holding a lock

then this writer request will need to be queued, as explained further on in this section. If

multiple reads are taking place and if a writer requests a lock, then this is allowed to

proceed and the writer is given a lock. This implies that the readers could be left with an

old copy of the file object and the user must take necessary steps to ensure consistency of

the file object being accessed. To summarize, this file system protocol has only a write

lock and does not have a read lock associated with a file object.

Integrating file locking into this protocol causes the protocol to be stateful. Stateful

services are those that require the server to maintain client information from one









transaction to the next i.e. maintain the state. As the protocol is stateful, care must be

taken to handle the following conditions.

* Appropriate division of state management responsibilities between the client and
server.

* Mechanism should be provided for detecting an inconsistency in state between the
client and the server.

* In case of either a client or a server crash, appropriate recovery mechanisms should
be provided. There are two specific state-related problems involved in providing
the locking in a network context.

* If the client has crashed, the lock can be held forever by the server.

* If the server has crashed, it loses its state (including all its lock information) when
it recovers.

File locking involves a request from the client for a lock on a file and later on
both the client and the server need to communicate between themselves, detecting if any
inconsistencies arise.
So the communication phase can be divided into two different types.

4.4.1 Lock Request

For each LOCK request, the client must identify itself to the server. This is done in

such a way so as to allow for correct lock identification and crash recovery.

Establishment of identification by a new incarnation of the client also has the effect of

immediately breaking any leased state that a previous incarnation of the client might have

had on the server, as opposed to forcing the new client incarnation to wait for the leases

to expire.

The client request will need two fields, the verifier and a field to identify the client.

The verifier is a random value reset by the client every time it reboots. A suggested value

for the verifier is appending the date and time of reboot with the IP address of the client.

The client on every initialization changes the verifier, the server can compare a new









verifier to the verifier associated with the currently held locks and determine that they do

not match. So if the server has previously recorded the client and if the value in verifier

has changed, then all previously recorded states can be removed.

The identification string has to be unique and specific for each client. A possible

identifier is the home address field used in Mobile IP [33]. Since we assume that our file

system runs on devices having Mobile IP addresses, the home address can be set as the

unique identification string. Since the care-of address used in Mobile IP changes as the

device changes it's access point it is not possible to use the care-of address field.

Another possible identification string can be based on the serial number available

on the device. It is possible to perform a one-way function on this serial number and the

string generated can be used as the identification string. An advantage of using the one-

way function is that the serial number will be protected from public access and privacy is

maintained.

A request for a lock on a file object can be handled in three different ways. This

section provides an overview of possible locking mechanisms with state diagrams for

each model.

4.4.1.1 Indefinite Wait

Figure 4-1 illustrates the scenario where a client has to wait indefinitely to receive a

lock for a file object. The client sends a request to the server for lock on a file object. The

server then verifies if a lock can be provided or not. If a lock is not available, the client is

made to wait until the lock is free. Once the lock is free, the server provides the client

with the lock. The advantage of this approach is that the client can be sure of receiving a

lock once it requests for a lock to a file object. On the flip side the client is made to wait

for an indefinite duration of time.










































Figure 4-1. Scenario where the client has to wait indefinitely until another client releases
the lock Indefinite wait.

4.4.1.2 No Wait

Figure 4-2 depicts the scenario where a client makes a request for a lock on a file

object, and the server verifies if the lock can be given or not. If the lock is free, then it is

provided to the client. Unlike in the previous case, if the lock is not free and is being used

by another client, then the client is informed that that lock is not free. The client will need

to try again. An advantage of this approach is that it is easy to implement this design and









the client has to wait for the least amount of time. On the flip side, the client will need to

make the request at a later stage as the server does not continue holding on to the request.


Figure 4-2. Scenario where the client either receives a lock or has to try again later No
wait.

4.4.1.3 Finite Wait

Figure 4-3 depicts the scenario where the client makes a request for a lock on a file

object. If a lock is free then it is given to the client immediately. If another client is using

the lock, then the client's lock request is added to a queue. The queue size is fixed, so if

the queue is full, then the client is informed of the failure to receive a lock.




















































Figure 4-3. Scenario where the client's request is added to a queue of finite size and has
to wait until another client releases the lock and it's request reached the top of
the queue Finite wait.

In the other case, the client's request is added to the queue. All client requests are

given equal priority and as the queue is a First In First Out (FIFO) object, the client









requests are processed in the same manner as they were added to the queue. This method

has a number of advantages, the primary one being that in the worst case the client has to

wait for a finite amount of time. Moreover the queue size is specified to be large enough

to accommodate a number of client requests, so most client requests terminate only after

receiving the lock. On the flip side this is comparatively difficult to implement as the

queue has to maintained.

In this file system, the aforementioned Finite Wait method of locking is used, the

client can request either a read / write access to a file. A read access proceeds without a

lock if the file does not have a write lock associated with it. If the client requests a write

access to the file, and if the file does not have a write lock associated with it, the client is

given the lock. If the client requests a write access to a file object, and if another client is

holding the lock for this file, then this request is added to a lock queue which is processed

in FIFO manner.

4.4.2 Lock Release

The lock associated with an object can be released either based on a client request

or by the server if it discovers an inactive client. The client can request for the release of

lock associated with the file. The server then releases the lock after verifying the identity

of the client. The server might also need to periodically check for the activity of the client

and if inactive will need to release the lock. A request is sent to the client mentioning that

the lock will soon be released. The server then waits for a response from the client for a

previously specified duration of time. If the client does not respond then the lock is

released.

When the lock is released, then the lock queue is scanned. If any other client has

placed a request for this file object then it is given the lock to this file object. Once again









as the implementation is based on a queue, the first request is given priority and is

processed before the other requests.

4.4.3 Crash Recovery

The important requirement in crash recovery is that both the client and the server

know when the other has failed. Additionally, it is required that a client sees a consistent

view of data across server restarts or reboots. All READ and WRITE operations that

may have been queued within the client or network buffers must wait until the client has

successfully recovered the locks protecting the READ and WRITE operations.

4.4.3.1 Client

If the client crashes, then on reboot and initialization, the value in the verifier field

is modified. A request is made to the server for a lock. The server then compares the old

verifier value with the new one for the particular client id and determines that the client

has crashed and restarted. The old lock is then released and a new one is provided to the

client once again. The lock queue is also scanned and any lock requests stored with the

previous verifier is removed. The client will need to place new requests for any of the file

objects it needs to write.

4.4.3.2 Server

If the server loses locking state (usually as a result of a restart or reboot), it must

allow clients time to discover this fact and reestablish the lost locking state. The client

must be able to reestablish the locking state without having the server deny valid requests

because the server has granted conflicting access to another client. Likewise, if there is

the possibility that clients have not yet reestablished their locking state for a file, the

server must disallow read and write operations for that file.









4.5 Group Permissions

In this protocol the client is authenticated by the server before the data transfer

phase begins. As was explained in the last chapter, once the identity of the client is

known the server assigns the client to a predefined group. This group is given access to

some or all files on the server. The client is thus allowed to read / write to all the files in

this region.

Sometimes the client might need to change the group that it is presently associated

with. This can be performed by the operation CHGGRP, as defined in the File Operations

section. This allows the user to change her group association. The user can be assigned to

only one group at a time and will need to change the group if it needs access to files other

than those accessible to this group.

The advantage of this approach is that one can do away with Access Control Lists

[34] (ACL's). This allows a larger degree of freedom in implementation and does not

pose to be a major constraint in file access because the user can still change a group or

file associations. Moreover as transfer occurs over wireless networks and as

computational power is limited on the mobile clients, from a data transfer point of view,

one can do with minimal file or directory access restrictions.














CHAPTER 5
CONCLUSIONS AND FUTURE WORK

5.1 Conclusions

This thesis presents a new file system protocol that can be used by the entire gamut

of connected computing devices for file sharing, be it wired or wireless. This protocol

features support for low power portable computation devices without any compromise on

file sharing functionality issues. Needless to say, it also supports high power computation

devices.

On wireless networks, security has always been a matter of major concern. Owing

to this the trade-off between security and computation complexity has become the issue,

which requires much deliberation. The authentication stage of this protocol is the result of

an in-depth analysis into the various other protocols available and their associated

complexities. The implementation of the authentication stage using a partially trusted

proxy enables the low power computation devices to use any of the best suitable

authentication protocols.

The file sharing protocol presented in Chapter 4 is an amalgam of features taken

from various commercially successful file systems. This file system has been optimized

for low power computation devices without any compromise on file sharing functionality

issues. Some of the file system features such as caching and locking break new grounds.

The server allows for client-side caching of a file object depending on a weak connection

or a strong connection. The file system also allows multiple clients to read from a file,

whereas only one writer can perform writing to a file object. Once authentication is









successful, each client is provided certain access permissions depending on the group

affinity. Unlike in the traditional file system group policies, where a client can change a

group affinity and thus have a different set of file access permissions, in the ubiquitous

file system, access permissions are decided by the server during authentication. The client

can change its access permissions by requesting the server for a change of group affinity.

5.2 Future Work

With the advent of wireless networks, the requirements of information security

have undergone a sea change. The file system that is discussed in this thesis has

attempted to provide adequate security for most day-to-day applications. Hardware

cryptographic mechanisms such as Fortezza Crypto Card, formerly called Tessera [15]

can be interfaced with the existing file system design and these algorithms may provide

better user response times with possibly an improved level of security. Some of the

algorithms mentioned require a partially trusted proxy; this can pose as a weak link in the

system. The details stored in the proxy need to be deleted after every transaction, and

mechanisms can be found to improve upon this system.

The design of a file system is a complex affair especially with distributed file

systems that allow weakly connected operations. The features that can be added to such a

file system are immense and most file systems are tailored to suit the operation

environment. The next stage is to provide an implementation of this file system design. In

an attempt to reduce the burden on low power computational devices, just the required

file system operations have been added to this protocol. Features such as group

permissions and access control lists can also be added to this file system protocol.

Compound file operations can be created which can perform a pre-defined set of

operations as requested by the client. Moreover in an attempt to create a generic file






64


system protocol, file locking for write operations has been added as a feature to this

protocol. Depending on the file system usage, one can do away with write locks and this

would vastly improve file system performance. Journaling [35] is a useful feature that can

be added to this file system and would provide a lot more stability to this file system.

Again techniques, which exploit and adapt to the communication opportunities at hand

are needed. Such techniques may include compressed network transmission, partial file

transfer and caching at intermediate intervals.














APPENDIX A
FILE SYSTEM OPERATIONS

This appendix lists the various possible file operations that are discussed in this file

system protocol. All the operations mentioned must be present in an implementation of

this file system. A detailed discussion of these operations can be found in Chapter 4.

Operations with Arguments

Procedure 1: NULL No Operation

This operation does not take any arguments.

Procedure 2: CHGGRP Change Group Association

This operation takes the client identifier as its argument.

Procedure 3: CLOSE Close the File

This operation takes the file handle as its argument.

Procedure 4: COMMIT Commit Cached Data

This operation requires the offset as the argument passed. The offset specifies the

position within the file where the flush is to begin. An offset value of 0 (zero) means to

flush data starting at the beginning of the file. The count specifies the number of bytes of

data to flush. If count is 0 (zero), a flush from offset to the end of the file is done.

Procedure 5: CREATE Create a File Object

This operation takes three arguments, file object type, file object name and

attributes of the file object.

Procedure 6: DELEGPURGE Purge All Delegations for a Client

This operation requires the client identification as its argument.









Procedure 7: DELEGRETURN Return Delegation

This operation takes as argument the file handle.

Procedure 8: GETATTR- Get File Attributes

This operation does not require any arguments.

Procedure 9: GETFH Return Current File Handle

This operation does not require any arguments.

Procedure 10: LOCK Create a Lock

This operation requires two arguments, the client identification and the lock object

requested.

Procedure 11: LOCKT Test for a Lock

This operation requires the name of the file object.

Procedure 12: LOCKU Unlock the Object

This operation requires two arguments, the client identification and the locked

obj ect.

Procedure 13: LOOKUP Lookup Filename

This operation requires the file object name as its argument.

Procedure 14: PUTFH Set Current File Handle

This operation requires the name of the object as its argument.

Procedure 15: READ Read from a File

This operation can take either the file handle of the object or the offset to read from

as part of its arguments.

Procedure 16: READDIR Read Contents of a Directory

This operation requires the name of the directory as its argument.









Procedure 17: READLINK Read a Symbolic Link

This operation requires the name of the symbolic link as its argument.

Procedure 18: RELEASELOCK Release Lock Associated with a File

This operation requires the client identification and the locked object.

Procedure 19: REMOVE Remove a Filesystem Object

This operation requires the file handle of the object being removed.

Procedure 20: RENAME Rename a Filesystem Object

This operation requires the file handle of the object to be renamed.

Procedure 21: RENEW Renew a Lease

This operation requires the time duration for renew, the client identification and the

name of the object to be renewed as its arguments.

Procedure 22: RESTOREFH Restore a Saved Filehandle

This operation requires the file object name as its argument.

Procedure 23: SAVEFH Save Current Filehandle

This operation requires the file object name as its argument.

Procedure 24: SETATTR Set Attributes

This operation requires the attribute set as its arguments. The attributes include type

of the object, change, size, fs identifier, lease duration and file handle.

Procedure 25: WRITE Write to a File

This operation can take either the file handle of the object or the offset to write


from as part of its arguments.















LIST OF REFERENCES


1. Oracle and Telephia, US Wireless Networks are ready for Business, August 2002,
http://www.oracle.com/ip/deploy/ias/mobile/USNetworks R ReadyFINAL.pdf,
accessed: 03/24/2003.

2. Satyanarayanan M, Hot Topics: Mobile Computing, IEEE Computer Sep. 1993,
Vol. 26, No. 9.

3. Satyanarayanan M, Mobile Information Access, IEEE Personal Communications,
Vol. 3, No. 1, February 1996.

4. Satyanarayanan M, Coda: A Highly Available File System for a Distributed
Workstation Environment, Proceedings of the Second IEEE Workshop on
Workstation Operating Systems, Sep 1989, Pacific Grove, CA.

5. J. Kistler and M. Satyanarayanan. Disconnected operation in Coda le system. In
ACM Symposium on Operating systems and Principles, 1992.

6. Noble, B.D. and Satyanarayanan, M., Experience with adaptive mobile applications
in Odyssey, Mobile Networks and Applications, Vol 4, 1999.

7. Mummert, L.B., Ebling, M.R., Satyanarayanan, M., Exploiting Weak Connectivity
for Mobile File Access, Proceedings of the 15th ACM Symposium on Operating
Systems Principles.

8. Martin Fowler, Kendall Scott, UML Distilled: A Brief Guide to the Standard
Object Modeling Language, Reading, Massachusetts, Addison-Wesley Pub Co; 2nd
edition, 1999.

9. Data Encryption Standard (DES), http://www.itl.nist.gov/fipspubs/fip46-2.htm,
accessed: 12/20/2002.

10. Public Key Cryptography, http://grouper.ieee.org/groups/1363/, accessed:
12/20/2002

11. Netscape Communication Corporation, Secure Sockets Layer,
http://wp.netscape.com/security/techbriefs/ssl.html, accessed: 12/20/2002.

12. Tung B, Hur M, Medvinsky A and Wray J, Public Key Cryptography for Initial
Authentication in Kerberos, 2001, http://www.ietf.org/internet-drafts/draft-ietf-cat-
kerberos-pk-init-12.txt, accessed 01/15/2003.









13. Massachusetts Institute of Technology, Kerberos: The Network Authentication
Protocol, 1998, http://web.mit.edu/kerberos/www/, accessed: 01/10/2003.

14. Netscape Communications, Secure Socket Layer, Version 3.0, 1996
http://wp.netscape.com/eng/ssl3/draft302.txt, accessed: 12/20/2002.

15. Fortezza PC Cards, http://www.rsasecurity.com/rsalabs/faq/6-2-6.html, accessed:
03/24/03.

16. W.Diffie and M.E.Hellman, "New directions in cryptography," IEEE Trans.
Inform. Theory, IT-22, 6, 1976, pp.644-654.

17. Rivest, R, L., Shamir, A., Adleman, L, A, A method for obtaining digital signatures
and public-key cryptosystems, communications of the ACM, Vol 21, Nr 2, 1978.

18. I. Chlamtac et al., "Energy conservation in access protocols for mobile computing
and communications," Microprocessors and Microsystems Journal, vol. 1, pp. 20--
32, March 1998.

19. Schneier B, Applied Cryptography, 2nd Edition, New York, N.Y., John Wiley,
1996.

20. Stallings W, Cryptography and Network Security--Principles and Practice, 2nd
Edition, Upper Saddle River, New Jersey, Prentice Hall Inc, 1999.

21. Hill J, Perrin T, Ross S, Singh A, Public Key Authentication on Mobile Devices,
1998, University of California, Berkeley.

22. Fox A and Gribble S D, Security on the Move: Indirect Authentication using
Kerberos, in MOBICOM 96, 1996, Rye, New York.

23. Harbitter A, Menasce D, The Performance of Public-Key Enabled Kerberos
Authentication in Mobile Computing Applications, IEEE Symposium on Security
and Privacy, 2001, Oakland, California.

24. Stern H, Eisler M and Labiaga R, Managing NFS and NIS, 2nd Edition, Sebastopol,
California, O' Reilly & Associates Inc, 2001.

25. Shepler. S, Beame. C, and others, http://www.potaroo.net/ietf/ids/draft-ietf-nfsv4-
rfc3010bis-05.txt, Sun Microsystems, Network File System. Version 4, November
2002.

26. NFS: Network File System--Version 3 Protocol Specification, Mountain View, CA,
Sun Microsystems, February 1994.

27. Common Internet File System Technical Reference, Colorado Springs, Colorado,
Storage Network Industry Association, Revision 1.0, 2002.









28. R. Macklem. Not quite NFS, soft cache consistency for NFS. In USENIX
Association Conference Proceedings, pages 261 278, January 1994.

29. Allison, C., Bramley, M., Serrano J. (1998) "The World Wide Wait: Where Does
the Time Go?", Proceedings Euromicro 98 Conference "Engineering Systems and
Software for the Next Decade, pp 932-940, August, IEEE Press, Vasteras, Sweden.

30. Silberschatz. A, Galvin. P, Operating System Concepts, 5th edition, Singapore, John
Wiley & Sons, Inc, 1999.

31. Chow. R, Johnson. T, Distributed Operating Systems and Algorithms, Reading,
Massachusetts, Addison Wesley Longman Inc, 1997.

32. Marshall K. McKusick, William N. Joy, Samuel J. Leffler, and Robert S. Fabry, "A
Fast File System for UNIX", ACM Transactions on Computer Systems 2, 3
(August 1984), 181-197.

33. Mobile Internet Protocol, http://www.computer.org/internet/v2nl/perkins.htm,
accessed: 03/10/2003.

34. Giampaolo. D., Practical File system Design with the Be File System, San
Francisco, California, Morgan Kaufman, January 1999.

35. IBM Developer Works. and Best, S., How the Journaled File System Performs
Logging, Proceedings of the 4th Annual Linux Showcase and Conference, Atlanta,
GA, October 2000, 163-168.















BIOGRAPHICAL SKETCH

Prasad K P Menon was born in Thrissur, Kerala, India, on April 24th, 1978, and

did most of his schooling in South India. He attended Government Engineering College,

which is affiliated to Calicut University and located in Thrissur, Kerala, where he

received a Bachelor of Technology in computer science and engineering in June 1999.

After graduation he worked at Verifone India, a division of Hewlett Packard, at

Bangalore as a Software Engineer. In August 2001, Prasad entered the graduate program

in the CISE department at the University of Florida where he worked as a teaching

assistant and attended school full time while completing the requirements for a Master of

Science in computer science engineering. His research interests include network security,

file systems and wireless networks.