Introduction

The IBM Network Authentication Service (NAS) is based on the Internet Engineering Task Force (IETF) Request for Comment (RFC) 1510 standards protocol for Kerberos Version 5. Kerberos is a network authentication protocol. It is designed to provide strong authentication and encrypted communication for client-server applications by using secret-key cryptography. IBM NAS server (KDC) is supported on IBM AIX.

The Network File System (NFS) version 4 is the latest version of the NFS protocol, defining the new generation of network filesystems. NFS V4 is specified by RFC 3530. One of the important feature of NFS V4 is to meet higher standards of security. In this protocol, the client-server interactions are secured using GSS-API framework offered by Kerberos, LIPKEY, and SPKM-3.

IBM NFS V4 uses Kerberos implementation offered by IBM NAS for its security needs. IBM NAS is used for authentication and optionally for per-message encryption between NFS client and server.

IBM NAS supports different types of encryption. The difference between the encryption types is the strength of algorithm and length of the key being used. The combination of algorithm and the key length results in having stronger encryption, medium encryption, and weak encryption. IBM AIX® V5.3L and 6.1 onwards IBM NFS V4 is capable of making use of AES encryption (128- and 256-bit key lengths).

Encryption types supported by IBM NAS and IBM NFS V4

IBM NAS supports encryption algorithms such as Arcfour, DES, Triple-DES, and AES. With combination of different key lengths and different hashing algorithms, IBM NAS provides encryption types as shown in Table 1.

IBM NFS V4 supports small subset of encryption types from Table 1. The supported encryption algorithms are DES, Triple-DES, and AES. Combined with different key lengths and hashing algorithms, IBM NFS V4 supports these encryption types: des–cbc–crc, des–cbc–md4, des–cbc–md5, des3–cbc–sha1, aes128-cts, aes256-cts.

Which encryption type to use?

The combination of encryption algorithm and the key length governs the strength of the encryption type. The encryption types listed above has different strengths associated, with "ENCTYPE_AES256_CTS_HMAC_SHA1_96" being the strongest. The associated hashing algorithm is used for providing integrity services. Typically, stronger encryption types consume more time but ensure a higher degree of privacy and vice versa. While accessing finance-related or high-privileged data, the strongest possible encryption is recommended, whereas less strong encryption will do when accessing less-important data and data that needs to be available very quickly.

Depending on the need of privacy level the administrator/user decides on which encryption type to use and accordingly he/she needs to configure Kerberos realm.

What all encryption types configured by default?

A simple Kerberos configuration is a realm definition, which includes KDC server, kadmind server (optional) and clients. The configuration information is in forms of configuration files, namely “kdc.conf” and “krb5.conf”. All encryption types are not part of default Kerberos configuration. The default encryption types in the “krb5.conf” file and “kdc.conf” file are: “des3-cbc-sha1”, “arcfour-hmac”, “aes256-cts”, “des-cbc-md5”, and “des-cbc-crc”.

Back to top

Hypothetical setup involving a non-default encryption type.

Figure1 depicts a hypothetical setup of Kerberos realm, which involves non-default encryption type. This setup involves Kerberos Server, Kerberos clients and NFS server, NFS clients.

Here are some basic assumptions:

1. All the machines used in this configuration are IBM AIX boxes, with AIX 53L or AIX 61 and above.
2. We have one IBM NAS server (KDC). On the same machine another server (kadmind) will be running. For simplicity it has been omitted from the diagram.
3. “fsaix.in.ibm.com” is the NAS server machine.
4. All other machines in the realm are clients. Even the NFS server (client E) is also a Kerberos client.
5. As depicted in the diagram, every Kerberos client is restricted to use the specified encryption type(s) only.
6. Configuration steps needed for NFSv4 are omitted.

If we look at the encryption type requirements of Kerberos clients in Figure1, those are “aes256-cts”, “aes128-cts”, “des-cbc-crc”, and “arcfour-hmac”. Configure the setup using "config.krb5" command shipped with IBM NAS. To find out more on these, refer the IBM NAS Version 1.4 Administration Guide", shipped with the AIX Version 5.3/6.1 Expansion Pack CD (see Resources).

