Migrate to KDFAES for Stronger Encryption of RACF Passwords


Out of all the recent advances in RACF technology, perhaps the one most overlooked is password encryption. Did you know RACF now offers Key Derivation Function Advanced Encryption Standard (KDFAES) encryption of RACF passwords (commonly referred to as AES)? Would you like peace of mind that your passwords are protected by strong AES technology? Support has been available since Nov. 3, 2014.

Strategies can make deployment of AES encryption of all RACF passwords easier.

Why Convert to AES?

In the 21st century there’s no such thing as “too much encryption.” We live in a world where technology is advancing so fast that we must keep pace with the exponential increase in CPU capacity. Numerous standards require use of the latest cryptographic technology—e.g., PCI and National Institute of Standards (NIST). Whatever the reason, there's no justification to continue to use the old single 56-bit Data Encryption Standard (DES) algorithm originally deployed for RACF decades ago.

Converting Any UserIDs With Masked Passwords: Required for z/OS V2.2

A required z/OS 2.2 migration action ensures you don’t have any UserIDs still using the “masking” method. Since this method predates RACF’s use of DES you probably don’t have any of these but you should trust but verify. If the return code of your ICHDEX01 is set to 08 then there aren’t any masked passwords. Two methods for validating if you have masked password values are:

1) Run ICHPSOUT with PARM=DES. According to Mark Nelson, RACF development, IBM:

  • This method attempts to de-mask a password before doing a DES encrypt operation
  • It will write error messages if the de-masked value contains any invalid password characters
  • DES encrypted passwords run through this de-masking utility have a very high chance of not having valid chars

2) Use zSecure Audit

  • Typing the command AU.V to reach the verify and cleanup security database options
  • Select “Password - UserIDs with trivial passwords”
  • zSecure can compute any passwords that are weak or still using masking

Plan For PTF Installation

A very wise systems programmer once said, “Joel, before you put your fingers on the keyboard you should stop and think.”

The biggest issue with getting AES enabled is ensuring you have all the necessary PTFs rolling out on schedule. IBM has a website with Informational APAR II14765 to document all the necessary PTFs to install.

Further, applications that use RACF for authentication (e.g., CICS) may need PTFs. For CICS V5.1 three PTFs are provided via APARs PI21866, PI33454 and PI39336

Some APARs recently opened for which there aren’t PTFs yet. I recommend monitoring for when PTFs become available. PI64443 for increased CPU usage by CICS, OA50846 which affects IMS Connect logins (recommend you don’t convert IMS UserIDs until after this fix is applied) and OA50748 for CPU usage for applications that use the R_Password callable service (IRRSPW00).

Joel Tilton is a senior mainframe security engineer. A former employee of IBM, where he got his start with mainframes, he continues to champion mainframe security issues and solutions. The views expressed are his own personal views, and are not endorsed or supported by, and do not necessarily express or reflect, the views, positions or strategies of his employer. He can be reached via LinkedIn at

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Application Integration With PCI

The problematic nature of PCI-compliance application integration makes research, analysis and planning important. It can also greatly simplify and reduce the effort involved.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters