Well, here's the thing. If they're not using z/OS AT-TLS then they're also not using, among other things, TLS/SSL-encrypted TN3270E. And that omission is already most probably security malpractice. (RACF credentials flying over their network in cleartext? Not good!) Since your tool is for security provisioning and reconciliation....
If you don't use AT-TLS it means somebody has to figure out whatever you did, including key/certificate/CA stuff. The centralized point of control and management in AT-TLS is valuable. Any hardware and cryptographic innovations will automatically get picked up, and you won't have to be responsible for figuring out how to implement the AES651 algorithm or whatever. Moreover, there's nothing whatsoever preventing the customer from keeping those connections unencrypted if they wish (or routing them over IPSec). That is, if the customer wants to commit security malpractice with your product, too, the customer can. That might be OK for a proof-of-concept, for example. AT-TLS is still an option, technically speaking. In short, I don't see any downsides to AT-TLS, but I see quite a few upsides. Maybe I shouldn't have used the word "protocol." OK, TCP/IP, got it, but what sort of chatting between components will occur? What are they talking about, how often, how long, etc? Do you have any preferences for what you'd like to see, from an interface point of view, at either/both ends? -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA -------------------------------------------------------------------------------------------------------- E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