The following steps and listings shows basic configuration commands for server and client and its output.

Server configuration

bash-2.05b# hostname
fsaix.in.ibm.com
bash-2.05b# config.krb5 -S -d in.ibm.com -r MYREALM
Initializing configuration...
Creating /etc/krb5/krb5_cfg_type...
Creating /etc/krb5/krb5.conf...
Creating /var/krb5/krb5kdc/kdc.conf...
Creating database files...
Initializing database '/var/krb5/krb5kdc/principal' for realm 'MYREALM'
master key name 'K/M@MYREALM'
You are prompted for the database Master Password.
It is important that you DO NOT FORGET this password.
Enter database Master Password:
Re-enter database Master Password to verify:
WARNING: no policy specified for admin/admin@MYREALM;
defaulting to no policy. Note that policy may be overridden by
ACL restrictions.
Enter password for principal "admin/admin@MYREALM":
Re-enter password for principal "admin/admin@MYREALM":
Principal "admin/admin@MYREALM" created.
Creating keytable...
Creating /var/krb5/krb5kdc/kadm5.acl...
Starting krb5kdc...
krb5kdc was started successfully.
Starting kadmind...
kadmind was started successfully.
The command completed successfully.
      

Here are the default configuration files.

bash-2.05b# cat /var/krb5/krb5kdc/kdc.conf
[kdcdefaults]
kdc_ports = 88

[realms]
MYREALM =  {
database_name = /var/krb5/krb5kdc/principal
admin_keytab = /var/krb5/krb5kdc/kadm5.keytab
acl_file = /var/krb5/krb5kdc/kadm5.acl
dict_file = /var/krb5/krb5kdc/kadm5.dict
key_stash_file = /var/krb5/krb5kdc/.k5.MYREALM
kadmind_port = 749
kdc_ports = 88
max_life = 24h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-cbc-sha1
supported_enctypes = des3-cbc-sha1:normal arcfour-hmac:normal
aes256-cts:normal des-cbc-md5:normal des-cbc-crc:normal
}
      

bash-2.05b# cat /etc/krb5/krb5.conf
[libdefaults]
default_realm = MYREALM
default_keytab_name = FILE:/etc/krb5/krb5.keytab
default_tkt_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts des-cbc-md5 des-cbc-crc

[realms]
MYREALM = {
kdc = fsaix.in.ibm.com:88
admin_server = fsaix.in.ibm.com:749
default_domain = in.ibm.com
}

[domain_realm]
.in.ibm.com = MYREALM
fsaix.in.ibm.com = MYREALM

[logging]
kdc = FILE:/var/krb5/log/krb5kdc.log
admin_server = FILE:/var/krb5/log/kadmin.log
default = FILE:/var/krb5/log/krb5lib.log
      

Client configuration

bash-2.05# config.krb5 -C -r MYREALM -d in.ibm.com \
-c fsaix.in.ibm.com -s fsaix.in.ibm.com
Initializing configuration...
Creating /etc/krb5/krb5_cfg_type...
Creating /etc/krb5/krb5.conf...
The command completed successfully.
      

Listing 5 shows the configuration file on the Kerberos client.

bash-2.05# cat /etc/krb5/krb5.conf
[libdefaults]
default_realm = MYREALM
default_keytab_name = FILE:/etc/krb5/krb5.keytab
default_tkt_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts
des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts
des-cbc-md5 des-cbc-crc

[realms]
MYREALM = {
kdc = fsaix.in.ibm.com:88
admin_server = fsaix.in.ibm.com:749
default_domain = in.ibm.com
}

[domain_realm]
.in.ibm.com = MYREALM
fsaix.in.ibm.com = MYREALM

[logging]
kdc = FILE:/var/krb5/log/krb5kdc.log
admin_server = FILE:/var/krb5/log/kadmin.log
default = FILE:/var/krb5/log/krb5lib.log
      

After configuring the Kerberos client on all machines (A, B, C, D, and E from Figure 1), you get the same "krb5.conf" file across the machines. The relations “default_tkt_enctypes” and “default_tgs_enctypes” from "krb5.conf" file governs the encryption type in use for that client. It's straightforward that the configuration on all the clients is not as per the setup. The next section describes the changes required on all the clients.

