Seymour J. Metz wrote: >What's wrongwith running a 3270 client in an encrypted VPN?
Grant Taylor replied: >IMHO, nothing. >I think the problem comes from complications around VPNs, not the least >of which include: >1) Complex configurations. -- Does the mainframe support being a VPN >endpoint itself? IPsec? Something else? z/OS does: IPsec (IKEv2). The major issue is that one VPN tunnel can be shared. When you operate this way, there's no security segregation per connection. The TN3270E traffic rides alongside NFS, HTTP, MQ, JDBC, ODBC, Enterprise Extender, and any other protocols you're using. Moreover, TN3270E Session A rides alongside Session B, Session C, etc. Usually you don't want multiple connections sharing the same private encryption keys, because the producers and consumers of data flowing over connection #1 should be kept cryptographically separated from the producers and consumers of data flowing over connection #2. Your connection to Production LPAR A has no business being in the same cryptographic "zone" as your connection to Test LPAR B, for example. (And maybe YOU shouldn't have those two connections either, but at least you can avoid cryptographically unifying these connections.) You could hypothetically solve this shortcoming by carefully configuring multiple active VPN connections with separate credentials and routing rules, but that can be quite difficult in practice. Thus the usual/typical best practice is to encrypt each connection separately (TLS-encrypted TN3270E, for example) insofar as possible *and* use a VPN at least if you're traversing a public network (and often also even if you're not). There's nothing wrong with double, triple, or even quadruple encryption! In this case, if someone or something manages to compromise your VPN connection, that someone or something still won't decipher each connection's separately encrypted traffic and would have to compromise each one separately since they use separate private keys. If you are restricted to using one and only one TN3270E session, with no other sessions of any type, and if the IPsec endpoints are the same endpoints that you would get with TLS-encrypted TN3270E, then IPsec/IKEv2 would provide a similar level of security compared to TLS-encrypted TN3270E. However, even then the end user wouldn't get visible, on screen assurance that the network path is reasonably secured because the magic padlock (or similar symbol) wouldn't appear on his/her emulator's screen. That's subpar because you're knocking the user out of the security equation. End user collaboration is really important to maintain a good or better security posture. As an aside, emulators should complain more loudly and forcefully when they're being asked to establish unencrypted sessions. I see some movement in that direction already, and it's a welcome development. Anyway, in summary, if you haven't already, get AT-TLS-encrypted TN3270E turned on, and shut off the unencrypted stuff. You've been able to avoid this class of security risks for literally a quarter century, and it's way, way past time to avoid them if you haven't already. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
