CS 739 Reviews - Fall 2014

Summary:
SFS is a secure network file system designed for Internet scale. SFS separates key management from the file system security and provides primitives which allow a myriad of key-management techniques to be implemented on top of it. File system security is achieved through self-certifying pathnames. It allows anyone on the Internet to setup a secure file server without requiring a trusted third party.
Problem:
There are different key-management techniques, each with its own advantages and pitfalls which different users might want to use. No available network file system could span the Internet because of problems with key-management when scaling. Given this, how does one design a global file system!
Solution from the paper/Contribution:
The key enabler in SFS is decoupling file system security and key management. SFS introduces self-certifying pathnames – where the path name consists of the location(network address) and public key information of the server. This enables setting up a secure channel between the client and the server. It also means that clients can authenticate servers without requiring any specific key management mechanisms. SFS also provides a global namespace with no distinction such as administrative realms etc. Since key management is no longer a part of the file system and we have a global name space, SFS can scale to Internet size.
The above decoupling means that the users can implement any key management mechanisms on top of SFS and the paper describes a couple of them – using certification authorities and password authentication.
SFS also decouples user authentication from the file system. External programs authenticate the users and communicate with the file system using RPC interfaces. This makes it easy to replace the user authentication mechanism without having to touch the core file system itself.
SFS uses symbolic links to map link human readable file names to the actual SFS pathname. Symbolic links can also be used for bookmarking or forwarding pointers in case the server changes domain name etc.
SFS is run in user space and speaks NFS. This makes it more portable though at the cost of performance.
It provides a single key revocation mechanism which is independent of how the keys are distributed.
My Key takeaway:
Separation of concerns can be great for system design. This is also exemplified in SDNs where the separation of control plane from the datapath has provided so many advantages.

SUMMARY: The authors recognize a fundamental problem of scaling security models across the entire internet, and introduce a global file system that is decoupled from the actual security methods.

PROBLEM: Given that attackers can sniff, modify, and inject traffic, a global file systems needs to provide hard security to ensure correctness. However, security models are not a one-size fits all, and there is no single, centralized security authority for the entire internet. They would like to have a secure, egalitarian system that does not depend on cooperation across administrative boundaries. SFS provides secure filesystem primitives while leaving the actual security implementations to external modules, and do this typically as an overlay onto NFSv3 for easy portability.

CONTRIBUTIONS: They argue that LESS security built into the filesystem itself makes the filesystem more usable, which is a well-known tradeoff. They then show how this works not just in the abstract, but in a practical setting. The major contribution of their system that enables it to work is the incorporation of public-key crypto into the filename itself. A client can authenticate a server just by knowing the name of it, easing key management by reducing the need to exchange information through a separate channel to bootstrap trust. And although not novel to this paper, the "same view of the system from every client" is very practical and is facilitated by the use of symlinks to reduce users' exposure to HostID.

DISCUSSION: One thing I found confusing was how file permissions and access control are done by the server after authenticating the user. In a global filesystem, this doesn't map directly to the UNIX model of owner/group and chmod bits. For example, zmiller@cs.wisc.edu and zmiller@mit.edu are two different users. There would need to be a list of permissions for each principal, and it's not obvious to me how this is managed. Something I learned from the paper is that it is possible to bootstrap a trusted secure channel without exchanging keys or passwords ahead of time. That is maybe weakend by the argument that we are in fact given the hash of the hostname and public key (and so could argue that we did exchange crypto information ahead of time.) However, I thought the idea was clever and makes good security more approachable.

Problem:
- The paper discusses SFS, a global file system with a separate key management mechanism. The paper focuses on security, extensibility (different modules), and portability (remote access).

Summary:
- SFS introduces self-certifying pathnames, which avoids the need for a separate key management by including the public key in the file pathname.
- The many possibilities to manage keys in SFS is 1) creating symbolic links and using the home directory as the password, 2) using certificates, 3) using password authentication, or 4) other existing key infrastructure.
- SFS has a similar performance to NFS.

Contributions:
- The paper first tackles security and a global file system image. Doing so have led the paper to separate the key management, which allows other scheme to bootstrap. This makes way for different modules and cryptographic protocols. Overall, one thing led to another, and this paper solve a lot of problems with a lot of new ideas, each of which can be applied to other file system to improve security.
- The paper explored a lot of key management systems, such as the negation protocol, the authentication protocol, and cryptography. Therefore, this paper takes the extra step of informing the readers of some sample key management mechanism they can use and how well they work. Therefore, if the user have a specific security needs, they can implement their own or mix-and-match, such as two factor authentication.

Confusing:
- I am not sure how the global file system image is generated to include the public keys of each server. I am guessing it is generated when you link your server to the global network. Also, will the user have to type in the public key to access their files? If so, that will be a bit inconvenient. If not, that will be less secure.

Learned:
- File systems can be implemented on a global scale, but requires a lot of security considerations.

This paper presents SFS(Secure File System), which is a secure network file system that can span the Internet. Different key management can be used for it is decoupled from the file system.

Problem:
No secure network file system has ever grown to span the Internet. Existing systems all lack adequate key management for security at a global scale. And given the diversity of the Internet, any particular mechanism a file system employs to manage keys will fail to support many types of use.

Contributions:
(1) Provide a global file system image, so that it looks the same from every client machine.
(2) Provide file system security and powerful primitives from which users can easily build a wide range of key management mechanisms. Key management is decoupled.
(3) Versality achieved by an egalitarian namespace, a powerful set of primitives with which to implement key management, and modularity.
(4) Uses self-certifying pathnames -- file names that inherently specify all information necessary to communicate securely with
remote file servers. The pathname has the form /sfs/Location:HostID, where HostID is a cryptographic hash of that key and the server's location.
(5) Uses revocation and HostID blocking to prevent users from accessing bad self-certifying pathnames.

Confusion:
Not quite sure about how authserv and sfsagent work. It seems to be using public-private key pair to do the authentication. Why a user can have more than one public keys?

