MQ

This is part of an occasional series of small blog posts where I (Morag) will write about some of the quirks in IBM MQ, in the hope of invoking the response, "Well, I didn't know that!" Read other posts in this series.

A recent post by Roger Lacroix about the speed at which hackers can crack passwords of different lengths got me thinking about another MQ quirk, which is the subject of this post.

Old versions of MQ clients, and any still using the Java client in Compatibility mode are restricted to passwords of 12 characters or less. So if you're looking at the table in Roger's post and thinking you need to make your password longer, first you need to read this post.

In the early days of MQ, before the MQCSP structure was added, there was a user ID and password flow as part of the client FAP (that is the proprietary protocol used between the client and the queue manager to negotiate how they are going to communicate). This was added for those client platforms that didn't have any logon themselves, such as DOS, or Windows 3.1 (yes we're going back a few years!). It was later also adopted by the Java Client in an era where the JVM couldn't discover the O/S user Id it was running under.

Before the queue manager itself provided a facility to validate user ids with their passwords, users of MQ could obtain (write/purchase) a channel security exit that could pluck out the user id and password from the aforementioned FAP flow.

struct tagMQCD {
  MQCHAR    ChannelName[20];           /* Channel definition name */
  :
  MQCHAR    RemoteUserIdentifier[12];  /* First 12 bytes of user */
                                       /* identifier from partner */
  MQCHAR    RemotePassword[12];        /* Password from partner */
  :
  /* Ver:2 */

One thing you'll notice about these two fields in the MQCD that the security exit could use, is that they have a finite defined length of 12 characters. This means that you cannot use a password longer than 12 characters if this method of delivering it to the queue manager is employed.

When V8 introduced Connection Authentication, there was a likelihood that security exits such as these were installed on users' queue managers' and if the Java client were to simply start using the MQCSP instead, these exits would break. This resulted in a setting to switch between compatibility mode for the old FAP flow style of delivering the password, and the "new" MQCSP structure which was done with a pointer and a length.

 struct tagMQCSP {
   MQCHAR4  StrucId;             /* Structure identifier */
   MQLONG   Version;             /* Structure version number */
   MQLONG   AuthenticationType;  /* Type of authentication */
   MQBYTE4  Reserved1;           /* Reserved */
   MQPTR    CSPUserIdPtr;        /* Address of user ID */
   MQLONG   CSPUserIdOffset;     /* Offset of user ID */
   MQLONG   CSPUserIdLength;     /* Length of user ID */
   MQBYTE8  Reserved2;           /* Reserved */
   MQPTR    CSPPasswordPtr;      /* Address of password */
   MQLONG   CSPPasswordOffset;   /* Offset of password */
   MQLONG   CSPPasswordLength;   /* Length of password */
 };

This setting to choose the type of password delivery, also referred to as authentication mode, was initially defaulted to continue using the FAP flow mechanism. This was known as compatibility mode as it retained compatibility for the exits I mentioned above. In IBM MQ V9.2.1 the default for this setting was flipped to now use MQCSP. Enough time has passed since V8 to allow any exits to be updated to also cater for MQCSP or to remove them altogether. Here is an example of the setting:-

java -Dcom.ibm.mq.cfg.jmqi.useMQCSPauthentication=true MyJavaApp

There are a number of different ways this setting can be used depending on exactly how your Java application is written. They are covered in detail in this IBM Docs page, so I will not repeat them here.

So to summarise; if you are using passwords up to 12 characters in length, either mode can work. When you need to use longer passwords make sure that you are using the MQCSP authentication mode for your Java Client. This is the default if your client is at IBM MQ V9.2.1 or higher, or you will need to use the above property to force this mode if you are using an older client.