Subject: Re: Questions not in FAQ - msg#00011

Previous Message by Date: click to view message preview

Re: Questions not in FAQ

On Sat, 1 Feb 2003, David Mazieres wrote: Thanks for your answers. > > This sfsagent.. Does it use kerberos or any other central db for auth > > users? > The agent is on the client side, and the client does not have a notion > of administrative realm. Thus, you can run: Ok, not a good idea to use SFS if you WANT a central db. Im admin of a 10-years-old AFS cell and will soon set up yet another AFS cell. > However, SFS as a network file system has a number of advantages over > SFS: NFS you mean? > 1. Sound cryptographic protocols. Strong? :) > 5. The ability to access any server from any client. In AFS, > there's a file /usr/vice/etc/cellservDB listing all the cells, > so there is a limited number of cells you can access. SFS is openafs looks for afsdb in DNS if not listed in CellServDB. > 6. The ability for untrusted people to create servers. For > example, if students want to set up AFS servers in their dorm > rooms, they typically can't. However, setting up an SFS server Yes, that can be good for some. > 7. The ability to share user databases. For example, NYU can > import users from MIT and vice versa, without needing to trust > each other. This is a result of the public key cryptography for > user authentication--one realm can safely share it's users' > public keys with another. That is a good feature. > I think the ideal network file system would look like SFS as a network > file system, but allow you to manage volumes and such on the server > the way AFS does. Someday perhaps we will have an SFS server with > this functionality. One other good property of SFS is that it has a Why not help openafs and implement strong crypto in AFS instead? BTW does SFS use portmap/rpc just as NFS?

Next Message by Date: click to view message preview

Re: Questions not in FAQ

> Date: Wed, 12 Feb 2003 22:47:20 +0100 (CET) > From: Peter Magnusson <iocc@xxxxxxxxxxxxxxxxxxxxxxxxxx> > > > However, SFS as a network file system has a number of advantages over > > SFS: > > NFS you mean? I meant over AFS, sorry. > > I think the ideal network file system would look like SFS as a network > > file system, but allow you to manage volumes and such on the server > > the way AFS does. Someday perhaps we will have an SFS server with > > this functionality. One other good property of SFS is that it has a > > Why not help openafs and implement strong crypto in AFS instead? > BTW does SFS use portmap/rpc just as NFS? SFS uses RPC, but not portmap. The RPC is done over a new encrypted and authenticated transport, because the AUTH mechanisms specified with RPC are not really the right hooks to implement something secure. While AFS's crypto should be improved, a number of the problems are inherent in its architecture. For example, the fact that there is no security for anonymous users. One of our target applications (for the read-only SFSRO) is distributing open-source software. Rather than having each OS distribution develop its own home-grown upgrade protocol, you can just put all your RPMs or Debial packages, or OpenBSD packages or whatever in a secure file system, and secure upgrade becomes a matter of a simple shell script. The reason AFS cannot guarantee data integrity to anonymous users of public file systems is that the AFS interface does not capture a users' actual intent when the user accesses a particular file system. If I run: cd /afs/redhat.com What should this mean? One possibility is "access a server that has a public key and certificate signed by Verisign for domain name redhat.com." Another equally valid possibility would be "access a server that has a public key in $HOME/.ssh/known_hosts." (Though what to do if different users disagree on the public key?) Yet another possibility would be "access the server redhat.com with a public key that was bundled with your OS distribution and is stored somewhere on your hard disk." All of these are valid interpretations, yet none is valid for all scenarios. Public key certificates provide the appropriate security level for things like e-commerce, but are too expensive for students in dorm rooms and not secure enough for other settings. (Say you worked for Thawte, one of Verisign's competitors. You might in general want to accept Verisign's certificates, but when you cd to /afs/thawte.com, you want to make explicitly sure that AFS doesn't honor a certificate from Verisign.) AFS was designed a long time ago. While it has fared reasonably well, the design was based on a number of assumptions that don't hold true any more. Notably: - AFS was designed under the assumption that public key cryptography was too expensive, or possibly impractical because of patents. - AFS was built on kerberos, which is designed to minimize the number of network round trip times during authentication. But with a file system, the initial login time is not a big deal. - Early versions of AFS were designed to minimize the amount state stored at a server per-client. Then they added leases, but the authentication protocol is still stateless, which is unnecessary. The result is a system vulnerable to replay attacks. - AFS assumes that workstations are single-user. - AFS assumes that sites will want large, centrally-controlled administrative realms, rather than a federation of independently-managed groups. - AFS assumes that all servers in a cell can trust each other. One big issue is that precisely because of it's centralized nature, it is very hard to upgrade AFS. For example, the kerberos protocol makes it easy for attackers to mount off-line password guessing attacks on people's passwords. It would be great to fix this. However, if you change the central kerberos server, you have to remain backwards-compatible for a very large amount of time, because of all the clients out there that will still be running the old software. At any rate, because AFS's design assumptions, I'm convinced that AFS is never going to become pervasive like SSH or the web. The goal of SFS is really to be "the SSH of file systems"--in the sense that you can run it anywhere, and get access to your files from everywhere. For this reason, it was much easier to start from scratch than to try to fix AFS. Two other issues are also that the code base for AFS is much larger than SFS, so it is harder to reason about its security. Moreover, it's also not clear that the AFS maintainers or that AFS administrators in general share SFS's philosophy of the world. People who run AFS are generally very happy with the centralized control it provides them. AFS *users* are the ones who are sometimes unhappy, because creating accounts for people ends up being an annoying centralized process, and because people can't just set up their own server if they don't like the one being provided by the realm administrator. An equivalent question might be to ask Tatu Ylonen why he didn't just fix Kerberized rlogin instead of building SSH from scratch. At least in retrospect, the answer seems pretty clear. David

Previous Message by Thread: click to view message preview

Re: Questions not in FAQ

On Sat, 1 Feb 2003, David Mazieres wrote: Thanks for your answers. > > This sfsagent.. Does it use kerberos or any other central db for auth > > users? > The agent is on the client side, and the client does not have a notion > of administrative realm. Thus, you can run: Ok, not a good idea to use SFS if you WANT a central db. Im admin of a 10-years-old AFS cell and will soon set up yet another AFS cell. > However, SFS as a network file system has a number of advantages over > SFS: NFS you mean? > 1. Sound cryptographic protocols. Strong? :) > 5. The ability to access any server from any client. In AFS, > there's a file /usr/vice/etc/cellservDB listing all the cells, > so there is a limited number of cells you can access. SFS is openafs looks for afsdb in DNS if not listed in CellServDB. > 6. The ability for untrusted people to create servers. For > example, if students want to set up AFS servers in their dorm > rooms, they typically can't. However, setting up an SFS server Yes, that can be good for some. > 7. The ability to share user databases. For example, NYU can > import users from MIT and vice versa, without needing to trust > each other. This is a result of the public key cryptography for > user authentication--one realm can safely share it's users' > public keys with another. That is a good feature. > I think the ideal network file system would look like SFS as a network > file system, but allow you to manage volumes and such on the server > the way AFS does. Someday perhaps we will have an SFS server with > this functionality. One other good property of SFS is that it has a Why not help openafs and implement strong crypto in AFS instead? BTW does SFS use portmap/rpc just as NFS?

Next Message by Thread: click to view message preview

Re: Questions not in FAQ

> Date: Wed, 12 Feb 2003 22:47:20 +0100 (CET) > From: Peter Magnusson <iocc@xxxxxxxxxxxxxxxxxxxxxxxxxx> > > > However, SFS as a network file system has a number of advantages over > > SFS: > > NFS you mean? I meant over AFS, sorry. > > I think the ideal network file system would look like SFS as a network > > file system, but allow you to manage volumes and such on the server > > the way AFS does. Someday perhaps we will have an SFS server with > > this functionality. One other good property of SFS is that it has a > > Why not help openafs and implement strong crypto in AFS instead? > BTW does SFS use portmap/rpc just as NFS? SFS uses RPC, but not portmap. The RPC is done over a new encrypted and authenticated transport, because the AUTH mechanisms specified with RPC are not really the right hooks to implement something secure. While AFS's crypto should be improved, a number of the problems are inherent in its architecture. For example, the fact that there is no security for anonymous users. One of our target applications (for the read-only SFSRO) is distributing open-source software. Rather than having each OS distribution develop its own home-grown upgrade protocol, you can just put all your RPMs or Debial packages, or OpenBSD packages or whatever in a secure file system, and secure upgrade becomes a matter of a simple shell script. The reason AFS cannot guarantee data integrity to anonymous users of public file systems is that the AFS interface does not capture a users' actual intent when the user accesses a particular file system. If I run: cd /afs/redhat.com What should this mean? One possibility is "access a server that has a public key and certificate signed by Verisign for domain name redhat.com." Another equally valid possibility would be "access a server that has a public key in $HOME/.ssh/known_hosts." (Though what to do if different users disagree on the public key?) Yet another possibility would be "access the server redhat.com with a public key that was bundled with your OS distribution and is stored somewhere on your hard disk." All of these are valid interpretations, yet none is valid for all scenarios. Public key certificates provide the appropriate security level for things like e-commerce, but are too expensive for students in dorm rooms and not secure enough for other settings. (Say you worked for Thawte, one of Verisign's competitors. You might in general want to accept Verisign's certificates, but when you cd to /afs/thawte.com, you want to make explicitly sure that AFS doesn't honor a certificate from Verisign.) AFS was designed a long time ago. While it has fared reasonably well, the design was based on a number of assumptions that don't hold true any more. Notably: - AFS was designed under the assumption that public key cryptography was too expensive, or possibly impractical because of patents. - AFS was built on kerberos, which is designed to minimize the number of network round trip times during authentication. But with a file system, the initial login time is not a big deal. - Early versions of AFS were designed to minimize the amount state stored at a server per-client. Then they added leases, but the authentication protocol is still stateless, which is unnecessary. The result is a system vulnerable to replay attacks. - AFS assumes that workstations are single-user. - AFS assumes that sites will want large, centrally-controlled administrative realms, rather than a federation of independently-managed groups. - AFS assumes that all servers in a cell can trust each other. One big issue is that precisely because of it's centralized nature, it is very hard to upgrade AFS. For example, the kerberos protocol makes it easy for attackers to mount off-line password guessing attacks on people's passwords. It would be great to fix this. However, if you change the central kerberos server, you have to remain backwards-compatible for a very large amount of time, because of all the clients out there that will still be running the old software. At any rate, because AFS's design assumptions, I'm convinced that AFS is never going to become pervasive like SSH or the web. The goal of SFS is really to be "the SSH of file systems"--in the sense that you can run it anywhere, and get access to your files from everywhere. For this reason, it was much easier to start from scratch than to try to fix AFS. Two other issues are also that the code base for AFS is much larger than SFS, so it is harder to reason about its security. Moreover, it's also not clear that the AFS maintainers or that AFS administrators in general share SFS's philosophy of the world. People who run AFS are generally very happy with the centralized control it provides them. AFS *users* are the ones who are sometimes unhappy, because creating accounts for people ends up being an annoying centralized process, and because people can't just set up their own server if they don't like the one being provided by the realm administrator. An equivalent question might be to ask Tatu Ylonen why he didn't just fix Kerberized rlogin instead of building SSH from scratch. At least in retrospect, the answer seems pretty clear. David