On 5/9/21 8:11 PM, Timothy Sipples wrote:
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.
I'd have to refresh myself on how granular you can target things, but I believe you can definitely differentiate between NFS, HTTP, MQ, JDBC, ODBC, Enterprise Extender, and any other protocols you're using based on the different ports that they operate on.
I agree that multiple TN3270E client sessions would (likely) be targeting the same mainframe IP and port. But there might be a way to extend the granularity used to match different service ports on the mainframe to also granularly match the different ephemeral ports that the client is using for each connection.
Aside: It looks like I can get extremely granular with the manual IPsec management method 'ip xfrm policy' command on Linux. Thus I would assume that IKE also supports such granularity.
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.
I'm going to assume that IKE can do what I can do with the 'ip xfrm policy' command until someone corrects me.
Thus, it should be quite possible to have different keying material for different TCP / UDP connections.
Your connection to Production LPAR A has no business being in the same cryptographic "zone" as your connection to Test LPAR B, for example.
I'd expect that different LPARs to have different IP addresses. Thus they would be in different IPsec security associations and have different keying material.
(And maybe YOU shouldn't have those two connections either, but at least you can avoid cryptographically unifying these connections.)
That's a different conversation.
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.
I get the impression that you're thinking a more traditional /tunnel/ connection with different (inside) tunnel IPs at each end. I'm talking about /transport/ mode, which is explicitly between two end system IPs.
I'm also assuming that it's possible to have different security associations per source IP, destination IP, source port, and destination port tuples. Thus TN3270E Session A would be in a different cryptographic zone from TN3270E Session B to the same endpoint. Other protocols / services would also be in different cryptographic zones.
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!
I disagree. Each layer of encryption (or more generically, tunneling) introduces it's own overhead and consumes usable space in packets, thus requiring more packets to get the same amount of data from end to end. There are many factors that come into play as to if this overhead causes problems or not.
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.
That would be the case with discrete security associations per per tuple.
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.
I've found that relying on the end user for security to be a weaklink in the chain. I would *much* rather rely on technology to enforce the security.
Aside: I can configure Linux so that IPsec protected packets are allowed while unprotected packets are rejected. I don't know if similar can be done on the mainframe or not.
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.
Sure. But there needs to be a way to do the task at hand and not be completely prevented from establishing the connection. At least I don't think the /client/ program has the knowledge of if a connection should be allowed or not. The server administrator probably does have the knowledge to make such a decision.
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.
Sure. -- Grant. . . . unix || die ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
