MQ

Considering all the variances, what are the implications for not using CONNAUTH at all? If we're using TLS channels and tight CHLAUTH and OAM rules, are we safe to avoid using CONNAUTH?

CONNAUTH = User id and Password checking

TLS channels = Authentication by digital certificate

The latter (digital certificates) is a much stronger type of authentication, so if you are already doing that with a certificate to identify each individual user that connects to your queue manager, then you don't need to add user id and password checking on top of it unless you have some business requirement to do so.

Cheers
Morag

I agree that digital certificates are a much stronger type of authentication but managing/controlling them can be a challenge, how do you stop people sharing them for example. Using a corporate LDAP, control of userid and passwords is likely to already be in place.  

Excellent point Rab.

For those starting out and trying to decide between passwords and TLS it is definitely a consideration.

If you already have TLS and processes for digital certificates in place, I wouldn't be throwing all that away to use passwords instead though.

Don't you have the sharing problem with passwords as well?  What stops people sharing those?

True, but in our organisation there are policies about sharing passwords that can lead to dismissal, it is a more mature process and it is drummed into people not to share them. I cannot say the same for certificates, but other organisations may have the same discipline with them though. 

A note on using SSL/TLS for authentication.  SSL was NOT designed to prevent access to a server.  In fact, that is the last thing that it was supposed to accomplish.  SSL was designed to authenticate the server to the client (not vice versa) as well as to encrypt transmitted data (i.e. Credit Card info).  In order for the Queue Manager to authenticate incoming certificates, two things must be in place:

1. Client Authentication must be enabled:  SSLCAUTH(REQUIRED)
2. Certificate Filtering may need to be enabled: SSLPEER('SERIALNUMBER=w,CN=x,O=y,OU=z, ...') 

Unless you require client authentication, MQ will only authenticate an incoming certificate if it is presented.  If no certificate is provided, then access will be allowed without authentication.  Not Good.  This is, of course, exactly what the bad guys will do.  So, when using SSL/TLS for authentication:  

Always set SSLCAUTH(REQUIRED)

Even with client authentication enabled, ALL certificates issued by any of the trusted CA certificates will be granted access with the User ID that they claim to be.  If you're using a third party CA, this means that you're willing to let a lot of people gain access to MQ using whatever ID that they assert. Unless you have an internal CA that has issued only a small number of certificates, or a self-signed certificate that has "issued" only one certificate (itself), you need to restrict the incoming certificate.  A trusted certificate that states "I'm a bad guy, don't let me in" should be allowed access.  To restrict unwanted certificates, there are only two approaches:

• Restrict the population of trusted certificates to a very small number using an internal CA or self-signed certificates.

• Use the SSLPEER parameter to specify which trusted certificates will be allowed entry.  

Since it never hurts, at worst will add documentational support and at best save your MQ network:  

Always set SSLPEER('CN=x,O=y,OU=z')

If you remember one thing from this, remember that SSL was designed to permit access, not to deny it.  You have to take positive action as an administrator to prevent incoming SSL channels.  Otherwise, your only encrypting the bad guys, not denying them entry.  

Regards,

Glen Brumbaugh

Its very clear cut explanation . 

I'm going to post a link to any important discussion regarding CONNAUTH in another thread.  I believe that you can use CONNAUTH to strengthen your security but, whatever your decision, both T.Rob and I agree that you need to understand this issue thoroughly before implementing it.  Using it incorrectly is MUCH WORSE, than not using it at all.  Here's the link: 

Great discussion from T.Rob on CONNAUTH

Regards,

Glen Brumbaugh