MQ L/L Channels Including V8 changes Morag Hughson hughson@uk.ibm.com Agenda MQ Configuration asks With some minor V8 updates Major new feature in MQ V8 ew ew in in V8 V8 Associating a certificate with an MQ entity Queue Manager Webphere MQ client Certificate Revocation ew channel attributes pecifying Cipherpec pecifying permitted partners pecifying that the partner must provide a certificate Using ecret Key Reset Using Channel tatus Refreshing Webphere MQ Certificate replacement Miscellaneous pecifying certified cryptography should be used pecifying cryptographic hardware (some platforms) pecifying L tasks (z/)
Webphere MQ and L QM1 (Local) QM2 (Remote) MCA Message Flow MCA Remote Queue ransmission Queue Application Queues Link-level security Application-level security Webphere MQ and L - otes We can look at the security of MQ at two levels which I will describe as application level security and link level security. L is used in Webphere MQ to do channel authentication and link-level encryption. his means that your messages are encrypted when they are moved across the network but they are not encrypted when they reside on your queues. If your security set-up is such that your queues are secure, then link-level security may be all that you require. If your system already authenticates applications and encrypts the messages at MQPU time and decrypts them at MQG time, then the messages are encrypted as they reside on the queues. hey should not require further encryption as they are transported across the network. In this scenario, link-level security may not be required, or may only be required for queue manager to queue manager authentication at a minimum.
Queue Manager Certificate Key Repository Contains Queue Manager's own Digital Certificate Digital Certificates from various Certification Authorities n Unix, Windows, ieries QMgrs Key database path n z/ Queue Managers Keyring name Default label z/ Queue Manager ibmwebpheremq<qmgr ame> (mixed case) label Distributed Queue Manager ibmwebspheremq<qmgr name> (lower case) label QM's Digital Certificate ALR QMGR LKYR(CQ1RIG) CRLABL( CQ1Certificate ) CRQGL( haredcert ) LKYR ALR QMGR LKYR('var/mqm/qmgrs/QM1/ssl/key') CRLABL( QM1Certificate ) In V8 can use the QMGR CRLABL attribute ew ew in in V8 V8 Queue Manager Certificate otes A digital certificate contains the identity of the owner of that certificate. ach Webphere MQ queue manager has its own certificate. n all platforms this certificate is stored in a key repository using your digital certificate management tool, e.g. in RACF (z/) or ikeyman (UIX and Windows). he key repository is specified on the Webphere MQ QMGR object using the ALR QMGR command. n z/ this is the name of the keyring object in the xternal ecurity Manager (M), and on the distributed platforms this is the path and the stem of the filename for the key database file. he key repository generally also contains a number of signed digital certificates from various Certification Authorities which allows it to be used to verify certificates it receives from its partner at the remote end of the connection. Before Webphere MQ V8, the label name for a digital certificate to be used by the queue manager was fixed by MQ. You had to label your certificate exactly as Webphere MQ required it, in order for the certificate to be found. his doesn t always meet customer standards of certificate labelling. n z/, the unless told otherwise, MQ looks for a certificate in the key repository labeled as ibmwebpheremq<qmgr ame>. n UIX, Windows and ieries, the certificate label searched for is the lower-case label ibmwebspheremq<qmgr name>. ote that the certificate label is also sometimes referred to as its "friendly name". In Webphere MQ V8 you can provide your own label name for the queue manager to use with a new attribute on ALR QMGR called CRLABL (and additionally CRQGL on z/ for a QG level certificate previously located with the label ibmwebpheremq<qgname>).
Client Certificate Key Repository Contains Queue Manager's own Digital Certificate Digital Certificates from various Certification Authorities mqclient.ini file L tanza LKeyRepository MQCX (MQC structure) KeyRepository nvironment variable export MQLKYR=var/mqm/ssl/key Default Label ibmwebspheremq<logged on userid> (lower case) label In V8 can name Client Certificate mqclient.ini file L tanza CertificateLabel MQCX (MQC structure) CertificateLabel export MQCRLABL=MyCert MQC cno MQC sco = {MQC_DFAUL}; = {MQC_DFAUL}; cno.version = MQC_VRI_4; sco.version = MQC_VRI_5; memcpy(sco.keyrepository,... ); memcpy(sco.certificatelabel,..); cno.lconfigptr = &sco; MQCX(QMame, &cno, &hconn, &CompCode, &Reason); QM's Digital Certificate LKYR ew ew in in V8 V8 mqclient.ini L: LKeyRepository=C:\key CertificateLabel=MyCert Client Certificate otes A digital certificate contains the identity of the owner of that certificate. Generally each user of the Webphere MQ client has a separate key repository file, with access restricted to that user. his key repository file is accessed using the environment variable MQLKYR, or the MQCX LKeyRepository parameter. he key repository generally also contains a number of signed digital certificates from various Certification Authorities which allows it to be used to verify certificates it receives from its partner at the remote end of the connection. Before Webphere MQ V8, the label name for a digital certificate to be used by an MQ Client was fixed by MQ. You had to label your certificate exactly as Webphere MQ required it, in order for the certificate to be found. his doesn t always meet customer standards of certificate labelling. Unless told otherwise the MQ client code uses the certificate labeled with ibmwebspheremq followed by the logon userid, wrapped to lower case. In Webphere MQ V8 you can provide your own label name for the MQ Client to use. For clients, you can provide the Certificate label in the MQC structure (along with the LKeyRepository location); or in the L stanza in the mqclient.ini file (along with the LKeyRepository location), or using the environment variable MQCRLABL.
Certificate Revocation Define AUHIF objects DFI AUHIF(LDAP1) AUHYP(CRLLDAP) CAM('ldap(389)') LDAPUR('cn=user') LDAPPWD(...) DFI AUHIF(CP1) AUHYP(CP) CPURL( http://ocsp.server ) LDAP Conname LDAP Userame LDAP Password Revoked Alice LDAP erver Put these AUHIF objects into a namelist Associate namelist with QMGR LCRLL attribute CP erver Clients: Client Channel able or MQCX Client Channel able contains the AUHIF definitions present when table copied off Certificate Revocation - otes Queue Manager Certificate Revocation Lists (CRLs) and Authority Revocation Lists (ARLs) can be stored in and accessed from Lightweight Directory Access Protocol (LDAP) servers. A few parameters must be specified to be able to access an LDAP server containing CRLs and ARLs. hese parameters are the D name or IP address of the LDAP erver with an optional CP/IP port number; also optionally the Distinguished ame of the entry that is binding to the directory (e.g. C=UK, =IBM, U=Development, C=John mith), and the password associated with the Distinguished ame. ote that LDAP CRL/ARL servers are generally defined to be publicly readable. hese parameters are defined on a queue manager object, an AUHIF object. everal of these objects may be needed to ensure redundancy so that, for example, if the first LDAP server connected to is down, another can be connected to that will be able to supply the same information. Up to ten of these AUHIF objects can be supplied for CRL/ARL checking. he list of AUHIF objects is named in a namelist and this namelist is specified on the LCRLL queue manager attribute using the ALR QMGR command. he above mechanism for accessing LDAP CRLs is not available on /400. n /400, LDAP CRLs are accessed using Digital Certificate Manager (DCM). An alternative to CRLs on LDAP servers (available on Windows and Unix) are the use of CP servers. he URL to connect to the CP server can either be used directly from the certificate where it may be included by the CA as a certificate extension, or configured in an AUHIF object. Clients When the channel runs, the client channel definition table AUHIF information does not have to match the definitions current on the queue manager system at that stage. MQCX provides a structure, MQAIR (MQ auth info records), to allow AUHIF details to be specified.
LCIPH nly mandatory parameter on an L channel Without it channel is assumed not to be using L pecify the Cipherpec to be used Both ends must specify the same Cipherpec ALR CHL LCIPH( L_RA_WIH_ULL_HA256) or LCIPH(003B) From a list of human-readable strings z/ and IBM i: also L API numeric values Allow support of new Cipherpecs without updates to MQ Code Full list in Knowledge Center http://www.ibm.com/support/knowledgecenter/fkj_8.0.0/com.ibm.mq.sec.doc/q014260_.htm HA-2 algorithms available everywhere in V8 And earlier by APAR, see technote http://www.ibm.com/support/docview.wss?uid=swg21639606 ew ew in in V8 V8 Platform support Cipherpec name Protocol Used Data Integrity ncryption Algorithm ncryption Bits FIP uite B L 3.0 L 1.0 L 1.2 MD5 HA-1/2* AAD* RC2/4 [3]D A 40, 56 128, 168 256 Yes / o 128/192 bit o LPR pecify the partner's Distinguished ame Can use wildcards Multiple rganisational Unit (U) Must be specified in descending hierarchical order (e.g. U=Big Unit, U=Medium ized Unit, U=mall Unit) Can get much more flexibility using CHLAUH rules for peer name matching More on this later LPR('C="Morag Hughson", =IBM') or LPR('U=Webphere*, =IBM')
LCAUH Client Authentication Request whether the client end is required to provide a certificate for authentication.b. Client refers to L Client, i.e. initiating end of session LCAUH(RQUIRD) or LCAUH(PIAL) ew Channel Attributes - otes here are three channel attributes that can be used when setting up L on your CP/IP channels. LCIPH his is the channel parameter that you use to specify the Cipherpec to be used by the channel. he same Cipherpec must be specified at both ends of the channel for the L session to be successfully established. he values used are most often the string values listed in the Knowledge Center which are a human-readable string combining the encryption algorithm and the hash function to be used. he corresponding numeric values for the / L API can also be used on z/ and ieries, thus allowing new Cipherpecs to be supported without updates to Webphere MQ code. Different types of input can be successfully used on the two ends of a channel as long as they specify the same Cipherpec. / API values are not relevant on UIX and Windows as on these platforms L support (GKit) is part of Websphere MQ. For a list of those numbers see on z/:- http://www.ibm.com/support/knowledgecenter/api/content/fkj_8.0.0/com.ibm.mq.ref.doc/csq_x.htm#csq_x csqx631e LPR his parameter is used to check against the Distinguished ame from the partner's certificate. his field can have wildcards to allow generic matching. If the field is left blank or is not present then no checking is done against the partner's Distinguished ame within the Webphere MQ code. Generally speaking we now advise to use CHLAUH for peer name matching as it is much more flexible - more on that later. LCAUH he end of the channel which initiates the L connection is considered by L to be the client. he client always authenticates the server's certificate, but may not necessarily send a certificate to the server to be authenticated. his parameter is used on the L server end of the connection to say whether we expect a certificate for authentication from the L client, or whether only the server end will have its certificate authenticated. his may be useful for Webphere MQ client connection, or for lightweight queue managers, or indeed for any initiating partner where authentication is not deemed necessary. his parameter can have the value PIAL or RQUIRD. he default is RQUIRD.
Using ecret Key Reset Periodic renegotiation After a specified number of bytes of data has flowed Before sending data after an idle period in which heartbeat(s) have flowed et specified number of bytes LRKYC queue manager attribute Display Channel tatus shows he number of times the key has been reset he time/date of the last reset ALR QMGR LRKYC(999 999 999) DIPLAY CHAU(*) LRKY LKYDA LKYI Using ecret Key Reset - otes ecret Key Reset is a feature introduced in Webphere MQ V6. An L channel will periodically renegotiate its secret key algorithm if ecret Key Reset is enabled. his renegotiation will take place after the specified amount of data has been moved across the channel, and also before data is next sent across a channel that has been idle for a period of time and has sent heartbeat flow(s). Fields in the channel status display will show when the last reset was done and how many resets have been done for the life of this channel instance.
Using Channel tatus Fields showing Partner Certificate details LPR Partner's Certificate ubject s Distinguished ame LCRI Partner's Certificate Issuer's Distinguished ame Mapped User ID (z/ only) LCRU Also passed to ecurity exit and CHLAUH rules More on CHLAUH later LPR(C=MQ23,=Queue Manager,=IBM,L=Hursley,=Hampshire,C=UK) LCRI(C=Webphere MQ CA,=IBM,L=Hursley,=Hampshire,C=UK) LPR(C=MQ23,=Queue Manager,=IBM,L=Hursley,=Hampshire,C=UK) LCRI(C=MQ23,=Queue Manager,=IBM,L=Hursley,=Hampshire,C=UK) Using Channel tatus - otes here are a number of fields in the channel status displays that are related to L channels. LPR and LCRI hese two fields show the details of the partner's certificate. LPR on DIPLAY CHAU should not be confused with LPR on DIPLAY CHAL. n the channel definition LPR contains the filter to match against the partner's D, and on channel status it shows the actual D of the partner's certificate. LCRI contains the issuer's D from the partner's certificate. If LPR and LCRI are the same, the certificate is self-signed. hese fields are also passed to the ecurity xit so more complicated decisions can be made based on this information. LCRU n z/, when mapping a certificate in RACF to a user ID, this field shows the user ID found.
Refreshing L on Webphere MQ Cached view(s) of Key Repository Changes require cached view(s) to be refreshed ew certificates Deleted certificates Updated certificates Replacing expiring certificates RFRH CURIY YP(L) his command tops all L channels ew cached view(s) of the Key Repository created tarts all L channels again ender types Receiver types will restart when partner retries Also picks up other changes ew Key repository location ew LDAP CRL/ARL locations Refreshing L on Webphere MQ - otes his feature was introduced in Webphere MQ V6. he L environment set up to run L channels in a channel process has a cached view of the key repository made at initialization time. If you make changes to your key repository, i.e. add, remove or update certificates, for example, because your are replacing a certificate that is about to expire, this cached view needs to be refreshed in order for the L channels to start using the new certificates. In order to refresh this cached view of the L environment, without disrupting any non-l channels, use the RFRH CURIY YP(L) command. his will stop all the L channels on the queue manager, new cached view(s) of the key repository will be made and all the sending type channels will be started again. Receiving type channels will get restarted as the partner end retries the connection. on-l channels will be unaffected by this command and will continue to run. Also use this command to pick up other changes, such as a new Key Repository locations, or new LDAP CRL/ARL locations.
Using Cert Labels to replace expiring certs Used to have to issue GKit/RACF commands to rename certificate ibmwebspheremqqm1 -> ibmwebspheremqqm1old ibmwebspheremqqm1new -> ibmwebspheremqqm1 RFRH CURIY YP(L) ow just MQ commands when the time comes Current label is QM1 Cert 2013 ALR QMGR CRLABL( QM1 Cert 2014 ) RFRH CURIY YP(L) ew ew in in V8 V8 Using Cert Labels to replace expiring certs - otes It is worth highlighting here that the change over from using one certificate to another is now a task that can be accomplished by the MQ administrator alone, when he is ready. he job of installing the new certificate can be done at any prior point and labelled however you wish. hat label does not now have to change in order to get the queue manager to use it, so it is just a task for the MQ administrator to tell the queue manager which label to use now, and then refresh.
Miscellaneous Using only officially certified cryptography on an L Important for UA (and other) government bids Can set up so can only use certain Cipherpecs Federal Information Processing tandards (FIP) Added at Webphere MQ V6.0 on Distributed platforms and V7.1 on z/ uite-b Added at Webphere MQ V7.1 on Distributed platforms CryptoGraphic Hardware on Unix and Windows Parameters are required by the L support. requirements vary according to hardware used pecify ALR QMGR LCRYP(<string>) <string>: cryptographic hardware configuration parameters Clients: nvironment variable or MQCX MQLCRYP=<string> LCryptoHardware L erver MV asks ALR QMGR LAK(8) Minimum 2 required to run L handshake and encryption calls on z/ Miscellaneous - otes Federal Information Processing tandards (FIP) he U ational Institute of tandards and echnology (I) is responsible for FIP. he particular area of FIP we are concerned with is the Cryptomodule Validation Program (CMVP), involving tests on individual cryptographic modules. At Webphere MQ V6.0, on all Windows and Unix platforms some of the cryptographic modules provided within Webphere MQ for use on L channels have been FIP 140-2 certified. nly some Cipherpecs are acceptable for FIP certification. It is possible to configure Webphere MQ queue managers and clients to only accept Cipherpecs for which the Webphere MQ cryptography has been FIP certified. (ote that this does not guarantee FIP certification if cryptographic hardware is used to provide the cryptography). CryptoGraphic Hardware on some platforms LCryptoHardware is in the MQCX structure, MQC -- L Configuration ptions. n other queue manager platforms the crypto-hardware is either configured automatically by the L software or is configured by the systems administrator independently of Webphere MQ L erver MV asks erver asks, similar to the adapter tasks already in the Channel Initiator address space, are required to run the L Handshake on z/. he number of these tasks started is specified using ALR QMGR LAK. If there are not at least two of these tasks then no L channels will be able to start.
Request for nhancement (26672) ew ew in in V8 V8
Business Partners with different CA requirements QMgr4A QMgr QM's Digital Certificate from Veriign? QMgr4B QM's Digital Certificate from ntrust nly one certificate to identify the queue manager L/L etwork Communications L/L etwork Communications BP A BP B Business Partners with different CA requirements otes Imagine the situation where your company has need to communicate securely with two difference business partners. hese business partners each have a different requirement about the Certificate Authority (CA) who signs the certificates that they are happy to accept. In our example, Business Partner A will only accept certificates signed by Veriign, whereas Business Partner B will only accept certificates signed by ntrust. In order for your company to be able to communicate with both of these Business Partners, you need a certificate that is signed by Veriign (to communicate with Business Partner A) and a certificate that is signed by ntrust (to communicate with Business Partner B). However, since a queue manager can only have one certificate, with releases prior to V8 of Webphere MQ, you were forced into having two queue managers, one using each certificate. his is less than ideal..b. ome people also solve this issue by using an MQIP in front of the queue manager.
Certificate per Channel ALR CHAL(BPA..M) CHLYP(RCVR) CRLABL( VeriignCert ) ALR CHAL(.BPA) CHLYP(DR) CRLABL( VeriignCert ) QMgr QM's Digital Certificate ALR CHAL(BPB..M) CHLYP(RCVR) CRLABL( ntrustcert ) ALR CHAL(.BPB) CHLYP(DR) CRLABL( ntrustcert ) L/L etwork Communications QM's Digital Certificate from Veriign QM's Digital Certificate from ntrust L/L etwork Communications BP A BP B Certificate per Channel otes What is required is the ability to indicate that this particular channel should use a different certificate than other channels. his is achieved in Webphere MQ V8 with an attribute on a channel, CRLABL, which can either be blank which means use whatever the queue manager overall is configured to use, or if provided, means that this channel should use the specifically named certificate. For reasons explained a little later on, we only allow you to specify a non blank CRLABL at definition time if you are using a L cipherspec.
Why haven t we always done this? QM1 (Local) ransmission Queue QM2's Digital Certificate MCA L/L Handshake Flows L/L Handshake Flows Initial data flow (inc. Chl ame) egotiation complete Message Message QM2 (Remote) MCA QM1's Digital Certificate Application Queues Channel Why haven t we always done this? otes he L/L handshake is done as the first thing on a channel, before any of the internal channel FAP flows. If you have ever pointed a web-browser with a https:// address at your MQ listener port, you ll know this. his means that the certificate is authenticated long before the channel name at the receiver end is known. his made it impossible to choose a certificate to be used for a receiver based on the channel name. he best that could have been done would have been to provide a different certificate per port number and have several different listeners running, each presenting a different certificate. ver time however, as L/L is used by more and more consolidated servers, think HP server farms and large application servers, it has become necessary to be able to separate the traffic that is going to a single server into differently authenticated groups. nhancements to the L protocol allow the provision of information as part of the L handshake which can then be used to determine which certificate should be used for this particular connection. his enhancement is known as erver ame Indication (I).
erver ame Indication website-a.com Website A s Digital Certificate website-b.com Website B's Digital Certificate website-c.com Website C's Digital Certificate erver ame Indication otes Wikipedia provides a succinct summary of what erver ame Indication (I) is. he example on this page shows a use case where I would be used. We have three websites which each have their own certificate. When they were hosted on individual servers, then this was no problem, each web server has one certificate. ow let s think about what happens if we decide to consolidate those web sites onto a single server. How can we maintain the certificate correlation with the website. I allows this to be able to happen by providing a place in the L handshake for additional data to be flowed. his additional data is the hostname the browser was trying to connect to, thus allowing the certificate to be chosen based off that hostname.
Using erver ame Indication (I) with a channel name QM1 (Local) ransmission Queue MCA Chl:.QM2's Digital Certificate Channel L Handshake Flows (inc. Chl ame) L Handshake Flows Initial data flow (inc. Chl ame) egotiation complete Message Message QM2 (Remote) MCA QM1 s Digital Certificate Application Queues Both ends of the channel must be at the new release nly L can be used, no L nly certain cipherspecs will be able to supply this behaviour J doesn t yet support I o Java client can t make use of it If old sender/client used, we d only detect that we needed to supply a different certificate after completion of the handshake and will fail the connection, if it hasn t already failed due to using the wrong certificate! Using erver ame Indication (I) with a channel name Webphere MQ V8 uses I to provide a channel name instead of a hostname. he sender (or client) end of the channel has been enhanced to put the channel name into the erver ame Indication (I) hint for the L Handshake. he receiver (or server-conn) end of the channel has been enhanced to retrieve the channel name from the I hint and select the appropriate certificate based on that information. It is worth nothing that the channel name is now flowing in the clear, although in a tamper-proof manner. here are some restrictions to using this feature as listed. A back-level queue manager upon receiving a L handshake containing I, will just ignore what is in the I (as it is defined as an optional extension) and use the normal certificate. If there are no channels defined on the queue manager with anything in the CRLABL field, then I will not be used by the receiving end. his will leave the behaviour the same as prior releases for certificate selection.
ur Business Partner cenario again CHLAUH(BPA..M) YP(LPRMAP) LPR( C=BP A ) MCAUR(BPAUR) QMgr CA Certificate CA Certificate Internal BP A's Digital Certificate from Veriign L/L etwork Communications QM's Digital Certificate from Veriign L/L etwork Communications QM2's Digital Certificate from Internal CA Internal CA BP A Internal QMgr ur Business Partner cenario again otes Let s look again at the business partner scenario again, but this time a little different, with one external CA and one internal CA. We ve got the system set up so that we re using a Verisign certificate when talking to Business Partner A, and for the rest of our connections we have certificates created by our Internal CA. We ve even got CHLAUH rules in place to ensure that they are only allowed to connect to the queue manager over their appropriate channel.
nsuring the Correct Certificate QMgr CHLAUH(BPA..M) YP(LPRMAP) LPR( C=BP A ) MCAUR(BPAUR) LCRI( C=Veriign ) CA Certificate CA Certificate Internal ecurity xit is passed MQCD.LPeeramePtr MQCXP.LRemCertIssamePtr L/L etwork Communications ecy xit BP A's Digital Certificate from Internal CA Internal CA Rogue connection nsuring the Correct Certificate otes However, since we now accept certificates which come from two different Certificate Authorities (CAs) we can run foul of another issue. ne of the benefits of CAs is that they guarantee not to issue the certificates with the same D as another certificate that they have already issued. o a rogue connection could not obtain a certificate with the same D as Business Partner A from Veriign, because Veriign has already issued one with that D. Also, one would expect external CA s to do a few more checks than that and not issue certificates with other people s company names in them to people not from that company. However, an internal CA may not be so diligent. ome internal CAs may simply accept what the user requests as their D, so our rogue could obtain a certificate with Business Partner A s D from such a CA. he only way to solve this issue in the past was to use a security exit, since security exits are presented with both the issuer s and subject s Distinguished ame. However, we are trying to get away from people having to write exits for common security issues, and this very much falls into that category. In Webphere MQ V8, we can solve this issue by using a new attribute on CHLAUH rules which matches the issuer s D LCRI. ur CHLAUH rules can now be fully qualfied to use both LPR (the subject s D) and LCRI (the issuer s D).
Certificate D Matching Webphere MQ V5.3 ALR CHAL(APP1.VRC) CHLYP(VRC) LPR('C="Morag Hughson",=IBM') MCAUR('Morag') ALR CHAL(APP1.VRC.XRA) CHLYP(VRC) LPR('C="Graham Richards",=IBM') MCAUR('Graham') Webphere MQ V7.1 CHLAUH(APP1.VRC) YP(LPRMAP) LPR('C="Morag Hughson",=IBM') MCAUR('Morag') CHLAUH(APP1.VRC) YP(LPRMAP) LPR('C="Graham Richards",=IBM') MCAUR('Graham') IBM MQ V8 CHLAUH(APP1.VRC) YP(LPRMAP) LPR('C="Morag Hughson",=IBM') LCRI('C="MQ Devt" CA,=IBM') MCAUR('Morag') CHLAUH(APP1.VRC) YP(LPRMAP) LPR('C="Graham Richards",=IBM') LCRI('C="MQ Devt" CA,=IBM') MCAUR('Graham') eed an extra channel object for different patterns ow can consolidate channel definitions ot available on channel object Certificate D Matching - otes In the original version of Webphere MQ that supplied L support (Webphere MQ V5.3) certificate D matching could be done using the LPR attribute on a channel definition. his was a single pattern per channel, and although it allowed wildcard matching the patterns you were matching on had to be fairly similar on any one channel. In Webphere MQ V7.1 CHLAUH rules were introduced that also allowed certificate D matching and were more flexible because along with the wildcard matching that you had before, you also had the ability to add as many rules as you wanted to, to any one channel name. In IBM MQ V8, the CHLAUH rules were extended further to allow you to match not only on the ubject s D but also on the Issuer s D allow even more control over recognising a partner s certificate. LCRI is the CHLAUH attribute for the Issuer s D and it has not been added to the channel definition. It is recommended that you use CHLAUH for all your certificate D matching requirements.
ecurity Problems? olutions Confidentiality ymmetric Key Cryptography Data Integrity Hash Function Authentication Digital Certificates Asymmetric Keys Plaintext A Private Hash Function Alice's Digital Certificate A Public h with IBM MQ LCIPH(RC4_MD5_U) LRKYC(999 999 999) LKYR(QM1KYRIG) CRLABL('QM1Cert') LPR('=IBM') LCRI('C=MQ CA') LCAUH(RQUIRD) Revocation status checking Revoked Alice LCRLL(LDAPL) ecurity olutions with IBM MQ - otes Here we show three main security problems, eavesdropping, tampering and impersonation. We show the techniques that can be used to solve these problems. For eavesdropping, we have symmetric key cryptography; for tampering we have the hash function; and for impersonation we have digital certificates, asymmetric keys and certificate revocation. We have shown how Webphere MQ makes use of these techniques to provide these solutions to these security problems. ne can specify which symmetric key cryptography algorithm and which hash function to use by providing Webphere MQ with a Cipherpec. Digital Certificates and Public Keys are found in a key repository with a label, both of which can be specified to Webphere MQ. We can also check that we are talking to the partner we expect to be talking to by checking the ubject s and Issuer s Distinguished ame (D) and can choose to authenticate both ends of the connection or only the L erver end of the connection. Also we can make use of certificate revocation lists or CP.
ummary of IBM MQ V8 L/L related features ingle Queue Manager Certificate ALR QMGR CRLABL('My certificate name') Per Channel Certificate ALR CHAL CRLABL('his channel certificate') Certificate Matching CHLAUH('*') YP(LPRMAP) LPR('C=Morag Hughson') LCRI('C=IBM CA') MCAUR('hughson')