Back to top

Configuration changes on Kerberos clients

In general you have to change the /etc/krb5/krb5.conf file to reflect the encryption type changes needed. The change will be reflected for the relations for default_tkt_enctypes and default_tgs_enctypes. These relations govern the encryption type used for getting a TGT (Ticket Granting Ticket) and TGS (Ticket Granting Service), respectively. In Figure 1, clients A, B, C, and D are using a single encryption type, while the client E is using two encryption types.

Now all of these clients need to have changed krb5.conf files. The following listings are a few of the changed configuration files.

bash-2.05# cat /etc/krb5/krb5.conf
…
…
default_tkt_enctypes = arcfour-hmac
default_tgs_enctypes = arcfour-hmac
…
…
      

bash-2.05# cat /etc/krb5/krb5.conf
…
…
default_tkt_enctypes = aes128-cts
default_tgs_enctypes = aes128-cts
…
…
      

bash-2.05# cat /etc/krb5/krb5.conf
…
…
default_tkt_enctypes = des-cbc-crc aes128-cts
default_tgs_enctypes = des-cbc-crc aes128-cts
…
…
      

Except for clients C and E, every other client is able to communicate and work with the Kerberos server without any further changes.

When client C tries to get a Kerberos ticket (TGT), the following error occurs:

-bash-2.05b# kinit admin/admin
Unable to obtain initial credentials.
Status 0x96c73a0e - KDC has no support for encryption type.
      

This clearly indicates that some changes at the server side (KDC) are needed. These changes are explained in the next section.

Back to top

Configuration changes on the Kerberos server

1. Edit the kdc.conf file

   While creating the principal, KDC makes use of encryption types specified in the kdc.conf file. So if a principal needs to support “aes128-cts,” the non-default encryption type, then it needs to be present in the kdc.conf file.

   Edit the kdc.conf file to reflect the encryption types required by all the clients and relevant principals. Modify the “supported_enctypes” relation in this file.

   
   
   Listing 10. Changed kdc.conf file on the Kerberos server
   

   bash-2.05b# hostname fsaix.in.ibm.com bash-2.05b# cat /var/krb5/krb5kdc/kdc.conf … … supported_enctypes = arcfour-hmac:normal aes256-cts:normal des-cbc-crc:normal aes128-cts:normal }

   
   
2. Restart the Kerberos server (KDC and Kadmind)

   After changing the kdc.conf file, the Kerberos server must be restarted. The kdc.conf file is read by the server at the startup, and hence you must restart the server to reflect the changes from the kdc.conf file.

   
   
   Listing 11. Restart the IBM NAS servers
   

   -bash-2.05b# stop.krb5; start.krb5 Stopping /usr/krb5/sbin/krb5kdc... /usr/krb5/sbin/krb5kdc was stopped successfully. Stopping /usr/krb5/sbin/kadmind... The command completed successfully. Starting krb5kdc... krb5kdc was started successfully. Starting kadmind... kadmind was started successfully. The command completed successfully.

   
   