Learned:
Decoupling gives system versality. A better design of system is to have modulars and each one can be easily plugged in or have different implementation.

Summary:
Key management in a shared file system with scalability to the size of internet is a long unsolved problem. In this paper, the authors take a stub to build a highle scalable secure file system (SFS) that can span to large size. Separating the key management from file system security is main idea to get the high scalability in the diverse atmosphere like internet. They proposed self-certifying pathnames for access permission. They also build and tested their system on top of NFS 3 and compared the overhead of SFS with the base.

Problem:
Diversity and size of Internet poses a difficult problem in key management which was directly or indirectly used in all previous approaches to build a globally accessible secure file system. Also, these need a centralized authority to provide security.

Contributions:

• Decoupled server authentication mechanism from file system by using self-certifying pathnames.
• Also separated key revokation from key distribution, making key management flexible and easy to recover from compromised keys.
• Servers give permission to users not clients, which allow users to access their files from multiple independenly administered servers.
• self-certifying pathnames is very nice concept, which gives a global namespace as well as secure access control.

Unclear concept:
The system needs a external entity (e.g. Verisgn) to provide server authenticity and stop impersonation. Can there something better than this?

Learning:
Self-certifying pathname can do a lot of nice tricks in distributed access control and authentication.

Summary:

This paper deals with the scalability of secure network file systems to span the entire heterogeneous Internet. The authors have presented SFS, a secure network file system that is designed to span the entire internet. To achieve this authors proposed a novel idea of separating the key management from the file systems security. The intention is to avoid internal key management and allow the sharing of a single global file system indifferent on how the individual keys are managed.

Problem:

The internet is diverse and heterogeneous, hence there are multiple mechanisms for a file system to manage keys. But at that time existing file systems lacked the ability to deal with multiple mechanism to manage keys and hence was very constricted in terms of scalability; as a result there was no existing secure files system that scaled to span the Internet. So a single key management mechanism does not support the heterogeneous nature of the internet and therefore the authors proposed separating the key management from the file system security giving the users the option to choose an available security mechanism.

Contributions:

• Separating of the key management from the file system security enabling the sharing of a global file systems indifferent of how individuals members manage keys.
• Separated key-revocation from general key management
• The concept of "self-certifying" pathnames using public key and location information as a way for authentication.
• Provided an implementation example.
• decentralization of the global namespace.

Learned:

The decoupling of the key management from the file system is a very interesting concept providing a salable solution at a global scale.

Confusion:

The concept of weak key was initially a little bit confusing, I guess it stems from my lack of understanding of general cryptography. Some searching on the internet did alleviate the confusion.

Summary:
The paper talks about designing a secure file system that is independent of a key management policy .

Problem:
The problem the paper is trying to tackle is that , it becomes really hard and unscalable when users from different administrative domains are trying to share files and the system becomes more complicated if the key mechanism policy is tied into the file system .

Contributions:
1.Self Certifying Pathnames to transparently communicate with the SFS server without the explicit need for external information by adding the public key(sha1sum) as part of the file path name
2.Key revocation - Added a message format for a key revocation certificate in case the server 's private key gets compromised
3.Server Key Management - Uses two functions sfskey and authserv as a secure way to download self certifying pathnames using passwords from a remote authserver

Comments

What I learnt : Decoupling the key managament poilicy from the file system allows clients to add varying degree of security according to their needs .

Confused : With multiple key management authservers doesn’t the SFS Server become a bottleneck ?

Summary
The author presents design and implementation of SFS(Secure File System), a distributed file system with "plug n play" security mechanisms.

Problem
In this age where Internet is more of a necessity than a luxury, its becoming more common for users from different administrative domains want to share files. They all have different security needs. So might want to use different authentication protocols that can suit their needs. Within this heterogenous environment global key management is difficult. It is imperative to have some sort of "plug n play" security mechanism for a distributed file system.

Contributions
Self certifying pathname : Clients can authenticate file servers without key management.

Decouple key management from file system. This provides a way to add new user authentication protocols without modifying the file system.

Using symbolic link in place of long path name to hide semantics, provide redirection.

Provides a way for revocation when servers private key is compromised, through key revocation and hostid blocking.

Learning
Modularity is key for scalability in distributed systems.
A best way to design a complicated system is to decouple the service into many layers and focus on each one separately.
Confused
The authors explained that global key management is difficult, but they didnt explain how authserver mange users public keys and map those keys to corresponding credentials.

Flaws
The file operation can still be delayed. This can be still used for DoS attack.

The paper talks about the goals, design and the implementation of a secure file system that is a global file system and is accessible from any client in the world without relying on any special administrative co-ordination.

Contributions :

1. Self certifying path names to authenticate file servers to users. HostIds are a cryptographic hash of the server’s public key.
2. Users need not deal with raw hostIds. Symbolic links are mapped to these self certifying path names for ease of use.
3. Users can create a new file server and then access it from any other client. It is devoid of any administrative overhead.
4. Key negotiation between client and server generate shared session keys that are used to securely encrypt any further messages between the client and server and thus provide the client a secure channel to the server.
5. User authentication is separated from the file system. This allows flexibility in modifying the authentication protocols that are used. The sfsagent on the client signs the authentication request and sends it to the server and the authserver validates it.
6. Revocation Certificates and HostId blocking mechanisms in place to restrict access by client when private key of server is compromised. Clients obtain revocation certificates either from the client agents or the file servers.
7. Portable because it runs in the user space and can be deployed on any operating system that supports NFS.

Learning :
The ideas of implicit authentication of file systems by using self certifying path names that consists of a public key by itself and the key management policies being quite independent of the file system.

Confusing : The user authentication protocol flow was not very clear. The idea of such a system is said to be applicable to span the internet. The experiments do not give us an idea about the extent to which the system can scale though.

