Provide a means to limit the permitted ciphers within a CICS region

Support for this is provided in CICS TS 6.1 which is generally available from 17th June 2022.

For more information see https://www.ibm.com/docs/en/cics-ts/6.1?topic=whats-new

Support for this is provided in CICS TS 6.1 which is announced today April 5th and will GA June 17th 2022.

See Announcement letter https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/2/897/ENUS222-092/index.html&request_locale=en

This is something we would like to address. The RFE is being moved into 'Planned for Future release' status. Please note:
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Apologies, this was moved to planned for future release in error. It is a candiadte for a future release, but not just yet.

This is something we would like to address. The RFE is being moved into 'Planned for Future release' status. Please note:
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

Thanks Arshia. This is a candidate for a future release.

That is exactly what we are looking forward. The mechanics of how to implement would be at your discretion. Using a "ALLVALIDCIPHERS.XML" sidefile via USSCONFIG would be fine. Thank you!

Arshia,
many thanks that is useful additional information.

As an alternative suggestion, we could have a master list of ciphers in USSCONFIG which only the network security personnel can update. This list would consists of those ciphers which you wish to support. This would probably be the ALLVALIDCIPHERS.XML
that we already ship as a sample.
Any way of specifying ciphers (API, RDO with cipher names, or RDO with an XML file), will only allow ciphers from that list.

Note that the only ciphers that we can support in CICS are those that are defined in system SSL, so our list would be a subset of those.

The problem in the proposed scenario is that is still doesn't limit API calls. They will continue to use the full suite of ciphers available to the CICS region, which is the same problem we have if a RDO entry doesn't specify either a manual entry of ciphers or the USS side-file and then makes an HTTPS call - it will use the full suite of ciphers available to the region rather than the subset network security personnel would want.

In 5.1 we introduced a mechanism whereby instead of the CIPHER option specifying a list of 2 digit ciphers,
you could specify an XML file name. This new file could contain either 2 digit or 4 digit ciphers and hence allowed the stronger TLS 1.2 ciphers.
The XML file is in the subdirectory /security/ciphers which should be set with permisions restricting to suitable network security personel.

For migration reasons we didn't prevent the old mechanism from explicitly using the 2 digit ciphers in the CIPHER option from being used.

Would a solution to this be to have a configuration option which just prevented the old mechanism from being used.
If this were set the RDO definition would only allow an XML file name.
This would give an indirection which would mean that only
network security personnel could then specify which ciphers could be used.
We provide 3 sample xml files, but you can decide whether you want to one or more of these, or create one or more of your own.