3. Recreate the service principal "krbtgt/<realm_name>"

   The tickets (TGT and TGS) are issued by the KDC in the encryption type requested by the client (governed by the krb5.conf file), provided the respective service entity supports this encryption type.

   As shown in the previous section of this article, the TGT request from client C is not granted, saying that KDC does not support the encryption type. Even after changing the kdc.conf file, the error remains the same. This is due to the fact that the ticket-granting service “krbtgt/MYREALM” by default does not have the key for aes128-cts encryption types. See the following:

   
   
   Listing 12. Information of principal “krbtgt/MYREALM”
   

   bash-2.05b# kadmin.local kadmin.local: getprinc krbtgt/MYREALM Principal: krbtgt/MYREALM@MYREALM Expiration date: [never] Last password change: [never] Password expiration date: [none] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Tue Apr 22 10:51:04 CDT 2008 (db_creation@MYREALM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 5 Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt Key: vno 1, ArcFour with HMAC/md5, no salt Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt Key: vno 1, DES cbc mode with RSA-MD5, no salt Key: vno 1, DES cbc mode with CRC-32, no salt Attributes: REQUIRES_PRE_AUTH Policy: [none]

   
   

   The solution for this is to have the key of encryption type “aes128-cts” associated with the principal “krbtgt/MYREALM.” This is possible by deleting the principal “krbtgt/MYREALM” and recreating it.

   As the kdc.conf file has an entry of “aes128-cts:normal” encryption type, while recreating the principal “krbtgt/MYREALM,” a key for this encryption type is also created. See the following:

   
   
   Listing 13. Recreate the principal “krbtgt/MYREALM”
   

   kadmin.local: delprinc krbtgt/MYREALM Are you sure you want to delete the principal "krbtgt/MYREALM@MYREALM"? (yes/no): y Principal "krbtgt/MYREALM@MYREALM" deleted. Make sure that you have removed this principal from all ACLs before reusing. kadmin.local: addprinc -randkey +requires_preauth krbtgt/MYREALM WARNING: no policy specified for krbtgt/MYREALM@MYREALM; defaulting to no policy. Note that policy may be overridden by ACL restrictions. Principal "krbtgt/MYREALM@MYREALM" created. kadmin.local: getprinc krbtgt/MYREALM Principal: krbtgt/MYREALM@MYREALM Expiration date: [never] Last password change: Tue Apr 22 10:52:46 CDT 2008 Password expiration date: [none] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Tue Apr 22 10:52:46 CDT 2008 (root/admin@MYREALM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 4 Key: vno 2, ArcFour with HMAC/md5, no salt Key: vno 2, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt Key: vno 2, DES cbc mode with RSA-MD5, no salt Key: vno 2, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt Attributes: REQUIRES_PRE_AUTH Policy: [none]

   
   

   Now the Kerberos setup (IBM NAS setup) is ready for use, as depicted in Figure 1. From this point onwards, the administrator will follow the steps needed for NFS server and NFS client setup.

   Note that these steps are recommended to be executed only during server outages required for maintenance.

Back to top

Conclusion

This article elaborates on the different encryption types supported by IBM NAS and IBM NFS V4, and the importance of these encryption types and recommendation on their usage. It further provides guidance to the IBM NAS administrators on enabling non-default encryption types for IBM Network authentication Service by providing detailed examples.

Resources

Learn

• Configuring AIX 5L for Kerberos Based Authentication Using IBM Network Authentication Service: Read this white paper to learn about using Kerberos as an alternative authentication mechanism to AIX.
  
  
• A Kerberos Primer (developerWorks, Nov 2001): This article introduces Kerberos technology and Distributed Computing Environment-based applications.
  
  
• AIX and UNIX : Want more? The developerWorks AIX and UNIX zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials.
  
  
• developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
  
  

Get products and technologies

• IBM Network Authentication Service for AIX: Download the IBM Network Authentication Service for AIX from IBM AIX Web Download Pack Programs.
  
  
• IBM Network Authentication Service for Linux,Solaris: Download the IBM Network Authentication Service for Linux,Solaris from here.
  
  
• IBM GUI-based Administration Tool for Network Authentication Service: Experience the GUI to perform IBM NAS-related administration tasks. Download from IBM alphaWorks® today.
  
  
• AIX 5L Expansion Pack and Web Download Pack: Start downloading now.
  
  

About the author

Sachin Punadikar is a Principal Software Engineer for IBM India Software Labs. He has worked for IBM for the past seven years. He has experience in file systems (DFS), transaction processing monitors (TXSeries Encina), and security products such as Network Authentication Service (NAS). He is currently developing new features for the IBM Network Authentication Service, along with its product support. Sachin holds a bachelor's degree in computer science and engineering from Shivaji University, Kolhapur, India. You can contact him at psachin@in.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Encryption types supported by IBM NAS and IBM NFS V4
• Hypothetical setup involving a non-default encryption type.
• Configuration changes on Kerberos clients
• Configuration changes on the Kerberos server
• Conclusion
• Resources
• About the author
• Comments

Dig deeper into AIX and UNIX on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers