You are here: Foswiki>TIG Web>DIRNetworkFileStorage?>IntroToKerberosAndAFS (09 Nov 2006, JonProulx)EditAttach

An introduction to Kerberos and AFS

In just about any enterprise computing environment, there are common needs that all users have. Among these needs are authentication and file storage. Despite the fact that these are almost universal needs, they have not always been met in a universal way. In the former Laboratory for Computer Science (LCS) and Artificial Intelligence Lab (AI) at MIT, each research group had its own solution for where to store files: on workstation disks, on Microsoft Windows file servers, Appleshare servers, UNIX NFS file servers, dedicated file server appliances, and so on. To complicate matters, there was no centralized authentication: that is, no central way of validating that a particular user really was who he or she claimed to be when requesting computing resources, like access to files.

When the merge between AI and LCS happened, we wanted to rethink the way files are stored and authentication is handled. We wanted to create an infrastructure that could handle the entire CSAIL population in a scalable way and that was not locked into one particular platform. After much thought and research, we settled on Kerberos as the core of our authentication system, and AFS as the core of our file service.

What is Kerberos?

The following section was excerpted from the MIT Kerberos release page.

Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. A free implementation of this protocol is available from the Massachusetts Institute of Technology. Kerberos is available in many commercial products as well.

The Internet is an insecure place. Many of the protocols used in the Internet do not provide any security. Tools to "sniff" passwords off of the network are in common use by malicious hackers. Thus, applications which send an unencrypted password over the network are extremely vulnerable. Worse yet, other client/server applications rely on the client program to be "honest" about the identity of the user who is using it. Other applications rely on the client to restrict its activities to those which it is allowed to do, with no other enforcement by the server.

Some sites attempt to use firewalls to solve their network security problems. Unfortunately, firewalls assume that "the bad guys" are on the outside, which is often a very bad assumption. Most of the really damaging incidents of computer crime are carried out by insiders. Firewalls also have a significant disadvantage in that they restrict how your users can use the Internet. (After all, firewalls are simply a less extreme example of the dictum that there is nothing more secure then a computer which is not connected to the network --- and powered off!) In many places, these restrictions are simply unrealistic and unacceptable.

Kerberos was created by MIT as a solution to these network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.

What is AFS?

AFS is a distributed filesystem product, pioneered at Carnegie Mellon University and supported and developed as a product by Transarc Corporation (now IBM Pittsburgh Labs). It offers a client-server architecture for file sharing, providing location independence, scalability and transparent migration capabilities for data. IBM branched the source of the AFS product, and made a copy of the source available for community development and maintenance. They called the release OpenAFS.

Why AFS and not NFS (or SMB)?

AFS was chosen over NFS for implementing a shared network file system for several reasons, including its security model. Users authenticate to the file system using Kerberos rather than assigning permissions based on a locally assigned UID. The one of the classic security flaws in NFS is that root must be trusted on all systems that mount the NFS share because root can assume the UID of any user. AFS eliminates this.

AFS also transmits data encrypted over the network and does caching on local disk to speed subsequent access.

The most obvious difference to the user from NFS is that AFS has a different permissions model. Permissions are applied as Access Control Lists (ACLs) per directory not as Unix Mode Bits per file. This means that all files in a given directory have essentially the same permissions. The exception is that you can remove write permissions on a per file basis using the standard Unix 'chmod -w '

AFS provides for allowing and denying permissions on a per user basis and allows users to create their own groups that can be used in ACLs. Multiple users and groups may be specified. This gives much greater granularity that the Unix convention of files having exactly one owner, one associated group (which must be defined by an administrator) and then everyone else.

Microsoft Windows file sharing (often called SMB or CIFS) is fairly familiar to users of that operating system, and many operating systems are able to access these file systems through the use of add-on software pagkages and kernel extensions. However, it is still a technology that is dominated by Microsoft, which makes it a less-than-optimal solution in our environment.

MIT Project Athena uses AFS for file storage, in conjunction with Kerberos authentication. Since these two technologies have a long history with MIT, as well as support for just about every platform in common use today, it seemed like a natural fit for the heart of the CSAIL infrastructure.

Some AFS limitations

We soon realized that there are a few places where AFS isn't a good fit:

  • For databases (in fact the same can be said for any network file system)
  • For concurrent read-write access from many hosts to one file

