Configure IBM NAS version 1.4.0.7 for AIX to make use of non-default encryption type

This article provides step-by-step procedures of how to enable and make use of non-default encryption type such as "aes128-cts" in the Kerberos setup (IBM® Network Authentication Service). It also explains the reasoning behind every action taken in this regard. The explanation and reasoning will help Kerberos administrators make use of any other non-default encryption types in their Kerberos setups.

Sachin Punadikar (psachin@in.ibm.com), Principal Software Engineer, IBM

authpr photogSachin 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.



19 August 2008

Also available in Chinese

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.

Table 1. IBM NAS-supported encryption types
Encryption typeDescriptionName used in configuration file
ENCTYPE_AES128_CTS_HMAC_SHA1_96AES-128 CTS mode with 96-bit SHA-1 HMAC"aes128-cts-hmac-sha1-96" / "aes128-cts"
ENCTYPE_AES256_CTS_HMAC_SHA1_96AES-256 CTS mode with 96-bit SHA-1 HMAC"aes256-cts-hmac-sha1-96" / "aes256-cts”
ENCTYPE_DES_CBC_CRCDES cbc mode with CRC-32"des-cbc-crc"
ENCTYPE_DES_CBC_MD4DES cbc mode with RSA-MD4"des-cbc-md4"
ENCTYPE_DES_CBC_MD5DES cbc mode with RSA-MD5"des-cbc-md5"
ENCTYPE_DES3_CBC_SHA1Triple DES cbc mode with HMAC/sha1"des3-cbc-sha1"
ENCTYPE_ARCFOUR_HMACArcFour with HMAC/md5"arcfour-hmac"
ENCTYPE_ARCFOUR_HMAC_EXPExportable ArcFour with HMAC/md5"arcfour-hmac-exp"

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”.


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.
Figure 1. A hypothetical Kerberos setup using IBM NAS
A hypothetical Kerberos setup using IBM NAS

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

Listing 1. Configuring Kerberos server using "config.krb5" command
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.

Listing 2. kdc.conf file on Kerberos server
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
}
Listing 3. krb5.conf file on Kerberos server
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

Listing 4. Configuring Kerberos client using "config.krb5" command
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.

Listing 5. krb5.conf file on 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.


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.

Listing 6. Changed krb5.conf file for client A
bash-2.05# cat /etc/krb5/krb5.conf
…
…
default_tkt_enctypes = arcfour-hmac
default_tgs_enctypes = arcfour-hmac
…
…
Listing 7. Changed krb5.conf file for client C
bash-2.05# cat /etc/krb5/krb5.conf
…
…
default_tkt_enctypes = aes128-cts
default_tgs_enctypes = aes128-cts
…
…
Listing 8. Changed krb5.conf file for client E
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:

Listing 9. Error while getting TGT of encryption type “aes128-cts” on client C
-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.


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.


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

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=332194
ArticleTitle=Configure IBM NAS version 1.4.0.7 for AIX to make use of non-default encryption type
publish-date=08192008