Network File System Version 4 (NFS Version 4) is gaining popularity, and enterprises have started formulating solutions that use its features and capabilities. Enriched security features are a key advantage of NFS Version 4 compared to earlier versions. Currently, NFS Version 4 supports only symmetric key-based security mechanisms, called Kerberos, so most deployments are using Kerberos as their authentication mechanisms.
In coming years, NFS Version 4 will extend support to public key security mechanisms, such as Simple Public Key Mechanism (SPKM) and LIPKEY. Because of the low infrastructure requirement, LIPKEY mechanisms will likely become a popular choice for Internet-based solutions and for solutions requiring public key technology for their security. To adhere to these requirements, administrators will be required to migrate or extend from Kerberos to the LIPKEY security mechanism.
This article briefly discusses different NFS Version 4 security mechanisms. It also explains how administrators can use an existing Kerberos authentication database in a LIPKEY security mechanism that helps extend their solutions to public key technology, as soon as NFS Version 4 offers such support.
NFS Version 4 is slowly, but surely, emerging as the next-generation enterprise file system. The NFS Version 4 protocol mainly focuses on addressing the shortcomings of previous versions. One major objective is security. Increasingly, businesses need to secure and protect data. Earlier versions of NFS had weaknesses that kept them from meeting those needs. NFS Version 2 and NFS Version 3 failed to provide strong authentication, fine-grained access control, strong encryption techniques, and unique identification of users. NFS Version 4 is designed to overcome these limitations and has been enhanced by having the security schemes built in.
NFS Version 4 uses Sun's remote procedure call (RPC) protocol to communicate over the network between the client and server. One RPC security flavor that the IBM implementation supports is RPCSEC_GSS security, as defined in RFC2203. Using RPCSEC_GSS security, you can apply the three levels of protection (authentication, integrity, and privacy) on the RPC as they are transmitted over the network between the server and client.
The following are three different required RPCSEC_GSS mechanisms that NFS Version 4 implementation supports, as defined in the NFS Version 4 standard (RFC 3530):
- Kerberos Version 5 [RFC-1964]
- SPKM-3 / LIPKEY [RFC-2847]
- SPKM-3 on its own [RFC-2847 / RFC-2025]
This section briefly covers all the RPCSEC_GSS mechanisms required by NFS Version 4.
- Kerberos Version 5 (IETF RFC-1964)
- The AIX 5L Version 5.3 Security Guide (see Resources) describes Kerberos as a network authentication service that provides a means of verifying the identities of principals (users and hosts) on physically insecure networks.
Kerberos provides mutual authentication, data integrity, and privacy under the realistic assumption that network traffic is vulnerable to capture, examination, and substitution.
Kerberos is a symmetric key mechanism that is more suited for an intranet-based solution. The Kerberos authentication method is the third-party authentication model; the trusted third-party or intermediary used in the Kerberos protocol is the Key Distribution Center (KDC). The KDC issues all of the Kerberos tickets to the clients. In the Kerberos protocol, a database is maintained that keeps a record of every principal. The record contains the name, private key, expiration date of the principal, and some administrative information about each principal. This Kerberos database is maintained on the master KDC and can be replicated to one or more replica KDCs. For detailed information on Kerberos protocol, see "A Kerberos primer" in Resources.
Apart from AIX® 5.3 NFS Version 4, other existing distributed file systems, such as DFS (Distributed File System) and AFS (Andrew File System), also use the Kerberos mechanism for their security.
- SPKM, (IETF RFC-2025)
- SPKM is a GSS-API mechanism based on a public key technology, unlike Kerberos, which is based on symmetric key technology. SPKM provides authentication, key establishment, data integrity, and data confidentiality in an online distributed application environment using a public key infrastructure. SPKM data formats and procedures are designed to be as similar to those of the Kerberos mechanism as is practical, for easy implementation in those environments where Kerberos has already been implemented. For applications that need to have a GSS-API mechanism based on a public key infrastructure, SPKM is the answer. For more information, see IETF RFC 2025 (in Resources).
- LIPKEY (Low Infrastructure Public Key Mechanism using SPKM, IETF RFC-2847)
- GSS-API mechanisms, such as Kerberos Version 5 [IETF RFC-1964] and SPKM [IETF RFC-2025], require a great deal of
infrastructure. As mentioned in IETF RFC 2847, LIPKEY is a low infrastructure-based GSS-API security mechanism that maps to a typical Transport Layer Security (TLS) deployment scenario. It consists of a client with no public key certificate accessing a server with a public key certificate. The LIPKEY mechanism can be used when the initiator (client) does not possess a public key certificate, and
instead uses user name and password for authentication.
LIPKEY mechanisms are built over SPKM-3 mechanisms. LIPKEY authentication works, as follows:
- The client with no public key certificate initiates the request to the server.
- The server possessing a public key certificate passes its certificate in the reply token to the client. The client uses this certificate to authenticate the server.
- In the token exchange, the client and server establish a secret session key (using Diffie-Hellman key establishment algorithm), and a secure channel is established.
- The client then provides a user name and password to the server in encrypted form.
- The server decrypts the information passed by the client and authenticates the client by validating the username and
password against its centrally managed username and password database. This username and password verification process is
independent of LIPKEY in exactly the same way that the unilateral TLS username and
password verification is independent of the TLS protocol.
Typically, most of the LIPKEY implementations use the native password database residing on the server's operating system for client authentication. Some LIPKEY implementations might provide a plug-in architecture that lets administrators use different authentication databases for verification of username and password supplied by the client. For more information on LIPKEY, read IETF RFC 2847 (see Resources).
Because of the asymmetric nature, these security mechanisms based on public key technology are more suitable for Internet-based solutions. The long-term plan for NFS Version 4 is to make it available on the Internet, separate from its usage in intranet-based solutions. For it to succeed, SPKM and LIPKEY, in particular, (because of its low infrastructure requirement ) will play a vital role.
Most of the current implementations of NFS Version 4 (including IBM AIX 5.3 NFS Version 4) support only Kerberos security mechanisms, so most initial deployments of NFS Version 4 have user authentication based on Kerberos. In Kerberos, the information is stored in the Kerberos security registry that could either be the legacy database on the local file system or in LDAP through the Kerberos LDAP directory plug-in. Likewise, even enterprises migrating from AFS or DFS to NFS Version 4 also have their authentication information migrated to Kerberos.
In a few years, NFS Version 4 implementations will start claiming support for the public key-based security mechanism (SPKM and LIPKEY). Many enterprises will then need to use these security mechanisms for their environment. Since LIPKEY has the inherent advantage of low infrastructure requirements, it might become a popular choice. The LIPKEY mechanism requires a username and password database for client authentication. NFS Version 4 administrators will then have to decide which username and password database to use for enabling the LIPKEY mechanism.
A major challenge that administrators face is to use the existing NFS Version 4 user authentication information stored in the Kerberos security registry with the LIPKEY authentication process. You could always choose to maintain a separate authentication database for a LIPKEY mechanism. But, maintaining separate authentication databases for the same set of users, and for similar purposes, has overhead and disadvantages, so this approach will generally not be favorable.
Another approach would be to reuse the existing Kerberos authentication database. Reusing the existing Kerberos registry reduces administration overhead required for user management, and allows NFS Version 4 users to have a single username and password required for NFS Version 4 authentication (regardless of whether NFS Version 4 is using Kerberos or a LIPKEY security mechanism).
There could be many different ways to address this issue. The example discussed below helps AIX NFS Version 4 administrators use existing Kerberos user authentication information for LIPKEY authentication whenever AIX NFS Version 4 starts claiming support for the LIPKEY mechanism. This example assumes that the AIX NFS Version 4 cell is configured using IBM Network Authentication Service (NAS), which is IBM's flavor of Kerberos, for Kerberos authentication.
IBM NAS exports administration APIs, commonly called the KADM5 APIs, that can be used to maintain principals and policies in the NAS database.
kadm5_init_with_password() is an API that you can use for verification of Kerberos username and password. The
kadm5_init_with_password() routine takes username and password as one of its input parameters and
verifies them against the Kerberos Version 5 administration service. Using this
API in the LIPKEY authentication process allows verification of the username and password supplied
by the client against the existing Kerberos security registry, as follows:
kadm5_ret_t kadm5_init_with_password (char * client_name, char * pass, char * service_name, kadm5_config_params * realm_params, krb5_ui_4 struct_version, krb5_ui_4 api_version, void ** server_handle)
Table 1 explains the input parameters.
Table 1. Input
|client_name||A valid principal name used for acquiring the ticket from the network service.|
|pass||The client's password.|
|service_name||Name of the service that will be used to communicate with the administration system. In this case, the service name is KADM5_ADMIN_SERVICE.|
|realm_params||A structure that contains parameters for the specified realm. This can be NULL, unless there is a need to override the configuration parameter values.|
|struct_version||Version of the administration system data structures. I set it to KADM5_STRUCT_VERSION to use the current structure version.|
|api_version||Version of the API. I set it to KADM5_API_VERSION to use the current API version.|
Table 2 shows the output.
Table 2. Output
|server_handle||Returns an opaque data structure that is used to communicate with the administration system.|
If the function's return value is KADM5_OK, then the username and password are successfully validated against
the Kerberos security registry. Remember to call the
kadm5_destroy() routine to end the session and release
I assume that the LIPKEY implementation used by NFS Version 4 allows administrators to use a different username and password database, apart from the native password database on the servers operating system, for the client authentication. (In this case, it will be the existing Kerberos security registry.) This could be through a plug-in interface. Administrators then need to take the following steps to reuse the Kerberos authentication database that has already been set up and is in use by NFS Version 4.
- Write a simple plug-in or program using the KADM5 API's that take username and password as its arguments, and uses the
kadm5_init_with_password()routine to verify them against the Kerberos security registry. Depending on the return value from
kadm5_init_with_password(), the plug-in or program returns success or failure.
- Make sure that the machine hosting the server configured for LIPKEY authentication is part of the existing Kerberos realm, whose security registry is required for client authentication.
- Have the LIPKEY mechanism at the server side invoke the KADM5 plug-in or program by passing the username and password obtained from the client. The plug-in or program validates the username and password against the existing Kerberos registry, and then returns success or failure to the LIPKEY module at the server side. In this fashion, you can use the existing Kerberos authentication database for validation of username and password supplied by the client, which is the key step in client authentication in the LIPKEY mechanism.
Based on this method, the following steps give an overview of the flow of events between client and server using GSS-API with the LIPKEY mechanism. The flow describes how the events inside the GSS-API layer (which encapsulates the LIPKEY layer) take place when the client and server are configured for LIPKEY authentication, and Kerberos security registry is being used for validation of username and password supplied by the client.
- Client initiates the request to the server.
- Server responds to the client by passing its digital certificate along with the reply token.
- Client authenticates the server using the digital certificate of the server.
At this point, the client and server have established a secured session. For detailed steps, see the LIPKEY RFC.
- Client sends the username and password in encrypted form to the server.
- Server decrypts the username and password, and passes it to the custom made Kerberos plug-in or program
(as explained above). The Kerberos plug-in or program internally makes a call to
kadm5_init_with_password()by passing the username and password as its input parameters.
kadm5_init_with_password()validates the username and password against the Kerberos authentication database and returns the status to the server.
- If the Kerberos plug-in or program returns success, the server goes on to create the secure LIPKEY context, or it does not. Whatever the case, it returns to the client the return status in encrypted form (using the reply token).
- The client decrypts the reply from the server and reads the return status indicating its authentication result.
Figure 1 shows the high-level steps between a client and server configured for LIPKEY authentication using a Kerberos authentication database for client validation.
The steps above are very high-level and convey the basic idea of how the Kerberos authentication database can be used in a LIPKEY security mechanism. It does not describe the LIPKEY implementation details. For internals on LIPKEY security mechanisms, see IETF RFC 2847 (in Resources).
Apart from the method described in this article, there could be many different ways to reuse the Kerberos authentication database in LIPKEY mechanisms. One possibility is to use the native password database on the server's operating system for client validation, which internally is designed and configured to make use of the Kerberos authentication service.
With NFS Version 4 slowly but surely emerging as the next generation distributed file system, enterprises have already started deploying NFS Version 4 in their production environment. This article discussed various NFS Version 4 security mechanisms, and showed how administrators can use an existing Kerberos authentication database in LIPKEY security mechanisms to be in position when NFS Version 4 extends its support for public key-based security mechanisms.
- Securing NFS in AIX:
An Introduction to NFS Version 4 in AIX 5L Version 5.3: Read this IBM Redbook for a broad
understanding of NFS Version 4 and specific AIX NFS Version 4 implementation
- Implementing NFS
Version 4 in the Enterprise Planning and Migration Strategies: Learn from this IBM Redbook the
methods for implementing NFS Version 4 in the enterprise, and extensive coverage
of methods for how it can potentially be used as a migration target for legacy
AFS- and DCE/DFS-based enterprise file systems.
"Network File System Version 4
Protocol:" Read IETF Request for Comments (RFC) 3530 for details on NFS Version 4.
- AIX 5L Version 5.3 Security Guide (SC23-4907-02): Provides system administrators with complete information on file, system, and network security.
"A Kerberos primer"
(developerWorks, Nov 2001): Read an introduction to Kerberos technology and Distributed Computing Environment-based applications.
"The Simple Public-Key GSS-API Mechanism (SPKM)": Learn details on the Simple
Public-Key GSS-API Mechanism (SPKM) from this IETF Request for Comments (RFC)
"LIPKEY -- A Low Infrastructure Public Key Mechanism Using SPKM": Learn details from this IETF Request for Comments (RFC) 2847.
Participate in the eServer™
forums or developerWorks
blogs to get involved in the developerWorks community.
Sandeep Ramesh Patil is a Staff Software Engineer for the IBM India Software Labs. He has worked for IBM for the past five years, focusing on distributed technology including DCE, SARPC, and security products such as the IBM Network Authentication Services (IBM Kerberos). He is currently developing new features and implementing security-related RFC for the IBM Network Authentication Service, along with its product support. He was involved in development and porting of IBM NAS1.4 on Windows.Sandeep holds a Bachelor of Science degree in Computer Science and Engineering from the University of Pune, India. You can contact him at email@example.com.