Summary:
The paper introduces Secure File System(SFS) which provides a secure, global, non-centralized distributed file system which separates key management from file security via self-certifying pathnames. Built on top of NFS, the paper also compares the performance of two file systems.

Problem:
The problem in hand is developing a secure file system at global scale. Existing systems lack adequate key management for security at global scale leading to either in compromise in security or inconvenience to users.
- No single approach to cater to diverse security needs at a global scale.

Contributions:
1. Separation of Key management from File System Security; introduces the self certifying pathnames which allows servers to authenticate without performing any key management.
2. Decoupling user authentication via modular architecture allows different ways to authenticate users.
3. Great key management architecture: Symbolic links to map human-readable file names to pathnames.
4. Flexibility for co-existence of multiple key management policies on same file system as key management is no more part of the file system.

Learning:
1. Learnt about Secure File system
2. Discussion about performance of NFS and SFS and the points of difference was interesting read
Insight into difference in performance of NFS and SFS due to user-level implementation in SFS and kernel level in NFS other factors like better attribute and access caching in SFS.

Confusion:
I am still confused about password authentication, sharing of weak secret etc to get self-certifying pathnames. I did not fully understand the use of SRP protocol to download self-certifying pathnames.

Summary:
The paper introduces Secure File System(SFS) which provides a secure, global, non-centralized distributed file system which separates key management from file security via self-certifying pathnames. Built on top of NFS, the paper also compares the performance of two file systems.

Problem:
The problem in hand is developing a secure file system at global scale. Existing systems lack adequate key management for security at global scale leading to either in compromise in security or inconvenience to users.
- No single approach to cater to diverse security needs at a global scale.

Contributions:
1. Separation of Key management from File System Security; introduces the self certifying pathnames which allows servers to authenticate without performing any key management.
2. Decoupling user authentication via modular architecture allows different ways to authenticate users.
3. Great key management architecture: Symbolic links to map human-readable file names to pathnames.
4. Flexibility for co-existence of multiple key management policies on same file system as key management is no more part of the file system.

Learning:
1. Learnt about Secure File system
2. Discussion about performance of NFS and SFS and the points of difference was interesting read
Insight into difference in performance of NFS and SFS due to user-level implementation in SFS and kernel level in NFS other factors like better attribute and access caching in SFS.

Confusion:
I am still confused about password authentication, sharing of weak secret etc to get self-certifying pathnames. I did not fully understand the use of SRP protocol to download self-certifying pathnames.

Summary:
Authors present SFS, a secure file system for the global internet. It provides basic file system security and the primitives needed for many diverse key management protocols to be used alongside.

Problem:
- Having a global namespace file system would be nearly impossible with current network file systems because no key management solution fits every user / server owner’s needs.
- Want to avoid central authorities which don’t scale, and simplify file sharing across administrative boundaries with heterogeneous requirements.

Contributions:
- Self-certifying pathnames, which allow clients to authenticate file servers (given that the user trusts the pathname/source of the pathname).
- Built into the file system, this provides a nice general framework for key management: public keys are embedded in files (in the pathname), and files can name public keys (symbolic links).
- Key revocation is separated from key management as well. Management remains flexible while allowing server owner or other trusted clients to alert a client that a server’s private key has been compromised.

Confusing:
The discussion of password authentication as method for pathname download did not make sense to me. In general, the separation of key management made sense, but many of the crypto methods built on top to actually manage pathnames were somewhat foreign.

Learned:
Another use for symbolic links. I liked the utility of self-certifying objects, allowing them to be distributed easily (both pathnames and revocation certificates).

Summary:
SFS is a secure, distributed filesystem and global namespace which is de-coupled from key management policies, which allows great flexibility. SFS runs on top of NFS3, but with improved caching, which helps mitigate the mild performance hit caused by running most of the required processes at the user-level.

Problem:
Current systems couldn’t provide key management policies suitable for reliable and functional security at a global scale. No single key management system could satisfy all possible security needs, so instead, SFS provides a flexible foundation of primitives and modular system to support a broad range of key management schemes. Also, unlike a cumbersome system such as SSL, SHS takes an equitable approach to the global namespace and allows anyone to add a server to the namespace.

Contributions:
1-Self certifying pathnames: a network address and public key information is stored in the filename, which means the key management policy depends on the filename. This provides a flexible, and scalable global namespace. Notably, this separates key management from the filesystem.

2-Key revocation & HostID blocking policies. These policies become necessary due to the egalitarian nature of the global namespace where anyone can add a server.

3-Modular user authentication for flexibility

4-The system performed quite well compared to NFS & only took a modest performance hit

5-They made SFS free software

What I Found Confusing:
Aspects of user authentication were confusing.

What I Learned:
Perhaps there are other aspects of systems that can be separated to add more scalability, reliability, or security. In other words, separating the file system from key management is an example of how de-coupling two intertwined parts of an implementation could potentially enhance a system.

Summary:
This paper propose the first approach to scale the Secure File Server (SFS) to internet scale instead of small network, which should ensure security feature and the versatile key management methods of users. They achieve it by decoupling key management strategy and from the file system, and use self-certificate path names. The authentication is done decentralized: users do it by themselves, not by any servers. They allow users to plug in multiple key management method.

Problem:
To scale existing file systems to the scale of internet, one needs to satisfy:
1. allow versatile key management methods over the system.
2. provide the security feature
3. Efficiency, the authentication should be quick

Contributions:
1. The idea of decoupling user authentication from the file systems. The external programs use well defined Remote procedure call (RPC) to authenticate user in file system.
2. The self-certifying pathnames embed the public keys in the filenames provides SFS the global namespace used for key certification.
3. User authentication is designed as a separate module. It allows users to use different authentication methods.

4. They separate key revocation with key distribution. So single revocation is not correspondant to any distribution used. And SFS use key revocation and HostId blocking to avoid compromised server.

One thing I learnt:
The idea of isolated key management from file systems, enables the versatile requirement in key management, makes the complex things easier. When a systems evolves to be too complicated,
devide it to multiple layers, and design each layer separately.

One thing I found confusing:
when (one time or multiple time) does the user sets up his private key using sfskey protocol?

Summary:
This paper presents a new file system called Secure File System as an extension to NFS, which provides self-certification for mounted remote hosts. It does so in a way to, as the title suggests, separate key management (which is left up to the user to provide) from file system security (which SFS provides). The design is very simple where mounted remote file servers are given paths on the client embedded with the public key to access and authenticate with them.

Problems:
SFS attempts to solve several problems with its novel use of self-certifying pathnames:
• A secure, global file system with pluggable user authentication and key management
• Diverse range of uses for file system from student, to corporate, and even military
• Low overhead verification versus using traditional SSL or IPsec

Contributions:
The central contribution is self-certifying pathnames that create low overhead in verification of remote servers whereby management of public keys is made obviously simple as they are stored in the filename.

Unclear:
In section 2.1.2 on Security the paper claims, “SFS proper provides only file system security”, meaning it doesn’t provide key management. However, a contradictory claim is made later on in the Summary section 6 that. “Because it has a secure, global namespace, SFS constitutes a very effective key management infrastructure.” How can these two statements be mutually true? What constitutes “SFS proper”?
Another confusing claim was that SFS was “designed to span the internet” because it is secure (Section 1 Introduction). I disagree as their method for authentication is inadequate. When keys are negotiated before user authentication as described in section 3.1.1 the system is vulnerable to a Man-in-the-Middle attack via DNS cache poisoning or general spoofing as this paper was written before DNSSec and DNS-based Authentication of Named Entities (DANE) existed. This is the very reason certificate authorities are needed for SSL, but in their section 5.2 on SSL Internet Security they dismiss this architecture as fundamentally weak. Some verified authentication through SSL certificate authorities, although admittedly weak, is better than no initial verified server authentication in SFS.

Learned:
I learned about a decentralized approach to abstracting a secure file system such that there is less network overhead than traditional security methods. Their many applications of their self-certifying pathnames in section 2.4 taught me some novel uses that expand upon their simple design like forward links, key distribution, and certificate authority distribution.

Summary:
This paper introduces a secure network file system designed to span the Internet, SFS as well as numerous key management techniques built on top of SFS.

Problem:
1. Managing encryption keys in large and diverse network is hard. No satisfactory means of key management exists in this kind of network.
2. Most secure systems have particular approaches of key management which limit the their usefulness. A good key management should be independent on its underlying services, which allows arbitrary key management policies coexist on the same file system.

Contributions:
1. Separate the key management from the file system itself. The key technique is using self-certifying pathnames. By self-certifying pathname there is no necessary to perform the key management from servers to users.
2. The self-certifying also
3. No centralized authority to manage the keys.
4. The SFS is built on the top of the NFS so that it provides portability to the users.
5. Decoupling key management from the file system makes the file system support different kinds of key management to coexist on the file system. Modular design also makes it very easy to change authentication protocols.

Confusings:
A high level confusing: what is the use case for a global file system. Is there any specific application that uses it?

Learned:
Design the key management as a separate modular can help to achieve both extensibility and portability. Also, the modular design allows user to choose his own preferred key management protocols or algorithms.

Summary: This paper introduced a secured global file system, SFS. SFS excluded key management from its system, and instead employed self-certifying path names to ensure security.

Problem: To build a file system that could support users from all over world, security is the first concern. However most file systems used complicated key management systems that prevented the system from supporting many types of use.

Contribution:
1. Separating key management from the file system, and using a self-certifying path name for authentication purpose. Every SFS filename is associated with a hash of the server name combined with its public key. When a client is contacting the server, the client will use this hash to check the identity of the server. It eliminates the need of using a trust agent or any complicated key management mechanism.

2. Using user-defined protocols to authenticate the identity of a user. This is the philosophy of solving a problem by leaving the problem to the user.

3. Key revocation mechanism. In case a server's key is compromised, both the server side and the user side could do something to mitigate the impact. The server could notify as many clients as possible of the new public key, and the client can support blacklisting a compromised public key.

Things confused me: The author said that in any existing large scale file systems, either it is inconvenient to use or its security is compromised because of the use of an integrated key management component. I don't understand why such an key management component would hurt usability or security.

Things I learned: How to authenticate a server using a self-certifying pathname.

Summary:
Secure File Server is a secure file system server to the scale of Internet but not limited to a smaller network. They do it by decoupling the key management from the file system through self certifying path names. They authenticate users instead of clients. This decoupling of key management and authentication from the file system enables the users to plug in the desired key management or bootstrap another key management over the current one. They have implemented this SFS on top of NFSV3, thus proving it is portable, versatile and more secure. They claim that the performance drop is due to system calls since the implementation is in user space, but it actually will gain performance since it reduces number of RPCs compared to NFS.

Problem:
Most secure systems such as keebros and SSL limit their functionality by using a particular key management technique which results in increased time, complexity, cost and some times makes the usability of the application degrades by not having a centralized approach. Also key management for the scale of internet is cumbersome and not trivial. Thus, SFS proposes an idea in which, it decouples key management and supports various key management for the file server systems.

Contributions:

1. It provides a mechanism to remove key management from the file system by introducing self-certifying path names, which contains the public key of the server it tries to access. Since the key information associated with the file is specified in the path, this voids the need for separate key management.
2. Self certifying path names also provides a way for all the files to share a single namespace.
3. In addition to this, it proposes a modular design for user authentication, thus reducing the complexity of file systems.
4. Since the key management is decoupled, it allows coexistence of multiple key management techniques.
5. They have implemented various key management techniques with their prototype.

Confusing:
1. During key negotiation, why does the client and server sends key halves instead of whole keys ?

Things learned:
One nice thing about this paper is that, it separates the key management from file system, which in general resembles a lot of systems paper that is separable policy.

Summary:
This paper presents SFS which is a network file system that decouples security key management from the semantics of the file system. This allows SFS to scale in a heterogeneous environment such as the Internet. Clients are allowed to authenticate using different security mechanisms, yet still get the same view of SFS once authenticated.

Problem:
The paper solves a problem faced by other network file systems. Namely network file systems of the time coupled the code to authenticate with the file server into the semantics of the file system. This meant that clients wanting to access the file system had to authenticate using the mechanism expected by the file server. This fails to scale as it requires a homogeneous population of clients. This is not possible at the scale of the Internet or even a large corporation. SFS decoupled this view to allow a diverse population of clients (using different security mechanisms) access to this global file system.

Contributions:
- Separating the security mechanism of client and server from the file system semantics utilized between the client and server to support a heterogeneous environment
- Self certifying pathnames to authenticate file servers
- The use of symbolic links to hide the semantics of the public key file pathnames from users
- System built from a series of modular components that allows modifications to be made easily depending on SFS use cases

Learned:
I was interested to learn about how they managed to decouple key management from the file system. It was cool to learn how they managed to do this and actually implement. It was also a learning opportunity from a more broad perspective in the sense that it was a road map to think critically about other systems and where the line should be drawn for the features some component of the system supports vs. having a given feature by its own component.

Confused:
I was a bit confused by the cryptographic protocols underlying user authentication. Specifically I did not understand the need to use random halves of the client and server public keys to build session keys. Is this simply to allow a client and server to have multiple sessions open simultaneously? If this is the case, would arbitrary strings suffice for these components of the session keys?

Summary:

The paper presents design and implementation of SFS(Secure File System), a distributed file system that separates user authentication from the file system thereby enabling high scalability to fit the Internet. Self-certifying pathnames allow users to directly authenticate file servers and access files from specific location within the file system. The paper also shows that the performance of SFS is at a comparable level with respect to NFS.

Problem:

• Diversity of the Internet cannot be accommodated by a single type of key management at the file system end.
• Existing security models perform badly when there is no centralized management.
• Allowing users to share files across different administrative domains is a very difficult goal to achieve.

SFS addresses these problems by decoupling authentication mechanism from file system storage and by permitting different types of security methods.

Contributions:

• Decoupling server authentication mechanism from file system storage by using self-certifying pathnames which are directly associated with the target files. HostID parameter aids in creation of a secure channel between client and server by using SHA-1 hashing.
• No centralized control of the global namespace.
• The concept of symbolic links provides extensive advantages included server's public key distribution.
• Separation of user authentication aids in supporting different authentication methods.
• Separation of key revocation from distribution helps to avoid the complicated process of tracking individual location of the previously distributed keys. The concept of CRL's is highly prevalent in many secure systems.

Unclear concept:

The user authentication part using sfsagent and authserv was not clear for me. Also I am not clear about multiple forwarding pointers, say a server changed pathname multiple times, would there be a limit to the number of forwarding pointers.

Learning:

The concept of separating security and authentication aspect from file system is something which I learned; also the fact that such a separation is as secure as any single key management technique deployed by many file systems.

Summary:
In this paper authors present SFS, a secure network file system which decouples the key management from the file system security. This enables the SFS to span the diverse internet and support heterogeneous types of key management policies as needed by different users. And the file system itself can be used for building an effective key management infrastructure.

Problem:
On a network as diverse as internet, any one particular type of mechanism for key management will fail to satisfy its diverse set of users each having different set of requirements. Therefore any network file system employing a fixed mechanism for key management will fail to grow at global scale. And any such secure network file system will be face unnecessary administrative burden to manage keys from large number of users. Here authors have tried to build a global file system without mandating any particular key management policy.

Contributions:
-The idea of decoupling the key management part from the file system, can lead to widespread use with users themselves selecting the key management mechanism.
-Allowing multiple key management policies to co-exist on same file system making SFS useful for heterogeneous file sharing requirements.
-Use of self-certifying pathnames that allow SFS to authenticate servers without performing any key management. This embedding of public key in the file name enables the SFS to provide global namespace which can used for key certification.
-Modular architecture to decouple user authentication from the file system. External programs communicate to file system through a well defined RPC to authenticate users.
-Automatic transparent mounting of remote file system upon access.
-Hiding of un-accessed path names in /sfs, thus protecting users from accessing unintended host id.

Confusing:
I am confused about the revocation part. It mentions that SFS provides mechanisms "key revocation" and "HostID blocking" to prevent user from accessing bad self certifying names. But it also says that "HostId blocking" does not originates from the owner and can happen against owners will. So how do individual users decide when to honor the blocked hostIds.

Learned:
Sometimes decoupling of related components in the system can make it more flexible and lead to its wider adoption. In any secure network file system, security is the key aspect with key management its one of the core component, but handling the key management separately leads to improved flexibility, without any degradation in security aspect of the system.

Summary:
The paper proposes secure file system (SFS) as a scalable system that can provide a global file system to its users irrespective of the key management techniques adopted underneath. The authors use the approach of isolation and modularization at each level to separate key management from file security. They show how various mechanisms can seamlessly work with SFS with some overhead compared to the NFS.

Problem:
Previous solutions did not have scalable key management with security. A system supported a single management technique which was not necessarily good for all cases. Because of the tightly coupled design, the systems were not globally compatible with other techniques.

Contributions:
• Key idea is the user to be able to access and share the contents from anywhere irrespective of the underlying file system and the key concept to achieve this is to decouple the file system and key management.
• The SFS has a single global file system irrespective of key management technique. It provides a global namespace /sfs and all files are under this directory.
• SFS uses the self-certifying pathnames that includes the information for securely communicating with the file server. It includes the location (like IP of the server) and a HostID which is obtained by hashing the public key and server location together (cryptographic).
• Symbolic names can be used to store the long pathnames conveniently. They can also be multi-level so that one server can redirect to the other.
• To isolate the authentication procedure, it is handled by the “agents” on client side and “authserver” on server side. Every user has his own view of the /sfs directory and is managed by its agent.
• SFS avoids the overhead of a central authority for key management, and any user can setup a new file server for its use.
• SFS can use key revocation or HostID blocking to avoid using compromised server. Also, it isolates the key distribution and revocation – this helps in using a single revocation mechanism irrespective of any distribution used.

Confusion:
• I did not really understand how the key negotiation is happening – paper says that client and server exchange random keys, split into 2, with each other. Why wouldn’t it work with whole keys instead?

Learning:
• I learnt how researchers were aiming to implement a scalable as well as global system that is coherent to its users. It was especially important with the rising internet use and I learnt how having multiple mechanisms for key management can hinder such implementations and how SFS can help here.

Summary

This paper discusses the design, implementation and evaluation of SFS. The key problem to adoption of a single file system that can globally work for all users is that of security - specifically how keys are managed. No single approach to key management can possibly satisfy every user of the file system. At a high level, the paper proposes separating key management from file system security as a solution.

Problem

Key management is a problem in a file system that spans the internet. People prefer different security policies and it is hard to satisfy secuity requirements of all users by a single file system. SFS separates key management from the file system security. It provides ways using which different key management mechanisms can be built on top of it.

Contributions

Self-certifying pathnames to authenticate file servers. The filename itself contains the location and hash of the public key of the server. So a user can authenticate a server if he/she just has the self-certifying pathname.

Single key revocation mechanism independent of how the key was distributed.

User authentication is decoupled from the file system allowing for different ways to authenticate users.

What I didn’t understand

I am confused about the real use cases for SFS. For what use cases is it best suited other than global file sharing and access? Is it used in practice today?

What I learned

The importance of separation of policy and mechanism. SFS separates mechanisms to provide security and the key management policies that can implemented separately.

Secure File System (SFS)

Summary:
The key management poses a great problem for scaling distributed file systems to the scale of the internet. No one particular key management strategy used by any network file system would satisfy all user needs. SFS, provides security for file systems at the scale of the internet by separating key management from the file system and to provide some primitives like self-certifying pathnames for providing security and authentication.

Problem:
The management of encrytion keys becomes a big problem at the scale of the internet and there is no satisfactory means to do it. This makes all the existing file systems lack the key management strategies for security at a large scale. SFS solves this problem by removing key management entirely from the file system.

Contributions:
1. The major contribution of this paper is the idea of self-certifying pathnames, which contain all the information necessary to communicate with remote file servers in a secure way using the pathname of the form /sfs/Location:HostID.
2. The idea of providing a global file system image without using any local configuration files and providing versatility without using any certificate authorities.
3. The various server key management strategies provided to help ordinary users not to use the raw HostIDs. For example, by secure links provide a mechanism to access a self certifying pathname on a file by using a symbolic link on another file system.
4. The mechanism of user authentication using the agent program on the client side and the authserver on the server side makes it easier for users to establish a new file server.
5. Key revocation and host id blocking mechanisms to prevent users from accessing bad self-certifying pathnames is also very useful.

One thing I learnt:
I learnt that key management can be totally separated from a file system and that different key management techniques can be used to achieve security in a distributed file system. I also learnt that people were trying to develop something like a one-file system for the internet which is secure.

One thing I found confusing:
I'm not sure how password authentication is used to retrieve the self-certifying pathnames.

Summary:
This paper proposes a mechanism to separate key management from the file system security, which enables the users to share a single global file system inspite of there being multiple individual keys. This is done in a completely decentralized manner letting the users directly authenticate the server.

Problem:
At a scale such as the internet, security becomes very difficult to implement and manage. In addition to this, a single key management mechanism may not be satisfactory to all users. So, this paper tries to solve this problem by separating key management from file system security and letting users use any of the available security mechanisms and build on top of them.

Contributions:
1. The authors introduce “self-certifying” pathnames which specify public keys in addition to location of the files. This removes the need for a separate mechanism of key management for communication with the servers.
2. They implement user authentication as a separate module, which enables users to employ different authentication mechanisms.
3. The paper implements two programs, sfsagent on the agent side and authserv on the server side to establish server authentication and user authentication.
4. Separating the key revocation component from the key distribution component enables a single revocation mechanism to revoke a HostID that has been distributed in a lot of different ways.

What I found confusing:
I did not completely understand how the user sets up his private key using sfskey protocol. Does this happen once or multiple times? I also did not understand the use cases for read-only and writable databases for storing user credential mappings.

What I learned:
I learned that implementing parts of a system as separate modules helps us a lot in extensibility and portability. For instance, separating key management and key revocation as separate modules in this paper.

Summary:
This paper introduces a secure file system which uses self-certifying file-names to securely authenticate the server. The file system is not bound with any key management, but file system primitives itself can be used to build a simple key management system or a different sophisticated key management mechanism can be used. The goal of the paper was to allow users to access and share files; and create their own file server easily without any system administration burden.

Contribution:
1. The main contribution of the paper was to separate the key management from the file server. The file-name contains the location and public key of the server. Only a server with valid secret key can establish a secure channel to the client i.e. clients can authenticate the servers. Key management to authenticate server is then simply reduced to arranging user's access to self-certifying pathnames. To authenticate users server can use any technique such as password, authentication server, etc.
2. SFS can transparently authenticate server across administrative realm. There user can access his file from any client.
3. SFS can be used with any key management mechanism to provide additional security such as authenticating users.

Confused: I am confused about the usability of SFS in a distributed system. In a distributed system, a file is replicated and cached in multiple servers and servers join and leave the system. Isn't the HOSTID of the file will be different for each replica, and that means the file name will be different for each replica. How does managing all these different filename works, and how different components knows about new key with central authority?

Learned: I learned about how separation of functionality can be used to provide flexibility in the system. By providing self certifying pathnames, it provides infrastructure for variety of other key management techniques.

Summary
Implementation of a secure, global network file system which scales over the internet and allows for different kinds of key management systems depending on need.

Problem to solve
Management and utilization of security becomes a problem when trying to scale for the Internet. Key management should not be limited to any particular one as it would not suffice due to diversity of the users. SFS must not rely on external information in order to guarantee. In order to provide this guarantee local configuration files must not be used, it cannot acquire global authority as they will go against the set goals.

Contributions.
Introduces the notion of self-certifying path names which removes key management at the file system level entirely. Thus the key management depends on user’s choice of file names.

User authentication is separated from the file system allowing for versatility in the protocols used to authenticate user.

Modular designing allowing different file systems, and user authentication protocols.

SFS implements a key management infrastructure even under the clause of diverse key management techniques. It also allows combination of different mechanisms to which provide improved functionality.

Found confusing.
Didn't understand the internal functioning during password authentication.
When performing key negotiation why send only key halves? Is there a particular reason.

Learned from the paper.
Learnt about the improved effectiveness with the use of different key management techniques.

Summary: SFS uses self-certifying path names to create a secure FS, without relying on external mechanisms. In addition, because it has a global namespace, it allows the FS to be used as a way to manage and look up keys.

Problem: there are no global filesystems with a way to authenticate everything. Essentially, there is nothing like the system set up with HTTP and certified (SSL) resources, but for a filesystem.
Contributions:

• The HostID has the public key embedded in it, thus self-certifying it.


• A certification authority can be set-up on top of the FS, basically pointing to certified hosts with symlinks.

Confusing: How do the sfskey and authserv communicate with the server? They do not
communicate through the FS, but with the SRP protocol. Why isn't the FS
layer used for communication?

Learned: that embedding some sort of certification into the name of a resource can be a cheap, yet effective, way of authenticating a resource to another party.

Summary
Given the scale of the internet, a file system that inherently imposes a key management policy will fail to scale out. By separating key management from the file system, and providing primitives instead to support other key management and authentication mechanisms, SFS looks to achieve the scale of adoption that could span the internet.

Problem
File systems that existed then conflated key management with file system security. The absence of this separation meant that a secure file system that spanned the internet would mandate a key management policy that everyone would have to adopt. The SFS file system being presented looks to separate key management out of the file system, and instead provide primitives using which key management mechanisms can be built on top of the file system.

Contributions

• Identifying that the need for separating key management from the file system, as a solution to providing scalability in terms of adoption and ease of management across the internet.


• The concept of self-certifying pathnames as a solution to authenticating trusted servers. By embedding the public key information in the file name, the file system effectively extricates the need for key management internally. This provides a global namespace that can be extended to perform the role of a key certification namespace on top of which other key management policies can be built, and made to coexist.


• Modular separation of user authentication outside of the file system, allowing for different authentication mechanisms that can be employed.


• Separation of key revocation from distribution enables a single revocation mechanism to work irrespective of how the revoked keys were initially distributed.

What I didn’t understand
Given that 97% of the time delay over NFSv3 can be attributed to the user-space implementation, why was it not implemented as a kernel module. Is portability that important?

What I learnt
Sometimes, concepts that seem closely related in systems, can be separated to achieve added benefit. Such as the separation of key management from the file system in this paper, or separation of ordering from durability in file systems [a la OptFS].

Summary: Paper presents SFS, a distributed file system that achieves flexible security for a variety of different cases. It achieves this by separating key management from the file system itself. The main mechanism used for this is the idea of a self-certifying pathname that inherently contains the public key and location of the server that a file is located on. The system provides user authentication services. They show that SFS is only slightly worse in performance than insecure NFS.

Problem: Secure distributed file-systems are hard to manage; even more so when they operate over the internet. Most systems at the time that wanted to operate over a network just dropped the security aspect. While in a closed system this type of decision may be acceptable, when operating over a wider network it becomes harder to justify. Therefore, being able to simplify this management issue so that operators have a greater incentive to deploy a secure distributed file system is advantageous.

Contribution: The main contribution of this paper is the creation of SFS with the ideas of separating key management via the use of self-certifying path names thus giving the entire global namespace the ability to have public keys built into them.

The authors were adamant in their distinction between providing key value management and providing a base to build upon it any number of management schemes. Since different management schemes make different tradeoffs with regards to security, building a management scheme into the file-system is too limiting. Again, the way the authors achieve this separation is with what they call “self-certifying pathnames”. What makes this “self-certifying” is that these pathnames contain the public key of the server from which they come from. This information is contained in the “hostID”, which is basically a hash of the info, location, and public key of the server. Therefore, the full pathname consists of a location, hostID and the file path on the remote server.

While multiple key management policies can be built upon this, SFS also provides authentication services that allow servers to authenticate users. The use of self-certifying-pathnames allows users to verify the servers, but the other way around is also necessary.

Finally, they present ideas with regards to how key revocation would work. One of their ideas was to use certificates to revoke file access and have a system like Verisign that would have a list of revoked filenames.

Confusion: I was having a hard time understanding how exactly the security components of the system worked (i.e. the stuff contained in the cryptography section). I didn’t really understand how the user authentication was working.

Learned: I learned about SFS and the fact that there seemed to be a goal or research push to have an “Internet file system” or one that spans the internet. It's interesting because I'm trying to think if there is something like this vision in place today. The closest thing I can think of is cloud based systems like dropbox and google drive. They don't seem to come very close to this egalitarian model that the paper was pushing for.

Summary:
This paper introduces a secure file system that avoids internal key management. In that file system (SFS), file names effectively contain public keys, making them self-certifying pathnames. SFS doesn’t depend on centralized authority to manage the namespace, and it encrypts the traffic between client and server to protect the data. The implementation of SFS performs comparably to NFS v3 on application benchmarks.

Problem:
Other secure file systems need key management to map file names to encryption keys. The key management is difficult to be deployed in global scale with diverse networks, which limits the scalability of traditional security file system. Relying on centralized authority to manage the keys also limits the availability of file system.
File sharing across administrative realms is hard for network file system without global namespace. And it’s hard for user to create new file server for users.

