Distributed networks are inherently vulnerable to "illegal" intruders. This is largely a result of the fact that components are no longer contained in one entity as is stand-alone systems; they are instead separated by an "untrusted" interface--the network. This vulnerability grows as the networks grow and connections extend beyond the local organization reaching a larger unknown community of strangers.

Security solutions can be expensive, complicated, and difficult to administer. When choosing a security solution, care should be taken to fully understand the security requirements of the environment. The following quote by noted security expert Jeffrey Schiller from MIT sheds light on this subject:

• "It is always important to understand the value of the information being protected, or the cost to the organization for its compromise or loss. Providing security comes at a cost; It is important that this cost be commensurate with the value of the protected information. [...] When speaking to people I like to say `It makes no sense to put a bank vault door on a cardboard house protecting an orange'." [12])

Along these lines, systems administrators should take care to select a distributed file system solution that provides the freedom to choose from a variety of security mechanisms whether the goal is to protect oranges or diamonds! Although some distributed file services are locked in to a single security service, NFS provides the freedom to choose between existing services today and is extensible to support new services in the future.

Security Services Available with NFS

There are many types of threats to security. For example, someone may compromise a system by impersonating another user in order to look at sensitive information or worse, destroy data. In another scenario, someone might send forged requests to an NFS server to access or damage file information. It is also possible to utilize a network "snoop" to watch parts of files being transferred and illegally gain access to data.

NFS can be implemented to utilize a variety of security services. The following sections describe how the security services provided by Solaris and utilized by NFS help protect against unwanted intrusions.

Authentication Services

An authentication service provides a mechanism for checking a users's network "identification" to make sure they are who they claim to be before being allowed to use resources. NFS can be configured to utilize two authentication services: one based on the Diffie-Hellman key exchange protocol and one using Kerberos. In addition, NFS can also utilize a simple authentication mechanism that is referred to as "Unix-style" authentication. NFS is able to utilize multiple authentication "flavors" by virtue of the fact that they are accessible through the TI-RPC service.

Both the Diffie-Hellman and Kerberos authentication options utilize an encryption service to protect authentication information. An encryption service protects data by making it unreadable by an unauthorized recipient. Information is encrypted using an encryption algorithm with a special value or key. Only those who know the decryption key value can convert the data back to its readable form.

The Data Encryption Standard

The encryption standard used in conjunction with the Diffie-Hellman and Kerberos authentication services on Solaris is the Data Encryption Standard (DES). DES was developed by IBM in the 1970s and became a national standard in 1977. It has been in existence for over 15 years and has never been broken.

DES is a private key encryption algorithm. What this means is that the same key value is used to both encrypt data before it is sent over the network and decrypt the data after it has reached its destination. But the question that arises in this scenario is, how does the recipient obtain the key in order to decrypt the data? How can the key value itself be sent over the network without its identity being compromised?

One answer is to use a public key exchange mechanism. Public key mechanisms differ from private key mechanisms in that a different key value is used for encrypting than is used for decrypting. The benefit of this is subtle but important because it solves the key distribution problem. When employing public key mechanisms, the encryption key can be posted in a "public" place such as a trusted name service, while the decryption key remains a "secret", known only to the recipient [13]).

The Diffie-Hellman Public Key Exchange Protocol

The Diffie-Hellman authentication option implements a public key exchange mechanism which NFS uses in the following way: The client asks a local software process called the key server to give it a unique DES private key. (This DES key will eventually be used to encrypt and decrypt authentication data exchanged between the client and server.) The client then asks the key server to encrypt the DES key using the server's public key and the NFS user's own private key. The client encrypts a time stamp and other related information using the DES key and sends it along with the encrypted DES key itself to the NFS server. The NFS server decrypts the DES key and using it decrypts the time stamp and the other information. If everything checks out OK, the client is authenticated as acting on behalf of it's user.

Kerberos

The Kerberos authentication service was developed by the researchers at MIT for project Athena. It offers additional layers of protection beyond what is available with simple private or public key based services. Kerberos introduces the notion of a ticket which contains expanded information about the user, and an encrypted DES key assigned by a trusted host called the Key Distribution Center (KDC). Issuing, obtaining and using tickets involves a nontrivial sequence of events that are beyond the scope of this document. However, the end result is that a DES key is safely distributed to both client and server, ensuring mutual authentication in much the same way as the scheme using Diffie-Hellman.