For data that falls into one of these categories, we also provide centralized NFS storage, but it is important to remember that NFS storage is much less safe than AFS based storage. One only needs to create a user account on a machine that has access to an NFS export, and match the UID of your files with the UID of the local account. They can then access all of your files, without any authentication whatsoever. This weakness was part of the reason that in 2003, the AI Lab's entire data storage space was attacked and erased by a single malicious user.

How does Kerberos work?

The very short version of the answer to this question is as follows: you provide a username and password to whatever your Kerberos authentication front-end happens to be - Leash32 for Microsoft Windows, the Kerberos application for Mac OS X, the
kinit
command in Linux - and as a result, you are granted a kerberos "ticket" that gets you into other services that use Kerberos for authentication.

A good introduction that is slightly more detailed can be found at The Moron's Guide to Kerberos. Despite the name, this is definitely worth a read.

An example of authenticating using Kerberos

For the following example, I'll use Mac OS X as the operating system, but please don't tune out this section if you don't use a Mac: the information here is applicable to all platforms.

Mac OS X comes equipped with Kerberos by default, although it isn't hooked into the local login process you see when you start your Mac. At CSAIL we will probably configure your Mac to automatically do all the Kerberos magic behind the scenes so you don't have to manually authenticate; but it's still good for you to have a vague idea of what's going on under the hood.

Once I've logged into my local user account on my Mac - assuming I don't have automatic login enabled so I don't have to deal with all those pesky passwords - I open up the Kerberos application, which is located in
/System/Library/CoreServices/Kerberos
and usually has an alias at
/Applications/Utilities/Kerberos
:

Kerberos control panel

In the image shown above, you can see that there is a setting for a REALM. Realm is a term used in Kerberos to describe an organizational group, sort of like a domain. MIT has its own realm, which is called ATHENA.MIT.EDU. CSAIL's realm is called CSAIL.MIT.EDU. Strictly speaking, a realm name does not have to be the same as the DNS domain name, but a lot of realms make it that way for simplicity's sake.

Also notice that there are several checkboxes that are checked, and in particular there is one that says "Get tickets that can be renewed for:" This setting is important because of one important Kerberos Fact:

KERBEROS CREDENTIALS EXPIRE AFTER A WHILE.

This fact is due to a security measure that Kerberos uses to prevent a malicious person from stealing a user's credentials. Since credentials expire, it helps minimize the window of opportunity that an attacker has to do damage with ill-gotten credentials. The shorter the lifetime of the credentials, the smaller that window of opportunity is. Of course, it also decreases the convenience to the user.

Some people are used to turning on their computer and never having to log in or type passwords, especially Macintosh users. However, in a large computing environment that is constantly being probed for just such a weak link, this is not an available luxury. We've struck a middle ground with our Kerberos realm that we think maintains a reasonable balance between security and convenience: we allow users to "renew" their credentials for up to two weeks. By default, CSAIL Kerberos tickets expire after ten hours, but at any point during that ten hours, a user can renew them for another ten hours; and so on, until the two weeks have transpired.

The nice thing about the Kerberos application on Mac OS X, Leash32 in Microsoft Windows, and other facilities for the CSAIL GNU/Linux distro, is that they can renew your tickets automatically for you. Just keep in mind that the longer you let your credentials hang around, the greater the risk you take that someone can steal your credentials and destroy - or, even worse - steal or subtly alter your files. It's your choice where you want to be in the continuum of security and convenience.

Using AFS

To be able to use the CSAIL AFS "cell" - that is, shared file storage space dedicated to CSAIL users - you'll need to run the AFS client software that is appropriate for your platform. CSAIL GNU/Linux is preconfigured with all the right stuff to use Kerberos and AFS, but if you are running a Mac or a Microsoft Windows PC, you'll need extras software installed (which tig can do for you).

In the following example, we'll use Microsoft Windows XP Professional as the operating system. Again, please read on even if you aren't using that OS, since the concepts still apply.

-- MarkPearrow - 06 Dec 2004
Topic revision: 09 Nov 2006, JonProulx
 

MIT Computer Science and Artificial Intelligence Laboratory

 

  • About CSAIL
  • Research
  • News + Events
  • Resources
  • People

This site is powered by Foswiki MIT: Massachusetts Institute of Technology