Contributions:
The most important contribution of this paper is the self-certifying pathname, which solves the problem of authenticating file servers to users, because clients can authenticate servers without performing key management.
SFS has a global namespace, all the files are mount under /sfs, and users with permission can access to the file from anywhere with SFS client installed.
SFS has no centralized authority to manage the keys. Any user with a machine in Internet can setup secure file server for users.
SFS pushes key management out of the file system lets arbitrary key management policies coexist on the same file system, which in turn makes SFS useful in a wide range of file sharing situations.
SFS separates key revocation from key distribution, so the key management can be flexible without worrying about the compromised keys.
SFS is built upon NFS, and it runs in userspace. Most part of the software run as non-root. That implementation achieves high portability. The benchmarks result prove that secure file systems implemented in userspace can also achieve good performance.

Discussion:
With self-certifying pathname, SFS simplifies the process for users to authenticate file servers, makes the centralized key management authority unnecessary, and makes the namespace be global. That’s the most impressive point for me after I read this paper. What I learn from that point is that we can add more information to the names in file systems in addition to identification and location. We might be able achieve high flexibility.
I am confused about the design choice to achieve high portability by implementing SFS based on NFS, after all, the authors also admit that running an NFS server can in itself create a security hole, whereas security is the most important feature of SFS.
Keep the file system running in userspace is good for portability as well, and the authors’ benchmark results indicate the performance penalty is acceptable, but if we use specialized hardware to accelerate the encryption/decryption, the penalty to run the software in userspace is unknown.
SFS doesn’t try to achieve high availability by replicating data, can it be implemented in low-layer, e.g. underneath NFS?

Summary:

The paper describes SFS, which is a secure file system that can be scaled to a network to the size of the internet. It describes how to separate key management from the file system, and shows how many applications with various key management protocols can be built using the primitives provided by the system.

Problem:

On a large network like the internet, one cannot expect all users to use the same mechanism for key-management. Existing file systems impose a particular key management mechanism that doesn't necessarily serve the diverse requirements across users. Security procedures are cumbersome and impose an administrative burden on the users of the system.

Contributions:

- Provides a generic mechanism that allows anyone to setup a secure server on the internet without an intervening central authority. We don't have to trust a certification authority, and the server needn't pay the certificate fees.
- Decoupled design allowing the user to choose from among several mechanisms for key management without affecting the core file system.
- Self certifying file names create a global namespace that can be accessed with relative ease over the internet.
- Transparent mounting of remote SFS file systems using symbolic links.
- Provided a key-management infrastructure that can easily be migrated to from the existing PKI infrastructure by parsing SSL certificates.
- On the fly transparent mounting of a remote file system upon access.

One thing I found confusing:

I did not understand what a weak secret is.

One thing I learned from paper:

I learned how forward secrecy is implemented.

Summary:
This paper is about the design and implementation of SFS - Secure File System which differs from other network file systems in terms of key management. SFS decouples user authentication from the file system and enables efficient file sharing across different administrative domains that employ heterogenous key management techniques. The file system also acts as an infrastructure for building various key management techniques and is highly versatile than other secure file systems.

Problem:
Security is a key concern while sharing data in internet. Following a specific key management policy like Kerberos could limit the purposes of a secure system. This is also due the varying security requirements for different types of scenarios. Deployment of such secure systems is also complex due to these specific key management techniques.

Contribution:
1. Key management is removed from the file system by using self verifying path names which contain the public keys that are required to communicate with the file servers in a secure manner.

2. User authentication decoupled by using a modular architecture. This enables us to change the authentication protocols without affecting the underlying file system.

3. Multiple key management policies can coexist on the same file system. This is very useful whenever files need to be shared across different domains.

4. Provides a infrastructure to build various key management techinques.

5. Allows users to employ their own algorithms for file name resolution.

6. Self certifying path names and automatic mounting enable to create an SFS server and reference to it using the Location:HostID mechanism from any client.

7. Hiding pathnames that are not accessed by an agent so far, thereby preventing a user from accessing a malicious host id.

One thing I found confusing:
Under password authentication I did not quite understand the mechanism of users registering additional copies of private keys with authserv process. When the user runs “sfskey” command does he enter the private key to register and does this behave like single sign on environment ?

One thing I learnt:
By combining multiple key management techniques, we can achieve high levels of security. For instance, while resolving a path name for a file, we can employ different key management techniques for each step of the resolution.

Summary:
This paper describes SFS, a distributed file-system that self-certifies file locations, allowing it to be used at internet scale.

Problems:
Current solutions to file sharing had many problems. One important problem is that management of an internet-scale file system is too cumbersome to be done using any available software. They limit themselves to one key management approach, which hinders users, and leads to low use of secure network file systems. In addition, these systems limited where and how any secure files could be accessed.

Contributions:
The solution this paper proposes covers a few important areas, but the most important is self-certifying filenames. By using the public key to map to a files location, all files on the internet can share the same namespace, making it possible to access files from any internet-connected device. This allows for all sorts of interesting use cases, especially where file locations themselves are symbolic links to other file locations. But most importantly, this allows for separating key management from file system management. Any key-management scheme can be used with any different file on the same server.

In general, then, the take-away would be that it is possible to have a single network file system that runs on such a large scale. It can share a single namespace, and still be flexible enough for (almost) every use case.

Confusing:
The only part I didn’t understand entirely is the password authentication part. It seems they had to implement an extra part for passwords?

Learned:
One interesting part is the description of setting up a SSL server. Of course, times have changed now, so I would be interested to compare how it worked then with now, and how secure the process is.

Flaw:
The major flaw I saw in this design was the requirement that the client run a specific client program. While this may have seemed reasonable at the time, it seems the reason that SSL (in the form of HTTPS) has won out is because we just access the files through our web browser, which is software already running on our machines. Of course, hindsight is 20/20.