In order to use the Kerberos security option with NFS, a KDC must be present and accessible to NFS clients and servers on the network. Several vendors provide KDC software for their platforms. In addition, a public domain version of the KDC software that can be ported to different platforms is available from MIT.

The current version of Kerberos that is utilized by NFS on Solaris is Kerberos version 4. A more recent version of Kerberos, version 5, will be available in a future release of Solaris. Until then note that a Kerberos 5 based KDC is backward compatible with and can therefore service Kerberos 4 clients.

"Unix Style" Authentication

The benefits derived from private and public key authentication mechanisms aren't necessarily "free". There can be a trade-off between a high level of protection and distributed file system performance. In those environments where very minimal security is acceptable, the Unix style authentication option can be successfully employed with little or no performance impact. When using Unix style authentication, NFS servers accept client requests only if the clients network address appears in a list of trusted hosts.

Generic Security Service Application Program Interface (GSSAPI)

There are many authentication "flavors" both standard and proprietary, both existing and emerging. Futhermore, it is likely that there will continue to be many, considering the fact that no single solution can satisfy the unique requirements of every distributed network environment. It is clear that distributed systems must possess the flexibility to support multiple authentication solutions under one "roof" in a standard, consistent way.

SunSoft is currently modifying NFS and TI-RPC to support a standard called the Generic Security Service Application Program Interface (GSSAPI). The GSSAPI defines a framework for uniting multiple authentication flavors underneath a common API. The GSSAPI is described in the Internet standard request for comment (RFC) 1508, and is referred to as the technology that enables true "pluggable" authentication.

Authorization Services

The purpose of an authorization service is to ensure that users have the permission to do what they are attempting to do once they have been successfully authenticated. NFS supports two authorization mechanisms: Unix style authorization (sometimes known as "permission checking") and Access Control Lists (ACLs).

"Unix Style" Authorization

On Unix systems, files are protected by a set of permission indications called permission bits. Permission bits are set (either "on" or "off") to indicate whether read, write and/or execute permission is allowed for the owner of the file, the members of certain groups, or for the world (also referred to as "other"). Further, each user and each group is assigned a unique identification number (ID). When a user attempts to access a file, his/her user ID (UID) and group IDs (GIDs) are checked and compared with the files permission bits in order to determine what file operations are allowed.

In order for NFS to employ Unix style authorization, both client and server must either share the same ID list, or there must be a mapping between the two. If a mapping is required, it is usually performed by the server following a static mapping scheme or a scheme established by the client system at mount time. After the mapping is established, users are authorized to manipulate files on a per operation basis.

Access Control Lists (ACLs)

Access Control Lists (ACLs) expand the amount of file permission information and exert a tighter reign over permission checking thus enhancing the level of protection against illegal access. Access Control Lists (ACLs) are just what the name implies: a list that controls access to files. Every file has an associated ACL. Clients identify themselves to the ACL manager by providing a list of identification values including their UID and GIDs. The NFS server is responsible for responding to client requests by comparing the client permission values to the file's ACL and either granting or denying access based on the results of the comparison.

In Solaris 2.5, both UFS and NFS ACLs have been implemented according to the POSIX 1003.6 draft standard [14]). Both NFS Version 2 and NFS Version 3 servers support ACLs by virtue of extensions that have been made outside of the NFS protocol. If an NFS server (Version 2 or Version 3) encounters a client (Version 2 or Version 3) that does not inquire about ACLs, then these extensions are simply bypassed. This enables NFS ACL servers on Solaris to be backwardly compatible with NFS clients that do not support ACLs.

Secure File Data Exchange

Once a user is properly authenticated and her permission status checks out, file sharing and information exchange between the client and the server can proceed. NFS file data is not encrypted by default before it is transferred over the network. If this is desired, it is necessary to use a user level encryption tool (e.g. crypt) on the sending end, and the appropriate decryption tool on the receiving end. On Solaris, data integrity and encryption will be available in conjunction with Kerberos Version 5 in the future.

Footnote 14
Note there are several proposed ACL standards.