Hi Glen,
> Either I wasn't clear in my post or I misunderstand how this mechanism works.
I'm pretty sure you understand correctly how it works. I wonder whether you understand how it breaks.
If it were implemented correctly, ADOPTCTX would not be needed because there would be no option to nominate an ID other than the one that was authenticated. The problem is that IBM chose to break CHLAUTH ID mapping when ADOPTCTX was enabled. The result is that the MQ Admin is forced to choose between the ability to trust the ID resolved during authentication or the ability to use CHLAUTH to map the MCAUSER. While neither of these is desirable, one is merely annoying whereas the other provides only security theater.
As you, know security theater is worse than no security at all. When people know the security is weak they take fewer risks and employ more controls in adjacent systems. When ADOPTCTX is disabled they get the appearance of security when legitimate and well behaved users access the system and their authenticated accounts are seen in the MCAUSER. The security holes would be glaringly evident if any of those legitimate users were caught authenticating with their own ID but nominating an app service account for the connection to run as.
It should NEVER be the case that the client can specify an arbitrary ID which the MQ Admin is powerless to override but that's what we have with ADOPTCTX disabled. It must always be enabled and if the loss of CHLAUTH mapping is a problem then work around it, use an exit, use certificates, but do NOT disable ADOPTCTX.
> While I would prefer TLS certificates to be used as the secret…
It's not a question of how a secret is stored but rather how it is proved. With passwords the client is obliged to send the password to prove the secret and the only way to do this safely is by first building an encrypted session within which to send the password. With certificates the possession of the secret can be proven in full view of an attacker without risk of disclosure of the secret or man-in-the-middle exploits. This is why even IBM warns against using MQCSP password protection to safeguard the exchange: "MQCSP password protection is useful for test and development purposes as using MQCSP password protection is simpler than setting up TLS encryption, but not as secure." (
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q118710_.htm)None of this is helped by the fact of MQ exposing passwords on the wire in the earlier Fix Packs, even with protection enabled and even with a v8 client. (This may be the case in later Fix Packs but I didn't take the time to verify each and every release with Wireshark.) The implication is that server-keyed TLS is required at the very least to provide protection of passwords used with CONNAUTH. Upgrading to mutual auth TLS is a short hop from there and provides reliable, consistent, and secure authentication.
> In this case, it's not possible for the client ID to be valid. The client can, of course, assert a valid ID through this mechanism and then be mapped into an appropriate group through CHLAUTH processing.
Here, I think, may be the disconnect. The client does not "assert" an ID in this scenario. They present an ID and password which are authenticated by MQ. When we talk about assertion, that implies the ability to claim an identity that is trusted without further authentication. In your scenario where ADOPTCTX must be disabled so that CHLAUTH MAPPING can function you get the ability when I authenticate as T.Rob to map my resolved ID to something locally relevant such the generic SVRCONN ID mqmmqi. But as the client, I gain the ability to tell MQ to validate my T.Rob ID and password but once authenticated assert the glenb and run as that. Depending on the Fix Pack, you as the MQ admin see only the glenb ID and must map against that. Imagine your burden of audit proof if the ID that you as the MQ Admin see is one that the client arbitrarily specified and, because of how MQ works with ADOPTCTX disabled, you can't tell which ID was password authenticated by MQ.
> As I understand it, the key thing is to process CONNAUTH first and CHLAUTH second.
More precisely, the key thing is to perform authentication first and perform authorization second and against the ID that was resolved during the authentication. In MQ terms CONNAUTH authenticates an ID and password. CHLAUTH resolves the authenticated ID as part of authentication process and can also perform some rudimentary authorization functions. The problem with ADOPTCTX disabled is that even though authentication and authorization happen in the correct order, the ID against which authorization applies is not bound to the ID that was authenticated, thus rendering authorization meaningless.
I like to describe this as the "airport problem." Say you and I are flying out of the same airport. We are authenticated by the TSA at the checkpoint. If you claim to be me you get caught, and vice versa. Between the ID check, the luggage scan and the millimeter-wave naked x-ray, you might say we are pretty strongly authenticated. We run into each other and go grab drinks before our flights. In the bar for whatever reason we decide to swap tickets. If both are domestic flights, the gate agents allow us onto each other's planes without question.
In this case strong authentication was performed and an authorization function followed in the correct order, but it fails because the authorization function was not based on the identity resolved during the authentication phase. Even if the authentication was so strong that it included an escorted trip to a holding room, the authorization function relied on mere assertion. "Hi, I'm Glen. Here's my ticket."
> Wow. I took a look at your testing spreadsheet, which you referenced. You really did some impressive research on this!
Thanks! Unfortunately, I have a lot of MQ security projects in flight and they tend to get cycles only when a client sponsors related work or I'm on the bench. My recent clients have generally taken my advice to disable CONNAUTH until IBM makes a version that works and they are uniformly upgraded to that release, and so nobody sponsoring the CHLAUTH work right now. Fortunately for me but not so much for the CHLAUTH research project, I've not been on the bench in a couple of years. I'll keep plugging away when I can and of course happy to consider pull requests for the parts of the project on GitHub. (
https://github.com/tdotrob)Kind regards,
-- T.Rob
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
https://ioptconsulting.com https://ioptconsulting.com https://twitter.com/deepqueue https://twitter.com/deepqueuecid:
image001.png@01D3A4AD.C76FB280From: Glen Brumbaugh [
mailto:wsmqfam-ws@lists.imwuc.org]Sent: Monday, April 02, 2018 18:41 PM
To: T.Rob
Subject: [WSMQFam-ws] - RE: Are you using MQ Connection Authentication?
T.Rob,
Either I wasn't clear in my post or I misunderstand how this mechanism works. Either or both are possible. It was my understanding, and what I tested, that I could authenticate with CONNAUTH and then have the MCAUSER value mapped to another User ID by the Channel Authorization rules. This is were the ChlauthEarlyAdopt setting becomes important.
The only useful case where the asserted CONNAUTH identity would not be used is if it were locally valid, thus enabling the connection, but not a User ID with privileges. This then would need to be mapped to another context using stand Channel Authorization processing. In effect, this becomes a slightly stronger version of Channel Authorization, which also requires a secret. The secret would then actually confirm an identify and the resulting authorizations. Channel Authorization rules currently make a leap of faith saying that the asserted User ID is possibly correct and should therefore be authorized. Not very strong but better than nothing. Addding CONNAUTH strengthens this considerably. This could provide a generic secret, much like an API secret for connections instead of a password.
While I would prefer TLS certificates to be used as the secret being held rather than a User ID & Password combination, I believe that there is a case where the mechanism described above would come into play. I have a number of clients with different security zones backed by different AD or LDAP domains. Some are reluctant to distribute any trust across those domains. In this case, it's not possible for the client ID to be valid. The client can, of course, assert a valid ID through this mechanism and then be mapped into an appropriate group through CHLAUTH processing.
Is my thinking wrong on this? As I understand it, the key thing is to process CONNAUTH first and CHLAUTH second. Otherwise a security hole is opened, as you describe. I only performed my testing with CHLAUTH rules driving the ultimate MCAUSER ID. That's a pretty standard setup.
Wow. I took a look at your testing spreadsheet, which you referenced. You really did some impressive research on this!
Best regards,
Glen
On 04/02/18 03:40 PM, T.Rob wrote:
Hi Glen
I have to take exception with the assertion that there are any conditions under which AdoptCTX may be optional. In order for authorization to be relevant it must be based on the identity resolved during authentication. In IBM's original implementation the identity resolved by CONNAUTH authentication was not bound to the authorization. It is possible to authenticate under one ID and then nominate a completely different ID for MQ to evaluate using CHLAUTH rules and OAM.
When the credential database against which MQ authenticates was NIS+, Active Directory or other enterprise-wide context, the result was that anyone with a valid ID and password could authenticate to MQ and then nominate a service account or other privileged ID for MQ to further resolve using CHLAUTH and OAM. Furthermore, once this disaster was reported the behavior of MQ CONNAUTH/CHLAUTH interactions changed with almost every FixPack, making it almost impossible to specify a single configuration guaranteed to work across versions or regular maintenance intervals.
Please see:
https://t-rob.net/2016/10/28/chlauth-research-updates/The correct behavior would be for MQ to behave as if ADOPTCTX is enabled in all cases so that the ID which is authenticated is always the one against which CHLAUTH and OAM operate. The requirement to be able to map that ID to something else is not solved by disabling ADOPTCTX since doing so eliminates all the assurance authentication was supposed to provide. When the authenticated ID is not usable on the local system the mapping the solution is to make sure the mapping functions of CHLAUTH work, but apply them to the authenticated ID and not whatever ID the client user nominated. This was supposed to be the behavior provided with ADOPTCTX and ChlauthEarlyAdopt both enabled.
Because CONNAUTH was so horribly broken when first implemented, and because the behavior has changed significantly across releases and continues to do so, the best advice is to not use it at all. If it must be enabled, then the best advice is to enable ADOPTCTX and ChlauthEarlyAdopt. What is NOT recommended in any situation is to enable authentication in which the ID that is resolved can be specified arbitrarily by the client, which is the behavior seen with ADOPTCTX disabled.
Kind regards,
-- T.Rob
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
https://ioptconsulting.com https://ioptconsulting.com https://twitter.com/deepqueue https://twitter.com/deepqueuecid:
image001.png@01D3A4AD.C76FB280From: Glen Brumbaugh, 98285 [
mailto:wsmqfam-ws@lists.imwuc.org]Sent: Monday, April 02, 2018 11:46 AM
To:
WSMQFam-ws@lists.imwuc.orgSubject: [WSMQFam-ws] - RE: Are you using MQ Connection Authentication?
Great comments, but absolutes are often dangerous in security. Let's be careful when discussing the relationship between the CONNAUTH and ADOPTCTX parameters. They are two very different things. What ADOPTCTX does was described in the earlier comments, but see some additional comments about it below. The CONNAUTH setting is about establishing trust. This parameter can force an incoming connection, either local or remote, to re-authenticate prior to the connection being established.
The credentials being authenticated (User ID and Password) must be verifiable by the Queue Manager's host (using OS or LDAP). When crossing security domains, this is not always possible. A client may be given MQ access credentials in the same way that software may be granted system access credentials for a database. You may not want to run the channel under these credentials. Therefore, using ADOPTCTX may not always be appropriate. The actual security context may be set by CHLAUTH rules or Security exits.
ADOPTCTX
In LTS FixPack 9.0.0.1, a new attribute was delivered for use in the mq.ini CHANNELS stanza. This is the ChlauthEarlyAdopt parameter. This parameter controls the interplay between the User ID context set by the ADOPTCTX parameter and the User ID context set by the Channel Authorization rules. This parameter can control whether the Channel Authorization rules apply to the connection User ID (ChlauthEarlyAdopt=N) or whether the rules are applied to the CONNAUTH validated User ID (ChlauthEarlyAdopt=Y).
Regards,
Glen Brumbaugh
-----End Original Message-----
-----End Original Message-----
--
Regards,
Glen
-----End Original Message-----